Wiki Home

Use Cases And Sequence Diagrams

Namespace: WIN_COM_API
A place to discuss the relationship between Use Cases and Sequence Diagrams
New experience suggests that producing sequence diagrams too early in the development process is probably a mistake. It's pretty easy to take almost any decent Use Case and map it into a Sequence Diagram. What this does, unfortunately, is jump from the Use Case directly into the realm of classes and objects. For simple systems or subsystems this can be okay, but for anything non-trivial a major Use Case refactoring for commonalities should always occur first. Then should come a detailed ex-use case analysis. Only then do you have enough real knowledge for design, and one of the design activities is to allocate behavior into packages and classes.

For example, sequence diagrams strongly infer implmentation decisions, and that these decisions really don't belong in analysis. Take the typical ATM scenario where the system and the user are 'talking' back and forth. What of an alternate design, equally valid, where the system collects all information at once in a form of some type, rather than having the system and user yacking back and forth?

According to Robert C Martin:
Use cases are use cases. They are not the beginning of design, nor do their structure somehow conducive to objects, classes, or messages. They are simply a statement of requirements, expressed in a form that is reasonably unambiguous, and simple to enumerate.

I can see no reasonable way to combine use case models, that describe system behavior, to sequence diagrams, that describe the message flow between objects, without imposing the implementation dependencies. I.e. that the use cases made unfortunate and unnecessary assumptions about the implementation.

The problem is that the statements in use cases need not (and often do not) map trivially to objects and messages. It may be that a single statement on a use case involves a complex interaction between many objects in several different threads; whereas a subsequent statement on a use case corresponds to messages in the software that must be executed
out of order with the rest of the use case.

In other words, the use case description is not the design of the software, and does not map trivially to the design of the software.

Now, *some* software may have trivial mappings. And for this kind of software it may be that the use case text and the sequence diagrams have a closer correspondence than is useful. But most of the systems that I work on would not yield well to that kind of functional decomposition.

See Use Cases Transition To Design
Contributors: Steven Black
Category Modeling Category Class Design Category Anti Pattern
( Topic last updated: 1999.12.19 10:55:48 PM )