model driven engineering evolution or utopia

CAS 747 - Software Architecture and Reverse Engineering, 2006

Model Driven EngineeringEvolution or Utopia

by Magdin Stoica

McMaster UniversityMarch 14, 2006

CAS 747 - Software Architecture and Reverse Engineering, 2006 2

Outline

What is Model Driven Engineering (MDE)?

What is Model Driven Architecture? What about Agile MDA?

Model Driven Development… what is this?

Domain-Oriented Programming? Object, aspect and now domain?

What is a model?

What is a metamodel?

Meta-metamodel? Where do we stop?

Why do we need to be “driven by a model”?

Is it applied in the industry? How?


Context

Complexity of software systems is ever increasing

Has anything fundamental changed since late 1950s?

… since the introduction of third generation languages (3GL)?

Things surely changed Structured Design Object-Oriented Design Component-Oriented Design Middleware platforms, virtual machines

How fundamental are these changes?


4GLs

Fundamental EvolutionLe

vel o

f Abs

tract

ion

1s and 0s

Assembly

3GLs

4GLs

Machine

OS

VM

Programming Platform Networking

Custom

Network Protocols

MiddlewareMiddleware Platform


Motivation for MDE

Platforms complexity (thousands of inter-related classes)

Increasing rate of evolution

Lack of integrated view

Inability to verify design properties at design time

A pictures worth a thousand words

Raise the level of abstraction of the programming environment

Enterprise centric computing

Resilience to change: personnel, requirements, development platforms and deployment platforms

Increasing system’s longevity


Enterprise Centric Computing

Component-Based Development (CBD)

Architecture styles, architecture and design patterns

Distributed computing and middleware platforms

Declarative specification with code generation or runtime interpretation

Enterprise Application Integration (EAI)

Business to Business Integration (B2Bi)

Design by contract: preconditions, postconditions and invariants


Model Driven…

Model Driven Engineering vs. Model Driven Development

Model Driven Architecture vs. Model Driven Engineering

Agile MDA vs. MDA

Other model driven approaches Model Integrated Computing Model-Centric Software Development Software Factories

Domain-Oriented Programming vs. MDE

MDE vs. CASE


Model Driven Engineering Defined

Creating software systems from models with code generators

… wait a second, aren’t we doing this today?

Raising the level of abstraction: domain-specific languages

Graphical languages: a picture is worth a thousand words

Code generators and model transformations

Automation is a key characteristic

Executable specification. Oxymoron or today’s reality?

The model becomes the main development artefact

From programmers to modelers


What is a model?

Model: set of statements about some system under study (SUS)

Statement: expression about the SUS that can be considered true or false

ModelStatement

valid : boolean

ElementSUS

1..*1..*

1..*

1..*

0..*

+object of statement1..*

0..*

1..*


Model Types

Descriptive models A descriptive model is correct if all its statements are true for SUS By definition incomplete; describes aspects of SUS Usually used in scientific disciplines The question is: “Is the model correct ?”

Specification models A specification model is correct by definition. All its statements are true

by definition. They are axioms. A SUS is correct relative to a specification model if no statement in the

model is false for the SUS Usually used in engineering disciplines The question is: “Is the SUS correct ?”


ModelStatement

valid : boolean

Element

Descriptive Model Specification Model

SUS

1..*1..*

1..*

1..*

0..*


0..*

1..*

<<describes>> <<specifies>>

Model Types


Models and Interpretations

Model Interpretation: mapping between a model’s elements and the elements of the SUS.

Interpretations give model meaning as systems are created by interpreting a model

Interpretations can be invertible allowing us to create models that represent a SUS

A model can have multiple interpretations


ModelStatement

valid : boolean1..*1..*

Element

1..*

0..*


0..*

Descriptive Model

Specification Model

SUS

1..*1..*

<<describes>> <<specifies>>

Interpretation

Models and Interpretations


Models and Theories

Theory: mechanism to deduce new statements about a SUS from statements already in a model of SUS

Theory allows us to reason about the model and extend it Class model can be extended with an object model through class

modeling theory

Theory enables one to verify a model’s conformity to the theory An interaction model can be verified to be consistent or not with a class

model using class modeling theory

Theory of descriptive models can be verified to be correct

Theory of specification models is correct


Models and Theories

Statementvalid : boolean

Model

1..*1..*

Theorycorrect : boolean

1..*<<conforms to>>

<<uses>> <<produces>>

1..*


Models and Languages

Model is expressed through a modeling language

Multiple languages can describe the same model. For example a software system model can be expressed through UML, XML, Text (HUTN)

Model Language

1..*

<<expressed by>>

1..*


Metamodels Why do we need metamodels?

A metamodel is a specification model

As specification model, it is correct by definition

As specification model, it specifies a SUS

The SUS of a metamodel is a modeling language

A metamodel specifies how another model can be expressed thus it specifies a modeling language

A metamodel, being a model is also expressed using a modeling language

Reflexive metamodels


