Meta-Proof for Structured Specifications

Meta-Proof for Structured Specifications Nuno Amálio Susan Stepney Fiona Polack Department of Computer Science, University of York, Heslington, York, YO10 5DD, UK. [namalio susan fiona]@cs.york.ac.uk Abstract We are working on a practical, template-based approach to the formalisation of object-oriented models. In previous papers, which demonstrate the approach, we have asserted that the formal proofs required for consistency checking and analysis of the model, are also amenable to a template-based solution, using modular metaproofs. In this paper, we explain the meta-proof concept, and illustrate its use on the simplest of the Z consistency checks, the initialisation theorem. Keywords: Consistency, proof, Z, UML 1 Introduction The engineering of systems that are acceptably correct is a hard problem. Modelling approaches that are good for practical, large-scale system development, are not amenable to formal analysis and consistency checking, whilst formal analysis requires a level of competence and expertise that is not common in commercial systems development communities. Our long-term goal is to make formal analysis practical. Starting from object-oriented specification models (for convenience, we focus on UML diagrams), we have presented elsewhere a modular approach for translating diagrams into a formal abstract model of the required system, in the Z notation [Amálio et al. 2003, Amálio et al. 2004b]. We have also presented the model analysis aspect of our work, using Catalysis [De Sousa & Wills 1998] snapshots and formal analysis techniques to consistency-check and analyse both the UML and the Z models [Amálio et al. 2004a]. In these earlier works, we assert that model consistency checks and formal analysis is amenable to meta-proof. In this paper, we explain the meta-proof concept, and illustrate its use on the simplest Z consistency check, the initialisation theorem. Supported by the Portuguese Foundation for Science and Technology under grant 6904/2001. 1

1.1 Formal and Semi-formal methods As is well-known, the primary advantage of formal development is that it allows precise modelling of and formal reasoning about systems. However, formality is considered to be difficult, requiring a high level of expertise to use in practical systems development. It could be contended that, because formality requires understanding of the underlying mathematics, and particularly of the fixed semantics of the mathematics, it is difficult for commercial developers to express their ideas about systems, and, in particular, to apply correct mathematical analysis to the models. Semi-formal methods, comprising annotated diagrammatic techniques, are much more popular in practice, and require significantly less expertise in their everyday use. However, they have the disadvantage that the semantics is almost always unclear or ambiguous. (Indeed, a semi-formal method can be defined as one with a formal syntax, but no agreed formal semantics.) Developers perceive semi-formal models as being easy to construct and understand, precisely because they can impose their own interpretation on the notations; there is little intellectual overhead in making the model express the imagined system. However, as most developers discover to their cost, the flexibility of semi-formal semantics also allows another person to interpret the semi-formal diagrams as expressing a different model, which may be an incompatible interpretation of the required system. Many researchers have attempted to exploit the complementary advantages of formal and semi-formal methods, so-called integrated methods. A popular integration approach is to provide a formal mapping from the semi-formal diagram components to expressions in a formal specification language. This approach is automatable, though the developer has to add constraints and other features not expressible in the semi-formal diagrams to the generated formal model. A problem with this approach is that it imposes a particular formal semantics on the semi-formal diagram components, and, to the non-formalist, the semantics that has been imposed is not clear; the diagram still looks the same, but the formal expression only captures one possible meaning of the model. Apart from the danger of concealing the applied semantics, this approach has the disadvantage of inflexibility; if the developer does understand what semantics is required, and it is not the same as that in the translation, it is very hard to change the formal model to represent the required semantics. Our approach circumvents these problems. We represent the formal mapping as instantiable templates; they represent the interpretation of the semi-formal components being followed. We also provide configurability, in the form of alternative templates, so that the appropriate semantics can be selected or substituted at any appropriate point. This gives us, effectively, a set of formal mappings, from which users can select the one(s) that meets their needs. In addition, new semantic interpretations can be built by changing existing templates, or by building new ones. The naive user never needs to confront the underlying formal specification; a basic set of (automatable) template instantiations give a formal model from diagrams with vanilla semantics. More sophisticated users can explore alternative semantics, express extra component and system properties, and tap into the power of the formal model; because the 2

