On Exceptions and the Software Development Life Cycle

Transcription

1 On Exceptions and Stware Development Life Cycle Jörg Kienzle School Computer Science, McGill University Montreal, QC H3A2A7, Canada This paper presents insights we gained in our research aimed at integrating exceptions and exception handling into entire stware development life cycle. We argue that exceptions are different nature depending on level abstraction that system under development is looked at. We outline a mapping relating exceptions at a high level abstraction to exceptions and or stware artifacts at lower levels abstraction, and show that some exceptions introduced at a low level abstraction also require definition corresponding exceptions at a higher level abstraction in case where transparent handling at low level is not possible. Finally, we list potential benefits integrating exception handling into entire stware development life cycle. Categories and Subject Descriptors D.2.9 [Stware Engineering]: Management Life cycle; D.2.10 [Stware Engineering]: Design Methodologies Keywords exceptions, exception handling, stware development life cycle, requirements, stware architecture, design, implementation 1. INTRODUCTION Exceptions originated at programming language level, and although ideas exceptions and exception handling have been known for over 40 years, se concepts are currently not an integral part standard stware development methodologies. Exceptions are mostly used during implementation phase, if at all, and even n re are ten no clear guidelines when and how to use m. Object-orientation also originated at programming language level. Nowadays, however, object-orientation is applied at all phases stware development. An object is always an entity that has it s own identity, and encapsulates state and behavior. However, notion object has Permission to make digital or hard copies all or part this work for personal or classroom use is granted without fee provided that copies are not made or distributed for prit or commercial advantage and that copies bear this notice and full citation on first page. To copy orwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. WEH 08, November 14, Atlanta, Georgia, USA Copyright 2008 ACM $5.00. slightly different meanings depending on development phase in which it is used. At requirements engineering phase, objects represent domain concepts, e.g., external actors that interact with system under development, or entities encapsulating state which allows system to reason about problem domain. Objects at stware architecture level usually represent components that partition system into modules that interact at run-time through welldefined interfaces. Sometimes, partitioning into components can also be used to distribute application onto multiple machines. At design phase, a solution implementing specified problem is designed. To this aim, objects are created with well-defined responsibilities and state. Algorithms to achieve desired behavior are devised, and are realized by interacting objects. Finally, at implementation phase, individual objects are implemented by elaborating program statements that achieve desired functionality for each operation or method. Using concept object throughout entire stware development process is very beneficial. Although meaning an object changes throughout development activities, object-orientation provides traceability from requirements phase down to implementation phase by relating objects at different levels. Of course, mapping between objects from one phase to or is not always one-to-one. Often, a requirements-level object is realized using many design objects. Furrmore, during stware architecture and detailed design, new objects are added that realize a specific solution. Neverless, object-orientation provides a unified structuring methodology that has proven to streamline stware development considerably. We and ors [1, 10] believe that integrating exceptions into entire stware development process can provide similar advantages. This paper presents insights we gained over last few years in our research efforts that were aimed towards achieving this goal. The rest paper is structured as follows: section 2 presents background on exceptions and exception handling, on idealized fault-tolerant component and on exceptions within stware development life cycle; section 3 looks at nature exceptions and handlers at various phases stware development; section 4 presents mapping we established between exceptions at different levels abstraction; section 5 outlines expected benefits integrating exceptions into stware development life cycle, and last section draws some conclusions. 32

