1. Model Driven Software Development
4th Year project 2014
Jimmy Kenny - A

2. What is MDSD?
An approach to software development where models rather than code are the principal outputs of the development process
The Models can be used to communicate business and software solution information to the various stakeholders, end users and developers of the particular system
Source Code can be either partially or fully generated from the Models
Documentation about the Software System can be generated from the Models
MDSD aka MDE, MDD
Stakeholders don’t need to know code to gain information from the models
In reality full generation of code is had to achieve. Some elements of the code has to be written by Software Developer
Jimmy Kenny

3. Benefits of MDSD
Portability - Same Models can be used for deployment across different platforms
Interoperability – Models running on different platforms cannot directly talk to each other. MDSD can generate bridges that allow cross platform communication
Reusability - Models or parts of them can be readily reused in different projects
Increased Quality and Productivity
Using automatic code generation enforces coding standards
Coding errors reduced by automated or semi-automated development tools
Task automation frees up capacity of Engineering or QA resources
Portability good for well known platforms. Less well known platforms may need support for plug-in transformation definitions or write definitions yourself
Resusability – models are usually stored in some repository = available for resuse
Code generation – build in the standards in the transformation definitions
Jimmy Kenny

4. Benefits of MDSD
Shortage of Software Developers in industry. If we utilise models then they can be used by people with little or no coding skills
Models can be used to impart technical information about software systems to non-developers
Software created by MDSD is less sensitive to changes in technology and can readily be adapted to new technologies e.g. if there are changes to the platform running the software, the application does not have to be re-written from scratch – just update the code generator and transform the existing Platform Independent Models (PIMs)
Skill shortage – but it does require someone with very specialized skills to create the models in the first place and there is a shortage of people in the industry who can do this
Its easier to describe systems with models
Jimmy Kenny

5. Criticisms of MDSD
For complicated systems creating the models can be quiet complex
Tools available are not up to the job
Some projects are just not suitable for MDSD
Steep learning curve leads to increased costs
It might be more cost efficient to create these systems in the standard code driven way
Tools often need to be adapted for the particular domain of the system being developed
Why should a company invest in MDSD if their existing code driven methods can do the job cheaper
Jimmy Kenny

6. Model Driven Architecture
MDA is a framework underpinned by a set of principles and standards laid down by the Object Management Group (OMG) for applying MDSD practices. It supports the use of the Unified Modelling Language (UML).
The basic MDA Framework consists of Models, PIMs (Platform Independent Models), PSMs (Platform Specific Models), Languages, Transformations, Transformation Definitions and Tools that perform the Transformations.
The image is the OMG view of MDA
First put forward in a white paper in the 2000 – still relatively new concept
MOF = Meta Object Facility. It defines all other languages used in MDA. All modelling languages like UML and CWM are instances of MOF
CWM = Common Warehouse Metamodel – used for data mining. It defines mapping to database Schemas
Jimmy Kenny

7. Basic MDA Framework This a simple view of the MDA framework
A PIM is written in a specific language and is transformed into a PSM using a transformation tool.
The tool uses transformation definitions to be able to map elements in the PIM to elements in the PSM
Jimmy Kenny

8. Key concepts of MDA Metamodel
Modelling languages can be text based or have a graphical syntax like UML. Metamodels are a mechanism for defining these languages. It can be thought of as the grammar for a model.
A Model defines what elements can exist in a system
A Metamodel sets rules for what elements are allowed and what elements are mandatory in a Model
The UML metamodel, for example, defines the elements such as “Package”, “Class”, “Attribute” etc for use in the UML Model
Jimmy Kenny

9. Key concepts of MDA Model
A model is high level abstraction that describes a system. This could be a text document, or a diagram for example. In MDA the main models of concern are:
Computation Independent Model (CIM)
Platform Independent Model (PIM)
Platform Specific Model (PSM)
A CIM is the business model of a system and is independent of the software model. Because of this the CIM will not be considered in this study.
A CIM can be used to define the requirements of the system from which the PIM is designed
Jimmy Kenny

10. Key concepts of MDA
Jimmy Kenny

11. Key concepts of MDA Platform Independent Model (PIM)
A PIM is a model that’s independent of any platform and not concerned about any implementation technology. It therefore can be transformed to a number of different platform models (PSMs).
Platform Specific Model (PSM)
A PSM is a model that is linked to a specific software platform, eg. .Net, Java, C#
In MDA a PSM is created from a PIM using a Transformation process.
Jimmy Kenny

