7.8 Event Diagrams, Logic Expressions, and Logic Diagrams

Exception handling should be used as the last line of defense because the mechanism totally alters the natural flow of control within the program. There are schemes that try to mask this fact, but those schemes are typically not flexible enough to scale to our programs that require concurrency or distribution. In the vast majority of situations where the temptation is to use catchall exception handlers, the logic can be made more robust by solid error handling or through improving the logic of a program. It is often useful to use an event diagram to help identify those components of an application that are critical to an acceptable completion of the application's work. Event diagrams can show which components can be potentially bypassed and which components lead to system failure. In some applications a single component's failure does not necessarily lead to system failure. Where a single component's failure would lead to system failure, then exception handling techniques can be used in conjunction with error handling techniques to provide the failure-is-notan-option feature. Figure 7-6 shows a simple event diagram.

Figure 7-6. A simple event diagram.

graphics/07fig06.gif

We use the event diagram to come up with a scheme to use in exception handling. Figure 7-6 depicts a system that consists of seven tasks labeled A, B, C, D, E, F, and H. Notice that each label is located at a switch. If switches are closed, then the component is functioning; otherwise , the component is not functioning. The terminal point at the left represents the beginning execution and the terminal at the right represents the end of execution. In order for the program to successfully end, a path through functioning components must be found. We can illustrate how this can be applied to our exception handling situation. Lets say that we start the program executing at A. In order for the program to successfully complete, A and C must both function properly. That is, the A switch and the C switch must be closed. In this event diagram both A and C are on the same branch. This means that A and C are executing concurrently. If either A or C fails, then an exception is thrown. The exception handler could possibly start A and C again. However, our event diagram tells us that this operation will be successful if either AC or DE or FBH is successful. Therefore, we design our exception handler to execute one of an alternative set of components (e.g., DE or FBH). There is an OR relationship between AC, DE, and FBH. This means that either set of these components concurrently executing represents success. The simple event diagram in Figure 7-6 indicates how we can approach our exception handler. The expression:

 S = (AC + FBH + DE) 

in Figure 7-6 is often referred to as a logic expression or boolean expression. This expression means that (A and C) or (F and B and H) or (D and E) must successfully execute in order for the system to be in a reliable state. The event diagram can also be used to tell us which combinations of component failure can lead to system failure. For instance, if only the components E and B fail, then the system may still successfully execute if components A and C are functioning. However, if components A, H, and D were to fail, then the entire system fails. The event diagram and the logic expression are useful tools for describing concurrently dependent and independent components. They are also good for determining how to approach processing in the exception handler. For example, from Figure 7-6, we can use:

 try{    start(task A and B) } catch(mysterious_condition &E){    try{       if(!(A && B)){          start(F and B and H)       }    }    catch(mysterious_condition &E){       start(D and E)    } }; 

This kind of strategy aims at improving software reliability. Also note that the concurrency and opportunities for fault tolerant planning can be seen in the traditional logic diagram shown in Figure 7-7.

Figure 7-7. A logic diagram showing three AND gates OR'ed with OR gates to obtain the success of the system.

graphics/07fig07.gif

Figure 7-7 shows three AND gates and how they are OR'ed together to get to the S that represents the success of the system. The event diagram in Figure 7-6 and the logic diagram in Figure 7-7 are examples of simple techniques that can be used to visualize the critical paths and critical components in a piece of software. Once the critical paths and components are correctly identified, the developer must design software responses in case any of the critical components fail. If the termination model is used, then the exception handling does not attempt to resume execution at the point where the exception occurred; rather, the function or procedure where the exception occurred is exited, and steps are taken to put the system in as stable a state as possible. However, if the resumption model is used, the condition(s) that created the exception are either corrected or adjusted and the program resumes from the point where the exception occurred. It is important to note that the resumption model carries with it several challenges. For example, if we have a succession of nested procedure calls such as:

 try{    A calls B      B calls C        C calls D          D calls E            E encounters an anomaly that it cannot cope with } catch(exception Q) { } 

and an anomaly occurs in E and an exception is thrown, then there is the issue of what to do about the call stack. There are also object destruction issues and suspended return values that need to be resolved. What happens if C and D are recursive? Even if we fix the condition that caused the exception in procedure E, how can we return the program to the state it was in just prior to the exception? We will have to keep stack information, object construction and destruction tables, interrupt tables, and so on. This requires a lot of overhead and cooperation between the callee and the caller. These issues represent only the surface. It is because of the complexity of implementing the resumption model and the fact that large-scale systems can be developed without it that the termination model was chosen for C++. In The Design and Evolution of C++ , Stroustrup (1994) presents a complete rationale about why the ANSI committee eventually selected the termination model of exception handling. While the resumption model does present challenges, if the reliability and the continuity of the software are critical enough, then the effort to implement a resumption model will have to be expended and the exception handling facilities in C++ can be used to implement a resumption model.



Parallel and Distributed Programming Using C++
Parallel and Distributed Programming Using C++
ISBN: 0131013769
EAN: 2147483647
Year: 2002
Pages: 133

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net