Use Case Diagrams – Part I
When it comes to UML Diagrams, Use Case Diagrams tend to be one of the first diagrams created when modeling requirements. Why is that? Well, it is probably because they provide a high-level overview of requirements. If you’d like a definition, I might say that Use Case Diagrams are used to identify the primary elements and processes of a system. In UML terminology, the elements are referred to as “actors,” and the processes are referred to as “use cases.” Let’s take this definition just a bit further. When I create Use Case Diagrams, I look for four things:
1. Actors: An actor can portray any kind of entity that interacts with a system. This could be a person or another system. More often than not, actors are drawn as stick figures outside of the system. Here’s an example of what an actor might look like:
(Isn’t it strange that the original form of written language on cave walls used stick figures and, now, an advanced modeling language also uses stick figures??)
2. Use Cases: A use case represents a distinct business process or functionality of a system. Use cases are drawn as ovals inside of the system. Here’s an example of what a use case might look like:
3. System Boundary: The system boundary is what separates the actors from the use cases. It also ensures that the use cases are grouped together based on their related functionality. The system boundary is drawn as a rectangle that spans all of the use cases. Here’s an example that includes the two previous examples with the system boundary:
4. Relationships: The actors need to be connected in some way to the use cases. That is done with relationships. Relationships are drawn as lines between the actors and the use cases. There are also special cases of relationships that are drawn between use cases. Here’s an example in which the line is added to the previous example:
Of course, this is a very simplistic overview. Coming up in a future blog entry, we’ll try a more practical example in which I will give you an actual requirement. Then, we’ll walk through the process of converting the requirement to a Use Case Diagram. Plus, I will provide you with some more details about the various relationships.
P.S. – For those of you who are curious, these diagrams were created using Poseidon for UML Community Edition 8.0. Support the community: http://www.gentleware.com/.