NOFReactive

Project Members:

• Vladimir Startsev (admin)

What is the NOFReactive framework ?

Why one additional Framework for IBM Rational Rhapsody (c)?

This is long number of the frameworks: OXF, SXF, RXF, MXF, IDF, … .
While the OXF is versatile, available for the C and for the C++ languages, it is complex (lines of code), big (memory layout) and uses dynamic memory. Numerous OXF settings and the based on the OXF frameworks are created to address the needs of the embedded applicationn development:
* Replace dynamic memory allocation be pseudo-dynamic memory allocation based on the static pool (private pools of the events, reuse of the events).
* This is still dynamic memory management with all bound to the dynamic memory management problems: no memory, destruction of the memory pool, excessive use of the dynamic objects and pointers, which needs to be managed
* The reuse of the statically allocated event instance is still one of the types of the dynamic memory management: the re-use (re-send, re-initialization) of the event while not processed/received (in processing or in the message queue) possible and requires additional handling
* Timer system is complex (code lines), not effective (CPU resources) and not reliable (single point of failure). See design and implementation of the timer system of the BSD unix version 4.4 for comparison.
* Reduction of the supported by the framework UML constructs
* Frameworks like IDF are simple, but still too complex (code lines)
* Limited UML support requires compensation at side of the application development and leads to increased application complexity. For this reason limited UML support does not decrease the complexity of the entire application: it does only move the complexity from the framework to the user code. This is one negative effect: instead of use of the common and well tested framework new code/library shall be created and maintained.
Limited UML support does not allows to create meaningful and effective software architecture (see below), which can be used for the code generation.
* Limited UML support does not allows use of the effective UML design checks (if major part of the design is done in code and not in UML then UML design checks are not applicable).

Moreover all frameworks do rely on the OS synchronization primitives and require additional precautions for sending events from different execution contexts (for example from the interrupt service routine) to the context where state chart is executed.

Additional note about event processing. The frameworks supporting asynchronous event processing are passing events as pointers. The static memory allocation in the frameworks affects the event allocation only. This does not change the way how the events are processed. Each event contains link fields. The link fields are used to manage the events in the event queue. The event self is passed as pointer to the base class. The reception of the event and the access to the event parameter requires the casting from the base class to the event class (See OMSETPARAMS OXF framework macro for details).

The major goal of the NOFReactive framework is to address the issues listed above and to provide one solution for small embedded applications.

[Vladimir Startsev]

Known problems

1. Events without parameters are not supported. Workaround: add parameter to each event. This shall not effect the performance and/or size of the code (ream more on the details of the event processing).
2. Triggered operations are not supported.