1. Model Driven Development (MDD) Devon M. Simmonds Computer Science Department UNCW simmondsd[at]uncw.edu http://people.uncw.edu/simmondsd/ _______________________________________________________

2. Problems in software development The role of models Model driven development (MDD) MDD principles/challenges Summary Overview 2

3. 3 Many Problems  Interesting Jokes. Building Large Complex Software is Difficult! “Witness testifies on Software Speed"

4. 4 Many Problems  Interesting Jokes. Building Large Complex Software is Difficult! “Witness Testifies on Software Security"

5. 5 Amid all the jokes, we are in the business of finding solutions! Building Large Complex Software is Difficult!

6. 6 Making The Case For Model-Driven Engineering

7. 7 Computer science - solving problems with the aid of a computer – Software engineering – systematic approach to creating complex software systems using teams. Motivation Computer software is ubiquitous!

8. Models can help Code-centric software development introduces Accidental complexity Unnecessary complexity introduced by a technology or method –building construction without using power tools – Essential complexity: inherent in the problem and cannot be eliminated making airplanes fly 8

9. What is a model? A model is a representation of a system A model does not show all the features A model is an abstraction – Abstraction = hide details 9

10. How Engineering Models are Used To help us understand and manage complex systems –Focus on essential complexity –Define different views To communicate understanding –Clients, users, implementers, testers, etc. To drive implementation –The model as a blueprint for construction Save resources –Identify problems before the item is put into production. Engineering is a Model-Driven Discipline! 10

11. Characteristics of Useful Models Abstract Emphasize important aspects while removing irrelevant ones Understandable Expressed in a form that is readily understood by observers Accurate Faithfully represents the modeled system Predictive Can be used to answer questions about the modeled system Inexpensive Much cheaper to construct and study than the modeled system 11

12. Models in Software Engineering UML –Use cases –Activity diagrams –State diagrams –Sequence diagrams –Class diagrams –Package diagrams –Etc. OCL to specify constraints 12

13. Views An view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective. 13

14. Diagrams A diagram is a view into a model –Presented from the aspect of a particular stakeholder –Provides a partial representation of the system –Is semantically consistent with other views UML diagrams –Static views: use case, class, object, component, deployment –Dynamic views: sequence, statechart, activity 14

15. Models, Views, and Diagrams Scenario Diagrams Scenario Diagrams Collaboration Diagrams State Diagrams State Diagrams Component Diagrams Component Diagrams Component Diagrams Deployment Diagrams State Diagrams State Diagrams Object Diagrams Scenario Diagrams Scenario Diagrams Statechart Diagrams Use Case Diagrams Use Case Diagrams Sequence Diagrams State Diagrams State Diagrams Class Diagrams Activity Diagrams A model is a complete description of a system from a particular perspective Models 15 Use Case Diagrams Use Case Diagrams Use Case Diagrams

16. 16 The 4 + 1 View Model – Philippe Kruchten(95) Logical view End-user Functionality Development view Programmers. Software management Physical view System topology, Delivery, installation Process view System integrators: Performance, Scalability, Throughput ConceptualPhysical Use case view

17. 17 Transforming System Views UML models present different views of systems Evolution of system effected by evolving models (views) –Requires well defined relationships between models – requires well defined notions of refinement/abstraction

18. Class Diagram Practice Exercise Create a class diagram using the problem description below. – A school video library tracking system is to be developed. Videos can be scientific, religious or general. General videos are classified as miscellaneous, sports or entertainment. Students and professors can belong to research groups. A research group must have at least 2 professors. Every student must belong to some research group. Professors that belong to a research group are called research professors. Research professors do not teach courses every semester. Each semester, a student must register for at least one course offered by a professor in his research group. A student cannot register for courses outside the subject areas of the research groups in his academic department. A research group can consist of members with various subject area interests. However, subject areas are only classified as an area of interest for the group if at least two members have interest in the area. In general, professors can check out any number of videos, however, visiting professors can check out at most seven videos. Unlike regular professors, visiting professors can check out videos for the duration of only two weeks. Students can check out any number of religious videos and at most 2 scientific videos. Students can check out only scientific videos in the subject areas represented in their research groups. 18