ModelLanguage

1..*1..*

<<expressed by>>

Metamodel

<<specifies>>

Specification Model

Metamodels

SUS

Language Reflexive Metamodel<<expressed by>>

<<specifies>>


Models – Putting It All Together

Statement

valid : boolean

Element

Descriptive Model

SUS

Specification ModelInterpretation

1..*

0..*


0..*

1..*1..*

<<describes>><<specifies>>

Theory

correct : boolean

<<uses>> <<produces>>

Model

1..*1..*

1..*1..*

<<conforms to>>

Language

1..*1..*

<<expressed by>>

Metamodel

<<specifies>>


Model Characteristics8

Abstraction

Understandability

Accuracy

Predictiveness

Inexpensive

Observable


Model Transformations

Platform Independent Model (PIM) Primary development artefact Uses a domain-specific language

Platform Specific Model (PSM) Derived from a PIM to target a specific technology or platform (e.g.

EJB, .NET) Uses a technology specific language

Model transformation take us from PIM to PSM. Reverse engineering takes us back. But is it feasible?

Approaches to model transformation Using 3GL to implement the transformation; large semantic gap Using XML and XSLT: semantic gap even larger Rule-based transformation with visual languages


Model Driven Architecture

A concrete approach to MDE in process of being standardized by the Object Management Group (OMG)

Initiated in late 2000 had a first draft released in 2001

An interim detailed definition of MDA was released in mid 2003

Final version expected in 2006

MDA Technologies Unified Modeling Language (UML) Meta-Object Facility (MOF) XML Metadata Interchange (XMI)


MDA Models, Metamodels

Instances of metamodels expressed using MOF; consist of model elements and links between them.

Model elements can have attribute values of primitive types

The metamodel specifies the abstract syntax of the language used to describe models and is expressed in the MOF language

Metamodel

Model

+language specification

Object(from MOF)

0..*

+objects

0..*

Primitive Type(from MOF)

Link(from MOF)

Element(from MOF)

1..*1..*

1..*1..*

...


MDA Model Transformations

Transformation are specified through specification models

Model transformation specification determines how a set of output models results from a set of input models

Transformation specification is made of elements (for rule-based implementations can be equated with a rule)

Model Transformation Specification

Model Transformation Specification Element

0..*0..*

Directed Model Transformation Specification

Model Transformation Formal Parameter1 2..*1

+parameters

2..*

1..*1..*+inParameters 1..*1..* +outParameters

Metamodel

0..* 1

+metamodel

1

Model

0..*


MDA Model Transformations (cont.)

Executing a transformation produces transformation records Transformation record links groups of objects in the input models to

the transformed objects in the output models with traces Transformation record binds input models to formal input

parameters and output models to the output parameters

Currently, MDA model transformation are performed through Direct model manipulation XML Metadata Interchange (XMI) and XSLT UML Action Languages (proposal stage) Graph-based transformation languages


Transformation Records

Model Transformation Specification Element

Trace

10..* 1

+templateElement

0..*

Transformation Record 0..*0..*

+traces

Object(from MOF)

0..*0..*+inputObjects

0..*0..*+outputObjects

Model Transformation Actual Parameter

2..*2..*+parmeters

Model

0..*+objects 0..*11+model

Metamodel

+language specification

Model Transformation Formal Parameter

11+parameterDefinition

+metamodel

0..*

1

0..*

1


MDA Modeling Languages

Unified Modeling Language (UML) is the de-facto standard for object-oriented software modeling

UML goes beyond software modeling and can be extended and customized through UML profiles CORBA UML profile CORBA Component Model UML profile Enterprise Application Integration UML profile Enterprise Distributed Object Computing UML profile QoS and Fault Tolerance UML profile Schedulability, Performance and Time UML profile Testing UML profile

How is UML specified?


Meta Object Facility (MOF) Meta-Language

UML’s abstract syntax is specified via Meta Object Facility

MOF language is also used to express other metamodels Common Warehouse

Metamodel (CWM) CORBA CCM Metamodel

MOF Example

Model Element

name : Name

Structural Feature

multiplicity : Multiplicityordering : OrderingKind

Behavioural FeatureisQuery : Boolean

Attribute

initialValue : Expression

Operation

concurrency : CallConcurrencyKindspecification : String

Namespace

Classifier Feature

visibility : VisibilityKind0..*0..1 0..*

+feature{ordered}

+owner

0..1


MDA Metalevels

Meta-Object Facility

Metamodels

Models

Systems

M3

M2

M1

M0Customer John, Customer Jane, Account 23456

class Customer, class Account

UML Class, UML Activity, UML State

MOF Classifier, MOF Link, MOF Model Element


Counter Point: MDA Critiques

UML semantics are not precise UML metamodel is large and poorly partitioned UML profiles provide only limited extension mechanisms Diagrams cannot be interchanged No support for view-points Object Constraint Language lacks formal definition through a

metamodel UML and MOF are subtly misaligned All these issues are acknowledged by OMG and are being

