Model Driven Software Development 4th Year project 2014 Jimmy Kenny - A00177486

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

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

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

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

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

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

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

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

Key concepts of MDA Jimmy Kenny

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

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

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

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

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

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

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

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

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

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

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

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

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