Revision as of 11:15, 5 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.

• JRO: Java root object
• URU: UML root object
• JRO <-sync-> URU

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 (static, final, strictfp)
  • Extends (may reference external types)
  • Implements (may reference external types)
  • Generics (may reference external types)
  • Imports

Class

Interface

Enumeration

• Literals
  • Initial value

Members

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

Fields

• Initial value

Methods

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

Annotations

Comments

Inner types