Restrictions
Almost all UML elements can be used in Rhapsody in combination with the
RXF. This includes classes, objects, files,
statecharts, several kinds of relations etc.
However, some UML elements
cannot be used together with code generation and for some other elements restrictions exist.
Activity Diagrams and Flow Charts
Code generation is only supported for operation Flow Charts. Code generation for Activity
diagrams is not supported.
Active Classes
The RXF with the RTOS Adapter OORTX
does not interface with an RTOS. Therfore for OORTX active classes
(classes that execute in an own execution context / task) are not
supported. When specifying a class as ‘active’, the RXF model checker
will show an error.
It
is highly recommended to instantiate active classes statically in the
model. If this is done consistently, all active classes and their
instances will be listed with details in the ActiveClassTable in the
RXF Profile.
Termination of active classes by calling endDispatching() or endBehavior() on active reactive classes is fully supported.
Destruction of active classes is only supported with limitations:
- An
active class instance should NOT be destroyed while executing.
Therefore it should be deleted by a task with lower priority or it must
be ensured that the underlying RTOS task is terminated before deleting
the active instance.
- Self destruction of an active class from its own context (while processing an event) is not allowed.
Animation
The RXF does not support the IBM Rhapsody internal animation, because
animation is using hevy weight instrumentation and TCP/IP communication.
The
goal of this features is to add back-annotation information to the
generated code to make tracing of the software possible. To add
back-annotation and tracing capabilities to the RXF, please refer to
the section on the UML Target Debugger by Willert Software Tools.
When
using the Embedded UML Studio version of Rhapsody by Willert Software
Tools GmbH the animation option is greyed out, when using the Rhapsody
Developer version, this is not greyed out and selectable. However,
since in the RXF does not contain implementations for the functions
called in the generated instrumentation, the compiling and linking of
the generated code will always result in errors.
Container Classes / One-to-Many Relations
The RXF supports the container sets OMContainers, RXFContainers and STLContainers.
For the OMContainers, only OMList and OMMap are supported. OMCollection and OMStaticArray are not supported.
More detailed information about the
API Differences can be found at willert knowlede base.
Critical Sections vs Mutex
For the
OORTX and the
embedded RTOS
Adapters, the RXF uses critical sections (interrupt locks) to protect
MemoryPools, EventQueues and the Timer Management. For those adapters,
the frameork itself does not use mutexes.
For
Linux or Windows, mutexes are used to protect MemoryPools, EventQueues and Timer Management.
Events
Please also refere the Technology section
Asynchronous Messages for more detailed information about Events.
The
RXF in C++ generates events differently than Rhapsody does it normally.
Event receptions are generated as Operation calls and events are
allocated in the destination, instead of allocating them in the source
by the expansion of the GEN-Macro.
Code generation for an event differs depending on the property
CG::Event::DeleteAfterConsumption. If this property is set to True
on a specific event, calling the GEN Macro will dynamically allocate an
event and send it to the message queue of the destinations active
context. It has a new operator that allocated memory from the event
pools and its delete operator takes care to put back the memory into
the appropriate pool.
When the property
CG::Event::DeleteAfterConsumption is set to False on a specific
event, it is a static event with a private new operator (to make
sure it cannot be dynamically allocated). Inside the destroy operation
a flag deleteAfterConsume protects static events from being deleted.
With the RXF, the code generator will generate static events as
local instances in the reactive destination and just put those
instances to the event queue.
Events
must not be send from a static operation. A nonstatic memberfuction of
an instance must be called, that then should send the event.
Events with Arguments will ignore the Property CG::Event::DeleteAfterConsumption and always be generated dynamically.
When
using dynamic event from the event pools, the pools need to be
carefully configured. If an event pool is full, this calls the error
handler RXF::ErrorHandler::error() with an argument that the error
handler may not return. For details see
Error Handler Argument "returnAllowed".
This means when event pools are configured too small, the system cannot
continue running but needs to be shut-down or restarted in the
application’s error handler.
The RXF does contain deprecated macros to send events. This may require changes in the
UML model, if macros like FIRE or GEN_ISR were used in user code
sections.
The RXF does not support inheritance of Events.
Ports
Only ports with interfaces are supported by the RXF.
Rapid ports (not having a specified interface) are not supported.
Power Saving Management
The RXF-Cert does not implement power saving functionality or a sleep mode itself.
When using the
OORTX, and power saving functionality is required, please contact our
support
team
When using an
embedded RTOS Adapter, these functionalities are mapped or handled by the RTOS in use.
Statechart Start Behavior
In
statecharts, default Transitions and every other states, that are
connected to the initial state via a null transition are executed from
the context that calls startBehavior(). In earlier Versions and in OXF, default
transitions from the initial state were executed not before
startDispatching(). For more detailed Information about Run-To-Completion please refer to
Deterministic Real-Time BehaviorStatechart Implementation
Only Statechart Implementation Flat is supported. Code generation for Statechart Implementation Reusable is not supported
Timers
Please note: When tm(delay) is used in a UML state chart, the
RXF by default does not guarantee, that the transition will be taken after the exact time.
For detailed information on realtime behavior, please refer section
Deterministic Real-Time BehaviorTriggered Operations
Return values for triggered operations are not supported.