Model-driven prototyping forcorporate software specificationThomas Memmel, Harald Reiterer, Carsten BockAutomotive HCI Lab...
Increasing functionality of automotive Human-Machine-Interfaces (HMIs)causes rising system complexity                     ...
Powerful networked development processes become inappropriate               Participants and means of communication in net...
Today development processes are predominantly paper-based and supportedby heterogenous and proprietary tool landscapes    ...
Current tool landscape leads to time delays in the development process                                                    ...
Three realms with current/potential problems were identified               Information flow                               ...
Central requirements for specification methods/tools                                                      Overall requirem...
Developing appropriate tool support through analysis of developers‘ tasks                                   Layout        ...
Additionally, problem and audience specific views shall be provided                   Rough UI specification              ...
Domain-specific modeling was chosen for tool development due to distinctadvantages                                      Id...
At the beginning domain experts identified essential domain concepts                             Identify domain          ...
Subsequently constraints and graphical notations were modeled                            Identify domain            Add gr...
Visual DSL for specifying content and behavior of driver informations systems                            Model-driven prot...
Code-generator and simulation framework allow early prototyping            Ergonomists   Technical                        ...
Promising approach for coping with technical and organizational complexity                                             Mod...
Thank you very much for your attention                             Questions?                            Model-driven prot...
Upcoming SlideShare
Loading in …5
×

Model-driven prototyping for corporate software specification

972 views

Published on

Model-driven prototyping for corporate software specification

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
972
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Model-driven prototyping for corporate software specification

  1. 1. Model-driven prototyping forcorporate software specificationThomas Memmel, Harald Reiterer, Carsten BockAutomotive HCI Lab, University of Konstanz Dr. Ing. h.c. F. Porsche AG Model-driven prototyping for corporate software specification Page 1 of 16
  2. 2. Increasing functionality of automotive Human-Machine-Interfaces (HMIs)causes rising system complexity Development of automotive Human-Machine-InterfacesFunctionality ?  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. 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. 4. Today development processes are predominantly paper-based and supportedby 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. 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. 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. 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. 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.05Ergonomists 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. 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. 10. Domain-specific modeling was chosen for tool development due to distinctadvantages 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. 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 framework1 Identify domain conceptsExample: 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. 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 framework2 Define domain constraints 3 Add graphical notationDefinition 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. 13. Visual DSL for specifying content and behavior of driver informations systems Model-driven prototyping for corporate software specification Page 13 of 16
  14. 14. Code-generator and simulation framework allow early prototyping Ergonomists Technical Programmers ExpertsDesigners 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. 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. 16. Thank you very much for your attention Questions? Model-driven prototyping for corporate software specification Page 16 of 16

×