WHITE PAPER

DOMAIN-SPECIFIC MODELING: 10 TIMES FASTER THAN UML

Ylistönmäentie 31 FIN–40500 Jyväskylä Finland Phone: Fax: E-mail: WWW:

+358 14 4451 400 +358 14 4451 405 [email protected] www.metacase.com

DOMAIN-SPECIFIC MODELING: 10 TIMES FASTER THAN UML Abstract Current development methods are based on the code world, leading to a poor mapping to organizations’ own domains and duplication of effort in problem-solving, design and coding. Developing an in-house, domainspecific method allows faster development, based on models of the product rather than on models of the code. Industrial applications of this approach show remarkable improvements in productivity and training time: up to ten times faster in both cases. In this paper we describe why domain-specific modeling is faster than current development methods and how to build a domain-specific modeling language.

1

INTRODUCTION

It has been recognized for many years that there is a vital difference between an application’s domain and its code (Jackson 1995). These are two different worlds, each with its own language, experts, ways of thinking etc. A finished application forms the intersection between these worlds. The difficult job of the software engineer is to build a bridge between these worlds, at the same time as solving problems in both worlds. Figure 1 shows four different ways in which this bridge building has occurred: how developers have moved from an initial domain idea to a finished product. In all cases the problem has to be solved in domain terms first. In the first two cases this solution was then mapped to the world of the implementation platform and implemented there. The invention of more powerful chips, assemblers, and compilers steadily narrowed the domain-product gap from the right inwards, allowing the final ‘hand-made’ artifacts of the designer to be at a higher and higher level of abstraction. These artifacts could then automatically be transformed into the finished product. The introduction of modeling languages such as UML changed surprisingly little. The problem must still be solved first in domain terms with little or no tool support. This is because UML does not relate directly to the application domain (e.g. mobile phones, e-commerce platforms, point-of-sale systems etc.) but to the implementation, i.e. it visualizes the code. Therefore, the domain solution must be mapped to the core UML models representing the implementation in code, from which in general a relatively small percentage of the finished code can be automatically generated. The developer must then fill in the method bodies by hand: the largest part of the implementation. Thus the developer still has to solve the problem twice: once in

© 2004 MetaCase

1

domain terms (often in his head and on the backs of envelopes), and once in code terms. He still has to perform the mapping from the domain solution to the code solution, now with an extra ‘stepping stone’ of UML — planted firmly near the code

Domain Idea

Solve problem in domain terms

side. In fact, in cases where UML models do not provide adequate mappings to code, the developer must now solve the problem three times!

Finished Product

Map to code, implement

Assembler

Map to code, implement

No map!

Code

Generate, Add bodies Map to UML

UML Model

Domain Model

Generate full code? Often too hard!

Generate calls to components

Components

Figure 1. Moving from domain idea to finished product Primarily from industry, there have been moves towards a way of building software that removes this resource-intensive and error-prone mapping and double (or even triple) problem solving (Seppänen et al. 1996). The ideal is that a developer would be able to develop the solution once only, as a model in domain terms, from which the finished product could be automatically generated. Such an approach has already been seen to work very effectively in a range of situations, most notably in embedded systems and product families. In this paper we first describe how domain-specific methods work and then look at the main experiences from the users of these methods. To achieve our ideal in a given domain, we must provide three things: a modeling language specific to that domain, a tool for building models in that language, and automatic code generation from models in that language to appropriate implementation code. In this paper we will discuss the support offered by a metaCASE tool in creating such languages and tools for visual modeling and code generation.

2

© 2004 MetaCase

2

DOMAIN-SPECIFIC METHODS

In a domain-specific visual modeling language, the models are made up of elements representing things that are part of the domain world, not the code world. The modeling language follows the domain abstractions and semantics, allowing modelers to perceive themselves as working directly with domain concepts. Let’s take a small example. Suppose you manufacture digital wristwatches and your developers make the watch applications, such as stopwatch or world time. Before any new features can be implemented developers must design them in the watch domain. This involves applying the terms and rules of the watch, such as buttons, alarms, display icons, states and user’s actions. The domain-specific method applies these very same concepts directly in the modeling language. An example of such a modeling language is illustrated in Figure 2. The model represents the time setting feature: the actions a user can make by pressing buttons, the display elements blinking, and the actions changing the time1.

Figure 2. Modeling time setting feature

From this example we can make three important observations about domain-specific modeling: 1. It captures the right aspects of the product. As Figure 2 shows all the relevant parts of the time setting feature are captured in the model. The language directs developers to concentrate on the required aspects of the watch (by hiding irrelevant parts).

1

A complete example of this modeling language with 100% code generators (for Java) is available upon request from [email protected].

© 2004 MetaCase

3

