From the point of view of the DSM environment, the domain framework consists of everything below the code generator: the hardware, operating system, programming languages and software tools, libraries and any additional components or code on top of these. However, in order to understand the requirements set for the framework to meet the needs of a complete DSM environment, we have to separate the domain-specific parts from the general platform-related parts of the framework.

In many cases the demarcation between the platform and the domain-specific part of the framework remains unclear. For example, the version of Java that the watch example was originally written in did not carry any useful service to handle timed events like alarms. Thus, we implemented such a service ourselves as a part of our domain framework. The more recent versions of Java, however, now do provide a similar mechanism, meaning that it could be part of the platform if the watch implementation only needed to support more recent versions of Java.

Without any deep theoretical discussion about what is the border between framework and platform, we shall use the following definitions here: The platform is considered to include the hardware, operating system (Windows or Linux), C# or Java programming language (with respective libraries) and other additional environments that are in some cases needed to test our generated code (like a browser or MIDP emulator). The domain framework consists of any additional components or code that is required to support code generation on top of this platform. The architecture of the watch domain framework – as defined in this way – is shown in Figure 3-5 (solid line arrows indicate instantiation relationships while dotted line arrows indicate inclusion relationships).

The domain architecture of the watch example consists of three levels. On the lowest level we have those Java classes that are needed to interface with the target platform. The middle level is the core of the framework, providing the basic building blocks for watch models in the form of abstract superclass ‘templates’. The top level then provides the interface of the framework with the models by defining the expected code generation output, which complies with the code and templates provided by the other levels.

There are two kinds of classes on the lowest level of our framework. METime and Alarm were implemented to raise the level of abstraction on the code level by hiding platform complexity. For example, the implementation of alarm services utilizes a fairly complex thread-based Java implementation. To hide this complexity, class Alarm implements a simple service interface for setting and stopping alarms, and all references from the code generator to alarms were defined using this interface. Similarly, METime makes up for the shortcomings of the date and time implementation of the Java version used. During the code generation, when we need to set an alarm or apply an arithmetic operation on a time unit, the code generator produces a simple dispatch call to the services provided by these two classes.

The other classes on the lowest level, AbstractWatchApplet and WatchCanvas, provide us with an important mechanism that insulates the watch architecture from platform-dependent user interface issues. For each supported target platform, there is an individual version of both of these classes and it is their responsibility to ensure that there is only one kind of target template the code generator needs to interface with.

On top of the platform interface and utilizing its services is the core of the framework. The core is responsible for implementing the counterparts for the logical structures presented by the models. The abstract definitions of watch applications, logical watches and displays can be found here (the classes AbstractWatchApplication and AbstractDisplay). When the code generator encounters one of these elements in the models, it creates a concrete subclass of the corresponding abstract class.

Unlike the platform interface or the core levels, the model interface level no longer includes any predefined classes. Instead, it is more like a set of rules or an API of what kind of generator output is expected when concrete subclasses of AbstractWatchApplet, AbstractWatchApplication or AbstractDisplay are created.

Typically a framework is mainly composed of in-house components either already available from previous projects, or specifically made for this purpose.