In the second part of The Use Case Chronicles, I continue to discuss use cases. In the first part, you can read about what a use case is, who invented it, where you can use it, and in what format. Here, let’s discover the structure of use cases. Both text and graphical views are based on the same concepts. In order to explore elements and connections of use cases, let’s first focus on the graphical view. It has less information and details and it is more intuitive. Afterwards, let’s consider additional elements and templates for the text view. A UML serves as a basis for the graphical view here. It may be expanded depending on the company and author; however, here, I will be using a traditional UML version. Use Case Diagram Base Elements Use case The main content of the diagram. A use case specifies the behavior that a system or a part of a system performs to get a valuable result for a user. It can be some function, process, or action, including variants, or a set of them. Graphically, a use case is rendered as an ellipse. Every use case must have a name that distinguishes it from other use cases. Name is usually a short active verb phrase naming some behavior: perform a transaction, process a bill, display a movie, order a ticket, etc. Subject/system A system (or a part of a system) that is described and to which use cases apply. Typically, a system is rendered as a frame around the use cases, with a name at the top. Sometimes, this element may not be shown, but anyway, you have to understand, what system you are describing. Actors An actor represents somebody or something that uses the system in different scenarios or that is required for different cases. Typically, an actor represents a role that a human plays with a system, but it also can be a hardware device or even another system. Usually, actors are rendered as stick figures, but you can also use other symbols to visually indicate different actors. For example, a system might be rendered as a rectangle, a database as a figure, and human actors as stick figures. Every actor must have a name. Typically, the name of an actor is a noun: client, enterprise, customer, database, etc. Association Each actor should be connected to some use cases; this connection is called an association. An association indicates that the actor and the system interact with one another in the context of the use case. If there are several actors associated with a use case, that means all of them participate in this use case (AND semantics). An association is rendered as a solid line (or a solid arrow). 📝 Example Let’s model base elements for a mobile application for food ordering: A system is a mobile application Who can interact with an app (who are the actors)? Clients (place orders), restaurants (place their menus), couriers (deliver orders), etc. For an example, let’s consider only a client. How a client can use the app? Let's highlight 4 main use cases: choose the restaurant choose dishes place an order track an order An actor can represent also a role of another system. For example, in the app, there is a database that contains lists of orders, restaurants, and their dishes. DataBase is an actor too. Here is a diagram: Relationships In addition to the association – the connection, there are relations between use cases and between actors . There are three types of relationships that are applicable both for use case ↔ use case and actor ↔ actor: extension, inclusion, and generalization. actor ↔ use case use case ↔ use case actor ↔ actor All relations between cases are rendered inside a frame representing a system. Below are examples and descriptions of each relationship considered for use cases, but keep in mind that all the same relationships are applicable to actors. Extend The base use case may stand alone, but its behavior may be extended by the behavior of another use case. The extended relationship can model what the user may see as optional system behavior. View: dotted arrow with the caption in the direction: extends → case_extension base_use_case Include The base use case explicitly incorporates the behavior of another use case. That relation shows reusable functions; instead of describing the same flow several times, you can put common behavior in a use case (like a subprocess). View: dotted arrow with the caption in the direction: include → included_use_case base_use_case Generalization There are the parent cases and children cases. The child use case inherits the behavior and meaning of the parent use case, but the child may add to or override the behavior of its parent. In other words, you can create a new case (child) based on another one (parent). View: A solid arrow with an empty tip in the direction: → case_child case_parent 📝 Example Let’s expand the model for a mobile application for food ordering. There is a use case "Place an order." If a user wants to place an order, he/she needs to and . These are use cases too, but they are parts of the bigger use case, they are in placing an order. confirm it pay for it included Now, let’s look at “Choose a restaurant.”Basically, restaurant selection means searing through a list of restaurants. An app can have a feature that to a user, making a search more convenient and personalized. That feature is a use case too, and it the base case. suggests a restaurant extends Last, but not least, the “Pay for an order” case. Payment may be realized in different ways ( or ), which are use cases too. Some way of payment inherits the meaning of a “Pay for an order” case but overrides the behavior–generalization relationship. bank PayPal Difference from other relationships: they are of a payment, but types (not ) not sub-processes include they included or not included in the payment (not ) cannot be optionally extend Additional Elements for Text Representation I mentioned above that a text view is more suitable for a detailed description. It is easier to place additional details through a table or text, so the following elements are usually used in text-based templates. Depending on the template, any useful information can be added to the use case description, but typically authors suggest including the following elements: Preconditions Preconditions define what must happen before the system can begin executing the use case. Preconditions can describe both actors and the system states, but they don’t describe a user’s intent. For example, the “place an order” button will not appear until the user adds at least one dish to the cart. Another example: to make a transfer in an online bank, the user must log in first. If the system knows from the start that it cannot complete the use case successfully, but proceeds anyway, some errors might occur. Checking preconditions before executing the use case can prevent these errors. Trigger That is the starting point for executing the use case, something that provokes it. When the system detects the trigger event, it checks preconditions (the trigger event itself is not one of the preconditions) and (if all preconditions are true) starts executing the use case. For example, placing an order begins by clicking the "Place an order" button. Goal The result of a use case is the result of an actor's interaction with the system. What should happen or what will guarantee success when the use cases are executed correctly? as a more detailed description of a Basic flow Use case That is a normal flow for the use case when everything works fine and without errors. It’s also called the main flow, basic flow, normal course, primary scenario, main success scenario, sunny-day scenario, happy path, and so on. Basic flow describes events that happen to lead the user from a trigger to a result. The reason it’s not the same thing as a use case is that, besides the basic flow, there can be other scenarios within the same use case (alternative flows). Alternative flows Alternative flows represent less common or lower-priority flows in a use case, the most likely deviations from the main scenario. The normal flow might at some point branch off into an alternative flow and might (or might not) rejoin the normal flow later. Quite frequently, alternative flows describe the system’s possible reaction to various errors. To write an alternative flow, you need to check every step of the basic flow and ask yourself the question, “What happens if...” For example, what happens if the website crashes while a user is placing an order? What happens if the client adds all products to the cart in an online store and closes the app? 📝 Example Let's extend the mobile application for the food ordering model, and describe one use case as a table with new elements. Element Content System Mobile application for food ordering In the diagram view, a system is rendered as a frame around the use cases with a name at the top. Use case name Confirm an order In the diagram view, it’s an ellipse with a name. Primary and secondary actors A client and a database The disadvantage is that relationships through actors and through cases will be more difficult to describe in words than to draw. Preconditions - The user is authorized - The user created an order Trigger The user clicked the “Confirm an order” button Goal The order is confirmed, the user proceeds to pay for the order Basic flow - The system shows the name of the restaurant, a list of selected dishes, the delivery address, and the payment method - The user checks the information - The user clicks the “OK” button - The system checks the availability of dishes in the restaurant - The system confirms the availability of all dishes in the restaurant - The system creates a new order Alternative flows - User removes or adds new dishes, changes their quantity.. - User changes delivery address... The user changes the payment method... The user clicks the "Cancel order" button... - Some dishes are missing, or there is not enough quantity - Error in creating an order [further description of system behavior] Conclusion This concludes the second part of the Use Case Chronicles. The third part will focus on the templates and tips for creating use cases.

Read My Stories

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

The Use Case Chronicles – Part 2: Unveiling Use Case Structure

Too Long; Didn't Read

Anastasiia Kostina

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

The Use Case Chronicles – Part 2: Unveiling Use Case Structure

Too Long; Didn't Read

Anastasiia Kostina

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES