Copyright © 2006 International Business Machines Corp.

UML2 2.0 Migration Guide



UML2 1.x Migration to UML2 2.0

Last revised 16:56 EDT August 3, 2006 (  marks interesting changes over the previous revision)




The implementation of the latest version of UML (UML2 2.0) provides several enhancements over its predecessor (UML2 1.x) including clarification of key concepts, introduction of important optimizations and newly introduced custom operations.   This guide will summarize those enhancements so that users will be able to quickly and effectively succeed in the migration process.


One caveat that should be mentioned up front is that this document is designed to help the reader get a sense of what has changed but by no means is intended to provide the kind of comprehensive coverage that a thorough reading of the updated Superstructure Specification will provide.



August 3, 2006

James Bruck and Kenn Hussey, IBM



There are two main goals of this document:

1.      To provide guidance in the migration process from UML2 1.x API (based on an interim draft of the UML 2.0 specification) to the UML2 2.0 API (based on the UML 2.1 specification).


·        Summary of newly refined concepts will be covered in the section “Superstructure Specification Changes

·        Migration tips will be covered in the section entitled “API Migration”.

·        Data migration of existing models and profiles will be covered in the section entitled “Model Artifact Migration



2.      It is also the goal of this document to summarize the features of the UML2 implementation so that developers may take advantage of the newly introduced optimizations and features.


·        A summary of these features will be covered in section entitled “Features of UML2 2.0”.




A few terms and abbreviations will be used throughout this document.




UML2 1.x

This refers to the versions of the UML API which were based on an interim draft of the UML 2.0 specification defined by OMG.


The UML 2.0 Superstructure Specification can be found at:


UML2 2.0

This refers to the latest version of the UML API which is based on the UML2.1 specification defined by OMG.


The latest draft of the UML 2.1 Superstructure Specification can be found at:


Eclipse 3.2

UML2 2.0 depends on Eclipse 3.2.


EMF 2.2

UML2 2.0 depends on EMF 2.2.




Object Management Group.  A consortium that promotes the adoption of standards.



Revision Task Force.  A process which the OMG uses to revise a specification.




Finalization Task Force.  A process which the OMG uses to finalize a specification.




Getting Started


Depending on your requirements, you will presumably be interested in one or more of the following aspects of migration:  API migration, artifact migration, or discovering what has changed in UML. 

This document is structured to help you accomplish your task as quickly as possible.  To that end, you may use the table below to quickly navigate to the section you are interested in.




Understanding changes to the Superstructure specification.

Superstructure Specification Changes


Understanding new features of UML2 2.0.

Features of UML2 2.0


Migration of existing models to the new format.


Model Artifact Migration


Migration of existing profiles to the new format.


Profile Artifact Migration


Migration of code that uses the UML2 1.x API .


API Migration



Although it has been mentioned in other documents such as the UML2 2.0 Project Plan, several key points should be re-iterated before continuing:

·        The older UML2 1.x version will not be shipped together with the newer UML2 2.0 version.

·        UML2 2.0 will not be upwards contract-compatible with UML2 1.x.

·        UML2 2.0 will not be upwards binary-compatible with UML2 1.x.

·        The newer UML2 2.0 defines a namespace called org.eclipse.uml2.uml that is different from the older org.eclipse.uml2 namespace.

·        Models created with the newer UML2 2.0 will have a .uml extension versus the older .uml2 extension.


If there are concepts that are not fully described by this document, you may find the following useful:

1.      Refer to the official UML 2.1 Superstructure Specification for complete descriptions.

2.      Refer to the change ballots on for specific issues (described below).


Superstructure Specification Changes


Before grappling with the task of understanding the myriad of changes to UML, let’s first review the process by which the Superstructure specification has evolved to its current form.




The above image illustrates several key points:

·        Notice that the UML2 1.x is based on an interim draft of the UML 2.0 version of the specification.

·        Also, notice that the UML2 2.0 API has been formulated based on change ballots coming out of the FTF and RTF processes that OMG has defined.

·        Also, UML2 2.0 API has been written according to the 060402 convenience document which will be identical to the formal UML 2.1 specification which at the time of this writing has not yet been produced.


The primary means by which the summary of changes discussed in this document has been obtained is from summarizing these FTF and RTF ballots.

Key Changes


Several key changes can be distilled out of the updated Superstructure specification.



Let’s first review the differences between Trigger, Event and Message:

·        A trigger is the association between an event and specification of an effect or behavior.  The trigger can include conditions on the recognition of the event, such as the port that a message was received on.

·        An event is the recognition of something that happens at a point in time.   In particular, the receipt of a message by an object or the handling of a previously received message by an object is one kind of event.  Recognition of state changes does not involve messages.  There are other kinds of events such as time events and the receipt of calls.

·        A message itself is not an event, as it spans an interval of time; its receipt or its sending can be an event.



So what has changed? 

In the latest version of the specification, the concept of Event has been separated from the concept of Trigger.  The Trigger metatype is now a concrete class whereas in the past, this was an abstract class.   The various concrete triggers such as CallTrigger, have been removed and replaced by a corresponding Event type (i.e. CallEvent).

For a given model to be considered valid, all triggers must refer to some event. A trigger must refer to an event since triggers relate events to behaviors. 

Triggers can be owned either by transitions or by behaviored classifiers (as an example).  

Existing code presumably has transitions owning one of the various trigger types such as CallTrigger.  Such code should be changed such that the transition will refer to the concrete trigger type and the trigger will refer to an event created somewhere at the package level (events are packageable elements and are owned by some package).

In order to create an event for a particular transition, one could:

·        Find the nearest package using the Element#getNearestPackage() function.

·        Call Package#createPackagedElement(EClass).  You would pass the event type as a parameter.




Let’s review some basic interaction concepts as defined by the current specification:

In general, in UML: an event occurrence refers to an instantaneous change of state in the system being modeled.  An occurrence specification is a model element that represents a particular event occurrence.  An event is a model element that specifies a set of possible event occurrences all of the same kind.

·        Event

o       State changes of a system are the result of the occurrence of some event.

o       Creation events occur when the system creates some object.

o       Destruction events occur when the system destroys an object.

o       Execution events occur at the start of an Action or Behavior which is referenced by the object of the lifeline.

o       Message events occur as a result of the sending or the receiving of messages from one object to another. 

       The message event instance can reference either an operation that was called or a signal that is sent.

       It is the intent of the specification that message events are only referenced by message occurrence specifications, however, as of this writing there is no explicit restriction in the API or in the specification stating this.


·        OccurrenceSpecification

o       Occurrence specifications model the occurrence of an event.

       Occurrence specifications represents points on a lifeline that deliver the anchors for Messages and execution specifications

       Occurrence specifications must refer to an event that identifies the kind of event that occurred.