specification is all modular, even advanced users need only be exposed to the incremental changes to the model under construction. In our approach, model constraints and other features, not expressible with diagrams, are added to the formal model also by instantiating templates. This allows us to control the structure of our specification, minimises the need for users to directly work with the formal model, and leaves open the opportunity for the expression of model constraints by non-experts which involves designing an approach (possibly involving both text and diagrams) for the expression of constraints by non-experts; these constraints would then be added to the formal model by instantiating templates. Templates also allow us to represent model consistency checks. (In our approach, these are proof-obligations or consistency conjectures.) Associated with component and system template representations, are these template consistency conjectures that must be discharged to ensure the consistency of the model s components and, ultimately, the whole system. These template conjectures and representations offer us the opportunity to reason at the template-level; we call this reasoning meta-proof. We demonstrate (here, for the simple case of initialisation only) how the meta-proof approach simplifies the consistency proof of the whole system to a demonstration of the consistency and correctness of the added properties. The additional proof effort required for more sophisticated models is proportional to the incremental changes to the model. To achieve this we have developed template meta-theorem and -lemmas which can be instantiated to provide verification of the original model. The meta-proof approach can also be applied to the validation-related proofs (checking that the right system has been modelled). 2 Templates and Meta-Proof The structure of our object-oriented (OO) Z specifications is captured by templates. Our templates are parametric descriptions of Z phrases. Actual Z phrases are obtained by instantiating templates, which involves providing names for the template s parameters. Every Z phrase of our OO specifications is the result of instantiating a template. Our templates represent two kinds of Z phrases: descriptions and conjectures. Descriptions are phrases that contribute to the overall description of the specified system. Conjectures are checks (or proof-obligations) that are set upon the specification; conjectures in the template form are called meta-conjectures. Our template representations establish a meta-layer of our Z specifications. We have developed a set of description templates to represent OO models in a Z promoted state and operations specification [Amálio et al. 2003, Amálio et al. 2004b], and to represent an underlying semantics of UML diagrams. Additional configuration templates express alternative interpretations of semantic elements of the UML diagrams; for example, different models of association, aggregation and composition, including the deletion propagation property of the latter. Our approach to represent OO models in Z extends those reviewed in [Amálio & Polack 2003]. 3

In terms of consistency checking, some formal languages, typically those whose use is tightly constrained, such as B, have a clearly defined set of necessary consistency checks [Abrial 1996, Appendix F], relating to the need to establish the state invariant in the initial state and all states accessed by operations. However, Z is a relatively unconstrained formal notation; it has usage conventions, but few methodical rules. Most authors are agreed that consistency checking includes checking the existence of at least one state, usually combined with an initial state check, and checking the feasibility of each operation (precondition investigation); system-specific checks can be stated as conjectures which express system properties in the specification [Woodcock & Davies 1996]. In addition, refinement imposes its own proof obligations. We have developed a set of meta-conjectures, that can be instantiated during this translation process, to provide these consistency proof obligations on the generated Z specification, which in turn provides consistency checking of the original UML model. Under our template-based approach, there are additional consistency checks arising from the configurations, such as the correctness of deletion propagation in the presence of a particular interpretation of composition [Amálio et al. 2003]. These meta-representations (conjectures and descriptions) offer us the opportunity to reason at the template (or meta) -level, i.e. before any actual specification has been generated. Meta-Proof is, thus, the proof of properties at the meta-level, with Z in the template form. This allows us to prove or simplify meta-conjectures to establish what we call meta-theorems and meta-lemmas. Meta-proof allows us to minimise the overall proof effort; meta-theorems and -lemmas establish results that have been proved once in advance and can be used many times so that modellers don t have to it again and again. In many cases, many of our checks are simply true by construction, by appeal to a meta-theorem or meta-lemma. Figure 1 sketches the overall process, from a UML model to a set of instantiated templates providing a Z specification, associated conjectures, and their proofs. For reasons of space, we do not present the details of the earlier work on templates for translation of UML models and semantic configuration. We wish to demonstrate simply the concept of meta-proof. 3 Applying Meta-Proof: initialisation conjecture Our OO Z specifications follow a classic Z state and operations style. The main structural units of our specifications, class intensions and extensions 1, associations, and systems, are abstract data types (ADTs), each comprising a description of state and operations upon the state. To check the consistency of state descriptions in Z, we prove initialisation conjectures. An initialisation conjecture is of the form: State StateInit 1 In our approach, classes have a dual representation. Class intension defines the properties shared by the objects of that class (e.g. Customer of figure 2 has properties name, address, and type). Class extension defines the class in terms of currently existing objects (e.g., Customer is {Ralph, John, Alan}). 4

