1 5 Nov 2002 Risto Pohjonen, Juha-Pekka Tolvanen MetaCase Consulting AUTOMATED PRODUCTION OF FAMILY...
-
Upload
paula-wilkins -
Category
Documents
-
view
213 -
download
0
Transcript of 1 5 Nov 2002 Risto Pohjonen, Juha-Pekka Tolvanen MetaCase Consulting AUTOMATED PRODUCTION OF FAMILY...
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