Let’s say you write a program that, when started, reads its configuration file to know which modules to start-up etc. If that configuration file is missing, an error will probably show up. This is an important situation that must always be handled.
I read a statistic once which said that about 70 % of the code in a typical program is there to deal with corner cases (like check that file is not missing, catch an Exception, check that I don’t divide by 0, check that a person’s age is a positive number etc.).
I don’t believe this (i.e. the 70 % claim) to be very accurate, but then again, a lot of the code that I write contains a lot of ifs that check for valid parameters and stuff like that. I doubt I’m the only one who does this. So that statistic does have some truth in it.
If a big part of a program’s code is represented by these checks, then shouldn’t these cases be represented in UML diagrams ? (like sequence diagrams etc.). I can’t remember if I ever saw such things.
Should I include them in my diagrams ? Will that enlighten or disturb/confuse another programmer who looks at those diagrams ? Would the diagrams then become too big because of this ?
1
INMO, you should define why are you using UML in your situation. If you are providing specification for someone to code from, then you may have to do that. If you want to specify step-by-step flow, use pseudo code not UML diagram.
If you are showing part of a flow as an example, yes, you could show all details (within a page or so). Also, if you have a tool that generates code from your definition then you need to do that.
If you are describing a process flow, then you may want to be generic about such details and represent all validation errors in 1 spot say, by using a comment that would apply to several of operations such as all file reads. The point here is to focus on the main scenarios not the exceptions.
In general, when you add low level details to diagrams, they become hard to read and take away the visual advantage a picture has over text. Also, with the exception of the Class Diagrams, UML diagrams are almost always presented in high level.
Whatever your choice is, follow it across all your diagrams. Consistency is important.
I don’t think so. UML diagrams don’t generally show details that far down. You might outline your plan for exception handling in pseusocode somewhere, but you don’t want to clutter your higher level diagrams with defensive programming details. I think that would be noisy.
2