SAAD Lab 2

System Analysis & Design
Introduction to UML diagrams

Use case diagram
Lab 2
System Development Life Cycle (SDLC)
• Requirements Collection
• Requirements Analysis
• System Design
• System Development
• System Testing
• System Deployment
• System Maintenance
?System Modeling – How
• A model helps you plan a system before you build it

• Take the business needs of the users
• Map them into requirements that your team can use
and understand
• Take these requirements and generate code from them
By mapping the requirements to the code, you can ensure that the
requirements are actually met by the code, and that the code can easily be
traced back to the requirements
Business
Requirements Model Code
Needs
?What is UML
• The Unified Modeling Language (UML) is a standard
language for specifying, visualizing, constructing, and
documenting the artifacts of software systems
•A standard is vital to realizing one of the benefits of visual

modeling: communication
• Communication between
users, developers, analysts, testers, managers, and
anyone else involved with a project
• Be independent of particular programming languages
and development processes
UML - Unified Modeling Language
UML DIAGRAMS
• Business Use Case diagram
• Use Case diagram
• Activity diagram
• Sequence diagram
• Collaboration diagram
• Class diagram
• Statechart diagram
• Component diagram
• Deployment diagram
These model diagrams illustrate different aspects of the system

UML Drawing Tool: Rational Rose
UML Drawing Tool Rational Rose
• ROSE = Rational Object Oriented Software Engineering

• Rose uses the UML to provide graphical methods for
non-programmers wanting to model business
processes as well as programmers modeling
application logic.
• It is used in reverse engineering (creating diagrams
from object classes) or forward engineering (creating
object classes from diagrams)
Rational Rose
Browser
Diagram
window
Diagram
toolbar
Documentation
Window
docked/floating
* Locked and unlocked modes of icons
** Customizing the tool bar
Rational Rose
Views
Diagrams
Use Case Diagram
• Use cases represent system functionality, the

requirements of the system from the user's perspective
• Use cases just focus on automated processes
• Use case diagrams show the interactions between

• Use cases: what the system should do, and
• Actors: anyone or anything that interacts with the
system (Individual, group, company,…)
Elements of Use Case Diagram
Actor
• An actor is anyone or anything that is outside the

system’s scope but interacts with it (Individual, group,
company,…)
• There are three types of actors:

• Users of the system
▪ physical person, or a user who will be directly using the system
• Other systems that will interact with the system being

built
• Time
▪ Time becomes an actor when the passing of a certain amount of time
triggers some event in the system (out of control)
Use Case
• It is the functionality the system will provide a value to the end

user
• Use cases are an implementation-independent:

• High-level view of what the user expects from the system
• Focus on what the system should do, not how the system will do it
• Use Case diagrams aren't intended to show in which order the use
cases are executed
• The use cases should be named in user terms, not technical

terms, and should be meaningful to the customer
Use Case
. cont
• So, when you have the final list of use cases, how do you
know if you've found them all?
- Is each functional requirement in at least one use case? If a
requirement is not in a use case, it will not be implemented.
- Have you considered how each end user will be using the system?
- What information will each end user be providing for the system?
- What information will each end user be receiving from the system?
- Have you identified all of the external systems with which the system
will need to interact?
- What information will each external system be providing to the system
and receiving from the system?
Relationships
• The association relationship is used to show the
relationship between a use case and an actor only
• There are only two types of relationships allowed between

use cases
• Includes relationship
• Extends relationship
These relationships are used when there is a certain amount of

commonality between the use cases
• Generalization relationship is the only relationship allowed

between actors
Relationships: Association
• Association relationship is used to show the relationship
between a use case and an actor only
• Every use case must be initiated by an actor, With the

exception of use cases in includes and extends
relationships
Relationships: Includes
• Includes relationship allows one use case to use the functionality
provided by another use case
• This relationship can be used in one of two cases:
• First, if two or more use cases have a large piece of functionality that is
identical
•The second case where an includes relationship is helpful is a situation in
which a single use case has an unusually large amount of functionality
• An includes relationship suggests that one use case always uses the
functionality provided by another
<<includes>>
Make Reservation Check Credit

While the “Make Reservation" use case is running, "Check Credit" must run
Relationships: Extends
• Extends relationship allows one use case the option to extend the
functionality provided by another use case
• It is very similar to an includes relationship, because in both of these

