1 A Reflective Implementation of Software ... - Semantic Scholar

A Reflective Implementation of Software Architectures for Adaptive Systems Rogério de Lemos and Emiliano Tramontana Department of Computing Science University of Newcastle upon Tyne, NE1 7RU, UK {r.delemos, emiliano.tramontana}@newcastle.ac.uk

Abstract Adaptive systems should be able to adapt to changes that occur in their operating environment without any external human intervention. Software architectures for such systems should be flexible enough to allow components to change their pattern of collaboration depending on the environmental changes and goals of the system: considering that the capability of a system to be adaptable depends on how objects, as rigid entities, cooperate. This paper describes a reflective implementation of co-operative object-oriented architectures. The feasibility of the reflective implementation of software architectures is demonstrated in terms of a case study of a control system that has to adjust the height of a vehicle’s suspension to different road conditions. Keywords: software architectures, objects, collaborations, run-time adaptability, reflection. 1. Introduction In the engineering of computer based systems, there has been a trend in which the quality of services delivered by a system, in terms of its dependability, performance and cost, is directly related to the quality and extent of the computer facilities embedded in that system. Software has played a central role in this trend because of its inherent flexibility in emulating physical devices and replacing human operators. As the life span of new emerging software intensive applications increases, so does the need for software to have the capability of adapting to changes that occur in its operating environment. However, providing an adaptive capability leads to an increase in software size and complexity, which could put system integrity at risk unless the software architecture enables adaptability to be engineered in a disciplined and structured manner. Architectural structures for systems tend to abstract away from the details of a system, but assist in understanding broader system-level concerns. This can be achieved in software architectures by employing abstractions and notations which are appropriate for describing the software components, the interactions between these components, and the properties that regulate the composition of components. In architectural descriptions which use collaboration-based designs as a basis, software systems are represented as a composition of independently-definable collaborations: collaborations are a group of objects together with a group of activities that determine how objects interact, and the object's role is that part of an object which prescribes the activity of the object within a collaboration /Smaragdakis 98b/. However, there are some applications where the notion of collaboration is not sufficient to represent collaborative behaviour, for instance, in complex concurrent applications it is also necessary to capture the notion of co-ordination for supporting error handling between multiple interacting objects /Randell 97, Xu 95/.

1

In addition to the notion of collaboration, software architectures for adaptive systems should include an architectural element which is able to represent the dynamic composition of software components. The modelling abstraction co-operative action (CO action) was introduced in order to co-ordinate collaborations between objects /de Lemos 98/. In a cooperative object-oriented architecture an object can be involved in more than one cooperation (defined by its participants and collaborative activity), and depending on the required behaviour of the system, co-operations are able to reconfigure interactions between objects. The rest of the paper is organised as follows. Section 2 discusses some basic issues related with run-time adaptability, providing the motivation for the work. In section 3, the cooperative object-oriented architectural style is presented in terms of its architectural elements and configuration rules. Section 4 discusses the reflective implementation of co-operative object-oriented architectures. In section 5, the feasibility of the approach is demonstrated in terms of the case study of a control system that has to adjust the height of a vehicle’s suspension to different road conditions. Finally, section 7 concludes with a discussion evaluating our contribution and indicating directions for future work. 2. Run-Time Adaptability Run-time adaptability is the ability of a software system to adapt itself to changes that occur in its operating environment, while providing its required service. In a co-operative objectoriented architecture the degree of run-time adaptability of a software system depends on the flexibility of components changing their pattern of collaboration. Instead of having a software system based on components which individually are able to provide a wide range of services, the proposed approach relies on the ability of components to reconfigure their collaborations while they remain unchanged. In the context of a co-operative object-oriented architecture, a system can either adapt its behaviour or its structure, although, adaptive systems might contain a mixture of these two types of adaptability. • In behavioural adaptability, the system components and their configurations remain the same, while the system behaviour changes by modifying the pattern of collaboration between the components. • In structural dependability, the behaviour of the system remains the same, while the system architecture changes by modifying (or replacing) the components, or their configurations. At the design level, an example of structural adaptability is adaptive fault tolerance /Kim 92/. The aim of this paper is to define an architectural representation which enables behavioural adaptability to be incorporated in co-operative object-oriented architectures of software systems. 3. Co-operative Object-Oriented Architectural Style An architectural style provides a specialised language for a specific class of systems that are related by shared structural and semantic properties /Shaw 96/, which include: a vocabulary of architectural elements (components and connectors), configuration rules that constraint how components and connectors can be composed, semantic interpretations that provide

