Comparison of Object-Oriented Formal Methods

Comparison of Object-Oriented Formal Methods Nicolas Guel 1, Olivier Biberstein1, Didier Buchs1, Ercument Canver2, Marie-Claude Gaudel3 4, Friedrich von Henke2, Detlef Schwier2 ;

1 LGL-DI, Swiss Federal Institute of Technology, CH-1015 Lausanne, Switzerland 2 Abteilung Kunstliche Intelligenz, University Ulm, D-89069 Ulm, Germany 3 LRI Bat. 490, University of Paris-sud, F-91405 Orsay, France 4 Instituto de Matematica e Estatstica, Universidade of S~ao Paulo, Brazil

e-mail: Nicolas.Guel @ep .ch

1 Goals of the document The goal of this document is the classi cation and comparison of object-oriented formalisms for assessing their suitability within DeVa. Numerous object-oriented formal speci cation languages are under development, either extending existing formal approaches or formalizing informal OO-methods. It is dicult to evaluate and compare them; a suitable evaluation framework identifying a set of classi cation criteria needs to be designed for this purpose. In this paper we present a comparative study of various OO-formalisms by means of an evaluation framework. The criteria we have chosen to describe features present or absent in a formalism. One of the challenging parts of this work has been the precise de nition of the classi cation criteria. The conclusions are drawn by relating the results of the classi cation and comparison to the needs of DeVa. This comparative study also shows that the term \OO formal approach" is used for quite dierent approaches.

