1. Model-Driven Development
Brian Mitchell

2. Models & Code – Scenario #1≠
One-Time Engineering: The value of the model does not extend beyond the initial design because it is not maintained.

3. Models & Code – Scenario #2
Round-Trip Engineering: If not tightly controlled, the final model might not look anything like the original model, and the architecture might have shifted dramatically ≠

4. Models & Code – Scenario #3=
Reverse Engineering: The end-state model might be complicated (and of little use) since it was directly rendered from the implementation

5. Models & Code – Scenario #4
Idealized Approach: A Software Architect oversees the model evolution and the code evolution and ensures that they remain synchronized. As changes are made the model, code, or both are changed to minimize drift

6. Models & Code: State of Practice
The difficulty of preserving the value of creating a model is due in part to the effort to maintain both the model and code artifacts
There is limited value in creating models that become outdated because they cannot be readily used for maintenance
Models generated/reverse engineered from code are missing many abstractions and might be themselves too detailed to be of much use
Models are good for managing complexity so we continue to strive to use them in our design activities

7. Model-Driven Development Objectives
Move the focus of work from the programming space to the solution modeling
Increase productivity and reduce time-to-market by enabling development at a higher level of abstraction
Design using concepts in the problem domain rather than the constructs offered by a particular programming language

8. UML Modeling Revisited Again
Horizontal Modeling: Use different UML diagrams to model the structural and behavioral aspects of a system
Vertical Modeling: Create UML models to describe common aspects of a system at various levels of abstraction

9. Model-Driven Development – Vertical Modeling
Architectural Model
Domain Model
<<Model Transformations>>
Implementation Model (e.g., J2EE, CORBA, .Net)
Source Code

10. Working with a Collection of Models can be Challenging
Maintaining overall consistency is very challenging when working with multiple, interrelated, models
Automation is necessary to:
Maintain consistency between the models
Provide synchronization between the models
Ensure quality of the models
Without automated assistance the benefits of working with multiple models is questionable since the complexity of managing these models might exceed the complexity of developing a design without models

11. Automation Opportunities for Managing Multiple Models
Refinement: Logical progression from requirements to implementation
Example: Generating a state machine from a specification of a component
Reverse Engineering: Moving from more concrete artifacts to abstract artifacts
Example: Generating class diagrams from code, estimating subsystems from component interactions
Generating New Views: Generating new views from existing views
Example: Generate a deployment view using information about distributable and non-distributed components from another view

12. Automation Opportunities for Managing Multiple Models
Applying Software Patterns: Maximize flexibility, increase simplicity, and enhance maintainability by using design and architectural patterns
Refactoring Models: Ongoing change to a model can make it difficult and complex to maintain – refactoring models can improve its form
Similar objectives to source code refactoring

13. Model-Transformation – The key to automation
Model transformation involves taking one or more source models as input and automatically producing one or more target models as output
Model transformations require automation
Too complex to be useful without tool support
Tools should provide
Predefined transformation templates
The ability for users to define their own transformations

14. Example: Using Design Patterns to Transform A Model
Before
Transformation
After

15. Example: Using Design Patterns to Transform A Model
Before
The transformation process is trivial manually, but to be useful the transformation should be automated. More on this later…
Transformation
After

16. Model Transformation Requirements
A clear understanding of the syntax and semantics of the source and target models
The semantics of the source and targets can be expressed using meta-models
An approach to specify how to transform from one model to another model

17. Sidebar: MOF – A Standard for Meta-Modeling
OMG Standard: MOF=Meta-Object Facility
MOF is a UML model for describing the abstract syntax of meta-models
The UML 2.0 model is developed using MOF
Models can be transformed using metamodel representations of the source and destination models, themselves defined in MOF
We will see how this is useful for specifying model transformations later.

19. Model Transformation Techniques
Direct Model Manipulation
Transformations are programs, models have a manipulation API, target model created by executing a transformation program
Intermediate Representation
Transformation performed on an intermediate representation
Example: Model->XMI (XML)->XSLT->Model’, thus transformation encoded in a XML stylesheet
Transformation Languages
Custom languages for defining transformations from one model to another
Pattern Transformations
Use patterns to guide the transformation process

20. Direct Model Manipulation
Use a common language known to manipulate the model – e.g., Java, C/C++, C#, VB, …
Tools (e.g., Rational XDE) offer an API to manipulate the model
Benefits/Detriments of this approach:
Procedural code that users already know
The API tends to restrict the types of transformations that can be performed since general purpose languages often don’t provide suitable abstractions
UML Action Language is a procedural language to define model transformations
Tool support is limited at this point in time

21. Intermediate Representation Transformation Approach
UML models can be persisted to an XML format based on a standard schema called XMI
XML has a transformation language called XSLT
XSLT is for XML transformations, which is more “low-level” than desirable for model transformations
These transformations are difficult to do interactively

22. Customized Transformation Languages
Domain specific languages for model transformations
Its another language to learn
It’s a formal language, which is difficult for practitioners to deal with
Proposals exist to use UML as a visual transformation language, formal extensions via the <<stereotype>> mechanism
Use OCL as the language to select the source model elements for the transformation process

23. Pattern-Based Transformations
Define transformations using templates
The pattern engine binds the “pattern parameters” with the source model automatically or manually to produce the target model

24. Graph-Based Transformations
Idea: Represent UML models as graphs
Leverage work done on graph grammars and graph transformations
Graph transformations can be achieved by using graph rewriting rules
Based on graph theory
LHS: graph or subgraph to match
RHS: output graph created by applying transformation rules to the matched LHS

