Model-driven systems development.

INTRODUCTION

According to conventional wisdom, software and systems projects are seldom successful because success is defined as the delivery of systems that perform as promised, on time, and within budget. According to a report published in Crosstalk, the Journal of Defense Software Engineering in 2003, $84 billion was spent on projects that were never finished, and $192 billion was spent on projects that were significantly late and over budget. (1)

There can be many explanations for this state of affairs, including the need for a redefinition of success in this context. This redefinition would encompass the delivery of systems that meet a variety of stakeholder needs, including content, cost, and schedule. It would allow for the likelihood of improving understanding of stakeholder needs as a program proceeds. Nevertheless, there is some consensus in a variety of contexts that fundamental change is needed in the way systems development is conducted in order to create systems that are agile in response to dynamic conditions and requirements. As stated by Alberts, Garstka, and Stein, "A fundamental lesson that has emerged from multiple domains, including business operations, product development, and defense, is that the power of a new technology cannot be fully exploited to create competitive advantage without the simultaneous coevolution of organization and process." (2) Among the characteristics of the new systems required by today's environment are tighter collaboration among the engineering disciplines involved in systems development and operational collaboration among members of extended enterprises.

In business, supply chain management creates value; the more tightly supply chains are integrated, the more value they create. Hence, the participants in a supply chain strive to integrate their operations and data and, at the same time, maintain unique business processes that create competitive advantage. In warfare, providing the right information at the right time to the right participant supplies a critical advantage. In defense and industry, this creates a need for components that are loosely coupled for architectural benefits such as maintainability and extensibility, yet tightly integrated to interact efficiently. In addition, as the components become more tightly integrated operationally, functionality is naturally redistributed as the collaborations are understood, which naturally results in higher capabilities and fewer components.

The plethora of poor development outcomes is not so much the result of incompetent execution of traditional processes, but rather the result of the inadequacy of the processes themselves to deliver modern collaborative systems. Traditional systems development methods, based on a static and predictable set of requirements, are limited in their capability to address the challenges of operational integration, effective information sharing, and the increasing volatility of requirements. These methods were designed to create a "point solution," and an essential assumption of these methods is that requirements must be well understood before development can go forward. As requirements volatility increases, such methods become less viable. Further, experience has shown that traditional requirements-driven methodologies result in systems that are limited in their capability to self-modify in response to evolving mission or business needs, brittle and difficult to manage in adapting to new requirements, and expensive to maintain over an entire product life cycle.

Systems engineering methods have to be extended in order to develop collaborative and agile systems throughout a broad set of application domains, including business-structure analysis, value-chain collaboration, and warfare. This paper describes a model-driven approach to systems development that extends traditional systems engineering methods and is well-suited to address the additional systems development concerns we have described.

Systems

A system is a set of resources that is organized to provide services. The services enable the system to fulfill its role in collaboration with other systems to meet some useful purpose. Systems may consist of combinations of hardware, software (including firmware), workers, and data. This definition of systems is extremely general: a product, such as an automobile or a computer, is a system; a business or its components are also systems. Businesses may be organized into larger enterprises that are also systems, e.g., the health-care system.

Systems can be characterized by their attributes, which can be grouped as follows: "Black box" attributes are a system's externally observable characteristics, including the services that it provides. "White box" attributes are the resources that comprise the system. A white-box view is a representation that reveals the internal aspects of the subject under consideration. The system's white-box resources are encapsulated in its black-box services.

Systems development may be thought of as the specification of the black-box attributes of the system (i.e., its requirements) and the delivery of the integrated system components that meet the requirements (i.e., its implementation or realization). An implementation describes how an item is constructed or computed. For example, a class is an implementation of a type; a method is an implementation of an operation.

At a high level, a service is a mechanism by which the needs or wants of the requestor are satisfied. In a given context, the term "service" represents either a service specification or a service implementation, or both. A service specification is the definition of a set of capabilities that fulfill a defined purpose. In model-driven systems development (MDSD), a service specification can be a Systems Modeling Language (SysML (**)) (3) interface. SysML is an adopted extension to the OMG (**) UML (**) (Unified Modeling Language (**)) standard that supports systems engineering. It is to hardware products and systems what UML is to software architecture and systems. To represent today's product embedding both hardware and software, both SysML and UML are used in a common setting. A service implementation realizes the behavior described in the service specification and fulfills the service contract. In MDSD, the service implementation is represented by the logical and physical projections (known as "viewpoints") of the model.

A model is defined as a collection of all the artifacts that describe the system. Generally, model-driven development (MDD) is a technique for addressing complex development challenges by dealing with complexity through abstraction. Using this technique, complex systems are modeled at different levels of specificity. As the development program proceeds, the model undergoes a series of transformations, with each transformation adding levels of specificity and detail. For the development of complex systems, MDSD begins with the black-box specification of the system and, through a rigorous process of transformation, creates a model of the system; this model is ultimately realized with tested and functioning system components.

The classical notion of a black-box and white-box characterization of a system is well-suited to an MDSD approach. The process of starting with an external view of a system's behavior and deriving specifications for the components and their integration in a semantically rigorous framework is achieved by model transformation. As we will describe next, this overall transformation from external view to component specification and integration is decomposed into several sub-transformations that account for multiple sets of engineering concerns.

Systems development approaches

Traditional requirements-driven systems development methods were developed before the Internet era. The purpose of life-cycle reviews in the traditional development environment was to synchronize a program's cost, schedule, and technical baselines in order to review the program in its entirety. Such reviews necessarily relied upon paper documents because of the inability of early information systems to provide electronic reviews of such programs. Hence a practice of paper-oriented life-cycle reviews was built around available technology, and this practice continues to this day.

Technology has changed. Object-oriented software development has led to the development of systems models to characterize complex behaviors. Further, current database and Web technology may be applied to enable new development methods. Effective exploitation of new technologies requires adoption of new processes. In this spirit, this paper describes an MDSD method that replaces traditional requirements-driven systems development methods.

Requirements-driven systems development methods

Requirements-driven systems development methods define requirements early in the life cycle, after which the techniques of functional decomposition are applied to determine the mapping of requirements to system components. At every level of the hierarchy, functional analysis derives requirements, and engineering methods derive measures of effectiveness. Once the requirements are described in sufficient detail, detailed design activities begin. This process is defined in Reference 4 and elsewhere.