3.4 The Aereal Framework
3.4.2 Specifying the exception flow view
An exception flow view comprises the components from the architecture description that signal or catch exceptions and exception ducts connecting these components. It adhe- res to one or more exceptional styles, depending on the normal styles the architecture description uses. Each element in an exception flow view is annotated with information about exceptions. All the elements in an exception flow view are instances of types that
3.4. The Aereal Framework 61
1 import families \ S i n g l e E x c e p t i o n F a m . acme ; 2 import families \ C l i e n t A n d S e r v e r F a m . acme ;
3 Family E x c e p t i o n a l C l i e n t A n d S e r v e r F a m extends S i n g l e E x c F a m , 4 C l i e n t A n d S e r v e r F a m with {
5 ...
6 Component Type E x c e p t i o n a l C l i e n t T extends E x c e p t i o n a l C o m p o n e n t with { 7 Port catchesPo r t : C a t c h e r P o r t T = new C a t c h e r P o r t T ;
8 invariant size ( self . ports ) == 1;
9 }
10 ...
11 Component Type E x c e p t i o n a l S e r v e r T extends E x c e p t i o n a l C o m p o n e n t with { 12 Port signalsPo r t : S i g n a l e r P o r t T = new S i g n a l e r P o r t T ;
13 invariant size ( self . ports ) == 1;
14 }
15 ...
16 Connector Type E x c e p t i o n a l C S C o n n T extends E x c e p t i o n a l C o n n e c t o r with {} 17 invariant Forall c1 : E x c e p t i o n a l C l i e n t T in self . componen ts |
18 Forall c2 : E x c e p t i o n a l S e r v e r T in self . components | 19 Forall conn : E x c e p t i o n a l C S C o n n T in self . connector s | 20 (( attached ( conn , c1 ) AND attached ( conn , c2 ) AND
21 connected ( c1 , c2 ) ) -> ( s a t i s f i e s T y p e ( c1 , ClientT ) AND 22 s a t i s f i e s T y p e ( c2 , ServerT ) AND
23 ( Exists normalConn : CSConnT in self . connectors |
24 attached ( normalConn , c1 ) AND attached ( normalConn , c2 ) ) ) )
25 << label : string = " OK . " ; errMsg : string = " Problems . " ;>>;
26 ...
27 }
Figura 3.7: Partial definition of the Exceptional Client/Server style.
the exceptional styles to which it adheres define. Aereal represents exception flow views as ACME systems.
The element types that SingleExcFam defines declare properties that are used to asso- ciate information about exceptions to architectural elements. In the exception flow view, instances of these types assign values to these properties. This information is taken into account during exception flow analysis (Section 3.4.4). Table 3.2 lists the properties de- clared by the element types of SingleExcFam and informally describes their semantics. All the properties in the table, except for the last one, are declared by ExceptionalComponent and ExceptionalConnector. Element types CatcherPortT and CatcherRoleT only declare properties handles, catches, and propagates. Element types SignalerPortT and SignalerRo- leT only declare properties raises and signals. Only instances of SignalerPortT use property catcherPorts.
In the exception flow view, values assigned to properties declared by exceptional com- ponents and exception ducts add up to the values assigned to the homonym properties declared by associated ports and roles, respectively. For example, if an exceptional com- ponent C assigns value {RemoteException} to property raises and signaler port P of C assigns value {IOException} to its homonym property, it is assumed that the value of property raises for P is {RemoteException, IOException}. This semantics makes it
3.4. The Aereal Framework 62
Tabela 3.2: Properties employed by the exception flow view to associate information about exceptions to architectural elements.
Property Description
signals The set of exceptions signaled by an architectural element. Aereal automatically computes signals from the values assigned to raises, handles, and propagates for all the elements in an exception flow view. Optionally, it is possible to manually specify a set of exceptions. In this case, Aereal verifies if the element actually signals the exceptions during exception flow analysis. catches The set of exceptions caught by an architectural element.
Similarly to signals, computed automatically by Aereal. handles The set of exceptions that an architectural element handles.
In this case, “handles” means that the handler for the exception does not end its execution by raising an exception. After handling, normal execution is resumed.
propagates This property is a variation of handles where the handler ends its execution by raising an exception. The propagates property specifies a cause-consequence relationship between an exception that an element catches and an exception that it signals. raises The set of exceptions that an element raises. Since only external
exceptions are taken into account by Aereal, raises is a subset of signals
catcherPorts The set of ports of type CatcherPortT associated to a port of type SignalerPortT. Exceptions caught by these catcher ports and not handled or propagated by the element are signaled through the associated signaler port. If catcherPorts is left unspecified for a given
signaler port, Aereal assumes that this port is associated to all the catcher ports of the element.
possible to specify that different ports of the same component manipulate different sets of exceptions while retaining the ability to specify a common denominator. A similar rationale applies to exception ducts and roles.
Usually, unlike exceptional components, exception ducts are connectors that do not exist in the normal architecture description. They are orthogonal to “regular” connectors, in the sense that they do not necessarily follow the same rules for message/data passing and transfer of control. For instance, an exception duct between components that adhere to the Publisher/Subscriber style may or may not indicate transfer of control, depending on the semantics of the application. In our approach for exception flow analysis, this is not of utmost importance because we are not modeling system behavior. Moreover, even though a set of components in a Publisher/Subscriber architecture may communi- cate through a single normal connector, there may be several exception ducts between these components, depending on how the components may fail and which is responsible for handling which exceptions.
3.4. The Aereal Framework 63
The IB system’s exception flow view only uses the Exceptional Client/Server style, de- fined by ExceptionalClientAndServerFam, since only the Client/Server style is used in the architecture description. It is important to notice, however, that various architectural styles could have been used.
Figure 3.8 shows part of the ACME definition of the IB system’s exception flow view. This ACME system adheres to the Exceptional Client/Server architectural style (Lines 2-3). Line 9 specifies that the InternetBankingServer component signals an exception cal- led RequestNotProcessedException. This exception is raised by the component itself (Line 8). Lines 14 and 15 state that exeception duct ExceptionalCSConnT0 catches exceptions of type RequestNotProcessedException and signals exceptions of type RemoteException, respectively. Furthermore, Lines 16-17 specify that ExceptionalCSConnT signals Remote- Exception as a consequence of catching RequestNotProcessedException.
1 import families \ E x c e p t i o n a l C l i e n t A n d S e r v e r F a m . acme ;
2 System E x c e p t i o n a l N e t b a n k i n g : E x c e p t i o n a l C l i e n t A n d S e r v e r F a m = 3 new E x c e p t i o n a l C l i e n t A n d S e r v e r F a m extended with { 4
5 Component I n t e r n e t B a n k i n g S e r v e r : E x c e p t i o n a l S e r v e r T = 6 new E x c e p t i o n a l S e r v e r T extended with {
7 Port signalsPo r t : S i g n a l e r P o r t T = new S i g n a l e r P o r t T exten ded with { 8 Property raises : Set {} = { R e q u e s t N o t P r o c e s s e d E x c e p t i o n };
9 Property signals : Set {} = { R e q u e s t N o t P r o c e s s e d E x c e p t i o n };
10 };
11 };
12 Connector E x c e p t i o n a l C S C o n n T 0 : E x c e p t i o n a l C S C o n n T = 13 new E x c e p t i o n a l C S C o n n T extended with {
14 Property catches : Set {} = { R e q u e s t N o t P r o c e s s e d E x c e p t i o n }; 15 Property signals : Set {} = { R e m o t e E x c e p t i o n };
16 Property propagates : Sequence <> =
17 < R e q u e s t N o t P r o c e s s e d E x c e p t i o n , R e m o t e E x c e p t i o n >;
18 };
19 ...
20 };
Figura 3.8: Exception flow view of the IB system.