2.1 Extensional sets, relations and functions

The term $\{x/A\}$ is called extensional set; the empty set is denoted by $\{\}$ . These are the basic constructors for sets; they can be arguments to all classic set operators – union, intersection, cardinality, etc. Set operators are provided as constraints. For example, un(A,B,C) denotes $C = A \cup B$ , inters(A,B,C) denotes $C = A \cap B$ , and diff(A,B,C) denotes $C = A \setminus B$ . Then, we can compute the union of two sets even when they are partially specifiedFootnote ⁴ :

where X nin A denotes $X \notin A$ and X neq 3 denotes $X \neq 3$ – note that a is a constant, not a variable.

The constraint size(A,N) denotes $|A| = N$ , that is set cardinality. The first argument can be an extensional set or the empty set; the second one can only be a variable or an integer number, but it can participate in integer constraints. Hence, $\{log\}$ can compute the solutions (or lack thereof) of:Footnote ⁵

In $\{log\}$ a binary relation is just a set of ordered pairs. The ordered pair $(x,y)$ is written [x,y]. $\{log\}$ provides all the operators of set relation algebra in the form of constraints. Then, for example, comp(R,S,T) denotes composition of binary relations ( $T = R; S$ ) and inv(R,S) denotes the converse (or inverse) of a binary relation $(S = R^\smile$ ). Cartesian product is also available: cp(A,B) denotes the set $A \times B$ . Extensional sets and the empty set can be arguments to all relational operators and Cartesian product.

By combining set and relational operators it is possible to define a number of other useful operators. In this way, $\{log\}$ provides constraints for the domain and range of binary relations, domain and range restriction, relational image and the widely used ‘update’, ‘overriding’ or ‘oplus’ operator – denoted $\oplus$ in Z and $\mathbin {{\lhd } \llap {+\!\!}\;}$ in B.

Functions are a subclass of binary relations – that is functions are sets of ordered pairs. The constraint pfun(F) states that the binary relation F is a function. $\{log\}$ provides two notions of function application: if pfun(F) holds then apply(F,X,Y) is satisfied iff $X \in dom(F) \land F(X) = Y$ ; in turn, applyTo(F,X,Y) denotes $\{(X,X)\}; F = \{(X,Y)\}$ , for any binary relation $F$ . That is, applyTo(F,X,Y) is true if F is a binary relation containing exactly one pair whose first component is X and whose second component is Y– meaning that F is not necessarily a function.

Given that relations and functions are sets, they can be combined and passed as arguments to all the classic set and relational operators.

2.2 Integer intervals and restricted intensional sets

Two more set terms are available in $\{log\}$ . Terms of the form int(m,n), with both arguments either variables or integer numbers, denote integer intervals – that is sets of the form $[m,n] \cap \mathbb{Z}$ . Interval limits can participate in integer constraints. Intervals can be arguments to all the classic set operators including cardinality – but in general they cannot be passed as arguments to relational operators. In this way $\{log\}$ is able to compute solutions (or lack thereof) for goals such as:

Finally, $\{log\}$ provides a set term, called Restricted Intensional Set (RIS), denoting set comprehensions of the form $\{x \in A: \phi (x)\}$ where $\phi$ is some formula depending on $x$ . For instance, the set $\{x \in A \mid 3x + 2 \geq 0\}$ is encoded in $\{log\}$ as the term ris(X in A, 3*X + 2 $\texttt{\gt=}$ 0), where A can be an extensional set term or another RIS. RIS have a more expressive and complex structure that we are not going to show here. RIS terms can only be used as arguments of classic set operators not including cardinality – they cannot be passed as arguments to relational operators.

2.3 Negation

Negation in $\{log\}$ is a delicate matter as it is in logic programming in general (Apt and Bol Reference Apt and Bol1994). The problem with negating a $\{log\}$ formula is that its result may not be a $\{log\}$ formula. Consider the following alternative implementation of $smin$ (1):

Note the presence of Max, an unbound variable making part of the body but not of the predicate’s head. This is an existential variable. Thus, the negation of smin2 requires the introduction of a (unrestricted) universal quantification over Max, that is:

(4) \begin{equation} \forall Max(\lnot (M \in S \land S \subseteq [M,Max])). \end{equation}