2. The solution is developed only once. Domain-specific methods shift the developers’ focus from the code to the required solution. After finding the solution in the domain developers do not necessarily need to think how the solution is implemented. The watch model, for instance, does not include any concepts of a particular programming language, but still provides enough design data for 100% code generation. 3. It applies familiar terminology. There are no extra semantics: if you understand the domain you can understand the designs. This is unlike current methods where team members must first learn new semantics (e.g. UML) in addition to the domain semantics, and then learn how different developers make the mappings between them (and often how the semantics are twisted at one or both ends of the mapping). The above observations show how individual developers’ work changes with methods that fit the domain. For the organization as a whole the use of domain-specific methods leads to several fundamental benefits, as discussed in the next section.

3

BENEFITS OF DOMAIN-SPECIFIC METHODS

Industrial experiences from domain-specific methods consistently show major improvements in productivity, time-to-market responsiveness and training time. In the following we examine the experiences of Nokia (MetaCase 1999), Lucent (Weiss & Lai 1999) and the US Air Force (Kieburtz et al. 1996).

3.1 Nokia Nokia uses a domain-specific method to develop mobile phone software. A domainspecific method was required because “UML and others say nothing about mobile phones” (MetaCase 1999, p2). Developers can encapsulate relevant domainknowledge using this method for visual modeling and code generation in the MetaEdit+ metaCASE tool (for more details see MetaCase 1999). The main benefits, with quotes from the project leader, are listed below. • Order of magnitude productivity gains (10 times): “A module that was expected to take 2 weeks even with the new tool now took 1 day from the start of the design to the finished product”. •

4

Domain-oriented method allowed developers to concentrate on the required functionality, and shifted the focus from code to design.

© 2004 MetaCase

•

Results from code generation more than fulfilled expectations. “In many cases we can generate 100% of the required code. This is a result of innovative method development: domain-oriented metamodels provide the ideal way to link designs to

•

code and to software components.” Training time was significantly reduced. The developers were familiar with the concepts and vocabulary of the method and found it easy to adopt. Similarly, new employees only needed training in the domain, not in coding: “Earlier it took 6 months for a new worker to become productive. Now it takes 2 weeks”.

3.2 Lucent Technologies In Lucent several domain-specific methods have been developed and used. Weiss and Lai (1999) discuss their development and experiences gained in modeling product families; where there is a large amount of similar functionality shared between several products. The experiences reported are based on systems ranging in size from small laboratory-type systems to large industrial applications, like the 5ESS phone switch. The benefits gained from domain-specific methods in Lucent are recognized as: • Productivity improvement of about 3-10 times per domain (and lower development •

costs). Shorter intervals between product releases. The improvement ratios are highly dependent on the domain, but most projects have experienced an interval reduction of four to one.

•

A domain-specific language improves the consistency of behavior across multiple products. It was found economically viable if there are more than 2-4 products (or variants).

3.3 USAF In the US Air Force domain-specific modeling has been compared against best-practice code components. Experiments to compare these development technologies have been made in relation to message specification in the Air Force C3I system. Kieburtz et al. (1996) analyzed the experiments statistically by comparing the variances. More than 130 development tasks, including both initial development and maintenance, were studied. The study highlights the benefits of domain-specific languages: •

3 times better productivity than with code reuse. Developers consistently expended less effort to accomplish tasks.

•

Significantly fewer errors. The acceptance tests found 50% fewer errors from systems built using domain models than from systems built using code components.

© 2004 MetaCase

5

•

The domain-specific approach was noted to give “superior flexibility in handling a greater range of specifications” than with code components. Locating errors was considered easier with a domain-specification language than with code.

•

The domain-specific language hides complexity and implementation details. All developers perceived the domain-specific language to be easier to use and felt completion of development tasks easier to determine.

4

HOW TO BUILD A DOMAIN-SPECIFIC METHOD

Three things are necessary to get to a situation of domain modeling followed by full automatic code generation. Firstly a modeling tool with a domain-specific method, secondly a code generator, and lastly a domain-specific component library. For any realistic chance of being able to achieve these, we need an expert, or a small team of them. This would typically be a good developer who has already developed several products in this domain, developed the architecture behind the product, or has been responsible for forming the component library for the product. Figure 3 shows these three elements that must be made by the expert, along with how they will be used by the normal user. It is important to note that only the expert is required to bridge the gap from the domain to the finished product. Other developers can focus on finding a solution in the domain.

6

© 2004 MetaCase

Done several times before

Domain Idea

Hard to think, Easy to do!

Domain Metamodel

Expert (one)

Normal (many)

Hard to think, Easy to do!

Easy! Domain Model

Finished Product

Easy to think, Easy to do!

Component Code Library Generation

Generate calls to components

Components

Figure 3. Leveraging experts to enable others

4.1 Assembling the component library Starting on the right, the component library is not always necessary, but it makes the task of code generation development significantly easier. Often, code components already exist from earlier development cycles, at least in the form of reusable pieces of code. Further developing these pieces of code into true components is a relatively easy task for the expert, requiring only the normal developer programming tools. In addition to components developed in-house, the library can of course contain third-party components. Whilst the component library here is thus nothing new, the fact that it will be intrinsically part of the development process ensures that the components there will actually be used.