19. 19 What is Model-Driven Development (MDD)? Models are the primary software development artifacts MDD involves –modeling software products and processes –precisely defining relationships among models –transforming models to executable forms

20. Model Driven Engineering Create Model Model A AA BB CC Model B MM BB CC AA PP KK.... Model PropertiesCodeCode Transform/CompileAnalyze 20

21. Model Driven Engineering Create Model Model A AA BB CC Model B MM BB CC AA PP KK.... Challenges –Abstraction: specifying models –Automation: transforming models, compiling models (e.g., code generation) –Analysis: determining properties of models –Evolution/Reuse: Changing and using models for developing other applications Model PropertiesCodeCode Transform/CompileAnalyze 21

22. The Abstraction Challenge : Specifying Models Can we build an analyzable language for modeling software systems at a level of abstraction above the current high-level programming languages? 22

23. The Abstraction Challenge: UML Class diagram view class Person { private: int age; char name[40]; Department dept; public: void move(); void speak(); } class Student: public Person { private: char id[20], grades[20], courses[20][20]; public: char major[20]; void takeCourse() void graduate() } Department Class diagram view shows structure and relationships Person -age:int -name:String[40] +move() +speak() Student +takeCourse() +graduate() -id:String[20] -grades:String[20] -courses:String[20] +major:String 23

24. class Person { private: int age; char name[40]; Department dept; public: void move(); void speak(); } class Student: public Person { private: char id[20], grades[20], courses[20][20]; public: char major[20]; void takeCourse() void graduate() } :Student:Department takeCourse() graduate() Interaction diagram view shows how classes interact The Abstraction Challenge: UML Interaction diagram view 24

25. The Automation Challenge Person -age:int -name:String[40] -address:Address +move() +speak() Code Generation generating code from models, i.e. compiling models. Managing Technologies supporting model portability, reusability, etc. Current Tools OptimalJ, Bridgepoint, XDE, etc. Model Transformation creating new models from existing models 25

26. 26 Code Generation class Department { private: char name[40]; Student csc[100]; public: void manageStudents(){ csc[i]->register(); … csc[i]->grade(); … csc[i]->graduate(); }} Model B MM BB CC AA PP KK Altova UModel

27. Distributed Systems Development Computer Hardware Operating System Application program Computer Hardware Operating System Application program Transaction management Fault tolerance Security Naming Concurrency Replication Query Event Quality of service Middleware Application program Realizing The Dream – Managing Technologies 27

28. Middleware Transparencies Services provided to distributed systems. – Access transparency : local and remote resources are accessed using identical operations. – Location transparency : resources are accessed without knowledge of their location (location independence). – Concurrency transparency : processes can operate concurrently using shared resources without interference between them. – Replication transparency : duplication of resources unknown to users. Resources are usually duplicated for purposes of reliability and performance. – Failure transparency : faults are concealed, allowing application programs to complete their tasks despite the failure of hardware or software components. 28

29. Standard Middleware Services Event Transaction Quality of service (QoS) Naming Query Security Method invocation Etc. 29

30. Distributed Systems Development Context Many middleware technologies – CORBA, Jini,.Net, EJB, SOAP, COM Problems require many technologies Middleware technologies evolve Middleware technology is crosscutting 30

31. Distributed Systems Development Problem Coupling of a pplications + technologies –Changes in middleware  change in application –Coupling results in complexity Difficult to develop and evolve distributed applications Specify models and transformations Migrate distributed applications 31

32. Difficult to Specify Design Models ClassA ClassB Middleware features ClassC ClassB ClassA ClassC Distributed Application Complex Model Transformation Transformed model or code Difficult to Specify Transformations Distributed Application 32

33. Difficulties To Migrate Distributed Application Eliminate Old Middleware Refactor Application Integrate New Middleware …... ClassA ClassB ClassC Distributed Application ClassA ClassB ClassC PIM ClassA ClassD ClassB ClassC ClassA ClassD ClassB ClassC New Distributed Application 33

