Model-driven systems development.

As defined previously, a system is a set of collaborating resources that deliver services. In particular, a system encapsulates the needed resources to deliver those services. To fulfill its goal, a system may rely on the services of others. Hence, context in systems modeling is well-captured by static diagrams capturing the actors with which the system interacts and how the system and the actors are related. Context varies according to viewpoint. In the logical viewpoint, context relates to the static relationships between the system and its actors. The system in this viewpoint is represented as a classifier with attributes and operations, organized into interfaces. An interface is defined as a named set of operations that characterize the behavior of an element. An interface declares a set of public features and obligations that constitute a coherent service offered by a block (in SysML) or a classifier (from UML 2.0). In the distribution viewpoint, context relates to the physical relationships between the system and the actors. In this viewpoint, the system is a kind of locality. In the data viewpoint, context relates to the relationships between the data maintained by the system and the data maintained by its actors.

Figure 2 includes an example of a RUP SE logical context diagram. This diagram is identical to what Lykins et al. call an elaborated context diagram in Reference 15. Following the work of Friedenthal and his colleagues, the diagram includes (in the logical view context diagram) the stereotyped block "I/O entity," which has attributes and no operations. I/O entities capture what passes between the system and the actors. I/O entities may typically contain data, but may also include physical things like power. Figure 2 also includes a context diagram of a distribution view. Although the system is both a logical entity and a distribution entity, it is shown as a class in the distribution view as a matter of style.

[FIGURE 2 OMITTED]

TRANSFORMATION METHODS

The RUP SE framework includes novel, related artifacts for transformation methods between model levels. The generation of these artifacts and their relationships requires new techniques. These techniques are described next.

System of systems decomposition

In this subsection, we describe a method of object-oriented logical decomposition to describe a hierarchical system of systems. Additionally, we discuss a number of principles, found in traditional systems development, that underpin the MDSD framework discussed in this paper.

A system encapsulates the resources it requires to deliver its services. Systems may be decomposed into systems, each of which also encapsulates all of their resources. Because systems control their resources and may encapsulate other systems, a "system of systems" is a recursive pattern. A process may therefore be applied to recursively decompose a system into other systems, which are themselves decomposed further. During such recursive decomposition it is important to understand at which "level" in the hierarchy we stand during a discussion. Although terms such as "superordinate system" and "subordinate system" are relevant when discussing the pattern, it is sometimes more useful to discuss "'system levels" because more than two levels may be considered.

The term "system level" indicates the relative position in the overall hierarchy; "system level 1" represents the "root" system (by definition, there is always exactly one "system level 1" system). An overview of the key artifacts in two system levels is shown in Figure 3. This figure shows the pattern that allows the framework to support recursive system decomposition. The dotted lines between the systems indicate UML dependencies.

[FIGURE 3 OMITTED]

Operations analysis

Classical use case analysis is a form of requirements decomposition; therefore, for reasons previously described, it is inadequate to meet the needs of systems development. In MDSD, the techniques of use case analysis are extended to operations analysis. Operations analysis consists of the following recursive pattern: (1) decompose the system to create a context for the system elements; (2) treat the system operations as use case scenarios for the elements; (3) describe the scenarios in which the elements, as black boxes, interact to realize the system operations; and (4) derive the operations of the elements from the scenarios.

This pattern can be applied starting at the enterprise, which contains the system of interest (hence the context level for the MDSD framework). In this application of the pattern, the enterprise is treated as a system and the system to be developed as a component.

The system decomposition creates the context for the elements; thus, context is maintained at every level of the system hierarchy. The operations analysis provides a method for creating traceability between the use cases, which define the business or mission needs, and the system components that satisfy those needs. The maintenance of this context at each level of the hierarchy was a key insight during our development of the MDSD. The use cases at the top level of the system hierarchy define the interactions of the system with external entities in order to fulfill its mission. These interactions are analyzed to identify the operations that the system provides in order to fulfill its role in the use cases. Operations analysis forms the basis of the use case realization. The operations are combined into interfaces or services.

Figure 4 shows a sequence diagram illustrating the realization of a use case initiated by a client requesting the operation "step 1" from analysis subsystem 1. This sequence diagram describes the internal workings of the system and is therefore a white-box view of the system that encapsulates the analysis subsystems 1, 2, and 3. The diagram is also a black-box view of the interactions between these analysis subsystems. In the context of the overall system this is a white-box view, but within this white-box view are black-box views of the collaborations of the various analysis subsystems. For analysis subsystem 2, the operations "step 2" and "step 4" are derived requirements in the context of a black-box view of this subsystem.

[FIGURE 4 OMITTED]

Operations analysis uses sequence diagrams to recursively derive system-component black-box requirements at every level of the hierarchy. An operation realization is created for each operation, and the realization is performed concurrently across the system components identified in the architectural analysis activity.

Joint realization

In developing the system model, use cases are written, system components are defined, and the interactions between the components are described. This is standard practice for modeling a system. For large-scale developments, we must also decompose the system, divide and suballocate the requirements, and develop links for traceability purposes. The new mechanism for connecting all of these items is a Joint Realization Table (JRT). The joint realization method is how the JRT is completed and is therefore the process by which decomposition is accomplished within MDSD.

In MDSD, we distinguish between functional requirements and nonfunctional requirements (NFRs). Functional requirements describe the system behavior as well as the collaboration among system components to accomplish the system behavior. NFRs pertain to how a system performs its functions and include concerns such as quality, quantity, and timeliness.

JRTs decompose the system in the context of the logical and physical architectures and, at the same time, assign nonfunctional requirements to these system components. In a real sense, this is the missing link--the item that was needed to connect object-oriented development models to the needs of the engineering community developing large-scale systems.

A JRT example that decomposes the task of printing a page is found in Table 4. The header material for the Build Page operation provides context for elaborating the JRT. This JRT decomposition allocates the functionality of the single black-box operation to white-box printer entities. The Action Performed column captures both the logical entity performing the action and the logical step performed. In this example, two logical entities, I/O Services and Raster Image Processing, collaborate to print a page. NFRs are allocated to the logical white-box steps in the White Box Budgeted Requirements column--for example, 10 milliseconds are allocated to the I/O Services to receive and store an available data block in memory. The last two columns provide the distribution and process references. In this example the printer-control-unit locality and Data_rec process must perform the task of receiving a block and putting it into memory within 10 milliseconds.

The JRT maintains context, captures the logical and distribution decomposition, and provides for the allocation of nonfunctional requirements. With the JRT in place, it is useful to represent the content in SysML as a coupled set of sequence diagrams showing the same flow in the different viewpoints. Figure 5 shows the sequence diagrams for the print page service. The insights gained by modeling the various elements (analysis subsystems, localities, etc.) may lead to their refactoring and refinement until the needed set of interactions are identified and assigned to them. The candidate operations may also be refactored and refined as a result of the insights gained from the model.

[FIGURE 5 OMITTED]