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

  • 2,439 views
Uploaded on

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

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

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,439
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
91
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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