2

well-defined meanings for the components, connectors, and compositions of these, and the type of analyses that can be performed on systems employing a particular style. For example, a software system might be described using one of the following more commonly used styles: pipes and filters, objects, repositories, layers, and interpreters. Systems are defined by their components and the relationships among their components, hence when modelling systems using an object-oriented approach, objects alone are insufficient to describe the system behaviour. Co-operative Actions (CO actions) were introduced for representing interactions between objects which characterise collaborative behaviour /de Lemos 98/. One of the motivations for using CO actions in an object-oriented approach is the ability of CO actions to extract from the specification of an object those issues which are related with its collaborative activities (although preserving object's encapsulation property), thus avoiding a specification of a co-operation to be scattered among objects. CO actions are a variant of Co-ordinated Atomic Actions (CA actions) /Xu 95, Randell 97/ which are design mechanisms for structuring complex concurrent activities and supporting error recovery between multiple interacting objects in an object-oriented system. In the following, we present in more detail the co-operative object-oriented style, which adopts as a basis the features of object-oriented models. 3.1. Architectural Elements The architectural elements of the co-operative object-oriented style are classes as the basic components, and CO actions as the basic connectors. (Classes and CO actions are instantiated, respectively, into objects and co-operations.) The difference between these elements is that while classes perform computation locally, CO actions essentially coordinate the distributed computation performed by the participant classes. In a CO action, the role of a class is prescribed by the activity of that class. A class may have as many roles as the number of CO actions it participates. The composition of these roles defines the interface of the class. At the architectural level no relational information is spread across classes, only CO actions contain relational information (how a co-operative object-oriented architecture is implemented is discussed later, however a CO action can be instantiated into an association when the interactions between classes are simple service requests). An advantage for only CO actions to contain relational information is that, once a co-operative object-oriented architecture is instantiated, co-operations can be added or removed without interfering with the object implementation of objects, thus improving modularity and reusability of the software. 3.1.1. Classes As in object-oriented models, classes in the proposed approach, support the representation of both structural and behavioural aspects of a system. A class is described by a template with the following fields: a name, declaration of attributes in terms of constants and variables which are local to the class, a description of its structure in terms of a collection of components in composed of and the intra-relations between the classes and its components, and finally, a description of the behaviour of the class. The behaviour field includes the initial state of the object, and behavioural assumptions or consistency invariants associated with the class. The behavioural field also includes the specification of the complete space of the behaviour of the class, in terms of its normal, exceptional and failure behaviours.

3

Normal and exceptional behaviours are related with the liveness properties of a system (“something good" eventually happens), while failure behaviours are related with the safety properties of a system (“something bad" does not happen). 3.1.2. Co-operative Actions CO actions are employed in the specification of co-operative behaviour between classes. CO actions can either co-ordinate the activities to be performed by the classes, or execute some activity which is not associated with any particular class which takes part in the co-operation. A CO action is described by a template with the following fields: the CO action's name, declaration of attributes in terms of the names and types of the participants of the CO action, constants and variables local to the CO action, and the specification of the collaborative behaviour of the classes participating in the CO action. The template for describing a CO action is the following: The initial state of a CO action represents its state when is activated, and is dissociated from the pre-conditions of the CO action: it either refers to the state of classes participating in the co-operation or the state of the variables local to the CO action. Associated with the description of normal behaviour, pre-condition and post-condition establish the respective conditions for a set of classes to start and finish a particular collaborative activity, and the invariant establishes the conditions which should hold while the collaborative activity is being performed. For the successful execution of a collaborative activity it is necessary that the pre- and post-conditions of the normal behaviour are satisfied, and that the invariant associated with the collaborative activity is not violated during its execution. For the specification of exceptional behaviour, the invariant is replaced by a handler, which identifies the exception event, together with the start and finish events associated with the handler of the exception. Although the pre-conditions for normal and exceptional behaviours are the same, the post-conditions for the exceptional behaviour might be different, depending on the degraded outcomes of a CO action, once an exception has occurred. In the definition of a CO action, an exception can be associated with the invariant whenever this is violated, or with the post-conditions whenever one of the conditions is not satisfied. A CO action provides the basis for dealing with both co-operative and competitive concurrency by integrating two complementary concepts: conversations /Randell 75/ and transactions /Gray 93/. Conversational support is used to control co-operative concurrency and to implement co-ordinated and disciplined error recovery, whilst transactional support maintains the consistency of shared resources in the presence of failures and concurrency among different collaborative activities competing for these resources / Xu 95, Randell 97/. 3.2. Configuration Rules For the description of systems, the configuration rules of the co-operative object-oriented style define how objects and co-operations can be combined. In the following, we will focus on the static properties of the co-operative object-oriented style. In a co-operative object-oriented architecture each class and CO action has an unique name. Classes can participate in more than one CO action, and at least two classes have to be associated with a CO action, thus avoiding the “dangling” of CO actions. A CO action defines and is defined by the roles of the classes, thus creating the context in which classes

4

collaborate. At the architectural level, the relationships between classes can be dependencies, generalisations, and aggregations. The same applies to CO actions. 3.3. Co-operative Object-Oriented Architectures and Adaptability In a co-operative object-oriented system, behavioural adaptability is obtained by changing how objects co-operate, and the selection of a co-operation depends on the state of the collaboration between the objects. An architectural representation of such system should describe the collaborative activities between classes in terms of CO actions. The conditions for selecting a co-operation should be part of the definition of a CO action, and these conditions are related to either the internal state of the co-operation or the states of the objects participating in the co-operation. Hence the architectural representation should be able to describe, across different states, the behavioural adaptability of the collaborative activities between classes. The intent of the State design pattern is to allow an object to alter its behaviour when its internal structure changes /Gamma 94/. In this paper we claim that this design pattern can be also used to provide the required support for a co-operation to alter its behaviour when its state changes. The structure of the design pattern State, in terms of CO actions, is shown in figure 1. The abstract State CO action defines the interface common to all the CO actions that represent the different states of the co-operation (an instance of COAction). COAction delegates all state-specific collaborations to the State CO action, and depending on its state, COAction uses an instance of a specialised CO actions (COAction1, COAction2,...) of the abstract State CO action to implement a collaboration. Using the design pattern State, we are able to obtain an effective and structured representation of behavioural adaptability using the co-operative object-oriented style. &2$FWLRQ



GHOHJDWHWR

&2$FWLRQ

6WDWH

&2$FWLRQ

Figure 1. State design pattern in terms of CO actions. 4. Reflective Implementation of Co-operative Object-Oriented Architectures This section describes the reflective implementation of co-operative object oriented (COO) architectures that in addition of providing support for run-time adaptability, it should also provide a clear separation between the application software and the computational support. Adaptability was achieved by allocating to meta-level the architectural entities which are more likely to change during run-time, that is co-operations, while the separation between application and support was achieved by defining a structure of object and collaboration managers for the support which mirrors the structure of the application software. A reflective software system is a system which contains structures representing aspects of itself that enable the system to support actions on itself. In OO programming, meta-objects were introduced to represent and control the behaviour of the objects /Maes 87/. In the metaobject model, each meta-object intercepts the messages sent to the base-level object to which

5

the meta-object is connected, and performs its meta-computation before it delivers the messages back to the base-level object /Ferber 89/. The diagram of figure 2 represents a reflective architecture of a COO design, where the application is composed of objects :Class1 and :Class2 which provide the basic functionality of the application, and co-operation :COActionA which defines the collaborative activity of the objects. The two objects were allocated to the base-level, and cooperation :COActionA was allocated to the meta-level because within the proposed approach to support adaptability, co-operations embody system dynamic change. The co-ordinating operations of a CO actions are defined in terms of three methods /Tramontana 99a/: pre() and post() which check, respectively, the pre- and post-conditions associated with a CO action, and coll() which executes the collaborative activities and checks whether the invariant is maintained. The support level of the architecture is composed of managers which mirror the structure of the application: an object manager controls the access and establishes the rules for co-operations to invoke services from its associated object, and a co-operation manager co-ordinates the request for accessing the objects used in a co-operation. &2$0DQDJHU UHTXHVW

UHTXHVW

FROODE WUDS

&0DQDJHU

&0DQDJHUO VXSSRUW DSSOLFDWLRQ

&2$FWLRQ$ PHWDOHYHO EDVHOHYHO

FKHFN

FKHFN

LQYRNH

LQYRNH

PHWKRG$

&ODVV

&ODVV

Figure 2. Reflective implementation of the COO architecture. In the following sections, we present in more detail the roles of each of the managers, and describe the flow of activation, once a method call to one of the objects of the base-level is trapped to the meta-level. The reflective implementation of COO designs is obtained using Dalang /Welch 98/ which is a reflective language based on Java. In Dalang metaobjects exist during run-time, so they can be dynamically created, destroyed, and associated to objects at the base-level. A meta config file is used to determine the association of meta-objects with objects. 4.1. Object Manager An object manager controls the access and establishes the rules for co-operations to invoke services from its associated object. For that, each manager at the meta-level introspects its respective object at the base-level to obtain all the necessary information for controlling the access to the object (granting the access could depend on the object's state). The access control can be enforced by mutual exclusion, to preserve object integrity in the presence of multiple accesses by several co-operations. 4.2. Co-operation Manager

6

The role of the co-operation manager is to co-ordinate the requests for accessing the object participants of a co-operation. The services provided by the co-operation managers include, interception of message calls to the base-level objects, acquisition of accessing rights to object participants, and activation of the co-operations at the application level. The activation of the co-operation can be done either synchronously once all the participants have granted permission for accessing, or asynchronously once individual objects are released from other co-operations. Although the latter approach is able to obtain an optimal usage of the resources, it is nevertheless more difficult to implement because is application dependent /Romanovsky 97/. 4.3. Flow of Activation The following describes the sequence of invocations for activating CO action :COActionA which has got objects: :Class1 and :Class2 as participants. When methA() of :Class1 is invoked (1), the call is intercepted (2) by co-operation manager :COAManager, at the support level, which co-ordinates the requests (3) to access the objects involved in the co-operation :COActionA. When access has been granted by all the objects, the control is given to the meta-object implementing the CO action :COActionA (4). At the application level, the initial step to be taken by co-operation :COActionA is to check whether the pre-conditions are satisfied (5). Once the check returns True, the collaborative activity involving the co-operation participants starts (5), until either the invariant or the postcondition associated with the co-operation is violated. 5. Case Study: Electronic Height Control System (EHCS) 5.1. Description of the Case Study The electronic height control system (EHCS) controls the height of a vehicle by regulating the individual heights of the wheels through a pneumatic suspension. The aim of this system is to adjust the chassis level depending on the road conditions, in order to improve driving comfort and keep the headlight load-independent /Stauner 97/. )5

&RPSUHVVRU

55

9DOYH

9DOYH

9DOYH

9DOYH

VS

VS LWL RWL

(VFDSH

)/

9DOYH

VS LWL

5/

RWL

LWL RWL

RIIURDG

JUDYHO

PRWRUZD\

)5IURQWULJKWZKHHO )/IURQWOHIWZKHHO

