Bài giảng Phân tích thiết kế hướng đối tượng - Chương 3: Mô hình Use Case

8/30/2017
1
Chương 3.
Mô hình Use Case
GV: Lê Thị Minh Nguyện
Email: nguyenltm@huflit.edu.vn
Phân tích thiết kế hướng đối tượng 1
Nội dung
1. Giới thiệu Use case
2. Các khái niệm mô hình hóa UC
3. Luồng sự kiện trong UC 
Phân tích thiết kế hướng đối tượng 2
1. Giới thiệu Use case
Phân tích thiết kế hướng đối tượng 3
MUA
SODA
1. Giới thiệu Use case
Phân tích thiết kế hướng đối tượng 4
Đưa tiền
Lựa sản phẩm
Lấy sản phẩm
8/30/2017
2
1. Giới thiệu Use case
Phân tích thiết kế hướng đối tượng 5
Đưa tiền
Lựa sản phẩm
Không có SP
1. Giới thiệu Use case
Phân tích thiết kế hướng đối tượng 6
Giả sử tôi quyết định mua một chiếc máy fax mới
Loại máy nào sẽ được chọn đây?
Tôi tự hỏi thật chính xác mình muốn làm gì với chiếc máy fax sẽ mua?
Tôi muốn có những tính năng nào?
Tôi muốn dùng bằng giấy thường hay giấy thermal?
Tôi muốn copy bằng cái máy đó?
Tôi muốn nối nó với máy tính của mình?
Tôi muốn dùng nó vừa làm máy fax vừa làm scanner?
Tôi có cần phải gởi fax thật nhanh đến mức độ cần một chức năng chọn số tăng tốc?
Liệu tôi có muốn sử dụng máy fax này để phân biệt giữa một cú điện thoại gọi tới và một
bản fax gởi tới ?.
1. Giới thiệu Use case
Phân tích thiết kế hướng đối tượng 7
Giả sử tôi quyết định mua một chiếc máy fax mới
Loại máy nào sẽ được chọn đây?
Tôi tự hỏi thật chính xác mình muốn làm gì với chiếc máy fax sẽ mua?
Tôi muốn có những tính năng nào?
Tôi muốn dùng bằng giấy thường hay giấy thermal?
Tôi muốn copy bằng cái máy đó?
Tôi muốn nối nó với máy tính của mình?
Tôi muốn dùng nó vừa làm máy fax vừa làm scanner?
Tôi có cần phải gởi fax thật nhanh đến mức độ cần một chức năng chọn số tăng tốc?
Liệu tôi có muốn sử dụng máy fax này để phân biệt giữa một cú điện thoại gọi tới và một
bản fax gởi tới ?.
2. Các khái niệm mô hình hóa UC
2.1. Tác nhân (Actor)
2.2. Use case-UC
2.3. Ví dụ xác định Actor và Use case
2.4. Quan hệ (Relationship)
2.5. Biểu đồ Use Case (Use case Diagram)
Phân tích thiết kế hướng đối tượng 8
8/30/2017
3
2.1. Actor
• Tác nhân (actor) biểu diễn bất cứ thứ gì tương tác
với hệ thống.
• Là đối tượng bên ngoài tương tác với hệ thống theo 3 
hình thức:
• Tương tác trao đổi thông tin với hệ thống hoặc sử dụng
chức năng.
• Cung cấp đầu vào hoặc nhận thông tin đầu ra từ hệ thống.
• Không điều khiển hoạt động của hệ thống.
• Có thể là người, máy móc hoặc hệ thống khác mà
chúng ta không phải xây dựng
• Ví dụ như các thiết bị ngoại vi, thậm chí là database
9
Actor
KhachHang
2.1. Actor
• Đặt các câu hỏi sau để tìm ra tác nhân:
• Nhóm người nào yêu cầu hệ thống làm việc giúp họ?
• Nhóm người nào kích hoạt chức năng của hệ thống?
• Nhóm người nào sẽ duy trì và quản trị hệ thống hoạt động?
• Hệ thống có tương tác với các thiết bị ngoại vi hay phần mềm
nào khác không?
• Hệ thống đang xây dựng tương tác với hệ thống khác nào?
• Thông tin về tác nhân:
• Tên tác nhân phải mô tả vai trò của tác nhân đó một cách rõ ràng
• Tên nên là danh từ
• Cần mô tả khái quát khả năng của tác nhân đó
10
Tìm kiếm tác nhân của hệ thống
2.2. Use Case (UC)
• Use case (Chức năng): Mô tả chức năng mà hệ thống có
• Mỗi Use-Case biểu diễn cho một chức năng của hệ thống
• Use-Case là một chuỗi bao gồm nhiều hành động
• Mỗi Use-Case có thể mở rộng (extext) thành nhiều Use-Case 
khác
• Mỗi Use-Case có thể bao hàm (include) nhiều Use-Case khác
• Use-Case được đặt bên trong phạm vi hệ thống
• Ký hiệu: hình elip + tên Use-Case (động từ)
Phân tích thiết kế hướng đối tượng 11
Mượn sáchUse Case
2.2. Use Case (UC)
• Xem các yêu cầu chức năng để tìm ra các UC
• Đối với mỗi tác nhân tìm được, đặt các câu hỏi sau để tì ra các Use 
case hệ thống.
• Các tác nhân yêu cầu hệ thống thực hiện chức năng nào
• Các công việc chính(đọc, ghi, tạo lập, bãi bỏ, sửa đổi) mà tác nhân đó muốn
HT thực thi?
• Tác nhân đó có tạo ra hay thay đổi dữ liệu gì của HT?
• Tác nhân đó có phải thông báo gì cho HT?
• Tác nhân đó có cần thông tin thông báo gì từ HT?
• Thông tin về use case:
• Tên của UC nên chỉ rõ kết quả của quá trình tương tác với tác nhân
• Tên nên là động từ
• Mô tả ngắn gọn về mục đích của UC
Phân tích thiết kế hướng đối tượng 12
Tìm kiếm Use Case của hệ thống
8/30/2017
4
Những điều nên tránh khi tạo Use Case
• Tạo ra các UC quá nhỏ
• Hành động quá đơn giản mà chỉ cần mô tả bởi vài dòng
• Tạo ra quá nhiều Use case (hàng chục)
• Nhóm các Use case liên quan thành một Use case tổng quát
(mức 1)
• Mô tả các Use Case tổng quát ở một sơ đồ khác (mức 2)
• Ví dụ: “Quản lý sách” bao gồm “Nhập sách”, “Xuất sách”, “”
• Sử dụng các Use-case quá cụ thể, hoặc làm việc với dữ liệu quá cụ
thể. Ví dụ:
• “Tìm sách theo tên” (nên là “Tìm sách”)
• “Nhập Pin vào máy ATM” (nên là “Nhập PIN”)
• “Thêm sách” (nên là “Quản lý sách” bao gồm “Thêm sách”)
Phân tích thiết kế hướng đối tượng 13
Ranh giới giữa hệ hệ thống và thế giới thực
Phân tích thiết kế hướng đối tượng 14
Subject/System boundary:
Chỉ ra ranh giới (boundary) giữa system và thế giới  ... oán Paypal
Phân tích thiết kế hướng đối tượng 15
Ví dụ: Xác định tác nhân và Use Case
Phân tích thiết kế hướng đối tượng 16
8/30/2017
5
Ví dụ: Xác định tác nhân và Use Case
Phân tích thiết kế hướng đối tượng 17
Phân loại Actor
Xác định Use Case
Phân tích thiết kế hướng đối tượng 18
• Xét hệ thống website có các chức năng sau:
• Khách hàng đăng ký tài khoản và mua sản phẩm
• Chủ cửa hàng duyệt các đơn hàng và đăng ký sản phẩm
• Hệ thống website có chức năng xuất báo cáo ra tập tin excel sử dụng phần
mềm MS Excel
• Hệ thống hỗ trợ khách hàng trực tuyến bằng cách trao đổi trực tiếp bằng âm
thanh của micro
• Hệ thống có khả năng giao tiếp với thiết bị đọc mã vạch để phục vụ cho việc
nhập thông tin sản phẩm
• Hệ thống hỗ trợ thanh toán trực tuyến thông qua việc kết nối với Hệ thống
thanh toán Paypal
Xác định Use Case
Phân tích thiết kế hướng đối tượng 19
2.3. Quan hệ (Relationship)
• Association
• Include
• Extend
• Generalization/Specializtion
Phân tích thiết kế hướng đối tượng 20
8/30/2017
6
Association
• Association
• Là mối liên hệ giữa actors và
use cases
• Thể hiện tương tác giữa
actors và use cases
• Đôi khi có mũi tên (thể hiện
hướng thực thi)
• Một use case được bắt đầu
bởi một tác nhân để gọi một
chức năng nào đó trong hệ
thống.
Phân tích thiết kế hướng đối tượng
21
Include
• Cho phép một UC sử dụng chức năng của UC khác
• Chức năng của UC Inclusion sẽ bắt buộc được gọi trong
UC Base
• Sử dụng stereotype là >
Phân tích thiết kế hướng đối tượng 22
Include
Phân tích thiết kế hướng đối tượng 23
UC rút tiền
1.Gọi UC xác thực KH 
2.Hiển thị menu 
3.KH chọn chức năng rút tiền
UC xác thực KH 
2. Kiểm tra thẻ
1. Đưa thẻ vào máy
3. KH nhập pin
4. Hệ thống kiểm tra pin 
E1: Thẻ sai.
E2: sai pin
Khi nào thì dùng quan hệ >
• Tách ra hành vi (chức năng) chung của 2 hoặc nhiều UC
• Tránh việc mô tả hành vi đó nhiều lần trong các UC
• Đảm bảo nhưng hành vi chung đó được thống nhất
• Tách ra hành vi của UC cơ sở nên được đóng gói riêng
(encapsulate)
• Tách hành vi không phải là chính của UC đó (hành vi ít quan trọng)
• Giảm thiểu sự phức tạp của luồng sự kiện
Phân tích thiết kế hướng đối tượng 24
8/30/2017
7
>
• Cho phép mở rộng chức năng của một UC
• Chèn hành vi của UC Extension vào UC Base
• Chỉ chèn khi điều kiện extend đúng (mở rộng, phát sinh) (Khi
thực hiện thực hiện UC Base thì thực hiện UC extension ở một
số tình huống nào đó, chứ không bắt buộc)
• Chèn vào lớp cơ sở tại điểm phát sinh (extension point)
• Sử dụng stereotype là >
Phân tích thiết kế hướng đối tượng 25
Khi nào dùng quan hệ mở rộng >
• Tách ra hành vi ngoại lệ, đặc biệt
hoặc không bắt buộc
• Chỉ được thực thi trong điều kiện
cụ thể
• Tách ra để làm đơn giản luồng
chính
• Thêm một hành vi mở rộng đối
với UC cơ sở.
• Phát triển hành vi đó độc lập
• Extension use case không bắt
buộc phải xảy ra
Phân tích thiết kế hướng đối tượng 26
Generalization/Specializtion
• Chỉ ra một vài tác nhân hay UC có
một số cái chung, giống nhau.
• Không nhất thiết hình thành quan
hệ này cho các tác nhân.
• Khi một loại tác nhân kích hoạt một
hay vài UC mà loại tác nhân khác
không kích hoạt -> nên hình thành
quan hệ khái quát hóa
• Khi cả hai loại tác nhân cùng sử dụng
các UC -> không cần mô hình hóa
quan hệ khái quát hóa
Phân tích thiết kế hướng đối tượng 27
Tạo các gói
Phân tích thiết kế hướng đối tượng 28
 Có thể nhóm các thành phần thành một nhóm chung
 Nếu số lượng UC quá lớn có thể chia chúng vào các nhóm
