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

Layout Initial Object Schematic

The process of organizing the identified object states into a Transition Schematic occurs as follows:

Step 1. The first step is to identify the initial, or leftmost, object state in the schematic. In this example, the leftmost object state is labeled PR: Unprepared.

Step 2. The second step is to identify the next state or states to which the object can transition. In this example, the PR transitions from an unprepared state to a prepared state.

Figure 5-13

Initial Transition Schematic

Step 3. The third step is to repeat steps 1 and 2 until all the possible state transitions are identified.

It is generally helpful to identify and document one transition path at a time before attempting to develop a schematic illustrating all possible paths. In this example, the first point where alternative paths are encountered occurs when a PR is approved by the account manager. At this point, the PR may require authorization. If no authorization is required, the PR may be submitted to Purchasing. This yields the Transition Schematics illustrated in Figures 5-14 and 5-15.

Figure 5-14

Transition Schematic for Path where Authorization is Not Required

167

Figure 5-15

Transition Schematic for Path where Authorization is Required

Add Junctions As Required

The fourth step involves combining the two paths into a single schematic by introducing the appropriate logical junction(s).

168

Attach Referents

Once the possible paths have been identified and integrated to reflect alternative state transition paths, referents for participating UOBs, scenarios, and other Transition Schematics will be identified and attached to appropriate points on the schematic. This step yields Figure 5-17.

170

Develop Elaborations

Once the initial Transition Schematic is completed, elaborations must be added to more fully characterize the identified object states as shown in Figures 5-18 through 5-20. In developing the elaborations, the analyst needs to avoid allowing his knowledge of the system type to influence the information placed in the elaborations.

The order in which the elaborations are developed is not necessarily important. It is often useful to develop elaborations in parallel with the rest of the Object Schematic. In particular, concurrent development of the Transition Schematic and associated elaborations may lead to the discovery of previously unidentified states. This example, however, illustrates a situation where the initial elaborations are developed after the Transition Schematic is complete.

Constraints:

State Conditions: The Purchase Request form must include the item description, the number of items needed, the required receipt date (if applicable), the number of the account that will fund the purchase, a written justification for the stated need, and the requester’s printed name and signature.

Figure 5-18

Elaboration for Object State PR: Prepared

172

Figure 5-19

Elaboration for Object State PR: Approved requiring authorization

173

Figure 5-20

Elaboration for Object State PR: Authorized

Review Object Schematic with Domain Experts

As with the Process Schematic, the correctness of the Object Schematic and associated elaborations are confirmed through validation with the domain expert. After reviewing the Transition Schematic, the domain expert observes that the allowable state transitions displayed in the schematic do not include those representative of a failed request. Earlier descriptions provided by the domain expert represented the typical case and had not included situations where approval had been withheld or when authorization had been denied. The domain expert’s response introduced two entirely new object states.

1.PR: Disapproved

2.PR: Unauthorized

The domain expert also identified transitions through which the identity of the object was preserved and transitions where the object was actually transformed into an entirely

174

Additional context-setting information is then added to the Transition Schematic as required. For example, the domain expert’s description indicated that purchase requests involving direct projects require an authorization signature. Additionally, the description included discussion of a constraint that account managers or their designated backups must approve all requests involving their projects. This information is noted directly on the schematic. The resulting Object Schematic is displayed in Figure 5-22.

176