2 Introduction to Object-Oriented Speci cation Formalisms The natural idea behind the object-oriented paradigm is to consider the system we want to model, simulate or develop, as a collection of active objects which collaborate with each other. The term active object denotes an autonomous entity equipped with its own behavior and some internal data. These local data correspond to the state of the object and of course may change during its lifetime. The only way of interacting with an object is to send it a message (asynchronous) or to request a rendezvous (synchronous). A message is a request for the receiver to give a service to the sender. The sender is also called a client while the receiver may be called a server. It does not mean that an object is exclusively either a client or a server, an object can play both the roles at the same time. The role of the formal speci cation is to provide means to describe in a precise manner the characteristics of the `behavior' of the expected system. The formal speci cation shall encourage to describe what is expected more than how it will be realized. Moreover, it is also necessary to provide some reasoning methods that can be used for validation and veri cation purposes. We are interested in studying the OO paradigm at the speci cation level because object orientation is well adapted to specify interesting high level properties of dependable systems (structuration, distribution, non-functional requirements, etc.) and because it looks attractive to have a uniform set of concepts through all the development life cycle. The aim of this report is to design a framework for the classi cation and comparison of speci cation methods which are both formal and object-oriented. This is done by giving a set of criteria, then a brief description of several object-oriented and formal speci cation languages and an answer is given for each criteria. A general comparison table is given at the end of the paper, thus allowing to identify some commonalities and dierences. Some of the conclusions given at the end of this report are speci c to the DeVa project objectives and may not be applicable outside this context.

3 Classi cation Criteria The comparison is organized as follows. First we give the comparison criteria that we have selected and a short presentation of each language. Afterward we discuss each comparison criteria for every previously introduced languages. Finally we summarize the discussion by means of tables which allows the reader to quickly determine, for each language, which criteria are supported.

We have split the OO criteria of the speci cation languages into two groups: 1. the object-based criteria; 2. the object-oriented criteria. Object based formalisms provide mainly encapsulation and methods for accessing the encapsulated state in a controlled manner. Objects are organized in a static structure. Thus usually no dynamic creation of object instances is allowed. The main aspect, however, that is missing in object based formalisms in comparison to object-oriented formalisms is, that no real inheritance is provided and objects may not be used like (pointers to) values, i.e. objects or object references may not occur as arguments to (or results from) a function, a procedure, or a method. These two groups of criteria are respectively described in Sections 3.1 and 3.2. We have also, in a third group of criteria, considered the existence of a formal semantic de nition and the possibility to perform formal proofs. Other relevant aspects are the integration into a software engineering support environment, the practical use and the existence of tools. Since the notion of state is present in all the speci cation languages which are considered here, we have classi ed them according to their underlying models rather than according to the classical distinction between model-based and property-based approaches. We identi ed four major underlying models upon which the speci cation languages studied here are based: 1. rst-order logic and set-theory; 2. algebraic approach; 3. Petri nets/algebraic nets; 4. temporal logic. They are grouped and presented in this order in the sequel of the paper.

3.1 Object-Based Criteria We classi ed the object-based criteria as follows:

1. object: the ability to consider a system as a collection of independent entities which interact and collaborate, i.e. an object gives some services to the other objects and can request some as well; every entity possesses a state which can be modi ed; 2. encapsulation: the ability to hide the state of the objects from the outside, the only way to interact with an object is to request one of its services; 3. synchronous/asynchronous: when the service requests are synchronous we say that an object asks to be synchronized with another object, otherwise the service requests are postponed (unbounded time) before their treatment. Generally, synchronization requests are achieved by means of method calling, while message passing is associated with asynchronous requests; 4. data abstraction: the ability to describe abstract data types, as distinct from individual objects; these models are called hybrid in contrast to pure object models, in which only objects can be used as modeling entities; 5. data structures of objects: the ability to describe data structures of objects such as stacks or arrays of objects; 6. object identity: the notion of a persistent identity for an object. The object identity is unique within the system; 7. intra-object concurrency: the ability to express concurrent events inside an object; 8. inter-object concurrency: the ability to have concurrent progress of objects.

3.2 Object-Oriented Criteria We classi ed the object-oriented criteria as follows: 1. classes as templates: the ability to describe the common aspects of objects and to create (statically or dynamically) instances or objects of the class; each class de nes a type which is associated with all instances of the class (intensional description); 2. classes as collections: the ability to describe homogeneous collections of existing objects (extensional description); 3. inheritance: the reuse or modi cation of an existing class in order to obtain a new one. Three distinct scenarios are considered: (a) specialization inheritance: some ingredients may be added; (b) rede nition inheritance: some services may be rede ned;

4.

5. 6. 7. 8. 9. 10.

(c) design inheritance: some ingredients may be removed; sub-typing: the ability to express a hierarchy of types based on the substitutivity principle. Three cases are considered: (a) weak sub-typing: only the pro les of the methods are considered; (b) strong sub-typing: the semantics of all the methods are considered; (c) observational sub-typing: only a subset of the properties (the so-called observable ones) is considered in the used logic; multiple inheritance/sub-typing: the ability to construct a class by means of more than one class, or the ability for a type to have more than one super-type; inheritance 6= sub-typing: the ability to build the inheritance hierarchy distinct from the sub-typing hierarchy; classes as object: the ability to consider a class de nition as an object. Therefore, there is some notion of meta-class (i.e. the class of classes); collection of objects: the ability to make a collection of heterogeneous interacting objects, and to act on the whole collection; dynamic/static creation of objects; genericity or parameterization of classes: syntactic or semantic de nition.

3.3 Semantics and Calculus The abstract concepts used for the semantic de nition of a formal approach can in uence considerably the possible use of that formalism. These abstract concepts can be mathematical (algebras, functions) or more computer oriented (automata, trees) but, in any case, mathematically de ned. Such semantics are necessary for any formalism in order to be able to establish the meaning of the constructions of the speci cation language. Furthermore, a more logical framework called calculus, in which some kinds of proofs can be performed, is necessary in order to be able to provide tools supporting veri cation and validation. This is why we consider two aspects in the de nition of the formalisms: 1. semantics: the existence of a complete mathematical de nition for the interpretation of a speci cation without distinction between denotational, operational or axiomatic approaches. 2. calculus: the existence of a proof system (a method for proving properties based on deduction rules) for the whole formalism or a restricted version.

4 Object-Oriented Speci cation Languages Considered Here is a the list of the object-oriented speci cation languages which are classi ed below according to the above criteria:

rst-order logic and set-theory { Object-Z (O-O extension of the Z notation) { VDM++ (O-O extension of the Vienna Development Method) { Z++ (O-O extension of the Z notation) Algebraic approach { HOSA (Hidden Order Sorted Algebra) { TROLL { Maude { AS-IS (Algebraic Speci cation with Implicit State) Petri net/High-level net approach { CLOWN (CLass Orientation With Nets) { CO (Cooperative Objects) { OPN (Object Petri Nets) { COOPN/2 (Concurrent Object-Oriented Petri Nets) Temporal logic approach { TRIO+ { OO-LTL

This list is not intended to be exhaustive. Our selection has been guided by the following considerations: abstract data types are necessary for the formalisation of information hiding and encapsulation; there is a strong interest in DeVa for distributed real-time systems; we wanted to have a sample of dierent approaches; and nally the usability of the approach and the existence and availability of a good documentation was mandatory. In the following sections, we use tables to summarize the comparison. The meaning of the items in the tables are: 1. Y, for yes;

2. N, for no; 3. (Y) (resp. (N)), indicates a partial yes (resp. no) and the justi cation is given in the corresponding section; 4. Special cases : '/' is used when two answers must be given (for example y/n in row of TRIO+ for the colum multi-inherit./sub-typing corresponds to a yes for multiple inheritance and a no for multiple subtyping, furthermore a yes or a no in such column concerns both topics). X stands for uncertain.

5 The rst-order logic and the set-theory approaches The rst-order logic and set-theory approaches are often also called model oriented because they support the speci cation of a system by constructing a mathematical model for it. Typically a speci cation describes the states of a system together with operations over the states, which denote next state relations. For this purpose speci c mathematical objects (e.g. data structures, relations or functions) which are structurally similar to the required computer software are described in detail and their properties are expressed in rst-order logic. The semantics of these languages is based on set-theory. During the design and implementation of a system, the speci ed mathematical objects may be modi ed in such a way that essential features of the initial speci cation are preserved. The best known representatives for this group of speci cation languages are the Vienna De nition Method (VDM) [Jon90] and the Z Notation [Spi92]. Due to its typical use { speci cation of states and operations over states { this group of languages seem to be well suited for being adapted to an object-oriented paradigm. Notions not addressed in the basic formalisms include

a module structure actually supporting encapsulation;

operations for expressing inheritance, object creation, object aggregation/collection, etc.;

object identity;

object activity i.e., methods and behaviors.

Several approaches towards an object-oriented extension of these formalisms have been developed; among the most prominent of these are Object-Z [DKRS91], Z++ [LH94b], and VDM++ [DvK92].

5.1 Object-Z The Object-Z [DKRS91] speci cation language is an extension of Z [Spi92] to accommodate object orientation. A Z speci cation typically de nes a number of schemas de ning state and operations. In Object-Z, an operation can refer only to the state of the object to which it belongs. The de nition of a state and its associated operations constitute a class. So the potential behavior of a class may be considered and understood in isolation. Syntactically, a class

de nition is a named box, optionally with parameters. The possible constituents of a class are: a visibility list, inherited classes, type and constant de nitions, a state schema, an initial state schema, operation schemas, and a history invariant. The visibility list restricts access to the listed features. If it is omitted all features are visible. Type and constant de nitions are as in Z. The state schema is nameless and comprises declarations of state variables and a state predicate. The state predicate forms the class invariant. It is implicitly included in every operation and the initial state schema. The initial state schema de nes the possible initial states. The initial state is not unique. Operation schemas describe the methods de ned for the class. Operation schemas have a -list of those individual state variables who's value may change when the operation is applied to an object of the class. The pre- and postcondition describe the eect of an operation. The history invariant is a predicate over histories of objects of the class. It further constraints the possible behaviors of such objects. Fairness or safety properties are typical constraints of object histories. History invariants are typically stated in temporal logic. A declaration c : C declares c to be a reference to an object of the class C . A declaration does not mean that a new object is introduced nor does it mean that the object is initialized. Initialization of objects is attained by including the init schema of the class in an operation schema or the init schema of another class. Object creation is not directly provided in Object-Z; if this concept is necessary in a speci cation, it can be expressed by modeling a set of existing objects. Dot notation (C:var, C:op, . . . ) is used to refer to class properties. The advantage of adopting object references is that the objects referenced by c may evolve without changing the value of c. For example, the declaration sc : finite set(C ) can model an aggregate of objects which may evolve without changing the value of sc as the references do not change. sc is only changed if an operation adds or removes objects from the aggregate sc. Objects may have object references as attributes, i.e. conceptually an object may have constituent objects. Such references may either be individually named or occur in aggregates: e.g. s1 ; s2 : NatStack declare two stacks of natural numbers. As noted before s1 and s2 need not be distinct. If it is intended that the referenced stacks be distinct, the references have explicitly be distinguished (s1 6= s2). If the references do not change they can be declared as constants. This does not mean the contents of the stacks remain constant. An operation is a relation between two successive states in the object history. Operations are represented by predicates over the primed and unprimed state variables. Conjunction, disjunction and other Z schema operations can be used to form new operations. [] indicates non-deterministic choice of one operation from those constituent operations with satis ed pre-conditions. The parallel operator, jj achieves inter-object communication. The operator conjoins [DKRS91] operation schemas but also identi es and hides inputs and outputs.

Complex classes can be speci ed to inherit from other classes, or to include references to instances of objects. The type and constant de nitions of the inherited classes and those declared explicitly in the derived class are merged. Similarly, the schemas of the inherited classes and those declared explicitly in the derived class are merged. Any schemas with the same name and the state schemas are conjoined. Also the history invariants are conjoined. Name clashes can be resolved by renaming. The visibility lists may be used to disable inheritance of properties of a class. Rede nition of properties may be achieved by hiding and renaming of properties. The table answers are given with respect to the informations collected in the following bibliographic references: [LH94a, DD90, DKRS91, DKS91]

Object-Based Criteria object and states encapsulation synchronous requests asynchronous requests data abstraction data struct. of objects object identity intra-concurrency inter-concurrency

Object-Oriented Criteria class as templates class as collections inheritance sub-typing multi-inherit./sub-typing inheritance6=sub-typing classes as objects collection of objects

dynamic/static object instantiation genericity or parameterization

Semantics Semantics Calculus

Value Comments Y Y Y N Y Y Y Y Y

Method calling No explicit messages Inherited from Z Classes are considered as types and may be used accordingly Reference type Speci cation of Histories in terms of temporal logic formulae

Value Comments Y N Y Y Y Y N (N)

explicitly stated in [LH94a] (a), (b), and (c) supported Not syntactically enforced but recommended in the guide lines

N Y

Collections of object references are possible No explicit syntax. Collections of object references used for the purpose Type parameters

Y Y

[DKRS91] Rules stated in [Gra92]

Value Comments

5.2 VDM++ VDM++ [DvK92, LH94a] is an object-oriented speci cation language based on VDM-SL [Jon90]. A VDM++ speci cation consists of a set of class de nitions. A class de nition provides a template for objects, which possess attributes and operations (methods) whose types and properties are de ned in the class. In addition there are features provided that are speci cally related to concurrency and real-time. A VDM++ class de nition consists of several clauses for constant values, instance variables, invariants, methods, synchronization, and threads. The types, values and function components of a class de ne local types and constant data, in the same style as the corresponding VDM-SL features. The instance variables clause de nes varying data. Invariant clauses constrain the initial values of variables, and also the values at the times when a method of the class is initiated or terminates. The init clause constrains the initial state, which is not required to be unique. The methods clause lists the operations of the class which can be invoked by external clients. Each method is given a name, a list of parameters with their types, and an optional output parameter. A method may be de ned in a number of ways.

The preliminary style identi es that the method will be de ned later in the development process. For each method de ned in the deferred style each concrete subclass must have a full de nition of this method. The declarative style de nes the eect of a method with a pre- and post-condition. In the procedural style the eect of a method is de ned in terms of a piece of code.

In a speci cation statement the read- and write-frame of a method has to be de ned. In addition to the usual VDM types, class reference types exist. For each class C declared in a system, we have a type @C consisting of references to objects of C . Elements of @C behave like pointers in programming languages. The \new" operator provides new references to the system. If m is a method of C we can invoke m on the element a : @C with the statement a!m(e) for suitable arguments e. A class can be declared to be a subclass of other classes. Each feature of the class becomes a feature of the subclasses. Additionally, new attributes, invariants, methods, etc. can be de ned within the subclass. Usually, methods will be rede ned in such a way that they are consistent with the speci cation of the superclass. If the method rede nition is consistent, a subclass is referred to as a subtype. A developer should document those inheritances which they expect to be subtypings. Name clashes in inheritance are dealt

with by automatic renaming of features. Aggregation, i.e. one object is build out of a xed set of component objects who's lifetime coincide with it which cannot be shared or removed, is achieved by indexed inheritance. A distinguished class called workspace acts as the root of a development. The sync clauses of a class contain either a trace speci cation, or a set of permission statements. They de ne the synchronization and allowed sequences of method invocations. A trace is a regular expression of method names or other traces. A permission statement de nes a guard for a method. A method is only invoked when the corresponding guards are satis ed. A guard may refer to the number of initiations, terminations, and requests of a method. A thread clause is either declarative or procedural. A declarative thread speci es activities which are periodically executed. A procedural thread speci es a general ongoing process. The table answers are given with respect to the informations collected in the following bibliographic references: [LH94a, Gro96].


Object-Oriented Criteria

class as templates class as collections inheritance sub-typing multi-inherit./sub-typing inheritance6=sub-typing classes as objects collection of objects dynamic/static object instantiation genericity or parameterization

Semantics


Method calls are synchronization points No explicit messages Inherited from VDM Not recommended [Gro96] but not forbidden Reference type Execution traces (with interleaving)

Value Comments Y N Y (Y) Y Y N (Y) (Y) N

(a), (b), and (c) supported Union types may be considered supertypes Inheritance and Subtyping are dierent concepts Collections of object references Objects created with the NEW statement

Value Comments

Semantics

(Y)

Calculus

(N)

Only static semantics [Gro96] stated informally No evidence for a VDM++ calculus found

5.3 Z++ The Z++ [LH94a, LH94b] speci cation language is based on Z [Spi92]. It was designed as a language which could express designs, in addition to provide a means for structuring incremental development of large systems. In making re nement the central concept of the semantics, conceptual simplicity is achieved. The concept of re nement also yields the various operations for composing classes. Within Z++ classes types and theories are considered equal concepts. Accordingly objects, elements, and models are equal concepts and so are con-formant sub-classing, sub-typing, and re nement. Classes are types and can be used wherever a type could be used in Z. The existence of a re nement relation between two classes implies that the re ned class is type-compatible with the parent class. Syntactically, a Z++ class speci cation consists of a name, an optional type parameter and a set of clauses which describe the various class features.

The extends clause lists a set of previously de ned classes that are inherited by this class.

The types clause consists of type identi er declarations local for the class.

The local variables declarations are attribute declarations, in the style of Z variable declarations.

The operations clause declares the types of the operations, as functions from a sequence of input domains to an output domain.

The returns clause de nes the output type of those attributes and functions of the internal state, that are externally visible. These are operations with no side-eects on the state.

The invariant gives a predicate that speci es the properties of the internal state, in terms of the local variables of the object. The invariant is guaranteed to be true of the state of an object instance between executions of the operations of the the object.

The actions clause gives the de nitions of the various operations that can be performed on instances of the class. Actions can be speci ed either as Z predicates or as B0 (cf. Abrial's B-Tool [Abr96]) procedural code. Additionally operations can be given explicit preconditions. Operations can be marked as spontaneous internal actions. These actions correspond to daemons in object-oriented terminology.

The history predicate speci es the admissible executions sequences of objects of the class. History predicates are either linear temporal logic (LTL) or real time logic (RTL) formulae.

Instead of the usual Z box notation an ASCII notation similar to object oriented programming languages is used. A type parameter can be used in the de nitions of the class body. It can be required to be a descendent of a certain class. Generic classes are templates for classes and are not types themselves. For each class C there is a corresponding type @C of object references. Methods can be used in two ways. If m is a method of class C it can be used as an operation on elements of object references (@C). m can also be used as an operation on the state of C. For the later usage it is required that m is used in a descend of C. These techniques allow the usage of Z Schema operations within classes. If C and D are internally consistent classes then D is a re nement of C via a re nement mapping of method names of C to those of D, and a data re nement R, a predicate on the combined state of C and D. The required conditions for re nement guarantee that the re nement concept forms the arrow of a category with products and co-products. Z++ permits several operations and relations on classes. There are operations for hiding and renaming features and for instantiating generic classes. The union operation creates a class which has the disjoint union of attributes of its arguments, and which conjoins the de nitions of identically named methods. Another operator forms the syntactic intersection of the de nitions of two classes. The class conjunction operator is also available. The following operators allow relationships of re nement or inheritance to be expressed between class expressions. A re nes operator is true if and only if there exists a re nement mapping and a data re nement relation between the two argument classes. The class equivalence operator is true if and only if two classes are re nements of each other. The inherits operator is true if and only if a class occurs in the extends list of another class. A semantics for Z++ is presented in [LH94b] and some rules for semantic analysis are presented. A mapping from Z++ to Z is lined out in [LH94a] which may allow a calculus for Z to be used for reasoning about Z++ speci cations. The table answers are given with respect to the informations collected in the following bibliographic references: [LH94a, LH94b].






Method invocation No explicit message passing Inherited from Z Classes are considered as types and may be used accordingly Reference type History speci ed in LTL or RTL

Value Comments Y N Y Y Y (N) N Y Y Y

(a), (b) and (c) supported subtyping equal to conformant subclassing A set containing the existing objects is provided Type parameters

Value Comments Y (Y)

[LH94b] see text

6 The algebraic approaches There have been numerous research experiments in extending algebraic speci cations in direction of object orientation. It is impossible to present all of them. We have chosen some typical approaches where object orientation is introduced at the speci cation level. It rules out several interesting works where the passage from algebraic speci cations to object-oriented programs is studied, such as the language ABEL [Dah87], which provides a way of composing formal speci cations and object-oriented programming, or the Larch/Smalltalk or Larch/C++ interface speci cation languages [CL94].

6.1 HOSA : Hidden Order Sorted Algebras The Hidden Order Sorted Algebra approach, developed by J. Goguen et al. [GD94, MG94], is more a semantic framework for object orientation (which could be used both at the speci cation and at the programming level) than a speci cation language. It is based on algebraic speci cations (the OBJ language) where some sorts are distinguished as \hidden" and some other ones as \visible". Intuitively, the rst ones correspond to the hidden states of the objects, and the others to the values which can be observed. Moreover, there is a partial order on the sorts, as in the order sorted algebra approach developed previously by some of the authors. This notion corresponds to subtyping. The main dierence with usual algebraic speci cations is in the notion of satisfaction of a property by a HOS-Algebra (Hidden Order Sorted Algebra): it is based on behavioural equivalence, i. e. a kind of observational equivalence based on the visible contexts. More precisely, an equation lhs = rhs of a hidden sort is satis ed if and only if for all context C of visible sort, C (lhs) = C (rhs) is satis ed. This choice is the formal counterpart of the notions of encapsulation of the state of an object and of information hiding: what is not observable via the interface of an object is not relevant. But proofs seem more dicult to perform with this notion of satisfaction than in more classical institutions. The interest of this work is to provide a complete and clean theory for HOS-algebras and their equational speci cations (existence of initial models, formal calculus, re nement, etc). The notion of class is formalised as a sort. Thus there is identi cation between a class of objects and the type of these objects. After a short discussion on the lack of a clear de nition for inheritance, the authors claim that inheritance is just module importation with preservation of the properties. It is a drastic simpli cation and may turn out to be inadequate to capture some useful aspects of inheritance. A community of objects is described by adding an identity argument to all the operations of

a module. Thus a community is homogeneous. There are no built-in creation and deletion of objects: identities are terms of an in nite prede ned sort of OBJ. In conclusion, this work is more a theoretical framework for the de nition of object-based formalisms than a \ready-to-use" speci cation method for object oriented approaches. It introduces two important semantic concepts: algebras with hidden sorts and behavioural satisfaction. The table answers are given with respect to the informations collected in the following bibliographic references: [GD94, MG94].





Value Comments Y Y N N Y Y (Y) N Y

all objects are OBJ3 speci cations and states are de ned using hidden sorts sort hiding not relevant not relevant

everything is a data structure built-in in OBJ3 +/-

Value Comments Y N Y Y Y Y N Y N Y

is a sort

is module importation is sub-sorting multiple subsorting see above as data structures

Value Comments Y Y

6.2 TROLL TROLL and OBLOG are 2 versions (textual and graphical) of the same speci cation language [JSHS91] developed in cooperation between the Technische Universitat Braunschweig and INESC in Lisbon within various European and national projects (IS-CORE, KORSO, OBLOG). The original application domains were Information Systems and Data Bases. TROLL-light [CGH92] is a sub-language of TROLL for which a formal semantics and a certi cation calculus have been stated. The semantics is based on categories and the notion of morphism is used everywhere, in particular for the modeling of structuring concepts, like objects, sub-objects, sharing, ... The certi cation calculus [Con94] is inspired from [FM91] and [FM92]. The main dierence between TROLL and TROLL-light is that there is no inheritance in TROLL-light. However, a formal treatment of inheritance is sketched in [EGS93]. An originality of this approach is the distinction between object templates and object classes. An object template is an intensional description of a kind of objects which have a common structure and the same behavior pattern. An object class is an extensional description of a time varying collection of objects with the same template. This view of classes makes it possible to consider classes as objects, thus to introduces meta-classes in a smooth way. There is a special class, INIT, and all the other classes are sub-objects of it (here the data base origin of the language is noticeable). In TROLL, inheritance is modeled as a relation between templates. Objects are described as a set of so-called object aspects : an object aspect is an object identity and a template; an object is an aspect plus all the derived aspects by inheritance, namely, all those aspects with the same identity and a template which is inherited by the original one. The dynamic aspects are formalized by events and processes. Here an event is a mixture of observations and actions on some object which can occur in \one instant of time". Processes are behavior patterns: they restrict the sequences of events allowed for the objects of a given template. Interactions between objects are synchronous, and ensured by sharing of sub-objects. TROLL-light is a good example of a true formal speci cation language with objects. Since all the examples given in the literature are related to data base problems, it is not clear that it is easily usable for the speci cation of fault-tolerant real-time systems. The table answers are given with respect to the informations collected in the following bibliographic references: [Con94, CGH92, EGS93, JSHS91]. There is another dialect of OBLOG, named GNOME [RS94] with a xed set of basic data

types, but more emphasis on the interactions between objects (for instance broadcasting), and on nested encapsulation via the concept of a region.






object as several aspects and state as attributes

sharing aggregation via k

Value Comments Y Y Y N Y N Y Y Y X

between templates with protection of the smaller template not relevant

Value Comments (Y) Y

6.3 Maude Maude [Mes93, MW92] is a language for specifying and programming concurrent objectoriented systems developed by J. Meseguer and collaborators. Maude builds on and extends the algebraic speci cation paradigm; the language includes, as a functional sub-language, what is essentially OBJ3 [GWM+93]. Furthermore, Maude inherits from OBJ3 all the mechanisms for modular structuring, including the various forms of importation, very expressive parameterization, and overloading via renaming. The basic concurrency model on which Maude builds is concurrent rewriting. Concurrent rewriting is a generalization of common term rewriting. In contrast to term rewriting systems, which are typically derived from equations, the rules considered here may involve arbitrary transformations of the underlying structures; in other words, concurrent rewriting may be regarded as a formalization of concurrent state transition systems, with states described by terms of an algebraic structure and rules expressing possible state transitions. More speci cally, a Maude object is represented by a record-like structure consisting of object name, object class name, and a list of attributes (pairs of attribute name and values). Messages are de ned by constructors which typically take one or more objects as arguments. A con guration is a multiset of messages and objects. Rewrite rules de ne \communication events", i.e. they specify how con gurations can be transformed by processing messages. In its most general form, the application of a rule transforms the messages and objects of its left-hand side by

absorbing the messages

modifying (the attributes of) some objects

deleting the remaining objects

possibly creating new objects

possibly producing new messages

Rules can be applied concurrently to dierent parts of a con guration. Rules can also express rather complex behaviour, including dynamic object creation and deletion and synchronous as well as asynchronous behaviour. The underlying mathematics is rewriting logic [Mes92] with rewriting of terms (over an algebraic structure) modulo associativity, commutativity and identity. The terms may be regarded as propositions about the systems, and rewriting as derivation or deduction. Thus, computation and deduction coincide, as in other logical systems.

Maude distinguishes between two kinds of inheritance. Class inheritance relates to the order-sorted structure; it refers to inheritance of attributes, messages and rules from an existing class when a subclass of that class is declared; a subclass may also introduce additional attributes and messages. Thus, the class hierarchy corresponds to the sort hierarchy. In contrast, module inheritance supports the reuse of code while permitting modi cation of behavior as described by the rules. Concurrent rewriting provides a very general model of concurrency. Thus it is not surprising that a large variety of other concurrency models can be embedded, including Petri nets, actors, or CCS. In its full generality, Maude should be regarded as a speci cation language. In Simple Maude, rewrite rules are restricted so that their left-hand sides consist of one object and at most one message, so that rewriting corresponds more closely to conventional invocation of object methods. In addition, the underlying algebraic structures are restricted to terminating and con uent term rewriting systems; thus, programs in Simple Maude can be executed reasonably eciently. The table answers are given with respect to the informations collected in the following bibliographic references: [Mes93, MW92].

Object-Based Criteria

Value Comments

object and states

Y

encapsulation synchronous requests asynchronous requests data abstraction data struct. of objects object identity intra-concurrency inter-concurrency

(Y) Y Y Y Y Y Y Y




Objects are essentially records of attribute-value pairs attributes can be hiding, but no encapsulation of rules cf. text cf. text essentially as in OBJ3 everything is a data structure as in functional rewriting (OBJ3)

Value Comments Y (Y) Y Y Y Y N Y Y Y

is mapped to a sort eect can be achieved by suitable structuring 2 forms; cf. text is sub-sorting multiple subsorting see above but can be expressed by meta-objects can be achieved by programming

Y (Y)

via mapping into rewriting logic none given, but appears to be feasible in rewriting logic

similar to OBJ3

Value Comments

6.4 AS-IS : Algebraic Speci cations with Implicit States AS-IS, Algebraic Speci cations with Implicit State, is an on-going research project at LRI. One rst step of this work has been to make algebraic speci cations more convenient to use when specifying systems whose external behavior depends on an internal state. A system is speci ed via some classical algebraic data types, with in addition some accesses which are the operations used to observe the implicit state, and some modi ers which are used to change the state, i.e. the accesses. A state is an algebra, and a change of state is a transformation of algebra. This approach has been used by Alexander Zamulin to introduce some typing in Gurevitch's evolving algebras [Zam97]. This is dierent from HOSA, because the state is not a sort. It is much closer to the VDM or Z notion of state. It is dierent of TROLL because there is no distinction between attributes and observation methods: they are all modeled as accesses. It prevents to make too early implementation choices. This approach makes it possible to specify systems with one centralised state, possibly containing complex data structures [DG93]. It has been validated on the speci cation of a complex control system [GDK96]. A revision of the semantics is reported in [KGD97] and an extension toward encapsulated and connected objects is currently under development. The main points are sketched below. Some built-in data types, operations, accesses and modi ers are introduced in order to make it possible to specify classes and collections of objects. Here, classes correspond to templates. Collections are speci cations of multi-objects systems where creations and deletions of objects, connections, disconnections of objects, signal passing between connected objects can occur. Among the built-in features of AS-IS are names, i.e. identities of object, some predicates for testing the existence of objects or their connections, signals between connected objects. The communications between connected objects are synchronous. There is no notion of inheritance. The management of object identities was in uenced by TROLL, and by [Wie91]. The concepts of connections and signals were in uenced by the BOSO model of distributed synchronous reactive systems [BVN96]. One of the main goal of the work is to give a uniform formal semantics to objects and collections, in order to make it possible to consider collections as objects, thus to have a hierarchical compositional approach. The formalism is oriented towards the formal description of synchronous reactive systems. Atomicity of the modi ers is wired in the theory, thus it should be convenient to use it for giving a formal semantics to the Coordinated Atomic Actions developed in DeVa [RRS+97].

The table answers are given with respect to the information collected in the following bibliographic references: [DG93, KGD97, GDK96]. Another relevant reference on similar approaches is [EO94].





Value Comments Y Y Y N Y N Y Y Y

simultaneity simultaneity

Value Comments Y N N Y N N N Y Y N

classes are not types subsorting for the used data types not relevant

Value Comments (Y) N

7 The High Level Petri Nets Approaches Petri nets and high-level nets are two representative of the model-based class in the sense that they describe the state of a system by means of places which contain \black tokens" for the conventional Petri nets and structured tokens for high-level nets. A set of transitions which consist of a pre- and a post-condition, describes how the system state change by consuming and producing tokens in the various places of the net. It is well known that Petri/high-level nets have attractive characteristics such as a natural graphical representation; many mathematical studies have been performed on them, and they are well-suited for the description of concurrency (interleaving and true concurrency depending on the underlying semantics). However, the absence of structuring capabilities has been one of the main criticisms raised against Petri nets/high-level nets. Thus, there have been many attempts to introduce structuring principles in nets of this kind [BCM88, Kie89, JR91, Gue94]. The attractive characteristics of Petri/high-level nets have prompted researchers to enrich these formalisms with object-oriented features. Two main approaches have emerged to combine Petri nets and object-orientation. In the rst one the behavior of each class of objects is governed by a net and the tokens (data structures) that circulate in the net represent the objects. In the second one each object correspond to a net and the places play the role of the attributes. In both approaches the methods correspond to transitions.

7.1 CLOWN : Class Orientation With Nets CLOWN [BC93, BCC95, BCC96] is the object-oriented extension of an earlier formalism for speci cation called OBJSA nets [BCM88, BdCM96]. Let us mention that: SA stands for superposed automata nets (SA nets) [DMPS82] and OBJ stands for the algebraic speci cation language OBJ3 [GWM+93]. SA nets is a model of systems of sequential non-deterministic processes which interact with each other in a synchronized way (transition fusion). OBJSA nets improves superposed automata nets by allowing structured tokens which are algebraically described by means of OBJ3. CLOWN de nes a class by a set of textual clauses (including inherits, interface, places, methods) plus a class net; its semantics is a corresponding OBJSA net, i.e. a net which retains the structure of the class net and is marked by means of tokens which represent class instances as tuples derived by the textual clauses and consisting of an identity and attributes values. As in OBJSA, OBJ3 is used to algebraically describe the data structures: the objects attributes. Each class is characterized by a name, an interface which describes the partners the class interacts with, and the description of the pre- and post-conditions of every method present in the SA net. A speci c class called the \compound class" describes how the various classes of a system mutally interact together, i.e. how the various transition (methods) are superposed. In CLOWN, inheritance is restricted to specialization and rede nition inheritance (ingredients can be added and rede ned) in a way that the substitutability principle is guaranteed. The substitutability principle adopted in CLOWN is based on the ST-preorder a relationship introduced in [PS92]. Hence inheritance hierarchy coincides with a kind of state-based observational sub-typing hierarchy. The fact that, in CLOWN, class instances are tuples of attribute values does not provide any native intra-concurrency, in other words two methods on the same object can not occur concurrently without speci c constructions (through the compound class). Since transition fusion is the interaction mechanism, encapsulation is guaranteed. An originality of CLOWN is its development system that allows the speci er to design graphically the SA net of a class and use a textual representation for any other elements of the class. CLOWN is an ongoing work and has few results comparing to its ancestor OBJ-SA but the answers given in the table concerns CLOWN only, even if we would have answered dierently for OBJS-SA. The table answers are given with respect to the informations collected in the following bibliographic references: [BC93, BCC95, BCC96].

Object-Based Criteria

Value Comments

object and states

Y

encapsulation synchronous requests asynchronous requests data abstraction data struct. of objects object identity intra-concurrency inter-concurrency

Y Y N Y N Y N Y




tuple of identi er and attributes values, i.e. typed (algebraic speci cation) values transition fusion

algebraic abstract data types (OBJ3) due to Petri net transitions concurrency

Value Comments Y N Y Y Y N N N Y Y

with semantic constraints Observational using the ST-preorder relation with semantic constraints

Value Comments (Y) N

in terms of OBJ-SA (but not seen in not seen in a publication)

7.2 CO : Cooperative Objects Cooperative Objects (CO) [Bas92, BP93, SB94] is a formalism that aims at modeling a system as a collection of objects that cooperate and evolve concurrently. Cooperative Objects has been in uenced, on the one hand, by the HOOD method [Age89] and, on the other hand, by the Eiel [Mey91] programming language regarding its object-oriented features. Each Cooperative Object belongs to a class. A Cooperative Object possess a type (the one of the class it belongs), an identity, and a state composed of values of built-in data types and/or references on other cooperative objects. The object identities play the role of references and data structures of object identities are possible although the built-in data structures are rather limited. A class of Cooperative Objects consists of an interface which mainly declares the services provided by the class, and of an implementation which details how these services are realized. Moreover, an interface comprises an Object Control Structure (ObCS, term borrowed from HOOD) which describes the activation conditions of the services. Such an ObCS corresponds to a net described by means of a High Level Petri Nets formalism. The implementation part of a class is mainly composed of another ObCS which is meant to describe the inner behaviors of the objects. Both inter- and intra-object concurrency are available, and the semantics is given in terms of a step semantics. In Cooperative Objects, inheritance coincide with sub-typing. It means that a sub-class must preserves the external behaviors of its super-class. This concern is addressed by means of an observational equivalence restricted to the observable behaviors of the sub-class. Finally, an interesting characteristic of Cooperative Objects is the notion of composite class which allows to gather various objects in one class. This notion is dierent of inheritance and allows to examine a system at dierent levels. The table answers are given with respect to the informations collected in the following bibliographic references: [Bas92, BP93, SB94, CHSB96, BP96, Bas95].





Value Comments Y Y Y Y N Y Y Y Y

blocking client server protocol client server protocol built-in data types due to Petri net transitions concurrency idem

Value Comments Y N Y Y N N N N Y (Y)

specialization

on data types

Value Comments Y N

step semantics with transition system

7.3 OPN : Object Petri Nets Object Petri Nets (OPN) are presented as an extension of Coloured Petri nets which integrates object-oriented structuring and concepts. The components of a net, whether tokens, places, transitions, or even subnets, now become objects. Each Petri net can be de ned as a class which can be, as usual, instantiated. In addition to places and transitions, a class contains data elds and functions. Data elds have types which may be simple (integer, real, boolean, . . . ), class, or multi-set which generalises classical Petri net places (which are multi-sets of tokens). New functions can be de ned assuming prede ned types and functions. Test and inhibitor arcs are added to classical arcs and provide a way of testing concurrently the state of an object without modifying the object state. Both places and transitions are provided in their classical form, but can also be re ned as super-places and supertransitions. A super-place, like a classical place, can act as the source or sink of tokens, but the logic for oering or accepting tokens is given by a subnet. A super-transition, like a classical transition, can synchronise the transfer of tokens to and from a number of places, but the detailed logic for doing so is given by a subnet. Object identi ers are available in the speci cation of classes and all the components of an object can be accessed through the object identi er. Simple inheritance is de ned and can be used for specialization, rede nition and design. Subtyping is not addressed. Other kind of communication between objects like call/return or pattern directed communications can be modeled using the OPN features. In fact the OPN features allow for various kinds of object coordinations. Thus synchronous or asynchronous communications are possible. The formal semantics of OPNs does not consider the matter of scoping and the import/export of identi ers. It is assumed that any implementation will provide some form of syntactic constraint. Thus, the textual language LOOPN++ provides an \export" clause, while the proposed graphical conventions indicate exported components with a double outline. Dynamic creation of objects is possible, just as it is possible to create arbitrarily-coloured tokens in CPNs. However, since subnets are objects, this allows the dynamic creation of subnets. Genericity is not directly available in the formalism but the data type de nition and the name binding can eventually be used for such purpose. Semantics of OPN is given by translation to coloured Petri nets in order to preserve the intra and inter concurrency which can be expressed in the step semantics of coloured petri nets.

Object Petri Nets have recently been rede ned in [Lak96b] with a more formal approach and some generalisation inspired from the -calculus (the new OPN version is called ON). The general use of names allows especially for the generalisation of place or transition fusion or substitution using name bindings. In ON everything is viewed as a class instance. A class may be primitive or structured (a compound entity) and has a guard associated to it. A guard is used to test the validity of an instance in a similar way than in Eiel. The table answers are given with respect to the informations collected in the following bibliographic references: [Lak96b, Lak96a, Lak95].





Value Comments Y N Y Y N Y Y Y Y

state = typed attributes attributes are shared between classes (place fusion, . . . ) transition fusion dierent coordination models built-in data types using the `star' operator for multi-set of object identi ers due to Petri net transitions concurrency idem

Value Comments Y N Y N N N N N Y (N)

specialization, rede nition and design

eventually with data types and name binding

Value Comments Y N

step semantics with transition system

7.4 CO-OPN/2 : Concurrent Object Oriented Petri Nets CO-OPN/2 [BBG97] (Concurrent Object-Oriented Petri Nets) is a speci cation language designed for the speci cation and the modeling of large concurrent systems. The two underlying formalisms of CO-OPN/2 are the algebraic speci cations and the Petri nets which are combined in a way that is similar to algebraic nets [Rei91]. The former is used to describe the data structures and the functional aspects of a system, while the later serves to model its concurrent features. For the sake of homogeneity regarding the notion of subtyping, order-sorted algebraic speci cations [GM92] have been adopted for the description of the data structures. An object is considered as an independent entity composed of an internal state and which provides some services to its environment. The only way to interact with an object is to ask for its services; the internal state is then protected against uncontrolled accesses. Thus, there is no way of violating encapsulation. CO-OPN/2 de nes an object as being an encapsulated algebraic net in which the places compose the internal state and the transitions model the concurrent events of the object. A place consists of a multi-set of algebraic values. The transitions are divided into two groups: the parameterized transitions, also called the methods, and the internal transitions. The former correspond to the services provided to the outside, while the latter compose the internal behaviors of an object. Contrary to the methods, the internal transitions are invisible to the exterior world and may be considered as being spontaneous events. An important characteristic of the speci ed systems is their potential dynamic evolution in terms of the number of objects they may include. Thus, the dynamic creation of objects is possible. In order to describe similar dynamic evolving systems, objects are grouped in classes. A class is an object template: all the objects of one class have the same structure. In CO-OPN/2 approach, the interaction with an object is synchronous, although asynchronous communications may be simulated. Thus, when an object requires a service it asks to be synchronized with the method (parameterized transition) of the provider object. The synchronization policy is expressed by means of a synchronization expression, which may involve many partners joined by three synchronization operators (one for simultaneity, one for sequence, and one for alternative or non-determinism). For example, an object may simultaneously request two dierent services of two dierent partners, followed by a service request to a third object. Each object possesses its own behavior and concurrently evolves with the others. The Petri net model naturally introduces both inter-object and intra-object concurrency into CO-OPN/2 because the objects are not restricted to sequential processes. The step semantics of CO-OPN/2 allows for the expression of true concurrency which is not the case of interleaving semantics. Nevertheless, the purpose of CO-OPN/2 consists in capturing

