General Modeling Guidelines

The following rules apply in all cases for all types of diagrams.

Activity

In Magicdraw, an Activity can own another Activity. This pattern is not allowed in Rhapsody. In such cases, a Package named "containment<pathToActivity><ActivityName>" is created and will own the Activity. To remember the original containment, a Dependency is created between both Activities.

Association

• Inversed Relation of a Part is necessarily Navigable in Rhapsody. This is not the case in Cameo.
• For some Stereotypes, Rhapsody forces the creation of a Part, while there is no composition in Cameo. This is the case for <<RessourceRole>>, for example.
• In Rhapsody, it is not possible to create an Association to a Type, a Dependency is created instead.

Colors

Colors are not transformed from Cameo to Rhapsody.
This will be an option in future versions.

Comment/Documentation

The documentation of an Element in Cameo is transformed to the description of the same Element in Rhapsody - except for a Diagram, for which it is not transformed.
The documentation of the Root Model in Cameo is transformed to an owned Comment for the corresponding Package in Rhapsody.
An owned Comment in Cameo is transformed to an owned Comment in Rhapsody - except for a Diagram, for which it is not transformed.

Common Shapes

Common Shapes supported from Cameo to Rhapsody:

• Horizontal and vertical separator
• Images from File
• Images from Attached File
• Rectangular Shape. It is not possible to transform the text added to the Rectangular Shape in Rhapsody. In order not to lose the text, the publisher creates in addition to the Rectangle in Rhapsody, a text box. Cameo also allows you to edit text boxes in html format. This is not possible with Rhapsody. The html format is lost during the transformation.

Known limitations: Cameo allows creating an Anchor from/to a Common Shape, which is not possible in Rhapsody.

Containment Links

IBM Rhapsody does not create Containment Link between Package and Files.

Containment/Structure

The Publisher keeps, as much is possible containment and hierarchy between Elements during transformation.
Indeed, Rhapsody can be more restrictive regarding containments and hierarchy. For example, in Rhapsody, Profiles are all grouped together in the Profiles view.
In addition, Several Rhapsody classifiers are not able to contain other classifiers, as Activity, Statechart or Usecase containing a class. In such situation, those unmanaged classifiers are moved in another container:

• Elements are moved in a Package container (created in the nearest Package/Classifier of owner) named contentOf_XXX (where XXX is the name of the original owner)
• Dependencies from created Package container to the original elements container are created
• Bidirectional dependencies between those unmanaged classifiers and the original container are created

Furthermore, an additional hierarchical level is created in Rhapsody. It corresponds to the model in Cameo.

Consistent Identification

The Publisher maintains consistent identifiers through publish event.
The user can compare two publishes of the same model and identify the differences in Rhapsody, but running Rhapsody diffMerge comparison.
However, there are several Elements where the order is not guaranteed on the interface when exported by the source tool.
The Publisher can not resolve those differences for these Elements.

Extended MagicDraw/Cameo Profile

MagicDraw/Cameo profiles are not published to Rhapsody.

Display Options

There are millions of possible ways the user can select to display elements on diagrams both in Rhapsody and Cameo.
Not all display options are controllable by the transformation.
We continue to improve the appearance of diagrams as versions.

Environment

License Manager requires a Windows operating system. Other operating systems are not supported. This is due to the FlexNet licensing schema.

Only one version and instance of the source tool should be installed and running on the publishing machine. This ensure no conflict on the interface.

Notes on Performance

• It is important to only run a single publish at a time to a single open Rhapsody project.
• If the cancel is selected in the middle of a publish, ensure the cancel request is completed before starting a new Publisher.
• For memory allocation adjustments please refer to the troubleshooting or FAQ sections of the Administration Guide.

Optional Stereotypes on Parameters

In UML/Cameo, <<Optional>> is a Stereotype that applies on Parameters.
While in Rhapsody, <<optional>> is a Stereotype that can be applied on Pins. There are two major kinds of Pins in Rhapsody:

• Pins attached to an action, that reflect parameters and returned value that may be produced by action behavior, (from an Operation, an called Activity, or any parameterized Element).
• ActivityParameterNode, that represents Parameters of the Activity itself.

Due to this difference, the Publisher implements the following rules:

• In case of an <<Optional>> Parameter in Cameo, the Parameter that will be produced in Rhapsody will not be stereotyped <<optional>>.
• The CallOperation's Pin will be stereotyped <<optional>>.

Ports

It is not possible to transform Standard Ports typed with Primitive Type from Cameo to Rhapsody. The Type of Standard Ports using Primitive Type is lost after the publication.

Proxy Element - Non Resolved Element

Non resolved Elements (Proxies) are converted to Comments in Diagrams.
Relationships from/to Non resolved Elements are lost.

Relationships

