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.

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.

As we wanted our watch models to be able to run on any desktop, we have chosen C# and Java as the implementation languages. We have also provided integration with their respective IDEs, Visual Studio and Eclipse.

If you are more interested in C, a more common choice for embedded software but harder for users to set up from scratch, please bear with us and other readers through this example! When you have completed it, you can look at the high-level C generator we have included in WatchApplication.

A domain-specific framework of classes was established as a bridge between the code generator and the runtime environment. 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 framework can be extended or ported with minor effort to support other runtime environments close to the original ones, e.g. Windows Phone for C#, or Android and MIDP for Java.

For the record, the whole project of designing and implementing the first working version of the Watch modeling language with its Java generator and 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.