·        ExecutionOccurrenceSpecification

o       Reference execution events.  


·        ExecutionSpecification (abstract)

o       The concrete types are BehaviorExecutionSpecification and ActionExecutionSpecification.

o       An execution specification does not model an event.  Instead, it models the act of some object executing some portion of its behavior specification (e.g., executing an action or behavior).

o       An execution specification defines start and finish points on the lifeline, which define its active period, and reference the corresponding action or behavior that is executing. A start and finish must be specified.

o       Messages do not necessarily have to “hook up” execution specifications - the execution specification may show “spontaneous” execution (e.g. representing queuing delays).


·        Message

o       A message is the result of the execution of a communication action (a call or asynchronous signal send).  The message carries the information about the call and is sent from the invoking object and received by the invoked object.

o       Objects can communicate via messages.

o       Messages have arguments if the called operation has parameters, or attributes if the message sends a signal.

o       Messages lead from the sending message end to the receiving one.  The message end could be an occurrence specification or a gate.



So what has changed?  Interactions have changed in several important ways.


·        OccurrenceSpecification is a newly introduced type that replaces EventOccurrence.

The new specification introduces two new types of OccurrenceSpecification: event occurrence specifications and message occurrence specifications

o       In order to migrate older event occurrences you can follow this rule of thumb:

       If there is a message that is coming into or going out of the event occurrence, then it can be replaced with message occurrence specification.

       If there is a spontaneous stop, then you can replace with an occurrence specification and refer to a destruction event.

o       If the event occurrence starts or finishes an independent execution occurrence then it maps to and execution occurrence specification.

o       Occurrence specifications must reference an event.

o       Events could be referenced by multiple occurrence specifications or triggers.  Since an event is owned by a package, this is a convenient way to tie together both statechart concepts and sequence concepts.

o       Differing messages that refer to the same operation should have ends that refer to the same send and receive event.    It is the occurrence of the event that causes the operation to be executed.  This is an important point when creating consistent models that could either be represented by state machine diagrams and sequence diagrams. 


·        The Stop metaclass has been removed from the latest version.

o       Stop used to be a specialization of EventOccurrence.   Now, stops should be replaced by creating either an occurrence specification or a message occurrence specification that references a destruction event.


·        ExecutionOccurrence (older)

o       Mapped to either an action exection specification that references an action, or a behavior exection specification that refers to a behavior (more general).


·        EventOccurrence (older)

o       In the past, messages could go between a send event occurrence and receive event occurrence. Now, instead of the event occurrence we must use a message occurrence specification.


·        Message

o       A message signature is now derived from the operation or signal that is referenced from the event associated with the message occurrence specification, at the end of the message. (a message occurrence specification is a message end)  One could have call events, receive operation events, receive signal events and corresponding “send” versions being created at the package level and referenced by the message occurrence specification.  Those events can refer to operations or signals from which the signature is derived.

o       If an operation is not present, it is derived from the receiving end (this is to take into account gates since they do not have events associated with them).


·        MessageSort

o       The synchSignal literal has been removed.

o       The createMessage, deleteMessage and reply literals are new.




UML 2.0 separated the concepts of navigability from association end ownership.  In UML 2.1, a new “black dot” notation has been introduced where it is desired to make ownership explicit.

Diagrams showing associations now can display three distinct concepts:  aggregation type, ownership and navigability.  These three notions could all potentially be combined at once in the display of an association.

The Superstructure specification refers to some presentation options that might be implemented including suppression of some display options. The specification does not mandate the use of explicit end-ownership notation, but defines a notation which shall apply in models where such use is elected.


In the diagram below:

·        endA is owned by classifier B and endB is owned by BinaryAssociationAB.

·        The absence of a dot signifies ownership by the association.




Refer to Issue 8956 for a more detailed explanation of this notation.


Time Concepts


Shortcomings in the older version of the specification made working with time concepts almost impossible.  All time expressions were relative to “now” and there was no way to specify some arbitrary point time “t” to which all other time expressions were relative.  In the current specification, the concepts of TimeObservation and DurationObservation have been introduced to fix this shortcoming.  Time expressions and durations now can refer to these observations to create more complex expressions that can be evaluated given some specific time.  Observations are really a way to introduce variables in time expressions and durations.


In addition, older TimeObservationAction and DurationObservationAction have been replaced by opaque actions.   The “now” and “duration” fields in these old metaclasses have been replaced by value pins as input values that refer to time expressions and durations (both of which are value specifications).


Time events are also newly added to the specification. Time events can also refer to time expressions thereby making it possible for execution specifications (that reference occurrence specifications) to refer to sophisticated time expressions.


For a thorough explanation of time concepts, please refer to issue 8894 and refer to the Superstructure specification.





Profiles have undergone some significant changes in the latest UML version.


·        The most notable changes include:

o       The ProfileApplication meta-type no longer extends PackageImport.  It now directly extends DirectedRelationship.

o       The structural feature ProfileApplication::importedProfile has been renamed to ProfileApplication::appliedProfile.

o       In the past, applying a profile implied importing the Package.  This is not necessarily the case now.

o       We now have Image support in stereotypes.

o       The standard profiles have been organized by compliance level.


Detailed Changes


The following is a more detailed description of key changes based on change ballots.  You may follow the links to the original issues to discover more about the history of the change.


·        Issue 6243 Issue 8956 Navigability of Associations

o         Navigability of association ends has been separated from ownership

o         New notation for owning end/navigability changes in association

o         Navigability in relational modeling is a requirement for some query service, rather than property ownership.   The model should indicate it is possible at runtime to get from one class to another efficiently rather than indicate the initial class has a property typed by the second class.


·        Issue 7328 Message Sort

o         MessageSort::synchSignal mapped to MessageSort::asynchSignal

o         A concept assumed in the Interactions chapter has no equivalent in the actions chapter.


·        Issue 7637 Event Occurrence

o         EventOccurrence::getFinishExecs and getStartExecs list changed to scalar

o         Additional events for interactions

o         The corresponding property is ExecutionOccurrenceSpecification::execution which is a kind of ExecutionSpecification. 

o         The multiplicity changed from * to 1 because the semantics changed somewhat.  That is in UML2 2.0 even if two execution specifications start at the same time, they have individual start events.  Therefore, when converting older models in which one EventOccurrence had more than one ExecutionOccrrence (if there are such), it is necessary to create multiple copies of the ExecutionOccurrenceSpecification ( corresponding to the UML2 1.x) EventOccurrence, so that each ExecutionSpecification can have its own start event.


·        Issue 7319 ExecutionOccurrence

o         ExecutionOccurrence::getBehaviors list changed to scalar

