Exception/Error cataloging

[son-of-sargasso]

I'm not sure where I'm going with this one, so bear with me please.

We've got a whole gazilliwump of code here, nicely reverse engineered to the structural level, nicely documented and all.  I've now got a need to somehow catalog all the errors and exceptions raised by the all the methods.  I don't want to go to the lengths of modelling the entire system behavior, I just need a comprehensive model of what exceptions and errors are raised by which method and hence which class and hence which component.

There are several options that leap to mind including using tagged values or the scenarios/requirements view.  We can get funding for doing the work to get this into the system model, but I'm unsure as to the "best" way to model this.  Don't worry about how to get it into the model (we will sed/grep the entire code and write an automation thingo.)  The question is how best to represent the catalogue in the model.

Anyone got any good ideas or prior expertise?
bruce

[Paolo F Cantoni]

Hi bruce,

Don't know whether the idea is good, but...  (if you ARE going the automation route - and I can't see any other viable route)

I'd create classes for each exception type I came across, create a raisedException (see UML superstructure) association between the raising class and the exception class.  In this case, I'd use EA's Link to Element Feature to join the association to the method in the raising class. The handling code would be an ExceptionHandler and have the exceptionType association to the the exception class.

HTH,
Paolo

[son-of-sargasso]

This might work.  I'll give it try and get back.

bruce

[Geert Bellekens]

bruce,

In fact the relation raisedException is between the operation (behavioralfeature) and the exception, so technically a relation between the owning classifier and the exception type would not be entirely correct.
Besides that, if you use the "link to element feature" feature of EA you are also deviating from the one an only true UML path  

In stead I would represent the raisedException relation as a tagged value on the operations. Use refGUIDList to be able to select a number of exceptions thrown by this particular operation.

To enable usuability you can write a little "navigator" addin that allows the user to find/select the exceptions thrown by the operation. (the default EA behavior isn't really usefull for that purpose)

The advantage of this approach is that you keep closer to the UML spec, and your not using the EA specific "link to element feature" thingy, so in case you ever would need to migrate to another case tool...
And tagged values are easier to add then "link to element feature" things. (you don't need to update the database directly)

The downside is that it is less visible on diagrams.

My 2.5 cents

Geert

[Paolo F Cantoni]

Geert is, of course, right...

I alluded to the relationship being between the raising method and the exception class - but wasn't as explicit as Geert (I left it as "an exercise for the reader" to check out the UML Superstructure document).

However, since it's all automation - why not do both?  The problem as I see it is that whether we like it or not there is a derived/implicit relationship between the two classes.   The implicit relationship is the union of all the method level Associations.  Depending on the granularity you require, you could add a relationship between EACH method and the raised exception class or a single aggregate relationship between the two classes.

My experience is that VISUALIZING the relationships makes it clearer for viewers - what is going on.

Paolo

[son-of-sargasso]

I am now using (after a few days experimentation) BOTH methods (more or less).  

I realize that this is not de rigeur UML but this appears to get the job done.  So far, we have loaded about  85% of the exceptions, the auto load turned out to be a lot simpler (or maybe a lot quicker to build) than I expected and the person who did it, did it in less than a day - I expected about 3-5 days.  Now I have the problem of disappearing the approved budget   .

Having the exceptions appear as classes on diagrams really shows up the inconsistencies and highlights why the user-beings were complaining.  Using the tagged value approach makes a lot easier to generate proposed changes and to document the new "wholistic" view.  

I had not believed that the situation was so much of a problem until we took this exercise on.  The biggest issue is "misdirecting/misleading" error messages, followed closely by the "confuse the user entirely by displaying a techno-cryptic error message".  We are now classifying categorizing the exception-exceptions (as well as manually loading the remaining beasts - several hundred).

It is quite amazing (to me at least) that a bit of "bent" UML and EA was able to highlight the core issues so easily and quickly.  With obviously, the help and ideas of the two current meister-gurus.

So thanks Paolo and Geert!

Now I've got to get back to that problem of the excess budget ... (hmmm, and it appears to be Friday ... ) ... cheers!

bruce

[Paolo F Cantoni]

[size=18]...[/size]
We are now classifying categorizing the exception-exceptions (as well as manually loading the remaining beasts - several hundred).
[size=18]...[/size]

Hi bruce,

Why did you strike out classifying?  I would also have but that's because I have terminological model that says you reserve the use of the word classifying to provide a Linean classification for a object within a classification dimension:  Bolt, steel, 3/4", whitworth (Remember those?),

Contrast this with how an item may be simultaneously have more than one categorisation within the same categorisation space.  (Also, classification is multi-leveled whereas categorization is typically only single level...)

Just interested...

Paolo

[Paolo F Cantoni]

[size=18]...[/size]
I realize that this is not de rigeur UML but this appears to get the job done.
[size=18]...[/size]  
It is quite amazing (to me at least) that a bit of "bent" UML and EA was able to highlight the core issues so easily and quickly.
[size=18]...[/size]

It's NO surprise to me...

As I said above - it's about being able to VISUALIZE the nature and extent of the problem.

I believe (know) that this type of modelling can be used to solve more general problems.

Don't let technical purity¹ get in the way of effective communication.

Paolo
¹In any case, I'd submit that this isn't even "non-de rigeur" UML.  It's just UML hasn't got there yet...  The basic relationships were direct from the Superstructure.  The implicit relationships are from first principles.
However, sacrificing technical purity is NOT a permission to generate incorrect models.

[son-of-sargasso]

re classifying:
Well, you pretty well hit the nail(6", galv., jolthead) squarely on the head.

I was intimating that we are not embarking on a development of a structural model of the exceptions themselves, merely loosely sticking them in one or more buckets.

bruce

p.s.  isn't terminology wonderful, consider "to draw a nail"  - are we designing it, manufacturing it or removing it...

[Geert Bellekens]

bruce,

I don't think you compromised on UML purity. After all UML defines a relation between operations and Exceptions, and that is exactly what you represented in your model.
The only sad thing is that EA doesn't support this UML relationship, so you had to figure out a way to get it into EA.

And besides, a wise man once said: The “purity” of any method should never rise above the purpose of a project

Geert