idef3_kbsi_report (1013870), страница 9
Текст из файла (страница 9)
For example, the first junction in the above figureindicates that only one path will be taken in an activation of the described process.The IDEF3 method allows users to capture descriptions at varying levels ofabstraction by providing a mechanism called a decomposition. A decomposition providesa means of organizing a more detailed description of a UOB. The decompositionschematic follows the same syntactic rules as those for a scenario and is created using thesame IDEF3 elements. A UOB can have any number of different decompositions, all onthe same level. The use of more than one decomposition for the same UOB is for thepurpose of representing different points of view or providing greater details of theprocessing relating to the UOB.
The UOB Request Material in Figure 2-1 has beendecomposed into UOBs 7 through 10. The numbers in the lower-left corner of UOBboxes 7 through 10 include a reference to UOB 1 (the first digit) and the decomposition(decomposition 1 of UOB 1). This is illustrative of the IDEF3 numbering scheme whichallows explicit traceability between levels of detail in the description.
The processdescription depicted in Figure 2-1 shows the material ordering process from a particularpoint of view—that of the business owner. It is possible to conceive of other views forthis process—for example, that of the Account Manager. Each view to be describedwould be presented in a separate decomposition with a unique label and number.The Process Schematic in Figure 2-1 represents a process-centered view of thematerial ordering process. This view focuses on assertions about the processes that occurand their ordering. Sometimes it is convenient to organize the description of a situationfrom an object-centered view (i.e., where a participating object or set of objects is thefocus of attention). The next section describes how IDEF3 facilitates process descriptioncapture using an object-centered view.15Object-Centered Views: The Object SchematicsIDEF3 Object Schematics capture, manage, and display object-centered descriptionsof a process—that is, information about how objects of various kinds are transformed intoother kinds of things through a process, how objects of a given kind change states througha process, or context-setting information about important relations among objects in aprocess.In IDEF3, an object is any physical or conceptual thing that is recognized and referredto by participants in the domain as a part of their descriptions of what happens in theirdomain.
Correctly identifying, characterizing, and naming objects is a necessary step inthe creation of object-centered IDEF3 Process Descriptions. Object names are oftennouns or noun phrases that may or may not be coupled with a state descriptor. Below aresome typical examples.1.Water: Boiling2.Purchase Order: Approved3.ChassisObject Schematics may be developed in the context of a single scenario, thuscharacterizing the state transitions traversed by participating objects in an occurrence ofthe scenario.. These schematics, called Transition Schematics, allow users to specify therules that govern the transitions between object states in a scenario occurrence.Alternatively, Object Schematics may evolve in a more opportunistic fashion, capturingdescriptions of objects, object states, and their transitions across multiple scenarios.Object Schematics developed in this fashion make no attempt to define the structure forobject state change behavior in a scenario occurrence.
This cross-scenario ObjectSchematic development approach is often useful when exploring what object-centeredprocess information merits a more detailed focus or when attempting to discover contextsetting information about the objects encountered in a description. Object Schematicsmay be distinguished from the more specialized Transition Schematics (and EnhancedTransition Schematics) by the absence of a context-setting scenario name Generallyspeaking, IDEF3 Object Schematics are developed to provide an object-centereddescription of a particular process or scenario. Transition Schematics therefore tend todominate the attention of those developing IDEF3 Object Schematics.The schematic in Figure 2-2 represents an Object Schematic for the Order Materialscenario derived from the business owner’s description. This example happens toillustrate a Transition Schematic since it characterizes the nature and structure of objectstate transitions for occurrences of the Order Material scenario.16Figure 2-2Example of a Transition Schematic17A key document in this process is the Purchase Request form.
This form iseventually transformed into a Purchase Order (PO) via the Order Material process. AUOB/SubmitSignedPurchaseRequestUOB/PreparePurchaseVoucherUOB/ObtainAccountManagerApproval7810PR:ApprovedPR:UnpreparedPR:PreparedUOB/OrderRequestedMaterialXXPR:Approved,RequiringAuthoriztionPR:AuthorizedUOB/ObtainAuthorizationSignature96PR:SubmittedPO:Issuedcircle containing the name of an object represents an object of a certain kind (e.g.,Purchase Request, Account Manager, Project). These labeled circles are known as kindsymbols. A certain kind of object being in a certain state is represented by a circle with alabel that captures both the kind itself and a corresponding state, thereby representing thetype (or class) of objects that are in that state (within a given process). For example, anapproved Purchase Request (PR) would be indicated by the label PR:approved, anauthorized PR by PR:authorized, and so on.
One of the first steps to develop an ObjectSchematic is to identify the possible states in which the object can exist. Though a realworld object often evolves through a continuum of states, an Object Schematic focuses onthose distinguished states of particular interest to the domain expert. The transition arcs(arrows with triangular, filled-in heads) connecting the circles symbolize a statetransition, the activity of changing from one state to another.
The conditions thatestablish when an object is in a given state, how it exists a state, how it can transitionbetween states, and how it can enter a new state are recorded on a special form. Thebanded boxes linked to the arrows (called referents) are aids to describe the relationshipsbetween objects states and UOBs, scenarios, or other Transition Schematics thatparticipate in a scenario occurrence.
For example, during the transition of the object PRfrom its state of having been prepared for review by an Account Manager (i.e.,PR:prepared) to an approved state (i.e., PR:approved or PR:approved requiringauthorization), the process represented by the UOB Obtain Account Manager approvalmust initiate and complete. The transition junctions containing an “X” (for exclusive or)indicate the choice of exactly one path among several possible paths in an occurrence.Thus, Figure 2-2 indicates that Purchase Requests transition from an unprepared to aprepared state and from a prepared state to either an approved state or an approvedrequiring authorization state.
If the Purchase Request requires authorization, it willtransition to an authorized state before transitioning to a submitted state. Otherwise, itwill transition directly to the submitted state. After the Purchase Request reaches thesubmitted state, the object will transition to an issued Purchase Order. UOBs, scenarios,and other Transition Schematics that participate in a transition between states areindicated by attaching appropriately labeled referents to the Object Schematic. Therelative positioning of referents on the Transition Schematic indicates the order in whichthey occur. For example, the position of the UOB Prepare Purchase Request in Figure 22 indicates that it initiates and completes before all other UOBs referenced by theschematic in an occurrence of the scenario.It is interesting to note that among the possible state transitions represented, nonereflect a failed request.
This is simply because the original dialog contained noinformation about such situations. This is a key point in the use of IDEF3. IDEF3 isintended as a mechanism for structuring the assertions made by the domain expert. Itdoes not force the completion of partial information with modeling assumptions.18The schematic in Figure 2-2 may be embellished to include additional context-settinginformation. An example of this is provided in Figure 2-3. In this figure, the TransitionSchematic has been supplemented with objects and appropriate relation links that provideadditional information.
For example, the three-place relation that stands between thekinds PR: Prepared, Direct Project, and Authorization Signature indicates thatPurchase Requests involving Direct Projects require an authorization signature.Furthermore, an Authorization Signature is included on each Purchase Request that hasbeen authorized. The schematic also indicates that a Requester may not be the sameindividual who approves or authorizes a Purchase Request.19not identical withRequestorPersonapprovingrequestUOB/Submit signedPurchaseRequestUOB/Order requestedmaterial106not identical withUOB/PreparePurchaseRequestUOB/Obtain AccountManagerapproval20Figure 2-3Example of an Enhanced Transition Schematic7 7Personauthorizingrequest8PR:PR:ApprovedApprovedsubmitsPR:PreparedPR:Unpreparedisauthorizedto sign1mustincludeDesignatedbackupXXPR:ApprovedrequiringauthorizationPR:AuthorizedXAccountnumberhasUOB/ObtainauthorizationsignatureAccountManager9hasis responsible forincluded onProjectsubkind ofinvolving-requiressubkind of2IndirectProject6DirectProject3AuthorizationsignaturePR:SubmittedPO:IssuedSection 5 contains a more detailed exposition of the example provided here.
Inparticular, the step-by-step process used to develop both the Process and ObjectSchematics is provided. For a more detailed description of the basic IDEF3 schematicelements and their semantics, readers are invited to continue with Section 3.IDEF3 PROCESS DESCRIPTION LANGUAGEThe following sections describe the basic elements of the IDEF3 process descriptionlanguage and how those elements can be combined todynamic form semantically richdescriptions of dynamic systems. An IDEF3 process description organizes the network ofrelations between situations in a specified scenario. IDEF3 descriptions are developedfrom two different perspectives: process-centered and object-centered. Because theseapproaches are not mutually exclusive, IDEF3 allows cross-referencing between them torepresent complex process descriptions.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
