MDT/UML2/UML2 4.0 Migration Guide

From Eclipsepedia

< MDT‎ | UML2
Revision as of 23:32, 23 October 2011 by Kenn.Hussey.gmail.com (Talk | contribs)

Jump to: navigation, search

Copyright © 2011 CEA

Contents

Summary

The intent of this guide is to assist consumers in the process of migrating from the UML2 3.x API, based on the UML 2.2 specification, to the new UML2 4.0 API, based on the UML 2.4 specification, and to summarize any new features of the implementation that developers may want to take advantage of.

Kenn Hussey
Last Updated: October 19, 2011

Introduction

The Eclipse UML2 (Unified Modeling Language 2.x) project is an EMF-based implementation of the UML 2.x metamodel for the Eclipse platform. This implementation was previously compliant with the 2.2 version of the UML specification, for which newer versions, namely 2.3 and 2.4 (and soon, 2.4.1), have been released by the Object Management Group (OMG) over the past couple of years. The source code for the UML2 project used to be stored in a CVS repository and its installable artifacts (update sites and downloads) were produced using an unsupported pre-Athena build system running on a machine that was at risk of being decommissioned in the near future.

The UML2 metamodel implementation has been enhanced so that it is compliant with the 2.4 and, implicitly, 2.3 version of the UML specification. This enhanced implementation has been delivered as a new version, 4.0, of the UML2 project, to be released as part of the Juno simultaneous release of Eclipse. The source code for this new version of the project is managed in an Eclipse git repository and built, using Buckminster, on the Hudson installation at Eclipse.

UML 2.4 was actually released by the OMG as part of a series of revisions, also known as the “2.4 series”, which includes updated versions of the Meta Object Facility (MOF) and MOF 2 XMI Mapping specifications as well. Based on a careful analysis of the delta between the previous UML2 implementation and the UML 2.4 and 2.3 specifications, described in more detail below, it was decided that the new version of UML2 would NOT be compatible with UML2 3.x. UML2 4.0 supersedes previous version(s) of the project (i.e., new major or minor versions of the 3.x stream will NOT be released) and is neither API contract nor binary compatible with UML2 3.x.

This migration guide has been provided to assist consumers in the process of migrating to the new UML2 4.0 API. An XMI-based (de)serialization mechanism (described herein) has also been provided to automatically migrate resources based on the UML2 3.x schema to the new 4.0 schema.

The changes in UML2 4.0 can be broken into functional areas, relating to various aspects of the EMF-based UML implementation provided by the UML2 project. The following sections describe each of these areas in detail.

API

The UML2 project provides a Java API that is generated using a (customized version of) the code generation facility in EMF. In the past, this API has been generated from a source model produced by merging models of Infrastructure, Superstructure, and L3 compliance level of UML with custom extensions introduced by the UML2 project. As of UML 2.4, however, a reference model of the merged L3 compliance level of UML, serialized in UML format, has been provided along with the specification by the OMG. As a result, the API is now generated from a source model produced by merging this merged L3 reference model with custom extensions introduced by the UML2 project.

The following subsections describe the changes to the classifiers, properties, operations, and constraints in the revised UML specifications which affected the API provided by UML2. It is worth noting that a number of the utilities and unit tests provided by UML2 were also modified in response to changes in the API.

Classifiers

Classifiers in UML are represented as Java interfaces, implementation classes, and enumerations in the UML2 API. These types are generated using the (customized) EMF code generator, along with associated factory and utility methods.

The following table lists the classifiers that were removed by the revised specifications. Removals that had a nontrivial impact on API compatibility and/or migration of legacy resources are highlighted in yellow.

Classifier Issue(s)
DestructionEvent 14629
ExecutionEvent 14629
ReceiveOperationEvent 14629
ReceiveSignalEvent 14629
SendOperationEvent 14629
SendSignalEvent 14629

The following table lists the classifiers that were modified by the revised specifications. Modifications that had a nontrivial impact on API compatibility and/or migration of legacy resources are highlighted in yellow.

Classifier Change Issue(s)
ActivityGroup specializes NamedElement 13943
OccurrenceSpecification abstract 9820
Pin abstract 12565

The following table lists the classifiers that were added by the revised specifications. Additions that had a nontrivial impact on functionality provided by the UML2 project are highlighted in yellow.

Classifier Issue(s)
DestructionOccurrenceSpecification 14629
LiteralReal 12583
Real 12583

