KAPTUR: Domain Engineering Tool. KAPTUR (Knowledge Acquisition for Preservation of Tradeoffs and Underlying Rationales) is a tool for recording, structuring, and reusing engineering knowledge. Such knowledge includes issues that were raised during development, alternatives that were considered, and the reasons for choosing one alternative over others. KAPTUR organizes software knowledge into domains, which are families of similar systems (examples of domains include satellite control center software, radar manager software, etc.). Within a given domain, assetsQ existing systems and subsystems, object classes, function implementationsQ are organized in terms of their distinctive features. Each distinctive feature represents an important engineering decision that went into the development of an asset. The distinctive features provide a means of comparing and contrasting alternative technical approaches in a domain. Assets at any hierarchical level can be compared and contrasted in this way, from system and subsystem architectures down to individual function implementations.
Each feature of an asset has certain information that is always attached to it:
ElvisC - A Tool for Building a Domain Taxonomy. ElvisC 1is a tool that applies a concept formation algorithm (called Cobweb) to automatically organize assets into a hierarchy of meaningful categories. Asset descriptions are provided to ElvisC in terms of features. The feature space is open-ended, and can be interactively extended when an asset is entered. In essence, ElvisC looks for features that tend to occur together, and uses these as the basis for defining clusters of assets. ElvisC was originally developed for NASA/Goddard as a tool for organizing and maintaining a component repository, but we see it also as a domain analysis tool. Domains typically go through a process of evolution: in the early stages a faceted classification is often the most natural or feasible way to describe concepts in the domain; later, as practice becomes more regular and the alternatives become clearer, a hierarchical classification becomes feasible. ElvisC can be used as a tool to facilitate this evolution by suggesting likely categories in a hierarchical classification.
Repository Interconnection Standard. We are active in an AIAA working group to define a standard for reuse repository interconnection. This work is being performed in conjunction with the Reuse Library Interoperability Group (RIG). The work builds upon the Asset Library Open Architecture Framework (ALOAF) developed for the STARS program, and is based on a three-level information model which carries the ALOAF to a greater degree of detail. This work has just begun and is expected to result in prototype demonstrations towards the end of the calendar year.
Domain Analysis in Flight Simulation. The Mission Simulator System (MSS) is a highly configurable flight simulator. MSS is sold as a product and has also served as the basis for several part-task trainers (PTTs) built for the Government, including the F-15/F-16 PTTs for the Air National Guard. The configurability of MSS stems from the fact that instruments, controls, engines, weapons, operational flight programs (OFPs), jammers, artilleries, radars, and missiles (JARMs) can be added or deleted without affecting the remainder of the simulation. MSS is a commercially successful example of domain engineering: the software adheres to a reference architecture for flight simulators that can be (and has been) instantiated to meet widely varying requirements.
Domain Analysis in Satellite Control. In 1988 CTA performed a domain analysis of satellite control centers for NASA/Goddard Space Flight Center. The analysis was based on a study of seven existing systems, from which a reference architecture was abstracted. The architecture was then refined using object-oriented partitioning criteria. The KAPTUR tool was developed initially to support this work. Since then, a domain analysis of satellite command management systems has been performed for the same client, and the results put into KAPTUR. Work is now continuing on the development
Knowledge from Pictures Environment. This is a multi-tool environment intended to support high-level model-based reasoning about software. The environment infrastructure consists of a graphical language for describing component interconnection, a table-based behavior description language, and a model repository. The repository is a set of model descriptions that cross- reference one another. In the model repository, there is no explicit notion of system, only the notion of component. A component may contain other components, and in this sense it may be considered as a system; on the other hand, a component containing other components may itself occur as a subcomponent in a still higher-level component. This uniform treatment of "components" and "systems" encourages the reuse of existing models as building blocks in new models, with the consequent semantic benefits mentioned in the Introduction.
We distinguish between component types and component instances. Each model in the repository describes a component type. Instances of this type may occur in other (higher-level) models. The description of a higher-level model M references the descriptions of the component types whose instances M contains.
The distinction between component types and instances has a couple of advantages. First, a model can contain more than one instance of a given component type. For example, the model of a building's climate control system may contain more than one air-conditioning unit. Second, a change to the definition of a component type is automatically propagated to its instances in all other models. The user of the tool is need perform multiple updates to implement a single conceptual change.
Tools that operate in the KFP environment include the Formal Interconnection Analysis Tool for verifying design properties, the Diagnostics Inferred from Graphics Tool which generates fault detection and isolation rules from the model descriptions, and the Multi-Aspect Simulation Tool, described below.
Multi-Aspect Simulation Tool (MAST). MAST is an environment for building and executing object-oriented models of complex electro-mechanical systems. The design is based on the connection manager approach described in the Software Engineering Institute's (SEI's) recommendations for flight simulators. The SEI approach has been extended by independently formalizing each aspect of a component's behavior, integrating work on discrete event simulation done by Bernard Zeigler at the University of Arizona, and implementing the design using the object-oriented techniques of multiple inheritance and virtual base classes. The models produced in this environment are highly comprehensible and unusually maintainable. The subcomponents produced during construction of the model have been reused in different models without modification. The types of behavior exhibited by the model during simulation have been modified and extended without difficulty.
Hendrix: A Meta-Tool. Hendrix 2 is an existing meta-modeling capability which has grown out of CTAUs work for NASA/Goddard and is based on CTA's Configurable Graphical Editor. Hendrix started off as an automated software design critic which is configurable to support different graphical design notations and different design rules. The Hendrix rule base is implemented in NASA's CLIPS language. Hendrix supports two functions that have made its evolution into a meta-tool a technically straightforward task: 1) the ability of the user to easily define new design rules (without having to code them in CLIPS), and 2) the ability of the user to define new design concepts in terms of previously defined concepts.
Defining new rules in Hendrix. The user defines a new design-evaluation rule by drawing an example of the erroneous situation which is to be caught by the tool. Hendrix generalizes the example into a CLIPS rule that will detect instances of this situation within an engineering model. The user specifies a diagnostic message to be issued when the rule fires. The diagnostic message can reference the design elements in the exampleQthese element identifiers are replaced by variables in the generated rule, and in any particular model will be instantiated to the model elements involved in the violation.
Defining new concepts in Hendrix. A similar approach is used in Hendrix to allow the user to define new concepts. In this case, the user draws an example of an instance of the concept, and Hendrix generates a CLIPS rule that asserts the concept as holding whenever this pattern is detected in a model. More than one pattern can be designated as examples of a particular concept. Hendrix generates one recognition rule for each pattern (this allows the user to define recursive concepts).
Associating concepts with graphical symbols in Hendrix. Having defined a new concept to Hendrix, the user is prompted to select either an arc type or a node type to represent the concept. A palette of available arc types (e.g., dotted, dashed, with/without arrows, etc.) and node types (i.e., different geometric shapes) are presented. If the new concept is a relation between objects, the user is prompted to select an arc type; if the new concept is a type of object, the user is prompted to select a node type to represent that type of object.