Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Papyrus Software Designer/Model Code Synchronization"

(→‎Mapping definition)
(→‎Mapping definition)
(2 intermediate revisions by the same user not shown)
Line 39: Line 39:
 
** JP.name <-> UP.name
 
** JP.name <-> UP.name
 
* The container of the Package object is the same as the Package object synchronised with the Java package that contains the mapped Java package
 
* The container of the Package object is the same as the Package object synchronised with the Java package that contains the mapped Java package
−
** JP.package <-> UP.ownerPackage
+
** JP.package <-> UP.owner
  
 
=== Compilation units ===
 
=== Compilation units ===
Line 50: Line 50:
 
** CU.name <-> NamedElement.name
 
** CU.name <-> NamedElement.name
 
* The container of the CU is the same as the Package object synchronised with the Java package that contains the mapped CU
 
* The container of the CU is the same as the Package object synchronised with the Java package that contains the mapped CU
−
** CU.package <-> UP.ownerPackage
+
** CU.package <-> Element.owner
−
* TODO details
+
* The visibility of the compilation unit (public, private, package, protected) is the same as the VisibilityKind set for the UML element.
−
** Visibility (public, private, package, protected)
+
** Only public and package-private visibility is allowed in units contained by packages
−
** Modifiers (abstract, static, final, strictfp)
+
** Inner types can use all visibility kinds
 +
** CU.visibility <-> NamedElement.visibility
 +
* Strictfp modifier is available on classes, interfaces and non-abstract methods to restrict floating point calculations for portability.
 +
** Java.strictfp <-> PapyrusJava.Strictfp stereotype applied on element
 +
 
 +
===== TODO details =====
 +
 
 
** Extends (may reference external types)
 
** Extends (may reference external types)
 
** Implements (may reference external types)
 
** Implements (may reference external types)
Line 61: Line 67:
 
=== Class ===
 
=== Class ===
  
−
* Classes have fields and methods
+
* Java classes (JC) have fields and methods that are mapped to properties and operations in UML Classes
 +
** See details in later sections
 +
* Class modifiers are abstract and final
 +
** JC.abstract <-> Classifier.abstract
 +
** JC.final <-> RedefinableElement.leaf
  
 
=== Interface ===
 
=== Interface ===
Line 67: Line 77:
 
* Interfaces only have public methods without body (before Java 8)
 
* Interfaces only have public methods without body (before Java 8)
 
* From Java 8, interface methods can define default implementations and static methods as well
 
* From Java 8, interface methods can define default implementations and static methods as well
 +
* See details in later sections
  
 
=== Enumeration ===
 
=== Enumeration ===
Line 75: Line 86:
 
** In case of enums with constructors and fields, the literals have initial values using assignment
 
** In case of enums with constructors and fields, the literals have initial values using assignment
 
** literal.inital <-> EnumerationLiteral.specification
 
** literal.inital <-> EnumerationLiteral.specification
 +
* Java enums may have methods and fields similarly to a class
 +
** See details in later sections
  
 
=== Members ===
 
=== Members ===
  
−
* TODO details
+
===== TODO details =====
 +
 
 
** Visibility (public, private, package, protected)
 
** Visibility (public, private, package, protected)
 
** Modifiers (static)
 
** Modifiers (static)
Line 93: Line 107:
  
 
Note that while fields could be represented by full Associations owned by the container, it is not done that way.
 
Note that while fields could be represented by full Associations owned by the container, it is not done that way.
 +
* TODO there is a "Create Association From Property" command, that transforms simple properties to association, it is not clear how this should be handled in synchronization
  
 
==== Methods ====
 
==== Methods ====
 +
 +
* Constructor
 +
** Method.isConstructor <-> standard.Create stereotype applied on Operation
 +
 +
===== TODO details =====
  
 
* Override
 
* Override
Line 101: Line 121:
 
** Type (may reference external types)
 
** Type (may reference external types)
 
** Generics (may reference external types)
 
** Generics (may reference external types)
 +
* Throws declarations in Java are represented by raised exceptions of the UML Operation
 +
** Method.throws <-> BehavioralFeature.raisedExceptions
 
* Body
 
* Body
  
 
=== Annotations ===
 
=== Annotations ===
 +
 +
* TODO handling Annotations are not yet defined in mapping and not supported by code generator or reverse engineering transformation.
  
 
=== Comments ===
 
=== Comments ===
  
−
 
+
* Comments in Java files that are added to elements and not inside blocks are stored in UML Comment elements
  
 
=== Inner types ===
 
=== Inner types ===
 +
 +
* Inner types are owned by a Compilation Unit instead of a Package
 +
* Static modifier can be used on inner types in Java
 +
** Type.static <-> PapyrusJava.StaticClassifier stereotype applied on Classifier

Revision as of 11:25, 8 December 2016

Model Code Synchronization

This page gathers ideas on the model-code synchronization component of Papyrus Software Designer, developed by IncQuery Labs and CEA. It will later become a finalized wiki page for users and developers. The synchronization component is based on change-based incremental transformation (code generation and reverse).

UML and Java