Properties

Properties in UML are represented as Java fields with accessors (“getter” and “setter” methods) in the UML2 API. These members are generated using the (customized) EMF code generator and, in some cases (e.g., if a property is derived), implemented or customized by hand.

The following table lists the properties that were removed by the revised specifications. Removals that had a nontrivial impact on API compatibility and/or migration of legacy resources are highlighted in yellow.

Property Issue(s)
BehavioredClassifier::ownedTrigger 14931
OccurrenceSpecification::event 14629
Profile::ownedStereotype 12833

The following table lists the properties that were modified by the revised specifications. Modifications that had a nontrivial impact on API compatibility and/or migration of legacy resources are highlighted in yellow.

Property Change Issue(s)
AcceptEventAction::trigger subsets ownedElement 14926
ActivityEdge::inStructuredNode subsets owner 13718
ActivityNode::inStructuredNode subsets owner 13718
Behavior::isReentrant default is true 9873
Behavior::redefinedBehavior subsets redefinedClassifier, subsets redefinedElement 15265
Clause::test multiplicity is 1..* 15265
Component::provided OCL expression 13146
Component::required OCL expression 13146
ComponentRealization::abstraction subsets supplier, subsets source, subsets client 11008
ComponentRealization::realizingClassifier subsets client, subsets target 11008
ConditionalNode::result redefines structuredNodeOutput, subsets output 11646
ConnectableElement::end read only 15568
Connector::kind derived, read only 7364, 14115, 15568
Duration::expr subsets ownedElement 14926
EncapsulatedClassifier::ownedPort read only 15568
EnumerationLiteral::enumeration multiplicity is 1..1 14631
ExecutionOccurrenceSpecification::execution multiplicity is 0..2 14629
ExtensionEnd::lower derived, read only, multiplicity is 0..1 15568, 15762
InteractionUse::argument type is ValueSpecification, subsets ownedElement 10591, 14926
Interface::redefinedInterface subsets redefinedClassifier 14554
LinkAction::endData subsets ownedElement 14926
LinkEndData::qualifier subsets ownedElement 14926
LoopNode::loopVariableInput redefines structuredNodeInput, subsets input 11646
LoopNode::result redefines structuredNodeOutput, subsets output 11646
LoopNode::test multiplicity is 1..* 8682
Message::signature not derived, not read only 14629
OpaqueAction::body nonunique, ordered 10081
OpaqueAction::language ordered 10081
OpaqueBehavior::body nonunique, ordered 10081
OpaqueBehavior::language ordered 10081
OpaqueExpression::body nonunique, ordered 10081
OpaqueExpression::language ordered 10081
Operation::interface subsets namespace, subsets featuringClassifier 13991
Operation::isOrdered read only 15568
Operation::isUnique read only 15568
Operation::lower read only 15568
Operation::type read only 15568
Operation::upper read only 15568
Port::provided OCL expression 13080
Port::required OCL expression 13080
Property::owningAssociation subsets redefinitionContext 15526
Property::redefinedPort subsets redefinedProperty 10144
Reception::signal multiplicity is 1..1 12558
RedefinableTemplateSignature::classifier redefines template, subsets owner 11244
State::deferrableTrigger subsets ownedElement 14926
StateMachine::extendedStateMachine redefines redefinedBehavior, redefines redefinedElement 15669
Stereotype::icon subsets ownedElement 14926
Stereotype::profile read only 15568
StructuredActivityNode::edge subsets ownedElement 13718, 14926
StructuredActivityNode::node subsets ownedElement 13718, 14926
TimeEvent::when subsets ownedElement 14926
TimeExpression::expr subsets ownedElement 14926
Transition::trigger subsets ownedElement 14926
ValuePin::value subsets ownedElement 14926
ValueSpecificationAction::value subsets ownedElement 14926
Vertex::incoming read only 15568
Vertex::outgoing read only 15568
WriteStructuralFeatureAction::value multiplicity is 0..1 9870
WriteVariableAction::value multiplicity is 0..1 9870

The following table lists the properties that were added by the revised specifications. Additions that had a nontrivial impact on functionality provided by the UML2 project are highlighted in yellow.

