idef3_kbsi_report (1013870), страница 26
Текст из файла (страница 26)
Unlike scenarios, which tend to be more general,UOBs are more specific, with definite time constraints. That is, if one is able to identifystrong causal or time-ordering dependencies, it is probable that a UOB rather than ascenario has been identified. Thus, phrases like, “Such events may require redefinition ofassigned tasks in response to shifts in national security policy,” may yield two candidateUOBs (Redefine assigned tasks and Revise national security policy) that stand in thecausal relation in response to.People also make extensive use of objectification and metonomy to describeprocesses without names. That is, most processes, like most objects, do not have names.Objectification of a process simply means that one takes a process and describes it as anobject. For example, the process Acquire Weapon System may be referred to by amember of Congress as weapon system acquisition, or simply system acquisition.Metonomy is a form of expression that uses the name of an important object orrelationship (e.g., attribute) that is associated with the thing being described as a definitedescriptor for that thing.
For example, processes may be referred to by the name of theprincipal product produced (e.g., mission needs determination, Milestone 1 decision).Recognizing these forms of expression, the analyst can quickly identify candidateUOBs, associate them with the appropriate scenarios, and begin the process ofconstructing the initial Process Schematic.Layout Initial Process SchematicAn initial Process Schematic is developed to illustrate the analyst’s understanding ofthe information collected from the expert. Using the initial schematic, the analyst reviewsthe description with the domain expert to ensure the description is correct. These initialschematics also assist the domain expert in recalling additional experience.
The processof initial data collection is limited by the ability of the domain expert to recall his or herinternalized knowledge.Obtaining a reasonably accurate and complete description from an expert is aniterative process that must be repeated until the analyst’s schematic agrees with thedomain expert’s knowledge. In some situations, it may be possible for the analyst and thedomain expert to develop the descriptions together, rather than developing a draftdescription followed by a review procedure. The joint development approach can reducethe development time and produce descriptions that are more complete the first time.A Process Schematic Summary form (See Figure 4-5) aids the analyst in coordinatingreview activity with domain experts and developing the Process Schematic from the rawdata.
A textual description, or glossary of the Process Schematic, is part of this form.113This text should contain a statement of the purpose for the schematic and may containother information that does not readily fit into the other fields. In addition to the textualdescription, the analyst records the UOBs and the other IDEF3 elements (UOBs,Scenarios, and Transition Schematics) that are referenced in the schematic. Initialcompletion of this form is part of the analysis activity associated with constructing theProcess Schematic.WORKINGDRAFTRECOMMENDEDRELEASEDDATE:USED AT: ANALYST:PROJECT:NOTES:1 2 3 4 5 6 7 8 9 10REV:REVIEWER:DATE:Process Schematic No.:Process Schematic Label:Process Schematic Name:UOB Set:Referenced UOBs:Referenced Scenarios:Referenced Transition Schematics:Objects:Description:CONTEXT-SETTINGREFERENCE:ITEM DESCRIBED:FORM TYPE:Process SchematicSummaryFigure 4-5Process Schematic Summary FormDevelop Elaborations for UOBs, Junctions, and LinksAn IDEF3 Process Schematic graphically describes a process in terms of the UOBsthat occur in it, with each relevant UOB in the process represented by a UOB box.However, a cursory inspection of the UOB boxes in a schematic will not provide acomplete picture of the processes being described.
Elaborations provide detailedcharacterizations of IDEF3 elements in the schematic. Information on the elaborationforms provide the most detailed characterization of the expert’s description. Theschematic is the graphical presentation of a portion of this information. For mostpurposes, natural language statements suffice for IDEF3 element elaborations. However,when the purpose for the schematics requires more structure and precision than natural114English statements in the elaboration, users can use IDEF3’s elaboration language (SeeAppendix A).Elaborations for UOBs, junctions, and precedence links are developed from theinterview data and reviewed by the domain expert whose knowledge the descriptionrepresents. Initially, these elaborations may look like simple glossary entries.
However,as the data analysis progresses, the elaborations become more structured and concise.Typical information found in an elaboration include participating objects and their roles,facts of interest, and constraints. These natural language elaborations will be written upon elaboration forms (See Figures 4-6 through 4-9).A UOB elaboration document includes: (1) the UOB’s name, label, and UOBnumber; (2) listings of the object types and instances, facts, and constraints thatdetermine the nature and structure of the UOB; and (3) a textual description of the UOB(See Figure 4-6).DATE:USED AT: ANALYST:PROJECT:NOTES:UOBNo.1 2 3 4 5 6 7 8 9 10REV:UOB Name:WORKINGDRAFTRECOMMENDEDRELEASEDREVIEWER:DATE:UOB Label:Objects:UOBFacts:Constraints:Description:UOBNo.UOB Name:UOB Label:Objects:UOBFacts:Constraints:Description:CONTEXT-SETTINGREFERENCE:ITEM DESCRIBED:FORM TYPE:UOB ElaborationFigure 4-6UOB Elaboration FormThe following list contains a description of the contents of each field on the UOBelaboration document.1151.UOB No.: This section contains the UOB Number of the associated UOB.
TheUOB number uniquely identifies the UOB box associated with the elaborationdocument.2.UOB Name: This section contains the UOB Name.3.UOB Label: This section contains the UOB Label (i.e., the UOB Name, somepart of the Name, or an abbreviation displayed in a UOB box).4.Objects: This section lists the names of all the objects (types or instances)which participate in the process being described by the UOB. These objects canbe either physical or conceptual. Objects can be created, modified, or destroyedduring the process.
It may be useful to categorize an object as an agent,affected, a participant, or a created or destroyed object.a.Agent – if the objects (or objects of the type in question) play an activecausal role in instances of the UOB.b.Affected – if the object (or instances of the type) is changed duringinstances of the UOB activity.c.Participant – if no causality or transformation is associated with the object(or instances of the type) in instances of the UOB.d.Created or Destroyed – if the object (or instances of the type) are createdor destroyed in instances of the UOB.5.Facts: This field lists facts about instances of the UOB.6.Constraints: This field lists constraints on the UOB, i.e., facts about what musthold in all instances of the UOB.7.Description: This field contains a glossary entry (textual description) for theUOB. Typically, the glossary entry provides a textual recount of theinformation already in the object, fact, and constraint lists.To facilitate capturing the decision logic of a junction, an elaboration document canbe attached to a given junction in a Process Schematic, as illustrated in Figure 4-7.116DATE:USED AT: ANALYST:PROJECT:NOTES:JunctionNo.1 2 3 4 5 6 7 8 9 10REV:WORKINGDRAFTRECOMMENDEDRELEASEDREVIEWER:DATE:Junction Type:Objects:JFacts:Constraints:Description:JunctionNo.Junction Type:Objects:JFacts:Constraints:Description:CONTEXT-SETTINGREFERENCE:ITEM DESCRIBED:FORM TYPE:JunctionElaborationFigure 4-7Junction Elaboration FormThe core fields in a junction elaboration document are as follows.1.Junction No.: The junction number, prefaced by the letter “J” (for junction),that uniquely identifies the junction within the description.2.Junction Type: Asynchronous AND, asynchronous OR, synchronous AND,synchronous OR, or XOR (exclusive or).3.Objects: All significant objects (types or instances) associated with thejunction.
Typically, these objects are the agents that enforce junctionconstraints.4.Facts: Noteworthy, nonconstraining facts associated with the junction and, inparticular, facts involving the objects associated with the junction.5.Constraints: A specification of the decision logic and any other constraintsassociated with the junction. Ideally, this specification will be given in alogically precise form in the IDEF3 elaboration language. The elaborationlanguage is defined, discussed, and illustrated in Appendix A.1176.Description: An informal description of the decision logic, along with anyother useful annotations or background information.The special constraints indicated by constrained precedence links are recorded in aprecedence link elaboration document (see Figure 4-8).
This document is similar to aUOB elaboration in format and purpose.DATE:USED AT: ANALYST:PROJECT:NOTES:LinkNo.Path No.1 2 3 4 5 6 7 8 9 10REV:WORKINGDRAFTRECOMMENDEDRELEASEDSource:REVIEWER:DATE:Destination:PLObjects:Facts:Constraints:Description:CONTEXT-SETTINGREFERENCE:ITEM DESCRIBED:FORM TYPE:Precedence LinkElaborationFigure 4-8Precedence Link Elaboration FormThe following describes the main content of a precedence link elaboration document.1.Link No.: A link number, prefaced by the letters “PL”, that uniquely identifiesthe precedence link within the description.2.Path No.: A link path number, comprised of the Link No.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
