Model-driven prototyping for corporate software specification

1. Model-driven prototyping for
corporate software specification
Thomas Memmel, Harald Reiterer, Carsten Bock
Automotive HCI Lab, University of Konstanz Dr. Ing. h.c. F. Porsche AG
Model-driven prototyping for corporate software specification Page 1 of 16

2. Increasing functionality of automotive Human-Machine-Interfaces (HMIs)
causes rising system complexity
Development of automotive Human-Machine-Interfaces
Functionality ?
 Instrument cluster
 Climate control
 Infotainment (Radio, CD,
(Mobile-)Phone, SMS,
E-Mail, Navigation, Voice
control)
…
 Speedo/odometer  Instrument cluster
 Radio  Climate control
 Radio
 Phone
1960 1970 1980 1990 2000 2010 Time
Model-driven prototyping for corporate software specification Page 2 of 16

3. Powerful networked development processes become inappropriate
Participants and means of communication in networked development processes
Manufacturer Supplier
Specification Product features
(Graphical layout) Market analyses
Product
Designer
manager
Requirement Final
Prototypes Programmer Buyer
specification product
Human factors Technical
specialist experts
Interaction concepts Technical
requirements
Media disruption Media disruption
Model-driven prototyping for corporate software specification Page 3 of 16

4. Today development processes are predominantly paper-based and supported
by heterogenous and proprietary tool landscapes
Tool landscape Problems (some Agile Principles & Practice in brackets)
 CASE tools too difficult to understand for non IT-
12 stakeholders (AM: Apply simple models)
10
 Wide-spread static, textual specification of requirements
leads to Ambiguity and chance for misunderstandings
7
6  Insufficient support for early prototyping (AM: Rapid
4 Feedback)
2  Important UI behavior not assessed before coding (AM:
1
Model to understand)
 High risk and notable effort for late changes (AM:
Embrace Change, but early cause of outsourcing!)
 Extra work for developers at manufacturer and supplier
 Low reusability of specification parts
 Very limited possibilities for code generation (AM: Model
with purpose)
 Conversion problems and inconsistencies
Developers use different tools for same
development tasks
Model-driven prototyping for corporate software specification Page 4 of 16

5. Current tool landscape leads to time delays in the development process
High development risk
due to late prototypes
and evaluation
Model-driven prototyping for corporate software specification Page 5 of 16

6. Three realms with current/potential problems were identified
Information flow Database Standardization
 Lack of transparency in decision  No version management/version  Missing mandatory templates
process history
 Different local copies
Ergonomists
Main Main
developers
ANTENNE1 ANTENNE1
Developers, D1-Telefon D1-Telefon
?
programmers 22°C 13:12 22°C 13:12
18.04.05 18.04.05
? Main
ANTENNE1
Designers,
ergonomists ? D1-Telefon
22°C
18.04.05
13:12
Communication problems Changes necessary in late No standardized semantics
development phases
Model-driven prototyping for corporate software specification Page 6 of 16

7. Central requirements for specification methods/tools
Overall requirements
 High problem orientation: Tool support must be extremely problem-oriented such that even non-experts can read
specifications and work with the specific CASE-tool (Prevent overhead and complexity)
 High abstraction level: The specific CASE-tools shall make system specification possible on an appropriate
abstraction level (hide implementation details / show details-on-demand)
 Intuitive notation: Graphical tools shall allow stakeholders to specify a system by means of a familiar graphical
representation - such as illustrated state charts
 Formal specification: Developers shall be enabled to create formal specifications  code generation
 ONE model for specification and simulation
 consistency of specification and prototype
 no additional effort for prototyping due to code generation
 Bridge gaps of understanding due to standardization
 Early verification of specifications (AM: Rapid Feedback)
Model-driven prototyping for corporate software specification Page 7 of 16

8. Developing appropriate tool support through analysis of developers‘ tasks
Layout Content
Main
Menuitem 1
Menuitem 2 ANTENNE1
Menuitem 3
Menuitem 4 D1-Telefon
Menuitem 5
22°C 13:12
Menuitem 6
18.04.05
Ergonomists
Designers
Technical Experts
Behaviour
Main Main
ANTENNE1 ANTENNE1
D1-Telefon D1-Telefon
22°C 13:12 22°C 13:12
18.04.05 18.04.05
Main
ANTENNE1
D1-Telefon
22°C 13:12
18.04.05
Separation of content, layout and
behaviour
Ergonomists Programmers
 Separation of Concerns
Model-driven prototyping for corporate software specification Page 8 of 16