Property Issue(s)
Action::isLocallyReentrant 6111
Classifier::isFinalSpecialization 10515
EnumerationLiteral::classifier 14631
InteractionUse::returnValue 10591
InteractionUse::returnValueRecipient 10591
Package::ownedStereotype 12833, 15568
Package::URI 15370
Port::isConjugated 13080
Property::interface 14235
Property::isID 15369
StructuredActivityNode::structuredNodeInput 11646
StructuredActivityNode::structuredNodeOutput 11646

Operations

Operations in UML are represented as Java methods in the UML2 API. These signatures for these methods are generated using the (customized) EMF code generator and their bodies are implemented by hand.

The following table lists the operations that were removed by the revised specifications. Removals that had a nontrivial impact on API compatibility are highlighted in yellow.

Operation Issue(s)
AssociationClass::allConnections() 9374

The following table lists the operations that were modified by the revised specifications. In all cases the OCL expression defining the result of the operation was changed.

Operation Issue(s)
Classifier::allParents() 12848
Classifier::hasVisibilityOf(NamedElement) 10006
Property::isConsistentWith(RedefinableElement) 8460
StateMachine::ancestor(State, State) 10832

The following table lists the operations that were added by the revised specifications.

Operation Issue(s)
Package::allApplicableStereotypes() 12833
Package::containingProfile() 12833
Stereotype::containingProfile() 12833

Constraints

Constraints in UML are represented as Java methods in the UML2 API. The signatures for these methods are generated using the (customized) EMF code generator, along with an associated validator utility class, and their bodies are implemented by hand.

The following table lists the constraints that were removed by the revised specifications. Removals that had a nontrivial impact on API compatibility are highlighted in yellow.

Constraint Issue(s)
Classifier::generalization_hierarchies 15574
Connector::assembly_connector 7251
Connector::between_interface_port_implements 7248
Connector::between_interface_port_signature 7249
Connector::union_signature_compatible 7250
Constraint::not_applied_to_self 15574
ObjectNode::not_unique 8891
Port::required_interfaces 12492
Property::navigable_readonly 15128
TransitionKind::state_is_external 9172
TransitionKind::state_is_local 9172

The following table lists the constraints that were modified by the revised specifications. In all cases the OCL expression defining the specification of the constraint was changed.

Constraint Issue(s)
Association::specialized_end_number 9374
Association::specialized_end_types 9374
BehavioredClassifier::class_behavior 12781
CollaborationUse::every_role 8743
CombinedFragment::opt_loop_break_neg 11286
Connector::between_interfaces_ports 7247
ConnectorEnd::role_and_part_with_port 8776
ExceptionHandler::result_pins 8479
InteractionUse::all_lifelines 10590
Message::sending_receiving_message_event 14629
Profile::metaclass_reference_not_specialized 8601
Profile::references_same_metamodel 8601
RemoveStructuralFeatureValueAction::non_unique_removal 9870
RemoveVariableValue::unlimited_natural 9870
StructuralFeatureAction::multiplicity 10045
StructuralFeatureAction::same_type 10045
TestIdentityAction::result_is_boolean 14570
WriteStructuralFeatureAction::input_pin 9870, 14569
WriteVariableAction::same_type 9870

The following table lists the constraints that were added by the revised specifications.

Constraint Issue(s)
AddStructuralFeatureValueAction::required_value 9870
AddVariableValueAction::required_value 9870
AssociationClass::disjoint_attributes_ends 9374
Classifier::non_final_parents 10515
Clause::test_and_body 8495
Component::no_nested_classifiers 12432
ConditionalNode::clause_no_predecessor 8684
ConditionalNode::executable_nodes 8495
ConditionalNode::matching_output_pins 8498
ConditionalNode::no_input_pins 11646
ConditionalNode::one_clause_with_executable_node 8495
EnumerationLiteral::classifier_equals_owning_enumeration 14631
ExpansionNode::region_as_input_or_putput 10145
GeneralOrdering::irreflexsive_transitive_closure 9806
InteractionUse::returnValueRecipient_coverage 10591
InteractionUse::returnValue_type_recipient_correspondence 10591
LoopNode::executable_nodes 8492
RedefinableElement::non_leaf_redefinition 12532
Stereotype::associationEndOwnership 14961
Stereotype::binaryAssociationsOnly 14961
StructuredActivityNode::input_pin_edges 9014
StructuredActivityNode::output_pin_edges 9014
Transition::state_is_external 9172
Transition::state_is_internal 9172, 10498
Transition::state_is_local 9172

Package Merge