The problem is that $\{log\}$ does not admit (unrestricted) universal quantification, meaning that (4), as it is, cannot be encoded as a $\{log\}$ formula. That does not mean that there is no $\{log\}$ formula encoding the negation of smin2. Actually, the following is such a formula:

(5) \begin{equation} M \notin S \lor X \in S \land X \lt M \end{equation}

were $X$ is an existential variable. The point is that, in general, neg(smin2) cannot be automatically computed. Fortunately, in the case of $smin$ , since its encoding with smin in (2) contains no existential variables, $\{log\}$ is able to automatically compute neg(smin):

(6) \begin{equation} \lnot (M \in S \land \forall X \in S: M \leq X) \equiv M \notin S \lor \exists X \in S: X \lt M \end{equation}

where the right-hand side predicate is encoded in $\{log\}$ as:

Now consider the following $\{log\}$ predicate:

where dom(R,D) encodes the domain of relation R, i.e., $dom(R) = D$ . Clearly, property introduces two existential variables (Dr and Ds) thus making it impossible to use neg to compute its negation. However, the nature of these variables is different from Max in the $smin$ example. Here, these variables define the domain of R and S. In other words, Dr and Ds are sort of names for the expressions $dom(R)$ and $dom(S)$ . This means that the negation of property is not:

(7) \begin{equation} \forall Dr,Ds(dom(R) \neq Dr \lor dom(S) \neq Ds \lor Dr \not \subseteq Ds) \end{equation}

It makes no sense to state $dom(R) \neq Dr$ for all $Dr$ because it would mean that the domain of $R$ does not exist. For cases like this $\{log\}$ provides the Let predicate (Cristiá and Rossi Reference Cristiá and Rossi2024d, Sect. 5):

Let is interpreted as follows:

where $x_i$ are variables, $e_i$ terms such that $x_i$ does not occur in $e_i$ and $\phi$ is a formula. Therefore, negating property(R,S) proceeds as follows:

where the rightmost formula can be encoded in $\{log\}$ as follows:

The Let predicate allows us to use neg for a whole class of formulas for which, otherwise, negation would have needed human intervention. In summary, neg( $P$ ) is safe provided $P$ does not contain existential variables.

2.4 Restricted quantifiers

We have already introduced RQ in $\{log\}$ . We have seen foreach (restricted universal quantifier, RUQ) and exists (restricted existential quantifier, REQ), in the previous sections. Here we discuss them a little more deeply. First of all, RQ in $\{log\}$ are at least as expressive as set relation algebra (Cristiá and Rossi Reference Cristiá and Rossi2024d, Sect. 4.3), in part, due to the following characteristics. First, RQ admit quantification terms rather than simply variables. For example:

states that all the elements of R of the form [X,Y] must verify X is Y $\texttt{+}$ 1. As [X,Y] denotes an ordered pair, then R is expected to be a binary relation.

Second, RQ can be nested. For instance:

is equivalent to the following nested RUQ:

Third, a bound variable can be used as quantification domain in an inner RQ:

(8)

That is, the elements of the range of R are expected to be sets – due to the set membership constraint V in Y.

The introduction of REQ in the language deserves a special note. Since logic programming allows for the introduction of existential variables, the presence of REQ might seem unnecessary, but it is not. REQ help in further extending the fragment of the language where negation can be easily computed. Consider the following simple predicate:

The negation of p cannot be easily computed due to the presence of X, an existential variable. However, p can be written in terms of a REQ preserving its meaning while exchanging an existential variable for a bound one:

Now neg(p(S)) can be easily computed:

(9) \begin{equation} \lnot p(S) \equiv \lnot (\exists X \in S: X \gt 0) \equiv (\forall X \in S: \lnot (X \gt 0)) \equiv (\forall X \in S: X \leq 0) \end{equation}

where the rightmost predicate is written in $\{log\}$ as: foreach(X in S, X $\texttt{=\lt}$ 0).

2.5 Types

Rooted in Prolog, $\{log\}$ provides essentially an untyped language based on untyped FOL and untyped set theory. In this way, a set such as $\{1,a,(3,b),\{x,q\}\}$ is perfectly legal in $\{log\}$ . Untyped formalisms are not bad in themselves but types help to avoid some classes of errors (Lamport and Paulson Reference Lamport and Paulson1999). For this reason, we recently defined a type system and implemented a typechecker as a $\{log\}$ component (Cristiá and Rossi Reference Cristiá and Rossi2024b).

