Bài giảng Mô hình hóa phần mềm - Tuần 2: Use Case Diagram - Nguyễn Thị Minh Tuyền

MÔ HÌNH HOÁ PHẦN MỀM  
TUẦN 2:  
USE CASE DIAGRAM  
GVLT: NGUYỄN THỊ MINH TUYỀN  
NỘI DUNG  
1.Giới thiệu  
2.Các thành phần  
3.Mô tả use case  
4.Best practices  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
2
NỘI DUNG  
1.Giới thiệu  
2.Các thành phần  
3.Mô tả use case  
4.Best practices  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
3
GIỚI THIỆU  
• Use case là một khái niệm nền tảng của nhiều phương pháp phát  
triển hướng đối tượng.  
• Các biểu đồ use case biểu diễn mong muốn của khách  
hàng/stakeholders  
• Cần thiết cho một thiết kết chi tiết  
• Biểu đồ use case được dùng trong suốt quá trình phân tích và thiết  
kế.  
• Ta có thể sử dụng biểu đồ use case để trả lời các câu hỏi sau:  
• Cái gì đang đượ
• Ai tương tác với hệ thống? (các actor)  
• Các actor có thể làm gì? (các use case)  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
4
VÍ DỤ: STUDENT ADMINISTRATION  
• Hệ thống (Cái gì đang được mô tả?)  
• Student Administration  
• Các actor (Ai tương tác với hệ thống?)  
• Professor  
• Các use case (Các actor có thể làm gì?)  
• Query student data  
• Issue certificate  
• Announce exa
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
5
NỘI DUNG  
1.Giới thiệu  
2.Các thành phần  
3.Mô tả use case  
4.Best practices  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
6
USE CASE  
• Mô tả chức năng mong đợi từ hệ thống đang phát triển.  
• Cung cấp một lợi ích hữu hình cho một hoặc nhiều actor tương tác  
với use case này.  
• Xuất phát từ các hách hàng  
• Tập hợp tất cả các use case mô tả chức năng mà hệ thống sẽ  
cung cấp à có thể được sử dụng làm tài liệu về chức năng mà hệ  
thống cung cấp  
• Các ký hiệu thay thế:  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
7
ACTOR [1]  
• Các actor tương tác với hệ thống ...  
• bằng cách sử dụng các use case, nghĩa là các actor bắt đầu thực  
hiện các use case  
• bằng cách được sử dụng bởi các use case, nghĩa là các actor cung  
cấp chức năng cho việc thực thi của các use case  
• Các actor biểu diễn vai trò mà user (người dùng) chấp nhận.  
• Các user có thể chấp nhận và thiết lập nhiều vai trò cùng lúc.  
• Các actor không phải là một phần của hệ thống, nghĩa là họ nằm  
ngoài ranh giới hệ thống.  
• Ký hiệu thay thế:  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
8
ACTOR [2]  
• 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 hoá trong hệ thống dưới dạng  
các đối tượng và các lớp.  
• Ví dụ: Actor Assistant  
• Actor Assistant tương tác với hệ thống Laboratory Assignment  
bằng cách sử dụng nó.  
• Lớp Assistant mô tả các đối tượng biểu diễn dữ liệu người dùng (ví  
dụ: name, ssNr, ...)  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
9
CÁC LOẠI ACTOR  
• Human  
• Ví dụ: Student, Professor  
• Non-human  
• Ví dụ: E-Mail Server  
• Primary: nhận lợi ích trực tiếp từ việc thực hiện use case  
• Secondary: không nhận lợi ích trực tiếp  
• Active: bắt đầu thực hiện use case  
• Passive: cung cấp chức năng để thực hiện use case  
Primary  
Active  
Human  
Primary  
Active  
Non-human  
Secondary  
Passive  
Human  
Secondary  
Active  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
10  
QUAN HỆ GIỮA USE CASE VÀ ACTOR  
• Các actor được kết nối với use case bằng các đường thẳng  
(association – liên kết): actor giao tiếp với hệ thống và sử dụng một  
chức năng nào đó.  
• Mỗi actor phải giao tiếp với ít nhất một use case.  
• Một association lột use case và một  
actor  
• Multiplicity có thể được xác định  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
11  
QUAN HỆ GIỮA CÁC USE CASE  
• Hành vi của một use case (included use case) được tích hợp vào  
hành vi của một use case khác (base use case).  
Base use case  
yêu cầu hành vi của included use case  
có khả năng cung cấp chức năng của nó  
Included use case  
có thể tự thực thi  
• Ví dụ:  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
12  
QUAN HỆ GIỮA CÁC USE CASE  
• Hành vi của một use case (extending use case) có thể được tích hợp  
vào hành vi của một use case khác (base use case) nhưng không  
bắt buộc.  
• Cả hai use case có thể được thực thi độc lập với nhau.  
Base use case  
• B có thể được kích hoạt bởi A  
Extending use case  
để thêm hành vi củ
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
13  
QUAN HỆ GIỮA HAI USE CASE  
• Một condition là điều kiện phải  
thoả mãn để base use case tích  
hợp hành vi của extending use  
case.  
• Các điểm mở rộng (Extension  
point) định nghĩa điểm mà tại đó  
hành vi của extending use case  
phải được tích hợp vào base use  
case.  
• Các điểm mở rộn
tiếp trong use case.  
• Có thể đặc tả nhiều điểm mở  
rộng.  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
14  
QUAN HỆ GIỮA CÁC USE CASE  
• Use case A tổng quát hơn use case B.  
Base use case  
Sub use case  
• B kế thừa hành vi của A và có thể  
hoặc mở rộng hoặc ghi đè lên nó.  
• B cũng có thể kế
hệ từ A.  
• B sử dụng 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.  
• A có thể được gán nhãn {abstract}  
• Không thể được thực thi trực tiếp  
• Chỉ B có thể thực thi được.  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
15  
QUAN HỆ GIỮA CÁC ACTOR  
• Actor A kế thừa từ actor B.  
• A có thể giao tiếp với X và Y.  
• B chỉ có thể giao tiếp với Y.  
• Cho phép đa kế thừa.  
• Có thể có abstract actor.  
• Ví dụ:  
Super-actor  
Sub-actor  
Professor AND Assistant  
cần thực hiện Query student data  
Professor OR Assistant cần thực hiện  
Query student data  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
16  
VÍ DỤ  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
17  
NỘI DUNG  
1.Giới thiệu  
2.Các thành phần  
3.Mô tả use case  
4.Best practices  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
18  
MÔ TẢ USE CASE  
Phương pháp có cấu trúc  
• Name  
• Short description  
• Precondition: prerequisite for successful execution  
• Postcondition: system state after successful execution  
• Error situations: errors relevant to the problem domain  
• System state on the occurrence of an error  
• Actors that communicate with the use case  
• Trigger: events which initiate/start the use case  
• Standard proce
• Alternative processes: deviations from the standard process  
[A. Cockburn: Writing Effective Use Cases, Addison Wesley, 2000]  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
19  
VÍ DỤ  
Name  
Reserve lecture hall  
Short description  
Precondition  
Postcondition  
Error situations  
An employee reserves a lecture hall at the university for an event.  
The employee is authorized to reserve lecture halls.  
A lecture hall is reserved.  
There is no free lecture hall.  
System state in the  
event of an error  
The employee has not reserved a lecture hall.  
Actors  
Trigger  
Employee  
Employee requires a lecture hall.  
(1) Employee logs in to the system.  
(2) Employee selects the lecture hall.  
(3) Employee selects the date.  
Standard process  
(4) System confirms that the lecture hall is free.  
(5) Employee confirms the reservation.  
(4’) Lecture hall is not free.  
Alternative processes  
(5’) System proposes an alternative lecture hall.  
(6’) Employee selects alternative lecture hall and confirms the reservation.  
MÔ HÌNH HOÁ PHẦN MỀM  
NGUYỄN THỊ MINH TUYỀN  
20  
Tải về để xem bản đầy đủ
pdf 35 trang yennguyen 19140 Free
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Mô hình hóa phần mềm - Tuần 2: Use Case Diagram - Nguyễn Thị Minh Tuyền", để tải tài liệu gốc về máy hãy click vào nút Download ở trên

File đính kèm:

  • pdfbai_giang_mo_hinh_hoa_phan_mem_tuan_2_use_case_diagram_nguye.pdf