(MBSE) as a systematic approach for software reuse. The use of models in .... Custom. Design. Custom. Develop- component specification. Integration & Test. Information. Model ..... systems and tailoring the executive. An operational system in ...
Models for Domains and Architectures: A Prescription for Systematic Software Reuse Sholom Cohen Robert Krut Spencer Peterson James Withey Software Engineering Institute
This paper presents a Abstract: tutorial on Model-Based Software Engineering (MBSE) as a systematic approach for software reuse. The use of models in MBSE differs from reuse approaches based on libraries which do not define how the components are structured, how they interoperate, and how they are combined to deliver a given functionality. MBSE offers an approach for systematic reuse by defining the required capabilities of a class of applications, or domains. It supports a trade-off decision process for design and implementation similar to that practiced in other engineering disciplines. Software modeling under MBSE is a key factor in successful reuse and is demonstrated in several case studies presented in this paper. The paper concludes by discussing the products necessary for successful transition of the MBSE technology.1
1
Modeling Software
Many approaches to software reuse focus on the creation of libraries of components. These libraries may be in the form of class hierarchies or may be functional modules. Often, reuse within a librarybased framework fails. Users of the library discover:
•that components lack a common underlying structure
•there are no guidelines for component interaction •there is no generic design to guide combining components to deliver a given functionality. Model-Based Software Engineering (MBSE) offers
1.
an alternative to library-based approaches and is proposed as a prescription for systematic reuse. The MBSE approach establishes a framework for relating several types of models:
•Abstract models give us basic modeling concepts. They address questions such as: What is a domain model, what is an architecture, and what are the structures for reusable components?
•Concrete models apply the abstract models by adding domain information. They include the domain model of a particular class of applications, a generic design, a collection of components, and application generators. For a specific domain, the concrete models constitute a domain-specific software architecture (DSSA) [Mettala 92].
•Instances are the applications built upon the concrete models. For systematic software reuse, organizations must invest in creating models of the common capabilities of related software applications. These models then serve as a basis for requirements and design analysis and also support creation of component libraries. Organizations use models and libraries of components as software assets to support systematic software reuse. Using these assets, the process for developing software applications will become more an engineering change activity of mapping from needs to software solutions rather than a synthesis activity of building from scratch. Figure 1 illustrates the framework for models and other software assets, including underlying technology, domain engineering, and application engineering. Technology areas encompass abstract models, supporting:
Sponsored by the U. S. Department of Defense.
Copyright 1995 by the American Institute of Aeronautics and Astronautics, Inc. All rights reserved. A Model Base for Software Engineering
•requirements - domain modeling techniques such as Feature-Oriented Domain Analysis [Mettala 92], object-oriented analysis[Withey 1
Technology Areas Architecture
Requirements
Implementation
Domain Engineering Design Model
Domain Model
Design Guidelines
Information Feature Model Model
Par titioning Strategy
Application Component Library Generator
Coordination Model Scheduling Time Location
Functional Model
Design Specification
C
Generic Design
Highway Regulations Constraints
npath = {a,b|b succ(a)}
Application Engineering customer needs
new rqmts Requirements Analysis proto-
Custom Design
component specification
protofeatures list
typing
product configuration
typing Design Analysis
Custom Development
software application
Integration & Test process backtracking
Figure 1 Model Based Software Engineering Framework 93], and related techniques.
•architecture - concepts relating to system components, connections, constraints, and rationale[Withey 93], [Mettala 92].
•implementation techniques - rules for developing software objects or components [Mettala 92], [Mettala 92]. Domain engineering produces concrete models. It applies techniques for architectural synthesis and analysis, domain analysis, object-oriented technology, performance analysis, and quality assessment to build reusable assets. Application engineering uses assets to produce the software application. The MBSE approach to domain and application engineering provides a framework for discussing reuse, reengineering, object technology, and other areas of interest. It also helps define the products and processes of software development.
1.1 Model-Based Software Engineering (MBSE) The objective of Model-Based Software Engineer-
ing (MBSE) is to improve product cycle time, product quality and product maintainability. MBSE promotes a formal understanding of the features and structure of related applications through the development of reusable software assets that simplify the development of new products. In MBSE, these reusable assets are designed for flexibility: they will not easily fail as changes occur in functionality, performance, or technology. Much of the technology in MBSE is not new. MBSE focuses on models that consolidate engineers’ understanding of a family of software applications. From this shared understanding, engineers can create reusable assets that satisfy a wide variety of uses and can easily analyze changes in existing software to quickly compose or synthesize new solutions for subsequent products. MBSE consists of the following elements:
• product families - domains • a production system • software assets • engineering processes. The following subsections discuss each element.
1.2 Product families Depending on whom you ask, what comprises a product family will vary. Some consider software products that share a common design and a set of components as a product family; e.g., training simulators or digital switches. Others regard those products that share common capabilities or provide similar services as a product family. The design and implementation of these products can vary significantly; for example, movement control systems. Still others will group software products according to the technology embodied in them. For example, process control systems are based on a common mathematical feedback model. In all of these overlapping notions there is the concept of a shared core. This shared core is what we define as a domain. Domains are areas of core product expertise for which economies of scope can be realized. Economies of scope occur when building a reusable resource and then using it in multiple products yields more income than recreating the resource in each product. The economy stems from leveraging expertise and reducing learning - major cost drivers in product development. Economy of scope is dependent on a strategy that pursues market share and product differentiation. Domains are centered around a body of knowledge. This knowledge typically encapsulates deep understanding of some combination of the following product characteristics:
• use scenarios • features • embodied technologies • standards • architecture • subsystems • components This knowledge is manifested in work products used in the development of software: models of requirements, architecture or design, code components, design records, application generators, and standards for development, test or integration. Domains may be defined by a common design 3
shared by a group of products. The domain model describes similarities and differences in product designs and implementations. An architecture is constructed to support product evolution and maintenance. The architecture describes:
• the allowable software elements, computational resources and their combinations
• how these elements and resources are coordinated
• how functionality is partitioned statically and dynamically to these elements and resources Domains may be based on a core technology such as signal processing or guidance control or centered around a consistent set of business rules. Work products in both cases typically include a domain language, execution models or “engines” and a code generator that experts use to produce parts of applications. Domains may be defined by the capabilities or services common to a group of products. The domain model describes:
• the general entities and functions • how these entities and functions can vary • the effect of the variation on the products’ operation. Individual customer needs are parameters that specialize the entities, functions, and operations. Different technologies or designs may be selected to meet the requirements of individual customer or a group of customers. Usually a best product design is constructed with sufficient flexibility to meet evolving user requirements and market segmentation.
1.3 Production System In many organizations, the scope of software development is project-centered. The priorities of the project drive resource allocation and design decisions. Since a project must satisfy the needs of an end user within cost and schedule, there is little incentive for inter-project coordination and for investment in reuse. To plan for change and grow core technology, the scope of software development must also include domains and be organized as a Deming production system [Deming93]. A Model Base for Software Engineering
Deming’s notion of a production system covers the essential activities of an organization:
•User Needs is an activity which includes market analysis, needs analysis, product definition, and strategic planning. For commercial organizations, the focus of this activity is primarily on identifying the features of products that increase customer value. For the DoD, the focus is on identifying the features of the mission that are critical for combat superiority. Improvements that should be performed by the design activity are an outcome.
•Design is an R&D activity that focuses on improving the production system - either the processes or the products. Statistical process control is applied to the production step while product technology is applied to define and improve the materials.
•Materials are tangible items used in the production activity. The production activity changes with the introduction of new materials. In addition, Deming covers actual production and distribution to the customer. MBSE affects the design activity, materials, and production activity in Deming’s framework: domain engineering is a design activity; software assets (i.e., the models, components, and application generators) are the materials; and application engineering is the production activity. (See Figure 2.) The production system is a process designed to facilitate innovation and incremental improvements and to achieve economies of scope as well as scale. At its foundation, this production system develops models and other assets which embody reusable technical and product knowledge.
1.4 Software Assets Materials that support a family of applications are software assets. These assets are more than just a library of reusable components. They include models supporting the front-end portion of software development - architectures, designs, and requirements. Each cycle through the production system is an opportunity to refine these assets. Software assets are the reusable resources used in application engineering. Examples of software assets include domain models, software architec4
tures, design standards, communication protocols, code components and application generators. In many companies, these assets are work products developed and maintained internally. These work products are used in products within a product family or in products across many families. Examples of assets are provided in the case studies of Section 2 of this paper.
1.5 Engineering Processes Figure 2 shows MBSE as a production system consisting of two parallel engineering processes: domain engineering and application engineering. Two engineering groups having different skills and rewards structures support these processes. Domain engineering is a process of analysis, specification, and implementation of software assets in a domain which are used in the development of multiple software products. Application engineering is an engineering change process that develops software products from software assets. Activities include using:
• a domain model to identify customer requirements
• a design model to specify a product configuration
• an architecture to guide new development • application generators and software components to implement the product. This information as well as an in-depth discussion of the process steps and outputs for MBSE, and implementing MBSE into your organization, are provided in [Withey 93].
2
Case Studies
Through collaboration with sponsors, MBSE technology has been applied in the creation of domain and application engineering products. Some of these sponsors include:
•National Institute of Standards and Technology (NIST) - applying the FODA method for developing a model of network management systems software
A Model Base for Software Engineering
Software Assets
Application Engineering
Distribution
Domain Engineering
User Needs
User
Figure 2 Production Cycle for Software
•Joint Modeling and Simulation System (JMASS) - applying verified and validated software components for design of friendly and threat models
•Army Communications and Electronics Command (CECOM) - creation of a domain model of Army movement control, a tactical decision aid supporting command and control.
2.1 NIST A pilot study at NIST has produced a domain model and requirements generator capabilities for the computer network management systems domain [Mettala 92][Mettala 92]. The study applied the Feature-Oriented Domain Analysis (FODA) technique [Mettala 92] to develop both a context and domain model for the domain. In addition, the study used the Culture-adaptive Mechanism for Expression, Reflection, and Analysis (CaMERA), a requirements analysis tool, to support the domain modeling. Under the context model, this effort produced two software assets:
1.Structure diagram to define fault management as the scope for analysis within network management systems 2.Context diagram for fault management to describe the interfaces of the fault management subsystem within a network manager.
Developers of network management systems can reuse these models as a basis for establishing interface requirements for fault management in a new system. The domain model includes three submodels for alarms processing within the scope of fault management: 1.Information model defining the entities and relationships relevant to the domain
2.Feature model defining the operations and context of operation (including characteristics of the network and its users) 3.Operational model defining the state transitions and activities. The network management systems developer may reuse these models to support requirements elicitation and specification for a new system. The CaMERA tool automates the elicitation process and supports completeness and consistency verification.
2.2 JMASS The primary focus of the Joint Modeling and Simulation System [Mettala 92] has been the development of a standard architecture to support modeling and simulation within DoD. Because a common modeling architecture and consistent design standards are the basis for developing simulation models, the components can be use by developers of
simulation components to effect a “plug-and-play” structure for building simulators. A developer of a simulation of a weapon system must follow the standard architecture in order to interface to other components within the overall simulation. While this constrains design, it assures supportability and maintainability of the system. A simulation support environment (SSE) also utilizes the standard architecture to support development and assembly of components, configure and execute scenarios, and perform post-simulation processing of data. A consistent architecture for development supports an evolutionary path for JMASS. Future enhancements include integrating hardware-in-the-loop into what is currently a software emulation environment. The architecture also supports reengineering and integration of legacy software into the environment.
2.3 CECOM The domain of interest for this work has been movement control, a command and control tactical decision aid that deals with the movement of soldiers and materiel on the battlefield. Products include:
•a domain modeling method called FeatureOriented Domain Analysis (FODA) [Mettala 92]
•a domain model of movement control using FODA models as the abstract modeling concepts [Mettala 92]
•a generic design that encompasses the domain of movement control
•a working prototype built on the domain model and generic design
•a technical report on using an abstract architecture model to map the domain model to a generic design. [Mettala 92] Taken together, these models constitute a domainspecific software architecture (DSSA) for movement control. The MBSE approach for systematic reuse is illustrated in detail through examples from the movement control domain.l
2.3.1
Domain Model
...the planning, routing, scheduling, control, and in-transit visibility of personnel, units, equipment, and supplies moving over lines of communication in accordance with the directives of command planning [USArmy 90]. Tactical decision aid systems in this domain must provide the following capabilities:
•Convoy Building - selecting vehicles for moving personnel, equipment, and supplies and organizing the vehicles into a convoy
•Routing - selecting a route using the available road network (and potentially off-road paths), taking into account the capabilities and characteristics of the vehicles involved
•Scheduling - determining the travel time for a given convoy and route combination, accounting for additional stops as required. The systems deal with significant amounts of information, the most important of which are:
•Units - encompassing personnel, equipment, etc. •Road Network - a structure containing information about points of interest and the roads between them
•Schedules - a structure containing information about events, where an event is a combination of a time and an occurrence of interest.
2.3.2
Context analysis
The context analysis establishes the scope of the movement control domain. A structure diagram shows the movement control domain in relationship to other related domains, such as Force Level Control (FLC). These domains will be a part of numerous Army command and control systems. Movement control is also related to data management, network management, etc. The latter support domains are necessary for implementing movement control. The second element of the context analysis, the context diagram (Figure 3), shows the extent of the domain by identifying key interfaces. It shows, for example, that movement control receives status updates from units through position reports. Movement control itself is not responsible for calculating current positions.
Movement Control is
6
A Model Base for Software Engineering
Direct Planning
Commander’s Guidance
Execute Movement Requests
Operational Considerations
Movement Estimate
Position Reports
Orders
Movement Status
Movement Control Order Status
Constraints and Options
Battlefield Data
Tactical and Terrain Constraints (static)
Orders
Weather, Friendly & Enemy Information (dynamic)
Movement File
Figure 3 Context diagram determines the scope of the domain and key interfaces mvmt_environment(tupleof:6)
messages(tupleof:4)
schedules(osetof) distribution_plans(tupleof:2)
intelligence(tupleof:2)
transportation(tupleof:4) events(tupleof:2) TCP(osetof)
IPB(tupleof:3) technical_intelligence(tupleof:1)
Figure 4 Part of the movement control information model
2.3.3
Domain analysis
In addition to scope, the analysis must identify the information handled by movement control systems and subproblems within movement control. The information requirements are modeled through any number of techniques that show the information model for the domain. These may include object models [Withey 93], entity-relationship models [Ze-
roual 92], or, as is shown in Figure 4, semantic networks. This information model shows a selection of the information requirements for movement control including transportation (i.e., convoys), schedules, and distribution plans (i.e., routes). The semantics within the network include the tupleof, to show decomposition, and osetof, or ordered set, relations.
Figure 4 context_features(tupleof:5)
kind(oneof:2) mission(oneof:3)
policy(tupleof:2)
control_strategy(oneof:3)
unit’
level_of_command(oneof:5)
logistical’
regional_CINC(oneof:5) centralized’
global’
distributed’
below’
joint’ theater_army’
division’ corps’
Figure 5 Context features identify reasons for variability within the domain The goal of the information model is to show the constituent components of the domain. A second element of the domain analysis is the identification of features for the class of movement control applications. Features may be defined as: what the applications in the domain do or accomplish or “an operation applicable to the instances of the class” [Mettala 92]. In FODA the identification of features is accomplished through feature models, showing operations, context for operations (or constraints), and representation. The selection of context features shown in Figure 5 identifies key factors that lead to variability within the movement control domain. Level of command, for example, is concerned with the types of units involved in movement. At the joint level, movement control involves strategic units numbering hundreds of thousands of soldiers and their supporting supplies; at the division and below, movement control may be concerned with hundreds of soldiers or fewer. The routing and scheduling will vary based on these constraints. Control strategy determines whether plans are controlled at a centralized site or are controlled by the moving units. Additional sets of operations will take place to centrally control multiple units.
Figure 6 shows a selection of operational features that define capabilities within the domain. These include the actual operations performed by applications and may include options and alternatives. For example, all movement control systems perform convoy building. However, defense planning prepares for possible enemy attacks and occurs only in a tactical situation, not in a purely administrative move. There are a number of means to accomplish routing: shortest path, shortest time, manual, or automatic. The choice may be dependent on context features. For example, when large units are being moved, a system should automatically perform routing. The domain model should include this knowledge and software built to satisfy the domain should accommodate this requirement. Representation requirements for movement control include maps, movement graphs, messages, and other forms of representing information to users or interoperating systems. The operational model defines how the system works in terms of state transition or other behavioral representations. For movement control this would include the flow of control necessary to obtain information for:
movement(tupleof:4)
highway_regulation(tupleof:2)
convoy_building(tupleof:2)
convoy_control(tupleof:2)
traffic_control(boolean) deconfliction(tupleof:3)
defense_planning(boolean) dependent_events(boolean)
column_formation(tupleof:4)
routing(tupleof:5)
independent_events(boolean) parallel_events(boolean)
asset(tupleof:5) scheduling(tupleof:4)
Figure 6 Operation features are capabilities within the domain 1.building a convoy 2.routing the convoy 3.scheduling the convoy 4.reconciling multiple schedules (i.e., deconfliction). The operational model also shows alternative or optional flows based on feature selection. For example, under centralized control, schedules must go to higher level organization for deconfliction of resource reservations. For distributed control, each unit must deconflict with other units in the area of its move.
2.3.4
Architectural analysis
During architectural analysis, the domain engineer selects an appropriate design approach for building a generic design. The design approach must accommodate the required features, captured by the domain analysis, plus be flexible enough to accommodate differences among individual applications to be built from the generic design. The domain model provides required capabilities and alternative requirements. In particular, the context features of the domain are a key factor identifying the reasons for change and variability. The basic design approach used in building the generic design for movement control is the Object
Connection Architecture (OCA) [Mettala 92]. This approach includes:
•standard design templates in Ada for all of the architectural elements and reuse of the template structure within the design
•decoupling of features through the use of import and export regions to handle data communication
•accommodation of alternative features though encapsulation at the subsystem and object levels
•alternative behavior through the use of signatures. Each subsystem needed in the generic design is built using the OCA as a building block. For example, the routing feature leads to a router subsystem. This subsystem, like all other subsystems in the generic design, has a controller, import/export regions, objects and signatures. The generic design shown in Figure 7 is built using the subsystem building block. The domain model provides information to guide the designer in identifying subsystems, objects, and alternatives within the design. The executive supports design based on the operational model with flexibility for choosing among alternatives. Systematic reuse from domain models, through ge-
Graphical Terminal
Data Storage DB/File Access
X/Motif User Interface
Data Base
Router
Database Status
User Selections
Executive Asset Manager Control Flow
Convoy Builder
Scheduler
Subsystem
Surrogate
Interface Code
Figure 7 The generic design of the Movement Control domain neric design to domain implementation, will support the specific requirements of an Individual application within the domain. These applications are built from the generic design by interconnecting subsystems and tailoring the executive. An operational system in Ada built from this generic design includes approximately 25,000 lines of code developed during domain engineering for movement control. Of this total, 5,000 are reused from software developed prior to domain engineering. The schduler subsystem (not included in the 25,000 line count) reuses a planning and scheduling application2 with 85% reuse.
3
Conclusions
The MBSE approach identifies required capabilities and alternatives within the domain and means for handling these differences. MBSE also includes standard design approaches and guidance for building individual systems from a common design. Through use of MBSE, the software developer no longer produces software in a line-by-line fashion.
2.
Computer-Aided Scheduling System (COMPASS), McDonnell Douglas/NASA.
Specific models guide the development and form components of the implementation:
•the domain model provides a common understanding of capabilities, alternatives, and selection criteria.
•the generic design provides a common approach for implementation
•using the generic design, domain engineering can produce usable components, built to -
support the capabilities identified in the domain model
-
work together according to the standard architectural building block.
Creating the models and other assets is only a first step. To bring systematic reuse into an organization requires training and consultative support. The organization must understand the framework for MBSE, the technology for domain and architecture models. They must develop their own standards for abstract and concrete models to support design and must establish pilot studies for initial application of these standards. In addition, the organization must investigate the methods for creating models and tool support. Under systematic reuse, an organization evolves; the organization must create new domain and application engineering groups to support a systematic approach[Withey 93]. These
groups become the key players in a new software engineering production cycle and continuous software process improvement.
4
References
[Booch 87] Booch, Grady. Software components with Ada: structures, tools, and subsystems. Menlo Park, CA: Benjamin/Cummings Pub. Co., 1987. [Cohen 92] Cohen, Sholom G.; Stanley, Jay L., Jr.; Peterson, A. Spencer; Krut, Robert W., Jr. Application of Feature-Oriented Domain Analysis to the Army Movement Control Domain (CMU/SEI-91-TR-28, ADA256590). Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1992. [Dabrow 93] Dabrowski, Christopher; Katz, Susan. A Context Analysis of the Network Management Domain (NISTIR 5309). Gaithersburg, MD.: National Institute of Standards and Technology, 1993. [Dabrow 94] Dabrowski, Christopher; Watkins, James. A Domain Analysis of the Alarm Surveillance Domain (NISTIR 5494). Gaithersburg, MD.: National Institute of Standards and Technology, 1994. [Garlan 93] Garlan, David; Shaw, Mary. “An Introduction to Software Architecture”, 1-39. Advances in Software Engineering and Knowledge Engineering. River Edge, NJ: World Scientific Publishing Company, 1993. [Kang 90] Kang, Kyo C.; Cohen, Sholom G.; Hess, James A.; Novak, William E.; Peterson, A. Spencer. Feature-Oriented Domain Analysis (FODA) Feasibility Study (CMU/SEI-90TR-21, ADA235785). Pittsburgh, Pa: Software Engineering Institute, Carnegie Mellon University, 1990.
Pa.: Software Engineering Institute, Carnegie Mellon University, 1992. [Meyer 94] Meyer, Bertrand. Reusable Software: the Base Object-Oriented Component Libraries. Hertfordshire, UK.: Prentice Hall International, 1994. [Peterson 94] Peterson, A. Spencer; Stanley, Jay L., Jr. Mapping a domain model and architecture to a generic design. (CMU/SEI-94-TR-8). Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1994. [Russell 93] Russell, D.B.; McQuay, W.K. “The Joint Modeling and Simulation System: a common modeling architecture for the DoD”, 984988. Proceedings of 1993 Winter Simulation Conference - (WSC ’93) Los Angeles, CA, 1215 Dec. 1993. [Shlaer 92] Shlaer, Sally; Mellor, S. J. Object lifecycles: modeling the world in States. Englewood Cliffs, NJ: Yourdon Press Computing Series, Prentice-Hall, 1992. [Withey 93] Withey, James. Implementing Model Based Software Engineering in your Organization: An approach to domain engineering. Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1993. [USArmy 90] United States Army. Field Manual FM 55-10: Movement Control in a Theater of Operations. Washington, DC: Headquarters, Department of the Army, Nov. 1990. [Zeroual 92] Zeroual, Kacem; Robillard, PierreN. “KBMS: A knowledge-based system for modeling system specifications” 238-252. IEEE Transactions on Knowledge and Data Engineering. Vol. 4, No. 3, 1992.
[Mettala 92] Mettala, E.; Grahan, M.H., eds. The Domain Specific Software Architecture Program. (CMU/SEI-92-SR-9). Pittsburgh, 11
A Model Base for Software Engineering
12
A Model Base for Software Engineering
