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 Domain Idea Finished Product Solve problem in domain terms Assembler Map to code, implement UML Model Map to UML Generate, Add bodies Components Domain Model Generate calls to components No map! Code Map 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 terms  Apply familiar terminology  Solve 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 MODELLING LANGUAGE DOMAIN- SPECIFIC CODE GENERATOR DOMAIN FRAMEWORK

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

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 output 1.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 + DOMAIN FRAMEWORK PRODUCT IDEA PRODUCT MODEL PRODUCT CODE + DSM CASE TOOL

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