1. Model-Driven Architecture & Software Factories
April 24, 2006
Radhika Pasumarthi
Bhavesh Thakker

2. Agenda Model Driven Development (MDD) Model Driven Architecture (MDA)
Eclipse Modeling Framework (EMF)
Software Factories (SF)
Discussion – MDA vs. SF
Conclusion
MDD based technologies: MDA and SA
Purpose of the emerging methodologies
Example partial MDA implementation – EMF
Discussion on Software Factories by Radhika
Comments on MDA and Software Factories
Concluding Remarks

3. MDD – Why? move from documentation to automation
language-based abstractions - numerical encoding > assembly > structured > object-oriented languages > byte coded languages and design patterns
In each generation, language designers produce constructs for lessons learned in the previous generation, and then architects use them to build more complex and powerful abstractions.
seek to increase productivity and predictability in software development using methodologies
Ref:
Industrializing Software Development: reused enough to more than recover the cost of their development
inability of the software industry to meet projected demand using current methods and practices
encapsulate their knowledge as reusable assets that others can apply
automate pattern application

4. MDD – Concerns
visualize the domain and generation of implementation artifacts
graphically represent code syntax and code concepts or domain concepts and structures
clear distinction between domain engineering and application engineering.
domain - application platform
application – application implementation.
model portability, to be able to bridge a model between different meta-modeling languages
creating usable models that ease knowing code assets make it easy to inventory and visualize them
Domain visualization - model more abstract concepts, such as 'what is a customer,' 'what is a purchase order' and 'what is an address.‘
while speaking of visualization we ignore the underlying technology thus make a clear distinction between the problem and solution domain
Anothing concern is that of porting models and bridging them between various meta-modeling languages
Reusable models that make it easy keep track of your code assets

5. MDA - Introduction
requirement for cross-platform development arises from the fast-pacing technology scene and the resulting uncertainty – EJB 2 today, EJB 3 tomorrow, or is it .NET?
An approach to system specification that separates the two specifications of system functionality and its implementation on a certain technology platform.
Models: representation of a part of function, structure and/or behavior of a system
designed “bottom-up” (starting from the target platform)
trademarked by OMG [Object Management Group], a consortium of vendors and end users that is developing standards for implementing MDD
They are implementing MDA as their version of MDD
Idea is similar to MDD I.e. to separate system and implementation
And represent function, structure and behavior of a system through models
MDA is designed to be implemented from the bottom-up where initially the target platform or platforms are realized

6. MDA continued… MDA Best Practices
View to how an MDA implementation progresses
First we gather requirements, then model them platform-independently, then define mappings for platform-specific models
The progression continues with generated code that can be customized and executed on the target platforms
There is high re-use for Platform-Independent models which makes coding consistent and
consequently new technologies can be accomodated faster

7. MDA Process Another view to the hierarchy in the previous slide..
System/solution is model is derived from the domain/problem model which is transformed to the platform-specific model and eventually into executable code
CIM – Business
PIM – UML
PSM – Technology Specific
Explain the cycles: The models can be refactored to and transformed into a more finely tuned PSM to generate efficient output code

8. MDA continued…
Developing software as a DAG (directed acyclic graph) of platform-independent and platform-specific models (PIM, PSM) with transformations in-between.
CIM – Compuation Independent Model
high-level overview of the software system
PIM – Platform Independent Model
provides formal specifications of the structure and function of the system that abstract away technical details
PSM – Platform Specific Model
expressed in terms of the specification model of the target platform
DAG: meaning the steps to which we model the various aspects of the system, apply transform and execute cannot contain directed cycles because if they do then our system will be forever in optimization/transformation phase
Just to refresh the terminology:
CIM: something that non-technical members can operate on as it shows the needs of the system also called the requirements analysis model
PIM: here we need not worry about the technical details of the system, although make sure the system is implemented in UML as proposed by the CIM
PSM: here we include the specification of the system in terms of the technology being targeted