o         In UML2 1.x this was the specification of the Behavior that, when executed, caused the ExecutionOccurrence.  In UML2 2.0 ExecutionOccurrence was replaced by ExecutionSpecification.  Furthermore, action executions (ActionExecutionSpecification) were differentiated from other types of executions (BehaviorExecutionSpecification).  Since the UML2 1.x model did not support the former case, this will never occur when converting a UML2 1.x model.  So the corresponding feature is BehaviorExecutionSpecification::behavior.


·        Issue 6207 Interval

o         Issue 8318, 8894

o         Interval::getMaxes and getMins list changed to scalar

o         This is a correction of a mistake from the previous UML version.  This parameter should never have been used as a list.


·        Issue 7560 Primitive Function

o         PrimitiveFunction::getBody and getLanguage scalar changed to list

o         Activity::getBody and getLanguage scalar changed to list

o         OpaqueExpression::getLanguage and getBody scalar changed to list

o         Latest version allows one to express the same thing in different languages.

o         This modification should be represented in the properties view.

o         The language does not have to be specified and default to OCL ( may cause issues )

o         Affects evaluating of constraints.

o         To resolve this migration issue, simply add existing scalar to list.


·        Issue 6682 Trigger vs. Event

o         AnyTrigger, CallTrigger, TimeTrigger, ChangeTrigger, MessageTrigger, SignalTrigger mapped to concrete Trigger.  That new trigger refers to the corresponding Event.

o         Trigger types have been replaced by Events.

o         Triggers are owned by behaviors.

o         Concept change: Not every event has to have a trigger.  An event might not trigger anything.

o         An event is an instantaneous thing.  An EventOccurrenceSpecification is an instance of an event.

o         An event is a receipt of a signal (for example).

o         Trigger is a reaction to an event.  e.g. only triggered if signal X arrives on port P.

o         Old trigger types can be replaced by their corresponding Event type.

o         For those old triggers that make use of the port property, a new Trigger (now a concrete class) should be created.

o         The new trigger can now be owned either by the state, transition or classifier.

o         The new event can be owned by the model or namespace.

o         The same event might trigger 2 different actions.  That is why the state machine does not necessarily own the event.


·        Issue 8894 ObservationAction

o         DurationObservationAction, TimeObservationAction are mapped to OpaqueAction.


·        Issue 8706 Issue 9183 ProfileApplication

o         Issue 6242

o         Now a ProfileApplication is a subclass of DirectedRelationship rather than PackageImport.


·        Issue 7405 ApplyFuncitonActoin

o         Issue 7319, 7365

o         ApplyFunctionAction::getArguments, getFunction, getResults unmapped.

o         ApplyFunctionAction mapped to CallBehaviorAction.


·        Issue 7421 TemplateSignature

o         TemplateSignature::getNestedSignatures and getNestingSignature unmapped

o         This was a mistake in the previous UML version.  It was undocumented in the official specification and should never have been used.


Features of UML2 2.0


As described in the UML2 2.0 Plan, the following features are part of this version:

Eclipse 3.2 / EMF 2.2 Compatibility


·        UML2 2.0 has been aligned with Eclipse3.2 and EMF2.2 to take advantage of the updated functionality of these components.


·        Support for sorted cell editors.

o       The latest version of EMF supports sorted cell editors and UML takes advantage of that.


·        Package Literals

o       New package literals have been introduced for accessing metadata.

o       More efficient to use package literals instead of metadata accessor methods, e.g. use UMLPackage.Literals.PACKAGE__PACKAGED_ELEMENT instead of UMLPackage.eINSTANCE.getPackage_PackagedElement().


UML 2.1 Conformance


·        UML2 implementation has been regenerated based on the UML 2.1 Superstructure specification

o       UML2 resources (libraries, metamodels, profiles) have been updated.


·        The revised package merge algorithm has been implemented

o       Helper utilities have been created for package merge.

o       UMLUtil currently supports two functions

       void merge(org.eclipse.uml2.uml.Package package_, Map options) ;

       void merge(org.eclipse.uml2.uml.Package package_,Map options, DiagnosticChain diagnostics, Map context)

o       UMLUtil implements a nested inner class that can be overridden for application-specific merge.


·        Profile Support

o       Stereotype attributes type can now reference a metaclass.

       Association between stereotype and metaclass (which introduces property on stereotype).

o       Image support in profiles

       Image is a new metaclass.

       Image part of stereotype definition.

       Introduces notational changes.

       Can now have multiple images per stereotype

o       Location of stereotype applications.

       Will no longer be in an annotation on an element. 

       Will be added to the resource and will reference the elements to which they are applied

       Listeners will be affected.

       When stereotypes are applied with applyStereotype(…)’  the object representing that particular stereotype application will be returned.

o       Required stereotypes will automatically be applied and unapplied as profiles are applied and unapplied (and as elements are added/removed from packages).

o       Previously we had three standard profiles.

       Will now use only one standard profile (called “Standard.profile.uml”) which is L3 compliant


UML 2.1 Interchange


·        Support for loading and saving in “official” OMG format.  The UML editor now supports saving with .xmi extension.   Simply select the “File > Save As...” and specify a .xmi extension.


·        The difference between the .xmi format and the .uml is that annotations are not a legal part of the UML schema.  When saving your existing .uml model to the .xmi format, annotations will be converted to XMI extensions.


·        Opening a model with .xmi format with the UML editor will work and properly render using the UML API.


UML2 2.0 Migration


·        For data migration, a resource migration mechanism has been provided, which provides resource migration from the UML2 1.x schema to the 2.0 schema.  See the section entitled Model Artifact Migration for more details.


Reduced Memory Footprint / Improved Performance


·        Retrieval of derived collections made more efficient.

o       Derived collections now use a “smart” iterator.

       The result is that sequentially moving through collections using an indexed approach is very inefficient.

       For a derived collection, getSize() is O(n)

       The list does not hold onto all the elements at once.  Memory price is paid only when the list is traversed.

o       Always use an iterator when moving through derived collections obtained from UML2 API.

o       Index-based iteration need only be avoided for lists returned for features that are derived unions.  In general, a way to tell which kind of iteration will be optimal at runtime is to test instanceof RandomAccess (see Javadoc for that interface for details).


Resource Fragments


·        Support for segregation of UML2 resources into ‘fragments’ (e.g. *.fragment.uml) with packages as root elements has been provided.


·         Support for containment proxies has been introduced.

o       Enabled on a per-feature basis.

       Defines moveable “subunits”.

                                           Is enabled for all containment features in UML2.

       EMF support for logical resources is to check definition of each feature and invoke isResolveProxies().  

       isResolveProxies  is an attribute on every Ecore reference and must be set to TRUE on containment references for which proxy support is desired (must be set to TRUE for containment proxies to work)


