4. Making the Use Case Diagram

Now that we have gone over what a use case diagram is, how it works, and the key components, we finally have the knowledge required to make a use case diagram of our own. When building a use case diagram, it is important to remember that thoroughness is key. We want to make sure that we convey as much information as we can in order to have a complete diagram (as stated previously, the use case diagram is arguably one of the most important diagrams within UML, as it is the foundation for all other diagrams developed). So before we can actually begin drawing the use case diagram, we need to perform some requirements analysis, to make sure that we have all the information we need. Some key things to analyze would include:

1. Use Cases: Do we have all the functions/events that are necessary for the system to function? Are they organized in a legible and logical manner? Are there common functions between use cases that could be use cases of their own?
2. Actors: Who or what interacts with the system? Are they clearly defined? Are there non-human items that may interact with the system as well? Did you include time as an actor?
3. Associations: How are use cases and actors related? Does it require a description? Are there any use cases that are associated with each other?

These are just a few of the questions that should be asked  before you make a use case diagram. But if you find any issues or additions in the future, don't be afraid to add them at a later time, just be sure to note the additions.

Theses are the steps required to create a use case diagram. For this example, I will use the example of a basic school registration system.

1. Draw a box to represent the information system.
1.  
2.  Identify and add any relevant actors
1.  
3.  Identify and model required use cases
1.  
4.  Add relevant associations between actors and use cases
1.  

To summarize this post and the information in this blog, remember these tips

•Use Case: set of scenarios related to a single goal.

•Use Case Diagram: shows interaction between actors and use cases within a system

•Key elements: System, Actors, Use Case, Association.

•Always document Assumptions!

I hope you have found this information relevant and useful, and I wish you the best of luck in future Modeling projects!

3. Use Case Model Concepts and Key Terms

Before we can begin any work on building a use case diagram, we first have to understand the terminology an symbolism use for this type of diagram. A use case is "a textual narrative that describes the sequences of events of an actor using a system to complete a process", according to the boo The Object Primer: Agile Model-Driven Development by Scott Ambler. In other words, a use case is simply a step-by-step narrative of all the events that occur for a specific process. For example, if I were to create make a use case for making a sandwich, the process would look a little like this:

1. Select bread type
2. Select Peanut Butter type
3. Select Jelly type
4. Place slice of bread on plate
5. Using knife, apply peanut butter to bread as desired.
6. Spread peanut butter evenly across surface of bread.
7. Using spoon, scoop jelly from jar.
8. Apply jelly to bread, spread evenly.
9. Place second piece of bread over jelly-covered side of bread.
10. Slice sandwich in half.

As you can see, there are a lot of steps that go into something as easy a making a sandwich. When making a use case, it is better to be too specific than not specific enough; this is crucial when the project enters development phases. But on a use case diagram, we do not put the entire steps to each use case. Instead, we simply put the name of the use case on the diagram (for example, using the sandwich steps, we could call the use case "Make Sandwich". Make sure the title clearly states what the process is about).

Now that we have discussed what a use case is, let's go over the key components of a use case diagram.

1. System: the information system being described.
1. Shows the scope of system boundary between the users and use cases
2. Shown as a rectangle
2. Actors: any entity that may interact with the system
1. Can include a person, device, time, or another information system
2. Represented as a stick figure
3.  Use Case: A specific function or event the system performs
1. Shown as an ellipse with the use case name inside
4. Association: shows the relationship between actors and use cases
1. ie: which actors can perform what use cases, and how they are related.
2. Use cases can also be connected to show dependencies or common functions.
3. Shown as a line with an arrow pointing to the use case

Next post, I will go over the steps to build a use case diagram, and give some examples to help understand how a use case model works.

2. Introduction to Use Case Modelling

Using Event Analysis, we can figure out the key requirements and events that a system must perform in order to be a successful business project. Once we have a list of these requirements, it's time to model them in an effective manner. Many people may wonder why modelling is such an important aspect of system development, but there are many benefits that a use case model alone may provide (along with the benefits of other model types), including but not limited to:

• Provides a baseline for testing in terms of defining test plans and test cases
• Provides a tool for requirements traceability
• Provides a starting point for the identification of data objects or entities.

As you can see from this diagram, Use Case Diagrams are the foundation for every on model used within the system development life cycle. A use case diagram shows the main actions and actors of the system, which is then further specified within the other diagrams.

In summary, the use case diagram takes the events found in event analysis and creates a model depicting the events and the actors of the system. There are many benefits to modeling a use case diagram, and are widely used within the business environment.