idef3_kbsi_report (1013870), страница 27
Текст из файла (страница 27)
and a unique integer,separated by a period. For example, given a precedence link PL1 that separatesinto three alternative paths following a junction, the path link numbers would bePL1.1, PL1.2, and PL1.3.3.Source: Name of the source IDEF3 element (i.e., UOB or referent) of the linkin the specified path.1184.Destination: Name of the destination IDEF3 element (i.e., UOB or referent) ofthe link in the specified path.4.Objects: All significant objects (types or instances) that participate in therelation that the link represents. Typically, these objects are constituents in thesource or destination of the relation indicated by the link.5.Facts: Noteworthy, nonconstraining facts involving the objects that participatein the relationship represented by the link.6.Constraints: Noteworthy constraints that hold between the source anddestination UOBs or between some of their constituent objects.
This fieldcontains, in particular, the constraints indicated by the general constrainedprecedence link.7.Description: The descriptive glossary associated with the link. Any descriptiveinformation that does not fit logically into any of the other fields in thedocument is placed here.As appropriate, objects, facts, and constraints that are uniquely associated with aparticular link path will be so identified.Special constraints indicated by dashed links are recorded in a dashed linkspecification document (see Figure 4-9).119DATE:USED AT: ANALYST:PROJECT:NOTES:LinkNo.1 2 3 4 5 6 7 8 9 10REV:WORKINGDRAFTRECOMMENDEDRELEASEDREVIEWER:DATE:Source:Destination:DLObjects:Facts:Constraints:Description:CONTEXT-SETTINGREFERENCE:ITEM DESCRIBED:FORM TYPE:Dashed LinkElaborationFigure 4-9Dashed Link Elaboration FormThe following describes the main content of a dashed link elaboration document.1.Link No.: A link number, prefaced by the letters “DL” (for dashed link), thatuniquely identifies the dashed link within the description.2.Source: Name of the source IDEF3 element (e.g., UOB, referent) of therelation indicated by a link.3.Destination: Name of the destination IDEF3 element (e.g., UOB, referent) ofthe relation indicated by the link.4.Objects: All significant objects (types or instances) that participate in therelation that the dashed link represents.
Typically, these objects are constituentsin the source or destination of the relation indicated by the dashed link.5.Facts: Noteworthy, nonconstraining facts involving the objects that participatein the relationship represented by the dashed link.1206.Constraints: Noteworthy constraints that hold between the source anddestination elements or between some of their constituent objects.7.Description: The glossary associated with the dashed link. Any descriptiveinformation that does not logically fit into the other fields in the document maybe placed here.Develop Decompositions for Selected Units of BehaviorA decomposition of a UOB is a collection of other UOBs that provides additionaldetails of a process represented by the parent UOB from a particular perspective.
UOBsat the scenario level will usually have decompositions. The UOBs in thesedecompositions may also be decomposed. Different decompositions normally result fromdifferent domain expert views of what happens during an activity. They can also resultfrom abstracting some participating object’s view of the process. For example, adecomposition view might be created to show the processing steps required of theinformation system in order to support an organizational activity.
Finally,decompositions can be produced by the analyst for selected UOBs to simplify aschematic. Decompositions are schematics providing a more detailed view or differentperspectives of a process with a clearly defined viewpoint. Decompositions are oftendeveloped to capture alternative views of a process or to simplify a process descriptionschematic.Like IDEF3 description development, the decomposition development process is arefinement process.
Decomposition development follows the same procedure as that ofthe primary description development. This refinement cycle consists of activities to (1)analyze the activity, (2) collect additional data, (3) describe situations in terms of relatedUOBs, (4) review, and (5) if necessary, return to a previous step in the procedure.Formulate Object SchematicsObject Schematics are provided in IDEF3 to complement Process Schematics.
ObjectSchematics enable an object-centered view of the process being described by facilitatingdetailed characterization of objects, object states, state transitions, and inter-objectrelations. Object Schematic development may occur before, during, or after thedevelopment of Process Schematics. This section provides guidelines for developingObject Schematics.The steps involved in constructing an Object Schematic are as follows.1.Select objects of interest.2.Identify object states.1213.Characterize possible transitions between states and lay out the basic statetransition schematic.4.Add junctions, as required, to reflect alternative state transition paths and objectcomposition logic.5.Attach referents for participating UOBs, scenarios, and Object Schematics toappropriate points on the schematic.6.Develop elaborations as needed.7.Develop object state decompositions for selected object states.8.Identify and mark transitions yielding the same object.9.Add other objects and relations to the schematic as needed to provide usefulcontext-setting information.Select Objects of InterestThe first task in constructing the Object Schematic portion of a description is decidingwhich object(s) to describe.
Basically, the analyst must identify which objects play animportant role in the domain expert’s knowledge about the system. The list of objectsinvolved in a process may be extensive. In comparison, the list of objects of specialinterest is likely to be small. These are generally objects that are modified by the processbeing described. Since Object Schematic creation normally follows the development ofone or more Process Schematics, a primary source for the objects of interest will be (1)UOB elaborations, (2) scenario descriptions, (3) models of the information required bythe scenario (e.g., other IDEF models), and (4) original interview data.
Regardless of thesource of the objects, they have two features in common: (1) they undergo noticeablechanges in the process and (2) they exist in several states at various points in the process.Because an object theoretically can be any physical or conceptual thing, there is noscientific method to decide which objects are in a domain. However, as a generalheuristic, in IDEF3 we are interested in objects that play an important role in theoperation of the system. Such objects will normally be named; that is, the analyst willfind a word or phrase that appears frequently in the interview information. Whatever thisword or phrase refers to can be considered a possible object for consideration.
Thesecond issue to consider is whether the objects of interest have states of interest. Again,some of the heuristics are: (1) each object state should display characteristics commonlyrecognized in the domain; (2) the object should be recognized to exist in a state for aperiod of time; and (3) there are recognized constraints or process that enable, cause, orinhibit the state changes. For each selected object, at least one Object Schematic isdeveloped.122Layout Initial Object SchematicFor each Object Schematic, the creation of an Object Schematic Summary form isnecessary (See Figure 4-10).
A textual description, or glossary of the Object Schematic ispart of this form. This text should contain a statement of the purpose for the schematicand will generally contain other information about the Object Schematic that does notreadily fit into the other fields (e.g., ontology information that would later be included inan IDEF5 model). In addition to the textual description, the analyst records the objectstates and the other IDEF3 elements (UOBs, Scenarios, and Transition Schematics) thatare referenced in the schematic.
Initial completion of this form is part of the analysisactivity associated with constructing the Object Schematic. This initial work aids theanalyst in developing an Object Schematic from the raw data.USED AT: ANALYST: I.M. ModelerX WORKINGDRAFTRECOMMENDEDRELEASEDDATE: 08 Feb 95PROJECT: Example IDEF3 DescriptionNOTES:1 2 3 4 5 6 7 8 9 10REV:REVIEWER:Object Schematic No.:Object Schematic Type:Object Schematic Name:Object Schematic Label:DATE:Object State Set:Referenced UOBs:Referenced Scenarios:Referenced Transition Schematics:Objects:Description:CONTEXT-SETTINGREFERENCE:ITEM DESCRIBED:FORM TYPE:Object SchematicSummaryFigure 4-10Object Schematic Summary FormThe following list contains a description of the fields contained in a TransitionSchematic description form.1.Object Schematic No.: A unique identification number for the ObjectSchematic, prefaced by the letters “TS” for transition schematics and “OBS” forObject Schematics.1232.Object Schematic Type: The Object Schematic type may be described as aTransition Schematic, Enhanced Transition Schematic, or an Object Schematic.Transition Schematics (i.e., Transition and Enhanced Transition Schematics) arespecial types of Object Schematics whose context is established by a singlescenario.3.Object Schematic Name: The name of the Object Schematic.4.Object Schematic Label: The Object Schematic Name, some part of theName, or an abbreviation used for convenience when displayed in an IDEF3graphical element (e.g., when displayed in a referent).5.Object State Set: The set of object states that make up the state transitionrepresented by the Object Schematic, if the schematic is a type of TransitionSchematic.
If the schematic is a general Object Schematic, this field lists theobject states included in the Object Schematic.6.Referenced UOBs: The set of UOBs referenced by the Object Schematic.7.Referenced Scenarios: The set of scenarios referenced by the ObjectSchematic.8.Referenced Transition Schematics: The set of Transition Schematicsreferenced by the Object Schematic.9.Objects: The set of objects included in the Object Schematic for contextsetting purposes.10.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
