Revision as of 08: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.

Methods

• Constructor
  • Method.isConstructor <-> standard.Create stereotype applied on Operation
• 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

Comments

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