Behavior Behavior in Software

Generating UCC - 12 in Software Behavior Behavior

Note that some references show a subtype of Interaction Diagram under Behavior Diagram, containing the Sequence, Interaction Overview, Communication, and Timing diagrams

Once the database designer has completed logical database design and an ERD for the proposed database and, in parallel, the process designers have completed their process model, how can we have any confidence that the two will be able to work together in solving the business problem the new project is supposed to address Part of the answer lies in a charting technique intended to show how the entities and processes interact, known as the CRUD matrix Fortunately, CRUD is not slang for a lousy design but rather an acronym formed from the first letters for the words Create, Read, Update, and Delete, which are the letters used in the body of the diagram The concept of the CRUD matrix is very simple:

One axis of the matrix represents the major processes of the application system The other axis represents the major entities used by the application system In each cell of the matrix, the appropriate combination of letters is written:

C, if the process creates new occurrences of the entity R, if the process reads information about the entity from a data source U, if the process updates one or more attributes for the entity D, if the process deletes occurrences of the entity

Here is a sample CRUD matrix for the order management function at Acme Industries, following the major processes shown in the function hierarchy diagram (refer to Figure 7-11) To be effective, only high-level processes and super-type entities should be shown in the matrix Too much detail clouds the effect of the diagram ENTITY: Product

The CRUD matrix is valuable for verifying the consistency of the process and data (entity) designs At a glance, one can find the following potential problems:

Entities that are never updated Entities that are never read Processes that delete or update entities without reading them Processes that only read (no Create, Delete, or Update actions)

Our example has multiple problems, which only proves that our process design is incomplete (that is, we are probably missing some key processes for the application system) At the conclusion of the logical design phase of a project, the CRUD matrix is an excellent vehicle for a final review of the work completed The next step in the database life cycle is to complete the physical database design, which is discussed in 8

Try This 7-1

In this Try This exercise, you will draw an ERD that demonstrates most of the concepts presented thus far, including entities (tables), relationships, recursive relationships, and super types and subtypes You may draw this as either a logical or physical model However, my solution is in the form of a physical model, and therefore the instructions will use physical model terms (such as table and column)

1 Draw a table for PERSON with columns PERSON_ID (primary key), FIRST_NAME,

LAST_NAME, BIRTH_DATE, and GENDER Leave room for two more columns, which you will be adding in the next step

for the person s mother Remember that recursive relationships have the same table as both the parent and the child In this case, the relationships should be optional in both directions because you won t have every person s parents in the database and not all persons have children The PERSON table will need two foreign keys to support the recursive relationships: one for the father s person ID and another for the mother s person ID

3 Draw a dependent table called MARRIAGE with columns PERSON_ID_1, PERSON_

ID_2, MARRIAGE_DATE, and END_DATE The primary key must be composed of the first three columns to be unique under all circumstances PERSON_ID_1 and PERSON_ID_2 will be the foreign keys for the two people who are married