Modelling of Exceptions

One method of handling exceptions in UML (Tau) is based on state charts. Using this approach may cause one minor problem that must be solved – receiving signal is acceptable only by communication port. Hence catching an exception is equivalent to receiving a signal, which parameter is an instance of a class which extends an Exception super class. Therefore the class receiving signal must be an active class because state charts can be added in Tau Generation2 only to active classes. Further- more this class (lets call this class A) must have a communication port to class which method is invoked (lets call this class B). If so class B must also have a communication port to class A in order to enable communication. The port of class B is used to send a signal which is carrying information about exception, which occurred while port of class A is used to receive this signal. In this approach we have to think about “future users” (programmers and software developers who wants to use our class) of designed class. Although this approach is not what we have used to using programming languages it seems that it provides simple and elegant way to solve the problem of handling exceptions in UML.

Solution proposed here is: each class that “wants” to invoke methods of other classes which may throw an exception should be encapsulated by another class (the same in each case) which has a communication port to announce the exception occurrence. This can be modelled on class diagram as generalization-specialization (designed class extends the super class which has required port) or composition (designed class is a part of the class which has required port) relationship between those two classes. In the same time each class which has a method or methods which can throw an exception must be encapsulated by an analogical class. This class has a port which allows to send an exception to announce the fact that exception occurred. This approach is described in Figure 5 – each class that handles exceptions should extend CatchExceptionClass (in the example below it is CatchExampleClass), whereas each class that has method/methods throwing exceptions should extend ThrowExceptionClass (ThrowExampleClass in the example). Instances of these classes communicate with each other by sending/receiving signal ExceptionSignal which is a part of Throwable interface.

As mentioned before solution proposed is based on sending/receiving signal which is carrying information about exception which occurred. Hence this signal should have one parameter – instance of a class that represents an exception – Exception class and its subclass all indicates conditions that a reasonable application might want to catch, Figure 6.

Modelling of sample handling in example class ThrowExampleClass could be realized by adding state chart to method method(Integer) in Tau. Example method throwing an exception is method (cf. Figure 7).

Figure 5. Classes, interfaces signals realizing exception handling

Figure 6. Part of class hierarchy responsible for handling exceptions

The concept of the example is: when invoking method(Integer) we pass integer parameter. If the parameter value is below zero exception is thrown – signal carrying exception information is sent. The diagram above is easy to understand however in terms of Tau is not proper. Transition between two states can be activated only by receiving signal. If so some signal should be received between states Initialize and Return. Unfortunately we do not know what kind of signal, who/what should send it. and we can not provide such a signal if we want to keep state chart clear. This is the only disadvantage of this approach, which solution should be taken into consideration in future research. In approach described (based on state chart diagrams) behaviour of the class which handles the exception may be modelled as described in Figure 8.

Figure 7. Throwing an exception - example state chart diagram

Figure 8. Handling exception - example state chart diagram

Simulating try-catch block which is well known in programming languages, such as Java or C++, is being performed by receiving signal ExceptionSignal. The only

disadvantage is that we can not emphasise that the signal can be received only if we invoke method of class ThrowExceptionClass before. Unlike previous diagram this diagram is syntactically and semantically correct.

Another approach to the problem could be modelling of whole exception-catching structure inside only one state-machine object. In this way we can bypass the problem around executing correct exception handling operations.

The block of exception catching could be defined here as:

x a block of operations, also with calling another external operations,

x a state machine implementation inside another state (nested states). This

structure can be created in the Telelogic Tau with utilisation of “Internal state machines”.

We can also use standard history-states to memorise an exit point, after an excep- tion has been thrown.

The hierarchy of exceptions could be directly passed to hierarchy of class interfaces, deriving from Throwable. One of these interfaces will be implemented by a class, which uses concrete type of exceptions. See example in Figure 9.

Figure 9. Throwable interfaces and exception signal ports modelling – example class diagram

The problem, which need attention is how to call correct exception handling operation – depending of an exception type. That operation could be placed on any other operation body, when the present operation was called from, according calling level. It is necessary do design a special construction, and use it on each level of sub- operation calling. This structure will consider calling operation return status, and depending of the result of, it will perform one of the following actions:

x it will continue execution after returning of called operation block (will

execute finally block or will go on with further code execution when no finally block),

x it will process an exception handling,

x it will pass an exception handling outside when an exception type is incorrect

(does not fit to a catching one).

For modelling of presented activity we can use an interface object linked to another interface objects thanks to generalisation/specialisation relation. Each interface will be equipped with exception signals. On the diagram in Figure 10 each exception thrown inside method2 () is being considered outside. method2 () can also include her own exception consideration mechanism.

Figure 10. Internal exception consideration mechanism modelling

All exceptions being generated inside internal state ExceptionBracketl (see Figure 11) and not caught will be redirected into calling operation code. The implemen- tation of ExceptionBracketl could be set as shown in Figure 12.

Thanks to usage of this notation we can recognise types of an exception caught – on each level of call-stack. Together with ability of that recognition we can redirect uncaught exception processing to another operation, which the current operation has been called from. In addition we can implement in the model a programming language “finally” block – also on each level.

Figure 12. Modelling an exception throwing method

4. Conclusions

Exceptions and handling of exceptions in UML are discussed in this paper. The question of exceptions is very important in computer-based systems. However excep- tion handling is a complicating factor in the design of these systems. Writing programs that include complete and proper exception handling is much more difficult (two to three times [4]) than writing code that is only supposed to work.

Exception handling is not discussed in UML widely. State diagrams and activity diagrams seem to be appropriate tools for exception modelling. State diagrams are examined in these paper. The research is expected to be continued. Activity diagrams will be the next step in the research, too.

Modelling exception handling in UML using approach based on state charts causes some minor problems but give easy to understand and elegant solution. In current version of Tau Generation2 we can precisely describe exceptions thrown by single method but:

x we are unable to model when exception is thrown,

x how to handle the exception in operation body.

In this paper we described approach based on state charts which solves these problems. The only disadvantage of the approach is that in one case state chart diagram which is linked to operation is not correct in terms of Tau. This cause that part of the model which uses the approach is not possible to simulate which is important feature of Tau. Solving this problem will be taken into consideration in future research.

In the alternative method we can base on distinguishing exception type carried by signal ignoring class hierarchy for exceptions which was proposed earlier.

The alternate way of solving problem of handling exceptions in UML is approach based on activity diagrams. Unfortunately in current version of Tau it is not possible to add such a diagram to operation. We are sure that such feature is very important and will soon be added to Tau to enable possibility of modelling handling exceptions. This is also a part of our future research as activity diagrams give easy and elegant way to design operation body.

References

[1] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1998.

[2] PA. Buhr, W. Y.R. Mok, Advanced exception handling mechanisms, IEEE Transactions on Software

Engineering 26(9) (2000), 820-836.

[3] M. Campione, K. Walrath, A. Huml, Java Tutorial. A Short Course on the Basics, Sun Microsystems, 2001.

[4] B. P. Douglass, Real-Time UML. Developing Efficient Objects for Embedded Systems, Addison-Wesley, 1998.

[5] R. Klimek, P. SkrzyĔski, M. Turek, UML i Telelogic Tau Generation2. Materiaáy dydaktyczne (in Polish), 2005.

[6] D. E. Perry, A. Romanovsky, A. Tripathi, Current trends in exception handling, IEEE Transactions on

Software Engineering 26(9) (2000), 817-819.

The ISMS Business Environment