Having specified the meaning of each of the parts of the model, we now turn to the task of connecting these parts to specify the required system. Because we have interpreted the diagrams using logical formulae, we can join them using logical connectives.
We want to make the send action the entry action of state s′. That is, if an object is in state s′, then immediately after it does an accept, we want its todo list to contain only this action.
SMp(x)≡ [ε][x.accept](state(x) =s′ //todo(x) =sendX tox.ex)
Putting x.exrather thanself.exsaves us the trouble of evaluatingself. Recall that in Section 6.2 we defined two formulae from the state machine diagram, SMs(x)for the states and SMt(x)for the transitions. Now, we attach the
state machine diagram augmented by the entry procedures, to the class A. SM≡[ε]((∀x)class(x) =A //SMs(x) ∧ SMt(x) ∧ SMp(x))
We are now in a position to ask whether our model is consistent. In other words, is there an execution trace which can satisfy CD, SM and SEQ?
Semantic tableaux deductive calculi [DGHP99] do a systematic search for an interpretation which satisfies their input formulae. Their purpose is to determine whether or not an argument is valid, that is, that it is impossible for the premises of the argument to all be true in the same situation where the conclusion is false. To test this, the conclusion is negated, and together with the premises, input to the search procedure. If a situation that satisfies these inputs is found, it is a counter- example to the argument, because it makes the premises and the negated conclusion all true, hence it makes the premises true and the conclusion false. It is impor- tant that the search procedure is exhaustive, because then if no counter-example is found, we may conclude that the argument is valid. Some logics, such as first order logic andDLare undecidable, so for some inputs, the procedure will not ter- minate4. However, when it does terminate without finding a counter-example, we still know that the argument is valid.
4Alwen Tiu pointed out that a decision procedure forDLwould be a solution for the halting problem, because for any programρ, the formulahρi⊤is valid iffρhalts.
Our goal is different: we want to show that a collection of formulae are con- sistent. We can therefore simply enter our formulae into the search procedure. If it finds an interpretation which satisfies the inputs, our model is consistent. If it terminates without finding one, it is inconsistent. Since the required execution traces are unlikely to be difficult to find, if the process runs for a long time without terminating, this would be a fair indication that the model has problems.
Tableaux methods for modal logics such as dynamic logic have been inten- sively studied [DGHP99, vEHN01]. We do not know of a tableau prover forDL with array variables, but the principle author of the Tableau Workbench [AG03] assures us that this system could be easily adapted to the task.
For now, we will conduct a manual search in the style of a tableaux system. The first step is to assume that there is a situation which satisfies SEQ, CD and SM. We call this situation w0. Recall that these situations are valuations, which
take variables to individuals, and array variables to functions. Recall also that programs denote relations between these valuations. Our search will consist in breaking down the formulae until we have a collection of explicitly specified val- uations, related as required by DLprograms. Or, if the model is not consistent, this inconsistency will be made explicit as two different values for a variable under some required valuation.
We begin by assuming that our three formulae are true at w0.
SEQ at w0, assumption (6.1)
CD at w0, assumption (6.2)
SM at w0, assumption (6.3)
For a conjunction to be true at a world, each of its conjuncts must be true there, so we reduce 6.1 (SEQ) to
class(ee) =EE at w0, from 6.1 (6.4)
class(a) =A at w0, from 6.1 (6.5)
class(b) =B at w0, from 6.1 (6.6)
and
hεi(sendCond(ee,W,a) ∧ hee.sendWtoai. . .⊤) at w0, from 6.1 (6.7)
If we were performing this tableaux search with pencil and paper, we would now mark 6.1 with a tick√to indicate that it is complete. These four new formulae are satisfied if and only if 6.1 is, so we can forget about it.
Since the class diagram formula CD is[ε]. . ., andεis a∗program which may run 0 times, the. . .part must be true at w0.
(∀x)class(x) =A //
size(x.ex) = 1 ∧
((∀y)y∈x.ex //class(y) =B)
The sequence diagram does not actually say that b is a’s ex, but this was our inten- tion when creating the scenario, and it makes 6.8 true. We hope that the tableaux system would try this before introducing new instances of B. Even so, it would take several steps to do so, which we omit. Note that there are other ways of making 6.8 true, so we do not mark it as completed at this stage. In particular we could assert the existence of new instances of B at w0. Although its fairly clear to humans that
this would not help, a tableaux system could easily get stuck in an infinite sequence of stupid ideas.
a.ex={b} at w0, from 6.8 (6.9)
Now we turn to 6.7. Again, becauseεis a∗program, we can satisfy the formula at w0 by satisfying the subformula under thehεi. If this failed, a tableaux system
would begin checking other states that can be reached under theεprogram. We split the two conjuncts.
sendCond(ee,W,a) at w0, from 6.7 (6.10) hee.sendWtoai. . .⊤ at w0, from 6.7 (6.11)
Now 6.4 says that ee is an external entity, and the definition of sendCond, says it can send messages as it pleases, so 6.10 is true at w0.
To satisfy formula 6.11, we need a transition from w0 to another situation re-
sulting from the send action. We write
w0 sendWtoa //w1 (6.12)
to say this. We also assume that a is in state s with an empty intray. This will mean that a can accept the sent W message and make the intended transition. Again, a formal tableaux system might have to work to find that this is what is needed.
state(a) =s at wo, assumption (6.13)
intray(a) = () at wo, assumption (6.14)
As a result of thesendaction, a will have a W message in its intray.
intray(a) = (W) at w1, from 6.14, 6.12, df.send (6.15)
We now reinstate some of 6.11 which we had turned into. . .. To make it true at w0
we require its subformula to be true at w1.
hεi(acceptCond(a) ∧ ha.accepti. . .⊤) at w1, from 6.11, 6.12 (6.16)
The condition acceptCond(a) is true at w1 because a has a message in its intray
but nothing in its todo list. To make the other conjunct true, we need anaccept
step to the next state.
w1
a.accept
/
Now the definition ofaccept, on Page 121, depends on the array variables nextState and entryProc, so its not immediately obvious what the situation will be in w2.
However
(∀x) state(x) =s ∧ head(intray(x)) =W
/
/[x.accept]state(x) =s′ at w1, from SM (6.18) and therefore
state(a) =s′ at w2, from 6.13, 6.15, 6.17, 6.18 (6.19)
It follows from this that, at least at w1, nextState(s,W) =s′, and since we are not
considering any programs which update nextState, we can consider this to be the value everywhere. Similarly, at least in effect (since we do not actually use self ), entryProc(s′) =sendXtoself.ex because
(∀x)[x.accept](state(x) =s′ //todo(x) =sendXtox.ex)at w1, from 6.3
(6.20) and so
todo(a) =sendX toa.ex at w2, from 6.17, 6.19, 6.20 (6.21)
Assume that values are equal to their singleton sets, so{b}=b.
todo(a) =sendXtob at w2, from 6.9, 6.21 (6.22)
Thus we can satisfy 6.16 if we can satisfy
hεi(sendCond(a,Y,b) ∧ ha.sendY tobi⊤)at w2, from (6.16)(6.17) (6.23)
and now, it would appear that we are stuck, because it seems nothing that can possibly happen is going to putsendY tob into a’s todo list, which we need in order to satisfy sendCond(a,Y,b). But recall that X and Y are variables. Hence each valuation maps them both to individuals in the semantic domain. If w2maps X
and Y to the same individual, then sendCond is satisfied, thesendcan proceed and the sequence successfully completes, showing that it is consistent with the model defined by the class and state machine diagrams.
This is clearly not how the story is supposed to end. We are developing a formal theory of our intuitive understanding of the diagrams, and our intuition says they are inconsistent, because X is X, Y is Y, and they can not be the same thing. That is “X” is not just a label we stick on that message from outside the system, but rather something essential to its identity. We can capture this idea formally by retrospectively asserting the following naming invariant
NAMES≡[ε](name(X) = “X”∧name(Y) = “Y”∧ · · · ∧name(s′) = “s′”)
which makes X = Y impossible. It also prevents the classes A and B from being the same, and also weird possibilities like A = s, identifying a class and a state.
(Although Mellor [Mel03] has made suggestions that are almost this strange when discussing how domain models might be woven together.)
So now there really is no way to find a situation withsendYtob on a’s todo list, so the sequence diagram is inconsistent with the model. This could be proven by induction on the definition ofε.