Figure 1: The template instantiation process. The user provides a UML model, configuration information (if empty, a default configuration is chosen) and Z annotations. The templates are instantiated to provide a specification, conjectures, and residual conjectures after meta-proof. If there are no Z annotations, the residual conjecture is empty. This says that there is some valid instance of State satisfying its initialisation; hence the model of state is consistent: at least one valid instance of state exists. Our specifications are structured with views, following a views structuring approach for Z [Jackson 1995]. Each view addresses one particular aspect of OO models. We have the following views: structural, intensional (defines class intensions), extensional (defines class extensions), relational (defines associations), and global (defines systems). In the following, we apply the meta-proof concept to the initialisation conjectures of the extensional, relational, and global views. Here, we use the simplest system initialisation: in the initial state of the system there are no objects; [Amálio et al. 2004b] also supports initialisations with objects in the initial system state. In the following, we make use of special notation. To represent templates, we introduce extra symbols; this is briefly summarised in appendix A (see [Amálio et al. 2004b] for further details). We also introduce extra Z notation. We write, P[x := val], to denote the Z expression that results from substituting the free variable x in P by the value val 2. 3.1 Extensional View Class extension defines the set of existing objects of the class, and a mapping from these objects to their internal state. This is captured by the state extension generic (names of extensional definitions are preceded by S) of our toolkit: 2 We resort to this special notation because in Z the usual logical substitution operator symbol, /, is used to denote variable renaming in a schema reference. 5

SClass [OSET, OSTATE] objs : P OSET objst : OSET OSTATE dom objst = objs The state template of class extension, S<Cl> SClass[<CL>Os, <Cl>][<cl>s/objs, <cl>st/objst] [ <constraint> e ] captures a generic instantiation of the SClass generic. Optionally, extra constraints may be added (constraint list above); these represent the extensional invariant of the class. The initialisation template, S<Cl>Init == [ S<Cl> <cl>s = <cl>st = ] initialises both the set of existing objects, and the set of object to state mappings to the empty set. The initialisation meta-conjecture for class extension is: S<Cl> S<Cl>Init Given the meta-conjecture and -descriptions above, we do some meta-proof, and our initialisation meta-conjecture reduces to: [ <constraint> e ] [<cl>s :=, <cl>st := ] All we are left to prove is that the extra constraints hold in the initial state. This establishes a meta-theorem. The detailed proof is given in [Amálio et al. 2004b]. The proof is trivial, we simply apply the one-point rule (see [Woodcock & Davies 1996]), discharge the true predicates, and we are left with the extra constraints. In many cases, there are no extra extensional constraints. Thus, the constraint list is empty and the meta-conjecture above reduces to true. This establishes a meta-lemma: the initialisation conjecture of a state extension without extra constraints is true. This gives us a nice property, for these particular cases, the instantiated initialisation meta-conjecture is true by construction. Hence, no further proof at the instantiation level is required. 3.2 Relational View The relational view contains association definitions, which specify relations between classes. In this paper, we use the vanilla interpretation of associations, where an association is seen as a mathematical relation between sets of class objects, which denote a set of object to 6