·        New menu items in UML editor to control or un-control in a unit.



Derived Features


·        For derived unions that are redefined by subclasses.

o       Cases where derived unions were redefined by non-derived properties have been removed; as a result, the properties like Package::ownedMember and Component::ownedMember are now derived and new modifiable properties named ‘packagedElement’ are available.


·        Creation of smart lists for derived properties.


·        Should not use indexed-based iteration (performance impact)


·        As a result, certain previous read only lists now are modifiable and vice versa.


Improved Convenience Methods


·        Convenience methods for getting relationships.




EList Element#getRelationships()


Gets all relationships of which this element is a participant.

EList Element#getRelationships(EClass)


Gets all relationships of a particular type of which this element is a participant.

EList Element#getSourceDirectedRelationships()


Get directed relationships of which this element is a source.

EList Element#getSourceDirectedRelationships(EClass)


Get directed relationships of a particular type of which this element is a source.


EList Element#getTargetDirectedRelationships()


Get directed relationships of which this element is a target.

EList Element#getTargetDirectedRelationships(EClass)


Get directed relationships of a particular type of which this element is a target.



·        Enhanced factory and look-up methods.  

o         The factory and look-up methods now have an optional parameter to create the item if it does not currently exist.

o         The factory methods have additional parameters to allow for one-step creation.

o         Also an additional parameter for factory and look-up methods indicating whether case should be ignored.

o         The table below shows examples of these enhancements.




Operation Class#createOwnedOperation(String name, EList ownedParameterNames, EList ownedParameterTypes);


[sample] One-shot creation of operation with parameters.

Operation Class#getOwnedOperation(String name, EList ownedParameterNames, EList ownedParameterTypes);


[sample] Get specific operation based on param types.  Passing NULL is OK.

Operation Class#createOwnedOperation(String name, EList parameterNames, EList parameterTypes, Type returnType);



Operation Class#getOwnedOperation(String name, EList ownedParameterNames,EList ownedParameterTypes, boolean ignoreCase, boolean createOnDemand);


[sample] Possibly create on demand.



Classifier Class#getNestedClassifier(String name);


[sample] Simple form of getter

Classifier Class#getNestedClassifier(String name, boolean ignoreCase, EClass eClass, boolean createOnDemand);


[sample] Getter with potential to create if not found.

Classifier Class#createNestedClassifier(String name, EClass eClass);


[sample] Creation by specifying name.

PackageableElement Package#getPackagedElement(String name, boolean ignoreCase, EClass eClass, boolean createOnDemand);


[sample] Getter with ability to create.

PackageableElement Package#getPackagedElement(String name);


[sample] Simple form of getter.

PackageableElement Package#createPackagedElement(String name, EClass eClass);


[sample] Creation with EClass specified.



Port EncapsulatedClassifier#createOwnedPort(String name, Type type);



Port EncapsulatedClassifier#getOwnedPort(String name, Type type, boolean ignoreCase, boolean createOnDemand);


[sample] Getter with ability to create and set type.

Port EncapsulatedClassifier#getOwnedPort(String name, Type type);

[sample] Simple form of getter.



·        Enhanced UMLUtil methods.


o       Named elements can now be found by qualified name and type




Collection UMLUtil#findNamedElements(Resource resource, String qualifiedName, boolean ignoreCase, EClass eClass)



Collection UMLUtil#findNamedElements(Resource resource, String qualifiedName)


Simple form.


o       Safe application of stereotypes.




EObject UMLUtil#safeApplyStereotype(Element element,    Stereotype stereotype)

Will apply profile to outermost package if not already applied.   All efforts are made to safely apply stereotype.



o       UMLUtil now defines a merge(…) function that performs a package merge as defined by the Superstructure specification




void UMLUtil#merge(org.eclipse.uml2.uml.Package package_, Map options)




·        Utilities to get all attributes and operations even inherited ones.




EList Classifier#getAllAttributes()

Retrieves inherited attributes.


EList Classifier#getAttributes()

Retrieves those attributes on this classifier only.


EList Classifier#getAllOperations()


Retrieves inherited operations.


EList Classifier#getOperations()


Retrieves those operations on this classifier only.


·        Profile utilities.




PackageImport Profile#createMetamodelReference(org.eclipse.uml2.uml.Package importedPackage)



ElementImport createMetaclassReference(PackageableElement importedElement)



Stereotype createOwnedStereotype(String name, boolean isAbstract);



boolean isDefined();



·        Custom operations specified in metadata

o       Result is that OCL engine can now use custom operations

       e.g. Check for applied stereotypes.

o       Lists vs. Sets

       Custom operations in source models used to return sets, now they return EList




·        Javadoc based on the Superstructure specification has been included.


Enhanced Icons


·        Icons added for each of the types defined by UML (instead of the default generated by EMF).


UML Ecore Importer / Exporter


Newly introduced in this version of the UML API is an Ecore importer and exporter.   This functionality takes advantage of the new exporter framework in EMF to convert Ecore models to UML (*.uml) models, and converts UML models to Ecore.


There are three means by which this functionality can be accessed.


  1. Through the import/export wizards.


    1. When creating a new EMF project, via the EMF Project wizard, it is possible to select a UML model as the source type.  The following page will appear…



    1. When exporting a generator model, it is possible to select a UML as the destination type. The following page will appear:




  1. Through the Ecore editor and UML editor.


    1. With the examples plug-ins installed…

                                                               i.      From the Ecore editor, on an Ecore package, select the “Convert to UML model…” option.

                                                             ii.      From the UML editor, select the “Convert to > Ecore Model…” option.


  1. Programatically.


    1. The behavior for import/export is defined in UMLUtil:




Collection UMLUtil#convertFromEcore(EPackage ePackage, Map options)



UMLUtil#convertToEcore(org.eclipse.uml2.Package package_,Map options)




Model Artifact Migration


The latest UML2 API provides a means to automatically migrate existing models saved with the UML2 1.x schema.    Simply right click (or double click) on your existing model (with .uml2 extension) and select… “Open With > UML Model Editor”




·        An in-memory model will be created with the correct UML2 2.0 schema. 

·        In addition, all applied profiles will automatically be migrated. 

·        For those features where no mappings are appropriate, a UML2 profile will be applied to the model and the appropriate stereotype will be applied that preserves the data that might otherwise be lost.   In this way, all features are mapped and no information is lost.


If you look at the file name in the editor tab you will also notice that the extension has already been changed to .uml.  In order to persist the model with the new schema, you will have to save it.  

Select the “File > Save As …” menu option.




Congratulations! Your model has now been migrated and serialized with the latest XMI version.  (Yes, it’s that simple.)