34. The Automation Challenge Person -age:int -name:String[40] -address:Address +move() +speak() Code Generation generating code from models, i.e. compiling models. Managing Technologies supporting model portability, reusability, etc. Current Tools OptimalJ, Bridgepoint, XDE, etc. Model Transformation creating new models from existing models 34

35. 35 Some slides by Robert B. France, CSU Defining & Using Transformations Person -age:int -name:String[40] -address:Address +move() +speak() Code Generation generating code from models, i.e. compiling models. Managing Technologies supporting model portability, reusability, etc. Current Tools OptimalJ, Bridgepoint, XDE, etc. Model Transformation creating new models from existing models

36. Outline Introduction Query, View Transformation Overview Transformation challenges Mapping models to code and vice versa Experiences & Lessons learned 36

37. 37 Model to Model Transformation Create Model Model A AA BB CC Model B MM BB CC AA PP KK

38. 38 class Department { private: char name[40]; Student csc[100]; public: void manageStudents(){ csc[i]->register(); … csc[i]->grade(); … csc[i]->graduate(); }} Model B MM BB CC AA PP KK Model to Code Transformation - code generation

39. 39 Are transformations the heart of MDE? MDE = models + transformations Transformation-driven development? –Specify models –Evolve models Model B MM BB CC AA PP KK

40. 40 Potential Transformation Goals Refinement/Realization : e.g., create design models from analysis models. Abstraction : e.g., gain understanding of an existing artifact or model by abstracting out irrelevant details. Inferencing : e.g., transforming a model to make implied properties explicit. Analyzing : e.g., transforming a model to make it amenable to particular forms of analysis. Refactoring : e.g., transforming a model to improve its evolvability.

41. Classes of Transformations Vertical transformations (e.g., realize design in code, refine design features) Horizontal transformations (e.g., refactor to change features or enhance design quality, transform descriptive models to analysis models) 41

42. 42 Vertical Transformations Refinement/Realization –Realization example: transforming detailed design models to code –Refinement example: transforming abstract designs to less abstract designs Abstraction –Example: reverse-engineering of code to design

43. 43 Horizontal Transformations Refactoring : Improving model quality –E.g., applying patterns to designs Requires precise representation of patterns Inferencing : Inferring properties from models Analyzing : Extracting information needed for analysis Composition/anti-composition

44. 44 Refactoring and Realization Example

45. 45 Simple Model Inferencing Example (work of A. Evans et al.) A B C D m..n p..q D D * * Rel Rel01 Rel02 Rel01  Rel02  Rel A B C D m..n p..q Rel

46. 46 Transformation Conceptual Model Rigorous Analysis static analysis dynamic analysis feedback based on Transformation Metamodel Transformation Metamodel Source Metamodel conforms to Source Model Target Metamodel conforms to Target Model feedback Transformation

47. 47 Example UML Model Formal Model Formalization feedback UML Metamodel Formal Language Metamodel conforms to based on UML-FL Metamodel UML-FL Metamodel

48. Query, View, Transformation Standard

49. 49 Query View Transformation Standard Standard language-based concepts for specifying and implementing transformations Based on best available experience (!) –and other concerns … Supports hybrid declarative, imperative styles

50. 50 QVT Structure Declarative section –transformations specified as relationships among modeling structures (MOF models) –Provides support for specifying patterns (as object template expressions) and for pattern matching Imperative section –Provides a standard language for describing implementations of relations as Mapping Operations A transformation described entirely by Mapping Operations is called an operational transformation –Provides support for using non-standard implementation operators for realizing relations

51. 51 QVT Transformation Language  A user-friendly Relations metamodel and language which supports complex object pattern matching and object tem-plate creation.  A Core metamodel and language defined using minimal extensions to EMOF and OCL.  MOF Operations may be derived from Relations making it possible to "plug-in" any implementation of a MOF Operation with the same signature.

52. 52 QVT Transformation Example Simple UML meta-model

53. 53 Simple RDBMS meta-model

54. 54 Graphical Representation relation UML2Rel { checkonly domain uml1 c:Class { name = n, attribute = a:Attribute{name = an}} checkonly domain r1 t:Table { name = n, column = col:Column{name = an}} } Source modelTarget model

