Refining Object-Oriented Invariants and Dynamic Constraints Jamie Shield Ian J. Hayes School of Information Technology and Electrical Engineering, The University of Queensland, Brisbane, Australia 4072. Email: {jims,ianh} @ itee.uq.edu.au Abstract An invariant is a constraint on a class which holds for each externally accessible state of its instances. A dynamic constraint is a dual-state property dictating before to after state behaviour that all methods must adhere to. Both invariants and dynamic constraints are of practical benefit as they allow explicit decla- ration of high-level behavioural constraints on a class and all its sub-classes. In this paper, formalisations of invariants and dy- namic constraints are provided in the refinement calculus. Each is separated into coerced (specification) and extant (implemented or documentation) categories. Refinement rules are provided for strengthening invariants and dynamic constraints. Two separate development paths are identified: (behavioural) sub-classing and private refinement. Refining a class may violate its invariant or dynamic constraint. Sub-classing is a constrained form of refine- ment that maintains these properties. Revised refinement laws are provided. Private refinement is an alternative to (behavioural) sub-classing. It also maintains properties such as invariants and dynamics constraints and foregoes the constraints of sub-classing. The disadvantage is that private refinement can only be used to implement a class. Keywords: Object-orientation, refinement calculus, invari- ants, history properties. 1 Introduction This paper describes the formalisation of invariants and dynamic constraints in the refinement calculus. A class in- variant is a predicate that defines a single-state property that must be upheld by the instances of a class at each externally accessible (i.e., client accessible) state. That is, it must be established upon instantiation and at the conclusion of the execution of any method calls. Dynamic constraints are dual-state properties that must be upheld by all consecutive states. They are also known as explicit history properties [11], transaction specifications [9], and transition invari- ants [19, 18]. A dynamic constraint is a relation between the initial (pre-) and final (post-) states that all methods of the class must adhere to. Consider the following model of a bank’s credit account 1 . One of the system’s functions is to record the transactions on credit accounts. To achieve this, the following class Transaction is introduced using the given type Date. class Transaction is field amount : Z field date : Date constructor Transaction(amnt : Z, when : Date)= amount := amnt; date := when end The amount field is an integer as the Transaction class must be able to store deposits (-ve) and withdrawals (+ve). The class defines a special constructor method which is used to instantiate the class. Constructor methods are called once and they are the first method called. The constructor meth- ods cannot assume anything about the object’s variables, however, it may reference the parameters of the constructor. The system also has a CreditAccount class. The class has an integer field balance representing the amount of credit that customer has used. The invariant specifies that this field is limited above by a given constant LIMIT and below by zero. The class also has a field t which maintains a sequence of transactions performed on the account. The dynamic con- straint ensures that the sequence of transactions can only be extended. For any method, the initial value, t 0 , of the se- quence of transactions must be a prefix of the final value, t, i.e., using the infix prefix relation, t 0 prefix t. This ensures that methods cannot delete any transactions in the history. The class has a constructor which ensures the balance is initially zero and the transaction history is initially empty 1 This example is derived from one presented by Mikhajlova and Sek- erinski [14]. Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02) 0-7695-1850-8/02 $17.00 © 2002 IEEE