Set Theory as a Semantic Framework for Object Oriented Modeling Prof. B. Cohen, Centre for Interoperable Systems Research City University, London (
[email protected]) Abstract The author has modeled complex systems in a variety of business contexts, from healthcare to telecoms, using a variant of Z. The notation, like Z itself, is a syntactically sugared form of ZF set theory but it permits the use of weak postconditions — a small, but crucially important, semantic device. The style of construction is very similar to that employed in Object-Oriented modeling, but it illuminates many dark corners of that paradigm, especially as concerns: composition, (multiple) inheritance, concurrency, invariance, inconsistency, emergence, modalities of interpretation, and the clinical aspects of enterprise modeling. This paper describes some of the author’s work-in-progress in these areas, and provides references to several models that have been published.
Introduction In this paper, the author reflects on his experience in object-oriented modeling using the style and notation developed by Professor S. A. Schuman at the University of Surrey [Sc1][Sc2]. No models are presented here, there being plenty in the literature already [Co1], [Co2], [Co3], [Gly]. The intent is to draw from this experience some insights into the practice of systems modeling that pertain whenever the object-oriented paradigm is invoked. These insights are mainly semantic in character but they also shed light on problems that frequently arise in praxis and in the mathematical foundations themselves. We start with a brief, technical introduction to simple (isolated) systems [Bun]. This is followed by a discussion of complex (composite) systems, where interaction, which is regarded as concurrent composition, can yield either emergent properties or inconsistency. Section 3 considers some other interpretations of composite models as their projections into different modalities. Implementation is then considered as the complex model formed by composing a model of a service with a model of a platform, which suggests that the traditional concept of refinement is not applicable. In section 5, we consider some of the problems raised by the modeling of anticipatory systems [Ros] from both mathematical and clinical perspectives. 1. The principles of systems modeling in set theory The subject of a set-theoretic model is the class of systems defined by: • the name of the class; • its state space, expressed as the product of some • state components, each of a set-theoretic type, mutually constrained by an • invariant, a first order predicate that is satisfied only by valid states;
•
its initialisation, an assignment of values to the state components that defines the state of any newly created system of the class; • the events (or operations) in which any system of the class may participate, each with • its name, unique to the class, • zero or more parameters, each of a type declared in the state space; • its precondition, a first order predicate governing the values of the parameters and state components for which the event is enabled; and • its postcondition, a first order predicate relating values of the state components after the event has terminated to values of the state components and parameters when the event occurred. Note that the invariant expresses a ‘global law’ — a property of the state space that may not be violated by any event in which the system participates. The pre and postconditions, on the other hand, express ‘local constraints’ — obligations imposed on the occurrence of each event. Such a model is consistent only if the local constraints guarantee the global law, i.e. no behaviour (sequence of events starting at the initial state) of any system of the class may ever reach a state that violates the invariant, which can be proved inductively by discharging the following proof obligations [Co5]: • that the invariant is satisfied by the initialisation. • for each event, that whenever it is enabled, it may terminate — i.e. that for every value of the state components (before the event occurs) and parameters that satisfy the invariant and the precondition, there exists at least one value of the state components (after the event occurs) that satisfies the invariant and the postcondition. Notes 1. The semantic domain here is entirely set-theoretic, i.e. the type of every state component and parameter is a set. However, sets of arbitrary structural complexity may be used, including powersets, relations, functions, and settheoretic models of such familiar types as sequences, bags, graphs, etc. 2. It is considered good style to express all invariants as relational constraints on, and between, state components and avoiding explicit quantification. 3. A clear distinction is drawn between types, which range over sets of values, and classes, whose instances are objects. Values are eternal and unchanging whereas objects retain their identity while changing their state. Thus, we eschew the practice of Smalltalk and several other O-O programming languages in which everything is an object. 4. We do not construct generic classes (or meta-models) even though some class structures, such as the name space, frequently recur. The main vehicle for reuse is set theory itself: it is the types that are generic, not the classes. 5. We do not quantify over events. Behavioural properties are derivable from the model, but we cannot represent event sequences in it. These semantic restrictions allow us to remain strictly within the domain of first order logic, but also exclude consideration of the evolution of the system itself (see nr. 5).
6. Throughout the construction of a class we assume that its instances will be isolated systems. This assumption is fictional but essential for intellectual manageability (as it is in all of science). Under it, interaction among systems is modeled by the explicit composition of their classes. 2. Composite Systems In order to model the interaction of two or more isolated systems, we must construct a class whose state space includes all the state components of each of the subsystems, together with any additional state components and invariants needed to express the additional interrelationships and constraints involved in their interaction [Bun]. That is, we take the product of their state components and the conjunction of their invariants. The events in which a composite system may participate may similarly be composed from its subsystem’s events, possibly extended with further parameters, pre or post conditions. Statically, this denotes the conjunction of all their preconditions and of all their postconditions. Dynamically, it can be thought of as synchronising the subsystems’ events, or as decomposing the event in the composite system. Notes 1. Clearly, in this framework, composition is an intellectual act, not an operator . All the consistency proof obligations must therefore be redischarged for each composite model, because the consistency of the composite system’s model is not guaranteed by the consistency of its subsystem’s models. These proofs are all still first order, but are not mechanically constructable from the proofs of the components. 2. If event postconditions are ‘strong’ — that is, if they insist that the values of all state components that are not affected by the event ‘remain unchanged’ after it — then the composition of such events is guaranteed to be inconsistent. This is the case with Z itself, which therefore cannot be used to construct models of composite systems in this way. The style developed at the University of Surrey allows weak postconditions, but imposes certain conditions that ensure the well-foundedness of the models [Sc3]. 3. This form of model composition corresponds to both subtyping and multiple inheritance in the object-oriented paradigm. However, there is no equivalent structure to the O-O concepts of message passing and object relations, which are simply not needed. 4. The repair of an inconsistent composite model also requires an intellectual act. There is no known unification theorem for set-theoretic models. Such inconsistencies reveal defects either in the enterprise being modeled or in the modeler’s understanding of that enterprise [Co4]. In either case, the resolution of the inconsistency requires the participation of the appropriate enterprise stakeholders, to whom the model’s consequences must be presented via one or more of its interpretations. 3. Interpretations Since the models are not generic, each has a specific frame of reference — that is, some system-in-the-world of which it purports to be a theory. In the set-theoretic
style, the names of classes, state components and events are chosen to suggest this intended frame of reference, which is further elaborated in informal comments attached to the model. The names of the types of components, however, are drawn from set theory itself and are independent of the frame of reference. Often, the model’s frame of reference is an enterprise, a part of the world in which agents offer their services to each other with a view to achieving some collective purpose [Co6]. In this kind of context, the parts and consequences of a model may usefully be interpreted in several different modalities, including: • temporal , the normal interpretation in which the model denotes behaviour, the set of sequences of events that it induces; • deontic , in which pre and post conditions on events are interpreted as the contractual obligations and responsibilities of agents who offer the service defined by the model. • linguistic , in which the state components and invariant are taken to define the semantic domain of the language comprising the set of sequences of events, and of the communicative acts from which these sequences arise. Notes 1. Under the temporal interpretation, all the usual properties of concurrent systems may be investigated, including liveness, safeness and fairness. It is very straightforward to translate a set-theoretic model into the notation of a temporal logic or a process algebra (although the converse does not hold). Of course, the decidability of any of these properties will depend on the domain structure, but as many models have finite domains, this is not usually a problem. 2. The resolution of inconsistency that arises from model composition often involves the imposition of constraints on subsystem models that are stronger than those to which they were subject when isolated. Under the deontic interpretation, this is tantamount to contract renegotiation, the parties having to find some compromise in which the new constraints are mutually acceptable. Of course, the model arising from any such agreement need not necessarily be consistent. The proof obligations here are essential checks on the fairness and validity of negotiated settlements. 3. The resolution of inconsistency often enriches the system state space which, under the linguistic interpretation, introduces additional complexity into the semantic domain which, in turn, increases the cognitive complexity of each of the services involved. The wise modeler therefore monitors the topological structure of the state space, and seeks frequently to simplify it — i.e. to endow it with ‘nice algebraic properties’ — for the sake of the eventual users of the services. It can be more effective to tackle cognitive issues at this stage than to wait for the ‘Human Computer Interface’ to become available. 4. The invariants of a composite model may be interpreted as the purpose of the enterprise and the pre and post conditions of its events as its business rules. Consistency proof therefore demonstrates that the rules achieve their purpose. 5. The interpretation of a subsystem model as a service description is particularly valuable when services are to be acquired from outside the
enterprise, as in outsourcing and open systems. 6. In both deontic and temporal modalities, a distinction is often sought between an obligation (a triggering condition) and a permission (an enabling condition). In set theory, preconditions are naturally interpreted as permissions and there is no obvious way of denoting triggers. However, most systems modeling formalisms, from classical systems theory to Petri Nets, suffer from this same limitation — an inability to capture, in Aristotelian terminology, efficient cause [Bu2]. This is a technical mathematical problem rather than a pragmatic one. The closure of a model that defines enabling conditions for an event, but does not insist that the event occur as soon as the conditions are satisfied, includes all the behaviours of the system in which the event does or does not occur when enabled. This stance accounts for an arbitrary delay between the enabling of an event and its occurrence thereby accommodating both relativity and failure, neither of which sits comfortably with the concept of an absolute trigger. 4. Implementations The notations of most object-oriented modeling techniques derive from computational (programming) languages. Systems satisfying models in such notations are usually implemented by compiling the language onto a suitable host. It is actually possible to translate any set-theoretic model directly into an executable logic program [], but the resulting programs are usually extremely inefficient and must be optimised by property-preserving transformations. The implementation of a set-theoretic model therefore requires an additional step, in which the intended target platform is itself modeled (as an unpopulated computational system) and composed with the service model to produce an interaction model [Hol]. This act of composition must explicitly relate the resources of the platform to the state space of the service, each events of the interaction model being decomposed into a pair of events, one in each ‘subsystem’, if possible. This composition defines all the integrity constraints that the implementation must maintain, but it also reveals the purposes of the service/enterprise that the computer system cannot itself guarantee. A common phenomenon in implementation is the temporary violation, and subsequent repair, of an invariant. For example, in distributed databases, global integrity constraints may be violated during update of individual fields and restored after all the updates have been completed (coend), access to the affected fields being locked out for the duration of the disturbance. It is clear from this formulation that such events are durative, that is, occupy, and potentially overlap with each other in, time. In an interaction model, this phenomenon would manifest as a composition of the update events in the distributed platform with the abstract event in the service model, the proof obligation being to to demonstrate that the abstract invariant be satisfied by all traces of the update events, operating concurrently. This kind of proof would typically performed over an interpretation of the model in a temporal modality, but such an interpretation is not, in general, possible in settheoretic models in which the post-conditions are ‘strong’, i.e. where those state components not directly referred to by an event are explicitly stated to ‘stay unchanged’. The variant of Z developed by Schuman et al [Sc3] uses ‘weak’
postconditions precisely for this reason. Notes 1. This view of implementation challenges some basic tenets of computing, particularly those concerned with the refinement of specifications into code. A fundamental assumption of refinement is that it commutes over composition, i.e. that the composition of correct implementations of two specifications will satisfy the composition of the specifications. The problem arises because the composition of services in an enterprise usually requires those services to interact with each other. Their models cannot therefore be orthogonal and their composition is not necessarily conservative (otherwise the collection of services would be a mere aggregate, not a system [Bu1). In other words, the composition of service descriptions introduces additional constraints on each. However, implementation involves the composition of a service description with a platform model, which also introduces additional constraints on each — not necessarily the same ones as those imposed by service interaction. Clearly, implementation does not commute over composition. So much for ‘open systems’! 2. An effective treatment of service composition will require that every service, and every platform, be provided with a public model, expressed in forms that admit composition and the discovery of inconsistency. This has serious implications for the OMG, CORBA, and Java communities, where external service descriptions are not expressed as formal models, and platforms (such as Java) are not provided with formal semantics. 3. These problems are not imaginary. They have been occurring for over 30 years in the telecommunications industry, where they are known collectively as feature interaction [Ca1]. Composition seems to impact feature interaction in at least five different ways, which can be used to provide a useful classification of known pathologies [Ca2]. 5. Open Questions All modeling techniques, including set theory and O-O, that take the system state space as their subject, suffer from similar analytical limitations which, although clearly visible in set theory, are obscured (sometimes deliberately) in most commercial O-O tools. These limitations are strongly related to open problems that have already been identified in other disciplines. Two of the most important are anticipatory systems and clinical intervention. The enterprises that we are called upon to model often belong to that class of systems known as anticipatory [Ros]. Such a system behaves as if it has internal models of itself and of its environment that it consults before deciding on its response to an event. These models are, of course, just theories which eventually must bifurcate with the reality to which they refer. In the context of business enterprises, this is known as strategy. The modeler encounters strategy in two different ways: as an attribute of the system itself; and as a consequence of the act of modeling. Both require structural operations on the model itself which an algebraist would recognise as theory morphisms. Set theory provides no mathematical assistance for modeling systems that can alter their own models. The search for a suitable mathematical framework
is currently being pursued [Dub]. Such systems bear some resemblance to those in the continuous world that classical systems theory treats with tensor calculus, but the question remains open. For many years, systems analysts have drawn attention to their clients’ annoying tendency to change their minds while analysis is in progress. It is clear from our earlier discussions of composite systems that such changes might well be stimulated by the modeler’s revelation of inconsistencies among the purposes, services and agents of the enterprise itself. Here, the modeler’s relationship to the enterprise is not that of the objective scientist to an unconscious reality (which has itself been a questionable philosophical stance since Heisenberg). As the demand for enterprise-wide integration increases, so do the scope of the model, the complexity of its state space, and the likelihood that it will reveal conflicts (and opportunities) that the enterprise itself had failed to detect. Under these circumstances, modeling becomes a clinical act — the modeler must diagnose, and attempt to treat, the subject’s neuroses and psychoses. The relationship becomes much more similar to that between psychoanalyst and patient, confronting both parties with many of the potential analytical pitfalls identified by the likes of Freud and Lacan [Box]. One aspect of this relationship has been identified with the tendency of software to ‘construct the reality’ of its users [Flo], but the problem arises well before software is constructed. This similarity between psychoanalysis and theory morphism is anathema to many practitioners on both sides of the disciplinary divide. It is therefore a totally unexplored field of research, but one that might have results of unexpectedly wide applicability. References [Box] Boxer, P. and Cohen, B. Analysing the lack of Demand Organisation, Proc CASYS ‘97 (to appear). [Bu1] Bunge, M. Treatise on Basic Philosophy (8 vols.), D. Reidel, 1974-80. [Bu2] Bunge, M. Causality, D. Reidel, 1986. [Ca1] Cameron, J. and Velthuijsen, H: Feature Interactions in Telecommunications Systems, IEEE Communications Magazine, August 1993. [Ca2] Cameron, J. and Cohen, B. Formal Approaches to Feature Interactions, Tutorial Notes, FORTE/PSTV'96, Kaiserslautern, 1996. [Co1] Cohen, B. and Mannering, D., The Rigorous Specification and Verification of the Safety Aspects of a Real-Time System, Proc. Compass ‘90, 1991. [Co2] Cohen, B. The CBM Co.: A Formal Model of a Dataflow Design, Proc. “Putting into Practice Theories and Tools for Formal Specification”, Université de Nantes, 1992. [Co3] Cohen, B. Formal Modelling of the Principles Governing the Confidentiality of the Patient Record, Proc. 'Toward an Electronic Patient Record', Nashville 1997 (to appear). [Co4] Cohen, B. Models and Modelling Frameworks in Health Care Informatics, Proc. 'Toward an Electronic Patient Record', San Diego and London, 1996.
[Co5] Cohen, B. and Pitt, D. Proof Obligations 2: State-Based Systems, Proc. Colloq. on High Integrity Systems, University of Warwick, 1990. [Co6] Cohen, B. The Description and Analysis of Services as Required and Provided by their Agents, http://www.cs.city.ac.uk/homes/bernie/services.html [Dub] Dubois, D. Concept and Method of Incursion and Hyperincursion, Proc. CAST ‘96. [Flo] Floyd, C. et al, Software Development as Reality Construction, Springer Verlag, 1991. [Gly] Glykas, M., Wilhelmi, P. and Holden, T. The Combination of Object Oriented Design Techniques with Object Oriented Formal Methods: ORML + Schuman Pitt, CAISE 93, Paris. [Hol] Holland, J., Sønksen , P., Carson, E. and Cohen, B. The Directorate Information System at St. Thomas‘ Hospital, Intl. Conf. on Requirements Engineering, Colorado Springs, 1994. [Ros] Rosen, R. Anticipatory Systems, Pergamon, 1987. [Sc1] Schuman, S.A. and Pitt, D.M. Object Oriented Subsystem Specification, in Program Transformaion and Transformation (ed. Meertens), Proc. IFIP Working Conf., North-Holland, 1987. [Sc2] Schuman, S.A., Pitt, D.M. and Byers, P.J.Object Oriented Process Specification, in Specification and Verification of Concurrent Systems (ed. Rattray), Springer-Verlag, 1990. [Sc3] Schuman, S.A. and Pitt, D.M. Object Oriented Formal Specification and ‘the rest stays unchanged’, BCS/FACS Workshop on Formal Aspects of Object-Orientation, London, 1993.
