---

University of California, Davis

Application Development Methodology

---

Activity A3.1.4

Develop initial entity relationship diagram

Review the list of entity types found so far, check whether there has been any duplication or overlap, and adjust the list accordingly.

¤ Name the entity types

For each entity type, write a definition and choose the best name. State at least one identifier for the entity type (this may be a composite identifier involving attribute types and relationship types). If an entity type is a subtype of another entity type in the list, record the name of the parent entity type against the subtype.

¤ Construct an entity relationship diagram

Construct a diagram showing the entity types and relationship types found so far. By drawing the diagram, you may think of more entity types and relationship types. Do not wander outside the perceived scope or include redundant relationship types.

¤ Name the relationship types

Always provide a name for the relationship types on the diagram. Relationship types have two names, one for each relationship membership.

¤ Determine the cardinality and optionality of relationship memberships

Consider the cardinality of each relationship membership and indicate the cardinality of many or one on the diagram. Consider whether it is mandatory for the entity type to participate in the relationship membership; if it is not, indicate optionality on the diagram.

» Creates deliverable D3.2.1 Entity Type Definition

» Creates deliverable D3.2.2 Initial Entity Relationship Diagram

This page was last built on November 22, 1996.

4. Add the cost of each mechanism until the cost limit is reached.

5. Similarly, take the list of procedures ranked by cost benefit and work down the list until the cost limit is reached.

6. Select the procedures that now appear on both lists.

7. Reconsider the benefits and selection criteria of the remaining procedures.

8. If necessary, agree on a weighting for the cost benefit to arrive at one ranked listing.

9. Select more procedures until the cost limit is reached.

A4.8.4 Group procedures into implementation areas

Perform this task by arranging the logical constraints imposed upon the implementation sequence by the need for data and related procedures. Analyze logical constraints to determine the sequence in which procedures and preliminary data structures should be implemented, and to group them into reasonable areas for implementation.

- Purpose of implementation areas -

The purpose of grouping into implementation areas is to construct units that can be implemented as a whole. Implementation units should be small to allow evolutionary, incremental development. If large, complex implementation areas are constructed, risks are increased. The time required before there is any return on investment is also increased.

- Criteria for grouping procedures, linkages and record types -

Apply the following criteria for grouping procedures, linkages and record types into an implementation area:

* They should all be related to the same business need, objective, or benefit

* All data needed to support high-priority procedures should be included; consolidate procedure action diagrams

* All procedures required to support other necessary data should be included

* They should form a consistent, coherent whole

* The area should be small

- Sequence for implementing areas -

Define implementation areas so that each can be designed and implemented as a unit.

Build up the sequence for implementing these areas by considering the sequence in which individual procedures have to be implemented and by grouping related procedures. If you move a procedure from one implementation area to another, it may change the sequence in which the areas have to be implemented.

One of two situations arises:

* You have already implemented the necessary procedures and data.

* You must carry your design back into this new area and implement these procedures first.

- Identification of needed data -

Identify what data are needed. Once you have an initial list of procedures for each implementation area, you must check that the areas make sense in terms of data. Produce a definitive list of the record types, fields, and linkages to be incorporated in each implementation area.

For each procedure in an implementation area, take the procedure action diagram and add all the record types, linkages, and fields it uses to a list for the area. Two excellent rules are: always start at the top of a hierarchy and work down, and do Create functions first.

If you identified your procedure data flows correctly, these constraints should be consistent with the data flows. At worst, they will be additional because you overlooked something. If they conflict, check if the data flows and the model are right. This cross-check is often useful for unearthing misunderstandings.

- Identification of common records and procedures -

A question that will arise from time to time during the BSD is: "What is the scope of this procedure?" The designer has been able to specify many procedures that represent one process, or one procedure that has been generalized to represent many processes. Use cluster analysis to identify where record types can be combined, where common procedures can be found, and where two or more procedures may be combined into a single procedure.

- Common records -

Using the record/procedure matrix, you can identify the record types that are always used by a common set of procedures. Within the constraints of the logical constraint analysis, you can combine those record types into a single record type that is used by the set of procedures. This reduction in data structuring complexity will reduce the development costs, and the simplified procedures will be cheaper to maintain.

- Procedures that can be combined -

The linkage/procedure matrix and procedure dependency diagrams will indicate the serial structure of procedures that may be combined into a single procedure. In many cases, artificial procedures are defined that are only steps in a bigger and more comprehensive procedure. Cluster analysis enables procedures to be combined up to their dependency constraints.

- Common procedures -

Common procedures are more difficult to detect because the data that are acted upon have different names. As an example, the procedure to update the customer name and address may be similar to the procedure to update the supplier name and address. The field/procedure matrices will indicate when similar fields are manipulated in the same way. By designing the procedure to act on either the customer or supplier data, you can make one procedure do the work of two.

» Creates deliverable D4.3.3 Implementation Area.

› Updates deliverable D4.3.3 Implementation Area.

A4.8.5 Sequence the implementation areas

Cluster analysis indicates a logical sequence for implementation areas. The logic is based on a desire to minimize dependencies or interfacing requirements between areas. The areas that are relatively independent can be implemented before those with many dependencies, but business priorities may override the logical