• Dễ hiểu mô hình tổng thể hơn
• Dễ bảo trì mô hình UC
• Dễ giao việc cho các thành viên
 Xem xét khả năng gộp nhóm
• Tương tác với cùng một tác nhân
• Nhóm UC hợp thành một module tương đối hoàn thiện
8/30/2017
8
Biểu đồ Use Case (Use case Diagram)
• Mô hình UC được mô tả bởi một hay nhiều biểu đồ UC
• Số lượng biểu đồ UC cho một dự án là tùy ý
• Không quá nhiều làm rối loạn
• Phải đảm bảo đầy đủ để biểu diễn đầy đủ thông tin của hệ thống
• Nó là công cụ mạnh giúp thu thập yêu cầu chức năng hệ thống
• Nó chỉ ra quan hệ giữa UC và tác nhân và giữa UC với nhau
• Sử dụng biểu đồ để làm tài liệu UC, tác nhân và các quan hệ giữa chúng.
• Lợi ích chính của biểu đồ UC là làm giao tiếp
• Khi quan sát các UC, customer biết hệ thống có các chức năng nào
• Khi quan sát các tác nhân, customer biết ai giao tiếp với hệ thống
• Khi quan sát cả UC và tác nhân, customer biết phạm vi dự án
Phân tích thiết kế hướng đối tượng 29
BÀI TẬP 1: TÌM USE CASE
Trần Thị Kim Chi 30
Hệ thống đặt vé máy bay
• Thiết kế một hệ thống đặt vé máy bay đơn giản cho một công ty hàng không
ABC với đặc tả như sau:
• Công ty hàng không ABC có các chuyến bay khác nhau. Ứng với một chuyến
bay, hệ thống được mở cho để khách hàng đặt vé và đóng đặt vé bởi nhân
viên của công ty.
• Một khách hàng có thể đặt một hoặc nhiều chuyến bay cho các hành khách
khác nhau.
• Một vé đặt cho một một chuyến bay duy nhất và một hành khách duy nhất.
• Một chuyến bay có một sân bay khởi hành và sân bay đến, thời điểm khởi
hành và thời điểm đến, có thể liên quan đến các chặng dừng tại sân bay. Một
điểm dừng chân có một thời điểm đến và thời điểm khởi hành.
• Việc đặt vé có thể được hủy bỏ hoặc được xác nhận.
Câu hỏi: Xác định mối quan hệ giữa các actor và use case
BÀI TẬP TÌM USE CASE
Trần Thị Kim Chi 31
Hệ thống đặt vé máy bay
Bài tập 2
• A company wants to develop a ticketing and
reservation system. This must support advance
booking of tickets, cancellation of tickets and change
of class of a ticket. All these are handled by a
Reservation Clerk.
• The system will also have a Web site where users
can register themselves and purchase tickets online.
They can pay either by using their online banking
account or by credit card. Reservations made over
the internet can only be cancelled across the counter.
The system will also have a querying facility that
allows users to check train time-tables, fares and
availability of tickets.
Phân tích thiết kế hướng đối tượng 32
8/30/2017
9
Ví dụ
Phân tích thiết kế hướng đối tượng 33
Ví dụ
Phân tích thiết kế hướng đối tượng 34
BÀI TẬP 3: Đăng ký học phần
• Là trưởng ban It của trường ĐH KHTN, bạn được yêu cầu phát
triển một hệ thống đăng ký học phần mới hệ thống mới cho
phép sinh viên đăng ký học phần và xem phiếu điểm từ máy
tính cá nhân được kết nối vào mạng nội bộ của trường. Các
giảng viên cũng có thể truy cập hệ thống này để đăng ký lớp
dạy và nhập điểm cho các môn học.
• Trường sẽ giữ lại CSDL sẵn có về danh mục học phần mà
trong đó lưu trữ toàn bộ thông tin về học phần. Đây là CSDL
quan hệ và có thể truy cập bằng các câu lệnh SQL thông qua các
server của trường. Hệ thống mới sẽ đọc các thông tin học
phần trên CSDL cũ nhưng sẽ không cập nhập chúng. Phòng
đào tạo sẽ tiếp tục duy trì các thông tin học phần thông qua
hệ thống khác.
Trần Thị Kim Chi 35
• Ở đầu mỗi học kỳ, sinh viên có thể yêu cầu danh sách các học
phần được mở trong học kỳ đó. Thông tin về mỗi học phần, ví
dụ như là tên giáo sư, khoa, và các môn học phần tiên quyết sẽ
được cung cấp để giúp sinh viên chọn lựa.
• Hệ thống mới cho phép sinh viên được chọn 4 học phần được
mở cho học kỳ tới. Mỗi sinh viên có thể đưa ra hai môn học
thay thế trong trường hợp không thể đăng ký theo nguyện
vọng chính. Các học phần được mở tối đa là 100 và tối thiểu là
30 sinh viên. Các học phần có ít hơn 30 sinh viên sẽ bị hủy
bỏ.
• Đầu mỗi học kỳ, sinh viên có một khoảng thời gian để thay đổi
các học phần đã đăng ký. Sinh viên chỉ có thể thêm hay hủy
các học phần đăng kí trong khoảng thời gian này.
Trần Thị Kim Chi 36
BÀI TẬP 3: Đăng ký học phần
8/30/2017
10
• Khi quá trình đăng ký đã hoàn tất cho mỗi sinh viên, hệ
thống đăng kí sẽ gửi thông tin tới hệ thống thanh toán
(billing system) để sinh viên có thể đóng học phí. Nếu
một lớp bị hết chỗ trong quá trình đăng ký, sinh viên sẽ
được thông báo về sự thay đổi trước khi xác nhận việc
đăng ký học
• Ở cuối học kỳ, sinh viên có thể truy cập vào hệ thống để
xem phiếu điểm. Vì thông tin về điểm của sinh viên phải
được giữ kín, nên hệ thống cần có cơ chế bảo mật để
ngăn cản việc truy cập không hợp lệ
• Các giảng viên có thể truy cập vào hệ thống để đăng ký
những học phần mà họ sẽ dạy. Họ có thể xem danh sách
các sinh viên đã đăng ký vào lớp của họ, cũng như nhập
điểm sau mỗi khóa học.
Trần Thị Kim Chi 37
BÀI TẬP 3: Đăng ký học phần
Lập bảng chú giải (Glossary) của ứng dụng Course
Registration:
• Course (Học phần): Một môn học được dạy trong
trường.
• Course Offering (Lớp): Một lớp học cụ thể được mở
trong mỗi học kỳ cụ thể cùng một học phần cụ thể được
mở song song nhiều lớp trong mỗi học kỳ. Thông tin gồm
cả ngày học trong tuần và giờ học.
• Course Catalog (Danh mục học phần): Danh mục đầy
đủ của tất cả các học phần được dạy trong trường.
• Faculty: Toàn bộ cán bộ giảng dạy của trường.
• Finance System (Hệ thống thanh toán): Hệ thống dùng
để xử lý các thông tin thanh toán học phí.
Trần Thị Kim Chi 38
BÀI TẬP 3: Đăng ký học phần
Lập bảng chú giải (Glossary) của ứng dụng Course Registration:
• Grade (Điểm số): Điểm của mỗi sinh viên trong một lớp cụ thể. 
• Professor (Giáo sư): Người giảng dạy trong trường.
• Report Card (Phiếu điểm): Toàn bộ điểm số cho tất cả học phần
một sinh viên đã học trong một học kỳ xác định.
• Roster (Danh sách sinh viên đăng ký): Tất cả sinh viên đăng ký vào
một lớp học cụ thể.
• Student (Sinh viên): Người đăng ký học các lớp của trường.
• Schedule (Lịch học): Các học phần mà sinh viên đã chọn học trong
học kỳ hiện tại.
• Transcript (Bản sao học bạ): Bản sao tất cả điểm cho tất cả các học
phần của một sinh viên cụ thể được chuyển cho hệ thống thanh toán
để hệ thống này lấp hóa đơn cho mỗi sinh viên.
Trần Thị Kim Chi 39
BÀI TẬP 3: Đăng ký học phần Bài tập 3: Đăng ký học phần
Hệ thống thư việnTrần Thị Kim Chi 40
Nhận diện actor
• Người dùng:
– Sinh viên (Student)
– Giáo sư (Professor)
– Nhân viên giáo vụ (Registrar)
• Hệ thống khác:
– Danh mục học phần (Course Catalog)
– Hệ thống thanh toán học phí (Billing System)
8/30/2017
11
Bài tập 3: Đăng ký học phần
Hệ thống thư việnTrần Thị Kim Chi 41
Nhận diện Use Case• Chức năng cho mọi actor:
– Đăng nhập hệ thống (Login) 
• Các chức năng sử dụng bởi Student:
– Đăng ký học phần (Register for Course)
– Xem phiếu điểm (View Report Card)
• Các chức năng sử dụng bởi Professor:
– Đăng ký môn dạy (Select Courses to Teach)
– Nộp điểm (Submit Grades)
• Nhiệm vụ của Registrar:
– Kết thúc đăng ký (Close Registration)
– Cập nhật thông tin giáo sư (Maintain Professor Information)
– Cập nhật thông tin sinh viên (Maintain Student Information)
Bài tập 1: Đăng ký học phần
Hệ thống thư việnTrần Thị Kim Chi 42
View Report Card
Student
Register for 
Courses
Submit Grades
Course Catalog 
Professor
Select Courses 
to Teach
Maintain 
Student Information
Maintain 
Professor Information
Billing System
Registrar
Close Registration
User
Login
Bài tập 4
Phân tích thiết kế hướng đối tượng 43
Vẽ lược đồ Use case cho một hệ thống quản lý thư viện
sách dựa trên các thông tin sau:
o Bạn đọc sẽ có các quyền như: gửi ý kiến phản hồi
cho thư viện, tìm kiếm tài liệu, quản lý thông tin cá
nhân, xem thông tin trả/mượn sách và đăng kí
mượn
o Các chức năng như quản lý thông tin các nhân,
xem thông tin trả/mượn và đăng kí mượn đòi hỏi
người dùng phải login vào hệ thống
o Khi đăng kí mượn ngoài việc đăng kí mượn trực
tiếp thì người dùng còn có thể đăng kí mượn online
Bài tập 4 (tt)
o Thủ thư sẽ có công việc như nhập mới thông tin sách,
đăng kí thông tin cho người dùng, thanh lý sách và chấp
nhận/từ chối cho bạn đọc mượn sách
o Thủ thư có công việc quản lý thông tin người dùng:
thêm, xóa hay chỉnh sửa thông tin
Phân tích thiết kế hướng đối tượng 44
8/30/2017
12
Bài tập 5 
• Vẽ lược đồ Usecase cho phần mềm luyện thi MOS:
o Người dùng sẽ có khả năng đăng kí tài khoản để
sử dụng phần mềm để luyện thi MOS
o Khi luyện thi MOS, người dùng có quyền luyện thi
MOS Word hoặc Excel (trước đó yêu cầu phải
login)
o Khi luyện thi Word/Excel, người dùng có thể chọn
lựa giữa xem thông tin từng câu hỏi, trả lời câu
hỏi hay bỏ qua câu hỏi
o Admin có quyền quản lý thông tin người dùng và
quản lý thông tin cho bộ câu hỏi
Phân tích thiết kế hướng đối tượng 45
Luồng sự kiện trong UC
• Tài liệu luồng sự kiện (flow of events) mô tả hành vi của UC
• Mô tả luồng logic đi qua UC
• Mô tả người sử dụng làm gì, hệ thống làm gì
• Trong một UC có nhiều luồng sự kiện: luồng chính, luồng phụ
• Kịch bản (Scenario)
• Một luồng sự kiện trong một hiện thực của UC
• Là trình tự hành động cụ thể để mô tả hành vi
• Kịch bản đi xuyên suốt UC theo nhánh chính, nhánh phụ, nhánh đặc biệt
Phân tích thiết kế hướng đối tượng 46
Xây dựng kịch bản cho luồng sự kiện
• Mô tả vắn tắt UC
• Mô tả ngắn gọn UC làm gì?
• Những ai sử dụng UC?
• Nó cho lại kết quả gì?
• Tiền điều kiện (pre-condition)
• Điều kiện cần thực hiện trước khi UC khởi động
• Không phải UC nào cũng có tiền điều kiện
• Luồng sự kiện chính và luồng sự kiện rẽ nhánh
• Hậu điều kiện (post-condition)
Phân tích thiết kế hướng đối tượng 47
Xây dựng kịch bản cho luồng sự kiện
Phân tích thiết kế hướng đối tượng 48
Tên use case Cập nhật từ điển môn học
Tên Actor Nhân viên phòng đào tạo
Tiền điều kiện Nhân viên phải đăng nhập hệ thống
Mục đích Cập nhật các môn học trong từ điển môn học
Mô tả
Sau khi đăng nhập vào hệ thống, nhân viên phòng đào tạo cập nhật
thông tin môn học vào biểu mẫu hoặc sửa môn học có sẵn và ghi lại.
Hành động tác nhân Phản ứng hệ thống
1. Chọn chức năng cập nhật từ điển môn học
2. Hiển thị biểu mẫu để nhập thông tin về các môn
học mới và hiển thị danh sách môn học để chọn môn
học tiên quyết cho môn học.
3. Nhập thông tin môn học, chọn môn học tiên
quyết, đồng ý nhập mới
4. Cập nhật môn học vào từ điển môn học
Luồng sự kiện phụ: sửa thông tin 
Ngoại lệ: Bước4: nếu thông tin nhập không chính xác thì yêu cầu nhập lại hoặc dừng use case sử dụng.
8/30/2017
13
Xây dựng kịch bản cho luồng sự kiện
Phân tích thiết kế hướng đối tượng 49
Tên use case Sửa đổi thông tin môn học
Tên Actor Nhân viên phòng đào tạo
Tiền điều kiện Nhân viên phải đăng nhập hệ thống
Mục đích Sửa các thông tin về một môn học đang tồn tại trong hệ thống
Mô tả
Tìm đến môn học cần sửa đổi, xóa các thông tin cũ và nhập các
thông tin mới về môn học này. Cuối cùng, yêu cầu hệ thống ghi
nhận các thông tin mới.
Hành động tác nhân Phản ứng hệ thống
Luồng sự kiện phụ: sửa thông tin 
Ngoại lệ: Bước4: nếu thông tin nhập không chính xác thì yêu cầu nhập lại hoặc dừng use case sử dụng.
Xây dựng kịch bản cho luồng sự kiện
Phân tích thiết kế hướng đối tượng 50
Ngoại lệ:
Bước4: Không có môn nào học nào thỏa điều kiện tìm kiếm thì thông báo không tìm được và yêu cầu tìm
lại hoặc dừng lại
Bước 8: Nếu thông tin sửa không chính xác thì yêu cầu sửa lại hoặc dừng Use case
Phân tích thiết kế hướng đối tượng 51