Bài giảng Phân tích và thiết kế hướng đối tượng - Bài 7: Thiết kế kiến trúc - Đỗ Ngọc Như Loan

7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Thiết kế kiến trúc 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 2 
Nội dung trước 
 Các biểu đồ 
 Activity Diagram 
 State Diagram 
 Component Diagram 
 Deployment Diagram 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 3 
Nội dung 
Thiết kế kiến trúc: 
 Tìm hiểu mục đích Thiết kế kiến trúc 
 Diễn giải về các cơ chế thiết kế, cài đặt và gán chúng 
từ giai đoạn phân tích. 
 Subsystems và interfaces 
Thiết kế Use-Case 
 Kiểm tra tính nhất quán trong Use- case 
 Tinh chỉnh Use-case realization 
Thiết kế Class 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Các loại cơ chế kiến trúc 
Các cơ chế phân tích (conceptual) 
Các cơ chế thiết kế (concrete) 
Các cơ chế cài đặt (actual) 
4 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Các cơ chế phân tích mẫu 
 Persistency: Cơ chế bền vững tồn tại lâu dài 
 Communication: Cơ chế trao đổi dữ liệu 
 Message routing: Cơ chế trao đổi thông điệp 
 Distribution: Cơ chế xử lý dữ liệu phân tán 
 Transaction management: Cơ chế quản lý giao tác 
 Process control and synchronization (resource contention): 
quản lý các tiến trình 
 Information exchange, format coversion: trao đổi dữ liệu với 
các phần mềm khác, chuyển đổi định dạng của dữ liệu 
 Security: cơ chế bảo mật 
 Error detection/ handling /reporting: cơ chế xử lý lỗi 
 Redundancy: cơ chế xử lý thông tin dư thừa 
 Legacy Interface: cơ chế giao tiếp với hệ thống đã tồn tại 
5 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Ví dụ 
 Các cơ chế phân tích sử dụng trong ứng 
dụng “Đăng ký học phần: 
Persistency 
Security 
Distribution 
Legacy Interface 
6 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Ví dụ 
 Ánh xạ các Analysis-Class với các cơ chế kiến trúc có từ 
bước phân tích Use-case 
7 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Cơ chế thiết kế và cài đặt 
8 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Cơ chế Persistence 
 Mô tả các hành vi liên quan đến cơ chế 
Persistence 
 Mô hình hóa các Transaction 
 Lưu (ghi) các Persistent Object 
 Đọc các Persistent Object 
 Hủy các Persistent Object 
9 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Thiết kế kiến trúc 
 Thiết kế lớp: thiết kế thuộc tính, method và mối kết hợp 
 Kiến trúc ba tầng trong thiết kế phần mềm 
 Thiết kế use case 
 Quá trình thiết kế các lớp tầng truy cập dữ liệu: xác định các lớp, 
thuộc tính, method và mối kết hợp qua việc phân tích use case 
 Thiết kề các lớp tầng giao diện: xác định các lớp, xây dựng bản mẫu 
(prototype), xác định thuộc tính và method qua việc phân tích use 
case 
 Mô hình hoá use case hiện thực hoá dùng sơ đồ lớp, sơ đồ tương tác 
 Nâng cấp kiến trúc bằng việc phân chia hệ thống thành các 
gói (package) 
10 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Kiến trúc 3 tầng 
11 
Tầng giao diện người dùng 
(user interface layer), 
Tầng tác nghiệp 
(business layer), 
Tầng truy cập dữ liệu 
(data layer). 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Kiến trúc mở rộng 
12 
Tầng Middleware: chứa các thành phần 
xây dựng giao diện với các CSDL 
(ODBC/JDBC driver) 
Tầng System software: chứa các thành 
phần về hệ điều hành, giao diện tới các 
phần cứng (ví dụ: các driver phần cứng cụ 
thể), v.v 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Xác định lớp ở tầng tác nghiệp 
 Các class ở tầng tác nghiệp không nên quan tâm đến cách 
thức nó được hiển thị và được hiển thị bởi ai. Các đối tượng 
này được thiết kế để độc lập với bất kỳ một giao diện cụ 
thể, và vì vậy cách thức chi tiết để hiển thị một đối tượng 
nên tồn tại trong tầng giao diện thay vì trong tầng tác 
nghiệp. 
 Các đối tượng ở tầng tác nghiệp cũng không nên quan tâm 
