de Lemos, Rogerio

English

Kent Academic Repository

Representing Exceptional Behaviourat the earlier Phases of Software DevelopmentRogério de LemosComputing LaboratoryUniversity of Kent at Canterbury, CT2 7NF, UKr.delemos@ukc.ac.ukException handling is a structuring technique that facilitates the design of systemsby encapsulating the process of error recovery. Exception handling has beentraditionally associated with the design phase of the software lifecycle, during whichall the effort is made to protect the application software from faults that may beintroduced during requirements, design, and implementation, or can occur at thesupport level. The consequence of such approach is that the appropriate context inwhich errors should be detected and recovered is lost also it is lost the potentialcorrelation that might exist between the error states of the different contexts and howthese should be recovered in an optimised way.Dealing with concurrent manifestations of several faults at different phases ofsystem development has been recognised as a serious problem that has not receivedenough attention /Avizienes 97/. Ideally, for each identified phase of the softwarelifecycle, a class of exceptions should be defined depending on the abstraction level(or context) of the software system being modelled and analysed, as represented infigure 1. As the software development progresses, new exceptions are identified andtheir respective handlers specified. However, the exceptions identified at the differentphases can be causally and timely related, which might constraint the specification oftheir respective handlers. Moreover, it might be the case that the rationalisation ofexceptions might enable the usage of a single handler for different classes ofexceptions. At every phase of the software development failure assumptions have tobe revised once the system structure is decomposed and behaviour refined. Thisprocess of revising failure assumptions, as we progress through the software lifecycle,might also lead to the refinement of the exceptions and handlers previously specified.Instead of assuming that exception handling should be restricted to the later phasesof software development, recent work has attempted to provide systematic andeffective approaches on how to deal with exception handling at all phases of thesoftware lifecycle. These approaches provide a stepwise method for definingexceptions and their respective handlers, thus eliminating the ad hoc way in whichexception handling is sometimes considered during the later phases of the softwarelifecycle.In one of these works, the description of exceptional behaviour within thesoftware lifecycle is supported by a co-operative object-oriented approach that allowsthe representation of collaborative behaviour between objects at different phases ofthe software development /de Lemos 99/. In a co-operative object-oriented descriptionof a system, the role of a co-operative action (CO action) is to co-ordinate thecollaboration between classes, which also involves the description of exceptionhandling in both objects and co-operations. In terms of objects, when abnormalbehaviour cannot be handle locally by an object exceptions have to be propagated toco-operating objects; co-operations provide the support for co-ordinating thepropagation and the handling of exceptions between co-operating objects. Whenexceptions are raised inside co-operations that cannot be related to any specific objectinvolved in the co-operation, all the co-operating objects should handle the exceptionin a co-ordinated manner, to guarantee that once the co-operation is finished all theco-operating objects are in a known consistent state.RequirementsDesignImplementationE(d)E(a)HandlersE(i&s)EH MechanismApplication-relatedDesign-relatedImplementation &Support-relatedE(d)E(a)E(a)H(a)H(a) H(d) H(a&d)Figure 1. Exception handling in the software lifecycle.In a more recent work, a systematic approach for incorporating the exceptionbehaviour in the software lifecycle was considered in the context of Catalysis and theidealised fault-tolerant component architecture /Ferreira 01/. Catalysis is a wellestablished technique for the systematic development of component-based systemsthat has three primary modelling constructs: collaborations, types, and refinement/D’Souza 98/. What differs Catalysis from other traditional approaches arecollaborations: these are considered first class entities that incorporate how a group ofobjects jointly behaves when configured together. Collaborations are defined in termsof actions with their pre- and post-conditions that define collaboration. Forrepresenting the propagation and handling of exceptions in a collaboration, thedescription of actions is extended by including the definition of signals and handlers,and both the normal and exceptional behaviours of the collaboration are representedin terms of collaboration diagrams. While Catalysis provides the process fordeveloping software, the idealised fault-tolerant component provides the elementaryarchitectural representation for describing the fault tolerant activities of a system /Lee90/.While developing the above work, we have come across several deficienciesregarding the modelling and analysis of exceptional behaviour in the softwarelifecycle, particularly, at the higher levels of abstraction. One of the problems that wehave faced was the explicit representation of exception handling in the use cases.These were initially conceived for succinctly describing the problem at hand, but ifexceptional behaviour is to be considered at the requirements level, then exceptionshave to be represented in the use cases, thus increasing the complexity of theirdescription. A possible approach is to describe use cases with different levels ofdetail, and to make sure that these descriptions are consistent and accurate. The threebasic stages for this description are the following. In the first stage, the use casewould be described in its usual way /Jacobson 92/. In the second stage, we wouldrefine the use case by identifying system variables, providing a table of exceptionsrepresenting the causal relation between the abnormal behaviours of actors and usecases, and providing collaboration diagrams for the exception behaviour. Theobjective of this stage is to model and analyse the interdependencies between actorsand use cases taking into consideration their exceptional and failure behaviours. In thethird stage, we would formalise the use cases in terms of a first order logic that couldbe used as a basis to obtain a state model, which can then be model checked. This laststage would be very similar to the process of conducting safety analysis of a criticalsystem /de Lemos 01/. In this proposed approach of three stages, the balance betweenbeing rigorous and formal depends on the criticality of the system being analysed. Ifthe second stage is well documented, and consistent with the underlying formalmodel, then the client would be able to understand and discuss the requirements of thesystem without the need of understanding a formal language.Another problem that we have faced when dealing with exceptional behaviour atthe early phases of the software lifecycle was the representation of exception handlingat the architectural level. If the current trends of software engineering are to befollowed, i.e. the development of new systems out of existing components, then thearchitectural representation of systems will have a key role in the process of adaptingeither the components or the interactions between them. For example, if mechanismsfor enforcing dependability of services have to be added to an untrustworthycomponent, then it is necessary to provide structural means for incorporating therequired changes. The co-operative architectural style being proposed offers theappropriate means for structuring complex applications that are intrinsicallycollaborative in their nature, and aims to provide fault tolerance in the context of howexception handling mechanisms can be added to untrustworthy components. The keyarchitectural element of this style is a co-operative connector that encapsulatescollaborative behaviour between several components, which also involves co-ordinating the handling of exceptions between components. An example of a co-operative architecture is shown figure 2. The depicted system is composed by twocomponents (co1 and co2) that are interconnected by three connectors (cn1, cn2,and cn3). The connector cn1 captures the collaborative activity associated with thethree roles of the components co1 and co2. The collaborative activities associatedwith connectors cn2 and cn3 are nested to connector cn1.A co-operative connector is described in terms of the roles involved in thecollaborative activity, and the specification of collaborative behaviour in terms ofnormal, exceptional and failures behaviours. The normal behaviour in defined interms of the pre- and post-conditions, the invariant that should hold, and thecollaborative operation to be performed under the control of the connector. For thespecification of exceptional behaviour, a handler replaces the operation, and isdefined in terms of its start and finish events. Although the pre-conditions for normaland exceptional behaviours are the same, the post-conditions for the exceptionalbehaviour might be different, depending on the degraded outcomes of a collaborativeoperation, once an exception has occurred.co1co2co1.ic1co2.ic1co2.ic2co1.ic1co2.ic1co2.ic2cn1co2.ic1co2.ic2cn2co1.ic1co2.ic1cn3(a) Components diagram.        (b) Connectors diagram.Figure 2. Co-operative software architecture.Figure 3 shows the representation of exceptional behaviour of a co-operativeconnector in terms of timed automata extended with data variables /Larsen 1997/. Theautomaton on the left starts a co-operation when the pre-condition is true(pre==true), it executes the collaborative operation (operation:=true) while theinvariant holds (invariant==true), and exists the co-operation when the post-condition of normal behaviour is true (post_normal==true). The representation ofexception behaviour is related to the raising of an exception (signal!) that starts ahandler on the automaton on the right. Once the handler is executed (handler:=true),the co-operation is finished assuming that the post-condition for exception behaviouris true (pos_exceptional==true).outCoopstartCoopendCoopraiseExcoutHandlerstartHandlerendHandlerinvariant==trueoperation:=truesignal!pre==truesignal!post_normal==truepost_exceptional==trueleave?signal?handler:=trueleave!Figure 3. Automata representation of exceptional behaviour.Most of this work is still on going, and currently we are investigating architecturaldescription languages that would incorporate the adequate capabilities forrepresenting and analysing exceptional behaviour.Acknowledgements. This work was performed in collaboration with Gisele R. M.Ferreira, Alexander Romanovsky, and Cecília M. F. Rubira.References/Avizienis 97/ A. Avizienis. “Toward Systematic Design of Fault-TolerantSystems”. Computer 30 (4). April 1997. pp. 51-58./de Lemos 99/ R. de Lemos, A. Romanovsky. "Exception Handling in aCooperative Object-Oriented Approach". Proc. of the 2nd IEEE InternationalSymposium on Object-Oriented Real-Time Distributed Computing (ISORC’99). SaintMalo, France. May, 1999. pp. 3-13./de Lemos 01/ R. de Lemos. Analysing Failure Behaviours in ComponentInteraction. UKC Computing Laboratory Technical Report. 2001./D’Souza 98/ D. D'Souza, and A. C. Wills. Objects, Components and Frameworkswith UML: The Catalysis Approach. Addison-Wesley, Reading, MA 1998./Ferreira 01/ G. Ferreira, C. Rubira, and  R. de Lemos. “Explicit Representation ofException Handling in the Development of Dependable Component-based Software”./Jacobson 92/ I. Jacobson. Object-Oriented Software Engineering - A Use CaseDriven Approach. Addison-Wesley. 1992./Lee 90/ P. Lee, and T. Anderson. Fault-Tolerance: Principles and Practice.Springer-Verlag 2nd Edition. 1990.

Analysing Failure Behaviours in Component Interaction.

Exception Handling in a Cooperative Object-Oriented Approach&quot;.

Object-Oriented Software Engineering - A Use Case Driven Approach.

Objects, Components and Frameworks with UML: The Catalysis Approach.

Springer-Verlag 2nd Edition.

Toward Systematic Design of Fault-Tolerant Systems”.

Representing Exceptional Behaviour at the earlier Phases of Software Development

http://kar.kent.ac.uk/13630/1/representing_exceptional_behaviour_lemos.pdf

Representing Exceptional Behaviour at the earlier Phases of Software Development

Abstract

Similar works

Full text

Available Versions

Kent Academic Repository