55. 55 Transformation specification Conceptual Model based on Transformation Metamodel Transformation Metamodel Source Metamodel conforms to Source Model Target Metamodel conforms to Target Model feedback Transformation Engine Input ModelOutput Model conforms to

56. 56 relation PackageToSchema { ckeckonly domain uml p:Package {name=pn} enforce domain rdbms s:Schema {name=pn} }

57. 57 Graphical Representation

58. 58 Simple RDBMS meta-model The when clause specifies the conditions under which the relationship needs to hold, so the relation ClassToTable needs to hold only when the PackageToSchema relation holds The where clause specifies the condition that must be satisfied by all model elements participating in the relation

59. 59 Simple RDBMS meta-model

60. In Class Exercise Create a QVT transformation for converting a sequence diagram to a class model. 60

61. 61 QVT Transformation Example Transformation model Input model

62. 62 QVT Transaction Example Transformation model Source transformation model

63. 63 QVT Transformation Example Target transformation model (part a)

64. 64 QVT Transformation Example Target model (part b)

65. 65 QVT Transformation Example Target model (part c)

66. 66 The Model-Driven Architecture (MDA) Person -age:int -name:String[40] -address:Address +move() +speak() Code Generation generating code from models, i.e. compiling models. Managing Technologies supporting model portability, reusability, etc. Current Tools OptimalJ, Bridgepoint, XDE, etc. Model Transformation creating new models from existing models Slides include some created by Richard Mark Soley

67. 67 Devon M. Simmonds Introduction to the Model- Driven Architecture (MDA) Slides include some created by Richard Mark Soley

68. 68 Outline Software context The OMG The MDA

69. Current Software Context Heterogeneity is permanent Problems require many technologies Middleware technologies constantly change Middleware technology is crosscutting 69

70. Heterogeneity is Permanent Programming languages –~2 million COBOL programmers 200 billion lines of Cobol code exist in enterprises –~1.6 million VB programmers –~1.1 million C/C++ programmers Operating systems –Unix, MVS, VMS, MacOS, Windows (all 8!), PalmOS… –Windows 3.1: it’s still out there! –Embedded devices (mobile, set-top, etc.) Networks –Ethernet, ATM, IP, SS7, Firewire, USB –Bluetooth, 802.11b, HomeRF Middleware technologies – CORBA, Jini,.Net, EJB, SOAP, COM 70

71. Problems Require Many Technologies Multiple OS Multiple programming languages Etc. 71 CSC550 Software Engineering

72. Technologies Constantly Change Middleware technology is crosscutting! Middleware itself has proliferated: CORBA ® : Vendor, OS & language independent middleware COM/DCOM/MTS Java/EJB XML/SOAP C#/.Net What will be Next Best Thing? 72

73. Technologies Constantly Change How can companies protect their software investments as the infrastructure changes? 73

74. Protecting Software Investment? Tracking the next best thing Protecting your investment in existing software base Retaining qualified staff Maintaining existing code base Integrating what you’ve built – With what you will build! 74

75. Where Can We Agree? There will not be consensus on hardware platforms There will not be consensus on operating systems There will not be consensus on network protocols There will not be consensus on programming languages There must be consensus on interfaces and interoperability! OMG to the rescue! 75

76. The Object Management Group (OMG) “ The OMG is an international not-for-profit software consortium that is setting standards in the area of distributed object computing. We are a vendor-neutral membership-driven organization and have hundreds of members who are working towards developing and refining these standards.” - OMG Website 76

77. Who Are OMG? AT&T BEA Borland Boeing CA Citigroup Compaq Compuwar e Ericsson Ford Fujitsu Glaxo SmithKline Hewlett Packard Hitachi Hyperion IBM IONA io Software Kabira Kennedy Carter John Deere Microsoft MITRE MSC.Software NASA NEC NetGenics NTT OASIS Oracle Pfizer Rational SAGA Software SAP SAS Institute Secant Siemens Sprint Sun Unisys Vertel 77

