Use Case Map

A UseCaseMap is the weaving of multiple UseCase threads into a tapestry.

On CritiqueOfUseCases, I babbled that

Consider a system to be a volume in a discrete space. A discrete space is built out of indivisible quantized partitions, like pixels on your screen. It's discrete because your computer is. It's that Turing guy again..

If you consider that, then each feature, or UserStory, is like a point inside this volume. A UseCase is like a path through the volume. A diagram is like a surface inside this volume.

A UseCaseMap, then, adds an extra dimension to the one-dimensional UseCases. (*)

The very simplest UseCaseMap is purely linear and looks very much like this:

      r1
   @__________|
          r2  |

Where @ is the start of the use case, | is the end of the use case and r1 and r2 are responsibilities of the use case.

This would (maybe) represent a UseCase that looked much like this for, say, someone hitting <ESC> on her keyboard:

 Actors: User, keyboard, OS
 Precondition: The keyboard is in its default state (all keys up)
 Triggering event: User presses <ESC>

 r1. Keyboard sends an <ESC> make message to the OS.

 r2. OS beeps.

 Postcondition: The <ESC> key is currently down.
 Resulting event: none.

The @ (which is really a solid dot) is the precondition and triggering event all in one. The | is the postcondition and resulting event all in one. The actors come into play during the bound map (see below).

A more complex example would look something like this:

                _____|
     r1        /  r4 |
 @____________/
          r2  \_____|
                 r3 |

The fork is an or-fork. That is, one of r3 or r4 will be executed.

http://www.usecasemaps.org can likely tell you more about the notation than I could. UseCaseMaps? look like squids to me.

A bound use case map or, simply, bound map is a UseCaseMap layered on top of a non-empty set of components. For example, if A, B and C are components:

                 +---------+
                 |    B    |
    +----+       |   ______|__|
    |  A |       |  / r4   |  |
    |    |       +-/-------+
    |r1  | +------/-----------+
 @__|____|_|_____/   C        |
    |    | | r2  \            |
    +----+ |      \___________|___|
           |         r3       |   |
           |                  |
           +------------------+

The responsibilities r1 through r4 have been bound to components here.

(*) Actually, a UseCase is probably more than one-dimension. However, just note that there is a total ordering between the dimensionalities of { UserStory, UseCase, UseCaseMap, the whole system }.

-- SunirShah

---

I don't see much benefit in drawing UseCaseMaps?. They smell greatly of BigDesignUpFront because I don't know what components I'll need. And if I misattributed r2 to component C instead of component A, refactoring the code requires changing the UseCaseMap. Moreover, I won't really know until I write the code.

They do provide a greater dimensioned slice of the system, but that should come after it's written, not before. This is very abstract, and AllAbstractionsLie.

As a benefit, though, you can tie various UseCaseMaps? together into a ScenarioCluster and you can show interactions between various UseCases here. But, that's tying the requirements down pretty solidly which assumes requirements are correct.

Another benefit proposed is ease of using formal methods and simulation to determine whether requirements are correct and consistent, and high-level design decisions aren't faulty (e.g. by providing race conditions). Well, requirements are going to be incorrect and inconsistent as a matter of course anyway. So, if you need a prototype to discover this, you might as well make your prototype your first iteration. It's cheaper.

As for race conditions or high-level constraints: in my experience, constraints invariably get violated at the lowest level in the design, not the highest. If it isn't obvious the design at a high level is correct, the system is too complicated. (this should be fractally applied throughout the system; cf FractalComprehension).

I'll likely have more to say and statements to retract after I draw more UseCaseMaps? over the next few weeks. -- SunirShah

---

CarletonUniversitySoftwareSystemsDesign's bouncing link tour takes us to MessageSequenceChart.