Post on 05-Sep-2019
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ống A
TM
tầng n
ghiệ
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