78. OMG’s Major Successes Common Object Request Broker Architecture –CORBA® remains the only language- and platform-neutral interoperability standard Unified Modeling Language –UML TM remains the world’s only standardized modeling language Common Warehouse Metamodel –CWM TM, the integration of the last two data warehousing initiatives Meta-Object Facility –MOF TM, the repository standard XML Metadata Interchange –XMI TM, the XML-UML standard 78

79. OMG & The Technology Change Problem Goal  Help organizations ensure that their mission- critical information systems are rooted in standards that will adapt to new hardware capabilities and software platforms. Provide a vendor-neutral approach to the challenge of business and technology change. 79

80. OMG’s Solution Develop an architecture, using object technology, for distributed application integration, guaranteeing: –reusability of components –interoperability & portability –basis in commercially available software 80

81. 81 Model Driven Architecture (MDA) [From OMG website] An initiative to address pervasive middleware features Make models 1 st class entities. Create technology-based models separate from business logic models. Support automated transformation of models Modeling in UML [From OMG website]

82. MDA Goals –Portability –Interoperability –Reusability –Platform Independence –Reduction in complexity Model to model transformations 82

83. 83 Basic MDA PIM Model Transformation –Platform Independent Models (PIM) –Mappings : PIM PSM QVT, MOF 2.0 (a standard for describing transformations) –Platform Specific Models (PSM)

84. Computation Independent (Business) Model Platform Independent Model Platform Specific Model T1 T5 T6 T7 T2 T4 MDA proposes model-to-model transformations T1 – T7 are transformations The MDA – Models & Transformations T3 84

85. Platform Independence? Depends on the selection of the target platform! (see next slide) 85

86. 86 Aspect Oriented Model-driven Development Framework (AOMDF) Model B mappings Develop source models Develop Model A mappings Specify Transformation Apply Model A mappings Apply Transformation Model A mappings Source Model A Target Model A Target Model B Source Level Transformation Specification Phase Target Level Source Model B Composition transformations Specification

87. 87 MDA & Code Generation

88. MDA – More Benefits Reduced cost throughout the application life-cycle. Reduced development time for new applications. Rapid inclusion of emerging technology benefits into existing systems. Reduced complexity of application development, maintenance and evolution. Domain Specificity Implementation of new applications for different platforms. Productivity - 30% increase with a model-driven engineering approach. The MDA boasts many success stories! 88

89. See Some Proof of Concept! 89

90. 90 ______________________ Devon M. Simmonds Computer Science Department University of North Carolina Wilmington _____________________________________________________________ Qu es ti ons? End of This Module

91. The Analysis Challenge Can we determine properties of the program before the code is generated? An open research question! Challenges –Abstraction: specifying models –Automation: transforming models, compiling models (e.g., code generation) –Analysis: determining properties of models –Evolution/Reuse: Changing and using models for developing other applications 91

92. 92 ______________________ Devon M. Simmonds Computer Science Department University of North Carolina Wilmington _____________________________________________________________ Qu es ti ons? The End

93. Other Slides 93

94. Distributed System A distributed system consists of a set of interconnected computers called a network. –Computer programs execute on each network computer, and coordinate actions by exchanging messages over the network. 94

95. Middleware Middleware is system software that occurs between the application and the operating system. –Its primary purpose is to simplify the development of distributed systems by providing a variety of features to the distributed applications. Access to infrastructural details such as operating system, hardware, and network specifics. Access to local, remote, and mobile resources. A menu of standard services. 95

96. 96 Behavioral Elements of UML Metamodel

97. Interaction Diagram Metamodel (see handout) 97 1. Can you derive the relationship between a message end and a lifeline? 2. Can you derive the relationship between a message and an operation? 2. Can you derive the relationship between a class and a lifeline?

98. The Analysis Challenge Can we determine properties of the program before the code is generated? An open research question! Challenges –Abstraction: specifying models –Automation: transforming models, compiling models (e.g., code generation) –Analysis: determining properties of models –Evolution/Reuse: Changing and using models for developing other applications 98

99. 99 Metadata and the UML Metamodel Next 