General Modeling Guidelines
The following rules apply in all cases for all types of diagrams.
- 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.
- Containment Links
- IBM Rhapsody does not create Containment Link between Package and Files.
- Containment/Structure
- The Publisher keeps containment and hierarchy between Elements during transformation.
However, 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.
- 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:
- 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 transformation/publish one 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.
Please let us know if round-tripping is a critical use-case to make your team successful.
- 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.
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.
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