12. Key concepts of MDA Transformation
Transformations are at the core of the MDA process.
A transformation is an automated mapping of a model to another state – this could be another model, actual source code or some documentation.
Transformations are performed by transformation tools using Transformation Definitions
A Transformation Definition is a collection of Transformation Rules
A Transformation Rule defines how one or more elements in the source model should be transformed into one or more elements in the target model
Transformations are essential in the MDA process
Jimmy Kenny

13. Key concepts of MDA Transformation cont’d
In practice a transformation tool will take a PIM and transform into a PSM (or a number of PSMs) according to the rules and constraints of the transformation definitions. In turn the PSM will be transformed into code by the tool.
PIM to PIM also
Jimmy Kenny

14. The Project Goals Design an application using MDA principles
Gain an understanding of the concepts and methodologies of MDA
Evaluate the benefits and drawbacks of MDSD/MDA
Draw some conclusions on the future of MDSD/MDA
Jimmy Kenny

15. The Project Application
Ticketing System Requirements
System for generating and issuing tickets for events in different types/sizes of venues.
Venue Manager
Shall Create, Modify, View Venue Layout
Shall Create Show
Sales/Admin
Shall Create, Update, Delete Customer
Shall Reserve, Issue, Cancel Tickets
Customer
Shall Reserve Ticket
Use Case of ticketing system showing user interaction
Jimmy Kenny

16. The Project Application
Tool used was Enterprise Architect. Also tried MagicDraw
Standard UML diagram which is the PIM of system. Class diagrams showing attributes and operations. Also associations between classes. Note that attributes are usually declared public in PIMs
Ticketing System PIM
Jimmy Kenny

17. The Project Application
PSM created from PIM using Transformation Process
PIM transformed into PSM – Java Platform – using Transformation Definition
Note attributes are now private and the getter and setter accessor methods have been created
Allowing Encapsulation!
Ticketing System PSM (Java)
Jimmy Kenny

18. The Project Application
Shows Transformation Rule for mapping an attribute in the PIM to the PSM in java
Enterprise Architect’s own Proprietary Transformation language is shown here
Note:
Public changed to Private
Transformation Rule for Attribute (Java)
Jimmy Kenny

19. The Project Application
Java code shown here displaying private attributes and getters and setters
Java code created from PSM to Code Transformation
Jimmy Kenny

20. The Project Application
To create a database. You can automatically create a DDL from the PIM. Then an sql file can be generated to create the database. A number of different database types can be generated
SQL Query generated from DDL
DDL created from PIM to DDL Transformation
Jimmy Kenny

21. Project Evaluation My MDA Experience
I was not able to implement a full executable working application using MDA. This was mostly due to my own knowledge deficit and limitations of the tool.
Main findings:
Steep Learning Curve – Models, Metamodels, PIMs, PSMs, Transformations etc.
Tools overly complicated. Main tools evaluated: Enterprise Architect and MagicDraw
Lack of comprehensive tutorials
You can‘t define the internal dynamics of an operation in uml. This needs to be done in the transformation definition. This requires a high degree of expertise.
The built in Transformation Definitions of the tool don’t define the body of the operation/method
Jimmy Kenny

22. Project Evaluation
High degree of expertise required to write Transformation Definitions
The OMG have specified a standard for a Transformation Language called QVT (Query/Views/Transformation)
Industry has been slow to adopt this standard
Enterprise Architect uses its own proprietary transformation language. MagicDraw provides a QVT plugin for its tool.
Jimmy Kenny

23. Project Evaluation
This Project has become more of a Research Study on MDSD. In my thesis I investigate the issues I have encountered with MDSD and show that these are replicated in industry. Some of the main areas I focus on in the thesis are:
Experience of Industry with the MDSD methodology
Are the tools available up to the job?
MDSD is still in a pioneering state. This means that the cultural support within industry is limited and the institutional infrastructure (e.g. Educational Institutions) to support it is not fully developed.
What future is there for MDSD?
Great things were expected of MDA when first proposed by the OMG but it has not yet lived up to these expectations. Still a debate in Industry about its future. Ronan Barrett in Ercisson said that total PIM to PSM to Code is not realized anywhere in industry except for very specific scenarios. In reality only parts of the process are possible to implement using the tools and languages available.
Jimmy Kenny