Model architecture has to consider a lot of different concerns – memory consumption, dependencies and ability to change the model effectively. The ability to manage change means the model is separated into components that are modified by individuals or separate teams. This also means that changes from one team or component are often propagated into their dependencies during a refactoring operation. An example of a refactoring operation is where a name of an element changes and dependent elements that reference that element need to update their reference accordingly.
In Rational Rose RealTime (RoseRT), to refactor effectively you often need to have all components and dependent components in the same model. As a result, it may be more effective to work with the system or executable model to do changes in a particular component. That way, you can be sure that changes are made to dependent components immediately. This approach inhibits working with a "block model" except for more trivial changes (a block model is a model of a single component that is designed for unit testing). When you refactor changes made in a block model, you run the risk of breaking the system model unless done in context to the system model.
In contrast, if you import block models into DevOps Model RealTime and the "system model" references these block models, it’s possible to work with the "block models" independently because Model RealTime refactors closed models located in the workspace. Refactoring closed models is possible because Eclipse workspaces can contain multiple projects, and the projects can have one or more models inside them. Also, models can be closed if not currently being edited, viewed, or referenced. Further, leaf dependencies or models that don’t depend on other packages can be edited independent of the rest of the system.
In summary, there is value when you separate your system model into smaller component ("block") models that you can use for test or minor modification. After migration to , these "block" models are imported into their project and are considered the primary target for editing instead of relying on the "system" model context. See Separated model.
The mechanism of shared elements is a powerful concept in RoseRT because it allows such elements to be reused by multiple models. This allows your team to develop common system components which can be used to build layers of services in different applications. Model RealTime supports sharing of packages or classes only. Since shared elements can reside within multiple model contexts, there should be a "master" model context where the shared element is edited and modified. The idea of "ownership" is managed through a property on the specification of the shared element. If you select the "Owned by model" check box, the element is modifiable in the owning context. If cleared, the shared element is not modifiable.
During the Model RealTime model import process, this property is used to determine how the package will be migrated by default.
| Shared (Controlled) Package in RoseRT | Migrated As: | |
|---|---|---|
| "Owned by model" property is selected. | Package is imported as an owned fragment (directly analogous to a controlled unit in RoseRT). |  |
| "Owned by model" is cleared and package has already been imported as owned from a different model | Package is replaced by an "element import" relationship to the previously imported package in the model workspace. |  |
| "Owned by model" is cleared and package doesn’t exist in the workspace. | Package is imported as a shadow package fragment which allows synchronization with the original package controlled unit in RoseRT. |  |
It’s possible that the "owned by model" property may not have been rigorously adhered to and the shared package may be "owned" in multiple contexts. Or, the development team may rely on a configuration management (CM) system to make the real determination if a particular package is "owned" or not (in other words, the CM system only allows write access to a particular package based on user privileges and so on). In these cases, you have the ability to modify how a particular controlled package is imported into (owned, shared, shadow) through the Controlled Unit Conversion UI page of the "Rational Rose RealTime Model" Import wizard. However, if you know about the "Owned by model" checkbox and you can keep it synchronized with the real model owner in RoseRT, you will save time and effort by modifying these options when it comes time to migrate.
Shadow packages are a concept introduced in Model RealTime that accommodates large enterprise organizations in their migration effort from RoseRT to Model RealTime. A shadow package is a fragment in Model RealTime that is not modifiable; it can be resynchronized and re-imported from the original package in RoseRT to keep the content synchronized. As another way to understand this concept, consider it "mastered" in RoseRT and simply replicated in the Model RealTime workspace.
A model or subsystem in RoseRT may have outside dependents in other subsystems that share in controlled packages from it. Those dependent models may be in a position to migrate to Model RealTime and will have their dependencies to other models become shadow packages. If your model has outside dependents to owned controlled packages, it is useful to understand some restrictions with modifying these packages. If these packages are modified in RoseRT, the contents could be replicated (synchronized) into a shadow package in Model RealTime.
RoseRT
In this example, the component Core1 is used by Product1 and Product2 in RoseRT. However, Product3 has migrated to Model RealTime and also depends on Core1. Core1 has been imported as a shadow package and replicates or synchronizes with Core1 in RoseRT.
Considering this synchronization, there are some complexities and/or limitations that cannot be avoided due to the nature of the meta-model transformation. To avoid some of these issues, it is best to turn on quid support in RoseRT for all models that own shared packages that will exist as shadow packages in Model RealTime.
When you turn quid values (i.e. unique identifiers) on, the synchronization process is able to resolve references to elements that have been renamed or moved. Understand that synchronization will still work if unique identifiers are turned off; however, the model import wizard will probably consider renamed elements as a new element and references to the previously named element will be considered deleted. In this case, it is best to minimize changes in these shared packages or try not to rename or move elements within them.
In addition to packages, the shadow concept is partially available also for real time classes/capsules and protocols, which are separate control units in RoseRT. The difference from the shadow packages is that synchronization is not available for them. However, there is a capability to import units containing classes and protocols, which are not owned by the current model, and once the model that owns the units has been imported, there is a capability to migrate imported classes and protocols. This allows read-only access to shadow elements until the owning model is imported and their conversion to short-cuts after the owning model is imported.