26
13 The Rational Rhapsody framework is a collection of base classes and interfaces that are used by the code generated from a users model. There are two main parts to this framework: 1. The Object eXecution Framework (OXF), which is the part of the framework that will always be linked into the final generated code. 2. The Animation and Tracing Framework, which is only used when animating or tracing and as such is less important to understand than the OXF. Framework CPU External Code RTOS OXF Framework Rational Rhapsody Generated Code

Document13

Embed Size (px)

DESCRIPTION

Rhapsody Material

Citation preview

Page 1: Document13

13

The Rational Rhapsody framework is a collection of base classes and interfaces that are used by the code generated from a users model.

There are two main parts to this framework:1.The Object eXecution Framework (OXF), which is the part

of the framework that will always be linked into the final generated code.

2.The Animation and Tracing Framework, which is only used when animating or tracing and as such is less important to understand than the OXF.

Framework

CPU

Exte

rnal

Code

RTOSOXF Framework

Rational RhapsodyGenerated Code

Page 2: Document13

14

Object eXecution Framework organization The OXF Framework is created directly from a

Rational Rhapsody model. (See <RhapsodyInstall>\Share\LangCpp\oxf\model\oxf.rpy).

There are three main parts to the Object eXecution Framework

1. Event Driven Framework (Core and Core Implementation package)

2. Operating System Adapter Layer (Adapters package)3. Container Classes (Part of Services package)

CPU

Exte

rnal

Code

OXF Framework

Rational RhapsodyGenerated Code

RTOS Event Driven Framework

Operating System Adapter Layer

ContainerClasses

Page 3: Document13

15

Object eXecution framework model The OXF Framework consists of many different

nested packages enabling it to be built in a scaleable fashion to include only the required functionality.

There is a set of interfaces in CoreAPI and a default implementation in CoreImplementation for the framework behavior. This allows you provide your own Implementation yet not break the automated code generation process.

Page 4: Document13

16

These are the principal interface classes in the Event Driven Framework:IOxfActiveIOxfReactiveIOxfEventIOxfTimeout

Event driven framework interfaces

Page 5: Document13

17

These are the principal classes of the default Event Driven Framework implementation:OMThreadOMReactiveOMEventOMTimeoutOMProtectedOMTimerManagerOMMemoryManager

Event driven framework implementation

Page 6: Document13

18

OMEvent OMEvent – Base class for all signal and timed events:

OMEvents have an unique ID.They know the address of their

destination (receiving reactive object).

There are specific Framework events for internal usage.

Events may – or may not be deleted after consumption (if static).

They may provide their own customdestroy() operation, for example, to reuse the event in a memory pool.

Page 7: Document13

19

OMTimeoutOMTimeout – Base class for all Rational Rhapsody

timed events:They inherit everything from

OMEvent.OMTimeout events have a

special ID.They add a delay time attribute.They may be canceled before

they matured, but also after already being queued.

Page 8: Document13

20

OMReactiveOMReactive – Base class for all reactive classes (for

example, all classes with statecharts).OMReactive knows the thread it runs on.It provides send() operations in order to

put events into the input message queue of its active class via OMThread::queue().

It provides the operations handleEvent() (for asynchronous signal events) and handleTrigger() (for synchronous events).

It provides operations to schedule and cancel relative timeouts.

Finally it defines virtual operations for the code generator in order to implement the statemachine of the application class, for example, rootState_processEvent().

Page 9: Document13

21

OMThread OMThread – Base class for all «active» objects for

multi-threaded applications. OMThread creates one event

Queue and a dispatchingGuard and runs its execute() operation in an operating system thread.

The operation queue() allows you to put events of type IOxfEvent into the message queue.

execute() by default readsmessages from the queue anddispatch() them calling the reactive destination’s handleEvent().

Page 10: Document13

22

OMThreadEach OXF thread waits on an event queue for

incoming events:

The above is a simplified version of the main loop operation in an OXF thread. It is named execute().

This operation may be overloaded in order to read from other blocking devices, rather than read OXF message queues. This is what was done in the KeyReader class in the CashRegister example.

OMReactive* OMThread::execute() { for ( ;; ) { while ( !eventQueue->isEmpty() ) { IOxfEvent *event = eventQueue->get(); IOxfReactive *dest = event->getDestination(); dest->handleEvent(event); delete event; } eventQueue->pend(); } }