Profile Artifact Migration


The structure of the profile definition has changed.


·        The version of the profile used to be explicitly serialized.


·        Now, the namespace URI of the profile is used as the identifier.


·        The namespace URI is computed on creation.


·        By convention, version identifier is now part of the namespace URI (schema version is kept in namespace URI).  The benefit is that if the version changes, the namespace URI changes.


It is possible to stereotype a profile as an EPackage.


·        User can then explicitly set the NS_URI which overrides the auto-generation mechanism.


In terms of how profiles are serialized to XML:


·        Stereotype applications are now stored at the resource level instead of as annotations on the elements themselves.


·        Any code that copies models must now explicitly copy the stereotypes separately since they are no longer held as an annotation under the element.


Profile versioning:


·        The current UML API implements a versioning format that conforms to the latest UML specification and uses existing nsURI naming conventions.


·        In the old schema, version information was stored as a prefix and in the nsURI.  This was somewhat redundant.


        <contents xmi:type="ecore:EPackage" xmi:id="_6hd4tLRJEdqcc7lEDGpkMw" name="ProfileOne_0" nsURI="http:///ProfileOne_0_6hd4s7RJEdqcc7lEDGpkMw.profile.uml2" nsPrefix="ProfileOne_0">


·        In the new schema, version information is stored explicitly in the nsURI


       <contents xmi:type="ecore:EPackage" xmi:id="_wRtnIOwjEdqsq-xx51kbkg" name="ProfileOne" nsURI="http:///schemas/ProfileOne/1" nsPrefix="ProfileOne">



There are 3 predominant workflows when working with profiles.  


Users can simply migrate the profiles on their own, but profiles don’t exist in a vacuum.  Profiles are applied to models.  It is therefore expected that you will want to migrate the models on which the profile is applied at the same time as the profile is migrated.  The various usecases are outlined below.


Migration of Profiles


Migration of the profile itself is the simplest scenario.


  1. Open your existing profile either by double clicking in the package explorer or by right clicking and selecting the “Open With > UML Model Editor”
    1. An in-memory version converted to the new schema will now exist.


  1. Select the profile in the UML editor.


  1. Select “UML Editor > Profile > Define”



  1. Save your profile.


(Congratulations! You have just migrated your profile.)


Migration of Models with Predefined Profiles


Models might have had one or more of the predefined profiles applied to them (Basic.profile.uml2, Intermediate.profile.uml2 or Complete.profile.uml2). Now, we have one standard profile called Standard.profile.uml.


The older .uml2 version of a model with these profiles applied look like the following:


<?xml version="1.0" encoding="UTF-8"?>

<uml:Model xmi:version="2.0" xmlns:xmi="" xmlns:xsi="" xmlns:Basic_0="http:///Basic_0.profile.uml2" xmlns:uml="" xsi:schemaLocation="http:///Basic_0.profile.uml2 pathmap://UML2_PROFILES/Basic.profile.uml2#__LeIQK86Edih9-GG5afQ0g" xmi:id="_y8utoOv8Edqsq-xx51kbkg" appliedProfile="_DKmYgOv_Edqsq-xx51kbkg _dmLfcOv_Edqsq-xx51kbkg">

  <packageImport xmi:type="uml:ProfileApplication" xmi:id="_DKmYgOv_Edqsq-xx51kbkg">

    <eAnnotations xmi:id="_DKmYgev_Edqsq-xx51kbkg" source="attributes">

      <details xmi:id="_DKmYguv_Edqsq-xx51kbkg" key="version" value="0"/>


    <importedPackage href="pathmap://UML2_PROFILES/Complete.profile.uml2#_M7pTkK87Edih9-GG5afQ0g"/>

    <importedProfile href="pathmap://UML2_PROFILES/Complete.profile.uml2#_M7pTkK87Edih9-GG5afQ0g"/>


  <packageImport xmi:type="uml:ProfileApplication" xmi:id="_dmLfcOv_Edqsq-xx51kbkg">

    <eAnnotations xmi:id="_dmLfcev_Edqsq-xx51kbkg" source="attributes">

      <details xmi:id="_dmLfcuv_Edqsq-xx51kbkg" key="version" value="0"/>


    <importedPackage href="pathmap://UML2_PROFILES/Basic.profile.uml2#_6mFRgK86Edih9-GG5afQ0g"/>

    <importedProfile href="pathmap://UML2_PROFILES/Basic.profile.uml2#_6mFRgK86Edih9-GG5afQ0g"/>


  <ownedMember xmi:type="uml:Artifact" xmi:id="_md9YcOv_Edqsq-xx51kbkg" name="artifact">

    <eAnnotations xmi:id="_o4MmQOv_Edqsq-xx51kbkg" source="appliedStereotypes">

      <contents xmi:type="Basic_0:Basic__Script" xmi:id="_o4MmQev_Edqsq-xx51kbkg"/>





If such a model is opened with the UML editor, the profile applications within will automatically get migrated and applied. Saving out the above mentioned model will result in the following.


<?xml version="1.0" encoding="UTF-8"?>

<xmi:XMI xmi:version="2.1" xmlns:xmi="" xmlns:xsi="" xmlns:Standard="" xmlns:ecore="" xmlns:uml="" xsi:schemaLocation=" pathmap://UML_PROFILES/Standard.profile.uml#_yzU58YinEdqtvbnfB2L_5w">

  <uml:Model xmi:id="_y8utoOv8Edqsq-xx51kbkg">

    <packagedElement xmi:type="uml:Artifact" xmi:id="_md9YcOv_Edqsq-xx51kbkg" name="artifact"/>

    <profileApplication xmi:type="uml:ProfileApplication" xmi:id="_3vnrsOw6Edqsq-xx51kbkg">

      <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_3vnrsew6Edqsq-xx51kbkg" source="">

        <references xmi:type="ecore:EPackage" href="pathmap://UML_PROFILES/Standard.profile.uml#_yzU58YinEdqtvbnfB2L_5w"/>


      <appliedProfile xmi:type="uml:Profile" href="pathmap://UML_PROFILES/Standard.profile.uml#_0"/>



  <Standard:Script xmi:id="_3vnrsuw6Edqsq-xx51kbkg" base_Artifact="_md9YcOv_Edqsq-xx51kbkg"/>




There are only two steps remaining…


  1. Re-apply to standard profile and any other pre-defined profile that has been applied.


a.       Select your model from the UML editor, then select   “UML Editor > Package > Apply Profile”.



  1. Delete the extra profile applications that are no longer required from your existing model that might have been left as a result of multiple predefined models (i.e. the Basic.profile.uml2, Intermediate.profile.uml2 and Complete.profile.uml2) being converted to Standard.profile.uml.


