The following rules must be obeyed for processing an UML model with TismTool:
- In protocols, an interface function can be used as trigger for a
transition. In design FSMs, a triggering function must be preceded by a
port name and delimited by -> . For example, pp_control->Start(),
where pp_control is a (provided) port of a component.
- In a protocol, one class has a client role and the other class has
a server role (see ). In the PSM (Protocol State Machine) of the server
the triggering functions in transitions have Event Type CallEvent, whereas in the PSM of the client triggering callback-functions in transitions have Event Type SignalEvent.
- The activity of a transition is implemented in the Effect section, with the Behavior Type equal to OpaqueBehavior.
- The name field of an element/section can be used for specifying
triggers or activities (i.e. source code). The reason for this peculiar
rule is that the entered text will be visible in a state machine
- Guards are used to enable choices in decision logic. In
specifications such as Protocol State Machines informal text suffices
to model choices. For the purpose of verification / simulation TismTool
generates source code for PSMs in modeled protocols. The informal
guards are replaced by functions returning false or true. TismTool
recognizes an informal guard when it begins and ends with a double
quote, e.g. "high temperature".
- TismTool detects the usage of the proxy mechanism from proxy components applying stereotypes ProxyOk and ProxyNok, and from proxy user components applying IsProxyOk and IsProxyNok .
At choice pseudostates of proxy users including both stereotypes
(IsProxyOk and IsProxyNok) is of course allowed. However, designing a
single stereotype in combination with a guard representing an else
clause is a best practice. Such an else guard is simply realised by a
constraint having the text else (without double quotes!).
- A pair of a proxy component and its proxy user must be modeled in the same thread.
- A package describing a protocol must have stereotype TismProtocol.
- Each parameter of a triggering function must be defined in the
protocol class using the interface of that function. (Otherwise compile
errors will make it clear to you.)
- The 2 stereotypes HasMutex and HasThread can not be assigned to a
component at the same time. A subcomponent may not be protected by one
of the above stereotypes, when its (super)component is already