AG VLSI Design and Architecture

SFB 501 - Project D1: Application System "Buildings"

PSiGene Pattern-based Simulator Generator

Description

PSiGene is developed as a domain specific, pattern-based modeling and software generation method. The goal is to support the modeling of building simulators by using domain-specific simulation patterns (see /SRZ97/). These patterns have a formal interface and can be bound to a class model describing the simulator's structure. The pattern bindings together with the class model, are sufficient for generation of complete product code for a building simulator.

Although the current application domain is building simulation, we believe that the approach can be applied to other domains as well.

The structure of the generation process using PSiGene is shown in the following figure:

PSiGene overview
This is a context sensitive map. Click on a component to get a detailed description

The following topics give a short overview of our modelling approach. The icons may be clicked to get a more detailed desctiption. Furthermore, some of our publications are on the web for further reading.

PSiGene is embedded in an experimental software engineering environment called MOOSE (Model based Object Oriented Software generation Environment).

The main idea behind MOOSE is support for the development of customized, application specific software systems. This is archieved by combining software component models in a well-defined way and expressing all aspects of a software system with formal models. Code generators are then able to generate all (or most) of the systems and components source code. Because concrete implementations of MOOSE are always targeted towards a concrete application domain, our models can be more specific (and thus express more of the components structure and functionality) than general models.

For PSiGene, we use class diagrams to express the static aspects of a simulation component. These class diagrams are comparable to diagrams used by other OOA/OOD techniques (e.g. UML). Here, they are also used as integration platform for other component models (e.g. interfaces of class libraries are expressed with class diagrams and patterns are bound to elements of such a class diagram).

After setting up or reusing an initial class model, patterns can be bound to it defining the behavior and functionality of the simulation component. Each pattern can be used to solve a typical task or problem that occurs in the simulator. By binding a pattern to objecttypes from a class diagram, the concrete context of the problem solution is specified.

The pattern bindings can be performed with our pattern editor (PEdit). This editor supports a user in finding a fitting pattern and binding it to a given class model. The bindings have types and PEdit enforces that only (syntactical) correct bindings can be performed.
Specifying a class model and applying (i.e. binding) patterns to this model is an iterative task because some structural components may be missing to bind a certain pattern. Therefore, typically some kind of explorative software modelling is performed by alternatetively extending a class model and binding patterns to it.

The patterns available within PSiGene are documented in a pattern catalog. All patterns form a "system of patterns" in the sense that they can work together with other patterns from the catalog in order to perform a specific task. It is very simple to create variants of a given simulator just by exchanging a few of the bound patterns.

Our catalog primarily consists of domain specific patterns that can be used to solve certain simulation problems. With domain specific patterns it is quite easy for a user of PSiGene to model a building simulator (because the patterns are more expressive), and, on the other hand, code generation is possible.

Another set of patterns in the catalog is used to match a specific simulation problem and a specific class model to the interface of the given domain specific patterns. These structural patterns are needed to be able to model a complete simulation component without having to be too restrictive concerning the model structure. As far as code generation is concerned, many structural patterns can be treated as idioms.

A description of the structure of the Pattern Catalog can be found here.

After modeling the simulation component, code generators can be used to automatically create executable (smalltalk-)code. The first generator is MPOK that uses class diagrams as input and generates the complete class structure with access methods ans I/O operations for the specified component.

We call MPOK a "single component generator", because it takes one model as input and creates code implementing this model. This generated code is quite general and can be used by other (manually written or generated) components.

The pattern generator, our second generator, is responsible for implementing the simulators functionality and behavior. It uses the class diagrams, the pattern bindings, and - in the near future - finite state machines as input. Therefore, the pattern generator can be seen as "cross-component-generator" - it takes more than one model as input and generates tailored code. PSiGene uses the additional models as well as the interrelations between these models to tailor and optimize the code to the specific needs of the current application. In addition, manually written code and libraries can be linked with the generated code.

I've compiled a small example of how PSiGene can be used to model and generate building simulators. You are invited to follow this short round trip through software development with PSiGene.

List of Publications

This is an ongoing research project. Because of limited resources (i.e. man power) these pages may not always be up-to-date. For any questions, comments or remarks feel free to contact Jan Peter Riegel.