What level of complexity should a Use Case diagram illustrate - how much detail should be included, and what is the "cut-off" point for when a Sequence Diagram, or alternative UML diagram should be used?
Asked
Active
Viewed 246 times
3 Answers
1
Although the UML spec lets quite a lot of freedom as to what may appear in any UML diagram, the following should go into a UC diagram:
- Actors
- Use Cases
- possible a boundary that symbolizes the system under consideration (SUC).
This for the "main" UC diagrams, but you will likely create others that include requirements and/or classes of the design, etc.
Now, the actors are all objects that interact with the SUC in first place. Use cases are all those bubbles that signify some individual added value (not some technical procedure!!) the SUC offers to its actors.
Use case diagrams are about added value of the system, not about technical features!
qwerty_so
- 35,448
- 8
- 62
- 86
0
The short answer, of course, is whatever level of detail (rather than complexity) is necessary. For the more thoughtful, use cases are most often used by the analyst to demonstrate to the non-technical stakeholders that all of their use-based requirements are being met. To that end, there should be enough detail so that managers, customers, and marketing have confidence that the developers will develop the product they want. For use case diagrams that capture decisions for developers, there should be enough detail that deeper design or programming can continue. It is best not to develop diagrams that try to address the needs of both types of users (stakeholders and developers). Finally, this is an iterative process of drawing and review. Start simple and add detail as necessary.
Bruce
- 2,230
- 18
- 34
-
1Well, the UCs shall be referred by programmers, but before they take action, there needs to be a system design done by an architect. It's not UC->Class producing code. There are a lot more steps. From UC you go to class design and collaboration. This is where three parties take action: stakeholders, architect and developers. – qwerty_so Mar 15 '16 at 14:31
-
@Jordan-C: Thomas makes a good point. You don't move to sequence diagrams until there are defined classes or at least components. – Bruce Mar 15 '16 at 15:36
0
Use cases
UML defines use cases:
Use Cases are a means to capture the requirements of systems, i.e., what systems are supposed to do. (...) A Use Case is a specification of behavior. An instance of a Use Case refers to an occurrence of the emergent behavior (...). Such instances are often described by Interactions.
In other words, it's an external view of what the system shall do in interactions with the external world.
The level of detail SHOULD be rather high. Typically, the top level of an interaction of a user with the system, that is the main function that a user would invoke for achieving his goal. Using the usual ATM example, the main goals would be "withdraw cash", "consult account balance", and certainly not "insert card", type in pin", "choose action in menu", "take money".
But there is no norm: you MAY as well have very detailed diagrams. It's just that they would be painful to draw, and not necessarily add to the understanding of the requirements. This is why, a recognized practice is to detail the high level use cases ("sea level") further as narratives, for example using Cockburn's approach.
Cut off with sequence diagrams
UML defines the sequence diagrams:
A sequence diagram describes an Interaction by focusing on the sequence of Messages that are exchanged (..) Interactions that are described by Sequence Diagrams form a basis for understanding the semantics of the meta classes in the Interactions package.
Here the focus is more on the internals of the system, and messages exchanged. However, UML sees a use case as a specialized class diagram. With this in mind, if you would have very detailed use case diagrams, the sequence diagram should describe an interaction between and actor and a use case.
Christophe
- 68,716
- 7
- 72
- 138