MDE in Practice
Download as PPSX, PDF0 likes431 views
The document discusses the significance of model-driven engineering (MDE) through examples and insights, highlighting the importance of engineering models that are abstract, understandable, accurate, predictive, and inexpensive. It presents a case study on web-based J2EE e-commerce development, comparing traditional and MDA approaches, showing a 35% productivity increase with MDA. Additionally, it introduces QVT (Query/View/Transformation) as a language for model transformations, emphasizing the need for further exploration in tooling and performance improvements.
MDE 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