The Import a Rational Rose RealTime model wizard has several pages that provide options on how to import the model into DevOps Model RealTime. The most significant is the "Controlled Unit Conversion" page, which allows you to select how the different controlled units in the RoseRT model are migrated into Model RealTime. A "Controlled Unit" is a separate file that stores a particular model element at its root. Controlled units allow you to edit elements such as packages and classes independently of other elements in the source control system. The corresponding terminology in Model RealTime is called a "fragment", which is essentially the same thing as a controlled unit.
The following table describes the different ways controlled units can convert to fragments in Model RealTime:
| Convert to: | Description |
|---|---|
| Absorbed Element | Unit is loaded into the same resource as the owning model or root package; no fragment is created. |
| Owned Fragment | Unit is converted into a fragment in the same relative location to the model as in RoseRT, unless a Project is specified (Packages only). If you specify a project, the Project is created (if it doesn’t exist), and the fragment will be created as a root package in the project. |
| Shadow | This option creates a new fragment that is owned by a Model RealTime model that is a shadow of a corresponding RoseRT controlled unit (package or class). This fragment is read-only, and changes can only be made in the corresponding RoseRT element unit. Package units can be synchronized into the shadow packages and extracted into separate root projects. Any controlled units that are owned by this element are absorbed into the element. |
| Shortcut | Available only for packages and classes that have been imported into another model in the workspace. Only packages and classes for models that are currently open in the workspace can be detected as previously imported. On import, the unit is converted into a shortcut, and references will point to the originally imported element. |
On import, controlled units can be in a number of different states that represent how they will be imported. For each state, there is a default action that takes place; this action depends on the "Owned by model" attribute on the "Unit Information" tab of the element specification dialog in RoseRT.
The following table lists the default conversion states; you can adjust these states as needed:
| Controlled Unit Element State in RoseRT | Default Action |
|---|---|
| Owned but not migrated previously | Load as owned |
| Owned but detected as migrated previously in another model in workspace | Load as element import to existing element |
| Owned but detected that a shadow element exists | Load as owned and log a warning that a shadow element exists |
| Shared but not migrated previously | Load as owned shadow element |
| Shared and migrated previously | Load as element import to existing element |
| Shared and exists as shadow element | Load as owned shadow element |
Another choice, which is not displayed as a default, is the option to simply absorb the unit into the model resource (absorb into model). Alternatively, you can import the model as a standalone model, although this is not the default choice.
The controlled unit page of the Rational Rose RealTime model import wizard is beneficial for model hierarchies that have inconsistent usage of the "Owned by model" property on controlled units. For instance, when you set the controlled unit package to "shared" in RoseRT, you cannot do several fundamental actions that allow you to manage the unit. Further, the source control system may own the unit; therefore, only certain users may modify the controlled units. When source control systems own units, it is not important how the ownership is specified in the tooling because the ownership is defined by the source control system.
Considering the modes of conversion above, the dialog needs to accommodate these as well as provide flexibility to provide blanket conversion for all elements. Common methods of importing may be to ignore all fragments for testing purposes, in which case, all units will be absorbed into the model. Likewise, the practitioner may simply want all fragments to be owned without concern for their shared properties. This is accomplished in the UI using a radio button in the dialog for the three modes of import.
If you want to merge all controlled units with the owning model, so that the controlled units no longer reside in separate files, select the first radio button that appears on this page. All other controls on this page are disabled.
If you want to import all controlled units as fragments that the imported model owns, select the "Convert all controlled units to owned fragments" radio button. In this case, the custom unit UI is disabled; however, the "fragment/model creation options" are enabled and allow you to determine the default naming scheme for the new fragments.
In this final mode of operation (Convert controlled units to fragments, models, or shortcuts), you can control how each unit is converted on an individual basis. By default, the units will be displayed hierarchically in a tree that can be collapsed if needed. The "Convert to" column allows you to select the conversion method for the individual unit. If you are unsure of the true ownership of the packages in the model, the safest approach is to click the "Share All Packages" button under the list control. This option converts all owned fragment packages into Shadow Packages or maintains them as "Shortcut" links if the original package has already been imported into the workspace.
For complex models with many controlled units, it may be difficult to decide how each controlled unit migrates into Model RealTime. You may need considerable time to decide what units need to become models and/or whether something should be a shadow element. The defaults attempt to reduce this overhead; however, you must inevitably perform analysis so you can figure out the best migration approach. To save the settings for how to import controlled units, you can click "Save Custom Conversion". During the experimentation phase, you can use the "Save Custom Conversion" functionality to avoid modifying the conversion method settings for each controlled unit multiple times. This functionality is particularly helpful when you experiment with migrating controlled units in very large models. When you click the "Save Custom Conversion…" button, the current settings in the custom conversion table are saved to a file in the workspace. A message box will appear indicating the location of the saved configuration file.
If the import wizard detects a custom conversion configuration file in the workspace, you can click "Load Custom Conversion" to restore the saved settings for importing controlled units.
The "Load Custom Conversion" button is disabled unless a custom conversion configuration file exists in the workspace at the location specified above. When enabled, you can click this button to load the current settings into the dialog. A warning dialog will appear to ensure that you want to perform the operation.
It can be useful, since fragments are not shareable entities in Model RealTime, to allow for the sharing of a fragment if in the Enterprise’s set of models, there is no clear owner of a particular fragment. For instance, in RoseRT, the owner of a fragment is determined conceptually by a Boolean property on the fragment, which determines if it is owned by the model or has been shared. If this property is not clearly defined or is set as "owned" in multiple models, it may make sense to have this unit be pulled out into its own model that it is a distinct shareable entity. Otherwise, it may be shared in the context of another model imported from RoseRT that has other elements that haven’t been designed to be shared in other models.
Finally, there are some global settings for how individual fragments and models are created during the import. These options are for how fragments are named and their location in the file system. You may wish to use the import as an opportunity to consolidate the fragment naming based on the logical name of the unit in the model. This could be useful if the controlled unit names in the file system have become out of sync with the corresponding logical name over time.
The first two radio buttons control this behavior. The default setting ("Use controlled unit file names") will continue to use the controlled unit names in RoseRT and translate them to the Model RealTime fragment file extension (.efx).
RoseRT organized controlled units in a similar fashion to how the logical model is organized. If a particular element was contained deep in a package hierarchy, then the corresponding controlled unit would typically be stored in a similar containment hierarchy on the file system. This organization is convenient if the user needs to locate particular controlled units and be able to "mind-map" them back to the corresponding element in the model. This paradigm is brittle when considering cases where the model element is refactored by either renaming it or moving it to a new location. The controlled unit must be either similarly renamed or moved to correspond with the logical element change. These can be expensive CM operations and can result in loss of file history in some systems (e.g., CVS). Model RealTime has accommodated these concerns by allowing an element-agnostic naming approach for fragments. This means that fragments are named generically and have a flat containment relative to their parent fragment. Even if the drawback with this approach is that file names become less "meaningful", it lets the fragments be resilient to refactoring use-cases.
The first two radio box options ("Use controlled unit file names"/"Use controlled unit element names") will respect the RoseRT controlled unit organization. The fragments will be created in a similar containment hierarchy and named according to either the controlled unit filename or the corresponding logical element. There is also a third option, "Use generic name in flat containment (Modeler default)", which supports a mode where the user can choose to import the controlled units using the same flat containment and generic naming as described above. In addition, it is possible to specify a subfolder where the fragments are located as opposed to having them created flat in the owning project.