Login | Register
My pages Projects Community openCollabNet

UML Migration Guide

Tom Morris
January, 2006


ArgoUML 0.20 is the first release to support UML 1.4. This document describes the changes caused by the move from UML 1.3 to UML 1.4 as well as some things that you may want to consider as you plan for the move to UML 2.0 in the future.

Important: The first time you open a UML 1.3 based project, or import a UML 1.3 XMI file, ArgoUML will automatically update it to UML 1.4. You should carefully verify that everything got converted correctly you should keep a backup of your UML 1.3 file in case you need it again. ArgoUML can no longer write UML 1.3 files, so this is a one way conversion process.

Changes from UML 1.3 to UML 1.4

The UML 1.4 specification is not completely upward compatible with the UML 1.3 specification, so some changes need to be made to UML 1.3 models when they are imported into a version of ArgoUML supporting UML 1.4. This conversion is done using XSLT with the stylesheet org/argouml/model/mdr/conversion/uml13touml14.xsl which can be found in the ArgoUML JAR or in the repository here . A summary done by the OMG of the changes between the two versions can be found at http://www.omg.org/docs/ad/01-02-11.pdf. The most comprehensive documentation of the changes is the changebarred version of the UML 1.4 specification available as document 01-09-67 on the OMG web site..
  • Visible changes to model
    • Metaclass State mapped to SimpleState (State was changed to abstract in UML 1.4)
    • Pseudostate.kind branch mapped to choice
    • Comment text is copied from Comment.name to Comment.body (which is new in UML 1.4)
      Note:Some modelling tools which support UML 1.4 still use the name attribute instead of the body attribute to store the text of the comment. The conversion process will not fix these (since no conversion gets run on UML 1.4 files).
  • New features in UML 1.4:
    • A Model Element may now have multiple Stereotypes.
    • A Stereotype may have multiple base classes.
    • Tagged Values have been significantly reworked. They now are defined by the new element TagDefinition and are of arbitrary type. (Only String values are currently supported by ArgoUML).
    • A new VisibilityKind 'package' is available.
    • There is now a type Enumeration which is a subtype of DataType and a related type EnumerationLiteral.
  • New features in UML 1.4 not yet implemented by ArgoUML:
    • The type ProgrammingLanguageDataType is another new subtype of DataType.
    • StructuralFeatures can have an ordering.
    • There is a new type TemplateArgument
    • There is a new type Artifact which is used on to represent physical representations of Components.
    • A new type SubsystemInstance, a subtype of Instance, has been added.
    • InteractionInstanceSet and CollaborationInstanceSet have been added for use in Collaborations.
    • The attribute isSpecification has been added to ElementImport.
  • Internal changes to XMI file:

    The following changes are internal to the project or exported XMI files should be transparent to most users, but you may find this information useful if you write your own tools that read or write XMI files.

    • UUIDs are no longer written to XMI files. If you were using them for stable identification of model elements, you'll need to use a different mechanism.
    • Stereotypes and tagged values are rewritten to conform to the UML 1.4 metamodel
    • Extension Points are copied to the Use Case from which they are referenced
    • In pre-0.20 versions of ArgoUML Use Case Includes had their Base and Addition swapped due to a bug in NSUML. They are swapped back to their correct orientation during the upgrade. Readers of ArgoUML XMI files which created workarounds to compensate for this problem may need to remove the workaround now that the problem is fixed.
    • The following items have been renamed:
      Old Name New Name
      ModelElement.supplierDependency ModelElement.clientDependency
      TaggedValue.value TaggedValue.dataValue
      TaggedValue.tag TaggedValue.type
      ModelElement.templateParameter2 ModelElement.parameterTemplate
      ModelElement.templateParameter3 ModelElement.defaultedParameter
      Classifier.structuralFeature Classifier.typedFeature
      Classifier.parameter Classifier.typedParameter
      Classifier.associationEnd Classifier.association
      Classifier.participant Classifier.specifiedEnd
      AssociationEnd.type AssociationEnd.participant
      Node.resident Node.deployedComponent
      ElementResidence.implementationLocation ElementResidence.container
      TemplateParameter.modelElement TemplateParameter.template
      TemplateParameter.modelElement2 TemplateParameter.parameter
      Constraint.constrainedElement2 Constraint.constrainedStereotype
      UseCase.include2 UseCase.include
      StateMachine.subMachineState StateMachine.submachineState
      ElementImport.modelElement ElementImport.importedElement
    • The following items are removed from XMI files:
      • Foundation.Core.ModelElement.elementResidence
      • Foundation.Core.ModelElement.presentation
      • Foundation.Core.ModelElement.supplierDependency
      • Foundation.Core.ModelElement.templateParameter2
      • Foundation.Core.ModelElement.templateParameter3
      • Foundation.Core.ModelElement.binding
      • Foundation.Core.GeneralizableElement.specialization
      • Foundation.Core.Classifier.participant
      • Foundation.Core.Operation.method
      • Foundation.Extension_Mechanisms.Stereotype.extendedElement
      • Foundation.Extension_Mechanisms.Stereotype.requiredTag
      • Foundation.Extension_Mechanisms.TaggedValue.stereotype
      • Behavioral_Elements.Common_Behavior.Signal.context
      • Behavioral_Elements.Common_Behavior.Signal.reception
      • Behavioral_Elements.Common_Behavior.Signal.sendAction
      • Behavioral_Elements.Use_Cases.UseCase.include2
      • Behavioral_Elements.Use_Cases.UseCase.extend2
      • Behavioral_Elements.Use_Cases.ExtensionPoint.extend
      • Behavioral_Elements.Common_Behavior.Link.stimulus
      • Behavioral_Elements.Common_Behavior.Instance.attributeLink
      • Behavioral_Elements.Common_Behavior.Action.stimulus
      • Behavioral_Elements.State_Machines.Event.state
      • Behavioral_Elements.State_Machines.Event.transition
      • Behavioral_Elements.State_Machines.Transition.state
      • Behavioral_Elements.Collaborations.ClassifierRole.message1
      • Behavioral_Elements.Collaborations.ClassifierRole.message2
      • Behavioral_Elements.Collaborations.Message.message3
      • Behavioral_Elements.Collaborations.Message.message4
      • Behavioral_Elements.Common_Behavior.Action.state1
      • Behavioral_Elements.Common_Behavior.Action.state2
      • Behavioral_Elements.Common_Behavior.Action.state3
      • Behavioral_Elements.Common_Behavior.Instance.stimulus1
      • Behavioral_Elements.Common_Behavior.Instance.stimulus2
      • Behavioral_Elements.Common_Behavior.Instance.stimulus3