đến nguồn gốc của nó hình thành. Có nghĩa là các đối 
tượng này sẽ độc lập về dữ liệu của nó được lấy từ truy cập 
CSDL hay là từ truy xuất tập tin. 
13 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Ví dụ 
14 
S
ơ
 đ
ồ
 l
ớ
p
 c
ủ
a
 h
ệ
 t
h
ố
n
g
 A
T
M
 t
ầ
n
g
 n
g
h
iệ
p
 v
ụ
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
User interface layer 
 Các class ở tầng này đảm nhận hai công việc chính: 
 Trả lời tương tác người dùng: các đối tượng mức này 
phải được thiết kế để chuyển dịch những hành động 
của người dùng tới một tình huống xử ly ́ phù hợp. Có 
thể là mở hoặc đóng một giao diện khác, hoặc gởi 
một thông điệp xuống tầng tác nghiệp hoặc khởi động 
một vài tiến trình ở tầng tác nghiệp 
 Hiển thị các đối tượng tác nghiệp: tầng này phải trình 
bày một hình ảnh tốt nhất các đối tượng tác nghiệp 
tới người dùng trong một giao diện. Điều này có 
nghĩa là một hình ảnh trực quan thao tác được có thể 
bao gồm: các textbox, listbox, commbobox, page, 
form, menu, toolbar, . 
15 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
User interface layer 
Xác định các lớp tầng giao diện: 
 Xây dựng sơ đồ lớp mô tả các đối tượng giao 
diện 
 Tạo bản mẫu giao diện (prototype) 
 Xác định hành vi và thuộc tính cho các lớp 
giao diện 
 Yêu cầu đọc thêm tài liệu về thiết kế giao diện 
16 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Xác định lớp ở tầng truy cập dữ liệu 
 Đối tượng tầng này phải truy cập vật lý CSDL ở các vị trí 
(CSDL quan hệ, tập tin, internet,) và xử lý nó. Hai nhiệm 
vụ chính của tầng này là: 
 Chuyển dịch các yêu cầu: chuyển dịch tất cả các yêu cầu 
liên quan đến dữ liệu từ tầng tác nghiệp đến một phương 
thức truy cập dữ liệu thích hợp (dạng SQL, truy xuất 
file,) 
 Chuyển dịch kết quả: chuyển dịch tất cả dữ liệu truy cập 
được tới các đối tượng tác nghiệp thích hợp. 
17 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Xác định các đối tượng lưu trữ và persistence 
 Mỗi dữ liệu sẽ có một thời gian sống (lifetime) khác nhau 
 phân loại: 
 Là kết quả tạm thời để đánh giá một biểu thức 
 Các biến trong quá trình thực thi một thủ tục (các tham 
số và biến trong phạm vi cục bộ) 
 Các biến toàn cục và các biết cấp phát một cách tự 
động 
 Dữ liệu tồn tại giữa các lần thực thi một chương trình 
 Dữ liệu tồn tại giữa các phiên bản của một chương 
trình 
 Dữ liệu tồn tại vượt ngoài phạm vi sống của một 
chương trình 
18 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Xác định các đối tượng lưu trữ và persistence 
Các loại dữ liệu persistent sẽ được quản lý bởi hệ 
quản trị cơ sở dữ liệu hoặc hệ thống lưu trữ tập 
tin. (3 loại sau) 
Ba loại dữ liệu đầu tiên đều gọi là dữ liệu tạm thời 
(transient data). Là dữ liệu có thời gian sống phụ 
thuộc vào thời gian sống của tiến trình sử dụng 
nó. Khi tiến trình kết thúc thì dữ liệu này bị giải 
phóng 
 19 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Chuyển đổi các đối tượng RDBMS 
Các thành phần tương ứng như sau: 
 Một cột ứng với một thuộc tính (persistent) lớp 
 Một dòng của bảng ứng với một đối tượng (thể 
hiện của một lớp) 
 Một thủ tục lưu trữ nội (stored procedure) có 
