Diagram Definition: Revised Submission

Slides:



Advertisements
Similar presentations
Object-Oriented Programming Session 9 Course : T Programming Language Concept Year : February 2011.
Advertisements

Diagram Definition: an Overview Third OMG/Eclipse Symposium 25 March 2012 Maged Elaasar, Senior Software Engineer.
2006 Pearson Education, Inc. All rights reserved Object-Oriented Programming: Inheritance.
2006 Pearson Education, Inc. All rights reserved Object-Oriented Programming: Polymorphism.
Advanced Piloting Cruise Plot.
Final and Abstract Classes
Chapter 7 System Models.
Copyright © 2003 Pearson Education, Inc. Slide 3-1 Created by Cheryl M. Hughes The Web Wizards Guide to XML by Cheryl M. Hughes.
Chapter 1 The Study of Body Function Image PowerPoint
1 Copyright © 2013 Elsevier Inc. All rights reserved. Chapter 1 Embedded Computing.
By D. Fisher Geometric Transformations. Reflection, Rotation, or Translation 1.
Service Oriented Architecture Reference Model
Software Process Modeling with UML and SPEM
Business Transaction Management Software for Application Coordination 1 Business Processes and Coordination.
Copyright CompSci Resources LLC Web-Based XBRL Products from CompSci Resources LLC Virginia, USA. Presentation by: Colm Ó hÁonghusa.
Language Specification using Metamodelling Joachim Fischer Humboldt University Berlin LAB Workshop Geneva
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
Introduction to HTML, XHTML, and CSS
DIVIDING INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
FACTORING ax2 + bx + c Think “unfoil” Work down, Show all steps.
2010 fotografiert von Jürgen Roßberg © Fr 1 Sa 2 So 3 Mo 4 Di 5 Mi 6 Do 7 Fr 8 Sa 9 So 10 Mo 11 Di 12 Mi 13 Do 14 Fr 15 Sa 16 So 17 Mo 18 Di 19.
Word Lesson 6 Working with Graphics
View-Based Application Development Lecture 1 1. Flows of Lecture 1 Before Lab Introduction to the Game to be developed in this workshop Comparison between.
Profiles Construction Eclipse ECESIS Project Construction of Complex UML Profiles UPM ETSI Telecomunicación Ciudad Universitaria s/n Madrid 28040,
ABC Technology Project
1 Undirected Breadth First Search F A BCG DE H 2 F A BCG DE H Queue: A get Undiscovered Fringe Finished Active 0 distance from A visit(A)
Lesson 8: Working with Illustrations Courseware #: 3240
VOORBLAD.
1 Breadth First Search s s Undiscovered Discovered Finished Queue: s Top of queue 2 1 Shortest path from s.
Object-Oriented Programming. 2 An object, similar to a real-world object, is an entity with certain properties, and with the ability to react in certain.
Heppenheim Producer-Archive Interface Specification Status of standardisation project Main characteristics, major changes, items pending.
Chapter 5 Microsoft Excel 2007 Window
© 2012 National Heart Foundation of Australia. Slide 2.
Lecture plan Outline of DB design process Entity-relationship model
Understanding Generalist Practice, 5e, Kirst-Ashman/Hull
آزمایشگاه مهندسی نرم افزار
1 Motion and Manipulation Configuration Space. Outline Motion Planning Configuration Space and Free Space Free Space Structure and Complexity.
25 seconds left…...
A lesson approach © 2011 The McGraw-Hill Companies, Inc. All rights reserved. a lesson approach Microsoft® PowerPoint 2010 © 2011 The McGraw-Hill Companies,
How to annotate simple drawings for use in constructing an object
Chapter 2 Entity-Relationship Data Modeling: Tools and Techniques
Januar MDMDFSSMDMDFSSS
We will resume in: 25 Minutes.
©Brooks/Cole, 2001 Chapter 12 Derived Types-- Enumerated, Structure and Union.
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 12 View Design and Integration.
PSSA Preparation.
Chapter 11 Component-Level Design
Copyright © 2009 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Java Software Solutions Foundations of Program Design Sixth Edition by Lewis.
 2004 Prentice Hall, Inc. All rights reserved. 1 Chapter 30 - Dynamic HTML: Structured Graphics ActiveX Control Outline 30.1Introduction 30.2Shape Primitives.
