Re: OCL: dealing with exceptions

Date view Thread view Subject view Author view Attachment view

From: Andreas Roth (
Date: Thu 23 May 2002 - 22:43:28 BST

We are currently working on specifying and verifying (parts of) the Java
Collections Framework with UML/OCL in the KeY project
( Specifying operations that close to an
implementation, it is obvious that we need to specify if (and which)
exceptions are thrown. Here is a sketch of our approach:

(1) What UML/OCL can do:

A UML class E can (following the UML standard) be stereotyped by
<<exception>> to indicate that it is an exception. An association
'throws' between a class C and E can be drawn to express the fact that
instances of C can throw instances of E. Let the association end at E
have the role name 'excThrown' and let it have the multiplicity '0..1'. 

Using that class diagram, we can express with OCL that an operation op
in C throws an exception of Type E, simply by saying:

  context C::op
  post:   self.excThrown->size=1 

To be more precise, one must also specify that 'result' is undefined,
because the result of a method call is usually not defined when an
exception is thrown; but this depends on the semantics of the exceptions
you want to use...

(2) Remark:

If (e.g.) Java is used as target implementation language of the
development process, all classes in the class diagram are subclasses of
'Object' and all exceptions inherit from 'Throwable'. Thus, only one
association 'throws' between 'Object' and 'Throwable' is needed (with
'excThrown' as role name and with a multiplicity '0..1' at the
association end of 'Throwable') to be able to specify the throwing of
exceptions for every operation in the class diagram.

(3) Abbreviations: 

It is certainly inconvenient to put an exception class and an
association in every class diagram and use 'self.excThrown->size=1 and
result=undefined' instead of a more intuitive expression.

Thus, we suggest to use a 'detailed UML diagram' where at least one
exception class and the mentioned 'throws' association(s) are always
implicitly present. Additionally, we suggest to use an abbreviation for
'self.excThrown->size=1 and result=undefined', say 'self.excThrown()'.

Often in detailed specifications, we need to determine if a certain
exception type E is thrown. We could say 'self.excThrown() and
self.excThrown.oclIsKindOf(E)', but it is certainly more convenient to
use 'self.excThrown(T)' as abbreviation for that.

An example: to describe that an exception ArithmeticException is thrown
in the case of a parameter div being 0, we put:

  post: div=0 implies self.excThrown(ArithmeticException)

Note that, for a complete operation specification, we must specify for
the other (non-exceptional) cases that no exception is thrown, using
'not excThrown()'.

(4) Literature:

Other approaches on specifying exception behavior with UML/OCL I have
found in literature: 

- N.Soundarajan and S.Fridella: 'Modeling Exceptional Behavior' in the
UML 99 proceedings. They try to introduce additional 'post' constructs
for each possibly occurring exception. It seems to be difficult to
express more complex exception conditions using that approach. And it is
a real extension of OCL, while our approach just uses native UML/OCL
(and simplifies matters by using intuitive abbreviations).

- Booch et al.'s UML User Guide tries to specify the throwing of
exceptions by UML usages with stereotype <<send>>. However, usages are
not accessible from OCL.

Finally there will be my diploma thesis on the specification of the Java
collections framework with the KeY system where I try to address the
problem of 'implementation close' specification with UML/OCL in a
broader context. We'll hopefully be able to provide an English version
within the next two months that will be available at

/Andreas Roth

> How can I use OCL to specify the conditions under which a particilar
> exception is thrown by an operation? I have looked at the OCL
> specification and there seems to be no way to do it.
> I am looking for a way to specify exceptions that will type-check.
> Any references to information about this topic are greatly appreciated.
> Thanks,
> Brian

Date view Thread view Subject view Author view Attachment view