idef3_kbsi_report (1013870), страница 43
Текст из файла (страница 43)
For a rigorous account of the relation between many-sorted and single-sortedlanguages, see Chapter 4, §4.3 of (Enderton, 1972). In any case, regardless of whether one isusing a many-sorted or single-sorted language, it is generally good practice to choose variables214that reflect their intended semantic categories—e.g., “?ind”, “?rel”, “?f”, “?sit”, “?inf”, “?uob”,“?coe”, and so on.1818Although this practice is adhered to in informal discussions in this document, it is not always followed in thestatement of the formalization above in order to drive home the fact that the elaboration language is itselfsingle-sorted, and that typing distinctions are introduced and enforced axiomatically.215APPENDIX B: IDEF3 GLOSSARYActivationConditions, EntryConditions, ExitConditions, StateConditions, TransitionConstraintsContextContext statementDecompositionA collection of instances of some or all of the UOBs inthe process represented by the schematic whose temporaland logical properties satisfy the temporal and logicalconditions specified in the schematic.
See instance.Sufficient conditions for an object to enter a state given a(possibly different) object in the source state of the linkleading to the destination state that has met the relevanttransition conditions. Entry conditions are associatedintrinsically with the interface between object states andtransition links.Sufficient conditions for an object no longer to be in thestate in question.. Exit conditions are associatedintrinsically with object states.Conditions that are individually necessary for an object tobe in the state in question. State conditions are associatedintrinsically with object states.Conditions that are individually necessary and jointlysufficient for there to be an attempted transition from asource state to the destination state.
Transition conditionsare associated intrinsically with the interface betweenobject states and transition links.Most generally, a statement which must (or equivalently,must not) hold in a system. Most often, constraintsexpress logical properties of, or connections between,domain objects that must be maintained if the system is tofunction as intended.
Constraints are distinguishedconditions known to hold between the objects in a processor between the processes themselves.The parts of the system under study identified as thebounds within which description development activitywill occur and which establish the environment or settingused to document and interpret domain expert knowledge.A written declaration identifying the boundaries of IDEF3process description development activity (usuallyexpressed in terms of which parts of the system are to beincluded and which are to be excluded) and the necessarylevel of detail. The context statement is documented onan IDEF3 Description Summary form.One of possibly many contextualized descriptions of oneUOB in terms of other UOBs.
Schematics providing amore detailed view or different perspective of a processwith a clearly defined viewpoint.216DescriptionDomainDomain expertElaborationElaboration languageFactsForm, IDEF3 DescriptionSummaryForm, ElaborationForm, IDEF3 SchematicForm, Object SchematicSummaryA recording of facts or beliefs about something within therealm of a domain expert’s knowledge or experience.A sphere of interest, such as the semiconductor domain orthe domain of abstract algebra.
A domain has its owndistinctive vocabulary for talking about the characteristickinds of objects and processes typically found in thedomain.An individual considered knowledgeable of, andconversant in, most of the distinguishing characteristics ofa certain aspect of a domain. A role played by theprimary sources of knowledge from the applicationdomain of interest.An elaboration provides a detailed characterization of anIDEF3 element (e.g., UOB, Object State, Junction, Link)in a schematic. See Form, Elaboration.A structured textual language designed specifically toexpress process-related information. The IDEF3elaboration language has the full power of first-ordermodal logic and set theory.Relationships that hold in the actual world. Facts areassertions made about objects.A structured document that summarizes theevolving/completed process description.
It records theproject purpose and context and provides a summary ofall the schematics and documents used to record theprocess description.A structured document used to provide a detailedcharacterization of IDEF3 elements (e.g., UOBs, objectstates, links, junctions) in the schematic. Elaborationdocuments typically include: 1) the element’s name,label, and number; 2) lists of the object types andinstances, facts, and constraints that are associated withthe element; and 3) a textual description of the element.The basic framework for all IDEF3 forms.
The IDEF3Schematic Form is divided into three major sections: 1)Working information (top), 2) Message field (center), and3) Identification fields (bottom). Working informationfields are used to support the kit review process. Theidentification fields establish the context and purpose ofthe information on the form. The message field containsthe primary message to be conveyed. This field isnormally used for schematics, but can be used for anypurpose (e.g., glossary, checklists, notes, sketches).A structured document summarizing the contents of anIDEF3 Object Schematic.217Form, PoolForm, Process SchematicSummaryForm, Source MaterialDescriptionForm, Source MaterialLogIDEFIDEFØIDEF1IDEF1XIDEF2IDEF3IDEF4IDEF4/C++IDEF5IndividualA structured document used to list the scenarios, objects,UOBs, and object states identified during descriptiondevelopment and provide traceability to the sourcematerial supporting those elements.A structured document summarizing the contents of anIDEF3 Process Schematic.A structured document used in conjunction with theSource Material Log to record more detailed informationabout each item tracked as source material.
In particular,this form is used to capture a concise overview of themain concepts discussed in the source material andprovide traceability from the source material to IDEF3description elements.A structured document used to identify and track all datacollected during the course of the project. The SourceMaterial Log serves as the primary index to all sourcematerial collected and used in an IDEF3 project.Acronym for Integration Definition. Also used to refer toa family of mutually-supportive methods for enterpriseintegration, including in particular IDEFØ, IDEF1,IDEF1X, IDEF3, IDEF4, and IDEF5.Integration Definition (IDEF) method for FunctionModelingIntegration Definition (IDEF) method for InformationModelingIntegration Definition (IDEF) method for Semantic DataModelingIntegration Definition (IDEF) method for SimulationModelingIntegration Definition (IDEF) method for ProcessDescription CaptureIntegration Definition (IDEF) method for Object-OrientedDesignA specialized Integration Definition (IDEF) method forObject-Oriented Design targeted toward implementationusing the C++ object-oriented programming language.Integration Definition (IDEF) method for OntologyDescription CaptureThe most logically basic kind of real world object.Prominent examples include human persons, concretephysical objects, and certain abstract objects such asprograms.
Unlike objects of higher logical orders such asproperties and relations, individuals essentially are notmultiply instantiable. Individuals are also known as firstorder objects.218InstanceInterviewJunctionKitKit, DescriptionKit, ObjectKit, ScenarioKit Contents SheetKit Cover SheetKit ReviewLinkLink, ConstrainedPrecedenceAs pertaining to an activation, a specific case where oneof the pattern of possible activations is exhibited.A face-to-face meeting with domain experts to pursuesome line of investigation.An element of the IDEF3 Schematic Language providinga mechanism to graphically display logical branching.An assembly of diagrams, text, glossaries, decisionsummaries, background information, or any portion of thetotal IDEF3 description packaged for review andcomment.















