idef3_kbsi_report (1013870), страница 20
Текст из файла (страница 20)
Resources play an enabling role in processes.Classification schematics provide a natural way of categorizing necessary resources, as,for example, in Figure 3-78.81ProgrammerLocalResourceTechnicalSupportSpecialistPersonnelComputerSystemRemoteFacilityTechnicalWriterAdministrator80x86ArchitectureUnixWorkstationQuadraMacintoshCentris486MachinePentiumMachineSunSparcstationIBMRISC 6000OlderModelFigure 3-78Classification of ResourcesHiding Composition and Classification InformationAs illustrated above, use of composition relations can yield quite detailed schematics.Such detail can cause a great deal of clutter.
For instance, in addition to describing thecomponent structure of the kind ballpoint pen, one might also want to talk about many ofthe other relations it and its instances are involved in (for example, that the pens can bemade in Sequim, Washington, that fountain pens generally cost more than ballpoint pens,that ballpoint pen is a subkind of pen, and so on). In many contexts, the componentstructure of the kind might well be irrelevant, and in such cases it would be useful to beable to hide that information. That such information is being hidden is indicated on adiagram by using a double circle (instead of a standard single circle) to represent the kind,82along with a ‘P’ (for part-of) in the top of the circle to distinguish the kind of informationthat is being hidden, as illustrated in Figure 3-79.PBallpointPenMade-inSequimmorethanSubkind-ofCostsSubkind-ofPenPFountainPenFigure 3-79Hiding Composition InformationThis example illustrates the use of first- and second-order relation symbols in thesame schematic.In a similar fashion, it often proves useful to hide classification details in an objectschematic.
In some contexts (e.g., those in which facilities and personnel need to behighlighted), information about computer systems might not need to be explicit. As withthe composition relation, hidden information will be indicated by a double circle,annotated in this case with a ‘C’ (for ‘classification’) at the top of the circle. Thus, onemight alter Figure 3-78 by hiding information about computer system subkinds andadding information about facilities to obtain the schematic illustrated in Figure 3-80.83ProgrammerResourceTechnicalSupportSpecialistCComputerSystemPersonnelTechnicalWriterFacilityAdministratorRemotencestaInoff-otanceofencencInsstas taInMain St.OfficeInofLocalEl PasoOfficeWash.
D.C.OfficeFirst St.OfficeFigure 3-80Classification of Resources with Hidden InformationCreating Enhanced Transition SchematicsThe general schematic constructs can be applied to enhance transition schematics withadditional information useful to the context and purpose of the description developmenteffort. Using the Transition Schematic as the central focus, context-setting information isadded as illustrated in Figure 3-81. Here, the states through which water traverses in aheating process are represented.
The subkind-of relation has been added to the schematic,illustrating that the kind water has subkinds represented by the various object states.84UOB/Melt iceWater:FrozenUOB/Heat to 100ÞCUOB/Heat to 40ÞCWater:ColdWater:WarmWater:HotWaterFigure 3-81Combined Schematic Displaying States and TransitionsAnother simple example of a schematic that integrates general object schematicconstructs with transition schematics is seen in Figure 3-82.85Water:BoilingLiquidSolidSubkind-ofSubkind-ofUOB/Dry PaintPaint:WetPaint:DryOnOnCarFigure 3-82Object Schematic Involving Object Transition ConstructsIn this example, in addition to indicating the transition of a quantity of paint from awet to a dry state via a drying process, relation symbols are used to indicate that the statesPaint:Wet and Paint:Dry are also related to other kinds, as indicated by the labels on thearrows.For a more complex example, consider the schematic shown in Figure 3-83.86Billed-toDirectMaterialAcct 1In sUOB/MakeFrammitzWidget:S1ta nce-ofInMaterialOvenFrammitz:S3&InGrommet:S2IIndirectMaterialBilled-toann stce-ofAcct 2Figure 3-83Another Object Schematic Involving Object Transition ConstructsAt its center, the schematic represents a transition in which a Widget in state S1 and aGrommet in state S2 participate in a Make Frammitz process that yields a Frammitz instate S3.
The use of relation links, however, enables one to express in addition that thewidget and grommet are in an Oven in the process. Also, one is able to express a gooddeal of additional contextual information, such as (1) widgets are Direct material whereasgrommets are Indirect material, (2) both of those are kinds of Material, (3) to whataccounts such materials are billed, and so on. The general object schematic constructsintroduced above enable an analyst to fill in a wide variety of contextual detailssurrounding a given transition.It is important to observe that the above interpretation of the schematic in Figure 3-83is not the only possible interpretation. Most notably, how is one to determine when apiece of information added to a transition schematic holds only relative to the transition inquestion, and when it holds in general.
For instance, the In link between Widget:S1 andOven was interpreted to mean that in (instances of) the indicated transition, the widget inthe transition is in an oven. There is nothing in the schematic proper that prevents onefrom interpreting this to mean that, at all times, a widget is in state S1 when and onlywhen it is in an oven. Similarly, there is nothing about the schematic that determineswhether widgets are always considered direct material, or only that the widgets used ininstances of the transition in question are so considered.
Widgets in other contexts (in thesame state) might be considered indirect material. In IDEF3, the general interpretation87Accountwill be taken as a default. That is, unless otherwise noted, the relations recorded in aschematic will be taken to hold in the widest possible context. If a narrower context isintended, this can be recorded in a note, or more formally in the elaboration language.ElaborationsThe elaborations that can be attached to the schematic elements (e.g., UOB boxes,junctions, links, object symbols) are critical to understanding a process description.Elaborations provide detailed characterizations of the entities referred to by the schematicelement in question.
These detailed characterizations are presented in an elaborationdocument. Elaboration documents typically include: (1) the schematic element’s name,label, and number; (2) listings of the object types and instances, facts, and constraintsthat are associated with the entity the element signifies; and (3) a textual description ofthat entity.The distinction between facts and constraints deserves some clarification.
A fact issimply a statement that has been observed to hold in at least one instance of a process.For instance, in a paint/dry process, an instance of the paint-part UOB might have beenobserved to have a duration of 4.5 minutes; or, the color of a part entering the processmight have been observed to be gray. Descriptive facts like these simply record what hashappened in some instances of the UOB in question.A large store of descriptive facts is useful in the early stages of building an IDEF3description.
These facts generally serve as the raw data from which a more definite andaccurate process description emerges. As knowledge of a process grows, facts are neededto record not only what has happened in some instances of the process, but what musthappen in all instances of the process. These facts are called constraints in IDEF3.Because a fact that must hold also holds as a matter of contingent fact, constraints are thusa special kind of fact. Two broad sorts of constraints can be distinguished: absolute andconditional. An absolute constraint is stated without qualification (e.g., All pieces of mailmust have a zipcode displayed). Conditional constraints are conditional in form: IF acertain state of affairs A holds, THEN a certain other state of affairs B must hold as well.For example, it might be a constraint in a paint/dry process, that IF (in an instance of thepaint-part UOB) the object being painted is of kind K, THEN the duration of the paintpart instance must be exactly 5 minutes.
An object of another kind, by contrast, might bepainted for only 4 minutes.Every identified element in a process description has an elaboration documentassociated with it. The elaboration document may consist of only a reference numberand, optionally, a label. However, by adding more information, the elaboration documentprovides an important key to understanding the elements that constitute complex88processes. A detailed discussion of elaboration documents and their contents is providedin Section 4, Developing IDEF3 Descriptions.Generally speaking, elaboration documents are populated with natural languagestatements. When something more structured and precise than natural languagestatements is required in the elaboration, users can use IDEF3’s elaboration language.The elaboration language will be illustrated with two examples in the following section.See Appendix A for a complete account of the elaboration language and furtherexamples.Some Examples of the Elaboration LanguageThe elaboration language is a logical language based (with some modifications) on asubset of the emerging information-sharing standard known as the KnowledgeInterchange Format (KIF) (Genesereth & Fikes, 1992).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
