Object-Oriented Modeling

Use Case Diagram

Slides accompanying UML@Classroom

Version 1.0

Business Informatics Group

Institute of Software Technology and Interactive Systems
Vienna University of Technology
Favoritenstraße 9-11/188-3, 1040 Vienna, Austria
phone: +43 (1) 58801-18804 (secretary), fax: +43 (1) 58801-18896
office@big.tuwien.ac.at, www.big.tuwien.ac.at
Literature

 The lecture is based on the following book:

UML @ Classroom:
An Introduction to Object-Oriented Modeling
Martina Seidl, Marion Scholz, Christian Huemer
and Gerti Kappel
Springer Publishing, 2015
ISBN 3319127411

 Use Case Diagram

 Structure Modeling
 State Machine Diagram
 Sequence Diagram
 Activity Diagram

© BIG / TU Wien 3
Introduction

 The use case is a fundamental concept of many object-oriented

development methods.
 Use case diagrams express the expectations of the
customers/stakeholders (Biểu đồ ca sử dụng thể hiện sự mong đợi của
khách hàng/các bên liên quan)
 essential for a detailed design
 The use case diagram is used during the entire analysis and design
process. (Biểu đồ ca sử dụng được sử dụng trong toàn bộ quá trình phân tích
và thiết kế)
 We can use a use case diagram to answer the following questions:
 What is being described? (The system.) : Hệ thống mô tả cái gì?
 Who interacts with the system? (The actors.): Các tác nhân tương tác với HT
 What can the actors do? (The use cases.): Các tác nhân làm gì với HT

© BIG / TU Wien 3
Example: Student Administration System

 System
(what is being described?)
 Student administration system <Hệ thống quản lý sinh viên>

 Actors (Các tác nhân)

(who interacts with the system?)
 Professor

 Use cases
(what can the actors do?)
 Query student data <Truy vấn dữ liệu sinh viên>
 Issue certificate <Cấp giấy chứng nhận>
 Announce exam <Thông báo kỳ thi>

© BIG / TU Wien 4
Use Case

 Mô tả chức năng mong đợi từ hệ thống đang được phát triển

 Cung cấp lợi ích hữu hình cho một hoặc nhiều tác nhân giao tiếp với ca
sử dụng (use case) này.
 Xuất phát từ những mong muốn của khách hàng đã thu thập được
 Tập hợp tất cả các trường hợp sử dụng mô tả chức năng mà một hệ
thống sẽ cung cấp.
 Ký hiệu

© BIG / TU Wien 5
Actor (1/3)

 Tác nhân tương tác với hệ thống

 Các tác nhân cung cấp chức năng để thực hiện các trường hợp sử
dụng.
 Các tác nhân trực tiếp thực hiện các ca sử dụng.
 Các tác nhân đại diện cho các vai trò mà người dùng chấp nhận.
 Các tác nhân không phải là một phần của hệ thống, tức là họ nằm
ngoài ranh giới của hệ thống.
 Ký hiệu :

6
Actor (2/3)
 Thông thường dữ liệu người dùng cũng được quản lý trong hệ thống.
Dữ liệu này được mô hình hóa trong hệ thống dưới dạng các đối tượng
và lớp
 Ví dụ: Tác nhân Assistant
 Tác nhân Trợ lý (Assistant) tương tác với Laboratory Assignment
(phân công Phòng thí nghiệm) của hệ thống bằng cách sử dụng
nó.
 Lớp Assistant mô tả các đối tượng đại diện cho dữ liệu người dùng
(Tên,…)

© BIG / TU Wien 7
Actor (3/3)
 Human
 E.g., Student, Professor
 Non-human
 E.g., E-Mail Server
 Primary: có lợi ích chính của việc thực hiện trường hợp sử dụng
 Secondary: không nhận được lợi ích trực tiếp
 Active: Tham gia trực tiếp thực hiện ca sử dụng
 Passive: Cung cấp chức năng cho ca sử dụng được thực hiện
 Ví dụ:
Human Human
Primary Primary
Active Active

Non- Human
human Secondary
Secondary Active
Passive 8
Mối quan hệ giữa Ca sử dụng và Tác nhân

 Các tác nhân được kết nối với các ca sử dụng thông qua các đường
liền nét (liên kết).
 Mỗi tác nhân phải giao tiếp với ít nhất một ca sử dụng.

8
9
Mối quan hệ giữa Ca sử dụng và Tác nhân

 Hành vi của một trường hợp sử dụng B (included use case) được tích
hợp trong hành vi của trường hợp sử dụng khác A (base use case)
Base use case: Ca sử dụng cơ sở

Included use case

 Ví dụ

© BIG / TU Wien 10
Mối quan hệ giữa Ca sử dụng và Tác nhân

 Hành vi của một trường hợp sử dụng (Extending use case) có thể được
tích hợp trong hành vi của một trường hợp sử dụng khác (Base use
case)
 Cả hai trường hợp sử dụng cũng có thể được thực hiện độc lập với
nhau. Base use case

Extending use case

 A quyết định liệu B có được thực hiện hay không.

 Các điểm mở rộng xác định tại điểm nào hành vi được tích hợp.
 Điều kiện xác định trong trường hợp nào hành vi được tích hợp.

© BIG / TU Wien 11
Mối quan hệ giữa Ca sử dụng và Tác nhân

 Extension points (các điểm mở rộng) có thể được viết trực tiếp trong
casử dụng.
 Ví dụ :

© BIG / TU Wien 12
Mối quan hệ giữa Ca sử dụng và Tác nhân
Generalization of Use Cases: Khái quát hóa các ca sử dụng

 Ca sử dụng A khái quát hóa ca sử dụng B.

 B kế thừa hành vi, đặc điểm của A và có thể mở rộng hơn
 B cũng kế thừa tất cả các mối quan hệ từ A.
 B chấp nhận chức năng cơ bản của A nhưng tự quyết định phần nào
