3.4 The Domain Framework
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), Java programming language with AWT classes and environment
to test our generated code (either 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
Figure 3-5. The watch domain framework
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.