1

5 Nov 2002

Risto Pohjonen, Juha-Pekka Tolvanen

MetaCase Consulting

AUTOMATED PRODUCTION OF FAMILY MEMBERS:

LESSONS LEARNED

2

Contents

Background Domain-Specific Methods (DSM) DSM architecture Example Lessons learned

3

DomainIdea

FinishedProduct

Sol

ve p

robl

em in

dom

ain

term

sAssembler

Map to code, implement

UML ModelMap to UML

Generate,Add bodies

ComponentsDomainModel

Generate callsto components

No map!

CodeMap to code, implement

Modelling domain vs. modelling code

4

What is domain-specific modelling

Captures domain knowledge (as opposed to code)– Uses domain abstractions

– Applies domain concepts and rules as modelling constructs

– Narrow down the design space

– Focus on single range of products

Lets developers design products using domain termsApply familiar terminologySolve the RIGHT problems!Solve problems only ONCE!

5

About product families studied

Different type of product families, ranging from embedded to financial products

Size of the families vary from a few to more than 200 members Size of development teams ranges from 4 to more than 300 developers

per family Largest product families have over 10 million model elements and

largest DSM languages have about 500 language constructs Some families stable, some others under frequent change Variability in different places, e.g. user interface, hardware settings,

platform services, business rules, communication mechanisms The experiences gathered from domain engineers, architects, tool-

smiths, and from consultants creating DSMs

6

Our focus in the paper

How to build languages and generators for fast variant development based on the results of domain analysis?

DSM environment consists of– Domain-specific modeling language

• operates on domain concepts, not on code• limited variation space

– Domain-specific code generator• generates products described by the models• variation for output formats

– Domain framework• supports code generation• primitive services and components on top of the

platform

DOMAIN-SPECIFIC

MODELLINGLANGUAGE

DOMAIN-SPECIFIC

CODEGENERATOR

DOMAINFRAMEWORK

7

Building languages

Choose among computational models for describing variation– data models, state machine, process models, interaction, flow, etc– often several needed (static/dynamic, high/low level variation)

Use family concepts directly as modeling constructs– already known and used – established semantics exist– natural to operate with– easy to understand and remember– requirements already expressed using them

Keep language independent from implementation code Extend computational models with family rules and

formalize with metamodels

8

Case: Wristwatches product family

Product family– Different watch models: Sport, Kid, Traveler, Diver, Luxery etc.

Common architecture of time-based applications– Time, Timer, LapTime, WorldTime, StopWatch, Alarm, etc.

Family-specific language and generators New models specified with high-level watch concepts

– Alarms, buttons, displays, icons, states, etc.

Code generators to produce 100% implementation in Java from graphical models

9

Variability space Variation space with variation parameters

Variability Description Parameter V1 Time units and icons displayed can vary depending

on the application Displayed Times (0-N) + Displayed Icons (0-N)

V2 Actions applied vary depending on the application [set Time, + Time, - Time, Icon on, Icon off, Alarm on, Alarm off]

V3 The sequential order of accessing applications can vary

Accessing order

V4 Watches can be executed in different OSs [MIDP, Linux, Windows] V5 The number of applications can vary [1..N] V6 Applications can be constructed from other

(sub)applications [0..N]

V7 The number of zones in a display unit can vary [1..4] V8 Unit of time shown in a zone can vary [Hours, Minutes, Seconds,

Hundreds of seconds] V9 The number of icon slots shown in a display unit can

vary [0..4]

V10 Icon label text can vary [Stopwatch, Alarm, World time, Timer]

V11 The number of buttons can vary [2..4] V12 Button label can vary [Up, Down, Mode, Set]

10

Watch architecture and variation

V8

V4

V10

Variation point

V7

V12

V9

V11

V2

V3

V5

V6

V1

All variation allocated– behaviour

– static

11

Sample models (wristwatch)

2 time applications

12

Making generators

Generator translates the computational model into a required output1. crawls through the models

2. extract required information

3. translates it as the code

4. using some output format

Generator should operate directly with domain concepts Keep generator simple Move to generator

– Language syntax

– Output format

13

Modular implementation to manage complexity

Example of the generator

Report '_Roll’

'get'; do ~Set.() {id;}; '().';'roll(METime.'; :Time unit; ', ';if :Up?; = 'T’ then 'true'; else 'false';endif;', displayTime());';

endreport

14

Example: generation of watch applications (continues)

Example of the generator

public Object perform(int methodId) {

switch (methodId) { case a22_2926: getclockOffset().roll(METime.HOUR_OF_DAY, true, displayTime()); return null; case a22_1405: getclockOffset().roll(METime.MINUTE, true, displayTime()); return null; case d22_977: return getclockTime(); } return null;}

Generator output

15

Domain Framework

Raise the level of abstraction on the platform side Achieved by atomic implementations of commonalities and

variabilities Include interface for the code to be generated

– often the only needed part for static variation (e.g. for XML schema)

Often have three layers:– the interface with models by defining the expected code generation

output

– the core implementing the counterparts for the logical structures presented by the models as templates and components for higher-level variability.

– the components and services interfacing with the target platform

16

Watch framework Watch framework provides

– Expected code generation output interface

– Basic building blocks in the form of abstract superclass ’templates’

– Java classes to interface with the target platform

Platform includes: – Hardware and OS

• Windows

• Linux

– Java with AWT

– Emulator

• Browser

• MIDP

17

Example: all together

public void roll(int field, boolean up, METime displayTime){ ...}

Framework primitive

getclockOffset().roll(METime.MINUTE, true, displayTime());...

Generated code

+

DOMAINFRAMEWORK

PRODUCT IDEA

PRODUCTMODEL

PRODUCTCODE

+

DSMCASETOOL

18

Summary

All variation don’t need to be expressed and managed in one place

DSM architecture gives possibilities– model, generator, framework

Domain-specific methods– make a product family explicit– leverage the knowledge of the family to help developers– substantially increase the speed of variant creation– ensure that the family approach is followed de facto

The amount of expert resources needed to build and maintain a DSM does not grow with the size of product family and/or number of developers.

Biggest difficulties are in organizational (e.g. introduction, diffusion) than technical side