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
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.
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: 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
Free Shapes
Free Shapes are not transformed from Cameo to Rhapsody.
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:
Due to this difference, the Publisher implements the following rules:
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:
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: