Modelling and Testing OO Distributed Systems with Temporal Logic Formalisms Sita Ramakrishnan and John McGregor School of CSSE, Monash University, Australia Dept Computer Science, Clemson University, USA +61-3-9903-2072
[email protected],
[email protected]
ABSTRACT Our ability to test a distributed system is directly related to the quality of the system's speci cation. The speci cation must be complete. That is, the system should have a speci ed behavior for every point in the input space. The speci cations of all of the components in the system must be consistent with each other. Ultimately the speci cation must accurately (i.e., correctly) model the real system. The usefulness of a modeling language is directly related to its ability to express the constructs required. For modelling distributed systems, time is often a critical dimension of the speci cation. Concurrent and distributed systems require speci cation languages that can express information about the temporal ordering of a series of actions. OCL does not currently have operators for expressing such sequences. This makes it impossible to express complete invariants for distributed OO components. The contribution of this paper is to describe the status of our work in modelling and testing OO Distributed Components with temporal logic formalisms, and our extension to the Object Constraint Language (OCL), a part of the Uni ed Modeling Language (UML), to support the expression of temporal constraints.
1 INTRODUCTION Verifying that test executions are correct is an important activity in the testing process. Once test executions are generated, they must be checked to determine if the system behaves according to its speci cation requirements. A large number of test executions must be examined to achieve coverage of the system space during execution. Concurrent programs introduce additional coverage criterion for veri cation such as the ordering and timing of events during execution. Test oracles based on temporal speci cations can be used to automatically verify that system behaviour conforms to speci cation. Concurrency and communication are two of the key features of distributed systems. These features can make systematic testing of distributed systems a complex task. As part of our research team work at Monash University, we [2] have developed testing techniques using an extended version of state charts for the speci cation of the communication and concurrency aspects of distribution systems. We used JavaCC (Java Compiler Compiler) to write a parser for this extended state chart notation. In this paper, we focus on temporal aspects of distributed systems. In the next subsection, we cover some background material on modelling languages, linear temporal logic, and interval temporal logic. Here, we report mainly from the work by [14] regarding linear temporal logic. From section 2, we discuss our approach in using temporal logic formalism for modelling and testing of concurrent and distributed OO systems. 1
1.1 Background A reactive system such as a production cell environment consists of a number of components which are designed to interact with one another and with the system's environment. In formal semantics, such systems are treated as mathematical structures such as functions and relations. The set of desired behaviours (properties) that these systems are supposed to exhibit are expressed as mathematical theorems about these structures [14]. A system can be viewed as a semantic model, and a property as a logical formula. It follows that correctness of a system can then be seen as verifying the formulae in models. Researchers in model checking use logical languages, e.g. rst and second order logic, and propositional modal and temporal logic. Multimodal logic formalises natural language modal adverbs such as \possibly" and \necessarily" and temporal phrases such as \eventually", \always", \sometime" which refer to future points in time. So, every formula description is for a given time. Multimodal logic introduces a new operator ' meaning possibly ', i.e. there exists some t accessible via R such that ' hold at t. The dual for this is necessarily '. Temporal logic is based on a binary operator U (', ) meaning until ', holds. Linear temporal logic is expressive for natural models. The same is possible with some modi cations for nite branching trees. Program executions can be modelled as a set of execution sequences or as an execution tree, where branches denote nondeterministic decisions. Statements about correctness of a program can involve considering all maximal paths in a tree. [4] introduced interval temporal logic (ITL). It is useful in specifying concurrent systems by providing temporal modalities which help in de ning temporal contexts and the properties that must hold in these contexts. The main di erence between ITL and standard linear time temporal logic [8] is that it is interpreted over nite state sequences, called intervals, rather than over in nite models [11]. Other examples of modelling languages include state machine description languages (e.g. State Charts), protocol speci cation languages (e.g. LOTOS, Esterelle, Promela ), programmming languages (e.g. C++, Ei el, Java), and process calculii (e.g. CCS and CSP). Since Pnueli's [12] work on temporal logic to reason about concurrent objects, linear-time temporal logic [8] has been used by researchers for the speci cation and validation of concurrent systems. However, temporal-logic based approaches for the design phase of system life cycle such as [9] do not consider OO systems. Although LTL is a good vehicle for expressing the temporal relationships in behavioural speci cations, it does not have the expressive power to show procedural dependencies which is necessary in modelling OO systems. Various temporal models have been proposed for the requirement analysis phase of OO (distributed) systems [5], but not much work has been reported for the design and implementation phase [10, 13]. These proposals impose di erent assumptions in their models as they consider di erent phases of software system development and address di erent application areas. Design issues in system development such as change of objects over time, thread and process issues have not been considered in these formal models.
1.2 Classi cation Hierarchy of Temporal Properties When ' is de ned as a safety property, for evey model not satisfying ', something \bad" must have happened after a nite number of steps which cannot be corrected by any future (good) beaviour. Lamport(1978) states that safety properties express that \something bad never happens". A liveness property ', holds, if and only if every nite sequence can be completed to a model satisfying ' , hence ' states that \ something good eventually happens". The occurence of the \good thing" need not have to be observable in any xed time interval. [9] gives a hierarchy of property classes. Assume that ' and are boolean combinations of pure present and pure past temporal formulae. Safety properties: 2 ' Liveness properties Guarantees: 2 '
Obligation: (2' _ 3 ) (or 3 ' ,> 3 ) Responses: 2 3 ' Persistence: 3 2 ' Reactivity: (3 2 ' _ 2 3 ) (or 2 3 ' ,> 2 3 ) All safety and guarantee properties are also obligations. The obligation property classes are included in the response and persistence classes. Response and persistence are included in reactivity. Every LTL property can be written as a conjunction of reactivity formulae. Temporal operators are useful in expressing safety properties and the guarantees associated with liveness properties. The always operator is used to express invariants that are intended to specify the safe limits for state attributes of each class. The eventually operator is used to express the fact that the design of the system guarantees that certain events will occur but cannot specify exactly when they will occur. Our e ort [13] has focussed on extending the object constraint language (OCL) with temporal operators and de ning a model for testing distributed component-based systems.
2 MODELLING DISTRIBUTED OO COMPONENTS IN EXTENDED OCL In this section, we look brie y at the features provided by the textual constraints of OCL and a distributed component model as de ned in [15]. We nd that although the UML state charts capture the concurrent states of an object and the message sequence charts show the time sequence in relation to objects and events, OCL constraints in UML models fall short in their ability to clearly show the temporal constraints of composite objects and components. We motivate why extending OCL with temporal logic formalism is useful in the speci cation and testing of the concurrency aspects of distributed systems.
2.1 A Distributed Component Architecture - Kens and Gates Schmidt (1998) describes a high level distributed component model based on three abstractions: kens, gates and rules. Kens are de ned as loosely coupled distributed components which can be built hierarchially from primitive kens. Gates are the interface objects that connect kens. Gates guard and coordinate when the objects enter or leave, which objects may enter or leave and through which gates they leave. Rules provide the interface speci cation. Schmidt (1998) provides an architectural level description of a production cell environment with kens and gates (see gure 1).
2.2 Why add temporal logic to OCL? The Object Constraint Language is the language used within the Uni ed Modeling Language (UML) to specify pre and post-conditions, class invariants, method semantics and other types of constraints. A constraint speci es a restriction on a value or a dependency between two objects in the model. UML, and by inclusion OCL, has been adopted as the standard for analysis and design facilities by the Object Management Group (OMG). As such, it is used to express the speci cations of distributed systems based on CORBA. The language de nes a number of types just as an Interface De nition Language (IDL) does. IDL provides an architectural level description of the public interfaces of distributed systems, and does not provide the operators necessary to express constraints between classes or objects. OCL supports more comprehensive speci cations than those expressed in IDL; however, it still does not provide a means of stating that \eventually the server will receive the request" as the speci cation of a one-way message in CORBA-based applications. This type of guarantee is useful for speci cation purposes and necessary to derive adequate tests. The Kens and Gates model does support expressing constraints. We use this distributed component model as a basis for drawing out the temporal relationships in classes that are composed
Figure 1. Kens and Gate Architecture
of multiplicity of associations. We discuss our understanding of how OCL enriched with temporal operators can assist in the speci cation and testing of reactive and distributed systems. We will relate the speci cation and testing needs in the next section. We have de ned an initial grouping for the various temporal operators based on their semantic scope in our speci cation model, which is in line with interval temporal logic. This will be useful in specifying the levels of component interactions and in deriving our test strategies based on the hints given by the temporal properties as to whether we are dealing with testing critical sections, chain of interactions or global states. For example, a mutual exclusion describes a critical section in a system's execution, when certain events or states are never allowed, and can be restated as a safety invariant that says two processes can never visit their respective critical region at the same time. This is the opposite requirement to specifying that certain invariants must hold or exist which is an existential requirement. We show using temporal speci cations that certain condition must never occur, and certain invariants, which must exist into a group, and use the always operator to negate or state the existence constraint. The \response" operator as speci ed by [9] is de ned to guarantee properties, always, eventually, which can be restated as a constraint on the sequence of states or events. This is similar to Sivilotti's [16] follows and leads-to operators, which represent causal relationships between states and events. We group these operators of explicit ordering requirements as sequential assertions and treat them that way in specifying and deriving our test cases, using always and concatenating the assertions into a chain of constraints that must be met. We also need to break this group into previous and next to specify the order at a more ne grained level, and consider the states in between the initial starting state to the end state. This is useful in specifying and deriving meaningful test cases at various intervals of time before testing the nal response requirement. For the purpose of modifying the OCL grammar, we constructed two sets of temporal operators. A number of temporal operators such as always, never and eventually are unary operators, whereas until, unless and since are binary temporal operators. This allows us to avoid the need to require a second \dummy" parameter that is either always false or always true, depending upon the operator.
3 SPECIFICATION AND TESTING OF DISTRIBUTED COMPONENTS Our working hypothesis is that the operators of temporal logic provide sucient expressiveness for our purpose. That purpose is the speci cation of reactive distributed systems constructed using object-oriented techniques. In support of that hypothesis we have extended OCL to include a set of temporal operators. We have modi ed the grammar for OCL de ned in Warmer & Kleppe (1998) in the following ways: The concept of an expression was broadened from its original de nition of being a logical expression to: expression := logicalExpression j temporalExpression The if expression was modi ed to be: ifExpression := \if" logicalExpression \then" logicalExpression \else" logicalExpression \endif" as expression has been now de ned to be either a logical or temporal expression. Three additions were made to the grammar: binaryTemporalOperator := \until"j\unless"j\since" unaryTemporalOperator := \always"j\eventually"j\never" temporalExpression := binaryTemporalOperator(unaryTemporalExpression, logicalExpression) j unaryTemporalOperator(logicalExpression) We developed these changes to the OCL grammar based on our requirements for distributed component testing. We are experimenting with small concrete examples to determine whether the syntax provides the expressiveness needed. We are also working on ways to specify and generate test cases by expressing the semantic constraints between Java IDL, clients and server components with these temporal constraints.
3.1 An Example We provide a speci cation for testing such components by drawing out the feasible interactions between various basic and composite components using an extended notion of OCL and design by contract. We derive a method for v alidating i nteractions in s oftware w ith a ssertions (viswas), and use this approach to derive test cases for a component. This is also the basis for testing speci cations which is elaborated through a production cell example. Here we discuss an example speci cation for a manufacturing robot. We base our example on the Ken and Gates model (Schmidt 1998) and extend his example to specify a robot operation using our extended OCL. The Production Cell example is a case study from manufacturing plants dealing with process control systems which impose hard real-time requirements. This case study was launched by the FZI (Forschungszentrum Informatik) in 1993 under the framework of the German Korso Project [7]. The aim of a production cell that is operational at a metal processing plant in Kalsruhe, Germany is to transform the metal blanks into forged plates and transport the plates from a feed belt into a container. The metal plates are conveyed to a press via a feed belt, a rotary table and a robot. The production cycle for the metal blank (see gure 3) is described in [6]. Lewerentz(1995) list a number of safety and liveness requirements in the speci cation of the production cell with distributed machine controllers. In this paper, we provide details only for modelling and testing the Robot Ken and its \Drop" operation. A robot has a multiplicity of associations with its components and these parts have to satisfy certain time-based constraints before this robot's operation can re. We specify the requirement for such a robot operation in a distributed software context with OCL extended with time based constraints.
We consider the following examples of safety requirements for a robot in a production cell environment. We de ne two robotParts - gripperMagnet and armMotor for our robot. The gripperMagnet is equipped with take and drop operations to enable the robot to perform these operations. The armMotor is capable of extending or retracting the robot's arm. The armMotor of the robot must have extended the arm to enable the gripperMagnet to take the metalplate. Once the armMotor is extended and the gripperMagnet has taken the metal, the robot can proceed with the \Drop" operation, and drop the metal plate on a FeedBelt in a production cell environment. So, we say that the robot is not ready to proceed with operation until the two robot parts have performed their required operations. We specify a robot ken and its gate in terms of classes and constrained relationships. We include two boolean operations: takeSignal and dropSignal for the gripperMagnet class where takeSignal() returns true if the robot is ready to perform the take operation. The classInvariant for the gripperMagnet class is: takeSignals xor dropSignals. We provide two boolean operations, extendSignal and retractSignal, for the armMotor class. The classInvariant is: extendSignals xor retractSignals. We can now express a temporal constraint on the robot class using our extended OCL that must be satis ed by the robot: until(always((armMotor.extendSignals and gripperMagnet.takeSignals), not robotReady)) which means "until the chained constraints of the robot parts become true, the robot's constraint, robotReady is false". The temporal extension to OCL enables us to group class constraints in time order where warranted, by concatenating individual class invariants of classes. This is useful in composing a constraint on a class with a number of associated constrained classes. It is especially useful in the context of distributed and concurrent systems to be able to specify the constraints of clients and server operations in terms of local class invariants on the client side and a group constraint that is placed on the server side, which must be met before the operation can proceed. We commence by specifying the monitor invariants that must always hold at the class level. We can consider the class invariants in our robot example takeSignals or dropSignals, and extendSignals or retractSignals as always(gripperMagnet.takeSignals xor gripperMagnet.dropSignals) and always(armMotor.extendSignals xor armMotor.retractSignals). We have restated the speci cation of class invariants in terms of the temporal operator, always, stating that at every point in time the conditions described in the invariant should hold true. Thus the statement of the class invariant is also a statement of the temporal safety property. The PACT described by McGregor (1997) evaluates the class invariant at the end of each test case. We group parts of class invariants that need to be satis ed and use them as the rst argument to the binary temporal operator, until. The second argument is the logical expression that must hold until the rst argument (expression) becomes true in the future. until(always((armMotor.extendSignals and gripperMagnet.takeSignals), not robotReady)) This method of speci cation states a conjunction of invariants that must hold in the future. This states a guarantee of the liveness properties which must hold in the future and it guarantees that these properties must hold true before the system will proceed with the robot \Drop" operation. We are using this temporal property-based speci cation as a basis for constructing test cases. These test cases are used to validate aspects of the system design and implementation. Our work on modifying an existing grammar from which to build a parser for the extended OCL is continuing, and considering various options.
4 VALIDATING INTERACTIONS in SOFTWARE WITH ASSERTIONS (VISWAS) Our design objective has been to produce a distributed component model which can be used to construct software, verify and validate interactions of software objects, processes and threads with extended version of design by contract and assertions. Our design must address testability issues, and uses the public interfaces of objects as a way of exposing observable events.
We present a detailed design model here that takes into account the important aspects such as procedural dependency between objects, extends Meyer's (1988) design by contract notion to time and place, for the design, implementation and testing phases of object-oriented concurrent and distributed system development. Our model uses event-based abstractions and this has been proven to be useful in reactive systems and also in general in testing [3]. As temporal logic is suited to specifying the requirements of concurrent and distributed systems, we have used it to group related events in the context of design by contract, and extended the contract notion to concurrent threads and to groups of related objects composed as a component. We have used temporal logic with design by contract to express behavioural constraints (properties with a notion of time) in OO distributed systems. We show how the events that our model is based on, can be used in the design speci cation and testing phases of distributed systems with CORBA (Common Object Request Broker Architecture) as the underlying platform. We have modelled the states, transitions, event ordering and concurrent objects of a Robot component in a Production cell as shown in the UML's state chart (see gure 2) that follows: Activating Arm motor
[extendSignals] extendSignal
Arm motor arm extended /arm extended & plate taken Robot.DROP
[takeSignals]
System Inactive
Activating takeSignal Gripper magnet
Magnet plate taken
Gate Interface Robot Arm
Figure 2. State Chart for a Robot Component
We express temporal properties over intervals of object/thread/process instances in a message sequence chart which is more intuitive than the nested formulae of propositional temporal logic. We identify temporal intervals of interest for objects, threads and processes when they need to satisfy speci ed assertion requirements. Intervals are derived from these state sequences and the transitions that make their end points. We have used message sequence charts with annotations to express timing constraints between Robot component parts. These textual annotations express timing constraints as formulae using temporal logic. These annotations are extensions to UML and OCL notations to show the sequential, concurrent and distributed constraints in objects, thread and at process level (see gure 3). In our model, a component's constraint is speci ed between objects, threads and processes and the properties are asserted to hold for the time interval of these interactions. We have implemented a prototype application in CORBA and Java, and have shown how one can observe and collect information needed to validate the property based speci cation by using the IDL public interface, and Java classes and interfaces enriched with assertions. IDL speci cation of the interfaces is usually passed to an IDL compiler which generates the stub and skeleton codes. The next step involves linking all the implementation les. In our model, UML model (with IDL speci cation) annotated with extended OCL constraints is also fed to a parser generator tool. This tool produces a list of observable event sequences. We have the property speci cations which were de ned as part of our design strategy to spell out the temporal contracts
Figure 3. Message Sequence Diagram - Textual annotations expressing timing constraints
for the IDL interfaces to be observed by the interacting objects in the system. We preprocess this contract speci cation and together with the event sequences produced from the parser, we have event trees which can be used as test sequences to validate the implementation code.
4.1 Test Oracles We have used message sequence charts for the speci cation of properties of sequences of states. Test Oracles check properties of system executions. Speci cation based test oracles are mechanisms to check whether a test has passed or failed. These oracles are derived from formal speci cation for checking automatically whether the test execution behaviour conforms to behaviour spelled out in the speci cation. Temporal logic-based test oracles also allow the veri cation of the ordering and timing of events in executions of concurrent systems. Test oracles which are ecient when combined with automatic test generation can be e ective in automating the testing of large number of test cases that are used for adequate coverage of system requirements and structure. Research literature [1, 14] on temporal logic speci cations consider veri cation of nite state systems with model checking, and determine whether it is possible to violate the speci cation for any speci cation. This checking requires exploration of the entire state space. Speci cation based oracles, on the other hand, do not need to search the entire state space, and only check whether a particular test execution violates the speci cation. We monitor the system execution through method/event trace during testing. Traces generated during testing can be used to verify the state sequences in speci cations. We state that a speci cation has been implemented correctly, when the trace from testing matches the speci cation if the speci cations hold when evaluated on these state sequences.
4.2 Test Data Selection We follow a speci cation based black-box approach to testing production cell components. Test sets are designed for the above examples of safety and progress requirements, using the Ken/Gate
architectural component model, UML state diagram and message sequence chart annotated with OCL extended with temporal operators as textual constraints. The production cell as de ned in the Ken/Gate model is composed of self-contained independent components such as feed belt, rotary table, robot, press and deposit belt. Our test strategy is to test these components in isolation rst and to follow it with systematic integration testing of these components. This integration testing will verify the progress requirements which considers a number of components of the production cell. Our strategy is to test the robot component rst and check the safety and progress requirements as spelled out above for the robot operation. At this level of component testing, the focus is mainly on verifying conformance to individual interface models of the basic component part, and in addition, conjunction of these constraint requirements for the composite component. In our robot component testing example, we test the interface constraints of the robot parts, and also the conjunction of these constraints to test the overall behaviour of the robot component.
5 SUMMARY We have presented our approach to modelling and testing distributed components with temporal logic formalisms. There have been solid foundational work on temporal logic, formal speci cations, and formal approaches to veri cation, model based checking and testing. However, there has not been much reported in the research literature linking distributed object-oriented components testing with temporal logic formalisms. We have not cited any work extending OCL to support temporal operators in modelling and testing such component based systems [13]. We believe that our approach of extending OCL, the companion language to a mainstream modelling tool is useful in improving the quality of the testing process in line with the development process. Given the basic grammar modi cations described in this paper, we have been considering the optimal set of operators. Although virtually all temporal operators can be derived from the until operator, we use our grammar to de ne a sucient set of operators for our example case study. We will conduct a systematic analysis of writing temporal statements with a limited set of temporal operators. Beginning with the minimal set until, a new operator will be added only if the concept it represents is useful in describing distributed systems, and writing the expression in terms of the existing operators results in a \much" more complex statement than using the new operator. Are there standard patterns of test cases that can be de ned for temporal operators? The second author has had considerable success with de ning standard templates from which testers instantiate speci c tests for a speci c situation. For example, the until(a,b) operator de nes an interval over which statement b is true. This interval is previous to the event of a becoming true. Given this analysis, can we de ne abstract test cases? For example, using the previous and next temporal operators, we can see that de ning test cases at previous(a) and next(a) give boundary value tests just before and after a becomes true. We would like to de ne a set of such tests for each operator. What de nitions of coverage are useful when selecting test cases based on temporal expressions? For the until(a,b) expression which de nes an interval, appropriate test values include those at the extremes of the interval, a value within the interval and one value outside the interval. In ITL, any expression de nes an interval. We will de ne an interval-based coverage metric. Are the temporal expressions a more e ective means of specifying pre/post-conditions and other types of constraints than state-based predicates? We often de ne " ags" as part of the state of an object in order to be able to evaluate expressions. For example, a class might contain a boolean variable that is set when the object is connected to the ORB. The pre-condition for some operation would be written isConnected(). An alternative pre-condition could be await connect(). This avoids the mention of a connected ag but may not avoid its existence. Could a temporal expression replace a state variable?
OCL is intended to be \both formal and simple" [17]. We have used English words rather than symbols for the names of the operators to produce readable expressions. Our goal is to extend OCL with the minimum set of temporal operators that provides the expressiveness we seek but without complicating the language needlessly. Early experiences have shown that we can write constraints that are useful with only a small number of operators.
References [1] J. M. Atlee and J. Gannon. State-based model checking of event-driven system requirements. IEEE Transactions on Software Engineering, 19(1), pages 24{40, Jan 1993. [2] A. Bader, A. S. M. Sajeev, and S. Ramakrishnan. Testing Concurrency and Communication in Distributed Systems. In International Conference on High Performance Computing, Dec 17-20 1998. [3] L. K. Dillon and Q. Yu. Oracles for checking temporal properties of concurrent systems. In 2nd ACM SIGSOFT Symposium Foundations of Software Engineering, pages 140{153, Dec 1994. [4] J. Y. Halpern, Z. Manna, and B. Moszkowski. A hardware semantics based on temporal intervals. In 10th International Colloq. Automata, Languages and Programming, pages 278{ 291, July 18-22 1983. [5] R. Jungclaus, G. Saake, T. Hartmann, and C. Sernadas. Troll - a language for object-oriented speci cation of information ssystems. ACM Transactions on Information Systems, 14(2):175{ 211, April 1996. [6] B. Kramer. Synchronisation Constraints in Object Interfaces, B Kraemer, M Papazoglou and H Schmidt (eds.). Research Studies Press, 1998. [7] C. Lewerentz and T. Lindner. Formal Development of Reactive Systems - Case Study Production Cell, C Lewerentz and T Lindner (eds.). Springer Lecture Notes in CS, vol. 891, 1995. [8] Z. Manna and A. Pnueli. The temporal logic of reactive and concurrent systems: Speci cation. Springer, New York, 1991. [9] Z. Manna and A. Pnueli. The temporal logic of reactive systems: Safety. Springer, New York, 1995. [10] A. Morzenti and P. Pietro. Object-oriented logical speci cation of time-critical systems. ACM Transactions on Software Engineering and Methodology, 3(1):56{98, Jan 1994. [11] B. Moskowski. Executing Temporal Logic. Cambridge University Press, 1986. [12] A. Pnueli. The temporal logic of programs. In 18th Annual Symposium on the foundations of Computer Science, pages 45{57, 1977. [13] S. Ramakrishnan and J. D. McGregor. Extending ocl to support temporal operators. In Workshop on Testing Distributed Component-based Systems held in conjunction with the 21st International Conference on Software Engineering, May 16-22 1999. [14] B.-H. Schlinglo . Veri cation of Finite State Systems with Temporal Logic Model Checking. South African Computer Journal (19) from Proceedings of 3rd WOFACS, Cape Town, South Africa, pages 27{52, 1997. [15] H. Schmidt. Compatability of Interoperable Objects in Information Systems Interoperability, B Kraemer, M Papazoglou and H Schmidt (eds.). Research Studies Press, 1998. [16] P. Sivilotti. A Method for the Speci cation, Composition, and Testing of Distributed Object Systems. PhD thesis, California Institute of Technology, Pasadena, California, USA, Jan 1998. [17] J. Warmer and A. Kleppe. The Object Constraint Language, Precise Modeling with UML. Addison-Wesley, 1998.
