Model Driven Development (MDD)

Devon M. SimmondsComputer Science Department

UNCW

simmondsd[at]uncw.edu

http://people.uncw.edu/simmondsd/_______________________________________________________

Problems in software developmentThe role of modelsModel driven development (MDD)MDD principles/challengesSummary

Overview

2

3

Many Problems Interesting Jokes.

Building Large Complex Software is Difficult!

“Witness testifies on Software Speed"

4

Many Problems Interesting Jokes.

Building Large Complex Software is Difficult!

“Witness Testifies on Software Security"

5

Amid all the jokes, we are

in the business of

finding solutions!

Building Large Complex Software is Difficult!

6

Making The Case For

Model-Driven Engineering

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!

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

What is a model?

A model is a representation of a system

A model does not show all the featuresA model is an abstraction– Abstraction = hide details

9

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

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

Models in Software Engineering

UML– Use cases– Activity diagrams– State diagrams– Sequence diagrams– Class diagrams– Package diagrams– Etc.

• OCL to specify constraints

12

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

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

Models, Views, and Diagrams

ScenarioDiagramsScenario

DiagramsCollaborationDiagrams

StateDiagramsState

DiagramsComponentDiagrams

ComponentDiagramsComponent

DiagramsDeploymentDiagrams

StateDiagramsState

DiagramsObjectDiagrams

ScenarioDiagramsScenario

DiagramsStatechartDiagrams

Use CaseDiagramsUse Case

DiagramsSequenceDiagrams

StateDiagramsState

DiagramsClassDiagrams

ActivityDiagrams

A model is a complete description of a system from a particular perspective

Models

15

Use CaseDiagramsUse Case

DiagramsUse CaseDiagrams

16

The 4 + 1 View Model – Philippe Kruchten(95)

Logical viewEnd-user Functionality

Development viewProgrammers .Software management

Physical viewSystem topology,

Delivery, installation

Process viewSystem integrators:Performance, Scalability, Throughput

Conceptual Physical

Use case view

17

Transforming System Views

UML models present different views of systemsEvolution of system effected by evolving models (views)– Requires well defined relationships between models– requires well defined notions of

refinement/abstraction

Class Diagram Practice ExerciseCreate 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

What is Model-Driven Development (MDD)?

Models are the primary software development artifactsMDD involves– modeling software products and processes– precisely defining relationships among models– transforming models to executable forms

Model Driven Engineering

CreateModel

Model AModel A

AA

BBCC

Model BModel B

MM

BBCC

AA

PPKK

. . Model Properties

