idef3_kbsi_report (1013870), страница 34
Текст из файла (страница 34)
No other accounts require an authorization signature to proceed withissuing the Purchase Order.CONTEXT-SETTINGREFERENCE:Scenario 1FORM TYPEJunction ElaborationITEM DESCRIBED:XOR Junctions J1 and J3Figure 5-11Example Junction ElaborationsAnother addition to this process description is an elaboration for one of the links (SeeFigure 5-10). This link elaboration may not have been entirely necessary in a situationthis simple; however, it illustrates how a link elaboration can be associated with aparticular link.
The link is assigned a number that allows a reader to associate a particularelaboration with the correct link. This link elaboration will contain relevant informationto the link between participating UOBs and/or referents.164USED AT: ANALYST: I.M. ModelerX WORKINGREVIEWER:DRAFTRECOMMENDEDRELEASEDDATE: 08 Feb 95PROJECT: Process Description CaptureLinkNo.PL6NOTES:1 2 3 4 5 6 7 8 9 10Path No.Source:PL6.1Obtain Account Manager’s approval (UOB8)“No op”PL6.2Obtain Account Manager’s approval (UOB8)Obtain authorization signature (UOB9)Objects:REV:DATE:Destination:Purchase RequestFacts:Constraints: (PL6.2) Those authorizing Purchasing Requests must first ensure that the appropriate Account Manageror designated backup has approved and signed the Purchase Request form.Description:CONTEXT-SETTINGREFERENCE:Decomp 1.1FORM TYPEPrecedence LinkElaborationITEM DESCRIBED:Precedence Link 6Figure 5-12Precedence Link Elaboration DocumentFormulate Object SchematicTo provide a detailed characterization of the objects that participate in a process, it isuseful to construct Object Schematics.
These are typically developed only for theimportant objects of the process description. Object Schematics provide a different viewof the process being described, i.e., an object-centered view. Object Schematics are mostoften developed after the Process Schematic; however, some users find it easier to beginwith the Object Schematic.Select Objects of InterestThe first step in formulating an Object Schematic is to select the object or objects ofinterest.
Suppose that in the Purchase Order process the purchase request is the importantobject. It may be useful to conceptualize the purchase request object as transitioningthrough several states in the process being described. This would indicate an interest inexamining the process from an object-centered view beginning with the initialdevelopment of a purchase request through the eventual issuance of a purchase order.165The following example illustrates the process of developing an Object Schematic withthis focus.Identify Object StatesHaving determined the main object of focus, the analyst begins to develop the ObjectSchematic by identifying candidate object states.
The key object of interest in this case isthe Purchase Request (PR), which requires close examination of perceived changes in itsstate through the process. The terminating state, as indicated by the client, is the point atwhich the PR finally becomes a Purchase Order (PO). Although there are likely manypossible states of a PO, the client’s needs dictate no requirement to explore those states.The first task for the analyst involves identifying candidate object states. A number ofsources directly identify these states or provide clues to indicate the possibility thatdomain experts distinguish certain states.
These sources include raw descriptionsprovided by the domain expert, candidate UOB names, the objects themselves, and UOBelaboration forms. Identifying the possible state changes that an object may undergo in aprocess often requires that the analyst work with domain experts to either extract orbestow candidate names for object states.By reviewing the data provided in the interviews, the analyst produces a list ofcandidate object states like the following list.PR: UnpreparedPR: PreparedPR: ApprovedPR: Approved requiring authorizationPR: AuthorizedPR: SubmittedPO: IssuedThis list is likely to undergo change through the identification of logically identicalstates, through name refinement, and through the identification of previously unnamed orunrecognized states.166Layout Initial Object SchematicThe process of organizing the identified object states into a Transition Schematicoccurs as follows:Step 1.
The first step is to identify the initial, or leftmost, object state inthe 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 theobject can transition. In this example, the PR transitions from anunprepared state to a prepared state.PR:UnpreparedPR:PreparedFigure 5-13Initial Transition SchematicStep 3. The third step is to repeat steps 1 and 2 until all the possible statetransitions are identified.It is generally helpful to identify and document one transition path at a time beforeattempting to develop a schematic illustrating all possible paths.
In this example, the firstpoint where alternative paths are encountered occurs when a PR is approved by theaccount manager. At this point, the PR may require authorization. If no authorization isrequired, the PR may be submitted to Purchasing. This yields the Transition Schematicsillustrated in Figures 5-14 and 5-15.PR:UnpreparedPR:PreparedPR:ApprovedPR:SubmittedPO:IssuedFigure 5-14Transition Schematic for Path where Authorization is Not Required167PR:UnpreparedPR:PreparedPR:ApprovedrequiringauthorizationPR:AuthorizedPR:SubmittedFigure 5-15Transition Schematic for Path where Authorization is RequiredAdd Junctions As RequiredThe fourth step involves combining the two paths into a single schematic byintroducing the appropriate logical junction(s).168PO:Issued169Figure 5-16Combined Transition Schematic Combining Figures 5-14 and 5-15PR:PR:ApprovedApprovedPR:UnpreparedPR:PreparedXXPR:ApprovedrequiringauthorizationPR:AuthorizedPR:SubmittedPO:IssuedAttach ReferentsOnce the possible paths have been identified and integrated to reflect alternative statetransition paths, referents for participating UOBs, scenarios, and other TransitionSchematics will be identified and attached to appropriate points on the schematic.
Thisstep yields Figure 5-17.170UOB/SubmitSignedPurchaseRequest171Figure 5-17Complete Schematic Before First ReviewUOB/PreparePurchaseRequestUOB/ObtainAccountManagerApproval7810PR:ApprovedPR:UnpreparedPR:PreparedUOB/OrderRequestedMaterialXXPR:Approved,RequiringAuthoriztionPR:AuthorizedUOB/ObtainAuthorizationSignature96PR:SubmittedPO:IssuedDevelop ElaborationsOnce the initial Transition Schematic is completed, elaborations must be added tomore 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 thesystem type to influence the information placed in the elaborations.The order in which the elaborations are developed is not necessarily important.
It isoften useful to develop elaborations in parallel with the rest of the Object Schematic. Inparticular, concurrent development of the Transition Schematic and associatedelaborations may lead to the discovery of previously unidentified states. This example,however, illustrates a situation where the initial elaborations are developed after theTransition Schematic is complete.DATE: 08 Feb 95USED AT: ANALYST: I.M. ModelerPROJECT: Process Description CaptureNOTES:ObjectStateNo.1 2 3 4 5 6 7 8 9 10REV:Object State Name:PR: PreparedLabel:PR: PreparedX WORKINGREVIEWER:DRAFTRECOMMENDEDRELEASEDDATE:OS2Transitions From Object State(s):PR: PreparedTransitions To Object State(s):PR: ApprovedPR: Approved requiring authorizationFacts:Constraints:State Conditions: The Purchase Request form must include the item description, the number of itemsneeded, the required receipt date (if applicable), the number of the account that willfund the purchase, a written justification for the stated need, and the requester’s printedname and signature.Exit Conditions:Other:Description:CONTEXT-SETTINGREFERENCE:Scenario 1FORM TYPEObject State ElaborationITEM DESCRIBED:Object State 2 - PR: PreparedFigure 5-18Elaboration for Object State PR: Prepared172USED AT:ANALYST: I.
M. ModelerDATE: 08 Feb 1995X WORKINGNOTES:Obje ctStateNo .1 2 3 4 5 6 7 8 9 10REVIEWER:DATE:DRAFTRECOMMENDEDRELEASEDPROJECT: Process Description CaptureREV:Objec t State Name :PR: Approved requiring authorizationLabel:PR: Approved requiring authorizationOS4Transit ions Fro m Obje ct St at e( s):PR: ApprovedTransit ions To Obje ct St at e (s) :PR: AuthorizedFact s: Not all completed Purchase Requests require authorization signatures.Co nstraint s:State Co nditio ns: Purchase involves use of Direct project funds.Purchase Request form has been signed by the Account Manager or designated backup.Exit Co ndit ions:Othe r:De sc ript io n:CONTEXT-SETTINGREFERENCE:Scenario 1ITEM DESCRIBED:FORM TYPE:Object State 4 - PR: Approved requiring authorizationObject State ElaborationFigure 5-19Elaboration for Object State PR: Approved requiring authorization173USED AT:ANALYST: I.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
