Model-driven systems development.

As systems become more complex and integrated, with fewer components delivering more capability, this traditional approach becomes unwieldy due to the large number of possible mappings. It is common for a modern system, such as an automobile, to have thousands of detailed requirements and thousands of components, resulting in millions of possible mappings. Faced with this dilemma, developers limit the level of integration, resulting in systems that may be highly capable but are brittle and difficult to maintain. (5) MDSD methods mitigate this explosion of mappings by providing levels of abstraction.

The development team must understand the mission and concerns of the business and how the proposed system relates to them. To ensure that the system indeed satisfies its intended purpose, the development team must establish that the top-level system requirements and the requirements derived from them are satisfied by the collaboration of the system's components. MDSD must address these system concerns, and, at the same time, provide the development team with an improved understanding of the system, its goals, and its components.

A model-driven systems development approach

MDSD must build upon the techniques of requirements-driven development methods in light of their historic success, but, for reasons described previously, a change in the approach to systems development is required. MDSD starts with system decomposition, that is, the division of a system into elements in order to improve comprehension of the system and the way in which it meets the needs of the user. Because of the limited capability of humans to understand complexity, a "divide and conquer" system decomposition approach is appropriate. (4) In this approach, the system is decomposed into a comprehensible set of elements, each of which has a comprehensible set of requirements. Sometimes, to manage complexity in very large systems, system decomposition must be applied recursively.

Effective application of system decomposition requires the means of modeling the system from a variety of viewpoints and at increasing levels of specificity. In addition, a set of transformations between model levels is required as a basis of the development process. These transformations provide a means of deriving the next level of specificity while maintaining traceability and coherence for the entire model. MDSD consists of creating the model artifacts as a means of specifying the system elements and their integration. An artifact is defined as any item that describes the architecture, including a diagram, matrix, text document, or the like. This model provides a common means for facilitating collaboration across the engineering disciplines, coordinating iterative development methods, and assigning technical and managerial responsibilities. (6)

In this paper, we describe an MDSD modeling framework, the Rational Unified Process (*) for Systems Engineering (RUP (*) SE), and some of its fundamental transformation methods. This MDSD framework and its associated transformation methods have been refined over eight years of field experience by Rational (*), IBM, and our clients. (7-9)

A comprehensive treatment of MDSD is beyond the scope of this paper. We provide a brief introduction to this field and supply references to more extensive treatments of the topics touched upon. A discussion of the underlying framework for modeling systems is presented in the section "The RUP SE architecture framework." This framework provides the setting for the transformations. The section "Modeling Languages and MDSD" is a discussion of the use of SysML to capture some of the key framework artifacts. The generation of the artifacts requires some specific transformation methods, described in the section "Transformation methods."

Finally, we conclude with a precise description of the framework captured in a RUP SE metamodel. This metamodel is implemented as a profile for SysML (and for UML when RUP SE concepts apply to the software part of the system). The metamodel therefore adds specific semantics to enable these languages to handle our framework. Thus, the various models shown in this paper are represented using RUP SE semantics that extend SysML, making them, in that sense, RUP SE models. Although this approach is appropriately supported by a modeling language such as SysML (and its toolset), it is actually independent of any language.

THE RUP SE ARCHITECTURE FRAMEWORK

The RUP SE architecture framework provides support for constructing a sound architecture on the basis of four principles: separation of concerns, integration, system decomposition, and scalability. Separation of concerns allows designers to address each set of stakeholder concerns independently; integration is achieved by requiring the use of a common set of design elements across multiple sets of concerns. System decomposition subdivides the system by structure, rather than by function, enabling the framework to provide levels of structure that enable parallel development; and scalability is achieved by using the same framework, whether the system under consideration is an enterprise or a product component or anything in between.

In this section we provide an overview of the framework and the reasoning underlying its design. In addition to the discussion here, a detailed description is provided in the section "RUP SE metamodel" at the end of this paper.

Like many frameworks, the RUP SE framework consists of two kinds of artifact: static artifacts, namely, representations of the system in its context and the things that comprise the system; and dynamic artifacts, namely, how the static elements collaborate to fulfill their role in the system. The static artifacts enable separation of concerns and scalability and provide the semantics for system decomposition. The dynamic artifacts enable integration of concerns. We discuss both types of artifact in the following sections.

Table 1 illustrates the RUP SE architecture static framework. The framework consists of three types of element: model levels, viewpoints, and views, each of which is described in detail in the following subsections. In the representation of Table 1, the rows represent model levels (context, analysis, design, and implementation levels), the columns represent viewpoints (worker viewpoint, logical viewpoint, information viewpoint, etc.), and the cells represent views (e.g., the worker viewpoint at the design level).

While Table 1 describes the framework elements at a high level, the metamodel described in the section "The RUP SE metamodel" provides a more complete description of the elements and their relationships.

Model levels

A model level is defined as a subset of the architecture model that represents a certain level of specificity (abstract to concrete); lower levels capture more specific technology choices. Model levels are not levels of abstraction; in fact, a model level may contain multiple levels of abstraction.

Model levels are elements designed to group artifacts with a similar level of detail. The MDSD transformations occur between the model levels. Table 2 describes the four model levels expressed in the framework.

The context level treats the entire system as a single entity, a black box. This level addresses the system's interaction with external entities. At the analysis level, the system's internal elements are identified and described at a relatively high level. Which elements are described at this level depends upon the viewpoint. For example, in the logical viewpoint, subsystems are created to represent abstract, high-level elements of functionality. Less abstract elements are represented as sub-subsystems, or classes. In the distribution viewpoint, "localities" are created (as described later in the paper) to represent the places where functionality is distributed.

At the design level, the decisions that drive the implementation are captured. In the transition from the analysis level to the design level, subsystems, classes, and localities are transformed into hardware, software, and worker designs. This is not a direct mapping from system elements to designs; rather, design decisions are made by deriving the design from the functionality represented in the subsystems and classes. These design decisions are constrained by supplementary requirements and distribution choices represented by the localities and their attributes. The resulting design transformation realizes all of the specifications from the analysis level. In other words, the system architecture is specified at the analysis level, creating requirements that the design level must satisfy.

At the implementation level, decisions about technology choices for the implementation are captured. Commercial products may be specified (e.g., a messaging middleware product, a model and part number for a piece of hardware), or items might be specified for internal implementation. As before, moving from the design level to the implementation level is a transformation, but this time the mapping is more direct. For example, at the design level, the functional activities of a worker are mapped to a position specification with a defined set of skills. Then, at this level, the specification can be fulfilled either by hiring someone with the correct skill set (similar to choosing a commercial product with certain capabilities) or by training an individual to acquire the required skills (similar to doing an internal implementation). This transformation of worker activities to specific skills, though necessary for the system to meet its goal, is not well understood, and is seldom, if ever, practiced.

Viewpoints