Моделирование бизнес-процессов / Моделирование бизнес-процессов / I D E F / IDEF1MR-part2

6.5.7 Phase Three Formalization

Formalization of the Phase Three entity class sets can be a fairly extensive process. This is because there tends to be a number of new entity classes identified in Phase Three and there are several indices and cross-references to be completed, in addition. Basically, formalization of the Phase Three entity class sets involves the following steps:

1.Finalization of new entity class definitions and updating of the entity class pool (from Phase One).

2.Finalization of all attribute class diagrams, including the updating of the Relation Matrix, relation class definitions, and node cross-reference pages (from Phase Two).

3.Finalization of the attribute class definitions.

4.The development of inherited attribute class cross-reference pages.

5.The development of the attribute class migration indices.

6.Finalization of reference diagrams, including refinement alternatives and function views.

Attribute class diagrams are similar to entity class diagrams in some respects; one is that they reflect only those entity classes with which the subject entity class shares some direct relationship.

The characteristics of the attribute class diagram are:

1.Each attribute class diagram deals with only one subject entity class.

2.Each attribute class diagram reflects, in addition to the subject entity class, all entity classes related directly to the subject entity class.

3.“Independent” entity classes are at the top of the page and dependent entity classes are at the bottom of the page.

4.Only “specific” relation class syntax is used.

5.Each subject entity class box (one per attribute class diagram) reflects the Key Class identification of the entity class, with all Key Class members underscored, multiple attribute classes separated by commas and alternate Key Classes parenthetically enclosed.

6.Each subject entity class box (one per attribute class diagram) reflects all attribute classes which are inherited by the entity class, those which are not members of its Key Class being recorded below, and indented to the right of, the key classes.

81

This format is illustrated in Figure 6-54. The key class(es) is always underscored at the top of the entity class box (and left-justified). Any inherited “non-key” attribute classes are listed below the “key” classes and are indented noticeably from the left margin of the entity class(es) box. Non-key attribute classes are never underscored.

An example of the basic form used for attribute class diagrams is shown in Figure 6-55. Note that the subject entity class box is noticeably enlarged as compared to the subject entity class box used on entity class diagrams. This is to facilitate the additional information which must be enclosed in the entity class box on attribute class diagrams.

82

Figure 6-54. Attribute Class Diagram

84

Figure 6-55. Attribute Class Diagram Form

85

Figure 6-56. Attribute Class Migration Index

Figure 6-57. Attribute Class Cross-Reference

the inherited attribute class cross-reference. Both of these documents are constructed based upon the entity class/ attribute class matrix.

The attribute class migration index reflects, from the “owner” entity class perspective, all of the entity classes wherein the various members of its Key Class (its “key” attribute classes) are used within the model. A sample migration index is reflected in Figure 6-56. To determine its content, the modeler first records an attribute class which is “owned” by an entity class and is a member of its Key Class. Then the modeler records the required information about each of the other entity classes with which the attribute class is shared, locating these by searching the vertical column of the matrix for the appropriate indicator. This process is repeated for all members of the “owner” Key Class.

The inherited attribute class cross-reference is from the perspective of the entity class which inherits in attribute class. It reflects how the attribute class arrived at the subject entity class. A sample of an inherited attribute class cross-reference is shown in Figure 6-57. To determine its content, the modeler first records all attribute classes which are inherited by the entity class and then, using the entity class/attribute class matrix, the “owner” of each one is identified and recorded. Using the attribute class diagram, the modeler records the information about the entity class and relation class through which the attribute class was directly inherited.

6.5.8 Phase Three Kits

Figure 6-58 illustrates the general structure of a typical Phase Three kit. Note that the structure of the review kit has become progressively more complex since Phase One.

The basic structure of the Phase Three kit, though more complex than Phase Two, is similar in several respects. For example, the cover sheet, kit overview, node cross-reference and reference only entity class definitions are handled in the same way. The primary difference is the injection of the function view (which is optional) and the additional material within the context of each entity class set. In total, the typical Phase Three kit will run in the vicinity of 40 to 44 pages. This allows some six to ten pages available to the modeler for the insertion of general text or reference diagrams pertaining to subjects other than the entity class sets within a kit.

87

In Phase Three, there are two types of kit overviews. If the kit is around a function view, then the same guidelines as used in Phase Two apply to structuring of the kit overview. If a function view is to be used, then the kit overview must be a subset of the function view employed.

Phase Three kits, like all other IDEF modeling kits, are prefaced with a kit cover sheet. A sample Phase Three kit cover sheet is shown in Figure 6-59.

When a Phase Three kit is organized around a function view, the subject kit overview diagram, is simply a subset of the function view diagram representing or reflecting those entity classes which are subjects of the kit. The function view diagram is included to provide the context within which the information contained in each entity class set is to be validated. The focal point of the review is intended to be validation of the relation classes reflected in the context of the function view and validation of all attribute class information within each entity class set. The secondary issue is the validation of all other relation classes shared by each subject entity class in the kit. This is because the remaining relation classes should be topics of other function views and submitted for review and validation in other kits.

A sample kit overview, representing a subset of a function view around which the kit was organized, is shown in Figure 6-60. Figure 6-61 is the function view it is based on. There has been an attempt to use the same lines and spacing on the kit overview as used in the function view; this is to achieve a degree of highlighting effect and to focus attention on the subject of the kit within the context of the function view used.

88

Figure 6-59. Phase Three Kit Cover Sheet