1. Sheet 1 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 UML to XML-Schema Transformation: a Case Study in Managing Alternative Model Transformations in Model Driven Architecture Ivan Kurtev, Klaas van den Berg, Mehmet Aksit University of Twente, the Netherlands

2. Sheet 2 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 Outline Alternative Model Transformations in MDA; Case Study: Transformation from a UML Class Model into XML Schemas; Example: Deriving Extensible XML Schemas; Managing Alternative Transformations: Transformation Space; –Construction of Transformation Space; –Reduction of Transformation Space; –Reduction of Transformation Space on the basis of Quality Properties; Discussion;

3. Sheet 3 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 Basic MDA Concepts Basic concepts in Model Driven Architecture (MDA); Models: Model Transformations –The MDA Pattern (from “MDA Guide”):

4. Sheet 4 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 Alternatives in Model Transformations M2: A given construct from the source meta-model may be mapped to more than one construct in the target meta-model. M1: This results into alternative transformations for the instances at level M1. The model level (M1) and the meta-model level (M2) in the four level Meta Object Facility (MOF) modeling stack:

5. Sheet 5 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 The Problem with Alternatives Generation and Selection Problem 1: Lack of support for identification of alternative transformations –Transformation to the desired model may not always be obvious and trivial; Problem 2: Selection among Alternatives –Alternatives differ in their Quality properties such as Extensibility, Adaptability, Performance; Alternative Transformations Analysis must be addressed explicitly in the MDA software development process!

6. Sheet 6 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 Case Study: UML to XML-Schema Transformation

7. Sheet 7 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 Example: Deriving Extensible XML Schemas We aim at deriving extensible XML schemas. New specializations of ExamItem are expected. This might affect the representation of Exam in the resulting schema. UML Source Class Model

8. Sheet 8 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 Two of many Alternative XML Schemas <element name=’examItem’ type=’examItemType’ abstract=’true’/> ……………….. ……. <element name=’multipleChoice’ type=’multipleChoiceType’ substitutionGroup=’examItem’/> <element name=‘fillInTheGap’… substitutionGroup=‘examItem’/> In the first schema it is not possible to extend the alternatives of. In the second schema the addition is modular and does not require changes in the rest of the schema components. Schema 1:Schema 2:

9. Sheet 9 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 MDA Transformational Problem The process of Alternatives Generation and Selection is based on the notion of Transformation Space Selection is based on Quality Requirements

10. Sheet 10 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 Transformation Space Alternative Space Analysis Activity

11. Sheet 11 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 Set of dimensions: one dimension for every (relevant) element from the source model; Coordinate set for every dimension –Coordinate: selected among the constructs in the target meta-model; Point in Transformation Space: represents alternative transformation for the source model Step 1: Constructing Transformation Space Coordinate sets for XML Schema Meta-model: Components: –Complex Type (CT); –Element (E); –Attribute (A); –Attribute Group (AG); –Model Group (MG); Relations: –Containment (Cont); –Reference (Ref); –Derivation (Der); –Substitution (Subst);

12. Sheet 12 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 The space includes only two classes from the source model (ExamItem and Open) and the generalization between them (denoted as ExamItem_Open) Example of Transformation Space 4 x 4 x 5=80 alternatives CT – Complex Type E – Element MG – Model Group AG – Attribute Group Der – Derivation Subst – Substitution Cont – Containment Ref – Reference

13. Sheet 13 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 Step 2: Reducing Transformation Space 20 alternatives 12 alternatives Two operations for selection and exclusion from a space are defined. Selection from space: (e.g. ExamItem to Element or Complex Type) Exclusion from space: (exclude Element and Reference) Select from S where <(ExamItem.E or ExamItem.CT) and (Open.E or Open.CT)> Exclude from S where <(ExamItem_Open.E or ExamItem_Open.Ref) >

14. Sheet 14 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 In this example the Quality Model is the model of Extensibility; Model elements are: –Extensible; –Inextensible; Our technique allows merging of quality properties with a transformation space; Step 3: Reducing Transformation Space based on Quality Requirements

15. Sheet 15 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 Operation Merge merges two spaces into one. In our example the resulting space contains information about the extensibility properties of the model elements Merging Quality Properties with Transformation Space The software engineer may be supported by heuristics during the selection process. XML Schema best practices may be used in our example to select extensible schemas.

16. Sheet 16 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 Result Set of Alternative Transformations After applying some reduction steps and taking into account the quality properties, two alternative transformations from the space are selected: Number…ExamItemOpenExamItem_Open… 1 EEESubst 2 EECTDer Dimension in Source Alternative Transformation Coordinate in Target

17. Sheet 17 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 We presented a technique for Alternative Transformation Space Analysis for MDA transformations –Transformation Space is the main concept in that technique; Transformation Space: –Is NOT a transformer; –Is NOT a transformation specification; Not all alternatives in the Transformation Space are explicitly generated; Conclusions

18. Sheet 18 Forum on Specification and Design Languages (FDL), Frankfurt, September 2003 More complex mappings (not only 1:1); More complex quality models; Balancing quality factors; Tool support – adaptation of existing prototype; Handling large transformation spaces; Discussion