A Formal Basis for Modelling Process and Task Management Aspects of User Interface Design

This paper presents a method for formally specifying and reasoning about process models for interactive systems. The method addresses two important aspects of user interface design: controlled but flexible access to functionality; and provision of useful task management information, such as indicating what progress has been made towards achieving goals and what remains to be done. 
 
The method is well suited to "data intensive" applications in which the system is being used to manage complex "configurations" of interconnected objects, and for which task goals can be expressed in terms of properties of the underlying configuration of objects. The method includes proof obligations to check the accuracy of the task management information. 
 
The paper illustrates the method on a Theory Manager, which manages a store of theorems and proofs; the store has complex consistency and completeness requirements.


Introduction
This paper describes a formal method for modelling and reasoning about functionality aspects of User Interface (UI) design for interactive systems.The method is primarily applicable to systems in which the user constructs and maintains large or complex \con gurations" of objects and relationships between objects, and the user's task goals can be expressed in terms of establishing or maintaining consistency and completeness conditions on the underlying store of objects.Common examples of such systems include programming environments, software engineering environments, hypermedia networks, airline reservation systems, and so on.For example, in a programming environment the objects might be individual program statements, and there might be consistency checks such as ensuring that correct syntax has been used, and completeness checks such as checking that all variables have been initialized, all paths have been tested, and so on.In a software engineering environment the objects might be coarsegrained objects such as software development documents, or ner-grained objects such as individual de nitions in a speci cation 15].For such systems, two of the most important aspects of UI design are 1.controlled and exible access to functionality.By controlling how objects are accessed and changed, the UI can play an important role in maintaining consistency of the object store; on the other hand, systems which enforce consistency (e.g.syntax-directed editors) can be annoyingly in exible to use. 2. provision of useful task management information, such as how far the user has gone towards meeting their goals, and what remains to be done.When the consistency and completeness conditions are complex or hard to check, the availability of such information can be crucial to the system's usability.In high integrity applications, the accuracy of such information can be of critical importance.
Process modelling has been proposed as a way of guiding and controlling access to functionality, and a number of process modelling languages are now available (e.g. 13, 14]).State-based process models are ones in which certain objects are assigned a state { or status as we prefer to call it, so we can use the term state in a more general sense.The status of an object is a representation of what the system \believes" about the object based on what process steps have taken place.Guided by status information, the process engine invokes tools and changes objects and their statuses accordingly.This paper presents a systematic method { originally proposed in 16] { for formally specifying and reasoning about state-based process models and describes how object statuses can be used to provide useful task management information.(Note that we do not however consider the problem of task analysis here.)The method includes proof obligations for verifying the accuracy of task management information and for checking control of access to functionality.The method could be used in conjunction with more general methods for modelling interactive systems, such as interactors 6].VDM-SL notation 3, 12] is used for formal de nitions here, although other state-based formal speci cation notations could be used equally as well.
The method is outlined brie y in Section 2 below and illustrated in detail on an example application in Sections 4-6.The application concerns a specialized object-store management system which, although limited in its functionality, has complex, critical consistency and completeness conditions.We describe a process model for a exible style of interaction in which users can take the object store into \inconsistent" states and recover from inconsistencies in a controlled manner.The process engine itself makes use of the task management information to optimize its performance.Some of the correctness proofs are sketched.
2 Outline of the method

The problem
Suppose the UI designer is given a set of application tools for a system such as described above, together with an informal description of the user's tasks.The designer's problem is how to design a coherent UI for the tool-set which: gives users access to the functionality they desire; prevents access to operations that are meaningless, irrelevant or unde ned; reports on the state of progress in the task; and indicates how further progress can be made.
The following factors may a ect the design: The task may or may not have a pre-de ned \ nal goal": e.g. the task may simply involve ongoing processing of new inputs.The tools may have \prerequisites" (constraints on how they can be used): e.g. a back-end compiler may require the source program to be syntax correct before it can generate object code.
There may be performance requirements: e.g. the user may be willing to accept slow response times on \critical" operations (such as those which have the potential to avoid a lot of subsequent re-work) but may expect quick responses on non-critical operations.Formalizing performance requirements is however beyond the scope of the method discussed here.
We assume the designer has a good understanding of the application domain and of formal modelling techniques.

The method
The following method can be used to specify and reason about possible designs for the UI: 1. Build a formal model of the application domain as follows: (a) De ne the data model: i.e., the kinds of object in the system and the possible relationships between them.(b) Specify the functionality of the tools, including their input and output types, the input/output relationships they establish, and any prerequisites they may have.
The tool descriptions should be \functionalized" (i.e., not use internal states).(c) De ne the task goals, including intermediate goals and situations to be avoided.
Express the goals as consistency and completeness checks on the object store: i.e., de ne what makes a con guration \consistent" and \complete".This model is called a con guration model in 16].Note that, in practice, the di erent parts of the model would usually be de ned in parallel.VDM-SL type and function de nitions will be used in the body of this paper to formally specify the con guration model for the example application.2. De ne a process model which incorporates task management information as follows: (a) Determine the objects which are to be tracked and their possible statuses.Status values shoud be chosen to represent the important process attributes of the objects (e.g.`has-correct-syntax' for the source code program example above).Note that it may not be practical { or even desirable { to track the status of every object in the system.(b) De ne the state of the process as consisting of the object store itself together with the status information.Also de ne the possible initial states of the system (including initial statuses).(c) Specify any extra tools required by the process engine (e.g. for checking relationships or creating new objects).(d) De ne the functionality of the UI in terms of operations (transitions between process states).Operations may seek input from the user or return output to the user.Also include a de nition of the conditions under which the operation may be invoked; this allows operations to be \disabled" in certain states.1 (e) State the behavioural properties which capture the intended meaning of status information in terms of the consistency and completeness checks de ned earlier.
These properties are typically statements of the form \if objects x 1 ; : : :; x n have statuses s 1 ; : : :; s n then property P holds" (su cient conditions) or \if property P 0 holds then object x has status s" (necessary conditions) or some combination of these. 2 In the example below we use VDM-SL state and operation de nitions to formally specify the process model.Status information is modelled using mappings ( nite partial functions) from objects to their status.State invariants record constraints on the object store, such as structural relationships that should always hold. 3. Verify that the process model is mathematically consistent and has the required properties: (a) Check that tool prerequisites have been met and that the speci ed transitions are mathematically feasible.In VDM these checks are called well formedness and satis ability proof obligations: see 1, 12] for details.(b) Show that the behavioural properties hold in all \reachable" states of the system: i.e., they are true in the initial state(s) of the system and are preserved by all enabled operations. 3The proof obligations are described in more detail in 16].
3 Example: a theory manager

Motivation and background
We illustrate the method on the design of an UI for a Theory Manager such as might be used in conjunction with a mechanical proof assistant to develop a collection of mathematical theorems and their proofs.The user will be provided with operations to add and delete proofs of theorems, together with status information for individual theorems in the theory and for the overall theory.Note that the proof of a theorem can use other theorems, and that the entire network of dependencies between theorems can become large and complex. 4t is crucial to the logical soundness of the theory that circular reasoning be disallowed (cf.Fig. 1).The user's task is to develop the theory by giving proofs of its theorems.We shall not consider how such a task would be carried out by the human user (see instead e.g.4]); rather, we assume the Theory Manager's role is to track dependencies and watch for circularities, and to present useful status information to the user.The user's overall goal is to create a \complete" theory { one in which all theorems have complete proofs, with no circularities.The traditional approach to maintaining soundness { as exempli ed by logic textbooks { is to linearly order the theorems and allow proofs to use only theorems which are proven earlier in the ordering (i.e., do not allow forward references).Automath 5] is an example of a proof assistant which enforces this style, and the highly in uential LCF 8] uses a variant of this approach.In practice, however, such an approach is annoyingly in exible, requiring that proofs be planned in detail on paper before taking them to the machine.The mural system 11] was developed in response to a perceived need for a more exible style of working, whereby the user could develop a theory on-line in a piecemeal fashion, say interrupting the proof of one theorem to conjecture and prove useful lemmas, or to work on another proof in parallel.The work described here grew out of an attempt to show that the mural theory manager ensures logical soundness. 5

UI requirements
The theory manager described here will support the storage and use of incomplete proofs and will even allow circular reasoning.The following task management information will be provided: i.The UI will indicate when the theory is circular.
ii.If a circularity is present, the UI will give the user some idea of where it can be found.iii.The UI will indicate when the theory is complete.iv.The UI will indicate when a given theorem is fully established.v.The UI will indicate which theorems have incomplete proofs.
We will state { and show how to prove { properties that relate status information to properties of the underlying theory store: e.g.we will show that if the theory attains the status complete then the theory really is complete.Such a system might be used for example to track the completeness of the formal veri cation of a user application { for example, to check that proof obligations have been completely and correctly discharged in a Z or VDM development.Although in this paper we restrict our attention to theorems and proofs, it is easy to imagine how the example could be extended to support formal veri cation more generally.In 16] the method is applied to a formal development support environment to track the co-development of a formal speci cation and its veri cation.

Modelling the application domain
In this section we describe and formally model the Theory Manager application domain.

The objects to be managed
We shall be concerned with three kinds of object: Theorems, which are (named) mathematical statements expressing properties which are believed to hold.For simplicity of modelling we shall not distinguish between axioms, lemmas, conjectures, postulates, proof obligations and so on { they will all simply be called theorems.Theorems will be modelled here using the not-further-de ned type Thm.
Formal (machine-checkable) proofs, which are structures which { if correct and complete { establish the truth of theorems.Di erent proof assistants use widely di ering forms of proof structures, but we shall not concern ourselves here with the di erences: instead, we shall simply assume there is a tool which extracts from a proof the set of theorems used in the proof.Note also that, as explained above, we wish to support the storage and use of partial and incomplete proofs; for simplicity of modelling we shall thus use the term `proof' to cover both complete and incomplete proofs.Proofs will be modelled here using the not-further-de ned type Proof .
A theory which is a collection of theorems together with their proofs.
Theories will be modelled as a mapping (i.e., a nite partial function) type from theorems to their proofs: Theory = Thm m -! Proof

Basic tools required
As explained above, we have chosen to model the application at the level of granularity of theorems and proofs, without going into details of their internal structure.We simply assume instead that there are tools available for checking whether a given proof is nished (i.e., is correct and complete) and for extracting the set of theorems used in a given proof.These two tools will be modelled formally as not-further-de ned functions with signatures as follows: 6 is-nished : Proof !B uses : Proof !Thm-set We shall assume both tools are reasonably e cient.In practice, the e ciency of these tools depends on whether the appropriate hooks are provided by the target proof assistant.For systems which record proof structures explicitly, such as mural 11] and Ergo 18], these tools could be very fast.In other cases an alternative design strategy may be needed (e.g.cache the results and store them with the proof at the time the proof is constructed).