thể tương ứng với một method. 
20 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Ví dụ 
 Các bước được thiết kế 
 Tạo các DBClass cần thiết 
• DBClass / persistent class 
 Tích hợp các DBClass vào thiết kế 
• Xếp đặt vào package/layer 
• Thêm các mối quan hệ từ các persistency client 
 Tạo/cập nhật interaction diagram để diễn tả: 
• Database initialization 
• Persistent class access: Create, Read, Update, Delete 
21 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Persistency: RDBMS: JDBC 
22 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Persistency: RDBMS: JDBC: Khởi tạo 
23 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Persistency: RDBMS: JDBC: Create 
24 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Persistency: RDBMS: JDBC: Read 
25 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Persistency: RDBMS: JDBC: Update 
26 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Persistency: RDBMS: JDBC: Delete 
27 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Nâng cấp kiến trúc 
 Các analysis class phức : 
 Tách thành nhiều class 
 Trở thành một package 
 Trở thành một subsystem (phức tạp). 
 Các analysis class đơn giản có thể trở 
thành một design class 
28 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Package: Tính khả kiến của các phần tử 
29 
Chỉ các public class 
mới được tham 
chiếu từ bên ngoài 
package sở hữu nó 
Nguyên lý OO: Encapsulation 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Subsystem 
 Một dạng trung gian giữa package (có thể chứa các phần tử 
khác) và class (có hành vi) 
 Hiện thực hoá 1 hoặc nhiều interface, định nghĩa hành vi của 
nó 
30 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Subsystem & Interface 
 Hoàn toàn đóng gói hành vi 
 Thể hiện một khả năng hoàn toàn độc lập, với các 
interface rõ ràng (có tiềm năng tái sử dụng) 
 Mô hình hoá nhiều phương án cài đặt khác nhau 
31 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Package & Subsystem 
Subsystem cung cấp hành vi, package không 
Subsystem hoàn toàn đóng gói nội dung của nó, 
package thì không 
Subsystem dễ dàng được thay thế 
32 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Subsystem 
 Subsystem có thể dùng để chia system thành các phần độc 
lập về: 
 Thứ tự, cấu hình, hoặc vận chuyển 
 Phát triển, chừng nào mà interface còn chưa thay đổi 
 Triển khai trên các node tính toán phân tán 
 Thay đổi mà không phá vỡ các phần khác của system 
 Subsystem còn có thể dùng để: 
 Phần chia system thành các đơn vị cung cấp độ bảo mật 
cao đối với các tài nguyên then chốt 
 Biểu diễn các sản phẩm có sẵn hoặc các system nằm 
ngoài bản thiết kế (chẳng hạn như các component) 
33 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Xác định subsystem 
Tìm kiếm sự cộng tác giữa các đối tượng 
Chú ý user interface của system 
Chú ý các Actor 
Tìm kiếm sự kết dính giữa các class 
Xem xét sự phân bố 
34 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Tìm kiếm các subsystem 
 Các Analysis classes có thể tiến hoá thành các subsystem 
 Các Class cung cấp các dịch vụ và/hoặc các tiện ích trọn vẹn 
 Các Boundary class (user interface và external system interface) 
 Các sản phẩm sẵn có hoặc các system nằm ngoài thiết kế 
 Communication software 
 Database access support 
 Các kiểu và cấu trúc dữ liệu 
 Các tiện ích dùng chung 
 Các sản phẩm ứng dụng đặc thù 
35 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Identifying Interface 
 Dựa vào nhiệm vụ của các subsystem 
 Xác định một tập các interface tiềm năng cho tất 
cả các subsystem 
 Tìm kiếm sự tương tự giữa các interface 
 Định nghĩa các phụ thuộc của interface 
 Ánh xạ các interface đến các subsystem 
 Định nghĩa hành vi được mô tả bới interface 
 Đóng gói các interface 
36 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Interface Guidelines 
 Đặt tên cho Interface 
 Thể hiện vai trò trong system 
 Mô tả Interface 
 Chuyển tải các nhiệm vụ 
 Định nghĩa Operation 
 Tên phải phản ánh đúng kết quả của operation 
 Mô tả operation được thực hiện, tất cả các tham số và 
