Intuitively, model-based development means to use diagrams instead of code. Class or ER diagrams are used for data modeling, State charts or SDL process diagrams abstractly specify behavior. CASE tool vendors often praise their tools to be model-based, by which they mean that their tools are equipped with graphical editors and with generators for code skeletons, for simulation code, or even for production code. However, we do not believe that model-based development should be regarded as the application of “graphical domain-specific languages”. Instead, we see model-based development as a paradigm for system development that besides the use of domain-specific languages includes explicit and operational descriptions of the relevant entities that occur during development in terms of both product and process. These descriptions are captured in dedicated models:
Process models allow the description of development activities. Because of the explicit description, activities are repeatable, undoable and traceable. Activities include low-level tasks like renamings and refactorings, but also higher level domain-specific tasks like the deployment of abstract controller functionalities on a concrete target platform.
Product models contain the entities that are used for the description of the artifact under development and the necessary parts of its environment, as well as the relations between these entities. All activities in the process models are defined in terms of the entities in the product models. We believe that many important problems in industry like the coupling of different tools for different development aspects (e.g., data aspects, behavior aspects, scheduling and resource management aspects) are still unsolved because of a lack of an underlying coherent metaphor. We see explicit product and process models as a remedy to this problem. We provide a rather abstract treatment of our understanding of model-based development. As application domain, we choose that of embedded systems, but the general ideas apply to other domains as well. We argue that model-based development may be used in different processes, agile or rigorous.
The shift from assembler towards higher languages likes C or Ada essentially reduces to the incorporation of abstractions for control flow (like alternative, repetition, exceptions), data descriptions (record or variant types), and program structure (modules) into these higher languages. Middleware (like CORBA, .NET) are further examples of increasingly abstract development. We consider model-based development to be a further step in this direction. It aims at higher levels of domain-specific abstractions as seen, at a low level, in the abstraction step performed in lex. In the field of embedded controllers, the concepts of capsules and connectors of, e.g., the UML-RT are used as well as state machines to describe component behavior. That these abstractions have intuitive graphical descriptions is helpful for acceptance, but not essential for the model concept. Furthermore, in model-based development there is no need to exclusively rely on one particular description technique, or rather the underlying concept. What are the advantages of model-based development? One advantage is independence of a target language: Models can be translated into different languages like C or Ada for implementation. For graphical simulation, other languages are likely better suited. Again, this is in analogy with the abstraction step, or, inversely, compilation of programming languages: C code can be translated into a number of different assembler languages.
The key advantage, however, is that the product model, which subsumes the abstract syntax of a modeling language, restricts the “degrees of freedom” of design in comparison with programming languages. This is akin to modern programming languages that restrict the degrees of freedom of assembler languages by enforcing standard schemes for procedure calls, procedure parameters and control flow. In a similar sense, Java restricts C++ by disallowing, among other things, multiple inheritance. Ada subsets like Ravenscar or SPARK explicitly restrict the power of the language, e.g., in terms of tasks. The reason is that these concepts have proved to yield artifacts that are difficult to master. Model-based development incorporates the aspects of abstraction and restriction in high level languages. This happens not only at the level of the product but also at the level of the process.
Working with possibly executable models not only aims at a better understanding and documentation of requirements, functionality, and design decisions. Models may also be used for generating simulation and production code as well as test cases. We consider the integration of different models at possibly different levels of abstraction as the key to higher quality and efficiency of the process we propose. Integration is concerned with both products and processes, on a horizontal as well as a vertical level.
Horizontally, different aspects have to be integrated. These aspects reflect a separation of concerns by means of abstractions. They deal with concepts like structure, functionality, communication, data types, time, and scheduling. Structural abstractions concern logical as well as technical architectures, and their relationship. Functional abstractions discard details of the actually desired behavior of the system. Communication abstractions allow the developer to postpone decisions for, e.g., hand-shaking and fire-and-forget communications. Data abstractions introduce data types at a level of granularity that increases over time. and helps in building functional, communication, and structural abstractions.
Timing and scheduling abstractions enable the developer to neglect the actual scheduling of components or even abstract away from timing by relying solely on causality in early development phases. Other aspects like security, fault tolerance, or quality-of-service may be considered as well. While these aspects are not entirely orthogonal one from another, thinking in these terms allows a better structuring of systems. Vertically, different levels of abstraction1 for each of the above aspects have to be brought together in a consistent manner. This applies to both integrating different structural abstractions and integrating structure with functionality and communication. Furthermore, different levels of abstractions in all areas have to be interrelated: Refinements of the black box structure have to be documented and validated, and the same is obviously true for functional and data refinements. Since in a sense, possibly informal requirements also constitute abstractions, tool supported requirements tracing is a must for such a model-based process.