9. Eclipse
an extensible development platform and application frameworks for building software.
a framework for program development into which programs can be added
plug-in based framework
Tool builders contribute to the Eclipse platform by wrapping their tools in pluggable components
EMF Plug-in
following MDA* example built and executed based on the EMF plug-in
talk the text on the slide

10. EMF - Introduction Eclipse Modeling Framework (EMF)
Java framework and code generation facility for building tools and other applications based on a structured model
Exploits the facilities offered in Eclipse to...
Generate code without losing user customizations (merge)
Consistent and Efficient
Improve extensibility
Provide a UI layer
What is an EMF "model"?
Specification of your application's data
Object attributes
Relationships (associations) between objects
Operations available on each object
Simple constraints (eg. cardinality) on objects and relationships
Essentially it represents the class diagram of the application
EMF is a framework embedded within eclipse for building tools and apps based on a structure data model
the structured data model is simply a set of related classes used to handle the data which will be dealt with in an application.
Data Models are designed to generate efficient and extensible code which can be tackled through a UI.
There is also functionality to create editors and adaptors but we will not concentrate on all the features of EMF just to show a basic example of a weak implementation of the MDA
Read the EMF “model” part

11. EMF - Models Not exactly MDA Three EMF Framework models:
focus on structured data models
positioned in the middle between MDA and manual programming.
does not currently support all of the UML specification
lacks the ability to generate source code for behavioral models such as UML state charts, it does provide support for extension points (e.g., plug-ins) that allow developers to add missing MDA capabilities.
Three EMF Framework models:
ECore models - UML modeling
Code models - specially annotated Java code.
XMI – XML Metadata Interchange, XML based modeling
all mapped to a representation that allows for translation between models.
1.sub implementation of MDA
EMF supports the key concept of MDA of using models as input to dev and integration tools and consequently the code generation and XML serialization is ‘driven’ from the same model.
Read the rest of the slide

12. EMF – Code Generation Code Generation Highlights:
Model - provides Java interfaces and implementation classes for all the classes in the model, plus a factory and package (meta data) implementation class.
Adapters - generates implementation classes that adapt the model classes for editing and display.
XML Schema for the model.
Characteristics:
Generated files are intended to be a combination of generated and hand-written pieces
All the code generated is pattern based optimized within the context of the semantics involved
Editor - produces a properly structured editor that conforms to the recommended style for Eclipse EMF model editors and serves as a starting point from which to start customizing.

13. EMF – Example Model
Just explain what the model does

14. EMF – Annotated Java Model
package org.eclipse.example.library;
import java.util.List;
/** */
public interface Library {
String getName();
type="Writer" containment="true"
List getWriters();
type="Book" containment="true"
List getBooks(); }
Ecore model is created within Eclipse via wizard and the following output:
Separating the generator model from the core model like this has the advantage that the actual Ecore metamodel can remain pure and independent of any information that is only relevant for code generation.
modelname.ecore - Ecore model file stored in XMI format, Canonical form of the model
modelname.genmodel - "generator model" for specifying generator options
decores .ecore file
EMF code generator is an EMF .genmodel editor
automatically kept in synch with .ecore file

15. Just explain what you did in the example you created

16. EMF – Generated Artifacts
Model
Interfaces and Classes
Type-safe enumerations
Package (metadata)
Factor
Switch utility
Adapter factory base
Validator
Custom resource
XML Processor
Edit (UI independent)
Item Providers
Item provider adapter factory
Editor
Model Wizard
Action bar contributor
Advisor (RCP)
Tests
Test cases
Test suite
Stand-alone example
Validation: Want to ensure your model's data conforms to constraints placed on that data? In three quick steps, this overview will give you an idea of how EMF's Validation Framework will let you do just that.
A skeleton adapter factory8 class (for example, POAdapterFactory) for the model. This convenient base class can be used to implement adapter factories that need to create type-specific adapters. For example, a PurchaseOrderAdapter for PurchaseOrders, an ItemAdapter for Items, and so on.
2. A convenience switch class (for example, POSwitch) that implements a “switch statement”-like callback mechanism for dispatching based on an object’s type (that is, its EClass). The adapter factory class, as just described, uses this switch class in its implementation.

17. EMF – Generated Artifacts (cont…)
Interface and implementation for each modeled class
Includes get/set accessors for attributes and references
EMF generates two more interfaces and implementation classes:
Factory
create instance of model objects
Eg: Library aLib = LibraryFactory.eINSTANCE.createLibrary();
Package
class provides access to model metadata

18. Software Factories
a development environment configured to support the rapid development of a specific type of application
less concerned with portability and platform independence than MDA, and more concerned with productivity
apply select patterns of automation to existing manual development tasks
UML not an actual software development artifact

19. Software Factories (cont…)
A software factory contains three key ideas: a software factory schema, a software factory template and an extensible development environment
Instead of having to build a whole application from scratch, developers using a software factory build only the parts where the application differs from other members of the family. The rest is provided by the software factory.

20. Software Factory Definition
A software factory is a software product line that configures extensible tools, processes, and content using a software factory template based on a software factory schema to automate the development and maintenance of variants of an archetypical product by adapting, assembling, and configuring framework-based components.

21. Software Factory Schema
A directed graph whose nodes are viewpoints and whose edges are computable relationships between viewpoints called mappings.
Describes the artifacts that must be developed to produce a software product
Recipe for building a family of software products

22. Software Factory Schema

23. Software Factory Templates
Describes Domain Specific Languages, Tools, Patterns and Frameworks
Consist of Code(DSLs) and Metadata that can be loaded in extensible tools
Tools produce specific type of software from the code and metadata
Software
Factory
Template
(Code +
Metadata)
Software
Product
Extensible Tools

24. Software Product Line
Software Product Line produces a Family Software Products
A Software Product Family is a set of products whose members vary, while sharing ,any common features
Microsoft Office (Word, PowerPoint, Excel, InfoPath, Access etc.)
Accounting Software Suite for different Industries
Problems common to family members can be solved collectively
Thus Software Product Line can produce a family of products more quickly, more cheaply, and with higher quality than producing them individually

25. Why Domain Specific Languages?
UML is good for documentation but insufficient for generating code or software automation
Failure of CASE Tools
Did not Exploit Platform Features and produced naïve, inefficient and LCD code
DSLs are designed to express model by targeting a narrow domain
Captures concepts used by people who work for a domain

26. Building a Software Factory

27. Building a Software Factory
Product Line Analysis
What products will be developed?
Product Line Design
How the products will be developed?
Design DSLs
Product Line Implementation
Build Software Factory Template

28. Building a Software Product
Problem Analysis
Product Specification
Product Design
Product Implementation
Product Deployment
Product Testing

29. MDA vs. Software Factory
MDA pure MDD approach
focus on platform independence
UML - modeling language
Requires UML experts for model comprehension
Greater learning curve due to complexity and individuality of using MDA based tools
SF development methodology
focus on product line development
UML – documentation
No misinterpretation as DSLs comprise the problem domain
High expense of DSL and Code Generator development
Pure MDD meaning automation,

30. MDA - Issues
MDA marks a significant step forward, but then model-driven development is still just a form of software development and has to answer all the well-known questions:
How to bridge the gap between business specification and technology?
How to enforce architectural and design guidelines while maintaining agility?
How to collaborate in a software development effort?

31. Conclusion Improved quality and reliability Which method to use?
Generated code less error-prone
Which method to use?
Depends on the problem domain, skill set, development tools and the idea of the intended solution
SA recommended for developing product lines
One-off development expensive in terms of time, budget and resources
MDA can be used for one-off development or product line development

32. Thank You!
Questions…