kết quả 
 Interface documentation 
 Package các thông tin hỗ trợ: sequence và state 
diagrams, kế hoạch kiểm chứng, . 
37 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Ví dụ: Design Subsystem 
38 
Design Analysis 
Tất cả các analysis class khác đều chuyển thành design class 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Mô hình hóa: Subsystem & Interface 
39 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Subsystem Context 
40 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Subsystem Context 
41 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Re-use 
 Mục đích 
 Để xác định nơi đâu có thể dùng lại các subsystem hay các 
component đã xây dựng dựa trên interface của chúng. 
 Các bước 
 Tìm kiếm các interface tương tự nhau 
 Hiệu chỉnh các interface mới để phù hợp hơn 
 Thay thế các interface cần có bằng các interface có sẵn 
 Ánh xạ các subsystem cần có với các component có sẵn 
42 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Re-use 
 Bên trong hệ thống đang xây dựng: 
 Nhận biết sự giống nhau giữa các package và các 
subsystem 
 Bên ngoài hệ thống đang xây dựng: 
 Các component thương mại 
 Các component từ các ứng dụng đã xây dựng trước đó 
 Các component đã được áp dụng kỹ thuật ngược 
(reverse engineering) 
43 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Tinh chỉnh use-case realization 
 Tinh chỉnh Use-case Realization 
 Xác định các object có tham gia vào Use-Case 
 Phân công trách nhiệm cho các object 
 Mô hình hóa các thông điệp giữa các object 
 Mô tả các kết quả xử lý từ các thông điệp 
 Mô hình hóa quan hệ giữa các class liên quan 
44 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Tinh chỉnh Use-case Realization 
 Thay thế các class khả dụng bằng các subsystem interface 
kết hợp với chúng 
 Từng bước tích hợp các cơ chế kiến trúc khả dụng 
 Hiệu chỉnh use-case realization 
 Các Interaction diagram 
 View of participating classes (VOPC) diagram(s) 
45 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Tích hợp subsystem Interface 
46 
Tất cả các analysis class khác được ánh xạ thành các design class 
 Analysis Classes Design Elements 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Subsystem Interface 
47 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Tích hợp subsystem interface 
48 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Đóng gói Subsystem Interactions 
Các Subsystem phải được biểu diễn với các interface 
của chúng trong interaction diagrams 
Các thông điệp đến subsystems được mô hình như 
các thông điệp đến subsystem interface 
Các thông điệp đến subsystems tương ứng với các 
operation của subsystem interface 
Các tương tác trong subsystems được mô hình trong 
Subsystem Design 
49 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Tinh chỉnh các Flow & Event 
50 
Annotate the interaction diagrams 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Tổng quan về thiết kế Class 
51 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Các bước thiết kế Class 
 Tạo các Design Class ban đầu 
 Xác định các Persistent Class 
 Định nghĩa các Operation 
 Định nghĩa Class Visibility 
 Định nghĩa các Method 
 Định nghĩa các trạng thái 
 Định nghĩa các thuộc tính 
 Định nghĩa các phụ thuộc 
 Định nghĩa các mỗi kết hợp 
 Định nghĩa các quan hệ tổng quát hóa 
 Giải quyết đụng độ giữa các Use-Case 
 Xử lý các yêu cầu phi chức năng nói chung 
52 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Khảo sát khi thiết kế class 
 Class stereotype 
 Boundary 
 Entity 
 Control 
 Các design pattern khả dụng 
 Các cơ chế kiến trúc 
 Persistence 
 Distribution 
53 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Thiết kế các Boundary Class 
 Các user interface (UI) boundary class 
 Công cụ xây dựng UI nào sẽ được dùng 
 Bao nhiêu giao diện được xây dựng 
54 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Thiết kế các Entity Class 
Các Entity object thường thụ động và persistent 
Các yêu cầu về hiệu năng có thể buộc ta phải tái xây dựng 
Xem thêm bước xác định Persistent Class 
55 
 Analysis Design 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Control Class 
Chuyện gì xảy ra với các Control Class? 
 Chúng thật sự cần thiết? 
 Có phải tách chúng ra không? 