9. Additionally, problem and audience specific views shall be provided
Rough UI specification
Start Zustand 3 Zustand 4
Ergonomen
Designer Zustand2
Programmierer
Technische
Experten
Start Zustand 3 Zustand 4
Detailed UI specification
Zustand 2
Zustand 5
Technical public class PCMSimula
private sta
tion exten
tic final long seri
ds JFrame {
alVersionU ID =
expertsn -75252276
private sta
719366855
tic PCMSi
37L;
mulation instance;
private Has hMap PCMS creenPanel = new Ha
s shMap();
Programmers private JPa nel jCont
//drawing area
entPane = null; // C ontainer for main
private JPa nel scree = null; // Contain
n er for a JFormDesig ner
//screen
private JBu tton jBut ton = null;
public static PCMSimulation getInstance( {return instance;}
)
public HashMap getPCMScreenPanels() {return this.PCMScreenPanels;}
public JPanel getMyJContentPane() {retur this.jC
n ontentPane;}
public PCMSimulation() {
super();
Source code }
this.inst
this.init
/*** This m
ance = th
ialize();
ethod ini
is;
tializes jButton
** @retur javax.s
n wing.JButton */
private JBu tton getJ Button() {
if (jButto == null {
n )
jButton = new JBu tton();
jButton. setBounds(new Recta ngle(520, 269, 208, 127));
...
Different views
Programmers  abstraction
Model-driven prototyping for corporate software specification Page 9 of 16

10. Domain-specific modeling was chosen for tool development due to distinct
advantages
Identify domain Add graphical
concepts notation
(Visual)
1 2 3 4 Domain-specific
Language (DSL)
Define Create code
constraints generator/framework
Pros DSM Cons DSM
 Abstract modeling brings application domain and code closer  Acceptance among users depends on support of graphical,
together interactive specification tools
 Productivity rises with level of abstraction since changes  Creation of graphical editors associated with significant
mainly originate in application domain (e.g. concepts, effort and costs as well as notable development risk
constraints) and not in implementation domain
 DSL reflects ideas and semantics of application domain
 Guiding principles and constraints of application domain can
be incorporated in DSM  (ideally) no invalid /undesirable  Domain-specific CASE
models (=specifications) can be created
tools for tool creation
 Non-programmers are enabled and encouraged to create
specifications
 No need for acquiring knowledge in new language(s)
Model-driven prototyping for corporate software specification Page 10 of 16

11. At the beginning domain experts identified essential domain concepts
Identify domain Add graphical
concepts notation
Visual domain
1 2 3 4 specific language (DSL)
Define domain Create code generator/
constraints framework
1 Identify domain concepts
Example: Development of a meta-model for modelling the Porsche Communication Management (PCM):
A) Objects: B) Relationships:
 MAIN screen  Push/rotary knobs
 Screen with menuitems right  Primary keys (main keys)
 Screen with menuitems right + left  Secondary keys (SOS,
Eject,…)
 Set-key
 Numeric keys
 Phone keys
 Audio keys
Model-driven prototyping for corporate software specification Page 11 of 16

12. Subsequently constraints and graphical notations were modeled
Identify domain Add graphical
concepts notation
Visual domain
1 2 3 4 specific language (DSL)
Define domain Create code generator/
constraints framework
2 Define domain constraints 3 Add graphical notation
Definition of modeling rules, e.g.: Provide intuitive visual representation for domain concepts
 Only one connection (=transition) is allowed between a  Schematic symbols for menu screens and keys
menu item and a subsequent menu screen for a specific
event (e.g. Left push/rotary knob pressed) Menu screen, items right + left
Sub menuitem 1 Menuitem 1 Numeric key
Menuitem 1
Menuitem 2 DDS left pressed Sub menuitem 2 Menuitem 2
Menuitem 3 Sub menuitem 3 Menuitem 3
Menuitem 4 Sub menuitem 4 Menuitem 4
Subsequent Sub menuitem 5 Menuitem 5 Push/rotary
Menuitem 5
Menuitem 6 menu screen Sub menuitem 6 Menuitem 6 knob
Model-driven prototyping for corporate software specification Page 12 of 16

13. Visual DSL for specifying content and behavior of driver informations systems
Model-driven prototyping for corporate software specification Page 13 of 16

14. Code-generator and simulation framework allow early prototyping
Ergonomists Technical Programmers
Experts
Designers Ergonomists Ergonomists
GUI-Builder: Domain-specific Domain-specific
Layout CASE-tool: CASE-tool:
Content Behaviour
Main Main
generate ANTENNE1
D1-Telefon
ANTENNE1
D1-Telefon
22°C 13:12 22°C 13:12
18.04.05 18.04.05
Main
ANTENNE1
D1-Telefon
22°C 13:12
18.04.05
Formal specification Formal specification Formal specification
XML XML XML
DDS left DDS right
DDS right
Interactive prototype
Code generator Living specification
Simulation framework
Model-driven prototyping for corporate software specification Page 14 of 16

15. Promising approach for coping with technical and organizational complexity
Model-driven development: advantages and potentials
 More flexibility when choosing suppliers
 Standardization (e.g. of cooperation with suppliers)
 Suppliers can serve with a standardized development
process
 Avoid duplicate work at OEMs and suppliers
 Simulations are available significantly earlier
 Conceptual problems are recognized earlier in
development process
 Less effort for late changes due to frontloading
 Disciplines are bridged due to common modeling
approach
 Paper-based specifications become substituted by living
specifications
Model-driven prototyping for corporate software specification Page 15 of 16

16. Thank you very much for your attention
Questions?
Model-driven prototyping for corporate software specification Page 16 of 16