Users can activate/deactivate the typechecker according to their needs. The type system defines basic or uninterpreted types, types for integers and strings, sum types,Footnote ⁶ Cartesian products, and set types – in this sense, the type system is similar to those used in B and Z. Set and relational operators are polymorphic. Users must declare the type of user-defined predicates. We will see more about types in Section 3.

2.6 Undefinedness

In B and Z, undefinedness arises whenever a partial function is applied to an argument that does not belong to the domain of the function. In turn, undefinedness may lead to inconsistencies. In those notations undefinedness is solved by requesting proof obligations guaranteeing that the argument belongs to the domain of the partial function.

In $\{log\}$ undefinedness is less pervasive because function application becomes a predicate rather than a term, as shown in Section 2.1. In effect, if X does not belong to the domain of F, apply(F,X,Y) is simply unsatisfiable. In other words, function application cannot remain undefined: it is either satisfiable or unsatisfiable. Same considerations hold for applyTo.

Another situation for undefinedness is division by zero in integer arithmetic. In this case B and Z requires to prove that $y \neq 0$ whenever $x \mathbin {\mathtt {div}} y$ is in context. In $\{log\}$ this situation does not occur given that it only supports linear integer arithmetic which rules out expressions such as $x \mathbin {\mathtt {div}} y$ . Whenever $\{log\}$ tries to solve a predicate including such a term an exception is raised.

In summary, in $\{log\}$ function application does not lead to inconsistencies.

3.1 Model parameters, axioms and user-defined theorems

The state machine specification language also supports parameters, axioms and user-defined theorems (Rossi and Cristiá Reference Rossi and Cristiá2025, Section 13.1.1). Parameters play the role of machine parameters and constants in B specifications and the role of variables declared in axiomatic definitions in Z. That is, parameters serve to declare the existence of some (global) values accessible to invariants and operations, but they cannot be changed by operations – that is there is no next-state value for a parameter. Axioms are used to state properties of parameters. User-defined theorems are used to state properties that can be deduced from axioms, invariants, operations or theorems that have already been declared.

3.2 Typing state machines

So far we have paid no attention to types in the specification. However, users can, but are not forced to, add typing information to each predicate (invariants, operations, etc.) declared in the specification to avoid some classes of errors. Here we type remind just as an example.

The $\mathtt {dec\_p\_type}$ declaration provides the type for remind. The term remind(rel(name, date),date,set(name)) declares the type of each argument of the operation. For instance, rel(name,date) is the type of Birthday, date is the type of Today, and so on. The type of M is given by an explicit type declaration, dec(M,rel(name,date)). In turn, name and date are basic or uninterpreted types; rel(name,date) is the type of all binary relations with domain in name and range in date; and set(name) is the type of all sets whose elements are of type name. If t is a basic type then its elements are of the form t: $\langle elem \rangle$ , where $elem$ is any Prolog atom or natural number.

4.1 The NEXT environment

NEXT is a component tightly integrated with $\{log\}$ that simplifies the execution and analysis of deterministic, fully instantiated functional scenarios. Although NEXT is less general than the approach shown in the next section, it considerably eases the job of users. For example, we can add a person’s name and birth date when the system is in its initial state, as follows:

initial refers to the predicate declared as such in the specification; $\texttt{\gt\gt}$ (read then) imposes a sequential order in the execution. $\{log\}$ automatically fetches state variables when calling an operation; users need to indicate values only for the input variables (e.g., Name:alice).

With NEXT it is easy to add more people to the system:

In fact the above call is equivalent to the following one:

As can be seen, NEXT automatically chains the after-state of an operation with the before-state of the next one thus relieving users from having to introduce new variables to get each state of the system.

More operations can be called by using $\texttt{\gt\gt}$ to execute more complex scenarios. Moreover, the execution trace of the scenario can be analyzed by enclosing the initial state between square brackets, as follows:

in which case the full state trace is shown as follows:

The execution starts from the initial state (Known $\texttt{=}$ {}, Birthday $ \texttt{=}$ {}), then Alice’s birthday is added thus arriving to the state given by Known $\texttt{=}$ {alice}, Birthday $\texttt{=}$ {[alice,may24]}. Afterwards, Bob’s birthday is added to the book and finally we call for the set of people whose birthday is May, 24. In this case the answer is Cards $\texttt{=}$ {alice} and we can also check that remind does not change the state of the system.

Whenever NEXT cannot fully determine the next state or an output value, an error message is issued.

Since there is no value bound to Name the next state of the system remains underspecified making NEXT to issue an error. This helps users to analyze the behavior of the system in situations similar to the real usage.

NEXT also performs invariant checking after each step of an execution. Users can indicate the invariants to be checked by appending a list with their names to the initial state. For example: [initial]:[domBirthday] would make NEXT to check domBirthday after each step of a scenario. If an invariant is not satisfied after a given step, then NEXT informs the user of the situation. This, in turn, provides valuable information on the correctness of the specification.

4.2 Symbolic executions

$\{log\}$ can perform symbolic executions too (King Reference King1976). That is, we can execute the prototype by providing some variables instead of constants as inputs – or a mixture of both. In this way we can draw more general conclusions about the specification. In this case, though, we cannot use NEXT because it requires variables involved in the scenario to be completely instantiated. Actually, in symbolic executions we need to analyze the constraints returned by $\{log\}$ . The following scenario analyses how remind responds to a call where Birthday has at least two equal dates in its range:

We have deliberately cut out the list of constraints returned by $\{log\}$ to simplify the exposition. pfun({[X,Y],[Z,Y]/B}) restricts the set to be a function, thus forcing X neq Z. Then, the names returned by remind include X and Z, plus some set $\mathtt {\_N1}$ . The constraints state that $\mathtt {\_N1}$ is the domain of $\mathtt {\_N5}$ , a subset of B, whose range contains only Y. That is, Names contains the right names and nothing else.

Clearly, this kind of answers is harder to analyze than the answers given by NEXT although the former yield more general results. To help during the symbolic analysis of the system users can combine it with ground solutions. For example, the answer to the above scenario when executed in groundsol mode (Section 2) is the following:

We can see that Names contains just the values of X and Z, thus coinciding with the above analysis.

Another scenario that can be analyzed is given by Birthday being a constant function:

Note that in this case W, not Y, is the second argument passed in to remind. We will analyze only two solutions: (i) Obtaining the reminders for date Y, which ensures that at least X and Z are contained in the list of names; and (ii) Obtaining reminders for any other date, which will result in an empty set of names. For the first solution $\{log\}$ returns the following:

As can be seen, in this solution W = Y and Names includes X and Z plus some set N1. As above, N1 is the domain of N5, a subset of B, whose range contains only Y. Note that the rest of B, N4, has a range not containing Y. That is, N4 and N5 are a partition of B. The second solution is the following:

In this case, Y neq W which, along with the fact that Y is the only element in the range of Birthday, implies that Names is the empty set. Names is the domain of N5 which in turn is a subset of N2 with a range containing only W. Then, Names is necessarily empty. This is confirmed by running the following:

Analysis such as these increase our confidence on the correctness of the specification perhaps more than executions where inputs are constants because variables cover all possible constant values.

5.1 Discharging verification conditions

After loading the file generated by the VCG, users can execute a small Prolog program (called $\mathtt {check\_vcs}$ ) that will attempt to discharge one VC after the other by passing in them to $\{log\}$ . In other words, $\{log\}$ is used as an automated theorem prover. Recall that each VC is a $\{log\}$ formula written in terms of the predicates defined by the user whose bodies are, again, $\{log\}$ formulas written in terms of constraints. Users are informed about the status of each VC:

• • OK: the VC has been successfully discharged.

• • TIMEOUT: $\{log\}$ attempted to discharge the VC but it run out of time.

• • ERROR: $\{log\}$ found a counterexample contradicting the VC.

Here we analyze the second situation, whereas the third one is analyzed in Section 5.2. $\{log\}$ can timeout when solving a VC simply because many decision procedures for set theory are NP-complete, although in practice they work in many cases.Footnote ¹¹ When a VC times out, we do not know whether the VC is indeed a theorem of the specification or not. Then, we should help $\{log\}$ to assist us to find out whether the VC is provable or not. To this end, users can rerun the VC by calling $\mathtt {check\_vcs}$ with a couple of arguments. These arguments are passed in to $\{log\}$ making it to slightly change the solving algorithm as follows.