the abstract concurrent behavior of each modeled entity, with the concurrency granularity associated to methods invocations rather than to objects. A set of method calls can be concurrently performed on the same object. Within CO-OPN/2 framework, each class instance has an identity, which is also called an object identi er, that may be used as a reference. Moreover, a type is explicitly associated with each class. Thus, each object identi er belongs to at least one type. An order-sorted algebra of object identi ers is constructed in order to re ect the subtyping relation which is established between the classes types, i.e. two carrier sets of object identi ers are related by inclusion if, and only if, the two corresponding types are related by subtyping. Since object identi ers are algebraic values, it is possible to de ne data structures which are built upon object identi ers, e.g. a stack or a queue of object identi ers. Obviously, the places of algebraic nets may contain object identi ers. Inheritance and subtyping are two dierent notions. Inheritance is a syntactic mechanism which frees the speci er from the necessity of developing classes from scratch and is mainly employed to reuse parts of existing speci cations. A class may inherit all the features of another and may also add some services or change the description of some services already de ned. CO-OPN/2 subtyping relationship is based upon the strong version of the substitutivity principle [Ame89, LW94]. This principle implies that, in any context, any class instance of a type may be substituted for a class instance of its super-type while the behavior of the whole system remains unchanged. In other words, the instances of the sub-type have a strong semantic conformance relationship with the super-type de nition. This conformance relationship is based, in CO-OPN/2, upon the bisimulation between the semantics of the super-type and the semantics of the sub-type restricted to the behavior of the super-type. Both inheritance and subtyping relationships must be explicitly given but the respective hierarchies generated by these relationships do not necessarily coincide. In other words, two classes related by inheritance are not necessarily related by subtyping. Identifying both inheritance and subtyping hierarchies leads to several limitations as stated by Snyder [Sny86] and America [Ame87]. The table answers are given with respect to the informations collected in the following bibliographic references: [BB94, BB95, BBG96, BBG97].






