2. Use case diagram
• Describes the relationship between the system being
modelled and the outside world
• Models the system behaviours in a graphic view
3. Main Components
• Actors
– Users of the system, e.g. Student
– Surroundings of the system, e.g. Billing System
– Anything that is external to the system and interacts with it
• Use cases
– Major functions (top level)
• Relationships
– Between actors and use cases
4. Actors
• Actors are NOT part of the system
– User
– Other system
– Sensor
• Actors interact with the system
– Input information to the system
– Receive information from the system
– Both
UML notation of actor
(A matchstick man)
5. Identifying actors
• Actors can be found in
– In the requirement statements,
– In problem statements,
– Though conversations with customers
• Who will use the system?
• Who will supply information?
• Who will support the system?
• Who will maintain the system?
• Any external resource?
• Interact with other systems?
• …
6. Use cases
• Functionality that is provided by the system
• Dialogue between actors and system
• Formal definition:
– A use case is a sequence of transactions performed by a
system that yields a measurable result of values for a
particular actor
UML notation of use case, (balloon shape)
7. Use case description
• Use case also needs documentation
– States the purpose of the use case in a few sentences
– Provides a high-level definition of the functionality
• For example:
– Register for courses:
This use case is started by student. It provides the capability to create,
modify, and/or review a student schedule for a semester
• Scenario based approach usually
8. Use case relationship
• Show the relationship between:
– An actor and an use case
– An use case and another use case
• The relationship represents communication
• Navigation direction
– Who is initialling the communication
– May be both directions
UML notation of a use case relationship
(an arrow)
10. Use case relationships
• We can have relationships between two or more use
cases.
• Such relationships indicates that some function is re-
using another function
• Several types of re-use relationship, but main are:
– Includes
– Extends
11. << include >>
Include Relationship
Represents the inclusion of the functionality of one use case within another
Arrow is drawn from the base use case to the used use case
12. << extend >>
Extend relationship
Represents the extension of the use case to include optional functionality
Arrow is drawn from the extension use case to the base use case
Write << extend >> above arrowhead line
13. Case study . Car sharing system
• System Analyst (SA): So you’re saying that car sharers will be able to register by telephoning
the office and speaking to someone there who will enter their details into the system.
• Director (Di): Yes, either the franchisee or more likely one of the office staff will take the call
and enter the details into the computer.
• SA: who are the office staff?
• Di: Well, there’s one or two clerks, a receptionist and a supervisor. They all have role in the
administration of the system.
• SA: what will they be entering?
• Di: The person’s name and address, details of the journeys they want to share, any
preferences they have.
• SA: Is that the only way that this information will get into the system?
• Di: No, it could also be transferred in from the national web-server.
• SA: How will this information be used?
• Di: Two ways. Firstly, it will used to match up potential car sharers, and secondly, it will be
used to produce a management report for the franchisee showing the number of registration
per week.
13
14. Find actors and use cases .. Case study
• Now ask the three questions about actors:
– “who are the people who will use this system to enter information?”
– “who are the people who will use this system as recipients of
information?”
– “what are the other systems that this system will interact with?”
14
15. Find actors.. Case study
• SA: So you’re saying that car sharers will be able to register by telephoning the office
and speaking to someone there who will enter their details into the system.
• Di: Yes, either the franchisee or more likely one of the office staff will take the call and
enter the details into the computer.
• SA: who are the office staff?
• Di: Well, there’s one or two clerks, a receptionist and a supervisor. They all have role in
the administration of the system.
• SA: what will they be entering?
• Di: The person’s name and address, details of the journeys they want to share, any
preferences they have.
• SA: Is that the only way that this information will get into the system?
• Di: No, it could also be transferred in from the national web-server.
• SA: How will this information be used?
• Di: Two ways. Firstly, it will used to match up potential car sharers, and secondly, it will
be used to produce a management report for the franchisee showing the number of
registration per week.
15
16. Find Use Cases .. Case study
• SA: So you’re saying that car sharers will be able to register by telephoning the office
and speaking to someone there who will enter their details into the system.
• Di: Yes, either the franchisee or more likely one of the office staff will take the call and
enter the details into the computer.
• SA: who are the office staff?
• Di: Well, there’s one or two clerks, a receptionist and a supervisor. They all have role in
the administration of the system.
• SA: what will they be entering?
• Di: The person’s name and address, details of the journeys they want to share, any
preferences they have.
• SA: Is that the only way that this information will get into the system?
• Di: No, it could also be transferred in from the national web-server.
• SA: How will this information be used?
• Di: Two ways. Firstly, it will used to match up potential car sharers, and secondly, it will
be used to produce a management report for the franchisee showing the number of
registration per week.
16
17. Draw use case diagram..
17
Match car
sharers
Manually add
car sharer
Transfer car
sharer from
web-server
Office Staff
Web-server
Produce
performance
report
Franchisee
18. Course Registration Example
• At the beginning of each semester students may request a course catalogue
containing a list of course offerings for the semester. Information about each
course, such as professor, department, and prerequisites will be included to
help students make informed decisions.
• The new system will allow students to select four course offerings for the
coming semester. In addition, each student will indicate two alternative
choices in case a course offering becomes filled or canceled. No course
offering will have more than ten students. No course offering will have fewer
than three students. A course offering with fewer than three students will be
canceled. Once the registration process is completed for a student, the
registration system sends information to the billing system so the student can
be billed for the semester.
• Professors must be able to access the on-line system to indicate which courses
they will be teaching. They will also need to see which students signed up for
their course offerings.
• For each semester, there is a period of time that students can change their
schedule. Students must be able to access the system during this time to add
or drop courses.
19. Actors ..
• The actors are
– Student
– Professor
– Billing System
– Registrar
20. Use Cases
• Student
– Register for courses
• Registrar
– Maintain course information, Maintain student information,
Maintain professor information, Generate catalogue
• Professor
– Request course roster, Select courses to teach
21. Use Case Diagram
Student
Register for Courses
Request Course Roster
Select Courses to Teach
Professor
Maintain Student Info
Maintain
Professor Info Maintain Course Info
Generate Catalogue
Registrar
22. Use cases descriptions
• After the derivation of use case model, each use case is elaborated by
adding detail of interaction between the user and software system.
• An elaborated use case has the following components
24. Example
• Use Case Name: Delete Information
• Priority: 3
• Actors: User
• Summary: Deleting information allow the user to
permanently remove information from the system. Deleting
information is only possible when the information has not
been used in the system
• Preconditions: information was previously saved to the
system and a user needs to permanently delete the
information
25. Example (Cont…)
• Post-conditions: The information is no longer available anywhere
in the system
• Uses: Record Transactions, Cancel Action
• Extends: None
• Normal Course of Events:
1. The use case start when user wants to delete some information
2. The user selects the information he wants to delete and directs the
system to delete the information. (Exception 1,2)
3. The system responds by asking to confirm deleting information.
4. The user confirm the deletion
5. Alternative path: Cancel Action
6. The system responds by deleting information and notifying the user
that information was deleted from system
7. The use case ends
26. Example (Cont…)
• Alternative Path: the user does not confirm Deletion
– If the user does not confirm deletion the information does
not delete
– Uses: Cancel Action
• Exceptions:
– The system will not allow a user to delete information that
is being used in the system
– The system will not allow user to delete another user
information
27.
28. Example
• Describe in detail the ‘Check out an item for a borrower’ use
case as performed by the checkout clerks at the circulation
desk of a library
Editor's Notes
3
4
5
6
7
8
Primary Actors: The Actor(s) using the system to achieve a goal. The Use Case documents the interactions between the system and the actors to achieve the goal of the primary actor.
Secondary Actors: Actors that the system needs assistance from to achieve the primary actor’s goal.