Activity 14: Define component and add functional constraint
|
Extend the file VendingMachine.component with the following text (you may copy the text below):
functional constraints
OperationalConstraintInsertCoin {
/* InsertCoin Command of IUser returns NOT_OPERATIONAL
* when IService is not in state Operational
* Otherwise it returns ACCEPTED or NOT_ACCEPTED
*/
use events
command vmUserPort::InsertCoin
vmUserPort::reply to command InsertCoin
initial state CoinReply {
transition trigger: vmUserPort::InsertCoin(int val)
guard: NOT vmServicePort in Operational
do:
vmUserPort::reply (*,CoinResult::NOT_OPERATIONAL)
next state: CoinReply
transition trigger: vmUserPort::InsertCoin(int val)
guard: vmServicePort in Operational
do:
vmUserPort::reply (*,CoinResult::ACCEPTED)
next state: CoinReply
OR
do:
vmUserPort::reply (*,CoinResult::NOT_ACCEPTED)
next state: CoinReply
}
}
Improve the lay-out using <CTRL>-<SHIFT>-F.
This specification assumes that interface IService has a state called Operational to represent that the machine is on and not in an error. Replace it with the state name of your model.
The functional constraint restricts the reply to command InsertCoin as indicated in the use events part. The specification expresses that when a reply to InsertCoin occurs, one of the following cases should hold:
-
the state machine of the vmServicePort in not in state Operational and the result is NOT_OPERATIONAL, or
-
the state machine of the vmServicePort in in state Operational and the result is either ACCEPTED or NOT_ACCEPTED.
To monitor the component constraints, change the file VendingMachine.prj as follows:
-
Import VendingMachine.component
-
Remove the current monitoring tasks
-
Add the following monitoring task:
Generate Monitors { monitoring for component VendingMachine { trace directories "VendingMachineEventsFiles" } }
Component monitoring checks the components constraints and all interfaces of the component.
Run monitoring and inspect the dashboard with the results in folder comma-gen.