CpSc 3220 Designing a Database
Lesson One: The Beginning
1Model Driven Architecture – 3. März 2008 – Siegfried Nolte 1.UML – What is it and what is it good for ? 2.MDA – What is it and what is it good for ? 3.MDA.
© 2014 Fair Isaac Corporation. Confidential. This presentation is provided for the recipient only and cannot be reproduced or shared without Fair Isaac.
Modeling Main issues: What do we want to build How do we write this down.
From Model-based to Model-driven Design of User Interfaces.
1 Programming Languages (CS 550) Mini Language Interpreter Jeremy R. Johnson.
OCL2 April A presentation of OCL 2 Object Constraint Language Christian Hein, Fraunhofer FOKUS April 2006.
An Approach and Tool for Synchronous Refactoring of UML Diagrams and Models Using Model-to-Model Transformations Hafsteinn Þór Einarsson Helmut Neukirchen.
Diagram Definition A Case Study with the UML Class Diagram MoDELS 2011, Wellington, NZ By Maged Elaasar 1,2 (Presenter) and Yvan Labiche.
® IBM Software Group © 2006 IBM Corporation Diagram Definition: Initial Submission Maged Elaasar, IBM ADTF, OMG June 2009, San Jose,
Sheet 1MDAFA2004 Linköping, June 2004 A Language for Model Transformations in the MOF Architecture Ivan Kurtev, Klaas van den Berg University of Twente,
Subgroup Chair: Robert Shapiro (Global360) Baseline Proposal:
SysML v2 Formalism: Requirements & Benefits
Proposed SysML v2 Submission Plan
Diagram Interchange Proposal
Presentation transcript:

Diagram Definition: Revised Submission ADTF, OMG March 2010, Washington DC Maged Elaasar, IBM melaasar@ca.ibm.com

DD Joint Submission Team Submitters Adaptive Deere & Company Fujitsu International Business Machines Model Driven Solutions Sparx Systems Supporters Trisotech U.S. National Institute of Standards and Technology

Diagram Definition Time Line RFP Initial Submission Revised Submission Voting September 2007 February 2009 May 2010 September 2010

Diagram Definition RFP Requirements Enable diagram interchange between tools of a given language Currently only the abstract syntax models can be interchanged Current DI spec provides a solution but it is not adequate because: Fixed metamodel that cannot be used to specify language-specific idioms. Mixes between what needs to be interchanged and what is fixed. Enable formal specification of the concrete graphical syntax of a language Currently graphical syntax and its mapping to the abstract syntax is specified using pictures and informal text. The lack of precision leads to confusion and ambiguity increasing cost/effort

Diagram Definition Submission Enable diagram interchange between tools of a given language Provides a new abstract Diagram Interchange (DI) metamodel Defines common DI abstractions, relationships and assumptions References abstract syntax (AS) model elements Gets extended by concrete language-specific DI metamodels. Provides base for integration between various language notations Enable formal specification of the concrete graphical syntax of a language Provides a new Diagram Graphics (DG) metamodel Defines well-known graphics abstractions, primitives and idioms. Is inspired by other popular graphics standards like SVG and CSS. Proposes using a mapping language (e.g. QVT) to map language-specific DI to DG Maps elements of DI and their referenced AS elements to elements of DG Results in DG models that depict the graphical syntax of models

Outline DD Architecture DI Metamodel Example: UML DI Metamodel DG Metamodel Example: QVT Mapping from UML DI to DG

DD Architecture DI DG MOF Mapping Language MOF M3 spec Abstract Syntax Diagram Syntax Concrete Syntax DI M2 spec AS AS DI CS Mapping Specification DG Model Diagram Graphics M1 user CS Mapping Model (interchanged) Controller (executed) View (rendered) Instantiates Specializes References DD Spec Language Spec DI : Diagram Interchange DG: Diagram Graphics AS: Abstract Syntax CS : Concrete Syntax

Example : UML DD Architecture MOF Mapping Language MOF M3 Abstract Syntax Diagram Syntax Concrete Syntax DI M2 UML UML DI UML Mapping Specification DG M1 UML Mapping Model Controller View Instantiates Specializes References DD Spec UML Spec DI : Diagram Interchange DG: Diagram Graphics