object mappings. This is captured by the association state template (names of association definitions are preceded by A): A<Assoc> <assoc> : <Cl A >Os <Cl B >Os [ <constraint> e ] Optionally, again, extra constraints can be added. The initialisation template of association state, A<Assoc>Init == [ A<Assoc> <assoc> = ] simply initialises the set of object mappings to the empty set. The initialisation meta-conjecture is: A<Assoc> A<Assoc>Init In the same way as for the class extension, the meta-conjecture simplifies to, [ <constraint> e ] [<assoc> := ] establishing a meta-theorem. Once again there is a meta-lemma: if there are no additional constraints, then the instantiated meta-conjecture is true by construction. 3.3 Global View In the global view we define the system. The system performs the composition of the system s components (classes and associations), and includes constraints of global scope. This is expressed in the system template: System [ S<Cl i > ] + ; [ A<Assoc i > ] [ ConsistencyA<Assoc i > ] [ Constraint<ConstName> ] In the predicate, each name refers to other schema template. The first to the association consistency constraint template, the second to the global scope constraint template (see [Amálio et al. 2004b] for details). The system initialisation is the initialisation of the system s components. This is expressed in the template form as: SysInit == System [ S<Cl i >Init ] + [ A<Assoc i >Init ] 7

Here we include System, the after state of the System schema, so that the predicates of the system schema are taken into account in the meta-conjecture (a system initialisation should satisfy the system s constraints). The system initialisation meta-conjecture is simply: System SysInit Assuming that component initialisation conjectures have been proved, the meta-conjecture reduces to (see [Amálio et al. 2004b] for details): [ Constraint<ConstName> ] [ [ <assoc i > := ], [ <cl i >s := ] +, [ <cl i >St := ] + ] This establishes a meta-theorem: to prove the initialisation of the system, one just need to show that the constraints of global scope hold in the initial state of the system (again assuming that component initialisation conjectures have been proved) 3. If there are no constraints of global scope, then the meta-conjecture reduces to true; in this case, the system initialisation conjecture is true by construction; this establishes a meta-lemma. 4 Example: making use of meta-theorems To illustrate the use of templates and meta-theorems, we define a trivial class diagram, describing a trivial bank system, figure 2. Customer represents the bank s customers; the attributes record the name of a customer, its address, and type (either company or personal). Account represents the accounts managed by the bank; the attributes record the number of the account (accountno), the balance of the account, and the type of the account (either current or savings). The association Holds relates Customer s and their Accounts; a Customer may have zero or more accounts; an Account must have one customer. Figure 2: The example UML model. See text for various Z annotations. The following terminology is used to refer to the results of proving conjectures: 3 Everything else, including the association consistency constraints, are discharged at the meta-level. 8

true by construction it is guaranteed to be true, there is a meta-theorem or -lemma establishing the result. trivially true the proof is trivial and the Z/Eves prover [Saaltink 1997] can do it automatically. In the following, we make an incremental development of the formal model of the bank system, comprising the following steps: 1. The first increment results from the generation of Z from the UML class diagram above, by instantiating our templates. Essentially, in this increment, the model has no invariants. The initialisation conjectures of this system are true by construction. 2. We add some constraints to the model. As a result, some initialisation conjectures become trivially true. 3. We add one constraint to the model that makes related initialisation conjectures untrue. 4.1 Z from the UML Class Diagram The model generated directly from the UML class diagram is given in Appendix B. The initialisation conjectures of this model are all true by construction. In the intensional view, the state schemas have no predicate, hence, the initialisation conjectures are true. In the extensional, relational and global views, we use our meta-lemmas to conclude that the initialisation conjectures are true by construction. 4.2 Adding Constraints We want to represent in our model the following system constraints: 1. Accounts of type savings cannot have negative balances. 2. Customers of type company cannot have accounts of type savings. The first constraint is local to the class Account, and can be expressed in the intensional definition of the class. The intensional state of Account is updated with this constraint to yield (the predicate expression is provided by the user): Account accountno : ACCID balance : N type : ACCTYPE type = savings balance 0 9