In Rhapsody, it is sometimes impossible to display relationships as they are in Cameo, because they are related to an "internal" element of one of the two boxes in relation.
For example, it is not possible to display the <<Desired Effects>> as they are in Cameo. In Cameo, a <<Desired Effect>> connects a <<Capability>> and an <<Operational State>>. This is not possible in Rhapsody.

Round Tripping

The Publisher off-the-shelf supports the round tripping transformation/publish but is not designed to update/synchronize a project.
By the way, Round-tripping is a difficult case to support as there are multiple interpretations of capability for SysML/UML between the tools.
Also, what is provided on the API is not the same or complete between the tools.
Moreover, customer style and preference are hard to capture consistently with a common standard mapping.
There are detailed modeling guidelines in the User guide because of the differences.

State

In Magicdraw, a State can own another Activity. This pattern is not allowed in Rhapsody. In such cases, the Activity is moved to the nearest owner that can contain an Activity. To remember the original containment, a Dependency is created between the State and the Activity.

Stereotypes

In the general case, Stereotypes are published without side effects.
Stereotypes defined in Rhapsody Profiles are called "New term". These Stereotypes only apply to one Metaclass. In Magicdraw, Stereotypes often apply to several Metaclasses, especially those that extend standard Profile Stereotypes. When publishing from MagicDraw, extending the Stereotypes of standard Rhapsody Profiles is no longer possible. To preserve inheritance information, a derivation is created between the two Stereotypes.

Stereotypes on Diagram

Stereotype on Diagram, and so TaggedValues on Diagram, are lost during import in Rhapsody.

Tables/Matrices

The Publisher does not publish tables or matrices. The source and target tools provide capabilities to export and import tables and matrices.

Transition

In Magicdraw, a Transition can own an Activity. This pattern is not allowed in Rhapsody. In such cases, the Activity is moved to the nearest owner that can contain an Activity. To remember the original containment, a Dependency is created between the Transition and the Activity.

SysML General Modeling Guidelines

SysML Ports

Due to Rhapsody API restrictions, it is not possible to draw Port and SysML Port like Property.
Property is displayed as Port. This is particularly visible in SysML Parametric Diagrams.

Requirements

Due to Rhapsody API restrictions, it is not possible for a Diagram to be contained by a Requirement.
Diagrams are moved to the nearest owner Package and HyperLinks targeting the moved Diagrams are created on their original owners.

Because extended MagicDraw/Cameo Profiles are not transformed, extended Requirement (like <<functionalRequirement>>) are stereotyped <<Requirement>>. However, 'Extended' TaggedValues are lost.

MagicDraw Custom Profile

MagicDraw provides some Stereotypes which does not exist in Rhapsody or extends Standard Profile like UML, SysML, UPDM...
To avoid data loss, a profile called “MDCustomProfile” will be created in Rhapsody. This Profile will contain all the MagicDraw customizations.
The tree structure of each Profile will be kept. For example:

UAF Profile

The Profile UAF is currently not supported by Rhapsody. However, when possible, UAF Stereotypes will be mapped to their UPDM equivalent.
When no equivalent is found, a Stereotype is created in the MDCustomProfile Profile, in order to preserve applied Stereotypes and associated tagged values.

UPDM General Modeling Guidelines

Diagram

Some diagram types are not recovered from Cameo to Rhapsody. Local stereotypes are created in that case.
Here is the list of local stereotypes created:

• AV-2 Data Dictionay Table
• OV-3 Operational Resource Flow Matrix
• OV-6a Operational Rules Model
• SvcV-10a Services Rules Model
• SvcV-3a Systems-Services Matrix
• SvcV-6 Services Resource Flow Matrix
• SvcV-7 Services Measures Matrix
• StdV-2 Standards Forecast
• SV-10a Systems Rules Model
• SvcV-3a Systems-Services Matrix
• SV-5b Operational Activity to Systems Traceability Matrix
• SV-6 Systems Resource Flow Matrix
• SV-7 Systems Measures Matrix
• SV-9 Systems Technology and Skills Forecast

Flows

Due to Rhapsody API restrictions, it is not possible to visualize the flows on Elements realizing them.
Semantic information is present in the model through Tagged Values:

• An <<Operational Activity Edge>> carriedItem <<Exchange Element>>
• A <<Function Edge>> carriedItem <<Exchange Element>>
• An <<Operational Message>> carries <<Operational Exchange>>
• A <<Resource Message>> carries <<Resource Interaction>>
• A <<Resource Interaction>> realizingMessage <<Operational Message>>
• A <<Resource Interaction>> realizingMessage <<Resource Message>>
• A <<Resource Interaction>> realizingConnector <<Resource Connector>>
• A <<Resource Interaction>> realizingActivityEdge <<Function Edge>>
• A <<Resource Interaction>> realizingActivityEdge <<Operational Activity Edge>>
• A <<Resource Interaction>> realization AssociationEnd