Dựa vào đâu để quyết định? 
 Độ phức tạp 
 Khả năng thay đổi 
 Tính phân tán và hiệu năng 
 Transaction management 
56 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Xác định Persistent Class 
Mọi thể hiện của class đều đòi hỏi phải lưu giữ 
trạng thái của nó 
Các Persistent class được gán với cơ chế 
persistence 
Database Design 
 Chiến lược Persistence phải nhất quán 
 Ở đây, nhớ rằng các class đều persistent 
57 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Operation 
Mục đích 
 Ánh xạ các nhiệm vụ đã xác định ơ mức phân 
tích thành các operation thực hiện chúng 
Những cái cần xem xét: 
 Tên Operation, signature, và mô tả 
 Operation visibility 
 Tầm vực Operation 
• Class operation hay instance operation 
58 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Ví dụ 
CourseOffering 
59 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Tìm kiếm Operation 
 Các thông điệp trong các Interaction Diag. 
60 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Đặt tên và mô tả các Operation 
Các tên thích hợp cho operation 
 Chỉ rõ kết quả của operation 
 Đứng dưới góc nhìn của client 
 Nhất quán qua tất cả các class 
Định nghĩa operation signature 
 operationName(parameter : class,..) : returnType 
Cung cấp một mô tả ngắn, bao gồm ý nghĩa của tất 
cả các tham số 
61 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Operation Signatures 
Khi thiết kế operation signatures phải bảo đảm 
hàm chứa: 
 Các tham số truyền theo giá trị hay tham số? 
 Các tham số có bị thay đổi bởi operation? 
 Các tham số là optional? 
 Tham số có giá trị mặc định? 
 Miền tham số hợp lệ? 
Càng ít tham số càng tốt 
Truyền các object thay vì “data bits” 
62 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Additional classes & Relationshops 
 Additional classes và relationships có thể được 
thêm vào để hỗ trợ signature 
63 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Operation Visibility 
Tính khả kiến được dùng để cung cấp tính đóng gói 
Giá trị có thể là public, protected, hay private 
64 
Private operations 
Protected operations 
Public operation 
Ký hiệu tính khả kiến? 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Package Element Visibility 
 Ôn lại: 
65 
Chỉ các public class 
mới được tham 
chiếu từ bên ngoài 
package sở hữu nó 
Nguyên lý OO: Encapsulation 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Utility Class 
Thế nào là một Utility Class? 
 Utility là một class stereotype 
 Dùng để chỉ các class chứa một bộ các chương trình con 
miễn phí 
Tại sao lại dùng chúng? 
 Để cung cấp các dịch vụ có thể hữu dụng trong các ngữ 
cảnh khác nhau 
 Để gói các hàm thư viện hay các ứng dụng phi đối tượng 
66 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Ví dụ 
67 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Method 
 Method là gì ? 
 Mô tả cài đặt của operation 
 Mục đích 
 Định nghĩa các khía cạnh đặc biệt của operation 
implementation 
Những gì cần xem xét: 
 Các thuật toán đặc biệt 
 Các object và các operation khác cần sử dụng 
 Cách cài đặt, sử dụng các attribute và các tham số 
 Cách cài đặt và sử dụng các mối quan hệ 
68 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Định nghĩa các trạng thái 
 Mục đích 
 Thiết kế ảnh hưởng của trạng thái đối tượng lên hành vi 
của nó 
 Phát triển state-diagram để mô hình các hành vi này 
Những gì cần xem xét: 
 Những object nào có trạng thái đáng kể? 
 Cách xác định các trạng thái của một object? 
 Cách ánh xạ state-diagram với phần còn lại của mô hình? 
69 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Thiết kế và tinh chỉnh State – diag. 
70 
Mô tả lịch sử đời sống đối tượng 
Nhắc lại : xem bài giảng trước về State-Diagram 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Attribute 
 Cần xem xét: 
 Persistency 
 Visibility 
 Name, Type, Default value 
71 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Tìm và biểu diễn Attribute 
 Khảo sát mô tả của các method 
 Khảo sát các trạng thái 
 Bất kỳ thông tin nào mà class cần duy trì 
Mô tả name, type, và giá trị mặc định 
 attributeName : Type = Default 