Planning for UML 1.4 to UML 2.0 Migration

As you upgrade your models from UML 1.3 to UML 1.4, it's a good time to think about the future and consider the changes which will be needed for UML 2.0 which is expected to complete the standardization process during 2006. It will be some time before it's supported by ArgoUML, but it's better to plan ahead and not model things in a way which will be incompatible with UML 2.0.

The following list of changes is derived in part from the MagicDraw Migration to UML 2.0 Manual. More detail may be found there.


  • A Dependency can only be connected between NamedElements in UML 2.0 rather than any ModelElement as in UML 1.4.

    Metatypes which were subtypes of ModelElement, but are not subtypes of NamedElements include Generalization, PackageMerge and ElementImport. These should be avoided when drawing dependencies which you want to migrate to UML 2.0.

  • The metatype Subsystem has been removed from UML 2.0. Use a Component with the stereotype <<subsystem>> instead.
  • All tags must be owned by a Stereotype in UML 2.0. This is optional in UML 1.4, but for best compatibility with UML 2.0, make sure all tags are modeled with an owning stereotype. Elements which have the tag should also have the stereotype applied. (Clarify this)
  • All Stereotypes must be contained in a Profile in UML 2.0. You can emulate this now by grouping all your Stereotype definitions together in package with the «profile» to make them easy to convert when you move to UML 2.0.
  • The following stereotypes were eliminated from the Standard UML Profile in UML 2.0 and should be avoided for best compatibility even though they are available in the UML 1.4 profile:
    Deleted Stereotype Base Element
    «access» Permission
    «appliedProfile» Package
    «association» AssociationEnd
    «copy» Flow
    «create» CallEvent
    «create» Usage
    «destroy» CallEvent
    «facade» Package
    «friend» Permission
    «invariant» Constraint
    «local» AssociationEnd
    «parameter» AssociationEnd
    «postcondition» Constraint
    «powertype» Class
    «precondition» Constraint
    «profile» Package
    «realize» Abstraction
    «requirement» Comment
    «self» AssociationEnd
    «signalflow» ObjectFlowState
    «stateInvariant» Constraint
    «stub» Package
    «table» Artifact
    «thread» Classifier
    «topLevel» Package
  • Other elements of the Standard UML Profile are to be described.


  • UML 2.0 provides new notation for concurrency and branching using combined fragments. There's not much that can be done to prepare for this, but being aware of the impending change may influence how much you try to model using these features.


  • StubState and SynchState have been removed from the UML 2.0 specification. Avoid using them in UML 1.4 so you don't have to rework your models for UML 2.0
  • Event can no longer have parameters in UML 2.0. Avoid using these so they aren't lost in the migration to UML 2.0. As alternatives, NoMagic is recommending to its users to:
    • Use parameters of Operation when using CallOperationEvent.
    • Add additional parameters to operation if you are using more CallOperationEvent parameters than Operation has.
    • Add additional parameters to operation if you are using more CallOperationEvent parameters than Operation has.
    • Assign stereotypes and tags to Operation parameters instead of CallEvent parameters.
    • Apply corresponding rules to parameters of SendSignalEvent and attributes of Signal


  • In UML 2.0, Components cannot be deployed in Nodes. Artifacts related with these components should be deployed instead.