Sioux Hot-or-Not: Model Driven Software Development (Markus Voelter)


Published on

Sioux Hot-or-Not Model 6 september 2007, Driven Software Development met Markus Voelter

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Sioux Hot-or-Not: Model Driven Software Development (Markus Voelter)

    1. 1. - - Markus Völter [email_address] Model-Driven Software Development Hot or Not?
    2. 2. About me - - Markus Völter [email_address]
    3. 3. About me - - Markus Völter [email_address] I work as an independent consultant/coach/trainer…
    4. 4. About me - - Markus Völter [email_address] <ul><li>… for software technology and engineering … </li></ul>
    5. 5. About me - - Markus Völter [email_address] <ul><li>… I focus on software architecture, … </li></ul>
    6. 6. About me - - Markus Völter [email_address] <ul><li>… middleware, … </li></ul>
    7. 7. About me - - Markus Völter [email_address] <ul><li>… and model-driven software development. </li></ul>
    8. 8. About me - - Markus Völter [email_address] <ul><li>I have written a number of books… </li></ul>
    9. 9. About me - - Markus Völter [email_address] <ul><li>… regularly speak on conferences … </li></ul>
    10. 10. About me - - Markus Völter [email_address] <ul><li>… and I am an comitter for </li></ul><ul><li>openArchitectureWare </li></ul>
    11. 11. About me - - Markus Völter [email_address] <ul><li>I am also founder and editor of software engineering radio </li></ul>
    12. 12. About me - - Markus Völter [email_address] <ul><li>More information is available at… </li></ul>
    13. 13. About me - - Markus Völter [email_address] <ul><li>and on my blog at </li></ul>
    14. 14. About me - - Markus Völter [email_address] <ul><li>I am based in Heidenheim, Germany </li></ul>
    15. 15. About me - - Markus Völter [email_address] <ul><li>And in my spare time I fly my glider… </li></ul>
    16. 16. C O N T E N T S <ul><li>Part 1: Theory </li></ul><ul><li>Part 2: Practice </li></ul><ul><li>Part 3: Q&A </li></ul>- -
    17. 17. Model-Driven Development <ul><li>Model Driven Development is about making software development more domain-related as opposed to computing related . It is also about making software development in a certain domain more efficient . </li></ul>- -
    18. 18. How MDSD works <ul><li>Developer develops model(s) based on certain metamodel(s), expressed using a DSL. </li></ul><ul><li>Using code generation templates , the model is transformed to executable code. </li></ul><ul><ul><li>Alternative: Interpretation </li></ul></ul><ul><li>Optionally, the generated code is merged with manually written code. </li></ul><ul><li>One or more model-to-model transformation steps may precede code generation. </li></ul>- -
    19. 19. Reasons for DDD <ul><li>Software Development is too complex and too expensive (now, this is a really new finding  ) … … because: </li></ul><ul><ul><li>There is too little reuse </li></ul></ul><ul><ul><li>Technology changes faster than developers can learn </li></ul></ul><ul><ul><li>Knowledge and practices are hardly captured explicitly and made available for reuse </li></ul></ul><ul><ul><li>Domain experts cannot understand all the technology stuff involved in software development </li></ul></ul><ul><li>DDD aims at attacking some of these problems. We shall see how on the following slides. </li></ul>- -
    20. 20. What is a „Domain“ <ul><li>A definition could be: A domain is a bounded area of knowledge or interest. </li></ul><ul><li>Examples (from the world of Software) include: </li></ul><ul><ul><li>eBanking </li></ul></ul><ul><ul><li>Embedded Software </li></ul></ul><ul><ul><li>Web-Based eBusiness Applications </li></ul></ul><ul><ul><li>Control Software for 4-Cylinder Diesel Engines </li></ul></ul><ul><ul><li>Astronomical Image Processing Software </li></ul></ul><ul><li>Domains can have varios „ scopes “ as well as various „ flavours “ – see next slides. </li></ul>- -
    21. 21. MDSD Core Concepts - - Model Domain Specific Language Metamodel textual graphical Domain Ontology bounded area of knowlege/interest semantics precise/ executable multiple partial viewpoint subdomains composable Metametamodel target software architecture software architecture transform compile interpret multi-step single-step no roundtrip knowledge several design expertise
    22. 22. Example 1: Model and Metamodel - - interface Sensor { operation start():void; operation stop():void; operation measure():float; } interface Controller { operation reportProblem(Sensor s, String errorDesc ):void; }
    23. 23. Example 2: Model (J2ME apps) - -
    24. 24. Example 2: Metamodel (J2ME apps) - -
    25. 25. Example 5: Power Grid - -
    26. 26. Example 5: Power Grid Metamodel - -
    27. 27. MDSD Core Values <ul><li>We prefer to validate software-under-construction over validating software requirements </li></ul><ul><li>We work with domain-specific assets , which can be anything from models, components, frameworks, generators, to languages and techniques. </li></ul><ul><li>We strive to automate software construction from domain models; therefore we consciously distinguish between building software factories and building software applications </li></ul><ul><li>We support the emergence of supply chains for software development , which implies domain-specific specialization and enables mass customization </li></ul>- -
    28. 28. MDA and Model Driven Software Development Overview <ul><li>Focus: Platform Independence, (Tool) Interop </li></ul>- - Model Domain Specific Language Metamodel textual graphical Domain Ontology bounded area of knowlege/interest semantics precise/ executable multiple partial viewpoint subdomains composable Metametamodel transform compile interpret multi - step single-step no roundtrip UML+ Profiles MOF OCL, Action Semantics PIM, PSM, .... QVT several target software architecture software architecture Application design expertise
    29. 29. Other related approaches <ul><li>Microsoft’s Software Factories: Focus on Reuse, Efficient Development, DSLs </li></ul><ul><li>Domain-Specific (Visual) Modelling: Focus on (Visual) DSLs </li></ul><ul><li>Generative Programming: Focus on Efficiency, “Automatic Manufactoring”, Software System Families </li></ul><ul><li>Language-Oriented Programming: Focus on DSLs instead of Frameworks, incl. Editor/Debugger Support </li></ul>- -  all basically the same 
    30. 30. MDSD and Agility <ul><li>Agile Manifesto: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. </li></ul><ul><li>MDSD-Models are no „paperwork “, they are the code which is translated to code automatically </li></ul><ul><li>Agility does not oppose tools in general – compilers are ok, model transformers are a kind of compiler </li></ul>- -
    31. 31. MDSD and Agility II <ul><li>Project automation (ant, cruisecontrol) is ok in „agile minds“, so is automation of the writing of repetitive code </li></ul><ul><li>Automation of the development process makes responding to change easier and faster (single source principle). </li></ul><ul><ul><li>Changes in the model respond to changes in the functional requirements </li></ul></ul><ul><ul><li>Changes in the templates/transformations can be used to evolve the architecture </li></ul></ul><ul><li>The customer on-site can be integrated better , if we have languages that are better related to domain concepts as opposed to 3GL code or the like. </li></ul><ul><ul><li>Pair programming between developer and domain expert is more realistic. </li></ul></ul>- -
    32. 32. MDSD and Agility III <ul><li>Tests can still be written manually (even before generation), generators can help is building mocks or scenarios </li></ul><ul><li>We do not recommend a waterfall that first builds generators and then builds apps, rather, both are iteratively evolved in parallel. </li></ul><ul><ul><li>Domains Architectures are based on experience , not based on „big design upfront“ </li></ul></ul><ul><li>Developers can do what they can do best: </li></ul><ul><ul><li>Some deal with applications and customer requirements, </li></ul></ul><ul><ul><li>Others deal with technical architecture, platforms and generators </li></ul></ul><ul><li>So: There is no problem with Agility and MDSD! </li></ul>- -
    33. 33. Reasons for using MDSD <ul><ul><li>You want to provide a way for your domain-experts to formally specify their knowledge , and to provide a way for your technology people to define how this is implemented (using model transformations). </li></ul></ul><ul><ul><li>You might want to provide different implementations (i.e. more concrete models) for the same model , perhaps because you want to run it on different platforms (.NET, Java, CORBA). </li></ul></ul><ul><ul><li>You may want to capture knowledge about the domain, the technology, and their mapping in a clear, uncluttered format. </li></ul></ul><ul><ul><li>In general, you don’t want to bother with implementation details when specifying your functionality. </li></ul></ul><ul><ul><li>MDSD results in a fan-out , i.e. one set of models can be the source for transformations to several targets. </li></ul></ul><ul><ul><li>Another reason for using MDSD: You are working in the context of product lines and software system families and need to develop domain-specific assets. </li></ul></ul>- -
    34. 34. MDSD Benefits I <ul><li>Models are free of implementation artifacts – they directly represent domain knowledge and are thus reusable. </li></ul><ul><li>Implementations for various platforms can be generated in principle – the technology change problem is adressed to some extend. </li></ul><ul><li>Technology freaks and domain experts can take care of „their business“ (transformations and models, respectively) and need to care of each other‘s problems only in a limited way. </li></ul><ul><li>Domain experts can play a direct role in development since they can more easily understand models expressed with a DSL as opposed to implementation code.  Domain Experts play the central role they deserve! </li></ul>- -
    35. 35. MDSD Benefits II <ul><li>Development becomes more efficient since repetitive implementation code can be generated automatically. </li></ul><ul><li>Architectural contraints/rules/patterns can more easily be enforced , since the they are embedded in the templates rather than just being documented (and ignored). This is especially important in really large teams, often in the context of Product-Line Engineering and Software System Families. </li></ul><ul><li>Transformer/Generator can address cross-cutting concerns (just like an aspect weaver) </li></ul>- -
    36. 36. MDSD Predjudices <ul><li>MDSD does not require UML – any kind of modelling language is ok, graphical or textual </li></ul><ul><li>Precise and complete models… </li></ul><ul><ul><li>… are not the the same as „visualized code“ – the abstraction level is higher </li></ul></ul><ul><ul><li>… are not the same as analysis models – analysis models are not computational </li></ul></ul><ul><li>MDSD does not require – not even recommend – a waterfall. Development of the generative infrastructure is iterative and incremental. </li></ul><ul><li>You do not need big and expensive tools – a lot of small and useful open source tools are available. </li></ul><ul><li>You don‘t need to generate 100% of the code – it is ok, to also code some aspects in a 3GL. </li></ul>- -
    37. 37. Benefits for Software Quality <ul><li>MDSD requires an explicit, well-defined architecture. Defining an architecture this way improves the quality of the system (indpendent of whether it is generated or not). </li></ul><ul><li>Transformations capture expert knowledge. The generated code reflects this expert knowledge uniformly. </li></ul><ul><li>An Domain Archtitecture defines a strict programming model for the manually developed parts – again, uniformity and constrained-ness improves quality. </li></ul><ul><li>Generator does not produce accidental errors – either things are always right or always wrong. This makes finding errors easier! </li></ul><ul><li>Models can serve as an up-to-date and always current documentation . </li></ul>- -
    38. 38. Benefits for Software Quality II <ul><li>In general, MDSD forces you to take care of many good things, which you‘d like to have in any application development project: </li></ul><ul><ul><li>Domain/Application Scoping </li></ul></ul><ul><ul><li>Variability Management </li></ul></ul><ul><ul><li>Well-Defined Software Architecture, Architecture Metamodelling </li></ul></ul><ul><ul><li>Trying to build a generator for a domain/target architecture enables your understanding of the domain/target architecture. This in itself is a huge benefit. </li></ul></ul>- -
    39. 39. No Free Lunch - Challenges <ul><li>You need additional skills in your team (domain analysis , metamodelling, generator development, architecture)  You need a couple of good people who usually aren‘t easy to get, and who aren‘t cheap. </li></ul><ul><li>Your development process needs to reflect the two-track nature of MDSD (domain architecture development, application development) </li></ul><ul><li>Sometimes tools require some „creative use“ and improvisation (  use open source!) </li></ul><ul><li>Remember: a fool with a tool is still a fool </li></ul>- - generator
    40. 40. MDSD (compared to “normal” Software Development) - -
    41. 41. MDSD Effort (stage 1) - -
    42. 42. MDSD Effort (stage 2) - -
    43. 43. UML Tools as DSL editors <ul><li>If you want to use a UML tool as the editor for you DSL, the DSL must be mapped onto a UML profile , i.e. a set of </li></ul><ul><ul><li>Stereotypes, </li></ul></ul><ul><ul><li>Tagged values, and </li></ul></ul><ul><ul><li>Constraints </li></ul></ul><ul><li>Pros: </li></ul><ul><ul><li>Easy to implement </li></ul></ul><ul><ul><li>(Looks like a) standard </li></ul></ul><ul><ul><li>More or less acceptable export format (XMI) </li></ul></ul><ul><ul><li>Model Management features (searching, paritioning…) </li></ul></ul><ul><ul><li>Integration into the tool suite (versioning, etc.), if provided by the UML tool and indeed necessary </li></ul></ul>- -
    44. 44. UML Tools as DSL editors II <ul><li>Cons: </li></ul><ul><ul><li>Graphical Features are very limited (especially, data-dependent graphics!) </li></ul></ul><ul><ul><li>Constraints cannot be checked in real time (this may change over time – tool vendors improve!) </li></ul></ul><ul><ul><li>You cannot „remove“ UML semantics completely (try to draw a line between two attributes…). </li></ul></ul><ul><ul><li>You always have to use the complete UML tool – complex UI </li></ul></ul>- -
    45. 45. Editor Alternatives: Developing a Custom Tool <ul><li>Pros: </li></ul><ul><ul><li>Typically, quite powerful graphics features </li></ul></ul><ul><ul><li>No inherited features forced upon you by the tool </li></ul></ul><ul><ul><li>Only valid concrete syntax is possible </li></ul></ul><ul><ul><li>Constraints can be checked in realtime </li></ul></ul><ul><ul><li>Tool can be as simple as possible – no UML mess </li></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>Implementation Effort usually high </li></ul></ul><ul><ul><li>Often limited partitioning and model management support (depends ultimately on the effort you want to put in) </li></ul></ul>- -
    46. 46. Editor Alternatives: Developing a Custom Tool II <ul><li>Models are instances of their metamodel. </li></ul><ul><li>The Editor edits models… </li></ul><ul><li>… and uses concepts from the metamodel </li></ul>- -
    47. 47. Editor Alternatives: Custom Tool / Generating Editors <ul><li>GEF (Eclipse Graphical Editing Framework) is powerful, but hard to use. </li></ul><ul><li>Especially, if the domain metamodel changes regularly in a project, adapting the editors correspondingly is annoying. </li></ul><ul><li>As a consequence, we generate the editors from the domain meta- model and additional editor descriptions. </li></ul>- -
    48. 48. GMF Process - -
    49. 49. Custom Tool – the generated Network Editor - -
    50. 50. Characteristics of Textual DSLs <ul><li>Different characteristics for different domains </li></ul><ul><ul><li>Concrete Syntax: textual vs. graphical </li></ul></ul><ul><ul><li>Domain Selection: structural vs. behavioural </li></ul></ul><ul><ul><li>Expressive Power: declarative vs. imperative </li></ul></ul><ul><ul><li>Execution: interpretation vs. compilation/transformation </li></ul></ul><ul><ul><li>Integration: internal vs. external </li></ul></ul><ul><ul><li>Tool Support: editor, debugger, … </li></ul></ul>
    51. 51. Why concrete syntax is important <ul><li>Abstract Syntax defines grammar for the language – most important for tools </li></ul><ul><li>Concrete Syntax is the “UI” for the language – critical for DSL users </li></ul><ul><ul><li>concise vs. redundant </li></ul></ul><ul><ul><li>intuitive </li></ul></ul><ul><ul><li>simple to write and read </li></ul></ul><ul><li>Tool support matters </li></ul><ul><ul><li>IDE integration </li></ul></ul><ul><ul><li>syntax highlighting </li></ul></ul><ul><ul><li>metamodel awareness </li></ul></ul>
    52. 52. Different syntax for different abstractions / domains <ul><li>Different concrete syntax is well established for different domains </li></ul><ul><ul><li>class diagrams to describe types and structure </li></ul></ul><ul><ul><li>state charts </li></ul></ul><ul><ul><li>textual expression notation for behaviour </li></ul></ul><ul><ul><li>XML for structured data </li></ul></ul><ul><li>The abstraction should drive syntax decision, not vice versa </li></ul><ul><ul><li>Available tool support often decides the syntax </li></ul></ul><ul><ul><li>UML has its uses, but it is no panacea </li></ul></ul><ul><ul><li>building specific textual languages – and IDEs to work with them – has become feasible </li></ul></ul>
    53. 53. Tradeoffs for textual DSLs <ul><li>With both textual and graphical syntax you can </li></ul><ul><ul><li>Model for any meta model </li></ul></ul><ul><ul><li>verify constraints in real time </li></ul></ul><ul><ul><li>(Eclipse) write ordinary EMF models </li></ul></ul><ul><li>Graphical Editors are good to show structural relationships </li></ul><ul><li>Textual Editors are better for „algorithmic“ aspects, or hierarchical models </li></ul><ul><li>Textual Editors integrate better with CVS etc. (diff, merge) </li></ul>
    54. 54. Strengths of Textual DSLs <ul><li>Textual languages have specific strengths compared to graphical languages </li></ul><ul><ul><li>ideally there should be the option to have both </li></ul></ul><ul><li>compact and expressive syntax </li></ul><ul><ul><li>productivity for experienced users </li></ul></ul><ul><ul><li>IDE support softens learning curve </li></ul></ul><ul><li>configuration management/versioning and integration into the “regular” development process </li></ul><ul><ul><li>splitting a model into several files </li></ul></ul><ul><ul><li>concurrent work on a model, especially with a version control system: diff, merge </li></ul></ul><ul><ul><li>search, replace </li></ul></ul>
    55. 55. Separate Generated and Non-Generated Code <ul><li>Keep generated and non-generated code in separate files. </li></ul><ul><li>Never modify generated code. </li></ul><ul><li>Design an architecture that clearly defines which artifacts are generated, and which are not. </li></ul><ul><li>Use suitable design approaches to “join” generated and non-generated code. Interfaces as well as design patterns such as factory, strategy, bridge, or template method are good starting points. </li></ul>
    56. 56. Separate Generated and Non-Generated Code II <ul><li>A) Generated code can call non-generated code contained in libraries </li></ul><ul><li>B) A non-generated framework can call generated parts. </li></ul><ul><li>C) Factories can be used to „plug-in“ the generated building blocks </li></ul><ul><li>D) Generated classes can also subclass non-generated classes. </li></ul><ul><li>E) The base class can also contain abstract methods that it calls, they are implemented by the generated subclasses ( template method pattern) </li></ul>
    57. 57. We didn’t talk about... <ul><li>Model-to-Model Transformations </li></ul><ul><li>Interpreters </li></ul><ul><li>Best Practices </li></ul><ul><li>AO & MDSD </li></ul><ul><li>CBD & MDSD </li></ul><ul><li>PLE & MDSD </li></ul><ul><li>Many many other tools... (ME+, DSL Tools, Intentional, ...) </li></ul><ul><li>... And many more </li></ul><ul><ul><li>Please ask in Q&A </li></ul></ul>
    58. 58. C O N T E N T S <ul><li>Part 1: Theory </li></ul><ul><li>Part 2: Practice </li></ul><ul><li>Part 3: Q&A </li></ul>- -
    59. 59. openArchitectureWare <ul><li>Open Source </li></ul><ul><li>Version 4.2 is almost released </li></ul><ul><li>Proven track record in various domains & project contexts </li></ul><ul><ul><li>e.g., telcos, internet, enterprise, embedded realtime, finance, … </li></ul></ul><ul><li> </li></ul><ul><li>IDE-portions based on Eclipse </li></ul><ul><li>(Optional) Integration with Eclipse Modelling facilities (such as EMF) </li></ul>- -
    60. 60. openArchitectureWare / Eclipse EMF, GMF, EMP
    61. 61. C O N T E N T S <ul><li>Part 1: Theory </li></ul><ul><li>Part 2: Practice </li></ul><ul><li>Part 3: Q&A </li></ul>- -
    62. 62. Some advertisement  - - <ul><li>For those, who speak (or rather, read) german: Völter, Stahl, Haase, Efftinge: Modellgetriebene Softwareentwicklung Technik, Engineering, Management 2. Auflage dPunkt, 2007 </li></ul><ul><li>A translation is available Model-Driven Software Development, Wiley, May 2006 </li></ul>2nd Edition – significantly updated
    63. 63. More Advertisement  - -
    64. 64. More Advertisement  - -
    65. 65. More Advertisement  - -
    66. 66. More Advertisement  - -
    67. 67. C O N T E N T S <ul><li>Part 1: Theory </li></ul><ul><li>Part 2: Practice </li></ul><ul><li>Part 3: Q&A </li></ul>- - THE END. Thanks.