CodeCodeSC_MODULE(producer){sc_outmaster<int> out1;sc_in<bool> start; // kick-startvoid generate_data (){for(int i =0; i <10; i++) {out1 =i ; //to invoke slave;}}SC_CTOR(producer){SC_METHOD(generate_data);sensitive << start;}};SC_MODULE(consumer){sc_inslave<int> in1;int sum; // state variablevoid accumulate (){sum += in1;cout << “Sum = “ << sum << endl;}

Transform/Compile

Analyze

20

Model Driven Engineering

CreateModel

Model AModel A

AA

BBCC

Model BModel B

MM

BBCC

AA

PPKK

. .

• 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 Properties

CodeCodeSC_MODULE(producer){sc_outmaster<int> out1;sc_in<bool> start; // kick-startvoid generate_data (){for(int i =0; i <10; i++) {out1 =i ; //to invoke slave;}}SC_CTOR(producer){SC_METHOD(generate_data);sensitive << start;}};SC_MODULE(consumer){sc_inslave<int> in1;int sum; // state variablevoid accumulate (){sum += in1;cout << “Sum = “ << sum << endl;}

Transform/Compile

Analyze

21

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

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

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()

takeCourse()

graduate()

Interaction diagram view shows how classes interact

The Abstraction Challenge: UML Interaction diagram view

24

The Automation ChallengePerson

-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

Code Generation

class Department { private:          char name[40]; Student csc[100];public:     void manageStudents(){ csc[i]->register(); … csc[i]->grade(); … csc[i]->graduate();}}

Model BModel B

MM

BBCC

AA

PPKK

Altova UModel

Distributed Systems Development

Computer Hardware

Operating System

Application program

Computer Hardware

Operating System

Application program

Transaction management

Fault toleranceSecurityNamingConcurrencyReplicationQueryEventQuality of service

Middleware

Application program

Realizing The Dream – Managing Technologies

27

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

Standard Middleware Services

EventTransactionQuality of service (QoS)NamingQuerySecurityMethod invocationEtc.

29

Distributed Systems Development Context

Many middleware technologies– CORBA, Jini, .Net, EJB, SOAP, COM

Problems require many technologiesMiddleware technologies evolveMiddleware technology is crosscutting

30

Distributed Systems Development Problem

Coupling of applications + 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

Difficult to Specify Design Models

ClassA

ClassB

Middleware features

ClassC

ClassB

ClassAClassC

Distributed Application

Complex Model

Transformation

Transformed model or code

Difficult to Specify Transformations

Distributed Application

32

Difficulties To Migrate Distributed Application

EliminateOld

Middleware

Refactor Application

Integrate New Middleware

….

..

ClassA

ClassB

ClassCDistributed Application

ClassA

ClassB

ClassCPIM

ClassA

ClassDClassB

ClassCClassA

ClassDClassB

ClassC

New Distributed Application

33

The Automation ChallengePerson

-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

35Some slides by Robert B. France, CSU

Defining & Using TransformationsPerson

-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

Outline

IntroductionQuery, View Transformation OverviewTransformation challengesMapping models to code and vice versaExperiences & Lessons learned

36

37

Model to Model Transformation

CreateModel

Model AModel A

AA

BBCC

Model BModel B

MM

BBCC

AA

PPKK

38

class Department { private:          char name[40]; Student csc[100];public:     void manageStudents(){ csc[i]->register(); … csc[i]->grade(); … csc[i]->graduate();}}

Model BModel B

MM

BBCC

AA

PPKK

Model to Code Transformation - code generation

39

Are transformations the heart of MDE?

MDE = models + transformationsTransformation-driven development?– Specify models– Evolve models

Model BModel B

MM

BBCC

AA

PPKK

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.

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

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

Horizontal Transformations

Refactoring: Improving model quality– E.g., applying patterns to designs

• Requires precise representation of patterns

Inferencing: Inferring properties from modelsAnalyzing: Extracting information needed for analysisComposition/anti-composition

44

Refactoring and Realization Example

45

Simple Model Inferencing Example (work of A. Evans et al.)

A

B C

Dm..n

p..q

DDp..q

*

*

p..q

Rel

Rel01

Rel02

Rel01 Rel02 Rel

A

B C

Dm..n

p..q

Rel

46

Transformation Conceptual Model

Rigorous Analysis• static analysis• dynamic analysis

feedbackfeedback

based on

TransformationMetamodelSource Metamodel

conforms to

Source Model

Target Metamodel

conforms to

Target Model

feedback

Transformation

47

Example

UML ModelFormal ModelFormalization

feedback

UML MetamodelFormal Language Metamodel

conforms toconforms to

based on

UML-FLMetamodel

Query, View, Transformation Standard

49

Query View Transformation Standard

Standard language-based concepts for specifying and implementing transformationsBased on best available experience (!)– and other concerns …

Supports hybrid declarative, imperative styles

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 matchingImperative 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

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

QVT Transformation ExampleSimple UML meta-model

53

Simple RDBMS meta-model

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 model Target model

55

Transformation specification Conceptual Model

based on

TransformationMetamodelSource Metamodel

conforms to

Source Model

Target Metamodel

conforms to

Target Model

feedback

TransformationEngine

Input Model Output Model

conforms to conforms to

56

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

}

57

Graphical Representation

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

Simple RDBMS meta-model

In Class Exercise

Create a QVT transformation for converting a sequence diagram to a class model.

60

61

QVT Transformation Example

Transformation model

Input model

62

QVT Transaction Example

Transformation model

Source transformation model

63

QVT Transformation Example

Target transformation model (part a)

64

QVT Transformation Example

Target model (part b)

65

QVT Transformation Example

Target model (part c)

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

Devon M. Simmonds

Introduction to the Model-Driven Architecture (MDA)

Slides include some created by Richard Mark Soley

68

Outline

Software contextThe OMGThe MDA

Current Software Context

Heterogeneity is permanentProblems require many technologiesMiddleware technologies constantly changeMiddleware technology is crosscutting

69

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

Problems Require Many Technologies

Multiple OSMultiple programming languagesEtc.

71CSC550 Software Engineering

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

Technologies Constantly Change

How can companies protect their software investments as the infrastructure changes?

73

Protecting Software Investment?

Tracking the next best thingProtecting your investment in existing software baseRetaining qualified staffMaintaining existing code base

Integrating what you’ve built– With what you will build!

74

Where Can We Agree?

There will not be consensus on hardware platformsThere will not be consensus on operating systemsThere will not be consensus on network protocolsThere will not be consensus on programming languages

There must be consensus on interfaces and interoperability!

OMG to the rescue! 75

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

Who Are OMG?

AT&T

BEA

Borland

Boeing

CA

Citigroup

Compaq

Compuware

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

OMG’s Major Successes

Common Object Request Broker Architecture– CORBA® remains the only language- and platform-neutral interoperability standard

Unified Modeling Language– UMLTM remains the world’s only standardized modeling language

Common Warehouse Metamodel– CWMTM, the integration of the last two data warehousing initiatives

Meta-Object Facility– MOFTM, the repository standard

XML Metadata Interchange– XMITM, the XML-UML standard

78

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

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

Model Driven Architecture (MDA)

[From OMG website]

An initiative to address pervasive middleware features

Make models 1st class entities.

Create technology-based models separate from business logic models.

Support automated transformation of models

Modeling in UML

[From OMG website]

MDA Goals

– Portability– Interoperability– Reusability– Platform Independence– Reduction in complexity

• Model to model transformations

82

83

Basic MDA

PIM

ModelTransformation

CORBAPSM

J2EE .Net.Net

– Platform Independent Models (PIM)

– Mappings : PIM <==> PSM • QVT, MOF 2.0 (a

standard for describing transformations)

– Platform Specific Models (PSM)

Computation Independent (Business) Model

Platform Independent Model

Platform Specific Model

T1

T5

T6

T7

T2

T4

MDA proposesmodel-to-model transformations

T1 – T7 are transformations

The MDA – Models & Transformations

T3

84

Platform Independence?

Depends on the selection of the target platform! (see next slide)

85

86

Aspect Oriented Model-driven Development Framework (AOMDF)

Model B map-pings

Develop source models

Develop Model Amappings

SpecifyTransformation

Apply Model Amappings

ApplyTransformation

Model A map-pings

SourceModel A

TargetModel A

TargetModel B

Source Level

Transformation Specification

Phase

Target Level

SourceModel B

Composition

Composition

transfo

rmatio

ns

transfo

rmatio

ns

Specification

87

MDA & Code Generation

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 SpecificityImplementation of new applications for different platforms.Productivity - 30% increase with a model-driven engineering approach.

The MDA boasts many success stories!

88

See Some Proof of Concept!

89

90

______________________Devon M. Simmonds

Computer Science Department

University of North Carolina Wilmington

_____________________________________________________________

Qu es ti ons?

End of This Module

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

______________________Devon M. Simmonds

Computer Science Department

University of North Carolina Wilmington

_____________________________________________________________

Qu es ti ons?

The End

Other Slides

93

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

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

Behavioral Elements of UML Metamodel

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 messageand an operation?2. Can you derive the relationship between a classand a lifeline?

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

Metadata and the UML

Metamodel

Next