Sample sequence diagram
In this section, we present an interesting example that represents an abstracted model for an Automated Teller Machine (ATM) system. Also, whenever two or more messages are being sent in parallel (thus part of the same configuration in the transition system), a comma is separating them. For readability reasons, we have by convention each message label starts with the sender actor and terminates with the receiving one.
#Sample sequence diagram series
The interpreted result of the trace provided by the model-checker consisted in the following path in the CTS: The identified path contains a series of messages (semi- colon separated) that are exchanged between the actors. However, the model-checker was able to produce a coun- terexample for the third user specified property. The first one asserts that it is always the case that if A is sending a request to D, then there should be case where a corresponding grant will be sent from D to A: The second one asserts that it is always the case that if D is sending a grant message to A, then it should be possible for H to deliver to A at the next step: The third one is stating that it is always the case that if A is canceling the request to D, then the system may not reach the point where the handler H is sending to A: When subjecting the sequence diagram to our V&V tool, we found that only the first two properties are satisfied. We have the following properties presented in both simplified macro notation along with their corresponding CTL notation. For the presented sequence diagram, we present some relevant properties that reflect the intended interactions.
#Sample sequence diagram manual
Thus, we will exemplify the usage of manual specification of properties. For the sequence diagram, we are mainly interested in the manual property specification as aside from deadlock and reachability, one can not infer automatically the required properties to be verified. The corresponding CTS is depicted in Figure 3. In order to construct it, we first explore all possible execution paths of the diagram. In order to assess the diagram, we convert it to a cor- responding semantic model which is a kind of a transition system (configuration system) wherein the elements represent sets (possibly singleton) of interaction messages. In the second case, H is sending a busy message to D, followed by the refuse message from D to A. The second group of messages is composed of an alternative between two other cases: in the first case, H is sending to D an accept message in parallel with a self processing message, followed by a grant message that D is sending to A and a subsequent de- livery message from H to A. The first group is composed of an alternative between two cases: in the first case, A is sending itself a wait message in the second case, A is sending to D a cancel message, followed by a canceling message of the dispatched request from D to H. Subsequently, we have the parallel composition of two groups of messages. After receiving the request, D is acknowledging A while dispatch- ing at the same time (in parallel) the request to the handler (H). The envisioned interaction is as follows: the requestor (A) is sending a request to the dispatcher (D). The actors are the requestor, the dispatcher, and the handler. The diagram encompasses three actors inter- acting in order to accomplish an arbitrated request/delivery service.
Wide borders styles with css could generate unwanted clipping which is why this config param exists.Figure 3 shows a sample sequence diagram that we use as case study. Turns on/off the rendering of actors below the diagram as well as above itĪdjusts how far down the graph ended.