A load module has packages that are shared by teams and has also owned packages that other teams utilize. Consequently, they want to keep most packages set as "shadow" packages initially.
For example, the Rational Rose RealTime (RoseRT) model below represents a load module executable that is ready to be migrated.
Subsystem1 is owned by the team that is migrating loadModule1
Subsystem1::Block1 (interface package) is shared by another team that isn’t migrating yet
Subsystem1::Block1Impl package is owned
Subsystem2 is shared from another model
Given these assumptions, also assume that the loadModule1 team has a configuration management (CM) structure around how they control and manage the versions. Therefore, they want to maintain the CM structure of how Subsystem1 (which is owned) after migration into DevOps Model RealTime. However, parts of Subsystem1 are shared by outside teams, so how it is separated for project needs to be considered as well. Subsystem2 is managed and owned by outside teams, so we don’t need to care about its CM structure.
When you decide how to convert package fragments, you must make some important decisions on how they are shared, who they are owned by, and whether the team that owns it is ready to migrate. Each package-controlled unit will be migrated either as a shadow package or an owned fragment. In turn, the package may be extracted to another project as a root package or model, depending on whether it is necessary to share it or edit it independently.
The following activity diagram represents this decision tree:
Take a look at the example from above and make some decisions around how you import it. In this example, you want to maintain the containment structure of the controlled units because many scripts support versioning and releasing of the model at the load module context. To do this and support the sharing of these units, the controlled units must be separated into their projects.
First, considering "Subsystem1", since you own it, that means it should be an "owned fragment". Following the decision tree, you know it is owned, but you also know this package is a container only and isn’t shared by itself. Therefore, it can be kept as owned in the same project as the original owning model. The sub-package contents in "Subsystem1" are less straightforward, though. "Block1" is owned but shared by other team projects, so it will need to be extracted as a root shadow package in a new project. "Block1Impl" is also owned, but the owning model isn’t the primary editing context. In addition, you know it isn’t shared by other models in or outside of the migrating team. However, we want to do the official migration of this package during this import as opposed to its "owning" model (i.e., Block model). So, it also will be extracted to a root into the same project as the "Block1" fragment package, except as an owned fragment. The corresponding packages in the "Component View" would be extracted in the same way as their "Logical View" counterparts. For these packages, it would make sense for them to retain their logical package containment to differentiate them from the "Logical View" packages.
The "Subsystem2" package would be imported as a shadow package. The decision to make it a root package would depend on whether other load modules existed that also depended on this subsystem. If this were the case, it would make sense to extract it into a separate project.
Since the underlying model representation has changed from UML 1.x to UML 2.x, there are also associated notation differences that have changed. However, the goal is to try and preserve the diagram notation as much as possible, considering the notational differences. For instance, in UML2, internal transitions are no longer represented as self-transitions on the state frame. Instead, they appear in a separate compartment as a list that can be optionally filtered out. While it is important to support this notation, at the same time, we have to consider the time and effort users spent to organize and annotate their diagrams with internal transitions in RoseRT. The diagram organization may be familiar or have a specific spatial format that helps you locate a particular internal transition in an efficient way. Considering how you organize your diagrams, Model RealTime supports a migration option that displays internal transitions as they appear in Rose RT.
When considering using this option one should take into account that its usage could degrade the performance of diagram interactions and generated code and would make diagrams non-compliant with the UML2 standard. Therefore it is not recommended to use it, unless it is absolutely necessary.
There are also differences in the semantics for sequence diagrams that will appear notationally different. For instance, co-regions in RoseRT don’t have a direct semantic mapping. The closest mapping is a Parallel Combined Fragment in UML2, and the notational representation is significantly different than the co-region bars in RoseRT. If you desire a similar notation mapping, then the wizard does provide an option to maintain this. The option "Behavior Execution Specification with <<Coregion>> stereotype" will maintain a similar notation to RoseRT; however, the semantics are assumed to be derived from the applied <<Coregion>> stereotype.
The "Map Rose RealTime Constraint to a State Invariant" is a convenient feature if your sequence diagrams have lots of floating constraints. This option will detect constraints that have proximity to a lifeline and/or are attached to the lifeline and will convert them to State Invariant elements, which are on the lifeline. This is convenient, especially when converting coregions to PAR combined fragments, since the layout will change, and these floating constraints won't move with the layout changes. Since a State Invariant is a constraint, it is a useful way to associate a constraint with a position on the lifeline. The State Invariant being on the lifeline will move relative to the other items on the lifeline and, as such, is resilient to layout changes.
Note symbols on sequence diagrams have a different appearance in RoseRT and Model RealTime, and in some cases, creating such notes in a default manner can significantly ruin the layout of the sequence diagram after migration. The option "Reposition sequence diagram notes and constraints on import" allows to keep position of notes and their attachment to lifelines after import.
In addition to the UML2 differences, there are also tooling differences such as the color scheme, fonts, and how elements are sized. The recommended approach is to adopt the new Model RealTime color scheme because these colors will be consistent with the newly created models and other existing models. However, there is a "Use Rose RT colors" option that maintains the Rose RT color scheme if there are constraints or consistency issues with other published models. The diagram-based auto-size settings are important because shapes have different margins and compartment sizes between the two tools. These differences may make the shape cut off the compartment contents if forced to be the same size. When the auto-size settings are maintained, then the auto-size functionality of Model RealTime will accommodate the local compartment margins and make the shape look appropriate in the new tooling context. By default, the auto-size option is turned off for State and Activity diagrams because diagram layout and spacing are more of a concern. In addition, shape size is more critical to the overall diagram aesthetic. The recommended approach is to keep the defaults and observe the results before making changes to the diagram element auto-size settings.
During import, cardinality references of ports are set using special "ElementImport" links, which improves the performance of code generation and port multiplicity resolution. But in some cases, it is useful to see the full element path of such references. To enable this functionality, the migration option "Replace element import by qualified name" should be used.
