Modeling Rules

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 diagram.
• 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 protected.