DevOps Model RealTime is built on a lot of Eclipse-based technology that is reapplied and reused in other domains. The advantage of this approach is that the technology is well-tested, adaptable to different domains and has an established Application Programming Interface (API) for extensibility. However, often these components are not optimized for a specific domain. Therefore, as a result, it’s possible that these products use more memory than the equivalent infrastructure in Rational Rose RealTime (RoseRT). There are some things that you can do to your RoseRT model to minimize memory issues before migrating to Model RealTime.
RoseRT requires a separate component for each target configuration. DevOps Model RealTime utilizes the C/C++ Development Tooling (CDT) which allows a single CDT project to be responsible for multiple target configurations or compile variations (e.g. debug/release). To take advantage of this capability, the Model RealTime model import wizard merges components in RoseRT that have the same code generation properties into a single abstract transformation configuration (TC) with the concrete transformation configurations inheriting from it and a single corresponding CDT project. The result is less CDT projects created (in memory), and an easier workspace to manage.
The concept of inheritance for TC files allows the property set functionality from RoseRT to be maintained after migration. Property sets is a convenient mechanism to store default properties for particular element types that are automatically inherited by each model element instance unless they are overridden locally. For models that are migrated from RoseRT, the inheritance for TC files will automatically be set based on the components' use of property sets. Default TCs are created in the project that is analogous to the Default property sets in RoseRT. Also for components that have the same properties in a component package, an abstract TC will be extracted that each component will inherit from.
The property for TC inheritance behaves in a similar way to the prerequisite property which also specifies a list of TCs. A TC can have multiple inheritance parents, and the order in which they are specified dictates which will take priority in the case where they have the same properties.
There are visual cues in the editor to see which particular properties have been overridden from the parent properties. If the property text is bolded, then that property is local to the TC and will take precedence over the property stored in the inherited transformation configurations.
Considering this TC file inheritance and how the component merge will work on migration to Model RealTime, we can take a look at a concrete example.
Above, the RoseRT model has a package with 4 components that generate the same sources to the different target configurations they support. Since they reside in the same package and have the same generation properties, they are candidates for merging during the migration.
Generates to CDT Project
Post migration, the components now exist as TC files that inherit from a newly merged TC file that contains all the common generation properties. This means that changes to the generation can be centrally managed in that abstract TC (e.g. adding / removing sources etc.). All the concrete TCs will generate in a single CDT project that has multiple configurations – one for each target (cygwin, sparcgnu281 etc.).
There are some component storage and naming requirements in RoseRT in order for this component merging to occur:
| CodeSyncEnabled | Environment | SourceSubdirectory |
|---|---|---|
| CommonPreface | GenerateTags | Threads |
| CompilationMakeInsert | Language | TopCapsule |
| CopyrightText | References (Sources) | Type |
| DefaultArguments | SingleDataCompilationUnit | UnitSubdirectory |
It is easy to create monolithic models in RoseRT because only one model is allowed in a workspace. Consequently, everything that needs to be viewed has to exist in the model at some level. This doesn’t map well in the Model RealTime world because Eclipse supports multiple projects in a single workspace and each project may contain multiple models as well.
There are many different aspects to a RoseRT model; there are the production bits which are code generated into the executable or library as well as the supporting model elements which help in the construction of the production model. These are the use-cases, sequence diagrams, collaborations and other model elements that describe parts of the system but may not be involved in the code generation aspects of the model. These elements should be scrutinized to see if they are necessary to carry forward with the development model. If you can delete or separate these elements into a new model you will save memory resources during the import process. You may consider deleting old sequence diagrams that were originally generated from a trace execution. For model separation, test artifacts and harnesses that test a specific component within the top model may be good candidates for separation.
In the example above, all the sub components and systems are contained in the top-level model including the associated test artifacts and residual sequence traces; therefore, this example represents a good candidate for model separation.
In the separated model, four new models are created to isolate the test artifacts from the production code. The "TopLevelModel" shares in the components and packages from Model1 and Model2, but doesn’t require any visibility of the associated test artifacts. This separation keeps the model foot print smaller and will ease the model migration process because the model import wizard requires less memory.
Having the model controlled offers a number of advantages in terms of managing a project with a team of developers. This is well documented in the
This is well documented in the RoseRT Team Development Guide.
There are some additional advantages when controlled units are migrated into Model RealTime as fragments. A fragment is a model element that exists as a root in a separate file resource (analogous to a controlled unit in RoseRT). Model RealTime has a loading strategy that states if a fragment isn’t referenced by a model or set of fragments that are currently loaded, then the fragment won’t be loaded. Essentially, the fragments are loaded into memory "on-demand". When working with a large model, if you are only interested in a particular subsystem, then the fragment loading strategy is very efficient because only the subsystem and it’s dependencies are loaded.
Consequently, the more granular the model is controlled to, the more potential memory is saved. A granular approach saves memory resources because dependencies are broken up and won’t force the load of elements that are part of a larger unit but don’t have dependencies to an element being loaded. To take full advantage of on-demand loading, as a general recommendation, control down to the capsule/class level.
There is cost associated with this since refactoring operations become more cumbersome because the associated resource may need to be moved or will become out of sync with the model name and location. Also, there are more file resources being managed by the source control system which means there is more complexity or overhead with respect to updating with the repository. There is an article on DeveloperWorks that discusses some these issues around model management in a source control repository: Model Management with ClearCase.
There are two aspects to every model: the semantic elements which transform into domain language code (such as C++), and the notation elements which represent a view of the semantics that allow them to be displayed in a diagram. The transformation is only concerned with the semantic elements in the model and the notation elements are ignored. Given the fragment on-demand load capability, it makes sense to separate out the diagrams (which contain notation elements) into their own controlled units. That way, the controlled units won’t be loaded unless you decide to edit or view the diagram during a work session. In RoseRT, it is not possible to create controlled units from capsule state and structure diagrams. However, you may choose to control any class, sequence or other diagrams in the file system.