Free Use Case Tool

Think from End User's Perspective

It is clear that you need to know users' expectation in order to build a software system that works, and this principle is particular important in use case modeling. Many people has mistakenly treats use case modeling as a process to model system functions, which can be wrong. To be accurate, use case modeling is a way to model what the users want. Each of the use cases in a use case diagram should yield an observable goal through users' interaction with the final software or system. Sometimes, a user goal is the same as a system function but this is not always true. For instance, "Login" is a system function but it is definitely not a user goal - No one will start a program, login and go away! So, the more system functions you draw in a use case diagram, the less effective the use case model can be used to express users' real expectation throughout the entire software development process. Therefore, when you develop a use case model, try to express everything by first thinking from end user's perspective.

Avoid Long Use Case Name

If you are reading a use case diagram prepared for an ATM system, which of the following use cases do you want to see in the diagram? "Withdraw Cash" and "Withdraw Cash and Update Balance in Account". The second use case seems to be more descriptive, right? What about having 50+ different use cases with such a long name? You probably does not want to read the diagram anymore and perhaps your eyes will be in pain.

One of the reasons why we need modeling is that we want to understand a complex software system in an easy and simple manner. That's why the UML has provided us with many different kinds of notations with each of them representing a specific perspective in describing a complete software system. This "spirit" applies to naming use cases as well. If we try to name use cases with detailed description, why don't we just use a text file instead? In order to make a use case diagram easy to understand, it is important to keep the names of use cases short, yet remain descriptive. Keep the names short and leave the detailed description to the description part of use cases.

Actor is a Role, not a Real Person

Some people try to represent employees in an organization as actors in use case diagram, which end up having a diagram with Peter, Mary, Daisy, etc Remember, an actor represents a unique role that comprises of people, sub-system or whatever entities with unique characteristic and share the same goals and expectations.

Model Common Use Case with << include >> Relationship

A use case represents a user goal, which can be achieved by going through a series of steps. When exactly the same steps are found among use cases, you can optionally create a new use case for the common steps and connect it with the use cases that trigger the steps. By using included use case, this makes it clear that the including use cases are indeed sharing the same set of steps as represented by the included use cases with no uncertainty.

Model Exceptional Behavior with << extend >>

The extend relationship can be used to specify when and how the behavior of a use case may be triggered by another use case. Extension takes place at extension points defined in extended use case. The extending use case defines the steps that may be executed by the extended use case under specific conditions.

Model Scenario with Flow of Events, Not Directly on Diagram

A use case represents a user goal, which can be achieved by going through a sequence of steps. Some people try to model the steps directly on use case diagram, by connecting actor and use case with many many associations, pretending to be the steps, which is definitely wrong. Instead, the steps of use case can be well described in the use case flow of events editor.

Make Good Use of Stereotype for Categorization

Stereotype is a mechanism that allows you to introduce domain specific notation in addition to those standard ones. A stereotype is shown within a pair of guillemets, on top of the name of shape when the stereotype is applied. The proper use of stereotype helps readers to realize the differences of use cases on easier.

Model Detailed System Flow with Sequence Diagram

Sequence diagram allows you to model the system behavior by representing the communication and interchange of messages between objects over time. But where to begin with? Instead of guessing what interaction to model, you can start by referring to what the user needs, which is exactly what a use case model aimed to present.

We know that every single use case represents a unique user goal. To draw sequence diagram from a use case implies that you are going to model what the computer system should do to fulfill the user. Ideally, there will not be any redundant design as all the sequence diagrams are created from use cases, which represent what the user wants.

Apply Same Width on Use Cases When Appropriate

Since the names of use cases are different in length, it is normal to have the use cases in different width. To make the diagram prettier and easier to read, it would be nice to resize them to the same width.

Position Actors and Use Cases in a Meaningful Way

A use case diagram with randomly placed actors and use cases is definitely a nightmare for readers. One has to examine the diagram carefully in order to find out the information he want from the scattered actors and use cases. It would be nice to place shapes in a discipline manner. You may also group use cases with package shapes if necessary.