General Modeling Guidelines
The following rules apply in all cases for all types of diagrams.
- Action Blocks
- Due to differences in the tools, the Publisher transforms an Action Block to a Note with a link to Opaque Action represented by Action Block.
- Activity and Activity Diagram
- In Rhapsody, an Activity must have an associated Activity Diagram, which is not mandatory for MagicDraw.
During the publication, an empty Activity Diagram will be created for Activities that do not have a diagram.
- Bi-directional Flows
- Due to differences in the tools, the Publisher transforms bi-directional Flows into 2 Item Flows.
- Code Generation Attributes
- Due to differences in the tools, some Code Generation Attributes used in Rhapsody are not transformed to MagicDraw, like "C++ Declaration type" properties.
Profiles are used to extend MagicDraw capabilities. The information is transformed in MagicDraw thanks to Tagged Values.
The user will have the possibility to do a post process in MagicDraw.
- The Publisher provides two options for color schema.
For more information on Colors and Styles transformation, consult Colors Transformation page.
- Preserve Original Rhapsody color scheme
- Use standard MagicDraw color scheme
- The Publisher keep containment and hierarchy between Elements during transformation. However, due to differences between tools,
visual differences can be observed in the explorers of the two tools.
- In Rhapsody, a Class Diagram or a Composite Structure Diagram can contain Properties not owned by the Diagram owner. This is not allowed in MagicDraw.
In case all Properties have the same owner, the Diagram is moved to be owned by this owner.
In case all Properties does not have the same owner, the Diagram is not moved, but Properties are in error.
- MagicDraw/Cameo does not show Constraints as in Rhapsody. To keep an equivalent display, an extra Note, with a link to the Constraint is created.
- 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 MagicDraw, but running MagicDraw 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.
- Diagram Connectors
- Diagram connectors are concepts existing only in Rhapsody, and are not available in MagicDraw.
Diagram connectors are transformed to Merged Nodes. Recommendation is to remove diagram connectors prior to publish.
- Diagram Resizing and Distortion
- Restrictions exist for how close items can be together in the target model as well as automatic resizing and spacing are applied.
Defaults available for modification are set using the
Defaults have been set to mitigate the distortion to the relative size and placement of the elements
- On certain diagram types, we have defaulted the Diagram Frame to off to avoid sizing distortion and justification issues in the published canvass. This can easily be turned back on after publish. (right click on the diagram and select Show Diagram Frame in MagicDraw.
- When an Element is displayed on a diagram and the text within that Element requires more space than available in the element size, the target tool resizes the element on the display to show all text.
Version 19, service pack 3 provides a property where the Publisher can negate the automatic resizing.
When set, the Element in the target tool with maintain sizing and crop the text. When the text is cropped the target tool places a dashed blue line around the Element as shown in the figure below.
- Display Options
- There are millions of possible ways the user can select to display elements on diagrams both in Rhapsody and MagicDraw.
Some of this information is available on the interface and other is not. Therefore the Publisher provides a properties.ini file,
located the installation directory, where the user can adjust the default settings.
We are constantly adding more capabilities to the properties.ini file allowing the user more flexibility with the resultant display.
- 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 from 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.
- Flows/Item Flows
- The implementation of these concepts are different between the source tool, the standard and the target tool.
For more information on Flows/Item Flows transformation, consult Item Flows Transformation page.
- It is not possible to transform line style, because of Rhapsody API limitation. We’ve introduced a Display Property called
LINK_LINE_STYLE in 2.4.0.
It permits the display of line style for a type of Diagram.
- In Rhapsody, both control flows and object flows are solid line.
In MagicDraw, control flows are dashed lines, object flows are solid lines.
Such display differences can't be managed by the Publisher for Rhapsody.
- Free Shapes
- The Publisher has limitations when publishing free shapes because of MagicDraw limitations. The available Free Shapes in MagicDraw are:
Other shapes (Polylines, Polygons, Curved lines, ...) won't be transformed. In addition, line style is not supported due to Rhapsody API limitations.
- Rectangular shapes
- Horizontal and vertical lines
- Image shapes
- Grouping by Stereotype
- The source tool has the capability to group Packages by Stereotype. The target tool provides a similar organizational capability through the interface SmartPackage. The user has to set the property rhp2md.semantic.newTerm.smartPackage to true. The figure below shows an example of the source grouping followed by the transformed grouping.
- Line Jumps
- The destination tool provides the capability to display line jump notation when line crossing indicating no interaction in that crossing.
The source tools does not have this feature.
- Optional Stereotypes on Pins
- In Rhapsody, <<optional>> is a Stereotype that can be applied on Pins. There are two major kinds of Pins in Rhapsody:
In UML, <<Optional>> is a Stereotype that applies on Parameters. Due to this difference, the Publisher implements the following rules:
- 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.
- In case of an <<optional>> ActivityParameterNode, the Parameter that will be produced will be stereotyped <<Optional>>.
- The ActivityParameterNode will no longer have a stereotype on it.
- OSLC Links
- OSLC Links between Rhapsody elements and IBM Rational Doors Next Generation (DNG) artifacts can be published to Cameo DataHub via an extra License.
Please see the option page Publish OSLC Links
- Panel Diagram
- Panel diagrams are a capability of Rhapsody and not published.
- Red Connector Lines
- MagicDraw is less permisive than Rhapsody, particularly on ownership. For example, in Rhapsody, an IBD can own a Block
but this is not allowed in MagicDraw.
Another example is that an IBD can exist without being owned by a Block which is not allowed in MagicDraw.
Also Connectors and Parts from the same IBD should be owned by the same Block.
These ownership issues show up with red connector lines in the published model.
Please refer to the guidelines for ownership in each diagram section for more details.
- When red connector lines are shown in the published model, Right click on Update Connector Ends menu.
The connection errors may also exist in Rhapsody prior to publish. Ensure the connectors have both ends defined prior to publish.
- Rhapsody Profile and Settings
- Profile mechanism is used by the Publisher to preserve Rhapsody data which has no equivalent in UML / SysML.
For more information on un-applying Rhapsody Profile, consult Unapplying Rhapsody Profiles page.
- 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.
- The Publisher does not publish tables or matrices. The source and target tool provide capabilities to export and import tables and matrices.
- Tags/Local Tags
- In Rhapsody, it is possible to have Tagged Values on Elements, even if the Element is not Stereotyped, while this is not possible in MagicDraw.
In Rhapsody, this is what we call "Local Tags".
For example, "block_2" is not Stereotyped, while it has a "local tag" called "block_2_localTag1".
To handle correctly Tagged Values in MagicDraw, Block "block_2" has to be stereotyped.
And this is the stereotype that carries the Tagged Value:
In this example, "block_2" is stereotyped <<LocalTags.block_2_Class_TAGS>> (<package_name>.<element_name>_<element_type>_TAGS).
The Stereotype is owned by a Profile called "LocalTags_TAGS" (<package_name>_TAGS).
In MagicDraw, "block_2" is stereotyped <<LocalTags.block_2_Class_TAGS>>, TaggedValues are set correctly:
- Un-associated Constraints
- In Rhapsody, you can display a Constraint that is not tied to an Element in anyway. This is
not allowed in MagicDraw. The Publisher transforms these Constraints to Notes.
- Virtual Operations/Functions
- Rhapsody provides a means to define an operation as
virtual This is a carry over from
UML where you would define a virtual function that the inherited classes would utilize but
with different parameters (usually in a table). Since this concept does not necessarily apply
to system level context it is not available in MagicDraw.