AG VLSI Design and Architecture

SFB 501 - Project D1: Application System "Buildings"

PSiGene's Pattern Catalog

Description

We have developed a Pattern Catalog to be used within PSiGene. Our patterns form a "System of Patterns" in the sense, that all patterns can work together to model a complete building simulator (see /BMR96/ and below).

Before you start to examine the catalog, one warning: As we are actively working on PSiGene, the catalog is far from being complete or consistent. You'll find patterns we use a lot as well as out-of-date, redundant patterns and patterns in their early stages, which are not yet suitable for modelling.

The pattern catalog has been gained from a set of prototypical buyilding simulators. It is divided into three categories dealing with different views of the application. These categories are: behavior, flow of control, and structural adaptation (see table 1).

Pattern Catalog
Framework Structural Adaption	Primitive	VariableValue
		BufferedValue
		...
	Indirection	FollowRelation
		Traversal
		...
	Redirection	MethodBranch
		MethodAlias
		...
Software Architecture	Creational	Singleton
	Dataflow	Pipe
		Filter
		...
	Distribution	AttributeProxy
...
Simulation Control	Control	Observer
		ContinuousComputation
		...
	State Machines	StateMachine
		...
User Interface	Display	DisplayAttribute
		DisplaySlider
		...
Domain-Speific	Simulation	ThermalMass
		ThermalJunction
		...
	Control-System	GenericControl
		PIDControl
		...
	Sensors and Actuators	SensuatorServer
		SensuatorClient
		BinarySensorServer
		...

Table 1: Structure of the Pattern Catalog

Patterns in the Behavior category contain algorithms and methodologies describing an object's behavior. In particular, patterns for the calculation and visualization of physical effects are included. Examples of physical effects patterns are ThermalMass and ThermalJunction that deal with the simulation of temperatures which are affected by heat flows.
Patterns from the category Flow Of Control are used to control the simulator. These patterns, like ContinuousComputation or ActuatorServer, describe parts of the component architecture: using different patterns from this category may result in different types of object communication like event-triggered or method calls. These patterns usually work together with our simulator kernel library. The patterns are aware of the interface of that library and therefore the library can be used on the modelling level. On the other hand, only the library's interface has to be known - the actual implementation can vary (e.g., real-time simulation vs. time-warp).
The last category of our pattern catalog contains patterns that are needed to adapt the class structure of the simulator's application model to specific needs. For example, to simulate a room's temperature, it somehow has to be known which heat flows affect that room. If this information cannot be obtained locally in the class Room, some kind of delegation mechanism must be used in order to import data from other objects. Our FollowRelation pattern can be used to specify simple delegations. More complex delegations are handled with the pattern Traversal. Structural adaptation patterns are the key part to match a component's structure (e.g. the class model) to blocks (simulation patterns or libraries) that expect a slightly different structure. This leads to "structure shy programming" (see /Lie96/) where the structure (described in class models) is only loosely coupled with the behavior.
Although our pattern catalog is intended to be domain specific, many of our patterns can be used in other domains as well, or are specializations of patterns found in other (more abstract) catalogs. The patterns and the catalog form a pattern system (see /BMR96/): each pattern provides just a partial solution to the simulation problem. In order to form a working simulator, all patterns must work together (e.g. ThermalMass must cooperate with ThermalJunction, Thermal Exchange, and ContinuousComputation). This collaboration is obtained as follows: first, all patterns are able to work together with certain other patterns by construction. Second, the formal interface definition of the patterns is used to ensure that all bindings are complete and correct.