rhapsody in c++ tool training "essential" © i-logix 1999-2000 v3.0 1/29/2001 adv-1...

Rhapsody in C++ Tool Training "Essential" © I-Logix 1999-2000 v3.0 1/29/2001Adv-1

Section 4

Advanced LevelConcurrency


Code Generation Per Package• Generated code for each package can be

directed into separate directories:


Concurrency

• We want each Sensor to run on its own thread (active class).

• To do so, we need each Sensor to be Reactive (class that waits for events).

• So we will create a Statechart for the base Sensor class as follows:


Active Classes

• With the browser, change the concurrency of the Sensor class from sequential to active.


Inheriting Behavior

• Open the Statecharts for the PressureSensor and TemperatureSensor. Note that they have inherited the base class Statechart.

• Specialize the behavior of the TemperatureSensor as below:

Grayed out indicatinginherited behavior


Starting the Behavior

• Add a call to startBehavior() from the TemperatureSensor and PressureSensor constructors to initialize the statecharts.

If we had used a composite class, Rhapsody would have done this for us, but that would have been too easy !


Multi-threads

• Save / Generate / Make / Run• Check that there are four active threads.• Setting the focus to a particular thread displays

the call stack and event queue for that thread.

There will always be one thread called mainThread.


Suspending Threads

• Note that a thread can be suspended.


Extended Exercise I

• Add two new operations to the Motor class• deleteSensor & addSensor


Extended Exercise II

• Modify the Motor Statechart to add two static reactions in state for evAdd and evDelete.


Extended Exercise III

• Save / Generate/Make/Run• Inject events evAdd and evDelete• Note that threads are created & deleted.


Extended Exercise IV

• Try adding a SpeedSensor that is a new type of Sensor.


Problems with the Design

• With the current design there are a few potential problems:– The Motor class needs to know about all

the different types of Sensor.– If another class wants access to the

Sensors, it too will need to depend upon all the different types of Sensor.

– Starting the behavior of a Sensor, in the constructor is not very elegant.

– Adding a new type of Sensor means finding and modifying all classes that use Sensor.


Improving the Design• Using the “factory method design pattern” will

solve all these concerns.• A SensorFactory class can be introduced that is

used by all classes ( ex: Motor ) that need to get a Sensor. This decouples the Motor class from the actual Sensors and can also start the behavior of the Sensors.

• The SensorFactory will be implemented using the “Singleton design pattern” (to ensure that there is only one instance of SensorFactory).

See the “SensorFactory” example.


The Improved Design


The Singleton Design Pattern I

Protectedconstructor

Static attribute


The Singleton Design Pattern II

Static factoryoperation

Calling thecreateRandomSensor

operation


More Design Improvements• In all the constructors of the sensors passing a

string by value is not very efficient, it would be better to pass a reference to a string.


Setting Priority, Stack Size, ...

• For an active class, the stack size, priority, name, etc can be set through the following properties:

rhapsody in c++ tool training "essential" © i-logix 1999-2000 v3.0 1/29/2001 adv-1...

Documents

base sensor class

inherited behavior slide

thread active class

reactive class

composite class

new type of sensor

base class statechart

different types of sensor