Migration of Models with User-defined Profiles


To migrate a model with user-defined profile properly, it is necessary to re-define and re-apply profiles. An example model with migration steps is outlined below.


Before migration (older .uml2 version)


<?xml version="1.0" encoding="UTF-8"?>

<uml:Model xmi:version="2.0" xmlns:xmi="" xmlns:xsi="" xmlns:ProfileOne_0="http:///ProfileOne_0_6hd4s7RJEdqcc7lEDGpkMw.profile.uml2" xmlns:uml="" xsi:schemaLocation="http:///ProfileOne_0_6hd4s7RJEdqcc7lEDGpkMw.profile.uml2 MyProfile.uml2#_6hd4tLRJEdqcc7lEDGpkMw" xmi:id="_HF4i4LRHEdqcc7lEDGpkMw" appliedProfile="_EMDHoLRKEdqcc7lEDGpkMw">

  <packageImport xmi:type="uml:ProfileApplication" xmi:id="_EMDHoLRKEdqcc7lEDGpkMw">

    <eAnnotations xmi:id="_EMDHobRKEdqcc7lEDGpkMw" source="attributes">

      <details xmi:id="_EMDHorRKEdqcc7lEDGpkMw" key="version" value="0"/>


    <importedPackage xmi:type="uml:Profile" href="MyProfile.uml2#_NLpAMLRHEdqcc7lEDGpkMw"/>

    <importedProfile href="MyProfile.uml2#_NLpAMLRHEdqcc7lEDGpkMw"/>


  <ownedMember xmi:type="uml:Class" xmi:id="_H44GELRHEdqcc7lEDGpkMw" name="MyClass">

    <eAnnotations xmi:id="_HyseMLRKEdqcc7lEDGpkMw" source="appliedStereotypes">

      <contents xmi:type="ProfileOne_0:ProfileOne__StereotypeOne" xmi:id="_HyseMbRKEdqcc7lEDGpkMw" MyProperty="4"/>


    <ownedAttribute xmi:id="_b9cgQLRKEdqcc7lEDGpkMw" name="PropertyOne"/>


  <ownedMember xmi:type="uml:Actor" xmi:id="_ERmhcLqqEdqSyLEgG4orvQ" name="Actor">

    <eAnnotations xmi:id="_ICL3ILqqEdqSyLEgG4orvQ" source="keywords" value="blah"/>




After migration (newer .uml version)


<?xml version="1.0" encoding="UTF-8"?>

<xmi:XMI xmi:version="2.1" xmlns:xmi="" xmlns:xsi="" xmlns:ProfileOne="http:///schemas/ProfileOne/1" xmlns:ecore="" xmlns:uml="" xsi:schemaLocation="http:///schemas/ProfileOne/1 MyProfile.uml#_wRtnIOwjEdqsq-xx51kbkg">

  <uml:Model xmi:id="_HF4i4LRHEdqcc7lEDGpkMw">

    <packagedElement xmi:type="uml:Class" xmi:id="_H44GELRHEdqcc7lEDGpkMw" name="MyClass">

      <ownedAttribute xmi:type="uml:Property" xmi:id="_b9cgQLRKEdqcc7lEDGpkMw" name="PropertyOne"/>


    <packagedElement xmi:type="uml:Actor" xmi:id="_ERmhcLqqEdqSyLEgG4orvQ" name="Actor">

      <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_ICL3ILqqEdqSyLEgG4orvQ" source="" value="blah"/>


    <profileApplication xmi:type="uml:ProfileApplication" xmi:id="_EMDHoLRKEdqcc7lEDGpkMw">

      <eAnnotations xmi:type="ecore:EAnnotation" xmi:id="_EMDHobRKEdqcc7lEDGpkMw" source="">

        <references xmi:type="ecore:EPackage" href="MyProfile.uml#_wRtnIOwjEdqsq-xx51kbkg"/>


      <appliedProfile xmi:type="uml:Profile" href="MyProfile.uml#_NLpAMLRHEdqcc7lEDGpkMw"/>



  <ProfileOne:StereotypeOne xmi:id="_AjMRkOwkEdqsq-xx51kbkg" MyProperty="4" base_Class="_H44GELRHEdqcc7lEDGpkMw"/>




To migrate older models with older profiles defined.


  1. Open up your older model with the UMLEditor.


    1. Follow rules for “Model Artifact Migration”.

                                                               i.      An in memory version of your model will be created

                                                             ii.      An in-memory version of your profile will be created.

                                                            iii.      If at this stage you decide to save your model to the new schema by saving out with a .uml extension, the model will still refer to the older profile (most likely not what you want)




  1. Redefine the existing profile.


    1. Select the applied user defined profile in the editor





    1. Select “UMLEditor > Profile > Define





  1. Re-apply the newly migrated profile.


    1. Select the model in the editor





    1. Select “UMLEditor > Package > Apply Profile …”





    1. Select the profile in question and click “Add” then “OK”





  1. Save your resource


    1. Simply click “Save”.


At this stage, you will notice a new version of your model and profile have been created.


(Congratulations! You have just migrated a model with a user-defined profile applied.)



 Programmatic Migration


In order to migrate models programmatically, some setup is required in order to register mappings (already defined by UML).  These mappings will be used by the resource set during the loading stage and will perform the necessary in-memory migration.


The example below demonstrates how one can migrate models with a stand-alone application.


Let’s first start with our main method.




      public static void main(String[] args) {

            if (args.length != 3) {


                        .println("Wrong number of arguments.\nFirst argument is path "

                              + "of file to migrate ie. C:/myModel.uml2 \nSecond "

                              + "argument is path to uml plugin "

                              + "ie. C:/cleanUML/uml2-M200607270400/eclipse/plugins/org.eclipse.uml2.uml_2.0.1.v200607270400.jar"

                              + "\nThird argument is path to uml resource jar "

                              + "ie. C:/cleanUML/uml2-M200607270400/eclipse/plugins/org.eclipse.uml2.uml.resources_2.0.0.v200607270400.jar");




            String fileToMigrate = args[0];

            String umlPluginPath = args[1];

            String umlResourcePath = args[2];


            URI umlPluginURI = URI.createURI("jar:file:/" + umlPluginPath + "!/");

            URI umlResourcePluginURI = URI.createURI("jar:file:/" + umlResourcePath

                  + "!/");

            migrateModel(URI.createFileURI(fileToMigrate), umlPluginURI,



Nothing very exciting here.  We simply pass the file to migrate as the first parameter, the path of the uml jar as the second and the path of the resource jar as the third. We’ll see how these are used later on.

For stand-alone applications, it is required to register pathmaps, extensions and packages. 




      protected static void registerPathmaps(URI umlResourcePluginURI) {











In the function above, we register the locations to the various pathmaps.  Here, we make use of the resource URI  passed in as a parameter to the main() function.



      protected static void registerExtensions() {

            Map extensionFactoryMap = Resource.Factory.Registry.INSTANCE






      *   extensionFactoryMap.put(UML22UMLResource.FILE_EXTENSION,




In the function above, we register the  .ecore2xml and  .uml2 extensions used by the resource set for conversion purposes.


            protected static void registerPackages(ResourceSet resourceSet) {

            Map packageRegistry = resourceSet.getPackageRegistry();

            packageRegistry.put(EcorePackage.eNS_URI, EcorePackage.eINSTANCE);



            packageRegistry.put(UMLPackage.eNS_URI, UMLPackage.eINSTANCE);


Stand alone applications require registration of Packages.  Eclipse based plugins are not required to register packages since packages are registered via an extension.





Now we get to the interesting part. 


      public static void migrateModel(URI resourceURI, URI umlPluginURI,

                  URI umlResourcePluginURI) {

            System.out.println("Migrating file " + resourceURI.toFileString());


            ResourceSet resourceSet = new ResourceSetImpl();






            // Map references to legacy (1.x) model elements to their new locations.

            Map uriMap = UML22UMLExtendedMetaData.getURIMap();



            // For a stand alone application, it is necessary to map the platform

            // plugin URI scheme to the workspace location.


                  .createURI("platform:/plugin/org.eclipse.uml2.uml/"), umlPluginURI);


            // Load a resource in the resource set.

            try {

      *         resourceSet.getResource(resourceURI, true);

            } catch (Exception e) {





            // Replace the .uml2 extension with .uml if necessary.

            Map resourceToURIMap = new HashMap();

            EList resources = resourceSet.getResources();


         for (int i = 0; i < resources.size(); i++) {

                  Resource resource = (Resource) resources.get(i);

                  URI uri = resource.getURI();

                  if (UML22UMLResource.FILE_EXTENSION.equals(uri.fileExtension())) {

                        uri = uri.trimFileExtension().appendFileExtension(


                        // resolveAll() will cause any referenced models to be loaded

                        // and migrated.



                  resourceToURIMap.put(resource, uri);


            // Update all the resources with updated extension at this point,

            // references to these newly named resource items will get updated

            for (Iterator entries = resourceToURIMap.entrySet().iterator(); entries

                  .hasNext();) {

                  Map.Entry entry = (Map.Entry);

                  Resource saveResource = (Resource) entry.getKey();

                  saveResource.setURI((URI) entry.getValue());


            // Save all resources.  We must save all resource after renaming

            // them so that references to newly named resource are correctly saved.

            for (int j = 0; j < resources.size(); j++) {

                  Resource saveResource = (Resource) resources.get(j);

                  String saveScheme = saveResource.getURI().scheme();

                  if (!URI.isArchiveScheme(saveScheme)

                        && !saveScheme.equals("pathmap")) {

                        try {


                              System.out.println("Saving migrated resource: "

                                    + saveResource.getURI().toString());

                        } catch (IOException ioe) {






First, we register all required pathmaps, packages and extensions  required for a stand-alone applications.  Next, we simply call upon the resource set  to open the file.  The previously registered mappings will be used when opening the resource.   After the call to getResource() the code is migrated in memory.  The only thing left to do before saving back out to disk is to  change the extension from .uml2 to .uml.  And finally  save to disk.



API Migration


Arguably, the most difficult part of the migration process will be migration of the code base.  To scope out the amount of work required for such a migration, a table of some common tasks has been provided. 


Keep the following points in mind as you try to gauge the scope of API migration:




Namespace changed from org.eclipse.uml2 to org.eclipse.uml2.uml



Custom operations specified in Metadata – the practical result is that Sets in the API have been replaced with Lists



Different handling of derived properties and sub-collections

The compiler won’t break on index based iteration but failure to fix them would result in poor performance.


Three default profiles have been replaced with one standard profile

There have been some minor changes in the content of the profiles as well


Stereotype applications are now stored at the resource level instead of as annotations on the elements themselves



Required stereotypes are now actually automatically applied

Significant performance improvement


Specification defined support for stereotype owned images/icons



Navigability of association ends has been separated from ownership


Opaque Expression now supports multiple languages and bodies



OCL is considered now default language for Opaque Expressions


language does not have to be specified

Many OCL constraints have been changed



Number of metaclasses  and properties  have been renamed or removed



New metaclasses (18), properties (25) and operations (4).

Mostly in following areas:

·          Actions

·          Behaviors

·          Events


Multiplicity of some properties changed.



Stereotype attributes can now reference metaclasses



UMLUtil class has utility methods to perform Package Merge



EMF support for logical resources



UMLUtil class has improved utility methods for export/import to Ecore format



You will likely notice two classes of problems during the migration process:  those cases where there is a simple 1-1 mapping between an old concept and a new concept, and, those cases that require a rework of the logic in your code.

These more difficult mappings will require a deeper understanding of subject matter than this document can fully describe.   For partial explanations refer to the section entitled Superstructure Specification Changes or refer to the actual Superstructure specification for a more complete explanation.

Convenience methods regarding manipulation of profiles:

·        To ensure the latest version of the profile is applied, there are newly introduced convenience methods.   Simply call ProfileApplication#getAppliedDefinition() and compare the result to Profile#getDefinition()Profile#getDefinition() will always return the latest version.


The tables below provide the basis of API migration work.  They summarize the changes to the metamodel and give you an understanding of the kind of modifications required:






·          ActionExecutionSpecification

·          ActionInputPin

·          BehaviorExecutionSpecification

·          ConsiderIgnoreFragment

·          CreationEvent

·          DestructionEvent

·          SendOperationEvent

·          Event

·          ExecutionEvent

·          ExecutionOccurrenceSpecification

·          ExecutionSpecification

·          FunctionBehavior

·          Image

·          MessageOccurrenceSpecification

·          OpaqueAction

·          OpaqueBehavior

·          SequenceNode

·          UnmarshallAction

·          ValueSpecificationAction

·          MessageEvent

·          SendSignalEvent

·          CallEvent

·          ChangeEvent

·          SignalEvent

·          AnyReceiveEvent

·          LinkEndDestructionData

·          StartClassifierBehaviorAction

·          ComponentRealization

·          TimeEvent




·          ApplyFunctionAction

·          Permission

·          PrimitiveFunction

·          Stop

·          MessageTrigger

·          CallTrigger

·          ChageTrigger

·          SignalTrigger

·          AnyTrigger

·          TimeTrigger

·          ParameterableClassifier

·          TemplateableClassifier

·          RemoveVariableValueAction

·          StartOwnedBehaviorAction




·          CollaborationOccurrence ->      CollaborationUse  

·          EventOccurrence ->                    ExecutionOccurrenceSpecification

·          ExecutionOccurrence ->             ExecutionSpecification

·          Implementation ->                       InterfaceRealization 

·          InteractionOccurrence ->           InteractionUse 


·          StartOwnedBehaviorAction ->   StartClassifierBehaviorAction




               Made Abstract

·          Action

·          ExecutionOccurrence




              Made Concrete

·          Trigger









·          AcceptEventAction::isUnmarshall : Boolean = false

·          Activity::variable : Variable [0..*]

·          Association::navigableOwnedEnd : Property [0..*]

·          BehavioralFeature::ownedParameterSet : ParameterSet [0..*]

·          DestroyLinkAction::endData : LinkEndDesctructionData [2..*]

·          EventOccurrence::event : Event [1..1]

·          ExecutionOccurrence::action : Action [0..1]

·          InformationFlow::realizingActivityEdge : ActivityEdge [0..*]

·          InformationFlow::realizingConnector : Connector [0..*]

·          InformationFlow::realizingMessage : Message [0..*]

·          InformationFlow::source: NamedElement [1..*]

·          InformationFlow::target: NamedElement [1..*]

·          MessageEnd::message : Message [1..1]

·          ObjectNode::isControlType : Boolean = false

·          Operation::interface : Interface [0..1]

·          Pin::isControl : Boolean

·          RemoveStructuralFeatureValueAction::isRemoveDuplicates : Boolean

·          RemoveStructuralFeatureValueAction::removeAt : InputPin [0..1]

·          RemoveVariableValueAction::isRemoveDuplicates : Boolean

·          RemoveVariableValueAction::removeAt : InputPin [0..1]

·          State::connectionPoint : Pseudostate [0..*]

·          Stereotype::icon : Image [0..*]

·          Trigger::event : Event [1..1]

·          Variable::activityScope : Activity [0..1]

·          ExtensionPoint::useCase : UseCase[1]

·          RemoveVariableValueAction::isRemoveDuplicates:Boolean

·          RemoveVariableValueAction::removeAt: InputPin




·          Behavior::formalParameter

·          Behavior::parameter

·          Behavior::returnResult

·          BehavioralFeature::parameter

·          BehavioralFeature::returnResult

·          BehavioredClassifier::ownedStateMachine

·          EventOccurrence::finishExec

·          EventOccurrence::startExec

·          MessageEnd::sendMessage

·          MessageEnd::receiveMessage

·          Package::packageExtension

·          StructuralFeature::isReadOnly

·          NamedElement::namespace

·          Comment::bodyExpression *




·          BehavioralFeature::formalParameter -> ownedParameter

·          BehavioredClassifier::implementation -> interfaceRealization

·          Classifier::occurrence -> collaborationUse

·          PackageMerge::mergingPackage -> receivingPackage



               Type Changed

·          ReplyAction::replyToCall : CallTrigger -> Trigger








                Made derived

·         Behavior::context


             Made navigable

·          ConnectionPointReference::state

·          Pseudostate::stateMachine



              Made ordered

·          ApplyFunctionAction::argument

·          Association::endType

·          CombinedFragment::operand

·          ConnectableElement::end

·          InteractionOccurrence::argument

·          Message::argument

·          StructuredClassifier::ownedAttribute

·          TemplateSignature::parameter

·          DataType::ownedAttribute

·          DataType::ownedOperation

·          OpaqueAction::body

·          OpaqueAction::language

·          LoopNode::result

·          LoopNode::loopVariable




                      Multiplicities changed












List  to Scalar












Scalar to List

·          AcceptCallAction::trigger : CallTrigger [0..*] -> 1..1

·          AcceptEventAction::trigger : Trigger [0..*] -> 1..*

·          ConnectorEnd::role : ConnectableElement [0..1] -> 1..1

·          Lifeline::represents : ConnectableElement [1..1] -> 0..1

·          Variable::scope : StructuredActivityNode [1..1] -> 0..1

·          ConnectionPointReference::entry : Elist[1..*]-> *

·          ConnectionPointReference::exit : Elist[1..*]->*

·          InstanceSpecification::specification : ValueSpecification::[0..1] ->1

·          BehaviorExecutionSpecification::behavior : Behavior [1] -> 0..1

·          Message::message[1]->[0..1]

·          ConnectionPointReference::entry : Pseudostate[1..*]->[*]

·          ConnectionPointReference::exit : Pseudostate[1..*]->[*]



·          DurationObservationAction::duration[*] ->[1] 

·          ExecutionOccurrence::behavior : Behavior[0..*] à BehaviorExecutionSpecification::behavior[0..1]

·          Interval::min: ValueSpecification[0..*] -> [1]

·          Interval::max: ValueSpecification[0..*]->[1]

·          TimeObservationAction::now[*] ->[1]

·          EventOccurrence::startExec[*] -> ExecutionSpecification::start: ExecutionOccurrence[1]

·          EventOccurrence::finishExec[*] -> ExecutionSpecification::finish:ExecutionOccurrence[1]


·          Activity::body : String[1] -> OpaqueBehavior::body:String[1..*]

·          OpaqueExpression::body : String [0..1] -> 1..*

·          OpaqueExpression::language : String [0..1] -> 0..*








Default Values:


·          CallAction.isSynchronous = true









·          Property::isNavigable() : Boolean

·          Region::containingStateMachine() : StateMachine

·          Transition::containingStateMachine() : StateMachine

·          Vertex::containingStateMachine() : StateMachine








·          InteractionOperator -> InteractionOperatorKind




·          MessageSort::synchSignal








·          ChangeTrigger :: Event

·          MessageTrigger :: Event

·          TimeTrigger :: Event

·          StringExpression :: Expression

·          ValueSpecification :: PackageableElement





Q. What does MultiplicityElement.UNLIMITED_UPPER_BOUND map to?

A.  LiteralUnlimitedNatureal.UNLIMITED.


Q. What does Activity::body map to?

A.  Create an OpaqueBehavior::body. Both OpaqueBehavior and Activity now are specializations of Behavior.


Q. What is the difference between getUpperBound() and getUpper() and getUpperValue() on a pin?

A. getUpperBound() on a pin is a convenience method that deals with tokens.  The getUpper() and getUpperValue() is part of MultiplicityElement.


Q. Empty string tests are no longer working for some UML items.

A. By default, strings are initialized to NULL and not empty string in UML2 2.0.


Q. What do I do if I have more questions?

A. Post a message to the Modeling / MDT / UML2 newsgroup at The turnaround time for questions posted on the newsgroup is usually less than 24 hours.