MDT/UML2/New and Noteworthy/Luna
MDT UML2 New and Noteworthy items for the Luna release.
For a complete list of the enhancements provided in the Luna release, see the Luna Project Plan.
This milestone was completed on November 15, 2013.
The UML2 package merge algorithm now injects documentation into the generated API to indicate the source package of classes, properties, and operations that originate in merge increments when the Capabilities merge option is enabled. For API elements defined in the receiving package of the merge, no such annotation is included in the documentation.
The Apply Stereotype action's dialog is enhanced to let the user specify an alternative resource in which to store the resultant stereotype application(s).
A new class org.eclipse.uml2.uml.validation.UMLTraversalStrategy implements an EMF Validation Framework "traversal strategy" that applications may register to let validation operations discover the instances of stereotypes that are attached to UML model elements, to validate them.
A new UML-to-Ecore conversion option, available in the EMF model importer and the profile definition action, lets the user determine how to handle properties that are untyped. In a UML model, a property that has no type can take any value; it is simply unconstrained. However, EMF cannot generate code for such a property, so now UML2 lets the user either substitute EObject type (the "Process" option), issue a warning ("Report"), or omit the property altogether ("Discard").
This milestone was completed on December 20, 2014.
The UML Editor menu sports a new Element → Expand Templates... action that reifies template bindings, replacing (in situ) the binding relationships in the bound element with elements merged from the templates. Constructs supported include
- template bindings for packages, classifiers, and operations
- bindings to multiple templates
- multiple bindings to the same template
- substitution of operands in name expressions (useful for disambiguating parameter substitutions from multiple bindings)
So, for example, a "deployment system" package that binds the same "system" package template twice, once for hardware components and once for software components. SoftwareSpec and HardwareSpec substitute for the ResourceKind in the template and the name of the Allocation class in the template is an expression in which the first segment is substituted by default with the string "Resource".
The template expansion algorithm is based on package merge. Most of the options are defaulted to values appropriate for template expansion, but the options for handling redundant generalizations and capabilities trace annotations are left to the user to decide.
The result of the expansion shows the substitution of parts of the name expressions for the SoftwareAllocation and HardwareAllocation which otherwise, using the default substitution, would both be named ResourceAllocation. Also, a trace annotation references all of the elements in the expanded package that were merged from the system template (just as in package merges).
UML-to-Ecore conversion (and, consequently, code generation) now supports transformation of OCL invariant constraints in EMF's non-API style for classes. These generate code only in the XyzValidator class, not as validation operations in the model API. This enhancement provides parity with constraint transformations for data types, which in EMF only support the non-API style of validation.
Generates this code:
The EMF.Edit item providers for the default attribute of the UML Property and Parameter metaclasses are improved to create values of more appropriate type than LiteralString where possible:
- for property or parameter of an Enumeration type, an InstanceValue referencing the EnumerationLiteral selected by the user from a pick-list
- for property or parameter of Boolean type, a LiteralBoolean with the value selected by the user from a true/false pick-list
- for property or parameter of Integer type, a LiteralInteger with the value entered by the user as text
- for property or parameter of UnlimitedNatural type, a LiteralUnlimitedNatural with the value entered by the user as text
- for property or parameter of Real type, a LiteralReal with the value entered by the user as text
- in other cases, a LiteralString is created
This milestone was completed on January 31, 2014.
The UML2 run-time bundles are now partitioned into Eclipse Features of finer granularity, to help software integrators to keep unneeded bundles out of their distributions. For example:
- the absolutely minimal feature is org.eclipse.uml2.common, containing only the org.eclipse.uml2.common and org.eclipse.uml2.types bundles needed to support a custom metamodel defined with UML and generated with UML2, but not actually extending or referencing the UML metamodel as such
- layered on the above is the org.eclipse.uml2.uml feature, which adds the following bundles for working with the UML metamodel (no editing capabilities included)
- org.eclipse.uml2.uml — the UML metamodel
- org.eclipse.uml2.uml2.profile.l2, org.eclipse.uml2.uml2.profile.l3 — standard profiles
- org.eclipse.uml2.uml2.resources — other supporting resources (metamodels, model libraries, and profiles)
A new org.eclipse.uml2.ant bundle provides an Ant task for integration of a dynamic profile definition step into a build or other automated process. The uml2.defineProfile task takes a profile resource as input, defines the profile, and saves it again in situ.
New example project wizards are provided by the UML2 SDK with complete "solutions" of the getting-started tutorials in this Wiki:
For stand-alone Java applications using the UML2 APIs that do not mind (or otherwise need to) including at least a portion of the Eclipse Equinox run-time, a new UMLPlugin.ExtensionProcessor API is provided that, like the EcorePlugin.ExtensionProcessor introduced by EMF in the Kepler release, instantiates the Equinox extension registry and populates it from plugin.xml files discovered in the JARs on the classpath. Note that this does not actually require the Eclipse Platform to be instantiated and "running".
The extension processor ensures proper and complete registration of
- traceability between UML profiles and their statically-generated implementations (the org.eclipse.uml2.uml.generated_package extension point)
- traceability between dynamic Ecore EPackages and their source UML Packages (the org.eclipse.uml2.uml.dynamic_package extension point)
- all of the EMF extension points for registration of packages, setting/invocation/validation delegates, etc.
This is particularly useful to ensure availability and function of custom models deployed in your applications. For applications that only need to work with the UML metamodel and its standard resources, it the UMLResourcesUtil::init(ResourceSet) API is still a lighter-weight solution, not requiring any Equinox components.
Via OpaqueExpressions specified with OCL, it is possible in UML to model initial and derived values for properties. The UML-to-Ecore converter is enhanced to process these defaultValue expressions as follows:
- for properties that are derived and read-only, generate an OCL setting delegate "derivation" annotation in the Ecore model for the computed property
- for properties that are not derived, generate an OCL setting delegate "initial" annotation in the Ecore model for the initial value of the mutable property
The actual code generation and run-time support for the latter is still pending, depending on changes in the EMF and/or OCL projects. Computed values are currently fully supported.
The UML-to-Ecore and Ecore-to-UML converters are enhanced to support the EMOF annotations for opposite role names of reference properties. These are used by OCL and possibly other components to support navigation of implicit opposite references, despite that they are not explicitly represented in the EMOF model nor actually implemented at run-time. The UML-to-Ecore converter creates opposite role name annotations on EReferences in the Ecore model from UML properties that
- are owned by a binary association (the navigable end is owned by a class)
- have a role name that is different from what OCL defines as the implicit role name. Because the implicit role name, according to OCL, is the name of the class that is the end's type, the following cases are included:
- the role name is blank (the UML2 API presents this as the name of the end's type with an initial lower-case character)
- the role name is explicitly set to something else