2 exceptions provided by programming languages or are indicated using exceptional replies to requests. It is even possible that some entity external to system component observes its failure and initiates appropriate error processing in users R DE LEMOS AND A ROMANOVSKY component. considering Service exception handling within Interface stware lifecycle Failure [8]. Request However, more Reply recent work which Exception deals with obstacles Exception in a goal-driven approach for requirements engineering has provided systematic techniques for identifying failure behaviours in requirements specifications [9]. Anor area in which new approaches have Localbeen Exception recently developed for specifying Normal and designing Processingactivities incorporating Error Processing multiple parties (objects or processes) and co-operative handling Return to normal exceptional situations is multiparty interactions [10]. The contents paper will be as follows. In next section exception handling is discussed in context stware Service lifecycle by Reply classifying Interface different types Failure exceptions. Request Section 3 describes co-operative Exception object-oriented Exception approach for stware development, which relies on a restricted Figurenumber 1: Fig. The 4: Idealized modelling Fault-Tolerant abstractions Component for Component describing stware systems. In section 4, we describe how exceptions Figure 1 Exception handling in stware lifecycle 2.6 Classification and handlers Concurrent can be represented Systems using co-operative Figure 2: Exceptions in Stware Life Cycle 2. EXCEPTIONS object-oriented approach. The feasibility whole The subsequent approach parts will be demonstrated paper present in and section review 4, in terms most commonly used stware fault tolerance 2.1 Background techniques, classi ed on Exceptions based and different Handlers abstraction phenomena being modelled and analysed Production Cell benchmark case study. Finally, in section forms 5 concurrency is essentially related to environment computer system. tech- Application-related exceptions correspond to error y support: sequential An exception techniques, describesindependent a situationor that, loosely-coupled if encountered, we present some concluding remarks. concurrent niques, competitiverequires something and collaborative exceptional concurrent to be done techniques, in order and to resolve hybrid techniques. it. During program execution, an exception occurrence is a states in application, and respective handlers (H(a)) situation in which standard computation cannot pursue. for se exceptions should recover state environment For each identified computer phase system into stware a known development consistent state. life using figure shown in Fig Sequential 2. For Techniques EXCEPTIONS program execution AND to continue, HANDLERS an extraordinary IN computation THE SOFTWARE is necessary [7]. LIFECYCLE In cycle, order a to class demonstrate exceptions different is defined. kinds For instance, exceptions during that 3.1 Robust Stware A programming language or system with support for ex- exist requirements during stware phase, lifecycle, authorsin propose following to identify we consider exceptions it does a series related simple to examples application involving (E(a)), and purchase to define a Robust stware Exception is ten handling not considered allows has been users part traditionally to signal stware exceptions associated fault tolerance, and with since define handlers [2]. To signal an exception amounts to detecting exceptional situation, interrupting usual pro- not use any for design redundancy. phase However, stware it represents lifecycle, during base which for achieving all book any application-specific form via Internet. handlers. If a client The is authors looking give for asa anparticular example and case Internet an Internet bookshop does store: not if ahave client is requested looking dependability. effort is made to protect application stware from book faults cessing that sequence, may be introduced looking forduring a relevant requirements, handler, and design, n Robustness invoking is de ned it. as extent to which stware can continue to operate item, for a correctly despite Handlers introduction are defined invalid on (or inputs attached [8]. to) Invalid entities, inputs such must as be de ned n book that bookshop is currently can eir unavailable return (application-level list all available exception), books and implementation, or can occur at support level. The in by bookstore same author, could return or inform a listabout or some books or consequence such approach is that appropriate context speci cation. data They structures, include orout contexts range forinputs, one orinputs several exceptions. books from on same same author, topic. or inform These two about alternative books on behaviours same wrong type or topic format, (application-specific handling). in which corrupted inputs, According errors wrong toshould sequencing language, be detected input, a context and recovered and violations may be ais program, lost, also pre-conditions. a can be considered handlers to application-related exception During design phase, intent is to identify all exceptions not it is process, lost apotential procedure, correlation a statement, that might an expression, exist between etc. Handlers states are invoked different when an contexts exception and is how signaled se during should be Upon error detection such invalid input, several optional courses action may be related having to requested design (E(d)), book i.e. in stock. related to chosenduring stware taken: requesting recovered execution new in an input optimised from use way. input associated source, context using or nested last acceptable context. order To default handle to resolve value. meansse to putlimitations, system into aproposed coherent be cation partitioned state toin a terms known consistent architectural state. design In and Internet detailed value, or architecture design phase, or object-interactions. intent is to identify The designlevel handlers related for se to exceptions design (E(d)), shouldwhich recover could appli- furr all exceptions using a pre-de ned In approach state, i.e. aims to to carry specify out forward exceptions, error and recovery, ir and respective n to design. bookstore At example, this level a crashed abstraction server (design-related phenomena exception) could and beanalysed tolerated is byessentially routing related following to requests stware to being handlers, take one in se context steps: in transfer which faults control occur. to Figure statement 1 representlowing proposed signaling approach one (resumption that associates model exception [4]), or discard han- that a backup controls server. application. Design-related exceptions cor- fol- modelled context between signaling statement and one to dling with phases stware lifecycle. For each respond Duringto error implementation states in phase, application intent stware, is to identify and which handler is attached (termination model [4]), or identified phase stware lifecycle, a class exceptions is defined depending on abstraction level (or con- signal a new exception to enclosing context. respective all exceptions handlers related (H(d)) to for implementation se exceptions should application and support in which application is executed recover state application stware into a known consistent (E(i&s)). Implementation-specific handling in Internet text) 2.2 Idealized stware Fault-Tolerant system being modelled Component and analysed. bookstore state. In example addition would to consist, handlers for instance, for design-related in executing As The stware Idealized development Fault-Tolerant progresses, Component new (IFTC) exceptions [8] is area exceptions a garbage collector (H(d)), re whenare also free memory handlers onfor server application-related low. exceptions (H(a)), and handlers associated is identified conceptand thatir was developed respective tohandlers structure specified. execution However, dependable exceptions stware identified (see Fig. at 1). Andifferent IFTC fers phases services can that be with Lemos combinations and Romanovsky exceptions [1] suggest both alsoclasses that re which might have causally may return and timely replies related, to which component might that constraint made a service specification to be be a need treated fortoger combined (H(a&d)). handlers, Examples i.e. handlers design-related that are de- request. ir If a request respective is malformed, handlers. Moreover, component it might signals be exceptions signed to handle are those situations associated in with which, fault fortolerance instance, policies, appli- this case bythat raising rationalisation an interface exception, exceptions orwise might it executes enable robust cation data and design-specific structures, algorithm-level exceptions have fault to be tolerance, addressed and usage request a and single produces handler afor reply. different If an classes internal exception exceptions. data-diversity; toger. for instance, an exception is raised whenever signaling At every an error phase occurs, error stware processing development is activated failure in an re We is agree no majority with voting authors between [1] that diverse exceptions versions are attempt to handle error. If it can be dealt with, normal assumptions have to be revised once system structure is different nature at each phase stware development processing in component resumes; if not, component same stware. In terms Internet bookshop, availability process. We agree also that new exceptions appear during decomposed itself signals and itsbehaviour failure byrefined. an exception. This process revising each development service phase. is one However, we system s believe main that requirementslationships hence among design-related exceptions exceptions, and handlers caused different by server re- failure assumptions, as we progress through stware lifecycle, 2.3 Exceptions might also lead and to Stware refinement Development exceptions crashes phases or aredelays complex in andservice, deservecan furr be handled investigation. transparently The and handlers Lemos and previously Romanovsky specified. [1] describe For example, general an idea application-relatetegratingspecification, exceptions into which stware considers development a sensor to life be cycle ide- server dlers at in each anor phase location. stware development. in- from following client sectionby present redirecting our notion all requests exceptions to an and available hanal, might have to be revised, once sensor failure behaviour is considered. During implementation phase, intent is to identify all exceptions related to implementation application stware and support in which application will During requirements phase, intent is to identify all 33 exceptions related to application (E(a)). At this level be executed (E(i&s)), e.g., operating system. Implementation

3 3. NATURE OF EXCEPTIONS AND HANDLING WITHIN EACH DEVELOP- MENT PHASE 3.1 Exceptions and Requirements Elicitation During requirements elicitation, an activity that is carried out at very beginning stware development cycle, focus developer is on discovering and documenting essential functionality and behavior a (stware) system that does not yet exist. Use case [6] or or goaloriented approaches are very popular for requirements elicitation, since y guide developer in discovering essential services that system under development needs to provide. A use case describes, without revealing details system s internal workings, system s responsibilities and its interactions with its environment as it performs work in serving one or more requests that, if successfully completed, satisfy a goal a particular stakeholder. The external entities in environment that interact with system are called actors. The actor that initiates a use case in order to pursue a goal is called primary actor, actors that system interacts with in order to provide a service are called secondary actors. During requirements elicitation phase developer works at a very high level abstraction. The system is looked at as a black box: only services that system fers and interactions that are necessary to achieve se services are investigated. In this context, we propose to define an exception as follows: Proposition 1 : An exception at requirements elicitation phase (at a level abstraction where system is considered a collection services) represents any potentially occurring exceptional situation E s that could prevent system from providing services it normally provides. Based on our experience, re are two cases exceptions at requirements elicitation phase: 1) context-affecting exceptions E s and 2) service-related exceptions E s. Context-affecting exceptions are situations that change context in which system operates. Certain context changes might require system to suspend some it s normal services for safety reasons, or to provide special exceptional services in order to satisfy stakeholder needs while exceptional situation is in effect. These exceptional services can be seen as handlers for exceptional situation (H s). For example, in an elevator system where safety is main concern, in case a fire outbreak in building (exceptional situation), elevator operator or a smoke detector (exceptional actors) should activate fire emergency mode elevator control stware. During a fire emergency, all elevator cabins are moved to ground floor (handler). Service-related exceptions represent exceptional situations in which completion a particular service or goal may be threatened. Service-related exceptions have many natures: The current system state makes provision a service impossible; Failure secondary actors that are necessary for completion user goal; Failure communication links between system and important secondary actors; Actors violate system interaction protocol, i.e. y invoke system services in wrong order, or at wrong time. If service-related exception puts user in danger, n measures must be taken to put system in a safe state. If service-related exception threatens successful completion service, reliability is at stake. It should n be investigated in consultation with stakeholders if system can recover and meet user goal in an alternative way or provide some form degraded service. Handlers should n be defined that describe interactions between environment and system needed to address exceptional situation (H s). After occurrence any exceptional situation, system should evaluate if encountered problem threatens reliability or safety future service provision. If yes, n a mode switch is necessary. Switching to a different operation mode allows system to signal to environment that services fered by system have changed, and reject any requests for services that cannot be performed with sufficient reliability or safety. 3.2 Exceptions and Requirements Specification During requirements specification, one important activity consists in outlining system interface. At this level abstraction, system under development is still a black box, i.e. no internal components are visible to outside. The focus is on messages that are sent to and from system. Applying ideas idealized fault-tolerant component (see subsection 2.2) to system and actors, we propose to define exceptions at this level abstraction as follows: Proposition 2 : An exception at requirements specification phase E m (at a level abstraction where system is considered a black box without internal structure) is an exceptional message exchanged between system and an actor in environment (to signal an exceptional outcome a service request, or to inform system a significant change in environment that could affect currently provided services), or absence a normal message, or reception a normal message that should not be received at this point according to interaction protocol. More precisely, exceptional messages can occur in 3 cases: 1. If an exceptional situation arises in environment that threatens system safety or reliability certain services, (exceptional) actor that detects situation should notify system with appropriate exceptional message (E m). 2. In order to complete a service, system might request services from secondary actors. If secondary actor cannot provide service, it should notify system failure (or degraded service provision, if some partial result was achieved) (E m). 34

4 3. Likewise, when a service is requested from system, in case where service cannot be provided as advertised, system should notify primary actor with an appropriate exceptional message (E m(out)). Case 1 exceptions are asynchronous messages, since exceptional situation can occur at any point in time. Case 1 exceptions signal occurrence a context-affecting exception (described in section 3.1) to system. Case 2 and 3 exceptions on or hand are synchronous messages, since exception is generated as a result a service request. Ideally, every secondary actor would signal its failure to system by sending it an exceptional message. However, it is dangerous to assume that secondary actors in environment and communication channels are reliable. Hence, sometimes it is necessary to detect failures secondary actors using, for instance, timeouts. Sometimes even reception a normal message can indicate occurrence a service-related exception. For instance, if an elevator receives a message notifying system that elevator cabin is approaching 10th floor, n system might conclude that floor sensor located at ninth floor is broken, if previously received message established that elevator cabin was approaching eighth floor and cabin was moving upwards. Apart from system interface, requirements specification also includes specification conceptual system state. Parts system state, namely that part state that is needed to remember current system mode, to keep track failures secondary actors and to verify adherence to system protocol, can be considered exceptional as well. As long as architecture system is not known, run-time interaction between system components cannot be determined yet. Therefore, a high-level requirements specification usually describes functionality system by specifying how service requests affect conceptual system state. This can, for instance, be done using pre- and postconditions that are attached to (atomic) system operations. The same strategy can be used to describe functionality that should be provided by handlers. 3.3 Exceptions and Stware Architecture During stware architecture phase, system under development is split into high-level components that communicate using well-defined communication protocols. [11] identifies several stware architecture styles, most popular ones being: Client / Server, Layered Architecture, Pipes & Filters, Event-Based Architecture and Blackboard Architecture. Since se architectures use different communication paradigms, exceptions within each architecture are different nature. The following paragraphs discuss nature exceptions within each above stware architecture styles. Client / Server. In a client / server architecture, a client component sends requests to a server component, which executes request and sends a reply back to client. This is exactly situation covered by idealized fault-tolerant component. In this style re are 3 possible situations in which server signals an exception to client: 1) The client s request is malformed or does not conform to server s specified protocol. In this case, server signals appropriate interface exception. 2) The request client could only partially be completed. The server signals partial service to client by means a degraded service exception. 3) The server failed in an uncontrolled way with no guarantees on its internal state. The server signals a failure exception to client. Any handling one above exceptions has to be done in client. Rigorous exception handling requires that a client must provide a handler for each potential exception. In case exception can not be addressed successfully by client, appropriate exception should be propagated. Layered Architecture. In a layered architecture style, stware is partitioned into several nested layers, where an inner layer provides services to outer layer. Similar to client / server style, we propose to use idealized fault-tolerant component ideas within this architecture style. Rigorous exception handling requires that each outer layer handles all potential exceptions signaled by inner layer. In case exception can not be addressed successfully by layer, appropriate exception should be propagated. Pipes & Filters. In a pipes & filters architecture, system is partitioned into several filter components. Each filter reads from its input port a stream data, processes it, and produces a stream data on its output port. Some filters also have a control port that can be used to change way filters processes data. Filter components are connected to each or using pipes. Simple pipes connect output one filter to input anor filter. Complex pipes can connect multiple filters by merging or splitting data flows. In addition to a standard output port, some filters also have an error port. In exceptional situations, filter component can output data to error port. Hence, an exception in pipes & filters architecture is represented by data flowing through an error output port. A pipe can be used to connect an error output port to input or control port some or filter. That filter (and following filters, if any) can n handle exception. Event-Based Architecture. In an event-based architecture, individual components are not statically connected. Instead, a set event types are declared that components can instantiate, in which case all components that expressed interest for that event type receive a notification. Communication is hence anonymous, i.e. receivers an event do not know who sent it. In event-based architecture style, exceptions are represented by event types that are only instantiated to signal occurrence an exceptional situation that needs to be addressed. Any component that is registered to be notified exceptional event can provide handling functionality. Blackboard Architecture. In a blackboard architecture, communication between components is centered around a data repository blackboard. Components observe data posted on blackboard, and as soon as y find data that y can process, y remove data from board, process it, and put result back on board. In a blackboard architecture, an exceptional situation manifests when data on blackboard satisfies a certain 35

5 exceptional condition. Typically, a handler component repeatedly scans data on blackboard, and, if it determines that exceptional condition is satisfied, it executes its handling functionality. In order to accommodate different architecture styles, definition exceptions at stware architecture phase has to be fairly general: Proposition 3: An exception at stware architecture phase (at a level abstraction where stware is partitioned into coarse-grained components that communicate using different communication stlyes) is any exceptional output produced by a stware component to signal to or components occurrence an exceptional situation. The nature exception depends on concrete architecture chosen: Client / Server: An exceptional reply is sent from server to client when a service request is malformed, or when request was only partially completed or failed. Layered Architecture: An exceptional reply is sent from an inner layer to enclosing layer when a service request is malformed, or when request was only partially completed or failed. Pipes & Filter: Data is output on an error port. Event-Based Architecture: An exceptional event is sent. Blackboard Architecture: The data on blackboard satisfies an exceptional condition. Any component that reacts to exceptional output is a handler component. If exception handling is applied rigorously at stware architecture phase, n components become error-containment regions, i.e. modules from which an erroneous state can not spread unnoticed to or parts application. Filho et al. show in [3] how to extend an architecture description language (ADL) with exception flow information. Their approach proposes to map enhanced architecture descriptions to Alloy [5], a formal modeling language and tool. This allows developer to automatically validate conformance architecture to specified exception handling and propagation rules. 3.4 Exceptions and Design During design phase, a solution that implements functionality each individual component is designed. In an object-oriented design (or any or design that provides modules with interfaces and encapsulation capabilities), functionality system is implemented by a set objects that send each or messages. Typically, responsibilities are assigned to objects, and each object n encapsulates state and behavior related to that responsibility. Just like in client / server architecture, each object can be designed according to concepts introduced by idealized fault-tolerant component. It should raise an interface exception if service request is malformed, and return an exception to signal a partial or failed request execution. Proposition 4 : An exception at design phase (at a level abstraction where each stware component has to provide its functionality using a set interacting modules) is an exceptional response propagated out a module to signal fact that an operation could not be completed as requested. An exception could occur in following situations: The caller module s request is malformed or does not conform to callee module s specified protocol. In this case, callee signals appropriate interface exception. The request caller module could only partially be completed. The callee module signals partial service to caller by means a degraded service exception. The callee module failed in an uncontrolled way with no guarantees on its internal state. The callee signals a failure exception to caller. 3.5 Exceptions and Implementation During implementation phase, constraints implementation platform have to be taken into account, e.g. constraints imposed by operating system or hardware. Modern programming languages usually provide a set predefined exceptions to signal violations platform constraints, e.g. ReadOnlyDevice or OutOfMemory exceptions, to program. They are signaled by language run-time support, i.e. libraries that encapsulate operating system services. Proposition 5: An exception at implementation phase (at a level abstraction where each operation provided by a stware design module is composed a set executable statements) is an exception E st signaled by operating system or language run-time when an implementationrelated exceptional situation prevents execution a statement. 4. MAPPING BETWEEN EXCEPTIONS AT DIFFERENT PHASES The previous section has established that exceptions are represented in different ways within each stware development phase. Although nature exceptions changes depending on level abstraction that a developer is working on, re exist interesting relationships between exceptions each phase. Fig. 3 illustrates se relationships. The most obvious mapping between exceptions is topdown. Exceptions and handlers (depicted E and H in Fig.3) at a high level abstraction usually encompass many exceptions and handlers at lower abstraction levels. This is illustrated in Fig. 3 by means arrows pointing downwards. A context-affecting exceptional situation E s is mapped to one or several exceptional messages E m sent by exceptional actors to system in order to notify it context change. Likewise, an exceptional service defined as a handler H s maps to a handler operation H m triggered by exceptional message(s). However, if service consists in multiple interactions between environment and system, only first input-output interaction sequence 36

6 E s H s Exc. Modes E s H s Exc. Modes Requirements Elicitation System = Set Services E m H m N m E m H m N m E m (out) Requirements Specification System = Set Operations Triggered by Messages N c N c (ar) (ar) (d) (d) Stware Architecture System = Communicating Components Legend handled by mapped to E = Exceptions H = Handlers N = Normal Entities H op E st H st N op (ar) N op (d) N op N op H op (ar) H op (d) H op N st E st (ar) N st E st (d) N st E st N st H st (ar) H st (d) H st Detailed Design Component = Set Modules Implementation Module = Set Methods with Statements Figure 3: Mapping Between Exceptions at Different Development Phases is actually a handler operation triggered by an exceptional message. The following interaction steps exceptional service are triggered by normal messages and provided by standard operations (depicted N in Fig. 3). For example, in case a fire outbreak in elevator, fire detector (exceptional actor) sends FireDetected exceptional message to system. The system handles that message by instructing motor elevator cabin to move towards ground floor. Subsequently, ground floor sensor sends a normal message to system when it detects that cabin is arriving at ground floor. This triggers execution normal system behavior, during which system instructs motor to stop. A service-related exceptional situation E s is mapped to zero or more exceptional messages E m (zero if exception is represented by absence or abnormal sequencing normal messages). For each service-related exceptional message, a corresponding handler H m describes first interaction steps involved in handling exception. Subsequent interactions sequences, if any, are most likely triggered by normal messages. If a requested service cannot be provided, n system should raise a corresponding exceptional output message E m(out). The mapping exceptional messages to exceptional communications between components is less straightforward. If a component is responsible for communication with a secondary actor, n it communicates failure actor to or components using exceptions. Therefore, some (but not all) service-related exceptional messages E m are related to exceptional communications at architecture level. It is also possible that new architecture-related exceptions (ar) have to be introduced into system because chosen stware architecture. For instance, in a distributed client / server system, it is possible that a server crashes and cannot be reached anymore. Client components can course define handlers (ar) for such exceptions that try to achieve desired behavior in a different way. For instance, a crashed server can be tolerated by sending an identical request to a backup server. If architecturerelated exceptions cannot be handled by a component in such a way that functionality failing component can be compensated for, n it is impossible to provide service, and hence environment has to be notified problem. This requires addition new exceptional output messages E m(out) at requirements specification level. It is hence possible that exceptions at a lower level abstraction affect higher level! This is shown in Fig. 3 by bold arrows pointing upwards. Similarly to what happens at component level in a client / server setting, exceptions are used by modules within design an individual component in order to signal failure or exceptional outcome a method call to calling module. As a result, some exceptional responses are related to a service-related exceptional message E m or an exceptional communication among components. New exceptions (d) also arise due to chosen design solutions. If handling cannot be done using handler operations H op(d) within component, n exception has to be propagated to or components by means an exceptional (design-related) communication (d). Finally, if problem cannot be handled transparently at architecture level, problem has to be signaled to environment with a corresponding exceptional output message E m(out). Some service-related exceptions E m map even down to an implementation-level exception E st. For instance, a message that is sent to a secondary credit card company actor can raise a CommunicationException when executing statement that tries to contact company server. Therefore, new statement exceptions E st related to specific implementation decisions have to be defined, toger with handlers that address situation. For example, an application executing on a computer might encounter an OutOfMemory exception when trying to allocate a big data structure on an execution platform with memory constraints. Again, if problem cannot be dealt with within design module, appropriate design-level exceptional response should be signaled to caller module, which might result in new architectural exceptional communications, and in rare occasions in new exceptional output messages E m(out), if transparent handling 37

7 implementation platform problem is not possible. 5. POTENTIAL BENEFITS Integrating exceptions into entire stware development life cycle promises many benefits. Separation Concerns. The obvious benefit is clear separation concerns. Handlers make it possible to separate exceptional behavior from normal behavior, and exceptions unambiguously define conditions in which normal processing is interrupted and exceptional processing begins. Separation concerns not only improves readability stware development artifacts, but also facilitates or stware development activities, e.g. debugging. Prioritizing. Separating handlers from normal behavior allows developer to define special policies and priorities for anything that addresses exceptional situations. For example, handlers at requirements elicitation and specification phase can be classified into handlers that ensure system safety or handlers that increase system reliability [9]. If this classification is established, developer can set clear guidelines that specify that, for instance, safety is more important than reliability. Such a decision affects stware development activity as well as run-time execution stware. The project manager could, for instance, decide to spend more development and testing time on safetycritical components. At run-time, safety-related exceptions and handlers can execute with higher priority, i.e. y can interrupt even reliability-related activities. Traceability. The previous section has highlighted relationships among exceptions and handlers at different stware development phases / levels abstraction. Documenting se relationships during development process provides valuable traceability information. It allows developer to propagate high-level decisions down to lower levels abstraction, or, conversely, to understand global exceptional execution context when working on stware entities at lower levels abstraction. 6. CONCLUSION This paper has investigated relationship between exceptions and different phases stware development. We argued that exceptions are different nature depending on level abstraction that system under development is looked at. At highest level abstraction, where system is just composed a set provided services, exceptions are exceptional situations that prevent system from providing normal service. At requirements specification level, where system interface is main focus and system itself still has no internal structure, exceptions are exceptional messages that flow between environment and system. At stware architecture phase, where system is partitioned into a set communicating components, exceptions take form any means exceptional communication among components. During detailed design, where each component is designed as a set communicating modules, exceptions are exceptional response messages sent to signal failure a service provided by a module. Finally, at implementation level, where behavior each module is implemented using a set programming statements, exceptions are pre-defined exceptions raised by libraries or language run-time. We have outlined a mapping between exceptions at different levels abstraction. The mapping is consistent with, but far more complex than one presented in [1]. We also showed that some exceptions at a low level abstraction can require definition corresponding exceptions at a higher level abstraction in case where transparent handling at low level is not possible. Finally, we outlined potential benefits integrating exception handling into entire stware development life cycle. If se benefits are indeed observable when applied to a real stware development project remains to be investigated. 7. ACKNOWLEDGMENTS This research has been partially funded by Natural Sciences and Engineering Research Council Canada (NSERC). 8. REFERENCES [1] R. de Lemos and A. Romanovsky. Exception handling in stware lifecycle. International Journal Computer Systems Science and Engineering, 16(2): , March [2] C. Dony. Exception handling and object-oriented programming: Towards a synsis. In N. Meyrowitz, editor, 4th European Conference on Object Oriented Programming (ECOOP 90), ACM SIGPLAN Notices. ACM Press. [3] F. C. Filho, P. H. da S. Brito, and C. M. F. Rubira. Specification exception flow in stware architectures. Journal Systems and Stware, 79(10): , [4] J. B. Goodenough. Exception handling: Issues and a proposed notation. Communications ACM, 18(12): , December [5] D. Jackson. Alloy: A lightweight object modeling notation. ACM Transactions on Stware Engineering and Methodology, 11(2): , April [6] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. Object-Oriented Stware Engineering: A Use Case Driven Approach. Addison Wesley, [7] J. L. Knudsen. Better exception-handling in block-structured systems. IEEE Stware, 4(3):40 49, May [8] P. A. Lee and T. Anderson. Fault tolerance - principles and practice. In Dependable Computing and Fault-Tolerant Systems. Springer Verlag, 2nd edition, [9] S. Mustafiz, X. Sun, J. Kienzle, and H. Vangheluwe. Model-Driven Requirements Assessment for Dependable Systems. Stware and Systems Modeling, March [10] C. M. F. Rubira, R. de Lemos, G. R. M. Ferreira, and F. C. Filho. Exception handling in development dependable component-based systems. Stware Practice and Experience, 35(3): , [11] M. Shaw and D. Garlan. Stware Architecture: Perspectives on an Emerging Discipline. Prentice Hall,