Monday, 3 August 2020
IBM Rational Rhapsody Tip #81 - Understanding actor test benches (intermediate)
I did this tips and tricks video in response to a few questions that people have asked as to whether they should tick the box to generate code for use case and generate code for actors? To answer this you need, of course, to understand better what you're doing when it comes to system simulation.
In this video I look at the concept of actor test benches. An actor test bench is part of a simulation that plays the role of an actor. By including the actor in a higher level system, you can show the interactions that is has with named external entities, rather than with the system border. In Rhapsody, this is possible because actors have full classifier status, i.e. they can have ports, operations, event receptions (signals), and state machines, in the same way as blocks do. This is one of my silent videos (it takes longer to create videos with sound, hence I need to balance my time with paid work).
Note: This is not the case for all UML/SysML tools.
This is the transcript:
Rhapsody’s code generator is used for both software (embedded C++/C) and systems engineering simulation.
Occasionally I get asked what the checkbox means to generate code for actors and generate code for use cases. In this short video I will attempt to explain it by creating a simple simulation model.
The first thing to note is that Actor and Use Case are types Classifier in Rhapsody. This means that they can have operations, attributes/value properties and state behavior just like Blocks.
Use Cases can therefore be placed sequence diagrams and used in the same way as if they were a Blocks, e.g., receiving signals or sending events or invoking operations. They could also own state or activity-based behaviors.
This should answer the first question, which is why one would tick the box to generate code for use cases?
Of course, if you do this then you need to treat the Use case as if it were a Block being used for simulation, i.e., set the name as legal as I’m doing here by changing its name to Camel case.
Now I can simulate the behavior of the use case by injecting events and see the changes in state on the animated sequence diagrams. The Government actor here. However, is not sown as injecting the event but I could drag a System Border on to show that the event is coming from outside the use case classifier.
Suppose, that I want to show the event as coming from the actor?
Well, this is where the concept of what is conventionally called an Actor test bench comes in.
Let’s create a build that includes the actor and the use case.
I’ll connect them for now, using rapid ports. Rapid ports are ports that have no interfaces. They can be used for building simulations quickly.
An actor test bench is one that has its own behavior, typically described using a state machine. We’ll get this statechart to send a antibody test event to the port, whenever it receives it as a trigger. We’ll do the same for the test invalidated event.
These are both reactions in state as no state change is needed.
Now, instead of building a simulation of the use case, I’m going to build a simulation of the test bench and it’s owned elements.
In this instance, I need to make sure that generate code for actors is checked.
The Government actor is now bold in the browser. This means that it is in the scope of the build, so I’ll regenerate and build the application.
In this simulation, the Actor test bench is now in scope and has it’s won state-based behavior. I can stimulate the simulation by getting the actor to generate the event on the use case.
Of course, it’s possible for the actor to have more than simple forwarding behavior. However, the approach shown here is the basis for how testbenches were designed to work with the Hamrony/SE toolkit.
This answers the question as to why one might check the boxes to generate code for actors and use cases?
Hopefully, that helps. If you need any more help, or want to discuss hands-on tool-based training options tailored to your company then let me know.