synchronization expressions (i.e. `generalization' of transition fusion) algebraic abstract data types algebraic abstract data types over class types

Value Comments Y N Y Y Y/N Y N N Y Y

syntactic semantic

Value Comments Y Y

step semantics with transition system On a part of the formalism: valid only for models based on the initial algebra for the ADT

8 The Temporal Logic Approaches Temporal logics are axiomatic formalisms that are well suited for describing concurrent and reactive systems. A common aspect associated with temporal logics is a notion of time and state. A speci cation written in terms of temporal logic describes in a declarative manner admissible sequences of states for the speci ed system, i.e. its expected behaviour; concurrency is admitted rather than enforced by the speci cation. Many object-oriented speci cation approaches based on temporal logic (TLA+, TRIO+, TL approach of Fiadeiro and Maibaum [FM92]) are motivated by the need for structuring the speci cation of concurrent systems. They provide no (or only rudimentary) support for real object-oriented features like class hierarchies, inheritance, and object creation. Object-based paradigms are approached by augmenting the language of temporal logic with means for encapsulating state and for de ning interfaces (attributes, methods). Such a speci cation may be interpreted as a description of the behavior of an object; intraobject concurrency is admitted. In addition means are provided for modular composition of (object) speci cations; this may be interpreted as a description of a collection of objects interacting with each other (inter-object concurrency).

8.1 TRIO+ TRIO+ [MP94] is an object-oriented language for modular system speci cation. It is based on TRIO [MMG92], a rst-order temporal language that is designed for specifying embedded and real-time systems. Much of the summary given here is based on [MP94]. TRIO is a rst-order temporal logic language for developing executable speci cations of real-time systems. It handles time in a quantitative way by providing a metric to indicate distance in time between events and length of time intervals. TRIO speci cations are parameterized with the time domain; hence, TRIO's semantics is capable to deal with dierent time structures ranging from nite over discrete to dense time. TRIO provides support for a variety of validation activities, like speci cation testing, simulation, and property proof. An axiom system for TRIO has been given in [FM94]; it allows to reason about speci cations by developing formal proofs. The major validation approaches provided are a tableau method and history checking, i.e., checking that a history of the system satis es the speci cation. Much emphasis is placed speci cally on the executability of formal speci cations, as a means to assess the adequacy of the requirements. The TRIO tool can also be used as a test-case generator. TRIO+ is designed to extend TRIO with the ability to construct speci cations of complex systems in a systematic and modular way. It combines the use of constructs for hierarchical system decomposition and object-oriented concepts, like inheritance and genericity, with a graphical notation. The universe of objects is partitioned into classes. Accordingly a TRIO+ speci cation consists of class de nitions; a class is a set of axioms describing the system.

simple class

{ { { {

class interface (methods) temporal domain (real/rational/integer) declaration of time-(in+)dependent predicates, variables, functions collection of axioms (TRIO formulas)

structured class

{ { { {

classes with \parts" - modules no recursion modules cannot be used in axioms; interface items can. connections between modules: equivalence between interface items

{ arrays of modules The semantics of a class with inheritance, connections or parameter instantiations is given in terms of an equivalent class without these constructs that is obtained by attening the textual structure of the original class speci cation. According to a reference in [MP94], TRIO+ has been applied to a case study extracted from a real-life industrial application: ENEL (Italian Electric and Energy Board). A further interesting study was conducted employing a dual language approach: TRIO was used for system speci cation and timed Petri nets were used for specifying high-level design; an axiomatization of timed Petri nets was developed. Now axiom system may be used to prove that the (PN) high-level design satis es the (TRIO) speci cation [GMMP91]. The table answers are given with respect to the informations collected in the following bibliographic references: [MP94, MMG92].

Object-Based Criteria Value Comments object and states

Y

encapsulation

Y

synchronous requests

(Y)

asynchronous requests data abstraction data struct. of objects object identity intra-concurrency inter-concurrency

N (N) (N) Y Y Y

every entity possesses a state which can be modi ed; this is expressed through state dependent predicates/functions/variables. TRIO+ provides so-called \connections" between objects. visibility of items stated explicitly (interface) connections express equivalences on the values of items in imported modules; no explicit event synchronization no explicit message sending only enumeration types and (built-in) scalar types (real, integer, character, . . . ) arrays of modules - static implicit identity: an object is identi ed with its entire history of evolution behavior speci ed in terms of temporal logic collection of objects with connections between them

Object-Oriented Criteria class as templates class as collections

Value Comments (Y) Y

inheritance

Y

sub-typing

N

multi-inherit./sub-typing inheritance6=sub-typing classes as objects collection of objects dynamic/static object instantiation genericity or parameterization


Y/N N N

see inheritance the universe of objects is partitioned into classes. is viewed as receiving attributes from other classes; (a) and (b) supported no need to consider a class as a type: restrictive syntax, no dynamic binding, no monotonicity consideration on behavior multiple inheritance supported in TRIO+ no sub-typing (see above)

Y

not considered in TRIO structured classes may be used for specifying a system consisting of several components no dynamic instance creation; instantiation of parameterized objects may be viewed as static instantiation; no provisions for object creation only simple types

Y (N)

[MP94]. no explicit calculus for TRIO+, but an axiomatization of TRIO is given.

Y N/Y

Value Comments

8.2 OO-LTL OO-LTL [CvH97] is a preliminary working name for a temporal logic approach towards object-oriented speci cation conducted in Ulm. The basic formalism underlying OOLTL is a discrete linear-time temporal logic, speci cally the temporal logic of actions (TLA) [Lam94]. Some extensions for structuring TLA-speci cations have been de ned in the TLA+ formalism [Lam91]; however, TLA+ provides mainly a textual structuring mechanism rather than a real module concept. The main idea behind OO-LTL is to employ object oriented structuring features as a module concept for the formal development of concurrent systems, including aggregation and parameterization. In contrast to some well established OO languages, OO-LTL is a hybrid approach, where certain entities, e.g. abstract data types, are not considered to be objects but rather elements of some type, including simple values, functions, and predicates. The types may be organized in a subtype hierarchy. Objects are considered as encapsulating a state and providing an interface consisting of attributes and operations. They also exhibit own activity. The state is observable through attributes only. It can be modi ed from outside by activating operations; this is formalized as a synchronization mechanism that models calls of object's methods. The state may also change as a result of the object's own activity; this behavior is expressed by TLA formulae. OO-LTL allows to model (static) collections of objects expressed in a structured speci cation. Complex objects can be re ned in terms of several object interacting with each other by means of the services they provide, by communicating through shared objects and through common arguments of their parameters. OO-LTL is not fully developed yet and at the current state it should be called object-based or class-based rather than object-oriented, since several object-oriented mechanisms, including class-subclass relation, inheritance, and object creation, are not (explicitly) represented in the formalism. The formalism is being modeled in PVS [SOR93] to make use of the capabilities for developing proofs supported by PVS. The table answers are given with respect to the informations collected in the following bibliographic references: [CvH97].

Object-Based Criteria object and states encapsulation

Value Comments Y Y

synchronous requests asynchronous requests data abstraction data struct. of objects

Y N Y N

object identity

(Y)

intra-concurrency inter-concurrency

Y Y

Object-Oriented Criteria class as templates class as collections

Y N

(Y)

sub-typing multi-inherit./sub-typing

Y Y

inheritance6=sub-typing classes as objects collection of objects

(Y) N Y

dynamic/static object instantiation

N/Y


rst-order and inductive abstract data types an object is identi ed by a unique name; however, the use of this name in TLAformulae is restricted. objects own activity objects interacting with each other

Value Comments

inheritance

genericity or parameterization

observable and accessible through attributes and operations operation activation mechanism (method call)

Y

not directly supported by the language but certain mechanisms for reusing a speci cation can be interpreted as inheritance. according to PVS in the restricted sense a of inheritance (see above) Not applicable since objects are as of yet not considered as values A speci cation may describe the aggregation of several objects instantiation of object parameters (in structuring the speci cation) objects parameterizable with types, predicates, functions, and objects

Value Comments Y Y

Transformational semantics in terms of TLA Calculus for TLA (encoded in PVS)

()

()

(n)

(n)

()

()

()

()

()

()

(n)

()

y/n

()

y/n

()

(n)

n/y n/y

X

Semantics Calculus

6

class as collections inheritance sub-typing multi-inherit./sub-typing inheritance=sub-typing classes as objects collection of objects dynamic/static object instantiation genericity or parameterization

class as templates

data abstraction data struct. of objects object identity intra-concurrency inter-concurrency

object and states encapsulation synchronous requests asynchronous requests

Object-Z VDM++ Z++ HOSA TROLL Maude AS-IS CLOWN CO OPN CO-OPN/2 TRIO+ OO-LTL

()

(n)

()

()

()

()

() (n)

()

(n)

Table 1: Comparison table between the object-oriented speci cation languages.

9 Global Table The table 1 gives the union of criteria answers for all the formalisms studied in this paper.

Legends: 1. stands for Y 2. nothing stands for N 3. () stands for (Y) and indicates a partial yes and the justi cation is given in the corresponding section (resp. (n) stands for a partial no). 4. Special cases : '/' is used when two answers must be given (for example y/n in row of TRIO+ for the colum multi-inherit./sub-typing corresponds to a yes for multiple

inheritance and a no for multiple subtyping, furthermore a yes or a no in such column concerns both topics). X stands for uncertain.

10 Conclusion The main body of the paper presented a comparison of various object-oriented formalisms from a general point of view. In this concluding section we address DeVa-speci c aspects more directly. The initial requirements of the DeVa project, as described in the proposal, point out the following aspects concerning the choice and the integration of speci cation formalisms: Structuring: the main structuring approach chosen in DeVa is that of object orientation, which shall deal with logical complexity and tackle dependability issues. Concurrency: DeVa must cover the development of distributed systems. To this end, the speci cation formalism should be able to describe distributed concurrent entities which collaborate or compete in order to compute the desired functionalities. Real-time: In order to facilitate the design and validation of real time software, timing speci cations must be taken into account during the development process. Analysis of temporal properties of systems could be made, in DeVa, based on the system temporal speci cation. Veri cation: DeVa must develop methods for veri cation of object-oriented software properties by formal testing and proof. Thus the formalism used must be capable of supporting the derivation of test patterns from formal speci cations and be supported by an adequate proof system. Validation: In addition to the usual functional requirements, the formalism must support the speci cation of non-functional requirements. This is particularly important for the formal speci cation of design components of the conceptual framework, such as coordinated atomic actions or meta-objects and re ection. Since object-orientation has been chosen as the main structuring approach, it is of rst importance to introduce it as soon as possible in the development process, during the speci cation and design activities. However, it is clear from this survey that object-oriented formal speci cation is a lively research topic, with a big diversity in the approaches and in the interpretation of some key concepts of object orientation: class, inheritance, methods/events/actions. There are also some dierences in the degree to which the formalisms presented here

introduce object orientation: some are only object based (with objects, without classes), some have the notion of class without dynamic creation of objects, or without inheritance. Very few of them include all the features of object-orientation. Given the objectives of DeVa, some aspects of the speci cation formalism are especially important. First, in order to take advantage of the use of a formal approach for validation and veri cation, a complete and precise semantics and a proof systems are mandatory, for tests and proofs. Moreover, designing dependable complex systems, it is clear that encapsulation and data abstraction are key concepts. Designing distributed real-time systems requires intra and inter concurrency, with safe notions of composition (to allow independent design) and atomicity, to allow easy re nement of concurrent systems. The above notions, namely encapsulation, abstraction, composition and atomicity are also of rst importance for validation and veri cation since they prevent the complexity explosion of these activities. Another point is that static checks should be encouraged as far as possible. Object-oriented approaches are very dynamic by essence and do not facilitate these kinds of activities. However, it is now recognized that some simple choices can improve signi cantly the possibilities of static veri cations. It is the case of the distinction between inheritance and subtyping, which is a condition for ensuring safe type checking. Considering all these facets, the general conclusion is that among all the formalism surveyed in this paper there does not exist a single one that provides all the capabilities required in the DeVa context and thus would suggest itself as the formalism of choice. This is not surprising since the whole eld is an active research area. As a consequence, it appears to be necessary to pursue, in the DeVa context, several complementary approaches to objectoriented speci cation that are based, or derived from, dierent paradigms. CO-OPN/2 is being developed as the primary formalism for modeling processes. The focus of the work on OO-LTL is on providing a basis for formal proofs of properties stated in temporal logic. Continuing work on AS-IS will investigate the algebraic approach further. It is expected that the ideas from these dierent lines of research will be brought together more closely in the course of the DeVa project.

11 Acknowledgements We would like to thank the following persons who have helped us to improve some parts of this report: C. Lakos for Object Petri Nets, F. de Cindio for CLOWN, R. Bastide for

Cooperative Nets and the referees of the DeVa project, namely P. Thevenod, J.C. Fabre and S. Romanovsky.

12 References [Abr96] J. R. Abrial. The B Book - Assigning Programs to Meanings. Cambridge University Press, 1996. [Age89] European Space Agency. HOOD reference manual issue 3.0, 1989. [Ame87] Pierre America. Inheritance and subtyping in a parallel object-oriented language. In J. Bezivin, J.-M. Hullot, P. Cointe, and H. Lieberman, editors, ECOOP'87: European conference on object-oriented programming: proceedings, volume 276 of Lecture Notes in Computer Science, pages 234{242, Paris, France, June 1987. Springer-Verlag. [Ame89] Pierre America. A behavioural approach to subtyping in object-oriented programming languages. Technical Report 443, Philips Research Laboratories, Nederlandse Philips Bedrijven B. V., April 1989. Revised from the January 1989 version. [Bas92] Remi Bastide. Objets Cooperatifs: un formalisme pour la modelisation des systemes concurrents. PhD thesis, Universite Paul Sabatier de Toulouse, February 1992. [Bas95] Remy Bastide. Approaches in unifying Petri nets and the object-orientation approach. In Proceedings of the \Application and Theory of Petri Nets 1995" workshop on \Object-Oriented Programming and Models of Concurrency", Torino, Italy, June 1995. [BB94] Olivier Biberstein and Didier Buchs. An object-oriented speci cation language based on hierarchical algebraic Petri nets. In R. Wieringa and R. Feenstra, editors, Working papers of the international Workshop on Information System Correctness and Reusability IS-CORE'94, pages 47{62, Amsterdam, The Netherlands, September 1994. vrije University. Also available as Tech. Report (EPFL-DI-LGL No 94/76). [BB95] Olivier Biberstein and Didier Buchs. Structured algebraic nets with objectorientation. In Proceedings of the rst international workshop on \Object-Oriented Programming and Models of Concurrency" within the 16th International Conference on Application and Theory of Petri Nets, Torino, Italy, June 26-30 1995. [BBG96] Olivier Biberstein, Didier Buchs, and Nicolas Guel . CO-OPN/2 : A speci cation language for distributed systems engineering. Tech. Report 96/167, Swiss Federal Institute of Technology (EPFL), Software Engineering Laboratory, Lausanne, Switzerland, 1996.

[BBG97] Olivier Biberstein, Didier Buchs, and Nicolas Guel . Object-oriented nets with algebraic speci cations: The CO-OPN/2 formalism. In G. Agha and F. De Cindio, editors, Advances in Petri Nets on Object-Orientation, Lecture Notes in Computer Science. Springer-Verlag, 1997. To appear. [BC93] Eugenio Battiston and Fiorella De Cindio. Class orientation and inheritance in modular algebraic nets. In Proceedings International Conference on Systems, Man and Cybernetics, volume 2, pages 717{723, Palais de L'Europe H^otel Westminster, Le TouquetFrance, October 1993. Ecole Centrale de Lille. [BCC95] E. Battiston, A. Chizzoni, and F. De Cindio. Inheritance and concurrency in CLOWN. In Proceedings of the \Application and Theory of Petri Nets 1995" workshop on \Object-Oriented Programming and Models of Concurrency", Torino, Italy, June 1995. [BCC96] E. Battiston, A. Chizzoni, and F. De Cindio. Modeling a cooperative environment with clown. In G. Agha, F. De Cindio, and A. Yonezawa, editors, Proceedings of the second international workshop on \Object-Oriented Programming and Models of Concurrency" within the 16th International Conference on Application and Theory of Petri Nets, pages 12{24, Osaka, Japan, June 24 1996. [BCM88] Eugenio Battiston, Fiorella De Cindio, and G. Mauri. OBJSA nets: a class of high level nets having objects as domains. In Grzegorz Rozenberg, editor, Advances in Petri Nets 1988, volume 340, pages 20{43. Springer-Verlag, 1988. [BdCM96] Eugenio Battiston, Fiorella de Cindio, and Giancarlo Mauri. Modular algebraic nets to specify concurrent systems. IEEE Transactions on Software Engineering, 22(10):689{705, October 1996. [BP93] R. Bastide and P. Palanque. Cooperative objects: a concurrent, petri-net based, object-oriented language. In IEEE / System Man and Cybernetics 93, pages 286{291, Le Touquet (France), October 1993. Elseiver Science Publisher. [BP96] Remi Bastide and Philippe Palanque. Modeling a groupware editing tool with cooperative objects. In G. Agha, F. De Cindio, and A. Yonezawa, editors, Proceedings of the second international workshop on \Object-Oriented Programming and Models of Concurrency" within the 16th International Conference on Application and Theory of Petri Nets, pages 1{11, Osaka, Japan, June 24 1996. [BVN96] F. Boulanger and G. Vidal-Naquet. Object execution model for reactive modules with a c++ implementation. ECOOP'96, Workshop on Objects and Real Time, jul 1996. Also available as Rapport LRI, no 946. [CGH92] S. Conrad, M. Gogolla, and R. Herzig. Troll-light: a core language for specifying objects. 92-02, Technische Universitat Braunschweig, 1992.

[CHSB96] Walid Chainbi, Chihab Hanachi, and Christophe Sibertin-Blanc. The multiagent prey-predator problem : A petri net solution. In Proceedings of the IMACS-IEEESMC conference on Computational Engineering in Systems Application (CESA'96), pages 692{697, Lille, France, July 1996. [CL94] Yoonsik Cheon and Gary T. Leavens. The Larch/Smalltalk interface speci cation language. ACM Transactions on Software Engineering and Methodology, 3(3):221{253, July 1994. [Con94] S. Conrad. On certi cation of speci cations for troll-light objects. In RECENT trends in data type speci cation: workshop on speci cation of abstract data types: COMPASS: selected papers, number 785 in Lecture Notes in Computer Science, pages 158{172. Springer Verlag, 1994. ~ von Henke. Formal speci cation and veri cation of object[CvH97] E. Canver and F.W. based systems in a temporal logic setting. Technical Report Second Year Report of the Esprit Long Term Research Project 20072 \Design For Validation", University of Newcastle Upon Tyne, England, Department of Computing Science, 1997. [Dah87] Ole-Johan Dahl. Object oriented speci cation. In Bruce Shriver and Peter Wegner, editors, Research Directions in Object-Oriented Programming, pages 561{576. The MIT Press, Cambridge, Mass., 1987. [DD90] D. Duke and R. Duke. Towards a semantics for object-z. In VDM'90: VDM and Z!, volume 428 of Lecture Notes in Computer Science. Springer-Verlag, 1990. [DG93] P. Dauchy and M.-C. Gaudel. Algebraic speci cations with implicit state. In Working papers of the international Workshop on Information System Correctness and Reusability IS-CORE'93, Hannover, October 1993. Also available as Rapport LRI, no 887. [DKRS91] R. Duke, P. King, G. A. Rose, and G. Smith. The Object-Z speci cation language. In T. Korson, V. Vaishnavi, and B. Meyer, editors, Technology of Object-Oriented Languages and Systems: TOOLS 5, pages 465{483. Prentice Hall, 1991. [DKS91] R. Duke, P. King, and G. Smith. Formalising behavioural compatibility for reactive object-oriented systems. In Proceedings of 14th Australian Computer Science Conference (ACSC-14), 1991. [DMPS82] F. De Cindio , G. De Michelis, L. Pomello, and C. Simone. Superposed automata nets. In C. Girault and W. Reisig, editors, Application and Theory of Petri Nets, number 52 in Informatik Fachberichte, pages 229{279. Springer-Verlag, 1982. [DvK92] E.H. Drr and J. van Katwijk. VDM++ - A Formal Speci cation Language for Object-Oriented Designs. In Computer Systems and Software Engineering, pages 214{219. IEEE Computer Society Press, 1992. Proceedings of CompEuro'92.

[EGS93] H.-D. Ehrich, M. Gogolla, and A. Sernadas. Objects and their speci cation. In RECENT trends in data type speci cation: workshop on speci cation of abstract data types joint with the 4th COMPASS...: selected papers, number 655 in Lecture Notes in Computer Science, pages 40{65. Springer Verlag, 1993. [EO94] H. Erhig and F. Orejas. Dynamic abstract data types: An informal proposal. In EATCS Bulletin, volume 53, pages 162{? Springer-Verlag, June 1994. [FM91] J. Fiadeiro and T. Maibaum. Temporal reasoning over deontic speci cations. Journal of Logic and Computation, 1(3):357{395, 1991. [FM92] J. Fiadeiro and T. Maibaum. Temporal theories as modularization units for concurrent system speci cation. Formal Aspects of Computing, 4(3):239{272, 1992. [FM94] M. Felder and A. Morzenti. Validating real-time systems by history-checking trio speci cations. ACM Transactions on Transactions on Software Engineering and Methodology, 3(4):308{339, October 1994. [GD94] J. Goguen and R. Diaconescu. Towards an algebraic semantics for the object paradigm. In RECENT trends in data type speci cation: workshop on speci cation of abstract data types: COMPASS: selected papers, number 785 in Lecture Notes in Computer Science. Springer Verlag, 1994. [GDK96] M.-C. Gaudel, P. Dauchy, and C. Khoury. A formal speci cation of the steam boiler control problem by algebraic speci cations with implicit state. In H. Langmaack J.-R. Abrial, E. Boerger, editor, Formal Methods for Industrial Applications, number 1165 in Lecture Notes in Computer Science. Springer Verlag, 1996. [GM92] Joseph A. Goguen and Jose Meseguer. Order-sorted algebra I: Equational deduction for multiple inheritance, overloading, exceptions, and partial operations. TCS: Theoretical Computer Science, 105(2):217{273, 1992. (Also in technical report SRI-CSL89-10 (1989), SRI International, Computer Science Lab). [GMMP91] C. Ghezzi, D. Mandrioli, S. Morasca, and M. Pezze. A uni ed high-level petri net model for time-critical systems. IEEE TOSE, 17(2):160{172, February 1991. [Gra92] Paul Smith Graeme. An Object-Oriented Approach to Formal Speci cation. PhD thesis, Department of Computer Science, October 1992. [Gro96] The VDM Tool Group. The IFAD VDM++ Language. Odense, Denmark, December 1996. Available from http://hermes.ifad.dk/products/pp documentation.html. [Gue94] Nicolas Guel . Les Reseaux Algebriques Hierarchiques : un formalisme de speci cations structurees pour le developpement de systemes concurrents. PhD thesis, Universite Paris XI Orsay, December 1994. also in Hierarchical Algebraic Nets, Technical

report 095/99, Software Engineering Laboratory, Swiss Federal Institute of Technology, Lausanne, Switzerland, January 1995. [GWM+93] Joseph Goguen, Timothy Winkler, Jose Meseguer, Kokichi Futatsugi, and Jean-Pierre Jouannaud. Introducing OBJ. In Joseph Goguen, editor, Applications of Algebraic Speci cation using OBJ. Cambridge, 1993. also to appear as Technical Report from SRI International. [Jon90] C.B. Jones. Systematic Software Construction Using VDM. Prentice-Hall International series in computer science. Prentice Hall, 1990. [JR91] Kurt Jensen and Grzegorz Rozenberg, editors. High-level Petri Nets, Theory and Application. Springer-Verlag, 1991. [JSHS91] R. Jungclaus, G. Saake, T. Hartmann, and C. Sernadas. Object-oriented speci cation of information systems: the troll language. 91-4, Informatik Bericht, Technische Universitat Braunschweig, 1991. [KGD97] C. Khoury, M.-C. Gaudel, and P. Dauchy. As-is. Technical Report 1119, Laboratoire de Recherche en Informatique, 1997. [Kie89] Astrid Kiehn. Petri net systems and their closure properties. In G. Rozenberg, editor, Advance in Petri Nets, number 424 in Lecture Notes in Computer Science, pages 306{328. Springer-Verlag, 1989. [Lak95] C. A. Lakos. The object orientation of object petri nets. In Proceedings of the rst international workshop on \Object-Oriented Programming and Models of Concurrency" within the 16th International Conference on Application and Theory of Petri Nets, pages 1{14, Torino, Italy, June 20 1995. [Lak96a] C. A. Lakos. Loopn++ user manual. R96-1, University of Tasmania, Dept. Comp. Science, Networking Research Group, January 1996. [Lak96b] Charles Lakos. The consistent use of names and polymorphism in the de nition of object Petri nets. In Proceedings of the \Application and Theory of Petri Nets 1996", volume 1091 of Lecture Notes in Computer Science, pages 380{399, Osaka, Japan, June 1996. Springer. [Lam91] L. Lamport. Introducing tla+. Preliminary draft, DEC, Palo Alto, December 1991. [Lam94] L. Lamport. The temporal logic of actions. ACM Transactions on Programming Languages and Systems, 16(3):872{923, May 1994. [LH94a] Kevin Lano and Howard Houghton, editors. Object-oriented Speci cation Case Studies. Object-oriented series. Prentice Hall, 1994.

[LH94b] Kevin Lano and Howard Houghton. The Z++ manual, October 1994. Available from ftp://theory.doc.ic.ac.uk/theory/papers/Lano/z++.ps. [LW94] Barbara Liskov and Jeanette M. Wing. A behavioral notion of subtyping. ACM Transaction on Programming Languages and Systems, 16(6):1811{1841, November 1994. [Mes92] J. Meseguer. Conditional rewriting logic as a uni ed model of concurrency. Theoretical Computer Science, 96:73{155, 1992. [Mes93] J. Meseguer. A logical theory of concurrent objects and its realization in the maude language. In G. Agha, P. Wegner, and A. Yonezawa, editors, Research Directions in Concurrent Object-Oriented Programming, pages 314{390. The MIT Press, Cambridge, Mass., 1993. [Mey91] B. Meyer. Eiel: The Language. Prentice Hall, 1991. [MG94] G. Malcom and J. Goguen. Proving correctness of re nement and implementation. Prg-114, Oxford Technical Monograph, Oxford University, 1994. [MMG92] A. Morzenti, D. Mandrioli, and C. Ghezzi. A model-parametric real-time logic. ACM Transactions on Programming Languages and Systems, 14(4):521{573, October 1992. [MP94] A. Morzenti and P. San Pietro. Object-oriented logical speci cation of timecritical systems. ACM Transactions on Transactions on Software Engineering and Methodology, 3(1):56{98, January 1994. [MW92] J. Meseguer and T. Winkler. Parallel programming in maude. In J.-P. Banatre and D. Le Metayer, editors, Research Directions in High-Level Parallel Programming Languages, volume 574 of Lecture Notes in Computer Science, pages 253{293. Springer Verlag, 1992. [PS92] L Pomello and C Simone. An algebraic characterisation of elementary net system (observable) state space. Formal Aspects of Computing, 4(6A):612{637, 1992. [Rei91] Wolfgang Reisig. Petri nets and algebraic speci cations. In Theoretical Computer Science, volume 80, pages 1{34. Elsevier, 1991. [RRS+97] B. Randell, A. Romanovsky, R. J. Stroud, J. Xu, and A. F. Zorzo. Coordinated atomic actions: from concept to implementation. Technical Report TR 595, Computing Dept., University of Newcastle upon Tyne, 1997. [RS94] J. Ramos and A. Sernadas. A brief introduction to gnome. http://www.cs.math.ist.utl.pt/cs/lcg/gnome.html, 1994. [SB94] C. Sibertin-Blanc. Cooperative nets. In Robert Valette, editor, Application and Theory of Petri Nets 1994, volume 815 of Lecture Notes in Computer Science, pages 471{ 490, 15th International Conference, Zaragoza, Spain, June 1994. Springer-Verlag.

[Sny86] Alan Snyder. Encapsulation and inheritance in object-oriented programming languages. In Proceedings OOPSLA '86, volume 21, 11 of ACM SIGPLAN Notices, pages 38{45, November 1986. [SOR93] N. Shankar, S. Owre, and J.M. Rushby. A tutorial on speci cation and veri cation using pvs. Preliminary draft, Csl report, SRI International, Menlo Park, CA, USA, February 1993. [Spi92] J. M. Spivey. The Z Notation. Prentice-Hall International series in computer science. Prentice Hall, 1992. [Wie91] R. Wieringa. Equational speci cation of dynamic objects. In Object-Oriented Data Bases: Analysis, Design and Construction. North-Holland, 1991. [Zam97] A.V. Zamulin. Typed gurevitch machines revisited. Joint NCC-IIS Bull. in Comp. Sc., 5:1{30, 1997.