25. Desirable Attributes for Automating Model Transformations
Be executable and implementable in an efficient way
Support expressive, yet unambiguous, transformations that can modify existing models or create new models
Be productive for developers to use
Separate the selection from the transformation rules
Graphical whenever possible
Be able to combine transformations to make composite transformations
Be able to define the conditions under which a transformation is allowed to execute

26. Automated Model Transformations
Using Patterns to Guide Model Transformations

27. Patterns
Patterns describe a family of solutions for a class of reoccurring design problems
Patterns effective for communicating design experience to developers
The lack of formal specifications for patterns have limited pattern automation

28. Model Transformations with Patterns
UML to UML
Pattern-Based Refactoring
Define metamodels to characterize the refactoring activity
Develop the pattern metamodel by specializing the UML metamodel
Objective - Precise definition of the pattern solutions so that they can be located in, and applied to, the design space

29. A Manual Process
Identify the elements in the source model that will participate in the pattern solution
Gif, Jpeg Painter
Add new model elements as needed to realize the behavior and structure specified by the pattern
Image, ImagePainter
A trivial manual process for small systems, but tedious and error prone when applied to large systems

30. Automating Pattern-Based Transformations
Need to develop a precise specification of patterns
Need to define transformation rules
Use a metamodel approach to define the transformations, and for pattern-matching
Each pattern variation requires a specification
Pattern transformation specifications are used to embed a pattern into a design
Pattern
Pattern
Specification
Pattern
Transformation
Specification
1..*
1..*

31. Pattern-Based Refactoring Requirements
Problem Specification: A precise specification of the family of UML design problems that the pattern addresses
Solution Specification: A precise specification of the UML designs representing solutions of the pattern
Transformation Specification: A specification of problem-to-solution transformations

32. Metamodeling Approach
Extension of UML metamodel to define a pattern transformation
language
Extension of UML model to define model transformations

33. Example: Observer Pattern (GoF)
Observers register with subject, subject notifies all observers that an update is required, each observer updates itself by getting the new state from the subject

34. The Pattern Solution Specification for the Observer Pattern
The UML Metamodel for the PSS

35. Example Illustrating the Bindings Between A Conforming Class Diagram (left) and a Pattern Solution Specification (right) for the Observer Pattern

36. Example: Model of a Maze Game (GoF)

37. Analysis of the Maze Game Model
MazeGame class creates 2 different types of mazes – Bombed, and Enchanted along with the maze game parts (e.g., walls, doors, etc.)
The Maze game model cannot accommodate change without significant reengineering if new maze types or maze parts were added to the game
Abstract Factory pattern increases flexibility
Maze creation aspects are localized in factories that the MazeGame class can access.

38. Abstract Factory Pattern
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

39. Abstract Factory PPS and PSS
Abstract Factory Problem Specification
Abstract Factory Solution Specification

40. Abstract Factory Problem Specification
Binding to the PPS
Abstract Factory Problem Specification
MazeGame
Maze
Room
Bombed Maze
Door
Enchanted Maze
Wall
Role: Client
Role: Primary Product
Role: SubPart

41. Transforming to the PSS
Abstract Factory Solution Specification
Maze
Room
Maze Factory
Bombed Maze Factory
Bombed Maze
Door
Enchanted Maze Factory
Enchanted Maze
Wall

42. Enchanted Maze Factory
Mapping to the Pattern
Maze
Bombed Maze Factory
Bombed Maze
Enchanted Maze Factory
RoomWith Bomb
Enchanted Maze
Enchanted Room

43. Final Solution Refactored with the Abstract Factory Pattern

44. OMG – Model Driven Architecture

45. To Design With or Without Platform Specific Concerns
Common execution and deployment frameworks such as CORBA, .Net and J2EE impose platform-specific constraints on designs
When designing for these platforms
Should we create a platform independent models and a platform dependant models?
Should we create a combined model?
Can we generate or transform a platform-independent into a platform dependant model?

46. Generic Design Concerns are Handled Differently on Different Implementation Platforms
Examples:
Presentation
WinForms, JSP, Swing
Distribution
.Net Remoteing, EJB, RMI, Sockets
Object-Relational Database Synchronization
Entity-EJB, .Net DataSet
Security
Database, Certificate, Windows Integrated, Kerberos, …
Protocol Support
CSIv2, HTTP, SSL, TCP/IP, NetBios
And So On…

47. OMG’s Model Driven Architecture (MDA)

48. Model Driven Transformations in MDA
MDA is useful for abstracting platform transformations such as going from a domain model to a .Net or J2EE model

49. Tooling Support for MDA – Example: Optimal J Framework
Transformation Patterns
Functional Patterns
Platform Independent Model
Platform Independent Model
Domain Patterns
Technology Patterns
Platform Specific Model
Platform Specific Model
Application Patterns
Implementation Patterns
Code Model
Code Model
Code Patterns

50. MDA – Example PIM -> PSM for EJB[

51. Platform Specific Model for SOAP Web Service[

52. References
Robert France, Sudipto Ghosh, Eunjee Song, and Dae-Kyoo Kim, “A Metamodeling Approach to Pattern-Based Model Refactoring”, IEEE Software, November “A UML-Based Pattern Specification Technique”,
Robert B. France, Dae-Kyoo Kim, Sudipto Ghosh, Eunjee Song, “A UML-Based Pattern Specification Technique”, IEEE Transactions on Software Engineering, Vol. 30, No. 3, March 2004,
Shane Sendall and Wojtek Kozaczynski, “Model Transformation – the Heart and Soul of Model-Driven Software Development”, Technical Report,
David Frankel, “Using Model-Driven Architecture™ to Develop Web Services”, IONA Whitepaper,
E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.