Papyrus Software Designer/Model Code Synchronization

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.ownerPackage

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 <-> UP.ownerPackage
• TODO details
  • Visibility (public, private, package, protected)
  • Modifiers (abstract, static, final, strictfp)
  • Extends (may reference external types)
  • Implements (may reference external types)
  • Generics (may reference external types)
  • Imports

Class

• Classes have fields and methods

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

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

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.

Methods

• Override
• Generics (may reference external types)
• Parameters (may reference external types)
  • Type (may reference external types)
  • Generics (may reference external types)
• Body