types of relationships, you separate some common functionality into its
own use case
<<extends>>
Change Reservation Check Credit
While the "Change Reservation" use case is running, "Check Credit" runs if and only if the
amount of the reservation has changed. If the amount has not changed, "Check Credit"
does not need to run
The arrow is drawn from the use case that is optionally run ("Check Credit") to the use
case that is being extended ("Change Reservation")
Relationships: Generalization
• Generalization relationship is used to show that several
actors
• For example, you may have two types of customers. If

the type A customers will be initiating some use cases that
type B customers will not, it's probably worth including the
actor generalizations. If both types of customers use the
same use cases, it's probably not necessary to show an
actor generalization
Example
Common
Mistakes
?Who is the actor in the use case diagram
• The actor is the one who directly uses the system

• Example: if a student needs a grade report from student affairs
department, he will ask the employee to prepare his request
• So, the user of the system in this case is the employee not the student
Print Grades Employee Print Grades

student
Report Report
• Every use case should have an initiator except abstract use cases
(includes and extends)
Functionalities
• Every use case should represent a main functionality
• So, we can’t list “select seat”, “enter user name” or “choose

category” as use cases
Because they are steps of a certain use cases (“Make

Reservation”, “Register” or “Search for Products”) rather than
being main functionalities
• We can’t create a use case with a vague name like “enter data in
database”, “choose” , “save data” or “manage data”
• Don’t create “Add course”, “delete course” and “update course” as

3 use cases but create one use case called “Manage course data”
Relationships
• There is no direct association relationship between actors

(except inheritance) or use cases (except includes & extends)
• The relations in use case diagram don’t give any sequential

meaning
Relationships
“extends” relationship is not used to represent options
>>extends<<
Search by name
>>extends<<
Search
Search by ID
>>extends<<
…… Search by
Use Case VS Business Use Case
Use Case Business Use Case

1- Automted processes of 1- Both Manual and
the system automated processes of the
system
2- Use case is represented 2- System represented form
for the customer the perspective of the
perspective e.g. make system e.g. receive
payment payment
3- Use Case 3- Business

Use Case
4- Actor icon is
same for 4- Business Actor
Admin, (customer or external
Customer and system)
external system 5- Business Worker
(employee)
Practice
• Draw a Use Case Diagram shows the interactions
between the use cases and actors of an Books and
DVD’s online shopping system:
:Requirements
Web Customer can be registered customer or new-1
.customer
.Registered customer can view items and make purchase-2
.New customer can view items and register-3
To make purchase, system view the items and checkout-4
.using credit payment service
View Items use case has some several optional use cases :-5
customer may search for items, browse catalog , view items
recommended for him/her, add items to shopping cart or wish
.list
Checkout use case has several required uses cases: check -6
if Web customer is authenticated, calculate shipping and
Thanks For Listening

SAAD Lab 2

Uploaded by

Copyright:

Available Formats

SAAD Lab 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAAD Lab 2

Uploaded by

Copyright:

Available Formats

System Analysis & Design

Introduction to UML diagrams

• A model helps you plan a system before you build it

•A standard is vital to realizing one of the benefits of visual

These model diagrams illustrate different aspects of the system

• ROSE = Rational Object Oriented Software Engineering

• Use cases represent system functionality, the

• Use cases just focus on automated processes

• Use case diagrams show the interactions between

• An actor is anyone or anything that is outside the

• There are three types of actors:

• Other systems that will interact with the system being

• It is the functionality the system will provide a value to the end

• Use cases are an implementation-independent:

• The use cases should be named in user terms, not technical

• There are only two types of relationships allowed between

These relationships are used when there is a certain amount of

• Generalization relationship is the only relationship allowed

• Every use case must be initiated by an actor, With the

Make Reservation Check Credit

• It is very similar to an includes relationship, because in both of these

Change Reservation Check Credit

• For example, you may have two types of customers. If

• The actor is the one who directly uses the system

Print Grades Employee Print Grades

• Every use case should represent a main functionality

• So, we can’t list “select seat”, “enter user name” or “choose

Because they are steps of a certain use cases (“Make

• Don’t create “Add course”, “delete course” and “update course” as

• There is no direct association relationship between actors

• The relations in use case diagram don’t give any sequential

“extends” relationship is not used to represent options

Use Case Business Use Case

3- Use Case 3- Business

You might also like