Up Previous Next Title Page Contents

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.

Up Previous Next Title Page Contents