idef3_kbsi_report (1013870), страница 14
Текст из файла (страница 14)
The first number is the last number in the referencenumber of B’s parent UOB. The second number is the number assigned to the particulardecomposition of the parent box in which B occurs. (Numbers are generally assigned todecompositions and UOB boxes in order of creation, but this is arbitrary.) Finally, thethird number in the reference is simply B’s UOB box number.
The reference numberingscheme thus displays a UOB box’s UOB box number, the decomposition to which itbelongs, and its parent UOB. The assignment of reference numbers is illustrated inFigure 3-31.1534DecompositionNumber 1 of UOB 3(i.e., decomposition 3.1)3.1.433.1.453.1.47DecompositionNumber 1 of UOB 4343.1.7643.1.7943.1.77Figure 3-31Unit of Behavior Numbering SchemeIf more than one person is involved in creating the description, constraints areenforced on the assignment of numbers to ensure that every UOB box is assigned uniquebox and reference numbers.
The procedure suggested for UOB box number assignmentis as follows. Each person is assigned a set of numbers (e.g., Joe gets 1-99, Jane gets100-199, etc.), and can assign UOB box numbers only from his or her allocated set. Oncethe initial set of numbers is used, additional numbers can be assigned as necessary. Byapplying this number assignment procedure, the lead analyst in the development effort45can be assured that each UOB in the final combined description will contain unique boxand reference numbers.4Partial DescriptionsUOB boxes are joined together by links.
Because of the description capture focus ofIDEF3, it is possible to conceive of UOBs without links to other parts of an IDEF3schematic, as the example in Figure 3-32 illustrates. These typically result early in thefact collection activity as references are made by the domain expert to the existence ofevents or activities without assertions being made about how they fit together.DefineSystemRequirements1DetermineSystemDesign2CodeSystemTest35InstallSystem6Proj.
ManagerComparesProgress toSchedule4Figure 3-32Disconnected UOB ExampleIn Figure 3-32, UOB 4 has no links to the rest of the schematic. This could eitherrepresent the actual situation or reflect the uncertainty of the domain expert’s knowledgeabout the presence or absence of links.
In this illustration, the schematic represents theactual situation. The concept that makes the Project Manager Compares Progress toSchedule UOB part of this schematic is the object Project Schedule shared by other UOBsin the schematic. The IDEF3 method, by allowing the creation of such stand-aloneUOBs, facilitates the creation of partial descriptions.
It allows users to represent the stateof the world as they know it, with no enforced constraints on completeness. In fact, acommon error that can be committed in the course of developing descriptions is toattempt to “drive to completion” inherently incomplete sets of descriptions.4The UOB reference numbering scheme is provided to facilitate coordinated team effort and easynavigation across multiple views and varying levels of granularity in the description. The UOBreference numbering scheme is particularly important in a paper-based environment or one where thesoftware tools being used provide limited integration support.
For convenience in presentation,however, users may choose not to display UOB reference numbers or to number UOBs from left toright and from top to bottom as they appear in the schematic.46ReferentsReferents enhance understanding, provide additional meaning, and simplify theconstruction (i.e., minimize clutter) of both process schematics and object schematics.Referents may be used in IDEF3 Process and object schematics to do the following.1.Refer to a previously defined UOB without duplication of its definition toindicate that another instance of a previously defined UOB occurs at aspecific point in the process (without loopback).2.Transfer control or indicate a loopback in the processing.3.Form references or links between the process schematics and objectschematics.The graphical symbols for the two basic styles of referents are displayed in Figure 333.
Each type of referent may be used either in a process schematic or an objectschematic, although process schematics tend to make more extensive use of the Call-andContinue style referent. Using a Call-and-Continue referent indicates that the referencedelement needs only to initiate before the focus IDEF3 element (that is, the IDEF3 elementthat makes the reference) can progress to completion. The use of a Call-and-Waitreferent indicates that the referenced element needs to both initiate and complete beforethe focus IDEF3 element can progress to completion.Call and Continue ReferentCall and Wait ReferentReferent Type/LabelReferent Type/LabelLocatorLocatorFigure 3-33Referent Symbol SyntaxThe type of thing signified by a referent—known, therefore, as the referent type—isindicated by prefixing one of the terms “UOB,” “SCENARIO,” “TS,” or “GO-TO,”followed by a slash, to a label for the thing signified (e.g., UOB/Perform Mission AreaAnalysis).
Referents also include a field to note a locator for the thing signified. Asummary of the referent types and referent labeling guidelines is provided in Figure 3-34.47Referent TypeReferenced ElementLabelLocatorUOBUOB LabelUOB#SCENARIOScenario LabelScenario #TSGO-TO (used only inprocess schematics)Transition SchematicLabelUOB LabelScenario LabelJunction Type (i.e., &, O,or XOR)Transition Schematic #UOB#/Scenario # orDecomposition # in which theID occursScenario #Junction #/Scenario # orDecomposition # in which theID occursFigure 3-34Referent Symbol StructureThe following paragraphs summarize the semantics of the possible uses for referentsin both the process and object schematics. To acquire a full understanding of thesemantics associated with referents, readers need to become more familiar with objectschematics. Readers may find it useful to read the following subsections which describeCall-and-Wait and Call-and-Continue referents, paying particular attention to their use inprocess schematics.
Readers should then proceed to the discussion of object schematics.Once a basic understanding of object schematics is acquired, the reader may return to theCall-and-Continue and Call-and-Wait referents subsections to obtain a full understanding.Call-and-Continue ReferentsIf the call-and-continue referent type is “UOB,” “SCENARIO,” or “GO-TO,” it mayhave no outgoing precedence link. To do otherwise would be inconsistent with thesemantics of a precedence link.
To understand why, one need only consider thesemantics of call-and-continue referents and precedence arrows. A call-and-continuereferent indicates that when an instance of the referenced UOB begins, for example, theprocess may continue. The precedence constraint, however, specifies that the processmay continue only after an instance of the UOB both starts and completes. Hence, thetwo differing semantics cannot be applied simultaneously without violating the grammar.48If the referent type is “UOB,” the label must be a UOB label; this means that anotherinstance of a previously defined UOB occurs at a specific point in the process (withoutloopback). If this referent type is attached to a transition arc in an object schematic, anactivation of the referenced UOB must be initiated before the state transition is allowed(see referent discussion in the object schematics subsection).
If this referent type isattached to an object state in an object schematic, it indicates that the referenced UOBsustains the object in the state. Similar semantics apply for Scenario-type referentsattached to object states. See the subsection entitled, “Referents Attached to ObjectStates,” for more detail.If the referent type is “SCENARIO,” the label must be a Scenario label. If thisreferent type is used in a process schematic, it indicates that the next happening in theprocess flow is an occurrence of an activation of the referenced Scenario. That is, alldecompositions of the named Scenario would be activated.
If this referent type isattached to a transition arc in an object schematic, an activation of the referencedScenario must start before the state transition is allowed (see referent discussion in objectschematics subsection).If the referent type is “TS,” the label must be a Transition Schematic label.
If thisreferent type is used in a process schematic, it must be attached to a UOB with a simpleconnecting link (i.e., no precedence links). This use indicates that the referencedTransition Schematic must initiate sometime during an activation of the UOB. If thisreferent type is used in an object schematic, it must be attached to some point on atransition arc between states (i.e., it may not be attached to an object or object state).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