của A được thực thi hoặc thay đổi.
 Ví dụ :
Base use case

Sub use case

© BIG / TU Wien 13
Mối quan hệ giữa các Tác nhân
Generalization of Actors: Khái quát hóa các tác nhân
 Tác nhân A kế thừa từ tác nhân B.
Super-
 A có thể giao tiếp với cả hai ca sử dụng X and Y.
actor
 B chỉ có thể giao tiếp với ca sử dụng Y. Sub-actor
 Cho phép sử dụng nhiều kế thừa
 Tác nhân trừu tượng là có thể (Abstract)
 Ví dụ :

Professor VÀ Assistant needed Professor OR Assistant needed

for executing Query student data for executing Query student data

© BIG / TU Wien
14
Description of Use Cases: Mô tả các ca sử dụng

 Structured approach (Cách tiếp cận có cấu trúc)

 Name
 Short description: Mô tả ngắn
 Precondition: Điều kiện tiên quyết để thực hiện thành công
 Postcondition (Hậu điều kiện): Trạng thái hệ thống sau khi thực hiện
thành công
 Error situations (Tình huống lỗi): Liên quan đến miền sự cố
 Trạng thái hệ thống khi xảy ra lỗi
 Actors that communicate with the use case: Các tác nhân giao tiếp với ca
sử dụng
 Trigger: Các sự kiện bắt đầu/bắt đầu ca sử dụng
 Standard process: Các bước riêng lẻ được thực hiện
 Alternative processes (Các quy trình thay thế): Sai lệch so với quy trình
chuẩn

© BIG / TU Wien 15
Description of Use Cases - Example
 Name: Khu giảng đường
 Short description: Một nhân viên đặt một giảng đường tại trường đại học cho một sự kiện.
 Precondition: Nhân viên được phép đặt trước giảng đường.
 Postcondition: Một giảng đường được đặt trước.
 Error situations: Không có giảng đường miễn phí.
 System state in the event of an error: Nhân viên chưa đặt chỗ giảng đường.
 Actors: Nhân viên
 Trigger: Nhân viên yêu cầu một giảng đường.
 Standard process:
(1) Nhân viên đăng nhập vào hệ thống.
(2) Nhân viên chọn giảng đường.
(3) Nhân viên chọn ngày.
(4) Hệ thống xác nhận giảng đường trống.
(5) Nhân viên xác nhận đặt chỗ.
 Alternative processes:
(4’) Giảng đường không miễn phí.
(5’) Hệ thống đề xuất một giảng đường thay thế.
(6’) Nhân viên chọn giảng đường thay thế và xác nhận đặt chỗ.

© BIG / TU Wien 16
Best Practices
«include»

UML standard Best practice

© BIG / TU Wien 17
Best Practices
Identifying Actors: Xác định các tác nhân

 Who uses the main use cases? : Ai quan tâm đến các các ca sử dụng chính?
 Who needs support for their daily work? : Ai cần hỗ trợ cho công việc hàng
ngày của họ?
 Who is responsible for system administration? : Ai chịu trách nhiệm quản trị
hệ thống?
 What are the external devices/(software) systems with which the system must
communicate? : Hệ thống thiết bị/(phần mềm) bên ngoài mà hệ thống phải
giao tiếp là gì?
 Who is interested in the results of the system? : Ai quan tâm đến kết quả của
hệ thống?

© BIG / TU Wien 19
Best Practices
Identifying Use Cases: Xác định các ca sử dụng

 Các nhiệm vụ chính mà một tác nhân phải thực hiện là gì?
 Tác nhân có muốn truy vấn hoặc thậm chí sửa đổi thông tin có trong hệ
thống không?
 Một tác nhân có muốn thông báo cho hệ thống về những thay đổi trong
các hệ thống khác không?
 Một tác nhân có nên được thông báo về các sự kiện bất ngờ trong hệ
thống không?

© BIG / TU Wien 20
Best Practices
Typical Errors To Avoid (1/5)

 Use case diagrams do not model processes/workflows! (Biểu đồ ca sử dụng

không mô hình hóa các quy trình/luồng công việc!)

 Các tác nhân không phải là một phần của hệ thống, do đó, chúng được đặt
bên ngoài ranh giới hệ thống!

© BIG / TU Wien 21
Best Practices
Typical Errors To Avoid (3/5)

 Ca sử dụng “Issue information” cần một tác nhân “Assistant” HOẶC

“Professor” để thực hiện


 Nhiều ca sử dụng nhỏ có cùng mục tiêu có thể được nhóm lại để tạo thành một
ca sử dụng lớn hơn

© BIG / TU Wien
 23
Best Practices
Typical Errors To Avoid (5/5)

 Các bước khác nhau là một phần trong các ca sử dụng, không phải là
các trường hợp sử dụng riêng biệt. Do đó KHÔNG phân rã chức năng


© BIG / TU Wien 25
Ký hiệu (1/2)

Name Notation Description

Boundaries between the system and the

System users of the system (Ranh giới giữa hệ
thống và người sử dụng hệ thống)

Use case Đơn vị chức năng của hệ thống

Actor Vai trò của người sử dụng hệ thống

© BIG / TU Wien 40
Ký hiệu (2/2)

Name Notation Description

Relationship between use cases

Association
and actors (Quan hệ kết nối)

Mối quan hệ kế thừa giữa các tác

Generalization
nhân hoặc ca sử dụng

Extend B extends A: optional use of use

relationship case B by use case A

Include A includes B: required use of use

relationship case B by use case A

© BIG / TU Wien 41