The initialisation theorem of Account, Account AccountInit, is trivially true. The second constraint has a global scope as it involves the classes Customer, Account, and the association Holds. To express this constraint, we instantiate the global constraint schema template, to yield: ConstraintCompanyNoSavings SCustomer; SAccount; AHolds {oc : customers (customerst oc ).type = company} holds {oa : accounts (accountst oa).type = savings} = The name of this schema would be added to the predicate of the System schema. Hence, we need to re-check the system initialisation conjecture. Applying our meta-theorem, the system initialisation conjecture reduces to, ConstraintCompanyNoSavings [customers :=, customerst :=, accounts :=, accountst :=, holds := ] which is trivially true; the constraint holds for the empty initialisation. 4.3 One constraint that makes some initialisation conjectures untrue We look at the third increment to our model, adding the constraint that the total balance of the bank (the sum of the bank s accounts balances) must be greater than 0. This can be expressed as an extensional invariant of the class Account. The extension of account with this constraint becomes: SAccount SClass[AccountOs, Account][accounts/objs, accountst/objst] Σ{a : accounts a (accountst a).balance} > 0 Here we use the generic definition Σ from our toolkit (see appendix B.1), to describe the constraint. We need to re-prove the initialisation conjecture of SAccount: SAccount SAccountInit By applying our extensional meta-theorem, the conjecture reduces to, Σ > 0 which is clearly false; the constraint expressed in the predicate does not hold for the empty initialisation. 10

To resolve this, we can try to relax the constraint to greater or equal than 0, which holds for the empty initialisation; this would have to be clarified and agreed with the customer of the system. If the constraint can not be relaxed, then we need another initialisation, which can be defined by using alternative initialisation templates, consequently, we would need meta-theorems supporting these alternative initialisations; here the obvious initialisation is to have one customer and one associated account, where the account balance is greater than 0. 5 Conclusions and future work Our template approach provides a plug-and-play formalisation of UML models. We can use the same template approach to produce consistency conjectures, and we can discharge much of the proof at the template level. The constrained structure of the Z specification that results from template instantiation allows many meta-theorems to be used, simplifying the proof effort. The remaining proofs are proportional in size to any added constraints not derived directly from the UML model. This paper demonstrates the use of meta-proof for (a subset of) the initialisation proof obligations. We have used the same approach for operation precondition obligations [Amálio et al. 2004b], consistency obligations of statecharts against class diagrams, and UML composition (deletion propagation) conditions. We are extending the approach to permit more sophisticated proof obligations, including model validation using snapshots [Amálio et al. 2004a] and to refinement, including its relationship with OO specialisation (sub-classing), and linking to different interpretations in one diagram (for example, refining associations to method calls and to relational references in different parts of the diagram). We are also extending the template approach to cover more UML diagram styles, including sequence diagrams capturing concurrent behaviour. The formal translation approach could clearly be automated. This would be necessary for use on practical development projects. Currently we hand-instantiate the templates, and use Z/Eves and ProofPower [Arthan] to perform the various proofs, and validate our template-level meta-proofs. Each configurable template captures the semantics of a particular interpretation of a particular component in UML terms, it is a precise expression of a particular stereotype, based on a particular core component. For even a non-formalist, this can open the way to much more powerful use of the UML notations (so long as configuration templates have meaningful names), exploiting the power of the plug-and-play formalisation. References [Abrial 1996] J-R. Abrial. The B-Book. CUP, 1996. 11