VSVHWSRLQW

55UHDUULJKWZKHHO

LWLLQQHUWROHUDQFHLQWHUYDO

5/UHDUOHIWZKHHO

RWLRXWHUWROHUDQFHLQWHUYDO

Figure 3. Diagramatic representation of the EHCS.

7

For this case study three distinct types of road are considered, namely, off-road, gravel and motorway. For each type of road we define a set point and two sets of tolerance intervals, as shown in the diagram of figure 3. In each of the four wheels there is an pneumatic suspension which is able to control the height of an individual wheel. Whenever the height of a wheel is outside the outer tolerance interval, the controller has to bring the height into the inner tolerance interval around the set point. The major components of the EHCS are a valve and a height sensor at each wheel, and an escape valve and a compressor to be shared by all the wheels, as shown in the diagram of figure 3. The height of a wheel suspension is increased by opening the wheel valve, closing the escape valve, and pumping air into the suspension. The height is decreased by releasing air from the suspension by opening the escape valve, and the valve of the wheel from which the height has to be reduced. The compressor and the escape valve cannot be used simultaneously, priority is given to the compressor when both have to be used. It is assumed that the height values provided by the sensors are mean values of the actual readings from which the disturbances, like road holes, are eliminated. The aim of this case study is to define a software architecture which enables the EHCS to adapt at run-time to changes that occur in the system environment. In terms of the height control system, the adaptability element is related with selection of the appropriate control algorithm depending on the type of road. In terms of the EHCS software architecture, the software components remain the same, while the pattern of collaboration between the components changes. 5.1. A Co-operative Object-Oriented Architectures for the EHCS In this section the software architecture for the electronic height control system (EHCS) of a vehicle suspension is established in terms of the co-operative object-oriented style, previously defined. The diagram of figure 4 represents the class and CO action structures for the EHCS. The representation of CO actions follows that of a class in UML /Booch 98/, except for the rounded corners. The CO action MaintainSP is responsible for maintaining the height of the suspension around the set point, and is composed by three other CO actions: ReadMH which is responsible for updating Wheel with the value of mean height of the suspension, and IncreaseMH and DecreaseMH which are responsible, respectively, for increasing and decreasing the suspension height of a wheel. Depending on road condition, a different control algorithm is necessary for maintaining the height of the suspension, hence MaintainSP can be specialised into MSPOffRoad, MSPGravel, and MSPMotorway. For example, it might be necessary, depending on the road conditions, to establish different tolerance levels for IncreaseMH and DecreaseMH, or to establish time intervals for updating (∆update) the value of the mean height in class Wheel.

8

0DLQWDLQ63

GHOHJDWHWR



5RDG7\SH 5HDG0+ ,QFUHDVH0+ 'HFUHDVH0+

6XVSHQVLRQ

5HDG0+ 0632II5RDG

:KHHO +HLJKW6HQVRU 

&RPSUHVVRU





:KHHO

(VFDSH9DOYH

063*UDYHO

,QFUHDVH0+



+HLJKW6HQVRU

&RPSUHVVRU (VFDSH9DOYH :KHHO :9DOYH



:9DOYH

0630RWRUZD\

'HFUHDVH0+

&RPSUHVVRU (VFDSH9DOYH :KHHO :9DOYH

(i) class diagram

(ii) CO action diagram

Figure 4. Co-operative object-oriented diagrams for the EHCS. For the sake of brevity, and to avoid repetition, only the composite CO action MaintainSP will be specified. The specifications of MSPOffRoad, MSPGravel, and MSPMotorway follow directly from MaintainSP. We assume that MaintainSP, which is considered appropriate for all types of road, is replaced by other three CO actions which encapsulate control algorithms which are specific for particular types of road. In the following, we present a brief description of the main CO actions of the case study, the formal specification of the CO actions using Extended Real-Time Logic was presented elsewhere /de Lemos 99/. The CO action MaintainSP co-ordinates the activities between the components of the Suspension to maintain the mean height of a Wheel’s around the established set point. The co-ordination of the collaborative activities is partitioned into three CO actions, detailed below. The definition of MaintainSP states that the pre-condition for MaintainSP to be activated is when EHCS is switched on (ehcs.on), and it will remain activated until the EHCS is switched off. The invariant defines the type of road for which MaintainSP is appropriate, which for this case we assume to be for all types of road. The provision of an adaptive software will be based on the specialisation of MaintainSP for the different types of road, which will be presented at the end of this section. The CO action ReadMH captures the collaboration between Wheel and HeightSensor, and is responsible for updating periodically the Wheel’s variable for the mean height of the suspension, which is obtained from the HeightSensor. The pre-condition for normal behaviour establishes that ReadMH starts periodically every ∆update. The invariant states that for ReadMH to be active, the current update has still to be made and the interval for the next reading has not expired. The post-condition is captured by two transition event predicates which specify the necessary and sufficient conditions for the co-operation to end: the variable w.height has been updated, or the time interval available for updating has expired. The CO action IncreaseMH is responsible for increasing the mean height of the suspension once a minimum threshold is reached. The pre-condition for normal behaviour establishes that the CO action starts when the Compressor is off, the EscapeValve and WheelValve are closed, and the minimum height threshold is reached. While the mean height of the 9

suspension is being increased the Compressor should be on, the EscapeValve closed, the WheelValve open. Once the mean height is within the inner tolerance interval, IncreaseMH ceases to be active. The description of CO action DecreaseMH follows the same pattern of IncreaseMH. However, for reducing the mean height of the suspension the Compressor should be off, and the EscapeValve and WheelValve should be open. According with the proposed approach, outlined in section 3.3, an adaptable software system for the EHCS can be obtained by applying the design pattern State /Gamma 94/ to the CO actions that capture the collaborative activity between the components of the Suspension. Referring to the CO action diagram of figure 4, the behaviour of MaintainSP depends on the state of RoadType, and depending on this state the behaviour of MaintainSP must change at run-time. Instead of defining a CO action for all types of road, the design pattern State allows to partition MaintainSP into other CO actions, namely, MSPOffRoad, MSPGravel and MSPMotorway. These three CO actions are mutually independent, and depending on the types of road they are defined in terms of specific attributes and control algorithms for maintaining the height of the suspension around the established set point, as shown in figure 4. 5.2. A Reflective Design for the EHCS Figure 5 shows the object and co-operation structure of the reflective implementation of the co-operative object-oriented architecture of the EHCS. In this snapshot of the reflective implementation, we only consider the co-operation :IncreaseMH when the vehicle is offroad, hence when the co-operation :MSOffRoad is activated. As already mentioned, for the different types of road there is a different algorithm for increasing the medium height of the suspension, this is capture by the different versions of the co-operation :IncreaseMH. For the support level, although there are different coo-operations :IncreaseMH, there is only one manager associated with all the co-operations. This is justified because this architecture only supports behavioural adaptability, hence it is not expected for the number and type of object participants to change while the system adapts. 0,QFUHDVH0+

0&RPSUHVVRU

0(VFDSH9DOYH

0:KHHO

0:9DOYH

VXSSRUW DSSOLFDWLRQ 0632II5RDG

,QFUHDVH0+

PHWDOHYHO EDVHOHYHO

&RPSUHVVRU

(VFDSH9DOYH

:KHHO

:9DOYH

Figure 5. Reflective implementation of the COO architecture of the EHCS. When the message, requesting for the height of the suspension to be increase, is trapped by :MIncreaseMH, the co-operation manager will check the availability of the object 10

participants. Once the access is granted, :MIncreaseMH will select, depending on the type of road, the appropriate co-operation for increasing the height of the suspension. In the scenario of figure 5, the co-operation :IncreaseMH associated with :MSPOffRoad will be selected. 6. Conclusion In this paper we have presented how collaborations between objects can be exploited when defining software architectures for adaptive systems. As a basis for the proposed approach, we have considered that objects are rigid entities, and the basis for adaptability depends on how they collaborate. Hence all the additional features which enables an object, or a group of objects, to adapt to changes that occur in its environment are not capture in the object itself, instead they are defined in the co-operations in which the object is a participant. For describing the architectures for adaptive software systems we have defined a co-operative object-oriented style where components are the classes, and connectors are the co-operative actions (CO actions). As architectural elements, CO actions capture the behavioural dependencies between the classes which are related with the adaptability features of an object, or group of objects. In this paper, we have only considered the type of run-time adaptability where the components remains unchanged while the behaviour of the system changes, however, depending on the type of application and the purpose of the system, another types of adaptability have also to be considered. Acknowledgements The authors would like to acknowledge the financial support from the EPSRC/UK ADAPT Project. References /Booch 98/ G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley. Reading, MA. 1998. /de Lemos 98/ R. de Lemos, A. Romanovsky. “Coordinated Atomic Actions in Modelling Object Cooperation” Proceedings of the 1st IEEE International Symposium on ObjectOriented Real-Time Distributed Computing. Kyoto, Japan. April, 1998. pp. 152-161. /de Lemos 99/ R. de Lemos. A Co-operative Object-Oriented Architecture for Adaptive Systems. Technical Report 674. Department of Computing Science, University of Newcastle upon Tyne, UK. 1999. /Ferber 89/ J. Ferber. "Computational Reflection in Class Based Object Oriented Languages". Proceedings of the ACM Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA'89). Sigplan Notices 24. October 1989. pp. 317-326. /Gamma 94/ E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. Reading, MA. 1994. /Gray 93/ J. Gray, A. Reuter. Transaction Processing: Concepts and Techniques. Kaufman Publishers. San Mateo, CA. 1993.

11

/Kim 92/ K. H. Kim, T. Lawrence. “Adaptive Fault Tolerance in Complex Real-Time Distributed Applications”. Computer Communication, Vol. 15(4). May 1992. pp. 243-251. /Maes 87/ P. Maes. "Concepts and Experiments in Computational Reflection". Proceedings of the Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA'87). ). Sigplan Notices 22 (12). Orlando, FA. October 1987. pp.147-155. /Randell 75/ B. Randell. “System Structure for Software Fault-Tolerance”. IEEE Transactions on Software Engineering Vol. SE -1(2). 1975. pp. 220-232. /Randell 97/ B. Randell, A. Romanovsky, R. J. Stroud, J. Xu, A. F. Zorzo. Co-ordinated Atomic Actions: from Concept to Implementation. Technical Report 595. Department of Computing Science. University of Newcastle. UK. 1997. /Romanovsky 97/ A. Romanovsky, and A. Zorzo. "On Distribution of Coordinated Atomic Actions". ACM Operating System Review 31(5). October 1997. pp. 70-78. /Shaw 96/ M. Shaw, D. Garlan. Software Architectures: Perspectives on an Emerging Discipline. Prentice-Hall, Inc. Upper Saddle River, NJ. 1996. /Smaragdakis 98/ Y. Smaragdakis, D. Batory. “Implementing Reusable Object-Oriented”. Proceedings of the 5th International Conference on Software Reuse (ICSR'98). Victoria, Canada. June 1998. /Stauner 97/ T. Stauner, O. Müller, M. Fuchs. “Using HYTECH to Verify an Automative Control System”. Hybrid and Real-Time Systems. Ed. O. Maler. Lecture Notes in Computer Science 1201. Springer-Verlag. Berlin, Germany. 1997. pp. 139-153. /Tramontana 99/ E. Tramontana, and R. de Lemos. A Reflective Approach for Describing Cooperation between Objects. Technical Report 663. Department of Computing Science, University of Newcastle upon Tyne, UK. 1999. /Xu 95/ J. Xu, B. Randell, A. Romanovsky, C. Rubira, R. Stroud, Z. Wu. “Fault Tolerance in Concurrent Object-Oriented Software through Coordinated Error Recovery”. Proceedings of the 25th International. Symposium on Fault-Tolerant Computing. Pasadena, CA. 1995. pp. 499-509. /Xu 98/ J. Xu, A. Romanovsky, B. Randell, “Co-ordinated Exception Handling in Distributed Object Systems: from Model to System Implementation”. Proceedings of the 18th International Conference on Distributed Computing Systems. IEEE CS Press. Amsterdam, The Netherlands. May 1998. pp. 12-21. /Welch 98/ I. Welch, and R. Stroud. "Dalang - A Reflective Java Extension". OOPSLA'98 Workshop on Reflective Programming in C++ and Java. Vancouver, Canada. October 1998.

12