1. Institute of Computing – UNICAMP - Brazil Modeling and Analysis of Architectural Exceptions Fernando Castor Filho Patrick Henrique da S. Brito {fernando}@ic.unicamp.br {patrick.silva}@ic.unicamp.br{fernando}@ic.unicamp.br{patrick.silva}@ic.unicamp.br Cecília Mary F. Rubira {cmrubira}@ic.unicamp.br FM’2005 Workshop on Rigorous Engineering of Fault-Tolerant Systems REFT’2005, Newcastle upon Tyne, July 19th 2005

2. REFT'2005 - July 19th 20052 Exception Handling Popular mechanism for structuring forward error recovery in software systems Exceptions can be derived incrementally at different phases of development: Requirements Architecture Detailed Design Implementation

3. REFT'2005 - July 19th 20053 Exception Handling Popular mechanism for structuring forward error recovery in software systems Exceptions can be derived incrementally at different phases of development: Requirements Architecture Detailed Design Implementation

4. REFT'2005 - July 19th 20054 Exceptions at the Architectural Level A system’s exceptional activity should be addressed since the early phases of development In recent years, many approaches combining software architecture and exception handling have been proposed There hasn’t been much focus on the description of exceptions at the architectural level This may be required for systems with strict dependability requirements such as commercial applications, control systems, and so on.

5. REFT'2005 - July 19th 20055 An Air-Traffic Control System Example M&C ConsoleG.A.MLocal/Group A.M.ATC ConsoleA.S.O.UO/S E. A. S.NetworkOperating SystemProcessorI/O DevicesAttachments Exceptions Source: Bass, Clements, and Kazman, Software Architecture in Practice, 2 nd Edition, 2003. Exceptions

6. REFT'2005 - July 19th 20056... Some Interesting questions... What does a double-headed arrow mean? What are the exceptions that each component signals and handles? Are there any relevant cause-effect relationships? Is this analyzable?

7. REFT'2005 - July 19th 20057 Problem To describe software architectures so that it is possible to reason about the flow of exceptions at the architectural level

8. REFT'2005 - July 19th 20058 Requirements of the Solution 1. Easy to use (pictorial representation) 2. Integrated with the concept of architectural style 3. Precise (unambiguous) 4. Analyzable 5. Capable of expressing rules of existing exception handling models

9. REFT'2005 - July 19th 20059 Alloy Design Language Lightweight formal method Similar to Z (less expressive but supports automated analysis) Support for complex data structures Declarative Alloy constraint analyzer Easy to use Requirements 3-5

10. REFT'2005 - July 19th 200510 Proposed Framework: Aereal Architecture Description Extended with Exceptions Translation Arch. Description + Exception Flow View “Normal” Architectural Styles “Exceptional” Architectural Styles

11. REFT'2005 - July 19th 200511 Proposed Framework: Aereal Documentation Analysis of stylistic constraints Architecture Description Extended with Exceptions Translation Arch. Description + Exception Flow View “Normal” Architectural Styles “Exceptional” Architectural Styles

12. REFT'2005 - July 19th 200512 Proposed Framework: Aereal Exception flow analysis Architecture Description Extended with Exceptions Translation Arch. Description + Exception Flow View “Normal” Architectural Styles “Exceptional” Architectural Styles

13. REFT'2005 - July 19th 200513 Proposed Framework: Aereal Translation Arch. Description + Exception Flow View Architecture Description Extended with Exceptions ACME Alloy “Normal” Architectural Styles “Exceptional” Architectural Styles

14. REFT'2005 - July 19th 200514 Elements of the Model Components: Signals Raises Encounters Handles SignalsTo CatchesFrom PortMap … Ducts: Signals Raises Encounters CatchesFrom SignalsTo … Exceptions

15. REFT'2005 - July 19th 200515 An Example CoalFeederController AirFlowController Duct1

16. REFT'2005 - July 19th 200516 An Example GENERIC MODEL sig Component { Signals : Exception->Duct, SignalsTo : set Duct, … } sig Duct { Encounters : set Exception, CatchesFrom : one Component … } INSTANTIATION sig AirFlowCtr extends Component {} sig Duct1 extends Duct {} sig AirFlowActuatorTimeout extends Exception {} fact SystemStructure { AirFlowCtr.SignalsTo = Duct1 Duct1.CatchesFrom = AirFlowCtr … } fact ExceptionFlow { AirFlowCtr.Signals= AirFlowActuatorTimeout->Duct1 Duct1.Encounters = AirFlowActuatorTimeout … }

17. REFT'2005 - July 19th 200517 Properties of Interest Basic EH mechanism properties Desirable EH properties Application-specific properties Verified using the Alloy Analyzer Violations of properties generate graphical counter-examples

18. REFT'2005 - July 19th 200518 Examples of Properties Exceptions encountered by a component and not handled or propagated are signaled If a component raises an exception, it must also signal the exception The exceptions encountered by a component are all the exceptions signaled by ducts in the components CatchesFrom set No useless handlers

19. REFT'2005 - July 19th 200519 Example: No useless handlers pred no_useless_handlers() { all C : Component | all D : C.CatchesFrom | D.(C.Handles) in D.(C.Encounters) && D.(C.Encounters)<:(D.(C.Propagates))=D.(C.Propagates) }

20. REFT'2005 - July 19th 200520 Future Directions Model coordinated exception handling Technical report describing the whole model Extend the implementation of Aereal in order to automatically compute the sets of exceptions that are caught and signaled

21. REFT'2005 - July 19th 200521 Thank You! Contact information: Fernando Castor Filho fernando@ic.unicamp.br fernando.castor@newcastle.ac.uk