UML Migration Guide

Tom Morris
January, 2006

• Introduction
• UML 1.4 Changes
• UML 2.0 Migration Planning

Introduction

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.

CLASS DIAGRAM

• 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.

SEQUENCE DIAGRAM

• 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.

STATE DIAGRAM

• 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

ACTIVITY DIAGRAM

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