Declaratively building behavior by means of scenario clauses

Abstract

Behavior needs to be understood from early stages of software development. In this context, incremental and declarative modeling seems an attractive approach for closely capturing and analyzing requirements without early operational commitment. A traditional choice for such a kind of modeling is a logic-based approach. Unfortunately, in many cases, the formal description and validation of properties result in a daunting task, even for trained people. Moreover, some authors established some practical limitations with temporal logics expressive power. In this work, we present omega-feather weight visual scenarios ($\omega$-FVS) a declarative language, not founded on temporal logics, but on simple graphical scenarios, powerful enough to express $\omega$-regular properties. The notation is equipped with declarative semantics based on morphisms, and a tableau procedure is given enabling the possibility of automatic analysis.

Appendices

Appendix 1: Demonstration lemma on tableau states characterization

We will know prove Lemma 7.1 detailed in Sect. 7.3. This lemma relates traces of the system and states of the built automaton. In essence, the lemma says that every trace leading to a given state can be matched, at least, in one of the situations in that state. What is more, this matching is maximal

Lemma .1

(Tableau states characterization) Given a rule R: $f:A \rightarrow C, e:A^{'} \rightarrow A, e^{i}:C^{i} \rightarrow C, i \in [1..k]$ morphisms, a state S of the automaton obtained for R and a trace t leading to S, then $\exists$ a situation $\eta , \eta \in S$, including morphisms: $g_i:A^{'} \rightarrow C^{i}, i \in [1..k]$, and $\exists h: A^{'} \rightarrow t, h_i:C_i \rightarrow t (i \in [1..k])$ such that

• Condition 1: $h_i \circ g_i = h$

• Condition 2: $\forall w: A^{'} \rightarrow C^{'}, e^{'}: C^{'} \rightarrow C$, where $w,e,e^{'}$ and f satisfy conditions 1, 2, and 3 from Definition 7.1, if $\exists p: C^{'} \rightarrow t$ such that $p \circ w = h$ then $\exists i$ ($p=g_i$).

Proof

Note that the lemma is equivalent to $\forall$ trace t and $\forall$ state S such that t leads to S, condition 1 and condition 2 of the lemma hold. This is due to the fact that all the states are reachable. Thus, we will prove this formulation using an induction proof on the length of a given trace t. For the base case, we consider a trace with length = 0. We need to prove that $\exists$ a situation $\eta , \eta \in S$, including morphisms: $g_i:A^{'} \rightarrow C^{i}, i \in [1..k]$, and $\exists h: A^{'} \rightarrow t, h_i:C_i \rightarrow t (i \in [1..k])$ such that the conditions of the lemma hold. We can prove that the initial state of the automata $S^0$ is the desired state S. The initial state $S^0$ contains a situation including the empty morphism (i.e., a morphism from $\emptyset \rightarrow \emptyset$). This situation is actually the expected situation $\eta$. What is more, the empty morphism also constitutes the morphisms h and $h_i$ wanted, since t has length = 0. Therefore it can be trivially seen that $h_i \circ g_i = h$, satisfying condition 1 of the lemma. Condition 2 is also satisfied, since the only valid morphism for a trace t with length = 0 is the empty morphism, which is present in the initial state $S^0$.

Now we prove the lemma for a trace with length = n + 1, assuming that the conditions holds for traces with length = n, which constitutes the Induction Hypothesis. We will note as $t_{n+1}$ an arbitrary trace with length n + 1, and $t_{n}$ the trace $t_{n+1}$ without its last element (noted as minterm m). In order to prove the lemma for $t_{n+1}$ we need to see that $\forall$ state $S^{'}$, where $t_{n+1}$ leads to $S^{'}$, $\exists$ a situation $\eta ^{'}$, including morphisms $g_i^{'}$, such that both conditions of the lemma hold. Due to the equivalence between traces and trace scenarios (see Definition 3.7), we can see trace $t_{n+1}$ as a succession of minterms. We know by the induction hypothesis that for $t_{n} \exists$ a situation $\eta , \eta \in S$, including morphisms: $g_i:A^{'} \rightarrow C^{i}, i \in [1..k]$, and $\exists h: A^{'} \rightarrow t_{n}, h_i:C_i \rightarrow t_{n}$ such that the conditions of the lemma hold. The candidate situation $\eta ^{'}$ is the situation that the tableau algorithm builds upon $\eta$ when calculating the advances by minterm m. When obtaining successor states of state S in lines 5 and 6 of Algorithm 1, all the situations in the state are “advanced” considering all possible matches. In particular, situation $\eta$ will be considered. When advancing a situation, all its morphisms are advanced in lines 2 of Algorithms 2 and 3, considering any possible matching in the antecedent and consequents of the rule for a given minterm. That is, morphisms $g_i: A^{'} \rightarrow C^{i}$ will be advanced considering minterm m. Algorithms 2 and 3 compute advances by calculating advances in a configuration, which has been previously defined in Sect. 7.1. Let be $A ^{''}$ and $C^{''i}$ the configurations obtained through $A ^{'} \mathop {\longrightarrow }\limits ^{m} A^{''}$ and $C^{i} \mathop {\longrightarrow }\limits ^{m} C^{''i}$ respectively. Morphisms $g_i^{'} \in \eta ^{'}$ are equal to morphisms $g_i \in \eta$ for those elements $\in A ^{'}$, and for those new elements in the antecedent (those in $A^{''}$–$A ^{'}$) morphisms $g_i^{'}$ relates them to the new elements in the consequent (those in $C^{''i}- C^{i}$).

Given a state $S^{'}$ containing a situation $\eta ^{'}$ build as explained, we now build the candidates morphisms $h^{'}$ and $h_i^{'}$ upon morphisms h and $h_i$ as follows. $h^{'}(x)= h(x), \forall x \in A^{'}$ and $h^{'}(x)= n+1, \forall x \in A^{''}-A^{'}$. Note that n + 1 is the last position of trace $t_{n+1}$, which is labeled with minterm m. Similarly, $h_i^{'}(x)= h_i(x), \forall x \in C^{i}$ and $h^{'}(x)= n+1, \forall x \in C^{''i}-C^{i}$.

Now we prove that the candidates $g_i^{'}, h^{'}$ and $h_i^{'}$ satisfy both conditions of the lemma. To prove condition 1, we need to see that $h_i^{'} \circ g_i^{'} = h^{'}$. By definition, all the candidates $g_i^{'}, h^{'} h_i^{'}$ behave exactly like $g_i, h$ and $h_i$ for those elements in $A ^{'}$. We also know by the induction hypothesis that $h_i \circ g_i = h$. Therefore, we only need to prove that $h_i^{'} \circ g_i^{'} = h^{'}$ for the new elements added by the processing of minterm m. That is, for those points in $A^{''}$–$A^{'}$. We know by definition that $h^{'}$ relates these points to n + 1. Following the definition of $g_i^{'}$, we know that the new elements in the antecedent are related to the new elements in the consequent $C^{''i}$. And by definition, $h^{'}$ relates these points to n + 1. Therefore, $h_i^{'} \circ g_i^{'} = h^{'}$ and condition 1 is satisfied.

To prove condition 2 we proceed as follows. We assume that the maximality condition does not hold for $t_{n+1}$. Therefore, there exists situation $\eta ^{'}$ such that $\exists$ state $S^{'}, t_{n+1}$ leads to $S^{'}, \eta ^{'} \not \in S^{'}$. We know that the range of $\eta ^{'}$ includes minterm m, the last minterm of $t_{n+1}$. Otherwise, $\eta ^{'}$ would have been a situation for $t_{n}$, which is an absurd since by know by the induction hypothesis that the maximality condition holds for $t_{n}$. Lets considerate a situation $\eta$ that eliminates n + 1 from the situation $\eta ^{'}$. That is, it removes all the pairs that are related to n + 1. It is easy to see that $\eta$ is a situation of $t_n$. Consequently, we know by the induction hypothesis that $\forall$ state S, where $t_n$ leads to $S, \eta \in S$. However, since the algorithm advances all possible situations in each state, $\eta ^{'}$ would have been included in one of the successors of S when calculating the processing of minterm m. This contradicts our assumption, so we are forced to conclude that the maximality conditions hold for a traces $t_{n+1}$, and condition 2 is satisfied. Since both conditions hold, the lemma is demonstrated. $\square$

Appendix 2: .NET NegotiateStream protocol example modeled in $\omega$-FVS

In this appendix we model the behavior of the client and the server of the .NET NegotiateStream protocol following its specification document [36]. The modeling assumptions described in Sect. 6.3 also apply to this appendix.

2.1 Client behavior modeled in $\omega$-FVS

The most important sections of the specification document describing the client behavior are: section 3.1.4 Higher-Layer Triggered Events and section 3.1.5 Message Processing Events and Sequencing rules. The first one includes the subsections 3.1.4.1 Application Invocation of the .NET NegotiateStreamProtocol, 3.1.4.2 Application Request to Send Data, and 3.1.4.3 Application Request to Close Stream. The second one includes different subsections focused on the information exchanged over the different states of the stream: section 3.1.5.1, which is focused on the CreatingSecurityToken state, section 3.1.5.2, which is focused on the WaitingForHandshakeMessage state, section 3.1.5.3, which is focused on the ProcessingFinalToken state, section 3.1.5.4, which is focused on the WaitingForHandshakeDone state, and finally section 3.1.5.5, which is focused on the Authenticated state. In what follows we describe the client’s behavior.

We start with three requirements extracted from the Application Invocation of the .NET NegotiateStreamProtocol stage:

• Initial requirement: Uninitialized is the initial state of the stream.

• R1: If an application invocation is received when the stream state is not equal to Unitialized, an error must be returned to the application.

• R2: If the function returns GSS_S_Complete the implementation must set the stream state to CreatingSecurityToken.

The rules in Fig. 33 model these requirements. As mentioned before, we use the event AnyOtherStreamState to represent the disjunction of all the others state events apart from the ghost event mentioned in the rule. For the rules in Fig. 33 the event AnyOtherStreamState its representing any other state than Uninitialized. More concretely, the rule at the top of the figure addresses the initial requirement: the Uninitialized state must be the initial state. The second rule addresses requirement R1, specifying that an ERROR event should occur if the application is invoked in an invalid state. The rule at the bottom of the figure tackles requirement R2. When the GSS-API returns the GSS_S_Complete value, the stream enters the CreatingSecurityToken state.

Fig. 33

Rules modeling the initial state and requirements R1 and R2

Similar to requirement R1, requirement R3 says the data transmission can only start, while the stream state is in the authenticated state. This requirement belongs to the Application Request to Send Data stage and it is shown in Fig. 34:

• R3: If the application requests data to be transferred while not in the Authenticated state, an error must be returned.

Fig. 34

Rules modeling requirement R3

The last subsection of the Sect. 3.1.4 Higher-Layer Triggered events deals with the application request to close a stream. This is described in requirement R4 (shown in Fig. 35 ). Since the application can, at any time request that the stream to be closed, be use the event AnyStreamState to represent the disjunction of all possible states of the stream.

• R4: When a request to close the stream is received, the stream state must be set to Closed. The application can at any time request that the stream be closed.

Fig. 35

Rule modeling requirement R4

We now describe the behavior of the client as detailed in section 3.1.5 Message Processing Events and Sequencing rules of the specification document.

2.1.1 Message processing events and sequencing rules: client side

The following requirements deal with the message processing events and sequencing rules while the stream state is CreatingSecurityToken, as detailed in section 3.1.5.1 of the specification document. In this case, the GSS-API returns any of three possible outcomes: ERROR, to report that an error has occurred, GSS_S_Complete to indicate the end of the negotiation, or GSS_S_Continue_Needed to indicate that further negotiation is needed. The rule in the top of Fig. 35 describes these assumptions. Requirements R5, R6, and R7 handle the expected behavior for any possible outcome value.

• R5: If the GSS_Init_sec_context returns a status of GSS_S_Complete, the stream state must be set to WaitingForHandshakeDone.

• R6: If the GSS_Init_sec_context returns a status of GSS_S_Continue_Needed, the stream state must be set to WaitingForHandshakeMessage.

• R7: If the GSS_Init_sec_context returns a status of ERROR, the stream state must be set to Uninitialized.

Rules in Fig. 36 model requirements R4, R5 and R6. The first rule describes the possible outcomes using three different consequents (one for each option), and the rules below that one reflect the expected change of state.

Fig. 36

Rules modeling requirements R5, R6, and R7

The requirements extracted from the section 3.1.5.2 of the specification document, which is focused on the WaitingForHandshakeMessage state, are described next and shown as rules in Fig. 37.

• R8: Upon the receipt of a message HandshakeInProgress, the stream state must be set to CreatingSecurityToken.

• R9: Upon the receipt of a message HandshakeDone, the stream state must be set to ProcessingFinalToken.

• R10: Upon the receipt of a message of ERROR, the stream state must be set to Closed.

Fig. 37

Rules modeling requirements R8, R9, and R10

Section 3.1.5.3 of the specification document focuses on the ProcessingFinalToken state. In this case, if the GSS-API returns a value of GSS_S_Complete, this indicates that the negotiation succeeded and the stream state enters the Authenticated state so that data transmission can be initiated. Otherwise, the stream state is set to Uninitialized. These are requirements R11 and R12, which are shown in Fig. 38.

Fig. 38

Rules modeling requirements R11 and R12

We now model requirements extracted from section 3.1.5.4, focused on the WaitingForHandshakeDone state of the specification document. These requirements (requirements R13 and R14) involve the end of the negotiation, either because a HandshakeDone event has been received (indicating that the negotiation is over and data transmission can begun) or because an error has occurred.

• R13: If the message has a handshakeId of HandshakeDone, the stream state must be set to Authenticated.

• R14: If the message has a handshakeId of ERROR, the stream must be set to Closed.

Rules in Fig. 39 reflect the expected behavior denoted in requirements R13 and R14.

Fig. 39

Rules modeling requirements R13 and R14

Finally, the client behavior is completed with section 3.1.5.5 Receiving Data in the Authenticated state of the specification document. Requirement R15 says that stream state keeps the Authenticated state while data are being transmitted (represented by the eventsSendData and ReceiveData). The rule for this requirement is shown in Fig. 40.

Fig. 40

Rules modeling requirement R15

2.2 Server behavior modeled in $\omega$-FVS

Section 3.2 Server details of the specification document describes the behavior of the server. Regarding the server’s perspective, the possible states for the stream are: Uninitialized, CreatingSecurityToken, WaitingForHandshakeMessage, ProcessingFinalToken, Authenticated, and Closed. Section 3.2.4 Higher-Layer triggered events of the specification document describes how the server may be invoked, when it can transfer data, and when it accepts to close the stream. These behavior is covered by subsections 3.2.4.1 Application Invocation, 3.2.4.2 Application Request to Send Data, and 3.2.4.3 Application Request to Close Stream. In what follows, we introduce several rules in our language to model each one of them.

Three requirements can be extracted from the section 3.2.4.1 Application Invocation. Those are:

• R16: Uninitialized is the initial state of the stream.

• R17: If an application invocation is received when the stream state is not equal to Unitialized, an error must be returned to the application.

• R18: If the function returns GSS_S_Complete, the implementation must set the stream state to WaitingForHandshakeMessage.

Rules in Fig. 41 exhibit the expected behavior of requirements R16, R17 and R18.

Fig. 41

Rules modeling requirements R16, R17, and R18

Section 3.2.4.2 Application Request to Send Data of the specification documents introduces requirement R20, which is modeled in the rule of Fig. 42:

• R19: If the application requests data to be transferred while not in the Authenticated state, an error must be returned.

Fig. 42

Rules modeling requirement R19

Finally, 3.2.4.3 Application Request to Close Stream details how and when a request to close the stream can be issued. This introduces requirement R20, which is described next and shown in the rule of Fig. 43.

• R20: When a request to close the stream is received, the stream state must be set to Closed. The application can at any time request that the stream be closed.

Fig. 43

Rule modeling requirement R20

2.3 MessageProcessing events and sequencing rules: server side

Section 3.2.5 MessageProcessing Events and Sequencing Rules of the specification document describe how the server’s state evolves. This section includes four subsections: 3.2.5.1 WaitingForHandshakeMessage State, 3.2.5.2 CreatingSecurityToken State, 3.2.5.3 ProcessingFinalToken State and 3.2.5.4 Authenticated State. In what follows, we model each one of them.

Three requirements can be extracted from section 3.2.5.1 WaitingForHandshakeMessage State of the specification document. Those are:

• R21: Upon the receipt of a message HandshakeInProgress, the stream state must be set to CreatingSecurityToken.

• R22: Upon the receipt of a message HandshakeDone, the stream state must be set to ProcessingFinalToken.

• R23: Upon the receipt of a message of ERROR, the stream state must be set to Closed.

Rules in Fig. 44 reflect the behavior for requirements R21, R22, and R23.

Fig. 44

Rules modeling requirements R21, R22, and R23

Fig. 45

Rules modeling requirements R24, R25, and R26

Section 3.2.5.2 CreatingSecurityToken State of the specification document introduces three new requirements. Those are:

• R24 If the GSS_Init_sec_context returns a status of GSS_S_Complete, the stream state must be set to Authenticated.

• R25: If the GSS_Init_sec_context returns a status of GSS_S_Continue_Needed, the stream state must be set to WaitingForHandshakeMessage.

• R26: If the GSS_Init_sec_context returns a status of ERROR, the stream state must be set to Uninitialized.

Rules in Fig. 45 model requirements R24, R25, and R26. The first rule describes the possible outcomes using three different consequents (one for each option), and the rules below that one reflect the expected change of state.

Fig. 46

Rules modeling requirements R27 and R28

Fig. 47

Rules modeling requirement R29

Section 3.2.5.3 ProcessingFinalToken State of the specification document introduces two new requirements (shown in Fig. 46). Those are

• R27 If the GSS_Init_sec_context returns a status of GSS_S_Complete, the stream state must be set to Authenticated.

• R28: If the GSS_Init_sec_context returns a status of ERROR, the stream state must be set to Uninitialized.

Finally, section 3.2.5.4 of the specification document deals with the information exchanged in the Authenticated state. This behavior is analogs to that presented when modeling the client: The stream state keeps the Authenticated state, while data are being transmitted (represented by the eventsSendData and ReceiveData). The rule for this requirement (R29) is shown in Fig. 47.

2.4 Translation of $\omega$-FVS rules into Büchi automata

We now conclude this appendix showing a simplified version (in not showing accepting states) of the automata generated using the tableau algorithm described in Sect. 7. Figure 48 shows the automaton describing the behavior of the client, whereas Fig. 49 reflects the behavior of the server. In order to favor readability, ghosts events are shown in italics, whereas actual events are not.

Fig. 48

The automaton built by the tableau for the client behavior

Fig. 49

The automaton built by the tableau for the server behavior