4.2 Developing the domain metamodel A harder task is the development of the domain metamodel; the concepts and notation the end user will build his model with. The experience and intuition of the expert, combined with hints from the component library, domain rules and architecture are the real sources of clues. The expert should also consider the issue of code generation, which will be his next task. A good mapping from the domain metamodel to combinations of components will make that much easier.

© 2004 MetaCase

7

The figures below illustrate the steps for developing a domain modeling language: define concepts, choose domain rules and draw notational symbols. The metamodel elements shown in the figures define parts of the watch-specific modeling language (see Figure 2). 1) Define domain concepts A modeling language should apply those concepts that map accurately to the domain semantics. In this step you enter each domain concept and define its properties: what information can be stored with it. Modeling concepts required in software production (e.g. links to components) can also be added. The example shows the concept of watch state and its properties, such as display function and blinking widgets. This concept is used in modeling the ‘Edit hours’ state in Figure 2. 2) Choose domain rules A modeling language should follow the rules as they exist in the domain. Once defined, the modeling language (enacted by the supporting tool) guarantees that all developers use and follow the same domain rules. These rules are of different kinds and relate to binding concepts, layering models, reusing designs, etc. The figures show the different modeling concepts in terms of relationships, roles and objects and a set of constraints like that only one ‘From’ role may leave each ‘Start’. 3) Draw notational symbols A visual modeling language requires symbol definitions. The watch model in Figure 2 is one example. Notation should illustrate as well as possible the corresponding domain concepts’ natural “visualization”. End-users are often the best people to invent these symbols. The Figure shows the symbol definition for the watch state; its shape, size, color, property values to be shown, etc. Figure 4. Steps for defining the domain metamodel

8

© 2004 MetaCase

In the above example a metaCASE tool is applied to define the metamodel. With a metaCASE environment an expert can define the metamodel (or just part of it) and instantly test it by making an example model. The expert can then concentrate on the challenge of developing the method. A good metaCASE tool can automatically make the finished CASE environment with its menus, toolbars, icons and behavior etc. In fact, a metaCASE environment makes the creation of tool support for the method a simple task, perhaps taking a day or two.

4.3 Developing the code generator The code generation definition forms the final task, conceptually if not chronologically: in practice there will be a large degree of parallelism and iteration between creating the metamodel and developing the code generators. In this step the expert specifies how code can be automatically generated from the structures in the users’ models. Of all the phases, code generation varies the most between domains. In some domains it will be possible to produce a large fraction of code with a relatively simple code generation scripting language. In other domains, it may be necessary to use a more powerful language to operate on data exported from the CASE tool. The most important goal is that the end user should be able to use the code generation simply: the cost of developing the code generation is defrayed over many users. A metaCASE tool should provide the necessary functionality for creating such generation scripts, and should guide the expert where possible by allowing him to reference and use the concepts in the metamodel (see Figure 5). Develop the generators Generators made by experts insulate the domain modelers from implementation aspects: programming details, architecture, component use and even optimization and other compiler flags. The example on the right shows part of the code generation definition: how watch models are used to generate 100% of the required code in Java.

Figure 5. Defining generators

© 2004 MetaCase

9

5

CONCLUSION

Domain-specific modeling languages represent a powerful way to leverage the abilities of expert developers to enable other developers in a team. Previously this was largely only applicable to a small area. However, recent advances in metaCASE technology significantly increase the range of applicability of this approach. In particular, a modern metaCASE environment can markedly reduce the time and effort required to develop a domain-specific method, along with its tool support and code generation. Industrial applications of this approach show remarkable improvements in productivity and training time, up to ten times faster in both cases. The benefits to industry of such an increase in productivity are clear, especially in areas of fast technological development and short product lifespan. In an era of rapid change and high employee turnover, the value of greatly shortened training and induction periods is also very considerable. Domain-specific modeling also provides a better role for expert developers. Rather than have them help others in fire-fighting problems in basic development tasks, or move them to a new area and lose their expertise, they can be put to work on a problem they will find interesting and rewarding, and which will best leverage their expertise.

6

REFERENCES

Kieburtz, R. et al., A Software Engineering Experiment in Software Component Generation, Proceedings of 18th International Conference on Software Engineering, Berlin, IEEE Computer Society Press, March, 1996. Jackson, M.A., Software Requirement & Specifications A lexicon of practice, principles and prejudices Addison Wesley, ACM Press, 1995. MetaCase 1999, Nokia case study, http://www.metacase.com/ Seppänen, V., Kähkönen, A. -M., Oivo, M., Perunka, H., Isomursu, P., Pulli, P., (1996) Strategic Needs and Future Trends of Embedded Software. Technology Development Centre, Technology review 48/96, Sipoo, Finland. Weiss, D., Lai, C. T. R., Software Product-line Engineering, Addison Wesley Longman, 1999.

The trademarks, product and corporate names appearing in this article are the property of their respective owner companies.

10

© 2004 MetaCase