Professional Documents
Culture Documents
Module8 - Thiết kế hướng đối tượng
Module8 - Thiết kế hướng đối tượng
v Trả lời cho câu hỏi how (hệ thống được xây
dựng như thế nào) thay vì câu hỏi what trong
pha phân tích.
• Làm việc với các kết quả của pha phân tích.
• Làm mịn mô hình phân tích để xây dựng mô hình thiết
kế (mô hình sát với các chương trình sẽ được cài đặt).
• Xác định một giải pháp cài đặt cho hệ thống.
• Mô hình hoá hệ thống ở mức chi tiết dựa trên các lớp,
các đối tượng trong miền ứng dụng của hệ thống.
3
Xác định các phần tử thiết kế
4
Các chế tác của hoạt động
xác định các phần tử thiết kế
5
Các bước xác định các phần tử thiết kế
6
Ánh xạ các lớp phân tích
sang các phần tử thiết kế
7
Xác định các lớp thiết kế
9
Quan hệ phụ thuộc giữa các gói
v Chỉ các lớp public mới có thể được tham chiếu từ
bên ngoài gói chứa chúng.
10
Sự kết hợp giữa các gói
1 1
1 1
12
Ví dụ: Gói các chế tác University
13
Ví dụ: Gói các chế tác University (tt.)
14
Ví dụ: Gói các giao diện hệ thống bên ngoài
v Các lớp truy cập hệ thống bên ngoài được phân vùng vào
trong gói các giao diện hệ thống bên ngoài.
• Các lớp giao diện hệ thống bên ngoài có thể được quản lý cấu
hình một cách độc lập với các hệ thống con cài đặt chúng.
15
Các hệ thống con và các giao diện
v Hệ thống con (subsystem) là một phần tử mô hình có
ngữ nghĩa giống với một gói (có thể chứa các phần tử mô
hình khác) và một lớp (có hành vi).
• Một hệ thống con thực thi một hoặc nhiều giao diện -> định nghĩa
hành vi mà hệ thống con đó có thể thực hiện.
• Một hệ thống con có thể được biểu diễn như một gói UML,
stereotype dạng <<subsystem>>.
v Giao diện (interface) là một phần tử mô hình, nó định
nghĩa một tập các hành vi cho một phân lớp (lớp, hệ
thống con hoặc thành phần).
• Mối quan hệ giữa các giao diện và các phân lớp (các hệ thống
con) không phải lúc nào cũng là 1-1.
• Một giao diện có thể được cài đặt bởi nhiều phân lớp, một phân
lớp có thể cài đặt nhiều giao diện. 16
Các hệ thống con và các giao diện (tt.)
v Các hệ thống con:
• Chỉ cung cấp các hành vi thông qua các giao diện.
• Thường dùng để biểu diễn các lớp đã có sẵn hoặc các dịch vụ mà
hệ thống sử dụng.
v Quan hệ phụ thuộc giữa các hệ thống con là quan hệ trên
giao diện, không phải giữa nội dung của các hệ thống con.
• Hệ thống con đóng gói hoàn toàn nội dung của nó (đóng gói sự cài
đặt của nó sau một hoặc nhiều giao diện).
17
Các gói và các hệ thống con
18
Hai lớp có liên quan chức năng với nhau
19
Làm mịn lớp phân tích
thành hệ thống con
20
Ví dụ: Thiết kế các hệ thống con
và các giao diện
21
Ví dụ: Biểu đồ lớp ngữ cảnh cho
hệ thống con CourseCatalogSystem
22
Ví dụ: Biểu đồ lớp ngữ cảnh cho
hệ thống con BillingSystem
23
Xác định các khả năng tái sử dụng
v Mục đích:
• Xác định các hệ thống con và/hoặc các thành phần nào đang có
sẵn có thể tái sử dụng dựa trên các giao diện của chúng.
• Giảm công sức cài đặt và kiểm tra các phần tử dùng lại này.
v Các bước chính:
• Tìm các hệ thống con và/hoặc các thành phần đang có sẵn có các
giao diện tương tự nhau.
• Sửa đổi các giao diện đang có sẵn được tìm thấy để cải thiện khả
năng kết nối.
• Thay thế các giao diện ứng viên bằng các giao diện đang có sẵn này.
• Ngoài ra, xem xét tìm kiếm các gói, các hệ thống con đã có các chức
năng mong muốn, các thành phần đã được thương mại hoá hoặc đã
được xây dựng trong các ứng dụng trước đó để sử dụng lại chúng.
24
Review: Tiếp cận phân tầng điển hình
25
Cập nhật mô hình thiết kế
v Visibility:
• Các phần tử chỉ nên phụ thuộc vào các phần tử trong cùng
tầng và tầng dưới liền kề.
• Các gói cần truy cập trực tiếp vào các dịch vụ của tầng thấp
hơn (in, gửi tin nhắn …) -> ngoại lệ.
v Volatility:
• Trong các tầng cao nhất, đặt các phần tử hay bị thay đổi khi các
yêu cầu người sử dụng thay đổi.
• Trong các tầng thấp nhất, đặt các phần tử hay bị thay đổi khi
nền tảng cài đặt (phần cứng, ngôn ngữ, hệ điều hành, cơ sở dữ
liệu) thay đổi.
• Trong các tầng giữa, đặt các phần tử có thể áp dụng chung trên
nhiều hệ thống và môi trường thực thi.
26
Cập nhật mô hình thiết kế (tt.)
v Generality:
• Các phần tử mô hình trừu tượng có xu hướng đặt ở các tầng
thấp, nơi chúng có thể được sử dụng lại.
• Nếu không phải phục vụ cho quá trình cài đặt -> xu hướng đặt
ở các tầng giữa.
v Number of Layers:
• Đối với một hệ thống nhỏ -> 3 tầng là đủ.
• Đối với một hệ thống phức tạp -> 5-7 tầng là đủ.
27
Ví dụ về các gói
28
Ví dụ về các tầng
29
Ví dụ: Ngữ cảnh tầng ứng dụng
<<layer>> <<layer>>
Application
Application
Registration
<<layer>>
Business
<<layer>> Services
Business Services
External System
Interfaces
Security
University Artifacts
Secure Interfaces GUI Framework
30
Ví dụ: Ngữ cảnh tầng Business Services
31
Ví dụ: Tầng Middleware
<<layer>>
Middleware
com.odi java.sql
Map Session DriverManager Connection
(from com.odi) (from com.odi) (from com.odi) (from com.odi)
32
Xác định các cơ chế thiết kế
33
Các cơ chế thiết kế điển hình
36
Các bước thiết kế lớp
38
Thiết kế giao diện
v Giao diện mô tả hành vi của các đối tượng.
• Che dấu sự cài đặt và trạng thái của các đối tượng.
v Mỗi lớp/hệ thống con cài đặt các thao tác trong
giao diện.
v Vai trò:
• Cầu nối giao tiếp giữa người dùng và phần mềm.
• Ảnh hưởng đến hiệu quả khai thác ứng dụng.
• Giao diện rõ ràng, có tính thẩm mỹ, thân thiện với người
dùng -> tăng hiệu quả khai thác.
v Chất lượng:
• Yêu cầu thống nhất về ngôn ngữ thể hiện (hạn chế pha
trộn nhiều ngôn ngữ).
• Yêu cầu thống nhất giữa màn hình chính với các màn
hình khác -> nên đưa ra một form thể hiện chung.
39