Use case programs

Identifying the correct actors is a key criterion for success, but determining the system scope is a foundation for project management, and also helpful in determining the actors. Actors are external entities that interact directly with the system. Using our Order system example, when customer service representatives enter the item number into the system, they are actors.

When customers enter items on a website, they are actors. If a customer orders by phone and a customer service representative alone enters that order, the customer is not an actor. Actors can be people, other systems, or time. When the Order system goes to an Inventory system to determine whether or not an item is in stock, the Inventory system is another actor.

If month-end processing triggers the Order system to create reports, for example, then time is an actor. Time actors are called temporal actors. When people are being considered as actors, it is important to understand that the people are playing roles such as customer, maintenance worker, troubleshooting technician, installer, and manager , and they should be documented and described by those role names, not their titles.

Sometimes people play more than one role, such as the following:. It is important to think of actors as role players, or actors in a play, rather than individual persons or job titles. Defining the actors by what interactions they wish to perform with the system will help define and differentiate the actors.

Systems can be any automated device with which the system will interface. This includes other computers and interface devices if they are out of scope of the system being developed. For example, if the system is a Distribution Center system which reads data from scanned cartons, the devices used to scan the cartons would likely be included as actors.

Time actors are time-based initiators or triggers of processing activity for the system. Common timers are weekly, daily, and monthly. Use cases: are the processes that occur within the system. Like other processes, they have a process scope. That is, they begin and end. They also transform input into output. Use cases are named with an active verb and a noun, such as Fulfill Order or Return Item. Additional examples:.

These are considered processes that accomplish a task for the actor. Use cases should provide value to the actor. The goal is to discover all the possible use cases for all the actors previously defined, which helps define the scope of the system. The interface allows the conversation between actor and system to take place. While not technically part of the use case, they are related.

Thinking about the interfaces helps uncover additional use cases and vice versa. Thinking about the use case often drives the design of the interface. Let's use the example of a car. One of the ways we might want to use our car is to have it stop when we want. That conversation is facilitated through an interface, in this case a brake, which allows us to make our request of the car and for the car to respond to the request to stop. Hopefully the car responds by slowing down and coming to a halt.

Screens, also known as user interfaces, help end-users communicate with automated systems. A use case model consists of a use case diagram and narrative text detailing the use cases. The diagram is a picture of the system, actors, and use cases.

It contains the system boundary, called a boundary box, the actors, and the use cases. The narrative text describing the use case is called a flow of events. UML does not address this textual description. Key components of the flow of event include:. We have found that other process models, such as process maps, swim lanes, and activity diagrams are more effective. Use cases that model business processes can become text procedures.

However, a graphical picture of the business process helps spot anomalies with the current process and more easily leads to ways to improve it. Use case diagrams are typically developed in the early stage of development and people often apply use case modeling for the following purposes:. A standard form of use case diagram is defined in the Unified Modeling Language as shown in the Use Case Diagram example below:.

Use cases share different kinds of relationships. Defining the relationship between two use cases is the decision of the software analysts of the use case diagram. A relationship between two use cases is basically modeling the dependency between the two use cases. The reuse of an existing use case by using different types of relationships reduces the overall effort required in developing a system. Use case relationships are listed as the following:. A Use Case diagram illustrates a set of use cases for a system, i.

The include relationship adds additional functionality not specified in the base use case. The extend relationships are important because they show optional functionality or system behavior. Take a look at the use case diagram example below. It shows an extend connector and an extension point "Search". A generalization relationship means that a child use case inherits the behavior and meaning of the parent use case.

The child may add or override the behavior of the parent. The figure below provides a use case example by showing two generalization connectors that connect between the three use cases.

The figure below shows a use case diagram example for a vehicle system. As you can see even a system as big as a vehicle sales system contains not more than 10 use cases! That's the beauty of use case modeling.

The use case model also shows the use of extend and include. Besides, there are associations that connect between actors and use cases. It typically shows when an error happens at the system level. You often include the most likely or most significant alternatives an actor might make an exception for in this portion of the use case.

In the e-commerce example, some alternative flows might include:. A session time-out when the customer is placing the order. A failed credit or debit card payment authorization. In this use case example, an international airline wants to refresh its online booking system, offering more complex fare options and ancillary revenue options and additional optional services, like curbside check-in.

UpCloud Airways software engineers design a branded and refreshed fare booking page, complete with tiered fare selection, add-on options like lounge access, free flight change or cancel abilities and complimentary checked bags.

It also allows account holders to pay in credit, debit, online payment platforms or by UpCloud loyalty program miles. The software engineers conduct several use cases to establish how the booking flow works and identify potential concerns.

They run cases that include:. A customer browsing flight schedules and prices. A customer selecting a flight date and time. A customer adding on lounge access and free checked bags.

A customer paying with a personal credit card. A customer paying with UpCloud loyalty miles. Through the various use cases, the engineering team identifies a malfunction with the optional add-ons prompting unless the user has a previously established account.

The team rectifies the issue before launching the refreshed booking system and the airline sees improved customer satisfaction ratings and increased revenue within the first week of the new platform.

In this use case scenario, a food delivery mobile application wants to expand to include more food and drink establishments, even if some locations have a limited menu. Deliver the Good Eats, a food delivery service, wants to grow the number of offered establishments and aims to include coffee shops and convenience stores.

The software developers need to determine how the newly featured establishments benefit from current software parameters and what user thresholds might prompt the software through to the next stage. The team runs use cases like:. A customer searching for a specific name brand item not found in the area or chosen establishment.

A customer with a low dollar amount total prompting for a minimum purchase message. What is an actor? Generally, the users are actors but often systems can be actors as well. There are possibly over a dozen actors that interact with Ebay, from buyers and sellers, down to suppliers, wholesalers, auditors, and customer service. So lets put them down as our first actors.

While John may be a seller and Sue may be a buyer, an actor is a Role. And a role in this case would be that of a buyer and that of a seller. Now that things are clicking, lets throw some more actors on your paper just so we can try and identify more possible users. Now we have a bunch of actors. Wait a minute? An actor can be a system, because a system plays another role in the context of your new system and has goals and interacts with other actors as you will see later.

These are sometimes referred to as your primary use cases. The product manager should be able to discern a common use case from the edge case and prioritize accordingly. So, once you are done with your sunny-day use cases, distribute it among your project team and get consensus that you have covered them all. It should be a business question as far as how much software development costs do you want to spend on something that is not likely to happen. Identify reuse opportunity for use cases In this step, you are going to cross the bridge into object modeling.

The goal of this Ebay use case example is to keep it understandable so we will explain this concept in terms of the example. What does the word general mean? Something is broad and not as detailed.