idef3_kbsi_report (1013870), страница 10
Текст из файла (страница 10)
Sections 3.1 through 3.5 contain descriptions ofthe syntactic elements of the IDEF3 process description language. Section 3.6 describeshow to combine those elements to form process descriptions. Section 3.7 containsdescriptions of the syntactic elements of the IDEF3 object state transition descriptionlanguage, which enables one to construct object-centered descriptions of processes.
Themechanisms for cross-referencing among statements made in each of these languages areintroduced as part of the individual language specification. Examples are interspersedthroughout these sections to illustrate how the basic syntactic elements are combined tobuild IDEF3 schematics.Basic Elements of IDEF3 Process DescriptionsThe basic syntactic elements of the IDEF3 process description language are shown inFigure 3-1a.
Figure 3-1b displays alternative symbol conventions for first-order relations.21Process Schematic SymbolsObject Schematic SymbolsObject SymbolsUOB SymbolsUOB LabelsNode Ref #Individual SymbolsObject StateLabelIndividualLabelIDEF Ref #LinksLinksWeak Transition LinkSimple Precedence LinkStrong Transition LinkConstraint Precedence LinkRelation LabelRelational LinkRelation LabelJunctionsJunctions&– AND&– Synchronous AND&– ANDO– ORO– Synchronous ORO– ORX– XORX– XORn - Place First-orderRelation Symbol2 - Place Second-orderRelation SymbolConnecting SymbolsReferents and NotesCall and Continue ReferentReferent Type/LabelLocatorCall and Wait ReferentReferent Type/LabelNoteNote IDLocatorFigure 3-1aSymbols Used for IDEF3 Process Description Schematics22Figure 3-1bAlternative Symbol Conventions for First-Order LinksThe informal syntax and semantics of these symbols and the more complex structuresthat can be constructed from them are presented in the following sections.Process SchematicsProcess schematics tend to be the most familiar and broadly used component of theIDEF3 method.
These schematics provide a visualization mechanism for processcentered descriptions of a scenario. The graphical elements that comprise processschematics include Unit of Behavior (UOB) boxes, precedence links, junctions, referents,and notes. Referents and notes are constructs that are common across process and objectschematics. Each of the graphical elements used for developing process schematics ispresented below, together with discussions of how to formulate more complex statementsusing those graphical elements. The discussion begins with the most fundamental ofthese building blocks: the UOB.Units of BehaviorTo be clear about the meaning of UOB (and, hence, the meaning of a UOB box) adistinction must be made between types and instances.
The distinction is familiar in thefield of database design. To design a database schema, a database designer abstractsaway from the particular objects found in a given system and isolates the classes, ortypes, of which those objects are instances. Similarly, the designer abstracts away fromthe particular attributes of those objects to identify attribute types (e.g., color, model,hardness) common to all instances of the same type. This information is then used todesign the relation schema for a particular type of object about which one wishes to keepinformation.
This is the kind of information expressed by a database schema in the EntityRelationship (ER) or IDEF1X modeling language; it describes the types of objects in a23given system, the types of attributes objects of any given type exhibit, and the logicalconstraints that bind them together.By the same token, when one captures “what’s going on” in a given system, onedescribes not what in fact happened in the system at particular time, but rather whathappens in general in the system; one abstracts the general dynamic patterns, the generaltypes of situation, that can occur again and again in the system.
A UOB, then—e.g., aPlanning Activity, or Make or Buy Decision, or Contract Award Event— describes a typeof situation; an instance of a UOB is simply an occurrence of the UOB. Like a databaseschema, a process description describes a system at the type level. A process descriptionrepresents the types of situations (processes, functions, etc.) that can occur in the systemand the logical and temporal constraints that bind them together.As illustrated in Figure 3-1a, a UOB is represented by a special kind of box with aunique label.
Though it is important to bear in mind the distinction between a UOB boxand the UOB it stands for (just as it is important to distinguish a name from the personthe name stands for), in practice, the term “UOB” is often used ambiguously to refer, atsome times, to a given UOB box within a schematic, and at other times, a given UOB inthe scenario represented. Context is usually sufficient to determine which is meant on agiven occasion. Many times, because of the structural similarity between a schematicand the scenario it represents, the ambiguity doesn’t matter.LinksLinks are the glue that connect UOB boxes to form representations of dynamicprocesses.
Links are used primarily to denote significant relationships among UOBs.Links draw attention to important relations between UOBs in a process. Examples of thetypes of relations that can be highlighted by IDEF3 links include temporal, logical,causal, natural, and conventional. However, the vast majority of the time, users are mostinterested in indicating simple temporal precedence. Hence, a special class of links isdevoted to expressing this relation. The precedence link elaboration document, enablesusers to capture additional details about a particular precedence link. Links are drawn tostart or terminate at any point on a UOB box or junction symbol.
There are two basictypes of links used in IDEF3 process schematics: precedence links and dashed links.The symbols that represent each type are shown in Figure 3-2.24Simple Precedence LinkConstrained Precedence LinkRelational LinkFigure 3-2IDEF3 Link TypesSimple Precedence LinksPrecedence links express temporal precedence relations between instances of oneUOB and those of another. They are the most widely used link and are denoted by a solidarrow, perhaps with an additional marker attached to the stem of the arrow, as indicatedin Figure 3-2.
Precedence links connect UOB boxes, as illustrated in Figure 3-3, with asimple precedence link.AB12Figure 3-3Basic Precedence Link SyntaxBox 1, (labeled “A”) at the “back” end of the link is known as the source of the linkand box 2 (labeled “B”) at the “front” end of the link is known as the destination.Considered as an IDEF3 schematic, box 1 is known as the (immediate) predecessor ofbox 2 in the schematic, and box 2 the (immediate) successor of box 1.The meaning of this schematic, as with IDEF3 schematics generally, can beunderstood in terms of possible activations of the schematic.
An activation of aschematic is a collection of instances of some or all of the UOBs in the processrepresented by the schematic whose temporal and logical properties satisfy the conditionsspecified in the schematic. In general, there are many different patterns of activation for agiven schematic. For example, one possible activation pattern for simple two boxschematics like Figure 3-3 is when a single instance a of UOB A is followed by aninstance b of UOB B. More precisely, any pair of instances a and b of A and B,respectively, where b does not start before a completes would be a legitimate activationof Figure 3-3.25Activation PlotsActivation plots are used to represent activations.
The UOB instances in an activationmust occur within a single, finite, interval of time that begins when the first instance inthe activation begins, and ends when the last instance ends. To determine whether agiven collection of UOB instances is an activation of a given description, it is useful toplot the general pattern of their occurrence over such an interval. For descriptiondevelopment purposes, it is often useful to plot the activation pattern for a collection ofobservations over a given interval in order to discover the general pattern.
This can bedone by vertically listing the names of the UOBs and plotting the instances of each UOBaccording to the time and duration of its occurrence. For example, an activation plot ofthe schematic in Figure 3-3 is shown in Figure 3-4 where the line to the right of eachUOB name represents the time interval in which an instance of that UOB occurs. Thatthere is no horizontal overlap in the projections of the two lines indicates that the instanceof B does not begin before the instance of A ends, as required by the semantics of Figure3-3. Hence, the plot does indeed represent an activation of Figure 3-3.Figure 3-4Activation Plot for Figure 3-3Constrained Precedence LinksFigure 3-3, with a simple precedence link, says nothing about whether instances ofeither UOB can occur in the system being described without a corresponding instance ofthe other.
For all Figure 3-3 says, an instance of A could occur without an instance of B;or an instance of B could occur before an instance of A. The semantics of the simpleprecedence link is thus rather permissive. Constrained precedence links add constraintsover and above the activation semantics of simple precedence.
The first of theconstrained precedence links indicates that any instance of the source UOB must befollowed by an instance of the destination UOB. This is what is meant by the“directionality” of the link; the constraint is in force only from “left to right.” So, forexample, as with simple precedence, an activation of the schematic in Figure 3-5aconsists of an instance of Sign timesheet followed by an instance of Obtain timesheetapproval. However, the constrained link in the schematic also expresses that any instanceof Sign timesheet must be followed by an instance of Obtain timesheet approval.
Lack ofsuch an instance indicates an inconsistency with the system as described. That is, such acollection of events would not be classified as an activation of the IDEF3 description.26ObtaintimesheetapprovalSigntimesheet12Figure 3-5aExample of a Schematic Involving a Constrained Precedence LinkGiven the directionality of the link in Figure 3-5a, instances of Obtain timesheetapproval alone are not prohibited by Figure 3-5a; such cases might occur, e.g., when anemployee quits before timesheets for a given pay period are turned in (in which case thesubsequently approved timesheet was never signed).Two remaining constrained precedence links are illustrated in Figure 3-5b.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
