object-oriented environmental fault...
TRANSCRIPT
Object-Oriented Environmental Fault Tolerance
Cecılia M. Fischer Rubira Brian Randell
[email protected] [email protected]
Departamento de Ciencia da Computacao Department of Computing Science
Universidade Estadual de Campinas University of Newcastle upon Tyne
Campinas, Brasil Newcastle upon Tyne, England
RESUMO
Muitas entidades no mundo real que um sistema de software foi projetado para in-teragir, por exemplo, para propositos de controle ou gerencia, exibem diferentes tiposde comportamento durante seus tempos de vida, em particular dependendo se elas estaofuncionando corretamente ou nao. Isto e, essas entidades exibem nao so um comporta-mento normal mas tambem um ou mais tipos de comportamento anormal associados comas varias faltas que ocorrem no meio ambiente. Essas faltas sao chamadas de faltas de
ambiente. Numa linguagem orientada a objetos baseada em classes, como por exemploC++, todos os objetos de uma classe devem seguir o mesmo comportamento. Entretanto,isto requer que cada objeto pertenca permanentemente a uma classe, impondo restricoesna mutabilidade do seu comportamento. Este artigo propoe solutions para o problemade encontrar meios atraves dos quais essas entidades possam fazer mudancas de compor-tamento de um modo claro e explıcito, ao inves do uso de codigo que normalmente estaescondido na implementacao dos metodos. Nossa proposta define estaticamente as vari-antes do comportamento anormal de um objeto, e o acesso a elas em tempo de execucaoe feito atraves de um mecanismo de delegacao, dependendo do estado corrente do objeto.
ABSTRACT
Many entities in the real world that a software system has been designed to interact
with, e.g., for controlling or monitoring purposes, exhibit quite different kinds of behaviour
in their lifetime, in particular depending on whether or not they are functioning correctly.
That is, these entities exhibit not only a normal behaviour but also one or more kinds of
abnormal behaviour associated with the various faults which occur in the environment.
These faults are referred to as environmental faults. In a class-based object-oriented lan-
guage, such as C++, all objects of a given class must follow the same behaviour. However
this requires that each object permanently belong to a particular class, imposing con-
straints on the mutability of its behaviour. This paper proposes solutions to the problem
of finding means whereby objects representing such real-world entities can make such be-
haviour changes in a clear and explicit way, rather than through status-checking code
which is normally embedded in the implementation of various methods. Our proposed
solution defines statically the abnormal behaviour variants of an object, and runtime ac-
cess to them is implemented through a delegation mechanism depending on the object’s
current state.
1
1 Introduction
Most real-world computer systems are extremely complicated, as is evidenced bythe intricacy of their hardware and software implementations, and they have be-come even more complicated since the requirements of new applications have becomemore demanding: high size and complexity, high reliability and high performance.It is sometimes possible, even desirable, to ignore this complexity, but doing sodoes not make it go away because it will certainly appear somewhere else. Softwareapplications that deal with complicated problems must cope with this complex-ity somewhere. The complexity of most computing systems is principally foundin their software, since hardware systems are comparatively simple, with limitedand constrained interconnections, and simple interactions between components[14].Hence many ongoing investigations are concerned with mastering software complex-ity. Since the early 80s, the object-oriented paradigm has been considered as one ofthe most significant developments in software programming, only comparable to theideas of structured programming in the early 70s. The object-oriented paradigm iswell suited for structuring a wide variety of complex systems, notably providing asound basis to develop applications that are easy to maintain and reuse. Object-oriented design techniques focus on resources and abstractions that relate to theapplication world and object-oriented languages can directly capture the structureof these abstractions in an implementation.
In many real-world situations entities of the problem domain may change theirbehaviour due to a variety of phenomena, e.g. equipment failure or malfunction,personnel errors, sensor failures. Assuming that the problem domain could be fullyunderstood at the outset, one could identify many different ways in which entitiescould behave, and also categorise different types of changes that occur in the problemdomain. These changes can be classified in many different ways, such as, frequentvs. infrequent, desired vs. undesired, or predictable vs. unpredictable. In thisresearch, we are particularly interested in behaviour changes caused by (relatively)infrequent, undesired and predictable changes of the environment. We refer to suchchanges of the environment as environmental faults. Thus, in a problem domain,various sources of complexity can be found, but the primary focus of this workconcentrates on environmental faults, and the frequent need to cope with them asan unvoidable source of complexity, but one which nevertheless has to be minimised.This paper demonstrates how object-oriented techniques can be used to implementsoftware components that support environmental fault tolerance.
In the object-oriented model[30], entities in the real world are modeled as ob-jects. An object has a time invariant identity that is unique with respect to otherobjects. Objects sharing the same structural and operational characteristics areclassified into classes. A class is a way of describing the structure and behaviourof a family of objects. Behaviour is how an object acts and reacts, in terms of itsstate changes and message passing. Inheritance is a mechanism for deriving newclasses from existing classes by a process of refinement. A derived class inheritsthe data representation and operations of its parent class but may selectively addnew operations, extend the data representation or override the implementation ofexisting operations. Thus programming is achieved by class definitions and hier-archy creation, in which properties are transmitted from superclasses to subclasses
by the concept of inheritance. Object-oriented software construction integrates es-tablished software engineering principles like data abstraction[15], encapsulation[23]and strong typing[16].
For purposes of this research, we restrict the inheritance relationship to the so-called behavioural inheritance model[15] that is increasingly being accepted as themodel that supports a subtyping/conformance relationship. In this model, a de-rived class is designed by including the specification of the parent class as a subsetof the specification of the derived class. However, the requirements of this modelgo beyond the textual matching of method names. It is important that overridingof operations by a derived class be performed in a disciplined manner so that thederived class still realises the same basic abstraction as the parent class. Meyerhas proposed a contract model for inheritance, known as design by contract[19], inwhich the behaviour of a class is constrained by pre- and post-conditions on itsoperations and an invariant over its internal state. Derived classes are obliged toconform to the specification of their parent classes in the sense that the invariantfor the derived class must preserve the invariant for the parent class, while eachoperation of the derived class that replaces an operation of the parent class musthave a weaker pre-condition and a stronger post-condition. These two requirementsproduce an inheritance hierarchy in which the subclasses are subtype compatiblewith their parents and polymorphic substitution of instances of derived classes forinstances of parent classes is possible without affecting the correctness of the overallsystem. In what follows, we refer to this model of inheritance as restricted inher-
itance which encompasses both notions of behavioural inheritance and “design bycontract” methodology.
Even when all possible changes of the entities related to the problem domainhave been envisaged at the outset, it can be desirable to represent such changesexplicitly in the solution domain, rather than simply encode them into the object’smethods. Thus, if we have chosen to identify the behaviour of an entity of a problemdomain as involving several distinct phases, transitions between which are causedby changes of behaviour, in particular faults, so we would wish to represent suchphases and phase transitions explicitly in the solution domain.
An object of the solution domain is referred to as faulty if its behaviour is al-tered due to environmental faults occurred in the problem domain. When an ob-ject’s behaviour changes from a normal to an abnormal one, the object provides theadequate fault treatment by changing the implementation of its methods. In thispaper, we suggest that the phases associated with this abnormal behaviour shouldnot be buried at the level of implementation but be explicitly represented as in-terface objects, and be developed behaviour variants for anticipated environmentalfaults.
The structure of the rest of this paper is as follows. Section 2 introduces an exam-ple which is used to illustrate our ideas, and describes the concept of transmutableobjects and their implementations using concepts such as delegation, abstract baseclasses and state hierarchies. Section 3 gives a more formal presentation of the del-egation concept and Section 4 presents a technique for incrementally building thestate hierarchy for a derived class from the sate hierarchy of its parent class basedon the concepts of state machines and the restricted inheritance model. Follow-ing this, Section 5 discusses some related work, and finally, some conclusions are
presented. Although the example in this paper is written in C++[27], the ideas pre-sented can also be applied with other object-oriented programming language, suchas Eiffel[18]. Furthermore, the example is simple but was chosen merely to facilitatethe illustration of the ideas.
2 Motivating Example
This section starts by motivating the need for a runtime association between anobject and the properties usually associated with its class. The examination of thedynamical aspects of objects in the problem domain leads us to study the behaviourof an object over time. When we consider the dynamic behaviour of entities in thereal world, we observe that these entities generally have a lifetime[21]. Since allinstances of a class must follow the same rules of behaviour, when we abstract agroup of similar entities to build a class, we also abstract their common behaviourpattern into a life cycle[21] typical of the object. In this sense, the life cycle providesa description of the behaviour pattern shared by all the instances of a class. Forexample, a butterfly begins life as a caterpillar, then changes into a chrysalis and,finally, transforms into an adult butterfly. The term logical state is applied to eachobservable phase of the butterfly, that is, caterpillar, chrysalis, and adult butterfly.However, the properties of a butterfly are different in these three distinct logicalstates. For example, an operation like move needs to be implemented in two differentways: one for creeping like a caterpillar and another for flying and walking like anadult butterfly. In general logical states are information obtained at the designphase, and almost all current object-oriented language enforce that this informationbe buried in the implementation of the methods of an object. It is desirable tofind means by which these logical states be represented very explicitly rather thanimplicitly through flag-checking code so as to obtain a better program structure.
Account
/ \
SavingAccount CurrentAccount
Figure 1: Account Types
Now we consider how these objects that have dynamic behaviour could be im-plemented in C++[27]. To illustrate our ideas, we take as an example a simplechecking account system, described in the following paragraph:
A bank has two types of accounts: saving and current. Suppose thatthe bank is very strict regarding its current accounts. A normal currentaccount must always maintain a positive balance, but, in return, themonthly charge is diminished. If it fails to do so, i.e., its balance dropsto a negative number, the normal account is transfered into an abnormal
account, and the monthly charge is augmented. If an abnormal accounthas a positive balance then it is automatically reverted to being a normalaccount.
2.1 First Implementation
The relationship between the account types of the bank is shown in the Figure 1. Apossible solution to the problem is to embed the logical states of an CurrentAccountobject within the attributes of the CurrentAccount class. Changes in the value ofthese attributes are detected by “if” statements buried within the methods of theobject’s class.
The implementation of the CurrentAccount class could be as follows:
class CurrentAccount: public Account{
private:
unsigned accountNumber;
int currentBalance;
int abnormalAccountFlag; // 1=abnormal 0=normal
public:
CurrentAccount(accountNum, initialBalance);
~CurrentAccount();
int balance();
int debit(int amount); // process a check
void credit(int amount); // process a deposit
void dailyBalanceUpdate(); // update the account’s balance at midnight
void monthlyCharge(); // apply monthly charge
}
int CurrentAccount::balance() { return currentBalance;}
int CurrentAccount::debit(int amount) {
if (currentBalance < 0)
return 0;
currentBalance -= amount;
return 1;}
void CurrentAccount::credit(int amount) {
currentBalance += amount;}
void CurrentAccount::dailyBalanceUpdate() {
if (abnormalAccountFlag == 0) // normal account
{ if (currentBalance < 0)
{ abnormalAccountFlag = 1;}
}
else { // abnormal account
if (currentBalance >= 0)
{ abnormalAccountFlag = 0;}
}
}
void CurrentAccount::monthlyCharge() {
if (abnormalAccountFlag == 0)
{ currentBalance -= MONTHLYCHARGE/2;}
else { currentBalance -= MONTHLYCHARGE;}
Account
/ \
SavingAccount CurrentAccount
/ \
NormalAccount AbnormalAccount
Figure 2: Expanded Hierarchy for Account Types
}
The abnormalAccountFlag attribute indicates that the account is currently ab-normal if its value is 1; otherwise, if its value is 0, it means that the account isnormal.
An examination of this solution reveals that it has the same problems when com-pared to a typical non-object-oriented solution: the rules concerning state transitionsof banking accounts are represented implicitly within the methods of CurrentAccount.The methods dailyBalanceUpdate() and monthlyCharge() that should only containcode from processing the monthly charge or changing the date at midnight shouldnow also contain code to check and update the value of abnormalAccountFlag.
2.2 Second Implementation
The “if” statements buried in the methods dailyBalanceUpdate() and monthlyCharge()used in the first implementation could be eliminated. Since C++ is a language withruntime type resolution, the creation of “class types” like NormalAccount and Ab-normalAccount would exempt the programmer to determine the type addressed bythe abnormalAccountFlag. Thus, another solution is to expand the class hierarchy toinclude the description of the different types of current accounts (Figure 2).
We might expand the CurrentAccount class as follows:
class CurrentAccount: public Account{
private:
unsigned accountNumber;
int currentBalance;
public:
CurrentAccount(accountNum, initialBalance);
~CurrentAccount();
int balance(); // same implementation as before
int debit(int amount); // same implementation as before
void credit(int amount); // same implementation as before
virtual void dailyBalanceUpdate();
virtual void monthlyCharge();
}
class NormalAccount: public CurrentAccount{
public:
void dailyBalanceUpdate(){
if (currentBalance < 0)
// account transition to AbnormalAccount}
void monthlyCharge() {
currentBalance -= MONTHLYCHARGE/2;}
}
class AbnormalAccount: public CurrentAccount{
public:
void dailyBalanceUpdate(){
if (currentBalance >= 0)
// account transition to NormalAccount}
void monthlyCharge() {
currentBalance -= MONTHLYCHARGE;}
}
In this solution, the methods of CurrentAccount defined in the first implementa-tion still exist for accessing information about an account. However, the methodsdailyBalanceUpdate() and monthlyCharge() are now virtual and are overloaded in theNormalAccount and AbnormalAccount subclasses. For example, now the implemen-tations of NormalAccount::monthlyCharge() and AbnormalAccount::monthlyCharge()take no extra action because the check for the value of a abnormal account flag isno longer necessary.
This solution now captures the relationship between the different types of currentaccounts. However, it has at least two limitations. First, class-based languages likeC++, do not allow a program to change the class of its objects. When a currentaccount changes state, for example, from NormalAccount to AbnormalAccount, a newAbnormalAccount object must be created and the old NormalAccount object deleted.However, this operation of deleting and creating objects could cause a large overheadfor applications of reasonable size. Furthermore, it is not possible to the programmerto guarantee that the identity of the new object is identical to the old deleted object.This is a crucial problem if other objects of the system contain references to theold object. A number of solutions have been suggested to solve such a limitation[7].One solution is create a table containing pointers to all changeable objects. Anothersolution could be to keep a dependency list of all objects that have references to achangeable object. Thus, when the object changes its identity, it is possible to knowall the objects that would require changing. Both solutions, however, add storageand performance overhead. What is needed is a mechanism that does not requireobjects to be deleted and recreated on every state change.
A second limitation is that NormalAccount and AbnormalAccount classes are notreally subtypes/specialisations of an abstract current account, but they are separateconceptual states of the same abstraction. In fact, the logical states of a currentaccount can be classified as normal and abnormal, and not the current accountitself. All this discussion leads us to a third implementation that tries to solve theproblems above mentioned.
Account CurrentAccountState
/ \ / \
SavingAccount CurrentAccount NormalState AbnormalState
Figure 3: Parallel Class Hierarchies
2.3 Transmutable Objects
As discussed previously, it seems that two different issues have been confused inthe second implementation: the class of an CurrentAccount object, and its currentlogical state. These two issues are represented by the same class hierarchy (Fig-ure 2). However, one could choose to build two separate hierarchies (Figure 3), eachrepresenting a different issue:
• Account Hierarchy that represents the subtyping relationship between thedifferent types of accounts, and
• CurrentAccountState Hierarchy that represents the subtyping relation-ship between the different logical states that an CurrentAccount object couldprogress through during its lifetime.
A software design solution always has some underlying form or organisation, andto minimise complexity we need techniques for discovering this inherent form so thatthe design can be decomposed into a series of highly independent components[22].So our proposed solution is to define a hierarchy of different subclasses related to anobject, each subclass corresponding to a different implementation of its behaviour,and, then, to arrange that each object designates the responsibility for providingits operations to appropriate instances of these subclasses representing the differentimplementations of the object’s behaviour that the external entity can possess. Bythis means it avoids having information about logical states hidden in the operationsof the object.
Adopting such an approach, the C++ definition for the CurrentAccount classwould like something like this:
class CurrentAccount: public Account{
friend class CurrentAccountState;
private:
unsigned accountNumber;
int currentBalance;
CurrentAccountState *currentState;
CurrentAccountState *normalState;
CurrentAccountState *abnormalState;
public:
CurrentAccount(accountNum, initialBalance);
~CurrentAccount();
int balance(); // same implementation
int debit(int amount); // same implementation
void credit(int amount); // same implementation
void dailyBalanceUpdate(){ currentState->dailyBalanceUpdate(this);}
void monthlyCharge(){ currentState->monthlyCharge(this);}
}
A CurrentAccount object intercepts and forward messages to currentState object,an “inner” state object which gets dynamically rebound to the different state ob-jects normalState and abnormalState as the CurrentAccount object changes its logicalstate. In the example, the operations monthlyCharge() and dailyBalanceUpdate() areforward to currentState object for processing. The currentState object is updatedthrough the state-changing method dailyBalanceUpdate.
The CurrentAccountState hierarchy is implemented as follows:
class CurrentAccountState{
public:
CurrentAccountState();
~CurrentAccountState();
virtual void dailyBalanceUpdate(CurrentAccount* ca)=0;//pure virtual
virtual void monthlyCharge(CurrentAccount* ca)=0; //pure virtual
}
class NormalState: public CurrentAccountState{
public:
void dailyBalanceUpdate(CurrentAccount* ca){
if (ca->currentBalance >= 0)
ca->currentState = normalState;}
void monthlyCharge(CurrentAccount* ca){
ca->currentBalance -= MONTHLYCHARGE/2;}
}
class AbnormalState: public CurrentAccountState{
public:
void dailyBalanceUpdate(CurrentAccount* ca){
if (ca->currentBalance < 0)
ca->currentState = abnormalState;}
void monthlyCharge(CurrentAccount* ca){
ca->currentBalance -= MONTHLYCHARGE;}
}
In this implementation, the logical state of a CurrentAccount object can bechanged without the need to delete and recreate the object. In addition, the pro-grammer can add or modify states, and methods that control the transitions betweenthem, without needing to change the methods related to the CurrentAccount class.The classes that compose the CurrentAccountState hierarchy are referred to as state
classes[8], and a CurrentAccount object, we term a transmutable object. So a statehierarchy represents sets of properties, each set describing a different logical statewhich implements basically the same interface specification. When messages aresent to a transmutable object, the interface implementation to be executed will
be selected at runtime. The relationship between a transmutable object and itsvariant objects can be thought of forming a composite object[30]. Although thereare multiple objects, the appearance to the user is that there is a single object -the transmutable object - which orchestrates the entire operation of the compos-ite object. When a transmutable object is instantiated, the state objects are alsointernally created.
The interface specification of the state hierarchy is defined by the abstract baseclass CurrentAccountState which declares the pure virtual operations dailyBalance-Update and monthlyCharge. AbnormalState and NormalState are concrete classesderived from CurrentAccountState which conform to the interface specification ofthe abstract base class. A pure virtual operation has no implementation in thebase class and it must be overridden in each derived class. In other words, a groupof related behaviour variants, that is, NormalState and AbnormalState, is definedas heirs of an abstract base class which defines a common interface specification,and as long as the transmutable object only access the behaviour variants via theabstract base class they are not affected when the current variant is replaced by anew one still conforming to the specification given by the abstract base class. Thus,specific reconfiguration changes can be easily incorporated to a software system fortolerating environmental faults.
Usually the state changes of an object over time, that is, its dynamic behaviour,is represented in a diagrammatic form known as a state diagram[20]. Such a diagramcan be a basis for the construction of well-structured state hierarchies. Up to now,we have informally introduced the concept of delegation, that is, when an objectforwards a requested message to some other designated object for processing. Inthe next section we define more precisely the concept of delegation, giving specialattention to how delegation is implemented in a class-based object-oriented languagelike C++. Following that, we explore the construction of state hierarchies using statemachines and the restricted inheritance model.
3 Delegation
There are many variations amongst existing object-oriented systems, especially con-cerning behaviour sharing and evolution. Behaviour sharing can be obtained intwo distinct ways: class-based sharing and delegation-based sharing. Classificationallows objects to be categorised, that is, all objects in a class have a common struc-ture and share common behaviour. As a consequence, changes made to methodsand structure in a class can automatically be passed on to all instances of that class.This implicit mechanism allows systems to be updated on a “per group” basis. Inthis sense, a class provides a template for all similar objects. Examples of class-basedlanguages are C++[27], Eiffel[18] and Simula[6].
On the other hand, the so-called delegation-based programming languages, suchas Actor[1] and Self[29], adopt an alternative approach based on delegation[25], inwhich objects are viewed as prototypes (or exemplars) that delegate their behaviourto related objects, called delegatees. Delegation-based systems can share both stateand behaviour of objects. The delegates-to relationship can be established dynami-cally, while the inheritance relationship of class-based languages is established and
fixed when a class is created. This is usually part of a system design that eliminatesclasses, focusing instead on concrete objects.
Three dimensions for behaviour sharing can be characterised in order to contrastclass-based systems and delegation-based systems [9]:
(i) static vs. dynamic - is sharing determined when an object is created or can itbe determined dynamically?
(ii) implicit vs. explicit - are there explicit operations to indicate the sharing?
(iii) per group vs. per object - is sharing defined for whole groups of objects(classes) or could sharing be supported for individual objects?
Class-based languages use static, implicit and per-group strategies. By contrast,delegation-based programming languages use dynamic, explicit and per-object shar-ing strategies.
Evolution is concerned with how and when the links between nodes in a classifi-cation hierarchy are allowed to change. In class-based systems, a method is invokedon an object as a result of sending that object a message. Usually the messageincludes: the name of the receiver and a selector. The selector carries the methodname and appropriate arguments. The binding of the method code to the method
call on the object is thus made at runtime. However, the pattern of sharing is static
in that the runtime search for the method code will always traverse the superclassesin the same order.
In contrast, delegation-based systems have no classes, and methods can be storedin each object. An object can delegate messages to other objects, thus if the methodlookup does not find the method name in the receiver, the search continues in theobjects that the receiver delegates to, in the objects they delegate to, and so on.In this sense, an object “inherits” the methods of the objects to which it delegatesmessages.
Delegation-based sharing can allow greater opportunity for implementing dy-namic changes than class-based sharing. However, each scheme has advantages anddrawbacks depending on the application domain. The security of compile-time classcreation versus the flexibility of creating new objects “on the fly” is a central issuein the design of object-oriented systems. The security of compile-time class creationis a highly desirable characteristic in a language that is used for large static systemsin which type security is needed. In this kind of system, to change the behaviouror specification of an object, the class is edited and the code passed again throughthe interpreter or compiler to recreate a new object that has the new specification.However, in class-based systems the requirement that each object belongs perma-nently to a particular class imposes constraints on the mutability of the behaviourof an object. Sometimes some flexibility is necessary because many applications,such as process control systems or telecommunication switching systems, cannot bestopped to modify and extend their software[24]. It must be possible to replace somesoftware components on the fly by new versions while the program is still running.The ability to modify and extend a system while it is running is known as dynamic
configuration[13].
3.1 Delegation in Class-Based Languages
Although inheritance and delegation are usually defined as alternatives in the designof an object-oriented system, delegation can be used in a class-based language as away to implement behaviour sharing when an object needs, for example because ofan environmental fault, to be able to change its responses to messages at runtime.The main advantage that delegation has over inheritance is that delegation makes iteasier for objects to change their behaviour. Since it is dangerous to change the classof an object, most class-based languages do not allow it, but it is easy to change thedelegatee of an object. Moreover, a language with static type checking can ensurethat a delegatee will understand all the messages delegated to it. Thus, delegationis quite compatible with static type checking presuming that the delegatees of anobject can be known at compile time. As a consequence, parent changing is limitedto objects guaranteed to possess all the properties required by the descendants -there is no danger that behaviourally incompatible objects become parents as well.So delegation can be viewed as a design technique that can be used with any object-oriented language including those that are statically typed.
Delegation differs from forwarding a message in that the delegator continues toplay the role of the receiver even after it delegates the message. In C++, delega-tion can be implemented by including the original receiver as an extra argument toeach delegated message. An original message sets this argument to the receiver ofthe message, but delegated message sends do not change this argument. Delegation-based languages implement this extra level of indirection automatically and invisibly.Hence one can easily implement behaviour changes of real-world entities by dele-gating operations to different objects representing the different kinds of behaviourthat the entity can possess. But the fact that these different objects are intended torepresent the same external entity at different logical states throughout its life timeis not clearly captured by this implementation. It is also not possible to guaranteethat all different objects representing the logical states of an entity conform to thesame specification. Usually delegation-based languages emphasise flexibility, relyingon runtime type checking rather than static type checking so there is no guaranteethat an object implements all the operations delegated to it.
We therefore explore a means of implementing delegation in a class-based lan-guage in order to improve the structuring of the program. We argue that the imple-mentation of transmutable objects can be achieved in a more controlled and reliableway in a class-based language. We do not give up the fundamental principle that alanguage must be secure. However, sometimes it is necessary to have some flexibilitywhen one embarks upon a real application.
The implementation of delegation in a class-based language requires more workon the part of the programmer that it does in a delegation-based language. Extrawork is required in defining the delegator and the delegatees. In Self, a method of adelegatee is automatically available to the delegator. In C++, this is not true. Thus,because delegation is being implemented “by hand”, a method definition needs tobe written in the delegator for each delegated operation. The function definitionsare trivial, but this is an overhead for the programmer not present in a delegation-based language. However, a tool can be built to automatically generate code forthe delegated operations. The operation in a delegatee class must have an extra
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
....................................................................
.................................................................................................................
..
.......................................................................................................................................................
.................................................................................................. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
..
..
.
....................................................................
..........................................................................................................
...........................................................................................................................................................
..................................................................................................
.............................................................................................................................................................
......................................
......................................
.........................................................................................................................................................................................
currentAccount is abnormal[accountBalance < 0]/currentState=abnormalState
NormalState AbnormalState
currentAccount is normal[accountBalance ≥ 0]/currentState=normalState
Figure 4: State Diagram for Current Account
argument to refer to the delegator. Instead of performing operations on this, thedelegatee must perform operations on the delegator.
4 State Hierarchies
The notion of state classes permit the specification of properties common to agroup of states using a generalisation hierarchy, just as generalisation of states inStatecharts[11] allows the specification of common transitions. Statecharts also in-troduces the notion of aggregation of states. These two constructs provide additionalpower for modelling object-oriented systems. In this section, we provide some back-ground about the use of state machines and their diagrams for representing classes,and show a technique for incrementally building the state diagram for a class fromthe state diagram of its parent class.
An important notion is that state diagrams can be represented as state hier-archies. As a consequence, the same technique for incrementally building statediagrams can also be used for building state hierarchies, as we show in the nextsections. Moreover, Statecharts is a graphical representation which includes mathe-matical semantics. This is a key feature for helping not only the correct constructionof state hierarchies but also to check whether the transitions between logical statesare correct.
4.1 State Machines
A number of object-oriented design methodologies utilise a finite state machine tomodel the dynamic behaviour of objects, including the technique proposed by Rum-baugh et al.[20] and that of Shlaer and Mellor[21]. Rumbaugh’s approach includes adynamic model for a class that captures the changes in state undergone by instancesin response to messages. Several styles of state diagrams have been reported onthe literature[5, 10, 11]. Here we follow the notation introduced by Harel[11] fordrawing (structured) state diagrams. The state hierarchy for the CurrentAccountclass presented in Section 2.3 (Figure 3) can be represented as a state diagram. Fig-ure 4 illustrates the state diagram for the a current account. When accountBalancevalue is less than zero, the current account is ranked as abnormal. Similarly, whenaccountBalance has a positive value, the current account is considered to be normal.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
..
........................................................................
...........................................................................................................
...........................................................................................................................................................
.................................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
.
..
.
..
.
..
....................................................................................................................................................................................
.............
...............
..................
........................
..............................................................................................................................................................................................................................................................................................................................................
............................................................................................................................................................................................................................................................................................................................................................................................................................
................................
............................................................................................................................................................................................................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
..
..
..
....................................................................
..........................................................................................................
...............................................................................................................................................................
...............................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
..
..
......................................................................
..........................................................................................................
...........................................................................................................................................................
..................................................................................................
.....................................................................................................
......................................
......................................
..........................................................................
.................................................................................
................................................................................................
.................
......................................
.........................................................................................................................................................................................
NormalState
AbnormalState
Overdraft OverdraftNotLimit
ExceededExceededLimit
Figure 5: Generalisation of States for Abnormal State
CurrentAccountState
/ \
NormalState AbnormalState
/ \
OverdraftLimitExceeded OverdraftLimitNotExceeded
Figure 6: Expanded State Hierarchy for Current Account
Statecharts, originated by Harel[11], introduced the concept of hierarchy andaggregation into state representation. The ways of structuring state machines aresimilar to the ways of structuring objects: generalisation/specialization and aggrega-tion/decomposition. Generalisation allows states and events to be arranged into gen-eralisation hierarchies with inheritance of common structure and behaviour, similarto inheritance of attributes and operations in classes. More specifically, a nested state
diagram is a form of generalisation on states, also known as the “or-relationship”.An object in a state in the high-level diagram must be in exactly one state in thenested diagram. The states in the nested diagram are all refinements of the state inthe high-level diagram. That is, one state may be divided into several independentsubdivisions, only one of which describes the state of the system at runtime. Forexample, in Figure 5, AbnormalState is refined in two states: OverdraftLimitExceededand OverdraftLimitNotExceeded. This combination of states is an exclusive-OR: to bein state AbnormalState, one must be either OverdraftLimitExceeded or OverdraftLim-itNotExceeded, but not both. The state hierarchy correspondent to the descriptionof this “or-relationship” is shown in Figure 6.
Aggregation allows a state to be broken into orthogonal components, with limitedinteraction among them, similar to an object aggregation hierarchy. Aggregation isequivalent to concurrency of states, also known as the “and-relationship”. A statediagram for an aggregate is a collection of state diagrams, one for each component.For example, in Figure 7, CurrentAccount consists of AND components, CurrentAc-countState and CurrentAccountDebitRate. Being in CurrentAccount implies being anaggregation of CurrentAccountState (either NormalState or AbnormalState) and Cur-rentAccountDebitRate (either Student Overdraft or Unauthorised Overdraft). In thisexample, there two kinds of debit rates which can be applied to a current account:student overdraft which corresponds to a rate of 0.52% and unauthorised overdraft
which corresponds to a rate of 2.00%. CurrentAccountDebitRate is a state orthogonal
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
.
..
...........................................................................
......................................................................................................
................................................................................................................................................................
............................................................................................... .
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
.
..
...........................................................................
......................................................................................................
................................................................................................................................................................
...............................................................................................
..............................................................................................................................................................
......................................
......................................
.........................................................................................................................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
.
..
..
.........................................................................
......................................................................................................
................................................................................................................................................................
............................................................................................... .
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
.
..
..
.........................................................................
......................................................................................................
................................................................................................................................................................
...............................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
.
.
..
.
.
..
.
.
..
..
.
..
..
...................................................................................................................................................................................................................................................................
..............
...............
...................
.............................
...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
...............................
..........................................................................................................................................................................................................................................................................................................................................................................................
.......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .
.............................................................................................................................................................
......................................
......................................
.........................................................................................................................................................................................
CurrentAccount
NormalState
CurrentAccountState
Abnormal
State
CurrentAccountDebitRate
UnauthorisedOverdraft
StudentOverdraft
Figure 7: Aggregation of States
CurrentAccountState | CurrentAccountDebitRate
/ \ | / \
NormalState AbnormalState | StudentOverdraft UnauthorisedOverdraft
Figure 8: Parallel State Hierarchies for Current Account
to CurrentAccountState so it is represented as an “and-relationship”. The dashedline indicates two aggregate sets of states. The state hierarchy correspondent to thedescription of this “and-relationship” is shown in Figure 8.
4.2 Inheriting State Machines
The dynamic model of a class is inherited by its subclasses. The subclasses inheritboth the states of the ancestor and the transitions, and they can have their own statediagrams. The assumption of the use of the restricted inheritance model allows usto deduce some implications about the state machine for a new derived class formedfrom a parent class[20][17]:
(i) A derived class cannot delete a state of its parent class. Given the assumptionof the use of behavioural inheritance, the parent diagram must be a projectionof the child diagram. It is possible to modify a state since the method invariantstill holds for every method in the class stated in the class invariant.
(ii) Any new state introduced in a derived class is wholly contained in an existing
state of its parent class. The state diagram of a subclass may contain sub-states of an original state in the parent class (the “or-relationship”). Anotherpossibility is the state diagram of a derived class be an aggregate/concurrentaddition to the state diagram inherited from the parent class, defined on adifferent set of attributes, usually the ones added in the subclass (the “and-relationship”). A third scenario where the state diagram of the subclass wouldinvolve some of the same attributes as the state diagram of the superclasses
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
.
.......................................................................
...........................................................................................................
...........................................................................................................................................................
................................................................................................. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
.
.......................................................................
..........................................................................................................
...........................................................................................................................................................
..................................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
..
...........................................................................
..........................................................................................................
...........................................................................................................................................................
................................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
.
.
.
..
.
.
..
..
.....................................................................................................................................................................
...........
............
................
....................
.................................................................................................................................................................................................................................................................................................................
........................................................................................................................................................................................................................................................................................................................................................................................................
............................
............................................................................................................................................................................................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
..
..
..................................................................
.............................................................................................................
............................................................................................................................................................
..................................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
.
.......................................................................
...........................................................................................................
...........................................................................................................................................................
.................................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..............................................................................................................................................................
......................................
......................................
.........................................................................................................................................................................................
..................................................................................
................................................................................................
.................
......................................
.........................................................................................................................................................................................
.
.
.
.
..
.
.
.
..
.
.
.
..
.
.
....................
.
.......................................................................
........................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
.
..
.
.
..
.
.
.
..
.
.
..
CurrentAccount
CurrentAccount
(a)
NormalStateAbnormal
State
AbnormalState
VisaCardCancelled
VisaCardNotCancelled
NormalStatePrivileged
(b)
Figure 9: Example of Generalization of States
generating a situation of conflict, is not possible under the assumption of theuse of behavioural inheritance.
In order to exemplify the above statements, consider again the CurrentAccountclass presented in Section 2.3 (Figure 3). The first example shows CurrentAccountclass that has two states: NormalState and AbnormalState(Figure 9(a)). The sub-class PrivilegedCurrentAccount is a special current account which offers a visa cardfeature. If the privileged current account is normal, the visa card feature is alwaysavailable. However, if the privileged current account is abnormal, the visa card canbe automatically cancelled depending on whether or not the account’s owner agreesto pay a fee of £5 per month. Thus the states VisaCardCancelled and VisaCardNot-
Cancelled are not independent from the states of the CurrentAccount class. Thesenew states are only meaningful if the current account is abnormal. Figure 9(b) showsthis relationship where the states VisaCardCancelled and VisaCardNotCancelled arerepresented as substates of the Abnormal state (“or-relationship”).
The second example is also based on the CurrentAccount class (Figure 10(a)).Suppose that SimpleCurrentAccount class, which is derived from CurrentAccountclass, represents a current account in which service charges are applied. There aretwo kinds of services: student service which is free of transaction charges, and gradu-
ate service which is not. So one could create two states, for instance, StudentService
and GraduateService, for representing this abstraction. The states StudentService
and GraduateService are independent from the states of the current account (“and-relationship”). This results in the state diagram illustrated in Figure 10(b).
To summarise, this construction technique is mainly based on the concepts ofhierarchy and aggregation in state diagrams. The first concept allows a state from
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
.
..
.
....................................................................
...........................................................................................................
...........................................................................................................................................................
................................................................................................. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..........................................................................
..........................................................................................................
...........................................................................................................................................................
..................................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
..
..
......................................................................
..........................................................................................................
...............................................................................................................................................................
...............................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
..
..
......................................................................
..........................................................................................................
...............................................................................................................................................................
............................................................................................... .
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
..
..
.........................................................................
..........................................................................................................
...........................................................................................................................................................
................................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
..
..
.........................................................................
..........................................................................................................
...........................................................................................................................................................
................................................................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......... .......
..............................................................................................................................................................
......................................
......................................
.........................................................................................................................................................................................
..................................................................................
................................................................................................
.................
......................................
.........................................................................................................................................................................................
..................................................................................
................................................................................................
.................
......................................
.........................................................................................................................................................................................
CurrentAccount
CurrentAccountSimple
(a)
NormalStateAbnormal
State
NormalStateAbnormal
State
StudentService
(b)
ServiceGraduate
Figure 10: Example of Aggregation of States
a parent class to be decomposed into two or more substates in the derived class.The second concept allows one to add a new set of states that are parallel to thosethat existed in the parent class. These two concepts together with the restrictedinheritance mechanism provide sufficient power to incrementally modify the statemachines from ancestor classes to form the machine that describes the derived class.
The series of implications derived from these assumptions (above described in (i)and (ii)) form a set of rules to be followed when designing such state machines. Sothe technique supports the reuse of state machine information along with the hierar-chical structure constructed by the inheritance relationships among classes. Statesmachines can be represented as state hierarchies when desirable. So the techniquesfor incrementally building state machines can also be applied to incrementally con-structing state hierarchies for derived classes based on the state hierarchy of theirparent class.
Moreover, Harel’s Statecharts are part of a larger development methodology thathas been implemented as a commercial product called STATEMATE[12], which is atool for the specification and analysis of complex reactive systems. One importantfeature of STATEMATE is the emphasis regarded the dynamic verification of thebehaviour specification: the tool provides facilities to program the model execution,in interactive or batch mode, and also to instrument the models to collect statisticsduring execution.
Statecharts is a graphical language which combines the visual appeal of graph-ics with rigorous mathematical semantics. The semantics of Statecharts defines thesequence of system configurations taken into response to an external stimulus: start-ing from a stable configuration (i.e., no possible evolution unless an external eventis generated), the system goes through a succession of unstable configurations untila stable configuration is reached. This chain of reaction is achieved by a broad-
cast mechanism: any internal modification can be sensed from all active orthogonalcomponents, so that further transitions may be triggered.
So the use of Statecharts for representing the behaviour of an object in terms oflogical states, helps us not only with the design of state hierarchies but also withthe formal verification of the transitions between the logical states. Moreover, thistool can also assist in the generation of automatic code for the implementation oftransmutable objects.
5 Related Work
There are a number of different approaches to the provision of the sort of trans-mutable objects that are of relevance to our goal of providing a structured approachto environmental fault tolerance.
5.1 Modes
Mode[28] is an explicit language construct which extends the concept of ordinaryclass inheritance. In this approach, classes can have multiple sets of properties,each of which describes a separate conceptual state called mode. Each mode imple-ments basically the same interface specification, and when an instance of a class isrequested to perform some operation at runtime, the selection of the operation willbe based on the set of operations in the mode in which the object is currently. Inthe case of defining a derived class from a parent class, because there are separateimplementations of the same operations, the redefinition of methods in the subclassmust be performed individually for each mode. Special transition functions can bedefined to control the mode changing, so state change information is kept separatefrom operation implementations (each class can have only one transition function).
This approach has at least two limitations. Firstly, it does not allow the modesof a class to be organised as a state hierarchy. Secondly, when a new mode is addedin a subclass is not sufficient to define only those operations for the new mode thathave been incrementally defined in the subclass; rather, the new mode should beable to respond to all inherited operations as well (this requires a lot of work).Furthermore, the author states that it is not conceptually very clear how transitionfunctions should be combined with inheritance in the case of adding new modes.This approach addresses many of the same issues as our approach although from alinguistic viewpoint. It should be mentioned that our solution tried not to createany new linguistic construction as a result.
5.2 Roles in Fibonacci
Role is a concept from the Fibonacci database programming language[2]. Thislanguage has a notion of state and a concept of object identity; it also allows existingobjects to be extended. For example, suppose that John is an object representinga person, when John enrols as a student the object might be extended to support anew behaviour, such as, a method Number that returns his student number. Let uscall this extended object JohnAsStudent.
In Fibonacci, John and JohnAsStudent are considered to be the same object bythe object identity test. Nevertheless, John and JohnAsStudent have different be-haviours: the first does not understand the Number method while the second does.It is also possible, for instance, for John to take a part time job, requiring that theobject that represents him be extended in another direction, creating JohnAsEm-
ployee. Moreover, JohnAsEmployee might also understand a Number method, whichreturns John’s employee number. Fibonacci implements these abstractions by treat-ing an object as a DAG of roles; messages are sent to a receiving role, which firsttries to “delegating” to subroles, and then inheriting from superroles. Thus themeaning of John.Number depends on the role type of John.
The role model emphasises the ability of an object to receive and send differentmessages at different stages of evolution, by means of changing dynamically the typeof an object. Our approach restricts all the variants of an object to having the samebasic interface whereas, in the role model, the interface of objects may well containa completely distinct set of operations. Static type checking with state-dependentinterface might require some interesting analysis similar to typestate checking in theHermes language discussed below in this section.
5.3 Predicates Classes
Predicate class[4] is a linguistic approach which extends the standard object-orientedparadigm by reifying behaviour modes of objects. A predicate class has all the prop-erties of a normal class, including a name, a set of superclasses, a set of methods,and a set of instance variables, and additionally, it has an associated predicate ex-pression. A predicate class represents the subset of the instances of its superclass(es)that also satisfy the predicate. Whenever an object is an instance of the superclassesof the predicate class, and the predicate expression evaluates to true when invokedon the object, the object will automatically be considered to inherit from the pred-icate class as well. While the object inherits from a predicate class, it inherits allthe methods and instances variables of the predicate class. If the object’s state laterchanges and the predicate expression no longer evaluates true, the inheritance of theobject will be revised to exclude the predicate class. Predicate class thus support aform of automatic, dynamic classification of objects, based on their runtime value,state, or other user-defined properties.
Although this approach is powerful and structured, it does not seem to providea clean separation between the predicate classes and the normal classes; both kindsof classes are represented by the same hierarchy. The classes representing the pred-icates become easily confused with those representing subtyping. That is, the ap-proach overloads the already rather overloaded inheritance mechanism. Again, thisapproach also addresses many of the same issues as transmutable objects, thoughfrom a linguistic viewpoint.
5.4 Hermes Typestate and Variants
The static type checking provided by the predicate class proposal earlier discussed inthis section, ensures that a uniform interface is provided by an object, independentof its state at runtime. A less restrictive approach to type checking would allow dif-
ferent states of an object to have different interfaces similar to the role approach. Forexample, a stack object might have empty stack and non empty stack state objects,but only the non empty stack object would support a pop operation. This approachwould require a type state checking similar to the typestate checking in the Hermeslanguage[26]. Typestate is a refinement of the concept of type. Whereas the type ofa data object determines the set of operations ever permitted on the object, type-state determines the subset of these operations which is permitted in a particularcontext. In this proposal, a type is not only characterised by the set of operations itprovides but also by an automaton. The automaton associated to a type is definedas follows: states indicate the subset of the operations that may actually be applied,and transitions correspond to applications of the operations.
Hermes also supports the notion of variant type to weaken the constraint thatthe type of every value should be known at compile-time. A variant is just like arecord, but whereas an initialised record may have several components, only onecomponent of a variant can exist at any one time. Which component it is dependsupon the case of the variant. For example, a Lisp object is either an atom, a pair,or nothing (nil). So the LispObject is a type whose case is an enumeration value,either atom, pair or nil. Each component is associated with one of the cases of thevariant.
These notions have been introduced in the strongly-typed, concurrent object-oriented language called Arche[3], although the main concern was to characterisestates under which a given method call may be selected. In this proposal, a typeis extended by sets of peculiar type-states called synchronisation-states. Withina type, a synchronisation-state defines the method that may be executed by theobjects of the type when they are to select an incoming message.
6 Conclusions
The object-oriented paradigm promises to be one of the most flexible and gen-eral frameworks for developing software systems. An approach for structuring andclassifying behaviours and states, and in particular faulty behaviours and states, inobject-oriented systems has been proposed. The mechanism obtained using such ap-proach can be used to solve the problem of system evolution in class-based systems,that is, how objects evolve during runtime. Classes are very useful in structuringlarge systems. For real large applications, static typing checking is crucial. How-ever, sometimes it is essential to have some runtime flexibility. We presented anapproach that benefits from the best of these two worlds: the security of compile-time class creation and the flexibility of implementing dynamic changes via thedelegation mechanism. Transmutable objects allow changing the way they respondto messages at runtime. This evolution mechanism is closely related to the bindingbetween method call and method code. So when a transmutable object receives amessage, the method look-up is done as in a class-based language. Once the methoddefinition is found, the operation is delegated to the current state object, and themethod code is executed.
The approach here described was being applied to improve the structuring ofa software controller with a complex and error-prone environment: a large model
railway with 92 switches and 150 sensors. The main goal of this application is toensure that correct system operation is maintained despite the presence of envi-ronmental faults such as malfunctions of switches and sensors. Different behaviourphases (including normal and abnormal ones) for switches and sensors are identifiedand a class hierarchy that captures these behaviour phases is developed in parallelwith the application class hierarchy. The two hierarchies are linked together by adelegation mechanism - at any particular time, an application object will exhibita particular behaviour implementation. More generally, our approach allows onelink together separate class hierarchies via a delegation mechanism, each providinga different hierarchical user’s view of what it is meant to be a same abstraction. Bysuch means it is possible to specify different views of a system’s behaviour, and theintended constraints on such behaviour.
Acknowledgements
This work has been supported in part by funding from the ESPRIT Basic ResearchAction entitled Predictable Dependable Computing Systems (research project 6362 -PDCS2) and also by Conselho Nacional de Desenvolvimento Cientıfico e Tecnologico- CNPq (Brazil), grant n. 200198/90.4. The presentation of these ideas has benefitedfrom discussions with our colleague Robert J. Stroud. The authors also would liketo thank Jean-Charles Fabre and Vincent Nicomette for their comments.
References
[1] G. Agha. Actors: A Model of Concurrent Computation in Distributed Sys-
tems. MIT Press, Cambridge, Massachusetts, 1986.
[2] A. Albano, R. Bergamini, G. Ghelli and R. Orsini. An Object Data Model
with Roles. Technical Report, no. FIDE/93/65, FIDE2: Fully Integrated DataEnvironment, ESPRIT BRA PROJECT 6309, 1993.
[3] M. Benveniste and V. Issarny. Concurrent Programming Notations in the
Object-Oriented Language Arche. Technical Report, no. 1822, IRISA/INRIA-Rennes, France, 1992.
[4] C. Chambers. Predicate Classes. In Proceedings of ECOOP’93, Kaiser-slautern, Germany, LNCS, 707: 268-296, Oscar M. Nierstrasz (Ed.), July1993.
[5] D. Coleman, F. Hayes and S. Bear. Introducing Objectcharts or How toUse Statecharts in Object-Oriented Design. IEEE Transactions on Software
Engineering, 18(1): 9-18, January 1992.
[6] O.-J. Dahl, B. Myhrhaug and K. Nygaard. Simula 67 Common Base Lan-
guage. Publication no. S-22, Norwegian Computing Center, Oslo, October,1970.
[7] S.R. Davis. C++ Objects that Change Their Types. Journal of Object-
Oriented Programming, 5(4): 27-32, July/August 1992.
[8] D. D’Souza. Navigating Those Learning Curves. Journal of Object-Oriented
Programming, 5(6): 21-25, October 1992.
[9] J. Gallagher. Basic Concepts II (Variations on a Theme). In Object-Oriented
Languages, Systems and Applications, Blair, Gallagher, Hutchison & Shep-herd (Eds.), Chapter 3, Pitman, 1991.
[10] D. Gangopadhyay and S. Mitra. ObjChart: Tangible Specification of ReactiveObject Behavior. In Proceedings of ECOOP’93, Kaiserslautern, Germany,LNCS, 707: 432-457, Oscar M. Nierstrasz (Ed.), July 1993.
[11] D. Harel. Statecharts: A Visual Formalism for Complex Systems. Science of
Computer Programming, 8: 231-274, North-Holland, 1987.
[12] D. Harel et al. STATEMATE: A Working Environment for the Developmentof Complex Reactive Systems. IEEE Transactions on Software Engineering,SE-16(4): 403-414, 1990.
[13] J. Kramer, J. Magee and A. Young. Towards Unifying Fault and ChangeManagement. In Proceedings of the Second IEEE Workshop on Future Trends
of Distributed Computer Systems, Cairo, September 1990.
[14] P.A. Lee and T. Anderson. Fault Tolerance: Principles and Practice. Second,Revised Edition, Springer-Verlag, 1990.
[15] B.H. Liskov and A. Snyder. Data Abstraction and Hierarchy. Addendum
to the Proceedings, OOPSLA’87, Special Issue of ACM SIGPLAN Notices,23(5):17 -34, May 1988.
[16] O. Madsen and B. Magnusson. Strong Typing of Object-Oriented LanguagesRevisited. ACM SIGPLAN Notices, 25(10): 140-150, October 1990.
[17] J.D. McGregor and D.M. Dyer. A Note on Inheritance and State Machines.Software Engineering Notes, ACM SIGSOFT, 18(4): 61-69, October 1993.
[18] B. Meyer. Object-Oriented Software Construction. Prentice-Hall, 1988.
[19] B. Meyer. Applying “Design by Contract”. IEEE Computer, 25(10): 40-51,October 1992.
[20] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W. Lorensen. Object-
Oriented Modeling and Design. Prentice Hall, 1991.
[21] S. Shlaer and S.J. Mellor. Object Life Cycles: Modeling the World in States.Yourdon Press, 1992.
[22] H.A. Simon. The Architecture of Complexity. In The Sciences of the Artifi-
cial, Second Edition, MIT Press, 1981.
[23] A. Snyder. Encapsulation and Inheritance in Object-Oriented Program-ming Languages. In Proceedings of OOPSLA’86, Portland, Oregon, Septem-ber/October, Special Issue of ACM SIGPLAN Notices, 21(11): 38-45,November 1986.
[24] M. Stadel. Object-Oriented Programming Techniques to Replace SoftwareComponents on the Fly in a Running Program. ACM SIGPLAN Notices,26(1): 99-108, January 1991.
[25] L.A. Stein. Delegation is Inheritance. Proceedings of OOPSLA’87, Orlando,Florida, Special Issue of ACM SIGPLAN Notices, 22(12): 138-146, October1987.
[26] R.E. Strom, D.F. Bacon, A.P. Goldberg, A. Lowry, D.M. Yellin and S.A.Yemini. Hermes: A Language for Distributed Computing. Prentice Hall, 1991.
[27] B. Stroustrup. The C++ Programming Language. Second Edition, Addison-Wesley, 1991.
[28] A. Taivalsaari. Object-Oriented Programming with Modes. Journal of Object-
Oriented Programming, 6(3): 25-32, June 1993.
[29] D. Ungar and R.B. Smith. Self: The Power of the Simplicity. In Proceedings
of OOPSLA’87, Orlando, Florida, Special Issue of ACM SIGPLAN Notices,22(12): 227-241, October 1987.
[30] P. Wegner. Concepts and Paradigms of Object-Oriented Programming.OOPS Messenger, 1(1): 7-87, August 1990.