2. Introduction to Model- Driven Engineering Olivier Barais (Univ. Rennes 1 & INRIA) Triskell Team @ IRISA Campus de Beaulieu F-35042 Rennes Cedex Tel : +33 299 842 541 Fax : +33 299 847 171 e-mail : barais@irisa.frbarais@irisa.fr D’après le cours de Jean-Marc Jézéquel (or: Why I'd like write program that write programs rather than write programs)

3. Problématique du génie logiciel aujourd’hui

4. Olivier Barais 3 Modern Software Problems Importance of non-functional properties Importance of non-functional properties –distributed systems, parallel & asynchronous –quality of service : reliability, latency, performance... Flexibility of functional aspects: Product Lines Flexibility of functional aspects: Product Lines –notion of product lines (space, time) Versions (Time) Variants (Functionalities) Time to Market! Time to Market! 1.11.2 1.0 1.1 1.2 1.3 1.4

5. Olivier Barais 4 Problems addressed in SE 1960’s: Cope with inherent complexity of software (Correctness) 1960’s: Cope with inherent complexity of software (Correctness) –Milestone: Floyd ‘ assigning meaning to programs’ » More than 10 years to mature. Mature <> solved! Mature <> solved! 19651975198519952005Time Size of « big » projects (LOC) 10 8 10 7 10 6 10 5 10 4 Compiler

6. Olivier Barais 5 Problems addressed in SE 1970’s: Cope with project size 1970’s: Cope with project size –Milestone: Parnas, Yourdon: modularity & structure » More than 10 years to mature 19651975198519952005Time Size of « big » projects (LOC) 10 8 10 7 10 6 10 5 10 4 Compiler Packet Switching System

7. Olivier Barais 6 Problems addressed in SE 1980’s: Cope with variability in requirements 1980’s: Cope with variability in requirements –Milestone: Jackson, Meyer: modeling, object orientation » More than 10 years to mature 19651975198519952005Time Size of « big » projects (LOC) 10 8 10 7 10 6 10 5 10 4 Compiler Packet Switching System Nuclear Submarine Control – Nokia’s GSM infrastructure: »50% of requirements changed after they were frozen after they were frozen »60% of these changed at least twice!

8. Olivier Barais 7 OO approach: frameworks

9. Olivier Barais 8 Problems addressed in SE 1990’s: Cope with distributed systems and mass deployment: 1990’s: Cope with distributed systems and mass deployment: –Milestone: MS (COM), Szyperski: product-lines & components 19651975198519952005Time Size of « big » projects (LOC) 10 8 10 7 10 6 10 5 10 4 Compiler Packet Switching System Nuclear Submarine Control GSM Network Component = deployment unit Component = deployment unit – focus on non-functional properties – installation/execution concept »Explicit (contractual) dependencies »Configuration and connection

10. Olivier Barais 9 OO approach: Models and Components frameworks frameworks Guarantees ? Functional, synchronization, performance, QoS Changeable software, from distributed/unconnected sources even after delivery, by the end user

11. Olivier Barais 10 Problems addressed in SE 2000’s: pervasive software integration, accelerating technological changes (platforms) 2000’s: pervasive software integration, accelerating technological changes (platforms) –Milestone: ? 19651975198519952005Time Size of « big » projects (LOC) 10 8 10 7 10 6 10 5 10 4 Compiler Packet Switching System Nuclear Submarine Control GSM Network Windows 2000

12. Olivier Barais 11 From the object as the only one concept From the object as the only one concept –As e.g. in Smalltalk To a multitude of concepts To a multitude of concepts Once upon a time… software development looked simple Design patterns Collaborations Required port Provided Port > Decoder DecoderI ReceiverI DataI Components COM+ DCO M CORBA IIOP Microsoft C# &.Net XML SOAP Sun’s Java & EJB HTTP HTM L + until the next ultimate middleware platform (~2005) Proprietary Middleware (eg. automotive) It's difficult -- in fact, next to impossible – for a large enterprise to standardize on a single middleware platform. (R. Soley) Middleware Middleware (middle war) Aspects

13. Olivier Barais 12 Collaborations Objects should be as simple as possible Objects should be as simple as possible –To enable modular understanding But then where is the complexity? But then where is the complexity? –It is in the way objects interact! –Cf. Collaborations as a standalone diagram in UML ( ( T. Reenskaug’s works)

14. Olivier Barais 13 Design Patterns Embody architectural know-how of experts Embody architectural know-how of experts As much about problems as about solutions As much about problems as about solutions –pairs problem/solution in a context About non-functional forces About non-functional forces –reusability, portability, and extensibility… Not about classes & objects but collaborations Not about classes & objects but collaborations –Actually, design pattern applications are parameterized collaborations

15. Olivier Barais 14 From Objects to Components Object = instance of a class Object = instance of a class Class = reusable unit of software Class = reusable unit of software –focus on structural and functional properties –development concept Component = deployment unit Component = deployment unit –focus on non-functional properties –installation/execution concept »Explicit dependencies »Configuration and connection

16. Olivier Barais 15 Middleware or Middle War? COM+ DCOM CORBA IIOP Microsoft C# &.Net XML SOAP Sun’s Java & EJB HTTP HTM L zNo clear winner until now zAnd probably not in the near future zMigration is expensive and disruptive zThe OMG tried to send in the ‘’blue helmets’’ with the MDA initiative + until the next ultimate middleware platform (~2005) Proprietary Middleware (eg. automotive) It's difficult -- in fact, next to impossible – for a large enterprise to standardize on a single middleware platform. (R. Soley)

17. Olivier Barais 16 Aspect Oriented Programming Kiczales et al., ECOOP’97 Kiczales et al., ECOOP’97 –MIT’s one of 10 key technologies for 2010 Encapsulation of cross-cutting concerns in OO programs Encapsulation of cross-cutting concerns in OO programs –Persistence, contract checking, etc. Weaving at some specific points (join points) in the program execution Weaving at some specific points (join points) in the program execution – Hence more than macros on steroids AspectJ for AOP in Java AspectJ for AOP in Java –Some clumsiness in describing dynamic join points What about Aspect Oriented Design ? What about Aspect Oriented Design ?

18. Olivier Barais 17 good modularity XML parsing in org.apache.tomcat XML parsing in org.apache.tomcat –red shows relevant lines of code –nicely fits in one box XML parsing

19. Olivier Barais 18 good modularity URL pattern matching in org.apache.tomcat URL pattern matching in org.apache.tomcat –red shows relevant lines of code –nicely fits in two boxes (using inheritance) URL pattern matching

20. Olivier Barais 19 problems like… where is logging in org.apache.tomcat where is logging in org.apache.tomcat –red shows lines of code that handle logging –not in just one place –not even in a small number of places logging is not modularized

21. Olivier Barais 20 AspectJ™ is… a small and well-integrated extension to Java a small and well-integrated extension to Java a general-purpose AO language a general-purpose AO language –just as Java is a general-purpose OO language freely available implementation freely available implementation –compiler is Open Source includes IDE support includes IDE support –emacs, JBuilder, Forte user feedback is driving language design user feedback is driving language design –users@aspectj.org –support@aspectj.org currently at 1..5.4 release currently at 1..5.4 release

22. Olivier Barais 21 Expected benefits of using AOP good modularity, even for crosscutting concerns good modularity, even for crosscutting concerns –less tangled code –more natural code –shorter code –easier maintenance and evolution »easier to reason about, debug, change –more reusable »library aspects »plug and play aspects when appropriate

23. État de la pratique

24. Olivier Barais 23 Des logiciels complexes... Logiciels de grande taille Logiciels de grande taille –des millions de lignes de code –des équipes nombreuses –durée de vie importante –des lignes de produits –plateformes technologiques complexes –évolution continue Logiciels complexes Logiciels complexes Logiciels critiques Logiciels critiques......

25. Olivier Barais 24 Évolution des acteurs scientifique programmeur utilisateur ingénieurs logiciels utilisateurs Time

26. Olivier Barais 25 Oui, Oui, Oui, mais... La mentalité de "l'informaticien moyen" a t elle radicalement évoluée ? La mentalité de "l'informaticien moyen" a t elle radicalement évoluée ? Du "Codeur", au "Programmeur", à l' "Ingénieur Logiciel",... Du "Codeur", au "Programmeur", à l' "Ingénieur Logiciel",... L' "Ingénieur logiciel" L' "Ingénieur logiciel" –prouve-t-il ses programmes ? –maintient-il à jour la documentation, les spécifications ?

27. Olivier Barais 26 État de la pratique 50 ans après les débuts de l'informatique, pour "l'informaticien moyen" la seule chose importante dans le logiciel c'est... la seule chose importante dans le logiciel c'est... le Code ! => Ingénierie Dirigée par le code

28. Olivier Barais 27 L'industrie logicielle aujourd'hui end users component developers architects assemblersstandardization organization tool vendors application testers site administrators component testers middleware providers

29. Olivier Barais 28 middleware providers end users component developers architects assemblersstandardization organization tool vendors application testers site administrators component testers De nombreux acteurs des préoccupations différentes des métiers différents des compétences variées des outils variés différents éléments logiciels Séparation des préoccupations L'industrie logicielle aujourd'hui

30. Olivier Barais 29 Point de vue des locataires Point de vue des plombiers Point de vue des électriciens architectes paysagistes Point de vue du cadastre Point de vue des assureurs pompiers notaires promoteurs Séparations des préoccupations système

31. Olivier Barais 30 Point de vue du propriétaire Point de vue du plombier Point de vue de l' électricien Point de vue du maçon Point de vue de l' architecte Point de vue du cadastre système Utile même pour des systèmes "moins" complexes Utile même pour des systèmes "moins" complexes Séparations des préoccupations

32. Olivier Barais 31 Problématique Complexité croissante des logiciels Complexité croissante des logiciels Séparations des préoccupations Séparations des préoccupations Séparations des métiers Séparations des métiers Multiplicité des besoins Multiplicité des besoins Multiplicité des plateformes Multiplicité des plateformes Évolution permanente Évolution permanente Logiciel = Code ? Est-ce la solution ?

33. Olivier Barais 32 Multiples modèles d'un même système modèles pour les architectes modèles pour les notaires modèles pour les pompiers système modèles pour le cadastre modèles pour l'assureur cadastre modèles pour les paysagistes modèles pour les électriciens modèles pour les plombiers modèles pour les promoteurs

34. Olivier Barais 33 Ingénierie Dirigée par le Code ou Ingénierie Dirigée par les Modèles ? Ingénierie Dirigée par le Code ou Ingénierie Dirigée par les Modèles ? Telle est la question...

35. Olivier Barais 34 système

36. Olivier Barais 35 Oui, Oui, Oui, mais... pour "l'informaticien moyen" la seule chose importante dans le logiciel c'est... la seule chose importante dans le logiciel c'est... le Code !

37. Olivier Barais 36 ? ? ? ? ?

38. Olivier Barais 37 Synthèse Des Modèles plutôt que du Code Des Modèles plutôt que du Code –Un modèle est la simplification/abstraction de la réalité –Nous construisons donc des modèles afin de mieux comprendre les systèmes que nous développons –Nous modélisons des systèmes complexes parce que nous somme incapables de les comprendre dans leur totalité –Le code ne permet pas de simplifier/abstraire la réalité

39. Pourquoi modéliser

40. Olivier Barais 39 Why modeling: master complexity Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality. A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality. Jeff Rothenberg.

41. Olivier Barais 40 Modeling in Science & Engineering A Model is a simplified representation of an aspect of the World for a specific purpose A Model is a simplified representation of an aspect of the World for a specific purpose M 0 (the world) M 1 (modeling space) Is represented by Specificity of Engineering: Model something not yet existing (in order to build it) Specificity of Engineering: Model something not yet existing (in order to build it)

42. Olivier Barais 41 UML: one model, 4 main dimensions, multiple views Device start() stop() Operator > 0..*1 1 controls Class diagram : Operator : Device start( ) stop( ) Sequence diagram UseCase diagram : Operator ControllingSiteRemoteSite TCP/IP : Device Implementation diagram : Operator

43. Olivier Barais 42 The X diagrams of UML Modeling along 4 main viewpoints: Modeling along 4 main viewpoints: –Static Aspect (Who?) »Describes objects and their relationships »Structuring with packages –User view (What?) »Use cases –Dynamic Aspects (When?) »Sequence Diagram »Collaboration Diagram »State Diagram »Activity Diagram –Implementation Aspects (Where?) »Component Diagram & deployment diagram

44. Olivier Barais 43 Example Modeling a (simplified) GPS device Modeling a (simplified) GPS device –Get position, heading and speed »by receiving signals from a set of satellites –Notion of Estimated Position Error (EPE) »Receive from more satellites to get EPE down –User may choose a trade-off between EPE & saving power »Best effort mode »Best route (adapt to speed/variations in heading) »PowerSave (Case Study borrowed from N. Plouzeau, K. Macedo & JP. Thibault. Big thanks to them)

45. Olivier Barais 44 Modeling a (simplified) GPS device Use case diagram Use case diagram

46. Olivier Barais 45 Modeling a (simplified) GPS device Class diagram Class diagram knows readsFrom route

47. Olivier Barais 46 Modeling a (simplified) GPS device Sequence diagram: configuring decoders Sequence diagram: configuring decoders

48. Olivier Barais 47 Modeling a (simplified) GPS device Sequence diagram: interrupt driven architecture Sequence diagram: interrupt driven architecture Many more sequence diagrams needed… Many more sequence diagrams needed…

49. Olivier Barais 48 Modeling a (simplified) GPS device Targeting multiple products with the same (business) model Targeting multiple products with the same (business) model –Hand held autonomous device –Plug-in device for PalmTop –Plug-in device for laptop (PCMCIA) –May need to change part of the software after deployment We choose a component based delivery of the software We choose a component based delivery of the software

50. Olivier Barais 49 Modeling a (simplified) GPS device Component diagram Component diagram Required port Provided Port > Decoder DecoderI ReceiverI DataI

51. Olivier Barais 50 Modeling a (simplified) GPS device Deployment diagram Deployment diagram

52. Olivier Barais 51 Model and Reality in Software Sun Tse: Do not take the map for the reality Sun Tse: Do not take the map for the reality Magritte Magritte Software Models: from contemplative to productive Software Models: from contemplative to productive

53. Olivier Barais 52 Modeling and Weaving Design Model Use Case Model Security Model QoS Model Business Model Object Model Test Model UI Model Platform Model Code Model tester Challenges: -Product Families -Reuse of Weaving Process -Automatic Weaving Challenges: -Product Families -Reuse of Weaving Process -Automatic Weaving

54. Olivier Barais 53 Assigning Meaning to Models If a UML model is no longer just If a UML model is no longer just –fancy pictures to decorate your room –a graphical syntax for C++/Java/C#/Eiffel... Then tools must be able to manipulate models Then tools must be able to manipulate models –Let’s make a model of what a model is! –=> meta-modeling »& meta-meta-modeling..

55. Olivier Barais 54 UML2 meta-model (part.)

56. Olivier Barais 55 Zoom: comments

57. Olivier Barais 56 Generalizations

58. Olivier Barais 57 Modeling techniques at OMG: 3 steps MOF UML aModel UML aModel MOF UML UML_for_CORBA aModel SPEM Workflow etc. Common Warehouse Metadata Common Warehouse Metadata Action language 1995 19982001

59. Olivier Barais 58 The 4 layers in practice

60. Olivier Barais 59 Comparing Abstract Syntax Systems Pascal Language Grammar A specific Pascal Program A specific execution of a Pascal program EBNF MOFThe UML meta-Model A Specific phenomenon corresponding to a UML Model A Specific UML Model Technology #2 (MOF + OCL) M3M3 M2M2 M1M1 Technology #1 (formal grammars attribute grammars, etc.) A XML document A XML DTD Or Schema A XML document A XML DTD or Schema Technology #3 (XML Meta-Language) KIF Theories Upper Level Ontologies Technology #4 (Ontology engineering) [XMI=MOF+XML+OCL] +Description Logics +Conceptual Graphs +etc. + Xlink, Xpath, XSLT + RDF, OIL, DAML + etc. (From J. Bézivin)

61. Olivier Barais 60 MDA: the OMG new vision "OMG is in the ideal position to provide the model- based standards that are necessary to extend integration beyond the middleware approach… Now is the time to put this plan into effect. Now is the time for the Model Driven Architecture." Richard Soley & OMG staff, MDA Whitepaper Draft 3.2 November 27, 2000

62. Olivier Barais 61 Mappings to multiple and evolving platforms COM+ DCOM CORBA C#.Net XML SOAP Java EJB HTTP HTM L zMOF & UML as the core zOrganization assets expressed as models zModel transformations to map to technology specific platforms Platform neutral models based on UML & MOF

63. Olivier Barais 62 The core idea of MDA: PIMs & PSMs MDA models MDA models – PIM : Platform Independent Model »Business Model of a system abstracting away the deployement details of a system »Example: the UML model of the GPS system – PSM : Platform Specific Model »Operational model including platform specific aspects »Example: the UML model of the GPS system on.NET Possibly expressed with a UML profile (.NET profile for UML) Possibly expressed with a UML profile (.NET profile for UML) –Not so clear about platform models »Reusable model at various levels of abstraction CCM, C#, EJB, EDOC, … CCM, C#, EJB, EDOC, …

64. Olivier Barais 63 A PSM for our GPS Here, the platform is.NET Here, the platform is.NET

65. Olivier Barais 64 How to go From PIM to PSM? "just" weave the platform aspect ! "just" weave the platform aspect ! How can I do that? How can I do that? –Through Model transformations –Now hot topic at OMG with RFP Q/V/T »Query/View/Transformation

66. Olivier Barais 65 Weaving aspects into UML Models? It’s what Model Driven Architecture is about! It’s what Model Driven Architecture is about! RequirementsAnalysis Architectural Design Detailed Design ImplementationValidation Lifecycle Modeling point of views Proofs, QoS Analysis, Simulation Technical Aspects Business Aspects Text (e.g. XML) PIM Doc PIM PSM PIMPSM CodeTests Formal Models Endomorphic Transformations Exomorphic Transformations Outside UML scope PIM=Platform Independent Model PSM= Platform Specific Model

67. Olivier Barais 66 But many more dimensions in modeling! Beyond Design Model Beyond Design Model –where UML is arguably good… Business model Business model GUI model GUI model Development process model Development process model Performance & Resource model Performance & Resource model Deployment model Deployment model Test model Test model Etc. Etc.

68. Olivier Barais 67 How to take these dimensions into account? Expression with either Expression with either –UML, using built-in extension mechanisms to link with other semantic domains –DS(M)L, based on MOF Exploitation Exploitation –Weave all these aspects into a design model –Define mappings between these aspects (as in e.g. federations ) Service model Domain model Resource model Design Model Test model Installation model

69. Olivier Barais 68 Element stereotype Design pattern application (parametric collaboration) …and also Tagged values & Contracts Command pattern receiver invoker Embedding implicit semantics into a model

70. Olivier Barais 69 …and the result we want...

71. Olivier Barais 70 Persitence implementation Command pattern implementation How To: Automatic Model Transformations In some domains (e.g.; RT systems) transformations can get more complex than initial model! => must be managed with sound SE principles

72. Olivier Barais 71 Why complex transformations? Example: Air Traffic Management Example: Air Traffic Management –“business model” quite stable & not that complex Various modeling languages used beyond UML Various modeling languages used beyond UML –As many points of views as stakeholders Deliver software for (many) variants of a platform Deliver software for (many) variants of a platform –Heterogeneity is the rule Reuse technical solutions across large product lines (e.g. fault tolerance, security…) Reuse technical solutions across large product lines (e.g. fault tolerance, security…) Customize generic transformations Customize generic transformations Compose reusable transformations Compose reusable transformations Evolve & maintain transformations for 15+ years! Evolve & maintain transformations for 15+ years!

73. Olivier Barais 72 The 3 ages of Transformations Awk-like (inc. sed, perl…) Awk-like (inc. sed, perl…) XSLT XSLT –W3C standard for transforming XML –Operates on tree structures –syntactical & inefficient QVT-like QVT-like –Now hot topic at OMG with RFP Q/V/T »Query/View/Transformation –Operates on graphs BEGIN {action) pattern #1 {action #1} … pattern #n {action #n} END {action) SE Limit: ~100 LOC SE Limit: ~1000 LOC SE Limit: ? Standard? Which/When?

74. Olivier Barais 73 Transformations are Assets => apply sound SE principles Must be Modeled Must be Modeled –with the UML, using the power of OO Must be Designed Must be Designed –Design by Contract, using OCL Must be Implemented Must be Implemented –Made available through libraries of components, frameworks… Must be Tested Must be Tested –test cases »input: a UML Model »output: a UML Model, + contract checking Must be Evolved Must be Evolved –Items of Configuration Management –Transformations of transformations

75. Olivier Barais 74 Principles 1. Everything relevant to the development process is a model 2. All the meta-models can be written in a language of a unique meta-meta-model »Same M3 helps Interoperability of tools defined at M2 3. A development process can be modelled as a partially ordered set of model transformations, that take models as input and produce models as output

76. Olivier Barais 75 Consequences 1. Models are aspect oriented. Conversely: Aspects are models 2. Transformations are aspects weavers. They can be modeled. 3. Every meta-model defines a domain specific language 4. Software development has two dimensions: M1-model development and M2-transformation development

77. Olivier Barais 76 Challenges Language definition problems (Q/V/T) Language definition problems (Q/V/T) –Expressive, easy to use language(s) for transformations Technological Issues Technological Issues –Tool set, interoperability… Software Engineering Issues Software Engineering Issues –From requirements to tests and SCM Theoretical issues Theoretical issues –A transformation is a mapping between semantic domains »Beyond Code Generation: Proof, Performance Evaluation, Test Synthesis … –Compositional weaving, cf. Aspect Oriented Software Dvp

78. Olivier Barais 77 UML & Model Driven Architecture: Summary Modeling to master complexity Modeling to master complexity –Multi-dimensional and aspect oriented by definition Models: from contemplative to productive Models: from contemplative to productive –Meta-modeling tools Model Driven Engineering Model Driven Engineering –Weaving aspects into a design model »E.g. Platform Specificities Model Driven Architecture (PIM / PSM): just a special case of Aspect Oriented Design Model Driven Architecture (PIM / PSM): just a special case of Aspect Oriented Design Related: Generative Prog, Software Factories Related: Generative Prog, Software Factories

79. Olivier Barais 78 Preview of the rest of this course Meta-Modeling Meta-Modeling –Meta-models & abstract syntaxes –Static Semantics with OCL –Dynamic Semantics with Kermeta Model Driven Specification Language Model Driven Specification Language –The logo case study Model Transformations & code generation Model Transformations & code generation Applications of MDE Applications of MDE –Design Pattern Application –Model Refactoring –Product Line Modeling and Derivation