[Amálio & Polack 2003] N. Amálio and F. Polack. Comparison of formalisation approaches of UML class constructs in Z and Object-Z. In ZB2003,: Formal specification and development in Z and B, Turku, Finland, volume 2651 of LNCS, pages 339 358. Springer, June 2003. [Amálio et al. 2003] Nuno Amálio, Susan Stepney, and Fiona Polack. Modular UML semantics: Interpretations in Z based on templates and generics. In Hung Dang Van and Zhiming Liu, editors, FACS 03 Workshop on Formal Aspects of Component Software, Pisa, Italy, September 2003, volume 284 of UNU/IIST Technical Report, 2003. [Amálio et al. 2004a] Nuno Amálio, Susan Stepney, and Fiona Polack. Formal proof from UML models. In ICFEM 04, Seattle, USA 2004, LNCS. Springer, 2004. [Amálio et al. 2004b] Nuno Amálio, Susan Stepney, and Fiona Polack. A modelling and analysis framework for sequential systems I: Modelling. Technical Report YCS-2004-???, University of York, 2004. to appear. [Arthan] R.D. Arthan. The ProofPower web pages. http://www.lemma-one.com/proofpower/- index/index.html. [De Sousa & Wills 1998] D. De Sousa and A. C. Wills. Object Components and Frameworks with UML: the Catalysis approach. Addison-Wesley, 1998. [Jackson 1995] Daniel Jackson. Structuring Z specifications with views. ACM Transactions on Software Engineering and Methodology (TOSEM), 4(4):365 389, 1995. [Saaltink 1997] M. Saaltink. The Z/EVES system. In ZUM 97: The Z Formal Specification Notation, volume 1212 of LNCS. Springer, 1997. [Woodcock & Davies 1996] J. C. P. Woodcock and J. Davies. Using Z. Specification, Refinement, and Proof. Prentice Hall, 1996. A Template Notation The template notation used here is as follows. 12

< X > denotes one template parameter of type name; X is to be substituted by a name when the template is instantiated. < Exp > e denotes one template parameter of type expression; Exp is to be substituted by a Z expression when the template is instantiated. [ expression ] s denotes a list of meta-expressions; [ ] denotes a meta-expression list that may be empty; [ ] + denotes a meta-expression list with at least one element. B The vanilla specification of the bank example Here we present the Z model of the bank example generated directly from the class diagram of figure 2. The Z model is generated by hand-instantiating templates of our vanilla interpretation. In the following, we present some definitions of our Z toolkit that are used in the Z model, and the actual Z model for each view of our structuring, namely, structural, intensional, extensional, relational, and global. B.1 Toolkit Definitions Given Sets [OBJECT ] Association Multiplicity Generics Rel,1 [X, Y ] == X Y Rel 1, [X, Y ] == {rel : X Y rel Rel,1 [Y, X ]} Other Generics [L] Σ : (L Z) Z Σ = 0 l : L; n : Z; S : L Z l dom S Σ({l n} S) = n + ΣS B.2 Structural View Class Object Sets CustomerOs, AccountOs : P OBJECT disjoint CustomerOs, AccountOs 13

B.3 Intensional View Types of Class Attributes [NAME, ADDRESS, ACCID] CUSTTYPE ::= company personal ACCTYPE ::= current savings Class Customer Customer name : NAME address : ADDRESS type : CUSTTYPE CustomerInit Customer name? : NAME address? : ADDRESS type? : CUSTTYPE name = name? address = address? type = type? Class Account Account accountno : ACCID balance : N type : ACCTYPE AccountInit Account accountno? : ACCID type? : ACCTYPE accountno = accountno? balance = 0 type = type? B.4 Extensional View Class Customer SCustomer == SClass[CustomerOs, Customer][customers/objs, customerst/objst] SCustomerInit == [ SCustomer customers = customerst = ] Class Account SAccount == SClass[AccountOs, Account][accounts/objs, accountst/objst] SAccountInit == [ SAccount accounts = accountst = ] 14

B.5 Relational View Association Holds AHolds == [ holds : CustomerOs AccountOs ] AHoldsInit == [ AHolds holds = ] B.6 Global View System ConsistencyAHolds SCustomer; SAccount; AHolds holds Rel 1, [customers, accounts] System SCustomer; SAccount; AHolds ConsistencyAHolds The global initialisation is: SysInit == System SCustomerInit SAccountInit AHoldsInit 15