addressed. We are on the right road, we just haven’t reached the destination yet


Counter Point: MDE Critiques

Are platform specific models viable? Who creates them? Why?

Can domain experts rather than software engineers create software system that get auto-magically generated?

CASE had limited adoption. Things changed since then but have they changed enough? Code generation techniques advanced. By how much, really? We have standards, reusable components, patterns and middleware

platforms; true, but they are constantly changing.

There are pictures that only worth one word. In such cases words are better

Code generation still needs to advance and it will MDE tools are needed and they will be available


MDA Successes

Rhapsody by I-Logix supports advanced code generation, execution, simulation and debugging at model level15.

Deutsche Bank AG used MDA and ArcStyler to embed existing Cobol Mainframe Application into web-based system16

Lockheed Martin uses MDA to develop the F-16 Modular Mission Computer Application Software to achieve cross-platform compatibility and increased quality and productivity. They used iCCG17

Daimler Chrysler uses MDA in the development of their Electronic Production Planning reaching automation levels from 20% to 100%18

http://www.omg.org/mda/products_success.htm


Conclusions

“Models help us understand a complex problem through abstraction”8

“[MDD] represents the first true generational shift in basic programming technology since the introduction of compilers”8

Domain modeling languages may become the true 4GLs MDA may have shortcomings but it is an organized and standardized

approach to MDE. Research effort should be spent evolving it, not replacing it

Automation techniques need to evolve further Software development tools will be transformed fundamentally Developers will have to learn to think at a level of abstraction above

the one currently offered by 3GLs MDE still addresses accidental complexities in building software

systems. Software engineering will still be hard to do


MDE

MDE – Evolution or Utopia ?

MDE is preparing to become a true 4th generation software development paradigm evolution

Domain experts rather than software engineers creating software systems using domain-oriented programming utopia

Evo

lutio

n

1s and 0s

Assembly

3GLs

Programming

4GLs


REFERENCES

1. David S. Frankel, Applying MDA to Enterprise Computing, Wiley Publishing Inc., ISBN 0-471-31920-1

2. Douglas C. Schmidt, Model-Driven Engineering, IEEE Computer Magazine, February 2006

3. K. Balasubramanian et al., Developing Applications Using Model-Driven Design Environments, IEEE Computer Magazine, February 2006

4. Adam Childs et al., CALM and Cadena: Metamodeling for Component-Based Product-Line Development, IEEE Computer Magazine, February 2006

5. Robert B. France et al., Model-Driven Development Using UML 2.0: Promises and Pitfalls, IEEE Computer Magazine, February 2006

6. Dave Thomas, MDA: Revenge of the Modelers or UML Utopia, IEEE Software Vol. 21, No. 3, 2004

7. Stephen J. Mellor et al., Model-Driven Development, IEEE Software Vol. 20, No. 5, 2003

8. Bran Selic, Pragmatics of Model-Driven Development , IEEE Software Vol. 20, No. 5, 2003

9. Ed Seidewitz, What Models Mean , IEEE Software Vol. 20, No. 5, 2003

10. Conrad Bock, UML without Pictures, IEEE Software Vol. 20, No. 5, 2003


REFERENCES

10. Shane Sendall, Wojtek Kozaczynski, Model Transformation; The Heart and Soul of Model-Driven Software Development, IEEE Software Vol. 20, No. 5, 2003

11. Torben Weiss et al., Model Metamorphosis, IEEE Software Vol. 20, No. 5, 200312. Axel Uhl, Model Driven Architecture Is Ready for Prime Time, IEEE Software Vol. 20, No. 5, 200313. Scott W. Ambler, Agile Model Driven Development Is Good Enough, IEEE Software Vol. 20, No. 5, 200314. ORMSC White Paper V00-02, A proposal for an MDA Foundation Model, ormsc/05-04-01,

http://www.omg.org/docs/ormsc/05-04-01.pdf 15. Bruce P. Douglas, Model Driven Architecture and Rhapsody, www.uml.org/

uml_success_stories/Rhapsody_ECITelecom(V1).pdf 16. Interactive Objects, Deutsche Bank Bauspar AG Uses ArcStyler to Embed Existing Cobol Mainframe

Application into Modern Web-Based Systems, www.omg.org/mda/ mda_files/SuccessStory_DBB_4pages.pdf

17. Lockheed Martin, Lockeed Martin (MDA Success Story), http://www.omg.org/mda/mda_files / LockheedMartin.pdf

18. Interactive Objects, MDA Success Story – ePEP successful with Model Driven Architecture, http://www.omg.org/mda/mda_files /SuccesStory_DC_TSS_MDO_English.pdf

19. Steve J. Mellor, Agile MDA, http://www.omg.org/mda/mda_files/Agile_MDA.pdf20. Dave Thomas and Brian M. Barry, Model Driven Development – The Case for Domain Oriented

Programming, Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications 2003

model driven engineering evolution or utopia

Documents