Scribd
Upload
19 views5 pages

ASSIGNMENT, SE

Uploaded by

life hour
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
19 views5 pages

ASSIGNMENT, SE

Uploaded by

life hour
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

ASSIGNMENT

The Islamia University of Bahawalpur

Use Case Diagram

Department: Computer Science


Submitted To: Ms.Saman

Submitted by: Group 1


Use Case Diagram:
In the realm of software engineering, understanding the system’s functionality
and user interaction is crucial. One of the key tools used to capture these
interactions is a Use Case Diagram. A Use Case Diagram is a graphical
representation that depicts how users or ‘actors’ interact with a system to
achieve specific goals. It is a part of the Unified Modeling Language (UML), a
standard language for specifying, visualizing, constructing, and documenting
the artifacts of software systems. The components of a Use Case Diagram
include actors, use cases, system boundary, and relationships. Each component
plays a vital role in providing a comprehensive view of the system’s
functionality. This document will delve into the details of these components,
enhancing our understanding of Use Case Diagrams and their significance in
software engineering.

Components:
1. Actors:

Actors are external entities that interact with the system. These can include
users, other systems, or hardware devices. In the context of a Use Case
Diagram, actors initiate use cases and receive the outcomes.

2. Use Cases:

Use cases represent specific things your system can do. For example, in an
online shopping system, examples of use cases could be “Place Order,” “Track
Delivery,” or “Update Product Information”. Use cases are represented by
ovals.

3. System Boundary:

The system boundary is a visual representation of the scope or limits of the


system you are modeling. It defines what is inside the system and what is
outside. The boundary helps to establish a clear distinction between the
elements that are part of the system and those that are external to it.
4. Relationships:

In a Use Case Diagram, relationships play a crucial role in depicting the


interactions between actors and use cases.

Representation and Symbols:

A Use Case Diagram is a visual representation of the functional requirements


of a system from the perspective of its various users. It is a type of behavioral
diagram defined by UML (Unified Modeling Language) and is used for
specifying, visualizing, constructing, and documenting the artifacts of a
software system.

Here are the key components of a Use Case Diagram:

1. Actors: These are the users who interact with the system. An actor can be
a person, an organization, or another system.
2. Use Cases: These are the specific roles or functions that the actors
perform on the system. Each use case is a set of actions, services, and
functions that the system needs to perform.
3. Relationships: These are the connections between the actors and the use
cases. They represent the interactions between the system and the entities
that use its functionalities.
4. System: The system is what we’re developing. It could be a software
application, a business process, or any other element that actors can
interact with.

The Use Case Diagram is drawn as a collection of ovals (representing use


cases), stick figures (representing actors), and lines (representing
relationships). Each use case is connected to one or more actors, and each actor
is connected to one or more use cases.

The primary purpose of a Use Case Diagram is to show what system functions
are performed for which actor. It helps to establish the boundaries of the system
and to understand the overall functionalities of the system and how actors
interact with the system.

Remember, Use Case Diagrams do not show the order in which steps are
performed to achieve the goals of each use case. They are not intended to show
sequence, timing, or other detailed behavior. For that, other types of diagrams,
such as sequence diagrams or activity diagrams, are used.
Here is a simple example of a Use Case Diagram:
Actor (User)
|
|--- Use Case 1 (Login)
|
|--- Use Case 2 (View Dashboard)
|
|--- Use Case 3 (Logout)

In this example, the User (Actor) can perform three Use Cases: Login, View
Dashboard, and Logout. The lines between the Actor and the Use Cases
represent the interactions. This is a very simplified example, and real-world Use
Case Diagrams can be much more complex. But the basic principles remain the
same.

Example:
1. Actors: There are three types
of actors in this system:
o Web Customer: A
user who is browsing
the website without
logging in.
o Registered
Customer: A user
who has an account
and is logged in.
o New Customer: A
user who is in the
process of creating a
new account.
2. Use Cases: The diagram shows four main use cases:
o View Items: Customers can browse and view items available for purchase.
o Make Purchase: Customers can select items and add them to their shopping
cart.
o Checkout: Customers can review their shopping cart and proceed to checkout.
o Client Register: New customers can create a new account.
3. External Services: The system interacts with several external services:
o eService Authentication: This service is likely responsible for authenticating
the identity of the customer, particularly during the login and registration
processes.
o Identity Provider: This service provides identity verification for the
customers.
o Credit Payment Service: This service handles credit card payments from
customers.
o PayPal: This service handles payments made through PayPal.
The lines between the actors, use cases, and external services represent the interactions. For
example, a Web Customer can View Items and Make Purchase, but they need to go through
the Client Register use case (and interact with the eService Authentication and Identity
Provider services) to become a Registered Customer.

This diagram provides a high-level overview of the interactions between different entities in
an Online Shopping System. It helps in understanding the functionalities of the system and
how different actors interact with it. However, it does not provide detailed information about
the sequence or timing of these interactions. For that, other types of diagrams, such as
sequence diagrams or activity diagrams, would be used.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy