A seminar in advanced Software Engineering concerning using models to guide the development process, and QVT to transfer a model into another model automatically

1. MODEL-DRIVEN ENGINEERING
in Practice

2. The $800-Million Bombshell (Motivation)
• The following was the code for controlling long-distance
phone traffic routing in USA:
• …
switch (caseIndex) {
case‘A’: route = routeA;
…
break;
…
case‘M’: route = routeM;
…
case‘N’: route = routeN;
…
break;
…}
Missing “break”
statement!
When this code ran (in 1990), the entire US Northeast lost
long-distance phone service

3. Engineering Model
A reduced representation of some system that highlights
the properties of interest from a given viewpoint
Functional ModelModeled system
 We don’t see everything at once
 We use a representation (notation) that is easily understood for
the purpose on hand

4. Models vs. Systems
Differences due to:
• Unique properties of actual
construction materials
• Construction methods
• Scaling-up effects
• Skill sets/technologies
• Misunderstandings
Can lead to serious errors and
discrepancies in the realization

5. Characteristics of Useful Models
• Abstract
• Emphasize important aspects while removing irrelevant ones
• Understandable
• Expressed in a form that is readily understood by observers
• Accurate
• Faithfully represents the modeled system
• Predictive
• Can be used to answer questions about the modeled system
• Inexpensive
• Much cheaper to construct and study than the modeled system
To be useful, engineering models must satisfy
all of these characteristics!

6. ModelTransformations • Computation-independent
Model
• Uses natural language
• Ex: state-chart diagram
CIM
• Platform-independent Model
• Does not specify any technology
PIM
• Platform-specific Model
• Built for a specific technology
• When technology evolves, a
new PSM can be generated
rather than rewriting it
PSM
BusinessAnalyst
Architect / Designer
Developer /Tester

7. Machine Code
Impossible?
TheAbstraction Gap
• Middleware makes MDA a potential reality
Level of
Abstraction
Generators
1
0..*
security
mortgages
1
0..*
borrower
mortgages
10..*
ownerhouses
House
-value:Money
Person
-ssn:Integer
-salary:Money
+getMortgage(sum:Money,security:House):Mortgage
Mortgage
-principal:Money
-monthlyPayment:Money
-start:Date
-end:Date
Machine Code with Operating System
Impractical?Use Operating System facilities
Unlikely?Use Middleware
Practical(ly)
Middleware with
Framework
Today!
AbstractionGap

8. Model Execution
X = cos (h + p/2)
+ x*5
X = cos (h + p/2)
+ x*5
?
 By formal analysis
 mathematical methods
 reliable (theoretically)
 software is very difficult to
model mathematically!
?
X = cos (h + p/2)
+ x*5
X = cos (h + p/2)
+ x*5
 By experimentation (execution)
 more reliable than inspection
 direct experience/insight
X = cos (h + p/2)
+ x*5
X = cos (h + p/2)
+ x*5
?
 By inspection
 mental execution
 unreliable

9. MDE Prospects
• The problem:
• We cannot keep implementing our applications using the
programming technologies of the late Fifties’
• The demands on functionality, reliability, dependability,
availability, security, and performance demanded of modern
software.
• We need to, can do, and have already done better!
• MDE:
• Increased levels of abstraction
• Open unified standards
• Increased levels of automation

10. Primary Forms of Automation for MDE
• Computer-based validation
• Formal methods (qualitative and quantitative)
• Computer-based testing
• Automated test generation, setup, and execution
• Computer-based model execution
• Particularly execution of abstract and incomplete models
-- when most of the important decisions are made
• Model transformations
• Code generation, between PSMs, …

11. MDE - Case Study
Project Description
• A simple web-based J2EE e-commerce system (Pet Store)
• Users can sign into a system and manage their accounts.
• Users can browse a catalogue of pets on the web site
(such as birds, fish or reptiles).
• Shopping cart functionality: Users can add pets to their
shopping cart and manage their shopping carts.
• Order functionality: Users can place an order for the
contents of their shopping carts.
• Web services. Users can query orders via a web service.

12. MDE - Case Study
Teams Description
• 2 development teams
• Traditional development lifecycle
• Model-driven Development style
• 1 senior J2EE architect + 2 experienced J2EE programmers per team
• Each team uses the same HTML, images and database schema.
• MDA team was required to use an MDA tool
• Traditional team was required to use leading J2EE IDE
• Both teams must use EJB in their code bases
• No further constraints

13. Savings Achieved
0% 36% 46% 28% No data
available
Total average savings achieved: 26%

14. Quantitative Results
development hours spent by each team:
Team Original Estimated
Hours
Actual Number of
Hours
Traditional team 499 507,5
MDA team 422 330
this corresponds to a 35% increase in
productivity when using MDA

15. QVT - Overview
• QVT stands for Query/Views/Transformations
• OMG standard language for expressing queries, views,
and transformations on MOF models
• Defines three model transformation languages. All of
them operate on models which conform to MOF 2.0
meta-models

16. QVT Transformation Languages
• QVT-Operational Mappings
• imperative language designed for writing unidirectional
transformations
• QVT-Relations
• declarative language designed to permit both unidirectional
and bidirectional model transformations
• QVT-Core
• declarative language designed to be simple and to act as
the target of translation from QVT-Relations

17. QVT Operational Structure
QVT MMb
Mb
conformsTo
conformsTo
based on
conformsTo
conformsTo
MOF
MMa
Ma
conformsTo
conformsTo
conformsTo
M1
M2
M3
Engine
Tab
based on
input output
executed

18. Operational Mappings in Use
• Case study: Flattening UML class hierarchies

19. Flattening UML Class Hierarchies
• Given a source UML model, transform it to another UML model
in which only the leaf classes (classes not extended by other
classes) in inheritance hierarchies are kept.
Rules:
• Transform only the leaf classes in the source model
• Include the inherited attributes and associations
• Attributes with the same name override the inherited
attributes
• Copy the primitive types

20. Example Input Model
name : String
ssn : String
Person
school : String
EnrolledInSchool
organizationName : String
Employed
Student Employee
«primitive type»
String
CarPhDStudent
firstName : String
lastName : String
FullName
name : FullName
Professor
carOwnership
supervisor
name : String
Course
street : String
city : String
Address
residesAtattends

21. Example Output Model
«primitive type»
String
Carname : String
ssn : String
school : String
PhDStudent
firstName : String
lastName : String
FullName
name : FullName
ssn : String
organizationName : String
Professor
carOwnership
supervisor
name : String
Course
street : String
city : String
Address
residesAtattends residesAt

22. ModelTransformation Expressed in
Operational Mappings Language
Overall structure of a transformation program:
transformation SimpleUML2FlattenSimpleUML(in source : SimpleUML
out target : SimpleUML);
…………………………………………………………………
main() {}
…………………………………………………………………
…helpers……………………………………………
…mapping operations………………
Signature:
Declares the transformation
name and the source and
target metamodels.
in and out keywords indicate
source and target model
variables.
Entry point:
The execution of the transformation starts here by
executing the operations in the body of main
Transformation elements:
Transformation consists of mapping operations
and helpers. They form the transformation
logic.

23. Mapping Operations
• A mapping operation maps one or more source
elements into one or more target elements
• Always unidirectional
• Selects source elements on the base of a type and a
Boolean condition (guard)
• Executes operations in its body to create target
elements
• May invoke other mapping operations and may be
invoked
• Mapping operations may be related by inheritance

24. Mapping Operations: Example (1)
• Consider the rule that transforms only leaf classes
• Selects only classes without subclasses
• Collects all the inherited properties
• Creates new class in the target model
mapping Class::leafClass2Class(in model : Model) : Class
when {not model.allInstances(Generalization)->exists(g |
g.general = self)}
{
name:= self.name;
abstract:= self.abstract;
attributes:=
self.derivedAttributes()->map property2property(self)->asOrderedSet();
}
Operation body
Signature and guard
name:= self.name;
abstract:= self.abstract;
attributes:=
self.derivedAttributes()->map property2property(self)->asOrderedSet();

25. Mapping Operations: Example (2)
mapping Class::leafClass2Class(in model : Model) : Class
when {not model.allInstances(Generalization)->exists(g |
g.general = self)}
Operation nameSource element
type
An optional sequence of
input/output parameters
Target element type
Guard
Operation Signature and Guard
The Guard is an OCL expression used to filter source elements of a given
type.The mapping operation is executed only on elements for which the
guard expression is evaluated to true.

26. name:= self.name;
abstract:= self.abstract;
attributes:=
self.derivedAttributes()->map property2property(self)->asOrderedSet();
The predefined variable self refers
to the source element on which the
operation is executed
The left-hand side of the
assignments denotes
properties of the target
element
Invocation of helper derivedAttributes
The keyword map is used to invoke
another mapping operation named
property2property over the
elements returned by the helper
derivedAttributes
Mapping Operations: Example (3)
The mapping operation body contains initialization expressions for the properties of
the target element.When an operation is executed over a source element the self
variable is bound to it and an instance of the target type is created.Then the
operation body is executed.
Operation Body

27. • Helpers are operations associated to a type that return a
result
• Both primitive and model types can be used
• Helpers may be used to perform complex navigations over
source models
• Helpers have:
• List of input parameters
• An executable body
Helpers

28. Helpers Example
query Class::derivedAttributes() : OrderedSet(Property){
if self.generalizations->isEmpty() then self.attributes
else
self.attributes->union(
self.generalizations->collect(g |
g.general.derivedAttributes()->select(attr |
not self.attributes->exists(att | att.name = attr.name)
)
)->flatten()
)->asOrderedSet()
endif
}
The context type of the helper
derivedAttributes Result type

29. Invoking Mapping Operations
……………………………………………………
attributes:=
self.derivedAttributes()->map property2property(self)->asOrderedSet();
……………………………………………………
mapping Property::property2property(in ownerClass : Class) : Property{
name:= self.name;
type:= self.type;
owner:= ownerClass;
}
Invocation of property2property on every
member of the set returned by
derivedAttributes query

30. Constructs for Managing the Flow of Control
• There are cases where more sophisticated control flow is needed.
The following imperative constructs are available:
• While
• forEach
• Break
• Continue
• If-then-else

31. QVT Future Improvements
• Tool support is still insufficient
• Many issues need further exploration:
• Performance;
• Testing;
• Scalability of transformations;
• Ease of use;
• Handling change propagation;
• Reuse mechanisms.

32. Thank you!
Presented by:
Anas Omar Basha
Hussein Al-shukheir
Abd Al-massih Yakeen
Munir Kamal
Hisham Alatrash