Diagram Common (DC) Metamodel Defines data types that are common between DI and DG: Primitive types: Boolean, String, Integer, Real 2D Layout types: Point (x, y), Dimension (w, h), Bounds (x, y, w, h) Color types: Color (r, g, b), KnownColor (red, green, yellow…etc) Defines common geometrical assumptions: Measurement Unit: user units (logical) A mapping to inches (physical) provided as diagram resolution Coordinate System: x-y based Origin at 0,0 and Increases to right and down Negative coordinates allowed Z-Order: based on rules Owned element > owning element Sibling at higher index > sibling at lower index Rotation: in degrees Can be +ve (clockwise) or –ve

Diagram Interchange (DI) Metamodel DiagramElement is the basic building block of a diagram Can reference an optional model element Can have an optional local and/or shared style Can nest other diagram elements Style is a bag of optional properties affecting the styling of diagram elements

Diagram Interchange (DI) Metamodel Diagram is a container of a hierarchy of diagram elements The root of the hierarchy is of type Plane (next slide) Can own styles shared by diagram elements in the diagram DiagramCollection is a container of a collection of diagrams Can own styles shared by diagram elements across diagrams

Diagram Interchange (DI) Metamodel Plane defines a 2-dimensional x-y coordinate system Owns an ordered collection of plane elements PlaneElement is the super type of elements laid out relative to their plane Owns a collection of labels Label is an attachment to a plane element Has its own optional bounds relative the plane When bounds are not specified it is positioned automatically

Diagram Interchange (DI) Metamodel Shape is a plane element specified with a rectangular bounds on the plane Edge is a plane element specified with a set of points relative to the plane represents a line connecting two plane elements: a source and a target

Example: UML DI Metamodel

Example: UML DI Metamodel

Diagram Graphics (DG) Metamodel GraphicalElement is the basic building block of graphics Can have a local and a share style Can be transformed with a list of transforms Can be clipped with a clip path

Diagram Graphics (DG) Metamodel Many primitive graphical elements are defined Others can be defined at M1

Diagram Graphics (DG) Metamodel Group is a graphical element that nests other elements as members Canvas is the top most group and defines a 2-dimentional coordinate system Owns shared elements (Fills and Markers) referenced by other elements ClipPath is a group that defines a clip path as the union of the the outlines of its members

Diagram Graphics (DG) Metamodel Fill is a definition of how to fill enclosed areas of graphical elements Two types of Fill exist: Gradient and Pattern Style is a bag of optional properties affecting the styling of graphical elements

Diagram Graphics (DG) Metamodel PathCommand is an instruction to manipulate the current pen in the canvas Tansform is a definition of a change to do to a graphical element

