

Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
An overview of use case diagrams, a behavioral diagram in uml (unified modeling language), used to present a graphical representation of a system's functionality. Learn about actors, primary and supporting, use cases, successful and unsuccessful scenarios, and relationships among use cases.
Typology: Essays (university)
1 / 2
This page cannot be seen from the preview
Don't miss anything!
Background:- Use case diagram is a platform that can provide a common understanding for the end users, developers and the domain experts. It is used to capture the basic functionality i.e. use cases, and the users of those available functionality, i.e. actors, from a given problem statement. In this experiment, we will learn how use cases and actors can be captured and how different use cases are related in a system. Use case diagrams Use case diagrams belong to the category of behavioural diagram of UML diagrams. Use case diagrams aim to present a graphical overview of the functionality provided by the system. It consists of a set of actions (referred to as use cases) that the concerned system can perform one or more actors, and dependencies among them.
Actor An actor can be defined as an object or set of objects, external to the system, which interacts with the system to get some meaningful work done. Actors could be human, devices, or even other systems. For example, consider the case where a customer withdraws cash from an ATM. Here, customer is a human actor. Actors can be classified as below:
Subject Subject is simply the system under consideration. Use cases apply to a subject. For example, an ATM is a subject, having multiple use cases, and multiple actors interact with it. However, one should be careful of external systems interacting with the subject as actors.
Graphical Representation An actor is represented by a stick figure and name of the actor is written below it. A use case is depicted by an ellipse and name of the use case is written inside it. The subject is shown by drawing a rectangle. Label for the system could be put inside it. Use cases are drawn inside the rectangle, and actors are drawn outside the rectangle.
Association between Actors and Use Cases A use case is triggered by an actor. Actors and use cases are connected through binary associations indicating that the two communicates through message passing. An actor must be associated with at least one use case. Similarly, a given use case must be associated with at least one actor. Association among the actors are usually not shown. However, one can depict the class hierarchy among actors.
Use Case Relationships Three types of relationships exist among use cases:
Include Relationship Include relationships are used to depict common behaviour that are shared by multiple use cases. This could be considered analogous to writing functions in a program in order to avoid repetition of writing the same code. Such a function would be called from different points within the program. Notation Include relationship is depicted by a dashed arrow with a «include» stereotype from the including use case to the included use case.
Extend Relationship Use case extensions are used to depict any variation to an existing use case. They are used to specify the changes required when any assumption made by the existing use case becomes false. Notation Extend relationship is depicted by a dashed arrow with a «extend» stereotype from the extending use case to the extended use case.
Generalization Relationship Generalization relationships are used to represent the inheritance between use cases. A derived use case specialises some functionality it has already inherited from the base use case. Notation Generalization relationship is depicted by a solid arrow from the specialized (derived) use case to the more generalized (base) use case.
Identifying Actors
Identifying Use cases Once the primary and secondary actors have been identified, we have to find out their goals i.e. what are the functionalities that they can obtain from the system. Any use case name should start with a verb like, "Check balance".
Guidelines for drawing Use Case diagrams Following general guidelines could be kept in mind while trying to draw a use case diagram: