6 th OOPSLA Workshop on Domain-Specific Modeling /10/221 The Practice of Deploying DSM Report from a Japanese Appliance Maker Trenches Laurent Safa

6 th OOPSLA Workshop on Domain-Specific Modeling /10/222 Today’s Menu Software Modeling at MEW Tool & Scope More Scope: HA Domain DSM Challenges Proposed Solutions DSM and Cognitive Dimensions Question to the Workshop

6 th OOPSLA Workshop on Domain-Specific Modeling /10/223 Software Modeling at MEW We see modeling and code generation as a way to significantly reduce human-factor in embedded software Traditional development Modeling Tool Model-driven Development Embedded application Practitioner Embedded application useproduce write human factor Stop Human-Factor Safe Software Software Risk Tool maker

6 th OOPSLA Workshop on Domain-Specific Modeling /10/224 Application Requirements Tool & Scope Find solution Hardware OS Middleware Hardware OS Middleware Framework App Deploy solution Framework Application New technology First-of-a-kind application Pass-over to Product Division Technical Creativity Problem solving Functional Creativity Solution variations Classic Software Engineering Software Process Improvement Domain-Specific Modeling

6 th OOPSLA Workshop on Domain-Specific Modeling /10/225 More Scope: HA Domain BudgetKLOC Total Software Production Cost Software Development 50% BSP 5% Middleware 20% Framework 10% Application 15% Quality Assurance 50% DSM Productivity x10 +14% Estimate improvement Untapped Potentially Huge Savings 50% DSM ? Today Next

6 th OOPSLA Workshop on Domain-Specific Modeling /10/226 DSM Challenges Framework 1 Framework 2 Traditional Environment is Fluid Modeling Tool 1 Model-driven Development is Viscose Embedded software Practitioner Embedded software write “C” Tool maker Framework 3 Embedded software Modeling Tool 2 Modeling Tool 3 Practitioner Many languages to master Many tools to maintain New (expensive) practitioner New tool to use What happens to me? Who’s the tool user anyway?

6 th OOPSLA Workshop on Domain-Specific Modeling /10/227 Proposed Solutions Framework 1 Framework 2 Traditional Environment is Fluid Modeling Tool 1 Model-driven Development is Viscose Embedded software Practitioner Embedded software write “C” Tool maker Framework 3 Embedded software Modeling Tool 2 Modeling Tool 3 Practitioner Family of similar languages Test-driven metamodeling Configurable metamodeling tool (DSM tool’s toolkit) HCI Present DSM as a pain-killer Focus on creative developments Problem-based user selection

6 th OOPSLA Workshop on Domain-Specific Modeling /10/228 DSLs and Cognitive Dimensions DimensionProblem in terms of DSLProposed solution Viscosity1.Small changes in a graph-based model require cumbersome operation to modify the model layout 1.Constrained graph editor Auto-layout Hidden dependencies 2.A model made of multiple views is broken after a concept name is changed in one view but not updated in the others 3.Generated code does not compile after the target framework has been modified 2.Model refactoring Only-one-view DSL 3. Automated DSL test Premature commitment 4.The model need to be complete before the practitioner can try it (generate & run) 4.Convention over configuration, default values, special values undefined and unknown Abstraction barrier 5.The practitioner must master many abstractions before being able to write interesting models 6.Default behaviors Small concept categories Secondary notation 6.The practitioner cannot express or try new ideas with the DSL tool 6.Escape semantics Visibility7.The model is fragmented into many views which makes finding information difficult 7.Only-one-view DSL

6 th OOPSLA Workshop on Domain-Specific Modeling /10/229 Question to the Workshop What are other approaches to 1.Foster usability 2.Sustain deployment 3.Reduce initial cost of DSM tools? Knowing 1.To foster usability we do escape semantics, convention over configuration, unknown, only-one- view DSL, default behaviors 2.To sustain deployment we do test-driven metamodeling 3.To Reduce initial cost we use a configurable modeling tool

6 th OOPSLA Workshop on Domain-Specific Modeling /10/2210 More from the paper…

6 th OOPSLA Workshop on Domain-Specific Modeling /10/2211 DSM Capsule Software Engineering Framework DSM capsule Product Variations Market Evolution Marketing Technologist domain Product domain “classic” design and modeling C D E

6 th OOPSLA Workshop on Domain-Specific Modeling /10/2212 DSM Development Life Cycle Software Engineering Domain-Specific Modeling Metamodeling ResearchNew Product Product Variations Product Line Software Engineering Product Line Development Only Once Development Simulink, etc... C D E

6 th OOPSLA Workshop on Domain-Specific Modeling /10/2213 Metamodeling Delay Tomorrow’s tool Today’s practices Yesterday’ s practices Today’s tool Well-known problem range lower value New problem range higher value Metamodeling delay Escape semantics bridge the gap

6 th OOPSLA Workshop on Domain-Specific Modeling /10/2214 Escape Semantics tu : bit dimmer : integer [0..127] dimmer : integer [0..127] group : bit patter n Union by: A. Tanaka (2006/01/25 16h30) With Full2Way, the address space from 0 to 255 is shared between “tu” and “dimmer” equipment. Each address within that space can be either bit or integer[0..127]. The selection can be changed at run-time by loading a new configuration file. Lighting equipment Full2Way

6 th OOPSLA Workshop on Domain-Specific Modeling /10/2215 Testing DSLs appli. source appli. model meta model input expected output actual output modeling tool build system test management system executable product test result framework