The UML2 project provides an implementation of the package merge algorithm described in the UML specification. This utility is intended for use by clients but is also used to produce the source model for generating the API itself. Changes in the revised specifications (to resolve issues 10515, 12532, and 13330) required updates to this utility.

The following changes with respect to package merge are of particular note:

  • Associations are now matched by name (only) when performing a merge.
  • A new option, Empty Qualified Names, reports cases where the qualified name of a classifier is found to be empty.
  • Another new option, Indistinguishable Classifiers, reports cases where a classifier is indistinguishable from the other classifiers in a given package.

U240MG PackageMerge.png

Profiles

The UML2 project provides an implementation of the profiles mechanism described in the UML specification. This implementation supports definition of “static” or “dynamic” profiles containing stereotypes to extend the UML metamodel with domain-specific tagged values. Changes in the revised specifications (to resolve issues 11160, 12833, 13306, 14092, 15006, and 15370) required updates to this mechanism.

The following changes with respect to profiles are of particular note:

  • The Standard profile that was provided by previous releases of UML2 has been split into two, corresponding to the L2 and L3 profiles defined in the UML specification.
  • Static (rather than dynamic) implementations of the L2 and L3 profiles have been provided by UML2, hence the introduction of new org.eclipse.uml2.uml.profile.l2 and org.eclipse.uml2.uml.profile.l3 bundles, respectively.
  • The profiles mechanism in UML2 now supports packages nested within profiles and stereotypes owned by packages; the Ecore definition for such profiles will have the corresponding structure (i.e., nested Ecore packages).
  • The new Package::URI property is now used to define the namespace URI of a profile (and nested packages), unless it is overridden by the nsURI tag from the Ecore profile.
  • A new convenience utility method, UMLUtil#getStereotypeApplication(Element, Class<T>), has been added to provide an easy way to obtain a stereotype application from an element based on its (statically defined) Java class.

Resources

The UML2 project provides a number of built-in primitive types libraries (Ecore, Java, and UML), metamodels (Ecore and UML), and (dynamic) profiles (Ecore and Standard), serialized in UML format. Changes in the revised specifications (to resolve issues 12583, 13306, 13993, and 14092) required updates to these resources.

The following changes with respect to resources are of particular note:

  • XMI resources provided by the OMG, namely Infrastructure.xmi, Superstructure.xmi, UML.xmi, PrimitiveTypes.xmi, StandardProfileL2.xmi, StandardProfileL3.xmi, and MOF.xmi, are now shipped with UML2 in the org.eclipse.uml2 bundle.
  • The primitive types that were once an integral part of UML proper have been segregated into a separate namespace for reuse by multiple specifications (e.g., CMOF and UML); "first class" implementations of these primitive types have been provided by UML2 in the new org.eclipse.uml2.types bundle.
  • The name of root model in the UML primitive types library has been changed from "UMLPrimitiveTypes" to "PrimitiveTypes" to reinforce its more independent nature.
  • A new Real type has been added to the UML primitive types library.
  • Since the UML metamodel resource is now based directly on the corresponding XMI resource provided by the OMG (as are all of the other OMG-defined resources provided by UML2 project), it no longer extends the Ecore metamodel resource, nor does it contain customizations (e.g., convenience operations) introduced by the UML2 project.

Legacy Interchange

The UML2 project supports interchange of legacy resources, i.e., artifacts that were created using older versions of the project. This XMI-based migration mechanism was enhanced to deal with the incompatibilities introduced by the new version of the UML2 API and schema. A mapping between the legacy UML2 3.x metamodel and the proposed new UML2 4.0 metamodel was created (using the Ecore2Ecore and Ecore2XML mechanisms provided by EMF) and existing mappings for older versions of the UML2 schema were updated. New resource handler and extended metadata implementations were also developed to cover transformations which could not be automated during deserialization.

The following changes with respect to legacy interchange are of particular note:

  • Instances of OpaqueAction that are arguments of interaction uses are preserved in InteractionUse::argument tags from the UML2 profile.
  • The clients and suppliers of component realization dependencies are swapped.
  • Instances of Pin are converted to instances of InputPin.
  • Applications of the Standard profile are replaced by applications of the L2 and L3 profiles.
  • Instances of DestructionEvent are converted to instances of DestructionOccurrenceSpecification.
  • Instances of ExecutionEvent are discarded.
  • Operations of call events, receive operation events, and send operation events are set as the signatures of their associated messages; instances of ReceiveOperationEvent and SendOperationEvent are discarded.
  • Signals of receive signal events, send signal events, and signal events are set as the signatures of their associated messages; instances of ReceiveSignalEvent and SendSignalEvent are discarded.
  • Instances of Trigger that are owned triggers of behaviored classifiers are preserved in BehavioredClassifier::ownedTrigger tags from the UML2 profile.