Consistency and completeness checks
In this section we describe the basic properties to be tracked by the Theory Manager.Note that although it would be possible to build tools that evaluate these properties directly, such tools would be woefully slow, especially when the theory store grows in size and complexity; instead, our system will use knowledge of the process model to provide an e cient means to track and manage the properties.
We say a theorem s depends directly on a theorem t in theory T if s has a proof in T and the proof uses t; formally: s 2 dom T ^t 2 uses(T(s)).
A reference chain is a sequence of theorems, each of which depends directly on the next theorem in the chain: is-reference-chain : Thm Theory !B is-reference-chain (ts; T) 4 8 i 2 f1; : : :; len ts ?1g ts(i) 2 dom T ^ts(i+1) 2 uses(T(ts(i))) We say theorem s depends on t in T if there is a reference chain from s leading back to t: depends-on : Thm Thm Theory !B depends-on (s; t; T) 4 9 ts : Thm len ts 2 ^is-reference-chain(ts; T) ^ts(1) = s ^ts(len ts) = t We say a theorem t has a circular proof if it depends { directly or indirectly { on itself.
A reference loop is a reference chain which starts and ends at the same theorem: is-reference-loop : Thm Theory !B is-reference-loop (ts; T) 4 is-reference-chain(ts; T) ^ts(1) = ts(len ts) A theory is said to have a circularity if it contains any theorems with circular proofs: has-circularity : Theory !B has-circularity (T) 4 9 t 2 dom T depends-on(t; t; T) A theory is said to be complete if it has no circularities, all of its proofs are correct and complete, and the theory is self-contained (i.e., all theorems used in its proofs are themselves proven in the theory): is-complete : Theory !B is-complete (T) 4 : has-circularity(T) ^8 p 2 rng T is-nished(p) ^uses(p) dom T The overall goal of theory management is to develop a complete theory; in practice however it might not be realistic to expect to complete every proof in a theory, and some compromise might have to be reached whereby full proofs are given only for certain selected theorems (e.g.safety properties).A theorem is said to be fully established in a given theory if it and every theorem on which it depends (directly and indirectly) has a complete proof: 8 t 0 : Thm; T : Theory depends-on(t 0 ; t 0 ; T) , 9 ts : Thm is-reference-loop(ts; T) ^t0 2 elems ts Lemma 3. When a theory T is extended with a proof p 0 of a theorem t 0 , the new theory has a circularity if and only if either (a) there was already a circularity present in T or (b) p 0 uses theorems that depend on t 0 in T. 8 t 0 : Thm; p 0 : Proof ; T : Theory t 0 6 2 dom T ) has-circularity(Tyft 0 7 !p 0 g) , has-circularity(T) _ 9 t 2 uses(p 0 ) depends-on(t; t 0 ; T) 5 The process model

Tracking the status of objects
The process model will track the status of individual theorems in the theory as well as the overall status of the theory.We shall not track the status of individual proofs since their status can be deduced from their corresponding theorem.
The overall theory status will be one of the following: has-circularity { indicates that the theory may be circular incomplete { indicates that one or more theorems may still require proof complete { indicates that the theory is complete This is modelled by the following type de nition: TheoryStatus = fhas-circularity; incomplete; completeg A theorem's status will be one of the following: Note that the status is merely indicative in some cases: e.g. the theory may have status incomplete and yet actually be complete. 7Section 5.5 below explains how status information relates to properties of the underlying theory store.

The process state
We de ne the state of the process model to consist of the current value of the theory, an assignment of statuses to theorems which have proofs in the theory, and the theory's current overall status.

Tools used by the process engine
This section describes some of the tools that will be used by the process engine.These tools extend the functionality o ered by the basic tools described in Section 4.2.Since this paper describes a high-level design, the tools are simply speci ed here.Note that simple tools for accessing and manipulating structures (e.g. to check t 2 dom T or to construct T yft 0 7 !p 0 g) will not be speci ed separately.The rst of the tools is for checking the depends-on relationship: i.e. given theorems s and t and theory T, determine whether or not depends-on(s; t; T).The de nition is given in Section 4.3 above.A variety of di erent techniques could be used to implement such a tool (e.g. via a graph-searching algorithm).Because dependencies may reach far back into a theory, however, any such tool is likely to be quite slow, especially when the theory is large and complex.As a result, we shall make sparing use of this tool.
A second tool is for checking whether or not a given theorem is used in any of the proofs in a theory T: has-user : Thm Theory !B has-user (t; T) 4 9 p 2 rng theory t 2 uses(p) A third tool uses theorem status information to perform a quick check on whether a theorem t is fully established.It does this by checking that all of the theorems used in the proof of t have status proven or established; for those with status proven the check is then applied recursively: 9 check-if-estab : Thm Theory (Thm m -! ThmStatus) !B check-if-estab (t; T; m) 4 8 s 2 uses(T(t)) s 2 dom T \ dom m (m(s) = established _ (m(s) = proven ^check-if-estab(s; T; m))) pre t 2 dom T It will follow from the properties of the process model that if the check evaluates to true then t is fully established in T. Note that the speci cation of check-if-estab includes a precondition, which expresses the prerequisite that the tool should only ever be applied to theorems t in T. (The prerequisite is included here mainly for illustrative purposes and is perhaps a little arti cial.)

UI operations
The high-level design of the Theory Manager UI has four core operations: 1. GiveProof (t 0 ; p 0 ) { adds theorem t 0 with proof p 0 to the theory store (assuming the theorem does not already have a proof); 2. DeleteProof (t 0 ) { deletes the proof of theorem t 0 from the theory; 3. CheckProof (t 0 ) { runs a \deep check" on theorem t 0 to see if it is fully established; 4. CheckTheory { updates the theory's overall status.
Later stages in the design { which are outside the scope of the present paper { would need to address questions such as how to ensure in GiveProof (t 0 ; p 0 ) that t 0 does not already have a proof, and how to present to the user details of which theorems depend (or don't depend) on a given theorem.For the purposes of this paper, however, we assume that the above four operations are the only operations that can directly change the process state.Figures 2{5 give formal speci cations of the four core operations.The operations are explained informally below: GiveProof (t 0 ; p 0 ) The status s 0 of the new theorem t 0 is calculated as follows: Check if anything in p 0 already depends on t 0 { if so, t 0 will have a circular proof, so s 0 is set to circular; otherwise, check if p 0 is correct and complete { if not, s 0 is set to unproven; check whether all theorems used in p 0 have status established { if so, set s 0 to established; otherwise set s 0 to proven.
The overall status of the theory is set as follows: If s 0 is circular, then the overall status is set to has-circularity; If it was complete and s 0 is unproven or proven, then it is set to incomplete; otherwise it is left unchanged.The strategy behind this design is as follows: It is important to ag any circularity as soon as it arises, so the user can see immediately that something is wrong; the user can thus be expected to be willing to wait for a full circularity check of the new proof.(Note however that a circularity check of the full theory is not required.)Rather than disallow the proof if it causes a circularity, we prefer to give the user the opportunity to break the circularity somewhere else in the loop, by changing one of the other theorem's proofs.
On the other hand, when it comes to checking whether a theorem is fully established, the thoroughness of the check should be under user control.Since a full check would be very time-consuming, GiveProof simply does a shallow check (of the statuses of the theorems used in the proof) and leaves the deep check to CheckTheorem.Note that the shallow check is conservative in what it asserts: e.g. it asserts that t 0 has status established only if all theorems used in the proof have status established.
Note also that the theory may actually become complete as a result of adding the new theorem and proof (e.g. because it completes the proof of theorems that were not fully established before), but before the complete status is achieved it may be necessary for the user to apply the CheckProof and CheckTheory operations a number of times.
DeleteProof (t 0 ) When the proof of theorem t 0 is deleted, the statuses of theorems which depend on t 0 are updated from established to proven.(Note that this operation should be applied cautiously, especially if many theorems depend on t 0 .)The overall status of the theory changes from complete to incomplete if t 0 was used in any proofs in the theory.

CheckProof (t 0 )
Recall that the status of a theorem is merely indicative and does not necessarily represent the \best" status the theorem could have.For example, a theorem t 0 may have received status circular because it caused a circularity when it was rst added but since then the circularity may have been broken by deleting one of the other theorems in the dependency loop.Similarly, a theorem may have received status proven rather than established because one or more of the theorems on which it depends did not have a proof, but the missing proofs may have been supplied subsequently.The CheckProof operation uses the check-if-estab tool described in Section 5.3 to update the theorem's status, using information about the status of the theorems on which it depends.

The behavioural properties
The following properties formalize the relationship between object statuses and \static" properties of the object store.In any reachable state mk-TheoryManager(T; m; ) of the Theory Manager the following properties hold: From the above properties we can deduce the following relationship between status information and task management information described in Section 3.2: i.If the theory is circular, it will have status has-circularity.
ii.The theory's status will change to has-circularity as soon as a proof is added which results in a circularity.(The status will remain has-circularity until no theorem has status circular and the CheckTheory operation has been invoked.)Additionally, if a theorem has status circular and the status does not change upon applying the CheckProof operation, the theorem has a circular proof.(Note that a theorem may have a circular proof without necessarily having status circular.)iii.The theory is complete if the status complete is attained.iv.A theorem with status established is guaranteed to be fully established.The converse does not necessarilly hold, however, and it may be necessary for the user to apply the CheckProof operation to the theorem or some of the theorems it uses before the system will recognize that the theorem is in fact fully established.v.The theorems with incomplete proofs are those with status unproven.Note that proofs may also use theorems which do not themselves have proofs and thus do not have a status; such theorems can be tracked down by looking at the proofs of theorems which have status proven but whose status does not change upon applying the CheckProof operation.
6 Veri cation of the process model This section illustrates the steps involved in the veri cation of the process model given in Section 5.The proofs are too lengthy to give here in full.

Well-formedness and satis ability of the model
To show that the model is mathematically meaningful it is necessary to check that partial functions are applied to arguments within their domains, and that operations are mathematically feasible, in the sense that their postconditions are satis able (can be achieved).As an example of the former, consider the term (??? status(t) in the postcondition of DeleteProof (Fig. 3): it is well-formed in context since t 2 dom (??? theory and dom (??? theory = dom (??? status (from the state invariant).The proofs of the other cases are similarly straightforward.Regarding satis ability, there is little to prove in this case since the operation de nitions are given constructively; we need only check that the postconditions of the four operations are consistent with the state invariant,10 which is straightforward.

The behavioural properties
We must show that the behavioural properties in Section 5.5 are true in the initial state of the system and are preserved by all enabled operations.From the initialization condition we know that T = f7 !g and hence that : has-circularity(T), is-complete(T) and dom T = f g initially; it is easy to check that all 7 properties are true under these conditions.We show below that Property 1 is preserved by the GiveProof operation (Fig. 2).The proofs for the other operations, and the proofs of the other properties, are similar (but generally easier).
Preservation of property 1 under GiveProof (t 0 ; p 0 ) Let = mk-TheoryManager(T; m; ) be the state in which the operation is invoked and 0 = mk-TheoryManager(T 0 ; m 0 ; 0 ) the state immediately after.It follows that and 0 are related by the postcondition of GiveProof (t 0 ; p 0 ).Suppose also that satis es the behavioural properties (the \Induction Hypothesis") and that the precondition of GiveProof (t 0 ; p 0 ) is satis ed (i.e., t 0 6 2 dom T); we are required to prove that 0 satis es Property 1.
To do this, we suppose that 0 = complete and show that is-complete(T 0 ).From the postcondition we know T 0 = T y ft 0 7 !p 0 g; = proven; s 0 = established It follows from s 0 = established and the postcondition that the theorems used by p 0 do not depend on t 0 in T; p 0 is a correct and complete proof; and every theorem used in p 0 has a proof in the theory and has status established.
From = proven and the induction hypothesis we know that T must be complete and have no circularities.From Lemma 3 in Section 4.4 and the facts above, it follows that T 0 also has no circularities.Finally, since rng T 0 = fp 0 g rng T and T is complete, it follows from the facts above and the de nition of is-complete that T 0 is also complete, as we were required to prove.

7 Relationship to other work
This work extends work done by others on formally modelling aspects of UI design (see 9] for a survey) by providing a proof method for verifying certain properties of UIs.
The method uses a state-based approach to the formal speci cation of interactive systems.
As has been argued elsewhere (e.g. 6, 17]), a state-based description on its own is generally inadequate or overly awkward for modelling interactive systems, and there are times when a trace-based description (in a language such as CSP or LOTOS) is more appropriate.While agreeing with the point in general, we believe that the state-based approach is ideal for \data driven" applications such as the one described above, and contend that it would be very di cult to give as succinct a de nition of the Theory Manager in a process-algebraic notation as we have given here.The method is well suited to the speci cation of interactive systems in which task goals can be expressed in terms of consistency and completeness conditions on the underlying con guration of objects, especially those systems in which the user takes primary responsibility for planning and carrying out the tasks.For a description of more general methods for analysing and modelling tasks, however, the reader is referred elsewhere (e.g.chapters 11-14 of 10]).This paper has been concerned with two aspects of usability: support for exible, nonproscriptive work patterns, and provision of useful, accurate task management information.Other dimensions of usability not touched on here include tolerance to human errors 19] and demands on the user's memory 7].

Conclusions
This paper has described a method for formally specifying and reasoning about aspects of UI design to do with process control and provision of task management information.The method is well suited to \data intensive" applications in which the system is being used to develop complex \con gurations" of interconnected objects, and for which task goals can be expressed in terms of properties of the underlying con guration of objects.The method includes proof obligations to check the accuracy of the task management information.The method could be used in conjunction with process modelling techniques, such as the use of state-charts as an intermediate design notation and the use of process engines provided by a variety of process modelling languages.Similarly, it could be used in conjunction with more general methods for UI design such as interactors 6].The `Theory Manager' application is a small but succinct example of how to apply the general method described in the paper, and illustrates a number of interesting aspects of formal modelling and veri cation of UIs.It is also an interesting application in itself, being to this author's knowledge the rst documented design of a theory management system that ensures logical soundness of the underlying theory store while allowing incomplete proofs and the possibility of circular reasoning.The ability to support and recover from \inconsistent" states, such as presence of circular reasoning in this case, can be vital to the usability of a system.The alternative strategy { of not allowing the system to enter inconsistent states { can force the user into highly convoluted and potentially confusing patterns of use, which can be tedious or even prohibitively complicated; such systems tend to be highly unpopular with users.Finally, we note that the techniques described in this paper can be applied at arbitrary levels of granularity: e.g. if access to the internal structure of proofs is available then we could track dependencies within proofs and support editing of individual lines within proofs (cf.Section 4.7 of 11]).Fine-grained process models can give better support for change management, for example, by limiting the extent to which changes need to be percolated through a design 15].In principle, the level of granularity is determined simply by what basic tools are available.In practice, however, the ner the level of granularity, the more complicated is the design and veri cation of the process model.

Figure 1 :
Figure 1: An example of circular reasoning.Note that each proof is complete and correct when considered in isolation, but that Theorems A and B are mutually dependent.
circular { indicates the theorem may have a circular proof unproven { indicates the theorem's proof is not yet nished proven { indicates the theorem's proof is nished but the theorem may not yet be fully established established { indicates the theorem is fully established This is modelled by the following type de nition: ThmStatus = fcircular; unproven; proven; establishedg

Figure 2 :
Figure 2: Operation for adding the proof of a theorem to the theory.

Figure 5 :
Figure 5: Operation for checking a theory The following lemmas are logical consequences of the de nitions above which are useful in the veri cation of the process model.Lemma1.A theory is complete if and only if it has no circularities and all of its theorems are fully established.8 T : Theory is-complete(T) , : has-circularity(T) ^8 t 2 dom T is-fully-established(t; T) Lemma 2. A theorem t 0 has a circular proof if and only if some reference loop involves t 0 .