Events to handle (both UML side and Java side):

  • Addition
  • Deletion
  • Rename
  • Move
    • = Addition + Deletion?
  • Refactor [UML-side] such as “impact of changing any element E on other elements that reference ”, e.g.
    • Impact of a renaming performed on a class which types properties
    • Impact of moving some class, typing properties, to another package
  • Refactor [Java-side]
    • By using the JDT refactor command, referenced JDT elements will be updated, firing change events so no problem.
    • Without using JDT refactor command, we will have broken code to be ignored (e.g. attribute with nonexistent type). I don’t think JDT will fire a change event on the broken code.

It doesn’t matter if such events are not explicit, as long as we can express them (e.g. combination of other events) and update elements without ambiguity.

Mapping definition

Mapping root

The root of the mapping is selected by the user:

  • Java: packages are handled with source folders considered as roots that are not mapped themselves
  • UML: by default, the root object of the UML model (a Model EObject, e.g. RootElement) is already a Package that can be mapped to a root Java package, or an added prefix (e.g. com.mycompany) can be used to map the contents of the model to a sub package (e.g. com.mycompany.RootElement)

Note that the root of the mapping is best described as a Java package and a corresponding UML Package (potentially Model) element, where the namespace (container package qualified name) of the Java package is the prefix for the code generated from the UML Package.

  • Java root object <-sync-> UML root object

Packages

  • A Java package is mapped to a Package object in the UML model.
    • Java package (JP) <-> UML Package (UP)
  • The name attribute of the Package is the same as the name of the Java package.
    • JP.name <-> UP.name
  • The container of the Package object is the same as the Package object synchronised with the Java package that contains the mapped Java package
    • JP.package <-> UP.owner

Compilation units

  • Compilation units (CU) are classes, interfaces and enums, each defined in source files (*.java).
    • Java class <-> UML Class
    • Java interface <-> UML Interface
    • Java enum <-> UML Enumeration
  • The name attribute of the UML NamedElement is the same as the name of the Java Package.
    • CU.name <-> NamedElement.name
  • The container of the CU is the same as the Package object synchronised with the Java package that contains the mapped CU
    • CU.package <-> Element.owner
  • The visibility of the compilation unit (public, private, package, protected) is the same as the VisibilityKind set for the UML element.
    • Only public and package-private visibility is allowed in units contained by packages
    • Inner types can use all visibility kinds
    • CU.visibility <-> NamedElement.visibility
  • Strictfp modifier is available on classes, interfaces and non-abstract methods to restrict floating point calculations for portability.
    • Java.strictfp <-> PapyrusJava.Strictfp stereotype applied on element
TODO details
    • Extends (may reference external types)
    • Implements (may reference external types)
    • Generics (may reference external types)
    • Imports

Class

  • Java classes (JC) have fields and methods that are mapped to properties and operations in UML Classes
    • See details in later sections
  • Class modifiers are abstract and final
    • JC.abstract <-> Classifier.abstract
    • JC.final <-> RedefinableElement.leaf

Interface

  • Interfaces only have public methods without body (before Java 8)
  • From Java 8, interface methods can define default implementations and static methods as well
  • See details in later sections

Enumeration

  • Java enum literals are mapped to UML EnumerationLiterals
    • Java enum literal <-> UML EnumerationLiteral
  • Initial value of literals can be represented by the specification of EnumerationLiterals in UML
    • In case of enums with constructors and fields, the literals have initial values using assignment
    • literal.inital <-> EnumerationLiteral.specification
  • Java enums may have methods and fields similarly to a class
    • See details in later sections

Members

TODO details
    • Visibility (public, private, package, protected)
    • Modifiers (static)
    • Type (return type in case of methods)

Fields

  • Java fields are mapped to UML Properties
    • Java field <-> UML Property
  • The container of the Property is the UML Element that is mapped to the container of the Java field.
    • Field.container <-> Property.owner (Owner.ownedAttribute)
  • Initial value is provided by assignment in Java, while UML represents this as default value
    • Field.initial <-> Property.defaultValue

Note that while fields could be represented by full Associations owned by the container, it is not done that way.

  • TODO there is a "Create Association From Property" command, that transforms simple properties to association, it is not clear how this should be handled in synchronization

Methods

  • Constructor
    • Method.isConstructor <-> standard.Create stereotype applied on Operation
TODO details
  • Override
  • Generics (may reference external types)
  • Parameters (may reference external types)
    • Type (may reference external types)
    • Generics (may reference external types)
  • Throws declarations in Java are represented by raised exceptions of the UML Operation
    • Method.throws <-> BehavioralFeature.raisedExceptions
  • Body

Annotations

  • TODO handling Annotations are not yet defined in mapping and not supported by code generator or reverse engineering transformation.

Comments

  • Comments in Java files that are added to elements and not inside blocks are stored in UML Comment elements

Inner types

  • Inner types are owned by a Compilation Unit instead of a Package
  • Static modifier can be used on inner types in Java
    • Type.static <-> PapyrusJava.StaticClassifier stereotype applied on Classifier
Retrieved from "https://wiki.eclipse.org/index.php?title=Papyrus_Software_Designer/Model_Code_Synchronization&oldid=412629"

Back to the top