Tuân thủ qui ước đặt tên của NNLT và dự án 
Type phải là KDL cơ sở trong NNLT cài đặt 
 Các KDL định sẵn, người dùng đ/n 
Mô tả tình khả kiến: Public, Private, Protected 
72 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Các Derived Attribute 
Thế nào là derived attribute? 
 Một attribute mà giá trị co thể tính từ giá trị 
của các attribute khác 
Khi nào dùng chúng? 
 Khi không đủ thời gian để tính lại giá trị mỗi 
khi cần thiết 
 Dung hòa giữa thời gian thực hiện và bộ nhớ 
sử dụng 
73 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Quan hệ: dependency 
 Là một loại quan hệ giữa hai object 
 Xác định những nơi KHÔNG cần đến các mối 
quan hệ cấu trúc 
Xem xét: Những gì buộc supplier trở nên nhìn thấy 
được bởi client 
74 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Dependency & Association 
Association là quan hệ cấu trúc 
Dependency là quan hệ phi cấu trúc 
Để .nói chuyện. được, object phải khả kiến 
 Tham chiếu đến biến cục bộ 
 Tham chiếu đến tham số 
 Tham chiếu toàn cục 
 Tham chiếu đến trường dữ liệu (Field) 
75 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Local variable visibility 
Operation op1() chứa một biến cục bộ có 
kiểu ClassB 
76 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Parameter Visibility 
Thể hiện của ClassB được truyền đến cho 
thể hiện của ClassA 
77 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Global Visibility 
Thể hiện của Class Utility khả kiến với mọi 
đối tượng vì nó là toàn cục (global) 
78 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Dependency hay Association 
 Bám vào các quan hệ trong thế giới thực 
 Bám vào các quan hệ yếu nhất (dependency) 
 Quan hệ là .thường trực.? Dùng association (field visibility) 
 Quan hệ là .nhất thời.? Dùng dependency 
 Nhiều object chia sẻ chung 1 instance 
• Truyền instance như tham số (parameter visibility) 
• Đặt instance là global (global visibility) 
 Các object không chia sẻ cùng 1 instance (local visibility) 
 Cần bao nhiêu thời gian để create/destroy? 
 Chi phí ? Dùng field, parameter, hoặc global visibility 
 Chọn lựa nào đúng? CÒN TÙY 
79 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Tinh chỉnh các mối quan hệ 
 Xem xét lại 
 Cân nhắc giữa Association và Aggregation 
 Cân nhắc giữa Aggregation và Composition 
 Cân nhắc giữa Attribute và Association 
 Chiều của quan hệ (Navigability) 
 Thiết kế Association class 
 Thiết kế bản số (Multiplicity design) 
80 
Xem lại bài giảng về phân tích class và các quan hệ giữa class 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Parameterized Class (template) là gì? 
Là một class dùng để định nghĩa các class khác 
Thường dùng cho các container class 
 Một số container class thông dụng: 
• Set, list, dictionary, stack, queue,  
81 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Thể hiện của Parameterized Class 
 Kết buộc tường minh Kết buộc ẩn 
82 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Ví dụ 
83 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Optionality 
Nếu một link là tùy chọn, hãy chèn thêm 
một operation để kiểm tra sự tồn tại của 
link 
84 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Nhắc lại quan hệ tổng quát hóa 
 Rất dễ nhầm lẫm giữa Generalization và aggregation 
 Generalization biểu diễn quan hệ “là một” hay 
“dạng của” 
 Aggregation biểu diễn quan hệ “một bộ phận của” 
85 
 ????? 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Tinh chỉnh quan hệ 
86 
Một WindowWithScrollbar ”là một” Window 
Một WindowWithScrollbar “chứa một” Scrollbar 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Sử dụng quan hệ tổng quát hóa 
Chia sẻ các thuộc tính và hành vi chung 
Chia sẻ cài đặt 
Cài đặt cơ chế Polymorphism 
 
87 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Thực hành 
88 
7 – Thiết kế kiến trúc: Use-case & Class Diag. 
Thực hành 
 Làm việc với công cụ Rational Rose 
 Thiết kế Use-case & Class 
 Tinh chỉnh lại các sơ đồ 
 Chuẩn bị hoàn tất đồ án. 
89