• • Timeout. We can simply extend the default timeout to see if $\{log\}$ needs some more time to discharge the VC.

• • Execution options. This is the more promising course of action as execution options influence the constraint solving algorithm. Influence means that the algorithm can take shorter to solve a formula but it also can take longer. It is hard to predict what execution options will have a positive impact in solving a particular formula. However there are some guidelines that in general produce good results. Here we will show a few execution options – see $\{log\}$ user’s manual for more details (Rossi and Cristiá Reference Rossi and Cristiá2025, Section 11.1).

  1. – $\mathtt {subset\_unify}$ . Implements set equality as a double set inclusion instead of implementing it by exploiting set unification (Dovier et al. Reference Dovier, Pontelli and Rossi2006). Note that set equality is pervasive in $\{log\}$ formulas even if the formula does not use it explicitly.

  2. – $\mathtt {un\_fe}$ . Implements $un(A,B,C)$ in terms of RUQ (Section 2.4). In this way $\{log\}$ produces two solutions instead of six when solving $un(A,B,\{X/C\})$ , with $A$ and $B$ variables. These two solutions encode the standard proof of $x \in A \cup B$ . Union is not as pervasive as equality but is one the most used constraints during the low-level stages of the algorithm.

  3. – noirules. By default $\{log\}$ applies inference rules while the goal is processed. noirules deactivates these inference rules because in some cases their application may slow down the constraint solving process.

  4. – strategy(ordered). Changes the order in which atoms are processed. It has shown to impact proofs of the form $p \land (q \lor r) \land s$ . Note that invariance lemmas have this form, indeed: $\lnot (Inv \land Op \implies Inv') \equiv Inv \land Op \land \lnot Inv'$ , where $Op$ is usually a disjunction – for example addBirthday.

  5. – $\mathtt {tryp(prover\_all)}$ . This is the most powerful option. It attempts to solve the VC by running it in multiple (operating system) threads. Each thread runs the VC under some combination of execution options. As soon as one thread terminates, the whole computation terminates as well. In this way, the net execution time will tend to be the time needed by the thread running the best combination of execution options for that VC.

  Therefore, users can analyze the VC to determine what execution options would be useful for that particular formula. If they have access to a large computer $\mathtt {tryp(prover\_all)}$ is the best course of action as it tries all possible combinations at once. According to our experiments there is always a combination of execution options that discharges the VC in a reasonable time. At the same time, exploring execution options is far less cumbersome than attempting an interactive proof.

5.2 Analyzing undischarged verification conditions

$\{log\}$ may not be able to discharge a VC for a few reasons: (i) If a VC falls outside the decision procedures implemented in $\{log\}$ , then the tool will be unable to discharge it; there is nothing to do in this case – see Section 5.3. (ii) If the specification is wrong (e.g., a precondition is missing, an invariant is too strong, etc.) then it may be impossible to prove some VC. (iii) Finally, a VC may require more hypotheses. Let’s analyze these last two situations.

Every time the status of a VC is ERROR, $\{log\}$ saves a counterexample contradicting the VC. These counterexamples can be very helpful in finding out why the proof failed. There are two kinds of counterexamples: abstract, which may include free variables; and ground, which do not contain free variables. For example, when $\{log\}$ attempts to discharge the VC of the birthday book specification, the VC named $\mathtt {addBirthday\_pi\_}$ birthdayFun fails. We can see the ground counterexample as follows:Footnote ¹²

The reason for the failure is in this counterexample. As can be seen, Birthday $\texttt{=}$ {[n2,n1]} whereas Known $\texttt{=}$ {} thus contradicting invariant domBirthday which states dom(Birthday,Known). That is, the counterexample says that Birthday is not empty while Known, its domain according to domBirthday, is empty. Therefore, the proof failed because it lacks domBirthday as an hypothesis. Once the user adds domBirthday as an hypothesis to $\mathtt {addBirthday\_pi\_birthdayFun}$ $\{log\}$ proves the VC immediately. Although in this case the cause of the problem is a missing precondition, the same analysis is conducted when the cause ends up being an error in the specification.

This example leads us to explain an important design decision concerning the way the VCG generates invariance lemmas. Let $\{I_k\}_{k \in A}$ be the invariants of some specification and let $O$ be an operation. The invariance lemma for $O$ and $I_{k_0}$ (for some $k_0 \in A$ ) is:Footnote ¹³ $(\bigwedge _{k \in A} I_k) \land O \implies I_{k_0}'$ , where $I_{k_0}' \triangleq I_{k_0}[\forall v \in \mathit{StateVars}: v'/v]$ . However, the VCG generates the following formula: $ I_{k_0} \land O \implies I_{k_0}'$ . Clearly, the invariance lemmas generated by the VCG may lack some other invariants as hypotheses. This is a design decision based on the fact that unnecessary hypotheses may severely reduce the performance of an automated theorem prover. Indeed, $\{log\}$ might start rewriting some useless hypotheses rather than the useful ones, thus spending time in dead-end proof paths. Hence, we decided that users can use counterexamples to add hypotheses one by one, if necessary. Furthermore, $\{log\}$ provides the findh command family that automates the search for hypotheses. findh uses the abstract counterexamples saved by the VCG to find invariants that contradict them. These invariants are good candidates to become hypotheses as their presence surely will not generate the same counterexamples. As with execution options, analyzing counterexamples is far less involved than attempting interactive proofs. It is important to observe that if a VC times out it leaves users without any clue about the reason for that. Instead, a failed proof accompanied by a counterexample let users to work it out.

Aligned with the way $\{log\}$ generates VC, is the decision of splitting the invariant of the birthday book specification into two predicates (domBirthday and birthdayFun). Indeed, these predicates could be defined as a single invariant. However, this strategy may hinder the automated proof process as it is like having all the invariants as hypotheses.

We have applied this methodology, for example, to analyze Chinese wall security properties (Capozucca et al. Reference Capozucca, Cristiá, Horne and Katz2024), where we have to add 12 hypotheses in 5 VC out of 35, that is, 30 VC need no human intervention; and to verify a model of a landing gear system (Cristiá and Rossi Reference Cristiá and Rossi2024a), where 60% of the VC where discharged in the first run whereas the vast majority of the remaining proofs needed only one hypothesis.

In summary, $\{log\}$ is used to automatically discharge VC and to help users to find why a VC could not be discharged.

5.3 What verification conditions can be discharged?

In the previous section we mentioned that $\{log\}$ will be unable to discharge a VC if it falls outside the decision procedures implemented in it. A formal and precise description of the boundaries of the decidable fragments available in $\{log\}$ has been given in our previous work – see at the beginning of Section 2. In this section we give an informal account of the decision procedures implemented in $\{log\}$ . Figure 1 helps us in this task. If theory A is above theory B it means that A inherits the signature of B.

• • LIA stands for linear integer arithmetic. $\{log\}$ uses an external implementation of a decision procedure for LIA.

• • SET is the Boolean algebra of sets. That is, a theory including hereditarily finite sets, equality, union, intersection, difference, set membership and their negations (Dovier et al. Reference Dovier, Piazza, Pontelli and Rossi2000).

• • CARD is SET extended with cardinality and combined with LIA (Cristiá and Rossi Reference Cristiá and Rossi2023). That is, variables denoting set cardinality can only participate in linear integer constraints. CARD cannot be combined with RIS or RA.

• • FII is CARD extended with finite integer intervals (Cristiá and Rossi Reference Cristiá and Rossi2024c). As with CARD interval limits can only participate in linear integer constraints.

• • RIS is SET extended with RIS – Section 2.2. Considering RIS of the form ris(X in A, $\phi$ ), the theory is decidable as long as $\phi$ belongs to a decidable theory supported by $\{log\}$ . When more complex RIS are used, the condition for decidability is more involved (Cristiá and Rossi Reference Cristiá and Rossi2021b).

• • RA (relation algebra) is SET extended with composition, converse and the identity relation. The condition for decidability is rather involved (Cristiá and Rossi Reference Cristiá and Rossi2020); we give a simplified version. RA is decidable for the class of formulas not containing constraints of the form comp(R,S,R) or comp(S,R,R). As many relational constraints are defined in terms of comp (e.g., relational image), a formula not containing comp may still belong to the undecidable fragment – for example, some formulas containing (simultaneously) domain and range fall outside of the decidable fragment (Cantone and Longo Reference Cantone and Longo2014).

Fig 1.

The stack of theories dealt with by $\{log\}$ .

The theory of restricted quantifiers, noted RQ, is not depicted in Figure 1. RQ is parametric w.r.t. some quantifier-free, decidable theory (Cristiá and Rossi Reference Cristiá and Rossi2024d) – for instance RQ could be configured with CARD or LIA or even with the decidable fragment of RA. However, the parameter theory must verify the following condition: if its solver, as a result of solving a formula, returns a conjunction of atoms including set variables, this conjunction must be satisfiable by substituting set variables by the empty set. This is not the case of CARD and FII. The decidability of RQ is as follows. Let $\{\ldots /A\}$ be the domain of a RQ where $A$ is a variable. We say that $A$ is the domain variable of the RQ.Footnote ¹⁴ The innermost formula of a RQ is called its quantifier-free formula. For instance, X is V + 1 is the quantifier-free formula of the nested RQ given in (8). The decidable fragment of RQ is characterized by formulas including foreach and exists with a quantifier-free formula belonging to a decidable fragment and meeting at least one of the following conditions.

1. 1. The formula contains only exists.

2. 2. The formula contains only foreach, and none of the domain variables are used in the quantifier-free formula.

3. 3. The formula contains nested RQ of the following form where foreach verify (2):

   

4. 4. The formula contains foreach and exists but does not belong to the above class (i.e., some exists occur after some foreach). In this case the condition for decidability is as follows: (i) no domain variable of a foreach is used in the quantifier-free formula; and (ii) no exists occurring after a foreach share the same domain variable. For instance, the following formula does not verify (ii): foreach(X in {W / A}, exists(Y in {V / A}, $ \phi$ )).

If $\{log\}$ is called on a formula not meeting the conditions for the theories depicted in Figure 1 nor the conditions for RQ, it will most likely run forever although it may terminate in some cases. Then, in general, calling $\{log\}$ on such a formula will be rather harmless. There is, however, an exception. If the formula combines CARD with RIS, RA or RQ, then the answer can be unsound.

6.1 Brief introduction to the TTF

In the TTF, test cases are generated for each operation in a state machine. Test case generation proceeds by applying so-called testing tactics to the selected operation. Each tactic partitions the input space of the operation. The input space of an operation is the set given by all the possible values that its input and before-state variables can assume. What tactics are applied depends on the logical structure and mathematical elements used in the operation, as well as on the testing goals determined by the testing team. The current implementation of the TTF provides a total of six testing tactics. Here we will discuss only two of them, namely disjunctive normal form (DNF) and standard partitions (SP). See $\{log\}$ user’s manual for more details (Rossi and Cristiá Reference Rossi and Cristiá2025, Section 13.7).

The DNF tactic requires writing the precondition of the operation into DNF and partitioning the input space in as many sets as terms are in the DNF. In this way, the main logical alternatives of the operation are considered. For example, when DNF is applied to addBirthday it will partition the input space into a set where the new person is added to the book and another set where the person already exists and so the book remains unchanged. Hence, there will be at least one test case testing the addition of a person and another test case testing an erroneous situation. In $\{log\}$ DNF must be the first tactic to be applied.

SP defines partitions for key mathematical operators such as union, intersection, overriding, etc. Figure 2 shows the standard partition for union, intersection and set difference. The partition indicates conjunctions of conditions depending on the arguments of the operator. The rationale behind SP is that set and relational operators have non trivial implementations that deserve a thorough testing. Currently, SP supports nine set and relational operators but can be easily extended by users.

Fig 2.

Standard partition for $S \cup T$ , $S \cap T$ and $S \setminus T$ .

As a result, DNF aims at the logical structure of the operation whereas SP aims at its mathematical elements. In $\{log\}$ each testing tactic is applied by means of its own user command, as we will show in Section 6.2.

The partition of the input space is represented as a testing tree. Nodes in the testing tree are called test specifications. Each test specification is a conjunction of $\{log\}$ constraints depending on the before-state and input variables of the operation. This conjunction is called characteristic predicate of the test specification. The root of the testing tree is the input space of the operation; its characteristic predicate is $true$ – meaning that the test specification is not constrained in any way. Let $C$ and $D$ be test specifications of a given testing tree, and let $\Phi _C$ and $\Phi _D$ be their characteristic predicates. If $D$ is a child node of $C$ then $\Phi _D = \Phi _C \land \phi$ with $\phi$ being a conjunction of at least one atomic predicate different from $true$ and not present in $\Phi _C$ . In other words, the characteristic predicate of a child node includes the characteristic predicate of its father node plus the conditions added by the testing tactic from which $D$ was created.

The testing tree is a compact representation of the status of the testing process. For example, by looking at the testing tree one can have an idea of the number of test cases that can be generated, what tactics have been applied and where.

When two or more testing tactics are applied many test specifications may turn to be unsatisfiable. Given that it is impossible to generate test cases from unsatisfiable test specifications, they must be pruned from the testing tree. Detecting unsatisfiable set formulas is one of the main $\{log\}$ ’s capabilities. Hence, the TTF provides a command, namely prunett, that iterates over all the leaves of a testing tree and asks $\{log\}$ whether or not they are unsatisfiable. If $\{log\}$ finds an unsatisfiable test specification, prunett eliminates it from the testing tree.

In the TTF a test case is an assignment (or binding) of values to the input and before-state variables. In other words, a test case is a solution to some test specification. Again, $\{log\}$ is good at finding solutions to set formulas. Then, $\{log\}$ provides a command, namely gentc, that iterates over all the leaves of a testing tree and asks $\{log\}$ for a ground solution to each of them. Test cases are derived only from the leaves of the testing tree because these nodes include all the conditions added by each applied tactic.

6.2 Applying the TTF to the birthday book specification

We will use the birthday book specification to show how the TTF works in $\{log\}$ . Before applying the TTF on a specification, the specification has to be typechecked and the VCG has to be called on that specification. The TTF uses information about the state machine collected by the typechecker and the VCG. In this example we will generate test cases for addBirthday. As DNF is the first tactic to be applied, we issue the following command:

That is, the command waits for a term of the form $\mathit{operation(i_1,\ldots ,i_n)}$ where $i_1,\ldots ,i_n$ are the inputs of the operation. Users decide what arguments are inputs and what are not. The resulting testing tree is shown with the writett command:

$\mathtt {addBirthday\_vis}$ is the root of the tree while $\mathtt {addBirthday\_dnf\_1}$ and $\mathtt {addBirthday\_dnf\_2}$ are its children – indentation is used to depict tree levels. The nodes of the testing tree can be exported to a file with exporttt, thus obtaining the following:

It would be possible to generate test cases from this testing tree but we can also apply more tactics to one or more of its test specifications, to further partition the input space. In this case SP is applied to the $\mathtt {addBirthday\_dnf\_1}$ test specification with the following command:

The first argument is the test specification that we want to partition and the second one is a constraint present in the operation – see addBirthdayOk in Section 3. Then, the above command generates the following testing tree.

$\mathtt {addBirthday\_dnf\_1}$ is partitioned into eight test specifications due to the eight conjunctions of the standard partition for set union – see Figure 2. Two sample test specifications are the following:

Note that the arguments of the partition ( $S$ and $T$ ) are substituted by the arguments of the constraint passed in to applysp (i.e., {Name} and Known).

Now we call prunett to prune possible unsatisfiable test specifications. The result is the following testing tree:

Although more tactics could be applied we stop here to keep the presentation concise. The final step in the TTF is to call gentc to generate one test case for each leaf in the testing tree. The resulting test cases that can be printed with writetc:

Observe that Birthday has not been bound to some value. This is so because no test specification includes a condition on that variable. Concerning these test cases, Birthday can assume any value. Applying SP on the postcondition un(Birthday,{[Name,Date]}, $\mathtt {Birthday\_)}$ as a third tactic would generate test cases with different values for Birthday combined with the values of these test cases. Appendix B presents the application of this tactic and the test cases so generated.

In summary, the TTF component uses $\{log\}$ as a back-end solver for automating two crucial but annoying, error-prone tasks: pruning unsatisfiable test specifications and test case generation. Users are left with the more creative task of deciding what tactics will generate the best test suite. By implementing the TTF as a $\{log\}$ component users work with only one notation and tool. Besides, it avoids costly translations between $\{log\}$ and Z which also brings in more efficiency.