1.2 The Development of the Watch Example
The development of the watch example closely resembles the
implementation of any DSM environment. In a venture of this kind there are
always three related entities: the problem domain, the target platform and the
DSM environment as a bridge between them. As the domain and target platform are
the parts that already exist, the task in making a DSM environment is to find
their key entities and then define mappings between them.
For this example, we needed a domain that we knew well
enough ourselves and that could be easily understood by developers from
different domains. The domain chosen was digital watches, in particular a family
of related wristwatch models. The DSM environment should allow development of
watches by modeling them and then automatically generate fully functional watch
applications directly from the models.
As the domain in this case is still quite simple, finding
the key domain concepts was fairly easy. A digital watch can be divided into a
physical display unit, and a logical watch specifying the behavior. The display
unit defines the widget and button configuration for the watch. The display
widgets are either icons that indicate whether or not a service (like alarm) is
activated, or two-digit display zones that can show basic time units like hours,
minutes or seconds. The logical watch application defines the required
functionality as a set of sub-applications like an alarm and a stopwatch.
Breaking the watch apart in this way results in very good
reusability. As sub-applications, logical applications and displays can be
defined separately from each other and they communicate via pre-defined
interfaces, they make natural components. This enables the developer to build
new watch variants quickly by combining sub-applications into new logical watch
applications and then combining these with displays (new or existing). This idea
of watch configuration is illustrated in
Figure 1-1.
Figure 1-1. A watch configuration
In real life the platform
in this case would be an electronic device controlled by a microchip. For an
example that anyone could run this is of course not a viable option. Instead, we
aimed for a test environment in which we can execute the generated code and test
the functionality of a watch, as it would appear in the final product. Such a
test environment would in any case be a common element in software development
of this kind.
We decided to base the modeling language for the watch
applications on state machines, which are a traditional way to model embedded
software. We did, however, significantly extend the state machines semantically
to achieve better expressive power for our purposes. With these extensions, the
finite state machines describe the whole application logic, making it possible
to generate 100% of the code for the watch implementation.
The watch modeling language itself consists of two diagram
types. First there is a WatchFamily diagram that describes the models in the
watch family. It also describes the displays and logical watch applications that
have been used to create the models. The logical watch applications and
sub-applications have been described with WatchApplication diagrams that define
the state machine implementation for each application. WatchApplication diagrams
are actually extended state transition diagrams with customized semantics and
domain-specific additions, which enable the use of such domain-specific concepts
as buttons and alarms. An example of a WatchApplication diagram is shown in
Figure 1-2.
Figure 1-2. An example of a WatchApplication diagram.
As we
wanted our test environment to run on any desktop, Java was chosen as the
implementation language. If you are more interested in C, a more common choice
for embedded software, please bear with us and other readers through this
example! When you have completed it, you can look at the minimal C generator we
have included in WatchApplication.
A domain-specific framework of Java classes was
established in addition to the standard Java runtime. This framework is the same
for all watches made in this way, and provides the user interface and the
abstract superclasses for displays and state machines. The code generator was
then implemented to take advantage of these component, for instance by creating
subclasses of them.
For the record, the whole project of designing and
implementing the first working version of the Watch modeling language with one
complete watch model took eight man-days for a team of two developers. Neither
developer had prior experience of Java programming, or of building watch
software, and there were of course no pre-existing in-house watch components. It
took five days to develop the Java framework, two days for the modeling
language, and one day for the code generator. These times include design,
implementation, testing and basic documentation. Since then, new watch models
have been implemented in fifteen minutes with this environment. As we estimated
that it would have taken five to six days to develop the first watch model
manually, and then one day for each additional watch model, it is fair to assume
that the third watch model completed the development effort payback.