Troubleshooting
Problem
Often IBM Rational Rose RealTime models or applications are part of larger systems. For example, there may be legacy code compiled into a utilities library. Rather than recreate the library as a Rose RealTime model, it is desirable that Rose RealTime models access, and if necessary, rebuild the external library.
Resolving The Problem
There are different ways of accomplishing this in Rose RealTime. This technote describes two methods. The attached zip file includes an implementation of these two methods and contains detailed information about what is required in the model.
Characteristics of Method 1:
- The external classes are not modeled in the Logical View.
- The component requiring the external library adds some extra make rules to the CompilationMakeInsert (Component, C++ Compilation) property that build the external library. The component now depends on the external library and cannot be built without it.
- An external library component is added to the model. It is not necessary to do this, but it is good modelling practice to explicitly represent the external library in the UML model.
- The external object files and library files are built in the location where the external source code files are located.
Advantages of Method 1:
- Does not require much work in the model.
Disadvantages of Method 1:
- The component using the external files requires all the information on how to build the external library. If multiple components wanted to use the external library they would all require this information.
Characteristics of Method 2:
- The external classes are modeled in the Logical View.
- The external library is modeled as a C++ Library component containing the external classes as references. This component can be built on its own.
- The library or executable component requiring the external library adds a dependency to the C++ Library component representing the external library.
- The external object files and library files are built in the C++ library component directory.
Advantages of Method 2:
- The external library is in a separate component. If multiple components wanted to use the external library then only a dependency is required to the external library component.
- The external elements are in the Logical View, so the dependencies can be drawn within the tool.
Disadvantages of Method 2:
- Extra files are created in the library component's directory. For example, a near-empty .cpp and .h file is generated for each class in the model representing an external class.
These two methods are suggestions. It is also possible to use an approach that is a combination of these two approaches.
For more detailed information about how these two methods are implemented, see the attached example model and external library files.
The model contains components to build NT40T.x86-VisualC++-6.0 and SUN5T.sparc-gnu-2.8.1 configurations of the model and external library.
Instructions:
1. Unzip the attached file 116872701_BuildExternalLibrary.zip. This will create two directories: ExternalLibraryFiles and Model.
2. In Rose RealTime, open the model file: Model/BuildExternalLibrary.rtmdl.
3. Select File > Edit Path Map…, add a path map $EXTERNAL_DIR set to the full path of the ExternalLibraryFiles directory. If you were build from outside the toolset, $EXTERNAL_DIR needs to be set as an environment variable.
4. In the model, take a look at the elements and notes on the Main Logical View and Component View diagrams. The diagrams contain notes which will direct you to other important parts of the model.
5. Build TopExecutable<platform>1 or TopExecutable<platform>2. (Note: Library<platform>2 can also be built alone).
Special Notes:
This solution satisfies the criteria that a user be able to build their Rose RealTime model and external libraries in one place - from within the model. As an alternative, it would be possible to build both the Rose RealTime model and the external libraries from outside of Rose RealTime. For information on building a model outside of the tool, see the following section in the online help:
Guide to Team Development > Building and Integrating (Integrator Tasks) > Building Using Automated Scripts
If a type descriptor is necessary for the external classes (i.e. to send by value, watch, inject, or send to the log), then an additional step is required. For this additional step, please see the following section in the online help:
C++ Reference > Classes and Data Types > C++ Data Type Examples > Integration Options
Related Information
Historical Number
116872701
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21136451