The modeling environment in DevOps Model RealTime has tried to maintain the look and feel of Rational Rose RealTime (RoseRT) diagramming experience (except for the differences introduced by UML2 and the integration with the Eclipse tooling). These differences should not interfere with the migration process, but some of the features have changed significantly which may affect how people decide to model in RoseRT before migration.
RoseRT has the capability to "Edit-Inside" a state or structure element to see and/or edit its contents. On evaluation of this feature in the Model RealTime context, the development team decided that this feature was not very practical as the window into the sub-diagram was difficult to edit and see; further, it didn’t scale beyond one level. Consequently, this feature was not migrated over explicitly. There is a way to see the contents of a state/part in Model RealTime through the "Region Compartment" and "Structure Compartment" commands respectively. These commands display larger size versions of the elements and can be used indefinitely through the containment hierarchy and are limited only by the space available in the diagram editor.
RoseRT was originally a next generation tooling for a tool called "ObjecTime Developer". In the process of that migration, some APIs changed within the Target RunTime System (TargetRTS). To ease this migration, an option was introduced in the Protocol specification to support the old API in backwards compatibility mode. This backwards compatibility mode is not supported in Model RealTime so you must ensure that you clear this option in all protocols before beginning the migration.
RoseRT and Model RealTime are based on a UML (Unified Modeling Language) semantic meta-model. Model RealTime is based on a newer version of the UML specification called UML2. The UML2 specification has changed significantly to accommodate more functionality. Interaction semantics is one of the areas that has changed the most. As a result, there are some differences after migrations that may introduce differences in the diagram appearance.
In RoseRT, you can delete the focus of control (FOC) for asynchronous messages. In Model RealTime, the behavior execution specification (analogous to an FOC in RoseRT) is mandatory. After migration, the deleted/missing FOCs will appear with a default minimum size. To avoid diagrams having a slightly altered appearance after migration, you might want to keep the FOC elements in sequence diagrams with asynchronous messages.
Message names are not imported when the message is assigned to a signal or operation. The name of the message is set to the signal name due to the following from the UML 2.2 specification: The signature must either refer to an Operation (in which case messageSort is either synchCall or asynchCall) or a Signal (in which case messageSort is asynchSignal). The name of the NamedElement referenced by signature must be the same as that of the Message.
Message names should be kept the same as the signal or operation to ensure that they will appear the same after migration.
The layout of the sequence diagrams usually signifies ordering of the messages in the interaction. In RoseRT, the ordering is only specific to a particular lifeline. This allows for cases where a local state and/or local action are co-located at the same vertical location on different lifelines. In Model RealTime, the ordering in an interaction is global, meaning that all elements have an implied ordering relative to all other elements even if they aren’t on the same lifeline. This is because Model RealTime is built on the UML2 meta-model which has these semantics. Therefore, the local state and local actions are adjusted by the diagram layout algorithm to be offset from each other to reflect that. This is somewhat unavoidable, but you can layout your diagrams with this offset in mind to accommodate the global ordering paradigm. There are ways to represent random ordering in UML2 through the use of a "Parallel Combined Fragment" (see the following section). It is not possible to decide if this was the intention in the RoseRT sequence diagram since the vertical alignment is the only indicator. You can add the "Parallel Combined Fragment" after migration, if desired.
Sequence diagram example after migration that demonstrates semantic equivalence to diagram above:
