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 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 19 th 2005 REFT'2005 - July 19 th 2005
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 REFT'2005 - July 19 th 2005 2
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 REFT'2005 - July 19 th 2005 3
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. REFT'2005 - July 19 th 2005 4
An Air-Traffic Control System Example M&C Console ATC Console Exceptions G. A. M Exceptions Local/Group A. M. Exceptions A. S. O. U Exceptions O/S E. A. S. Exceptions Network Operating System Processor I/O Devices Source: Bass, Clements, and Kazman, Software Architecture in Practice, 2 nd Edition, 2003. REFT'2005 - July 19 th 2005 Attachments 5
. . . 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? REFT'2005 - July 19 th 2005 6
Problem To describe software architectures so that it is possible to reason about the flow of exceptions at the architectural level REFT'2005 - July 19 th 2005 7
Requirements of the Solution 1. 2. 3. 4. 5. Easy to use (pictorial representation) Integrated with the concept of architectural style Precise (unambiguous) Analyzable Capable of expressing rules of existing exception handling models REFT'2005 - July 19 th 2005 8
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 REFT'2005 - July 19 th 2005 9
Proposed Framework: Aereal “Normal” Architectural Styles “Exceptional” Architectural Styles Arch. Description + Exception Flow View Translation REFT'2005 - July 19 th 2005 Architecture Description Extended with Exceptions 10
Proposed Framework: Aereal “Normal” Architectural Styles “Exceptional” Architectural Styles Arch. Description + Exception Flow View Translation Architecture Description Extended with Exceptions • Documentation • Analysis of stylistic constraints REFT'2005 - July 19 th 2005 11
Proposed Framework: Aereal “Normal” Architectural Styles “Exceptional” Architectural Styles Arch. Description + Exception Flow View Translation Architecture Description Extended with Exceptions • Exception flow analysis REFT'2005 - July 19 th 2005 12
Proposed Framework: Aereal “Normal” Architectural Styles ACME “Exceptional” Architectural Styles Arch. Description + Exception Flow View Translation Architecture Description Extended with Exceptions Alloy REFT'2005 - July 19 th 2005 13
Elements of the Model q Components: Signals üRaises üEncounters üHandles üSignals. To üCatches. From üPort. Map ü… q Ducts: Signals üRaises üEncounters üCatches. From üSignals. To ü… ü ü q Exceptions REFT'2005 - July 19 th 2005 14
An Example Coal. Feeder. Controller Duct 1 Air. Flow. Controller REFT'2005 - July 19 th 2005 15
An Example GENERIC MODEL INSTANTIATION sig Component { Signals : Exception->Duct, Signals. To : set Duct, … } sig Duct { Encounters : set Exception, Catches. From : one Component … } sig Air. Flow. Ctr extends Component {} sig Duct 1 extends Duct {} sig Air. Flow. Actuator. Timeout extends Exception {} fact System. Structure { Air. Flow. Ctr. Signals. To = Duct 1. Catches. From = Air. Flow. Ctr …} fact Exception. Flow { Air. Flow. Ctr. Signals= Air. Flow. Actuator. Timeout->Duct 1. Encounters = Air. Flow. Actuator. Timeout …} REFT'2005 - July 19 th 2005 16
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 REFT'2005 - July 19 th 2005 17
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 Catches. From set No useless handlers REFT'2005 - July 19 th 2005 18
Example: No useless handlers pred no_useless_handlers() { all C : Component | all D : C. Catches. From | D. (C. Handles) in D. (C. Encounters) && D. (C. Encounters)<: (D. (C. Propagates))=D. (C. Propagates) } REFT'2005 - July 19 th 2005 19
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 REFT'2005 - July 19 th 2005 20
Thank You! Contact information: Fernando Castor Filho fernando@ic. unicamp. br fernando. castor@newcastle. ac. uk REFT'2005 - July 19 th 2005 21
Скачать презентацию Institute of Computing UNICAMP — Brazil Modeling
b994b5c3b4d80abc3960591c7365c4b8.ppt