Example: QVT Mapping from UML DI to DG modeltype DC uses 'http://www.omg.org/spec/DD/20100525/DC'; modeltype DI uses 'http://www.omg.org/spec/DD/20100525/DI'; modeltype DG uses 'http://www.omg.org/spec/DD/20100525/DG'; modeltype UMLDI uses 'http://www.omg.org/spec/UML/20100525/DI'; modeltype UML uses 'http://www.omg.org/spec/UML/20090901'; transformation umldi2dg(in umldi : UMLDI, out DG) { main() { umldi.objectsOfType(UMLDI::UMLPlane)->map planeToGraphicalElement(); } mapping UMLDI::UMLPlane::planeToGraphicalElement() : DG::Canvas inherits DI::DiagramElement::diagramElementToGraphicalElement member += self.planeElement->map planeElementToGraphicalElement(); … UMLPlane PlaneElement UMLDI DG Canvas Group

Example: QVT Mapping from UML DI to DG mapping DI::PlaneElement::planeElementToGraphicalElement() : DG::Group { init { result := switch { case (self.oclIsKindOf(UMLDI::UMLShape)) self.oclAsType(UMLDI::UMLShape).map shapeToGraphicalElement(); case (self.oclIsKindOf(UMLDI::UMLEdge)) self.oclAsType(UMLDI::UMLEdge).map edgeToGraphicalElement(); }; } mapping UMLDI::UMLShape::shapeToGraphicalElement() : DG::Group inherits DI::DiagramElement::diagramElementToGraphicalElement { member += self.umlElement.map shapeToGraphicalElement(self); member += self.label.map labelToGraphicalElement(); member += self.compartment->map compartmentToGraphicalElement(); mapping UMLDI::UMLEdge::edgeToGraphicalElement() : DG::Group member += self.umlElement.map edgeToPolyline(self); UML::Element UMLShape UMLEdge UMLLabel UMLLabel UMLCompartment UMLDI DG Group Group GraphicalElement Polyline Text Text Group

Example: QVT Mapping from UML DI to DG UMLCompartment mapping UMLDI::UMLCompartment::compartmentToGraphicalElement() : DG::Group inherits DI::DiagramElement::diagramElementToGraphicalElement { member := object DG::Rectangle { bounds := newBounds(self.bounds) }; member += self.label.map labelToGraphicalElement(); member += self.planeElement->map planeElementToGraphicalElement(); } mapping UMLDI::UMLLabel::labelToGraphicalElement() : DG::Text bounds := newBounds(self.bounds); switch { case (self.kind = UMLDI::UMLLabelKind::name) {var diagramElement = self.owningElement.oclAsType(UMLDI::UMLDiagramElement); data := diagramElement.umlElement.oclAsType(UML::NamedElement).name(diagramElement);} case (self.kind = UMLDI::UMLLabelKind::sourceRole) data := association.memberEnd->at(1).role(); case (self.kind = UMLDI::UMLLabelKind::targetRole) data := self.owningElement.modelElement.oclAsType(UML::Association).memberEnd->at(2).role(); case (self.kind = UMLDI::UMLLabelKind::sourceMultiplicity) data := self.owningElement.modelElement.oclAsType(UML::Association).memberEnd->at(1).multiplicity(); case (self.kind = UMLDI::UMLLabelKind::targetMultiplicity) data := self.owningElement.modelElement.oclAsType(UML::Association).memberEnd->at(2).multiplicity(); case (self.kind = UMLDI::UMLLabelKind::title) data := self.owningElement.oclAsType(UMLDI::UMLCompartment).title(); }; UMLLabel PlaneElement UMLDI DG Group Rectangle Text Group

Example: QVT Mapping from UML DI to DG abstract mapping DI::DiagramElement::diagramElementToGraphicalElement() : DG::GraphicalElement { var s : DG::Style; if self.localStyle->notEmpty() and self.localStyle.oclIsKindOf(UMLDI::UMLStyle) then s := object DG::Style { if not localStyle.oclIsSet(fontName) then fontName := ds.fontName endif; if not localStyle.oclIsSet(fontSize) then fontSize := ds.fontSize endif; } endif; if self.sharedStyle->notEmpty() and self.sharedStyle.oclIsKindOf(UMLDI::UMLStyle) then localStyle := s;

Example: QVT Mapping from UML DI to DG mapping UML::Element::shapeToGraphicalElement(shape:UMLDI::UMLShape) : DG::GraphicalElement { init {} } mapping UML::Classifier::shapeToGraphicalElement(shape:UMLDI::UMLShape) : DG::GraphicalElement { init { result := object DG::Rectangle { bounds := newBounds(shape.bounds) }; mapping UML::Property::shapeToGraphicalElement(shape:UMLDI::UMLShape) : DG::GraphicalElement { result := object DG::Text { bounds := newBounds(shape.bounds); data := self.name(shape); alignment = DC::AlignmentKind::start }; mapping UML::Operation::shapeToGraphicalElement(shape:UMLDI::UMLShape) : DG::GraphicalElement {

Example: QVT Mapping from UML DI to DG property interfaceRealizationStyle = object DG::Style { strokeDashLength := Sequence {2, 2}; }; property interfaceRealizationMarker = object DG::Marker { size := object DC::Dimension {width := 10; height := 10}; reference := object DC::Point {x := 10; y := 5}; member += object DG::Path { command += object DG::MoveTo {point := object DC::Point{ x:=0; y:=0 } }; command += object DG::LineTo {point := object DC::Point{ x:=10; y:=5 } }; command += object DG::LineTo {point := object DC::Point{ x:=0; y:=10 } }; mapping UMLDI::UMLPlane::planeToGraphicalElement() : DG::Canvas inherits DI::DiagramElement::diagramElementToGraphicalElement { …. marker += interfaceRealizationMarker; style += interfaceRealizationStyle; } mapping UML::Element::edgeToPolyline(edge:UMLDI::UMLEdge) : DG::Polyline { point := edge.waypoint->collect(p|newPoint(p)); mapping UML::InterfaceRealization::edgeToPolyline(edge:UMLDI::UMLEdge) : DG::Polyline inherits UML::Element::edgeToPolyline { sharedStyle := interfaceRealizationStyle; endMarker := interfaceRealizationMarker; 0,0 10,10

Example: QVT Mapping from UML DI to DG query UML::NamedElement::name(de : UMLDI::UMLDiagramElement) : String { return self.name(de.isQualifiedName) } query UML::NamedElement::name(qualified : Boolean) : String { return if qualified then self.qualifiedName else self.name endif query UML::NamedElement::visibility() : String { return switch { case (self.visibility = UML::VisibilityKind::public) '+'; case (self.visibility = UML::VisibilityKind::private) '-'; case (self.visibility = UML::VisibilityKind::private) '#'; else ‘'; query UML::TypedElement::type(qualified : Boolean) : String { return if self.type->notEmpty() then ' : ' + self.type.name(qualified) else '' endif query UML::Property::name(de : UMLDI::UMLDiagramElement) : String { return self.visibility() + self.derived_() + self.name(de.isQualifiedName) + self.type(de.isQualifiedName) query UML::Property::derived_() : String { return if self.isDerived then '/' else '' endif query UML::Property::multiplicity() : String { return '[' + self.lower.toString() + '..' + self.upper.toString() + ']' query UML::Property::role() : String { return self.visibility() + self.derived_() +self.name(false) query UML::Operation::name(de : UMLDI::UMLDiagramElement) : String { return self.visibility() + self.name(de.isQualifiedName) + '()' + self.type(de.isQualifiedName)

Example: QVT Mapping from UML DI to DG helper newPoint(p : DC::Point) : DC::Point { return p.clone().oclAsType(DC::Point) } helper newBounds(b : DC::Bounds) : DC::Bounds { return b.clone().oclAsType(DC::Bounds) helper newColor(c : Color) : DC::Color { return c.clone().oclAsType(DC::Color) helper rgbColor(r : Integer, g : Integer, b : Integer) : DC::Color { return object DC::Color { red := r; green := g; blue := b; } helper knownColor(color : DC::KnownColor) : DC::Color { return switch { case (color = KnownColor::maroon) rgbColor(128, 0, 0); case (color = KnownColor::red) rgbColor(255, 0, 0); case (color = KnownColor::orange) rgbColor(255, 165, 0); case (color = KnownColor::yellow) rgbColor(255, 255, 0); case (color = KnownColor::olive) rgbColor(128, 128, 0); case (color = KnownColor::purple) rgbColor(128, 0, 128); case (color = KnownColor::fuchsia) rgbColor(255, 0, 255); case (color = KnownColor::white) rgbColor(255, 255, 255); case (color = KnownColor::lime) rgbColor(0, 255, 0); case (color = KnownColor::green) rgbColor(0, 128, 0); case (color = KnownColor::navy) rgbColor(0, 0, 128); case (color = KnownColor::blue) rgbColor(0, 0, 255); case (color = KnownColor::aqua) rgbColor(0, 255, 255); case (color = KnownColor::teal) rgbColor(0, 128, 128); case (color = KnownColor::silver) rgbColor(192, 192, 192); case (color = KnownColor::gray) rgbColor(128, 128, 128); case (color = KnownColor::black) rgbColor(0, 0, 0); }; }

Circularity Issue QVT is mapping from a MOF model to a MOF model MOF abstract syntax models are normally specified using UML diagrams (even if they are represented in XMI for interchange). To avoid circularity, the UML notation subset used specifically for specifying MOF abstract syntax models must be defined independently of DD. As with other MOF core circularity concerns, this is really a MOF issue, not a DD issue.

FTF Planned Activities Fix issues with the Revised Submission Define in Annex A a more elaborate example (subset of UML) Define in Annex B a M2T mapping from DG to SVG Implement a reference implementation for this mapping