1 / 15

Hafsteinn Þór Einarsson Helmut Neukirchen University of Iceland, Reykjavík, Iceland

An Approach and Tool for Synchronous Refactoring of UML Diagrams and Models Using Model-to-Model Transformations. Hafsteinn Þór Einarsson Helmut Neukirchen University of Iceland, Reykjavík, Iceland. Outline. Motivation Foundations Related Work Approach Prototype tool Discussion.

Télécharger la présentation

Hafsteinn Þór Einarsson Helmut Neukirchen University of Iceland, Reykjavík, Iceland

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. An Approach and Tool for Synchronous Refactoring of UML Diagrams and Models Using Model-to-Model Transformations Hafsteinn Þór Einarsson Helmut Neukirchen University of Iceland, Reykjavík, Iceland

  2. Outline • Motivation • Foundations • Related Work • Approach • Prototype tool • Discussion Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  3. 1. Motivation • Model-Driven Engineering (MDE): • Develop software based on high-level models instead of low-level source code. • Refactoring of models needed! • Most popular modeling language: • Unified Modeling Language (UML) by OMG. • Refactoring of UML needed! Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  4. 2. Foundations: UML Diagrams & Models • UML := diagram + underlying model • Diagram is just a partial view of the model. • Model does not contain any information related to diagrams: No layout information! • Abstract syntax (=metamodel) of UML model: • Defined using MOF (Meta Object Facility). • Concrete syntax of UML diagram: • Defined using prose language and graphical examples. Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  5. Foundations: XMI and UMLDI • Standard formats for UML models and diagrams: • Model: XMI (XML Metadata Interchange) • Applicable to anything that has a MOF-compliant metamodel. • As UML standard does not define diagrams in terms of MOF, XMI cannot be immediately used to store diagrams. • Diagram: UMLDI (UML Diagram Interchange): • Introduces MOF-compliant metamodel for layout information  XMI can be used as well for storing diagrams. • Contains only information not contained in the model. • Refer to model elements using GUID (Globally Unique Identifier). Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  6. Reference to another model element using GUID Name of element XMI of model (excerpt): Definition of GUID Definition of Action node UMLDI of diagram (excerpt): Layout information Reference to model element using GUID Layout information Foundations: XMI/UMLDI Example Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  7. 3. Related Work • A couple of commercial UML editors support simple refactorings: • “Rename element”: is in fact just an operation on the model. (Due to references, diagram will refer to the changed name in the model.) • A couple of academic tools support more advanced refactorings: • However, only performed on the model. • Diagrams will become inconsistent. Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  8. 4. Approach • Refactor model + diagram using Model to Model (M2M) transformations. • We use the transformation language Query/View/Transformation (QVT). • Standardised by OMG  Natural choice for transforming UML. • Flavours: QVT Relations (declarative), QVT Operational (procedural). • Applicable to any MOF-compliant model. • Both XMI and UMLDI are MOF-compliant: • QVT can be used to transform UMLmodel + diagram. • 1 transformation for XMI + 1 transformation for UMLDI. • Consistency of model + diagram preserved when applying comparable transformations! Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  9. 5. Prototype Tool • Implemented refactoring plug-in for open-source Eclipse UML editor Papyrus. • Stores model in XMI, diagram in UMLDI format. • Eclipse M2M project provides QVTO engine. • Implements QVT Operational language. • Provides black-box approach: • Implement using Java functionality that is not present in QVTO. Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  10. Architecture • Java invocation library: • User interface + glue code to invoke QVTO transformations. • QVTO transformations: • The actual refactorings. • Java black-box library: • Mainly needed because the Eclipse QVTO implementation does not support the full QVT standard. Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  11. Sample Refactoring: Merge Actions • Summary: The action which is on the source-end (“first action”) of the connecting edge will be merged into the target-end action (“last action”). • Mechanics (to be applied on model and diagram): • Move the target of all incoming edges from first action to last action. • Add name of first action to name last action. • Remove the control flow edge that connects first and last action. • Remove first action. • Merge actions of activity diagram After: Before: Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  12. Sample Merge Actions Implementation Refactor Diagram (simplified) (1 of 2) Type of input and output models of transformation … transformation MergeActions(inout notation : NOTATION, inout uml : UML); configuration property toMerge1 : String; configuration property toMerge2 : String; property objToMerge1 : notation::Shape = null; property objToMerge2 : notation::Shape = null; … main() { notation.objectsOfType(Shape) -> getSelectedObjects(); notation.objectsOfType(Shape) -> map merge(); … } query Shape::getSelectedObjects() : Void { if (self.hasGlobalId(toMerge1)) then { objToMerge1 := self; } endif; if (self.hasGlobalId(toMerge2)) then { objToMerge2 := self; } endif; } Input parameters: strings containing GUIDs of elements selected in the editor. Global variables: hold non-string reference to elements selected in editor Query to convert string GUIDs into non-string references. (Called on every element of type Shape.) Not shown: call of mapping to refactor model just like diagram Call mapping to refactor diagram. (Called on every element of type Shape.) Find out if current shape happens to have a GUID matching an element selected in the editor: if yes, store reference in global variable. Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  13. Sample Merge Actions Implementation Refactor Diagram (simplified) (2 of 2) mappinginout notation::Shape::merge() when { self.hasGlobalId(toMerge1) } { var firstNode : Shape = null; var lastNode : Shape = null; var connectingEdge : Edge = null; self.targetEdges->forEach(incoming) { if (incoming.source = objToMerge2) then { firstNode := objToMerge2; lastNode := objToMerge1; connectingEdge := incoming; } endif; }; … firstNode.oclAsType(Shape).targetEdges->forEach(incomingEdge) { incomingEdge.target := lastNode; }; notation.removeElement(connectingEdge); notation.removeElement(firstNode); } Mapping called on every Shape, however only applicable if Shape happens to be the Activity to be merged. getSelectedObjects() did not tell us which of the two selected nodes is the first, which is the last: find out by investigating for each edges that targets us whether it comes from the other node. First step of actual refactoring mechanics: Move the target of all incoming edges in diagram from first action to last action. Further steps of actual refactoring mechanics: remove obsolete elements from diagram. Not shown: mapping to refactor model just like diagram was refactored (plus: adjust name of activity node). Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  14. 6. Discussion • By considering UML diagram as model (using UMLDI), diagram can be refactored just like a UML model. • QVT language useable for refactoring implementation. • More and more UML tools support QVT, XMI, UMLDI. • QVT refactoring implementations exchangeable between tools! • QVTO advantage: procedural programmers feel familiar. • QVTO disadvantage: procedural programming isawkward. • But having pattern matching/iterating is already nice and the fact that transformations are done on the model level (not on data structure level) is nice. • Implementation of 2 prototype refactorings is pretty short: • 205 LOC of QVTO, 57 LOC of Java for the black-box library, 284 LOC of Java for user interface and glue code. Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

  15. Discussion • Other M2M languages may be better suited, e.g. QVT Relations or languages specific to refactoring domain, e.g. Henshin. • Transformation of two related models not based on any formal foundations with respect to consistency. • Diskin and Czarnecki provide a formal algebraic framework for mapping changes applied to one model to another related model. • Not considered: speed (UML models are typically small). • Refactoring of QVT code itself needed! Einarsson, Neukirchen: Refactoring of UML Diagrams and Models Using Model-to-Model Transformations

More Related