Page 11: Document13

23

Client server OXF sequence - sending

Page 12: Document13

24

Client server OXF sequence - receiving

Page 13: Document13

25

OMProtectedOMProtected is used to

protect an operation from concurrent access. To do so, set the property CG:Operation:Concurrency from sequential to guarded.

This protects this operation with OMProtected (which is basically a mutex).

For more info, see the OMProtected.h file.

Page 14: Document13

26

OMMemoryManager The framework includes a memory manager that

overrides new and delete to allocate memory.

For more info, see the OMMemoryManager.h file.

Page 15: Document13

27

Extending memory management There are two ways to override memory allocation:

Use the static architecture properties so that memory will be allocated statically using memory pools.

Provide a custom memory manager class.

Page 16: Document13

28

Interrupt driven frameworkBy using the interrupt driven framework

(IDF), it is possible to use Rational Rhapsody in C++ without the need for an Operating System.

The IDF can replace the OXF and RTOS. It generates smaller code. Requires just a periodic interrupt to be

configured (so that timeouts can be used in statecharts).

The IDF is supplied in a Rational Rhapsody in C++ model RiCpp_InterruptDrivenFramework.rpy.

CPU

Exte

rnal

Code

IDF Framework

Rational RhapsodyGenerated Code For more info, see the documentation included in

the V73_RiCpp_InterruptDrivenFramework model.

Page 17: Document13

29

The standard frameworks ( OXF and IDF ) both allow asynchronous and synchronous communication.

If only synchronous communication is desired so that the behavior is deterministic, then triggered operations can be used instead of events.

In this case, the majority of the framework is redundant.

The Synchronous Framework is just the bare minimum framework necessary to allow the use of triggered operations.

The Synchronous Framework does not require an OS. and as such, active classes are not supported.

Timeouts and events are not supported.Has a smaller footprint than the IDF.

Synchronous framework

CPU

Rational RhapsodyGenerated Code

Exte

rnal

Code

SF Framework

Page 18: Document13

30

No framework If the framework is not required, then you can simply

set the stereotype «NoFramework» to the configuration.

Of course without the framework, there will be no code generation for active classes, ports, state charts, relations with unbounded multiplicity and so on.

This stereotype is provided in the same profile used during the CashRegister exercise.

Page 19: Document13

31

Container classes Template based containers

OMList<Concept>OMCollection<Concept>OMMap<Key,Concept>OMIterator<Concept>

Untyped containers (do not use templates)OMUListOMUCollectionOMUMapOMUIterator

MiscellaneousOMString OMBoolean

These classes are in Rhapsody\Share\LangCpp\oxf.

Page 20: Document13

32

Operating system adapter layer In order to be able to work with almost any Operating

System, Rational Rhapsody provides a thin Operating System Adapter Layer that describes the services required of an OS.

When ever the application needs to use an OS service such as creating a mutex, it does so via this adapter layer.

This gives the advantage of being able to easily interchange Operating Systems, such as being able to test on the host using Windows, then deploying on a target with INTEGRITY, VxWorks, Windows CE, OSE, Nucleus, Linux, ThreadX, QNX, pSOS …

The adapter layer is implemented using the Abstract Factory design pattern.

Page 21: Document13

33

Adapter interface

Page 22: Document13

34

NT adapter

Page 23: Document13

35

VxWorks adapter

Page 24: Document13

36

INTEGRITY adapter

Page 25: Document13

37

Nucleus adapter

OMOSSem apho reOMOSMess ageQueueOMOSThre ad OMOSMute xOMOSEve ntFlag OMOSTim e r

NuMute x NuOSMe s s ageQue ueNuOSEve ntFlag NuOSSem apho reNuThre ad NuTim e r

OMOSFacto ry

NuOSFacto ry

Page 26: Document13

38

Using the adapter For example to use a mutex:

Create an attribute of type OMOSMutex*: OMOSMutex* itsMutex; Create using : itsMutex = OMOSFactory::instance()- >createOMOSMutex();

Locking: itsMutex->lock();Unlocking: itsMutex->unlock();

If you use this method for creating event flags, mutexes, and semaphores, then it works on all OSs.