AG VLSI Design and Architecture

SFB 501 - Project D1: Application System "Buildings"

As usual: Page under construction!

Description

MOOSE (Model-based Object-oriented Software generation Environment) is a framework for software development based on formal models and code generation principles. Within MOOSE, an application consists of several components. Each component is modeled with one or more component models. The set of all component models forms the application model. Code generators are used to create the component code from the models. Reuse within MOOSE takes place on the modelling level as new application models are derived from base models which describe common characteristics of the application domain. Base models can therefore be seen as reusable templates for a concrete application domain. Furthermore, MOOSE supports component reuse (by the code generators, which act as generic components) as well as 'traditional' code reuse (e.g. libraries).

While the idea behind MOOSE is pretty general, every concrete implementation in terms of base models, editors, and generators depends on a particular application domain. We are therefore able to choose powerful, domain specific model semantics and to support code generation to a large extent.

MOOSE was initially developed for another application: for the generation of components for large electronic CAD frameworks (like e.g. PLAYOUT). Along with new application domains, we adapted MOOSE to serve these new domains, too. MOOSE has successfully been used for about twenty projects in three different application domains.

The current structure of MOOSE is shown in the following figure:

MOOSE consists of a large central database, where the models of applications (base models and derived application models) are stored. Models are entered via a set of editors for different model types. At the moment (and for the domain of reactive systems), we support class diagrams (extended Entity-Relationship diagrams), a variant of Design Patterns (see PSiGene), and we are about to implement finite state machines. The models are interpreted by a set of code generators, which produce the final application code. We have generators for abstract datatypes (class hierarchies, access functions, etc.) for C/C++/Smalltalk, for building simulation, and some others. Libraries, which are linked to the final application, are also available on the modelling level, e.g. as EER models representing their class structure. Because we can not generate ALL of the code, we allow the user to add additonal source code, e.g. to add algorithms to the code which can not be expressed by the supported model types.

The following figure shows the simplified design data flow for MOOSE:

The data flow is linked to the major phases of software development. Please note, however, that this is not a process model: it shows the data flow between MOOSE's components, but it does not show the order of tool executions or cycles in the development process.

The application domain (reactive systems for this project) influences the notations used for the models (in other words: it determines the model types), and it influences the semantics of the modelling primitives by determining the primitive functions which are in turn used by the code generator for the creation of source code. The application system (in this case building automation) influences the base model, which represents such models shared by most applications. An individual application is developed by analysing the problem statement carefully and determining the characteristics of the problem at hand, i.e. by finding the 'deltas' between the base model and the models the application needs, thereby reusing the information from the base model. During the design phase, the editors and the database are used to create the application model from the base model and the application charcteristics. This model is then fed into a set of generators which create source code for the different components of the application.This code can be combined with hand written parts and compiled and linked with other libraries needed, e.g. a real time kernel. The result is the executable for the application.

Current limitations:

• The database needs improvement to make the derivation of application models more convenient.
• For most applications and domains, we can not generate all source code. There are allways parts of an application which are inherently difficult to define with formal models on an abstract basis. For example, we don't know a better technique to define an arbitrary algorithm with other 'models' than a piece of code (of course, there are exceptions like software elements which can be defined with finite state machines or design patterns). So we do not generate code for these parts. A counterexample for this limitation is the PSiGene project (an implementation of MOOSE designed to support the development of real time building simulators), where we are able to generate complete applications for a very narrow and well defined domain.

More information on MOOSE can be found in the publication(s) mentioned below.

Recent Publications (generated document)

page designed by eau

Temporary maintenance by Martin Schuetze (schuetze@informatik.uni-kl.de)