XMI Interchange

The UML2 project supports interchange of OMG-compliant XMI resources, i.e., artifacts that were created using other tools that conform to the UML specification. This XMI-based mechanism was enhanced to deal with XMI documents that conform to the 2.4 version of the UML specification. New resource handler and extended metadata implementations were also developed, and existing ones (supporting older versions of OMG-compliant XMI) were updated.

Changes in the revised MOF 2 Mapping specification (to resolve issues 9644 and 9682) required additional updates to the XMI interchange mechanism provided by UML2.

The following changes with respect to XMI interchange are of particular note:

  • XMI resources serialized by UML2 are now based on XMI 2.4, whose version is 20100901 and whose namespace URI is http://www.omg.org/spec/XMI/20100901.
  • The org.omg.xmi.nsURI and org.omg.xmi.nsPrefix CMOF tags now are serialized for profiles when saving them in OMG XMI format.
  • Namespace URIs of UML2 resources are mapped to their corresponding OMG XMI resources according to the following table:
UML2 OMG XMI
http://www.eclipse.org/uml2/4.0.0/Types http://www.omg.org/spec/PrimitiveTypes/20100901
http://www.eclipse.org/uml2/4.0.0/UML http://www.omg.org/spec/UML/20100901
http://www.eclipse.org/uml2/4.0.0/UML/Profile/L2 http://www.omg.org/spec/UML/20100901/StandardProfileL2
http://www.eclipse.org/uml2/4.0.0/UML/Profile/L3 http://www.omg.org/spec/UML/20100901/StandardProfileL3

CMOF Interchange

The UML2 project supports interchange, and automatic conversion to and from UML, of Complete MOF (CMOF) resources. This XMI-based interchange mechanism was enhanced to deal with changes made in both UML 2.4 and MOF 2.4. A mapping between the CMOF 2.4 metamodel and the new UML2 4.0 metamodel was created (using the Ecore2Ecore mechanism provided by EMF) and existing mappings for older versions of the schemas were updated. New resource handler and extended metadata implementations were also developed to cover transformations which could not be automated during deserialization.

Changes in the revised MOF specification (to resolve issues 6905, 10968, 12800, 15397, 15398, 15820, and 15827) required additional updates to the CMOF interchange mechanism provided by UML2.

The following changes with respect to CMOF interchange are of particular note:

  • TBD

Ecore / UML Conversion

The UML2 project provides utilities for conversion of UML models to and from a corresponding Ecore representation. These utilities are intended for use by clients but an integral part of the process followed to produce source models, generate code for the UML2 project, and define profiles. Changes to the API, as described above, required updates to these utilities; in particular, they needed to take the new Package::URI and Property::isID properties into account when performing conversions.

The following changes with respect to Ecore / UML conversion are of particular note:

  • TBD

Examples

The UML2 project provides a number of examples, including editor actions which are in fact used by the UML2 project to produce some of the artifacts it publishes. These examples will were updated based on the changes that were made to the API and reference resources described above. More specifically, the actions to generate the standard profile and UML primitive types library were updated based on the XMI resources provided by the OMG and the actions to convert models to model libraries or metamodels were updated to make use of the new (static) standard profile implementations mentioned above.

The following changes with respect to source code are of particular note:

  • TBD

Source Code

As mentioned already, the UML2 project has(as other projects have) switched to git instead of CVS as its source code management system for the upcoming Juno release. In fact, all of the changes for UML2 4.0 have been committed (and pushed) to git (only).

The following changes with respect to source code are of particular note:

  • TBD

Builds

As mentioned above, the installable artifacts (update sites and downloads) for the UML2 project were previously produced using an unsupported pre-Athena build system running on a machine that was at risk of being decommissioned. Buckminster was used instead to develop a new build system which now runs on Hudson and extracts the UML2 source code from git. The resulting artifacts are published to a new set of UML2-specific p2 repositories (instead of the antiquated MDT one) and included in the top-level composite repositories for the Modeling project.

The following changes with respect to builds are of particular note:

  • TBD