PHÂN TÍCH, THIẾT KẾ HỆ THỐNG THÔNG TIN

v Giảng viên: ThS. Nguyễn Đức Hiếu

v Khoa: Công nghệ thông tin
v Bộ môn: Khoa học máy tính
v Email: nguyenduchieu247@gmail.com
v Mobile: 0968.240.787
 Các hoạt động thiết kế hướng đối tượng

v Xác định các phần tử thiết kế

v Xác định các cơ chế thiết kế
v Mô tả kiến trúc Runtime
• Đọc thêm slides “Describe the Runtime Architecture”
v Mô tả sự phân tán
• Đọc thêm slides “Describe Distribution”
v Thiết kế ca sử dụng
v Thiết kế các hệ thống con
v Thiết kế các lớp
v Thiết kế cơ sở dữ liệu 2
 Giai đoạn 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ế

v Xác định các lớp và các hệ thống con

v Xác định giao diện hệ thống con
v Xác định các khả năng tái sử dụng
v Cập nhật mô hình thiết kế
v Kiểm tra

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ế

v Một lớp phân tích có thể trở thành:

• Một lớp trong mô hình thiết kế.
• Một phần của một lớp trong mô hình thiết kế.
• Một lớp toàn thể trong mô hình thiết kế (thành
phần của lớp này không được mô hình hoá trong
mô hình phân tích).
• Một nhóm các lớp kế thừa cùng một lớp trong mô
hình thiết kế.
• Một nhóm các lớp có chức năng liên quan trong
mô hình thiết kế (một gói).
• Một hệ thống con trong mô hình thiết kế.
• Một quan hệ trong mô hình thiết kế.
8
 Phân bổ các lớp biên vào các gói

v Nếu giao diện hệ thống v Nếu giao diện hệ thống nhiều

nhiều khả năng sẽ thay đổi: khả năng sẽ KHÔNG thay đổi:
-> các lớp biên cần được đặt vào -> các lớp biên cần được đặt vào
cùng gói với các lớp điều khiển và
trong các gói riêng biệt.
các lớp thực thể (có liên quan chức
năng với nhau).

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

v Ưu điểm: Cho phép chúng

được tái sử dụng.
v Nhược điểm: Làm cho các gói
phụ thuộc lẫn nhau -> hệ thống
khó thay đổi và mở rộng.
v Một số nguyên tắc chung:
• Hai gói không nên phụ thuộc lẫn
nhau -> phụ thuộc một chiều.
• Các gói ở tầng dưới không nên phụ
thuộc vào các gói ở tầng trên ->
phụ thuộc trong cùng tầng (hoặc
tầng dưới liền kề).
• Các gói không nên phụ thuộc vào
các hệ thống con -> phụ thuộc vào
các gói khác (hoặc các giao diện). 11
Ví dụ: Gói Registration

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

v Các gói: v Các hệ thống con:

• Không cung cấp hành vi. • Cung cấp hành vi.
• Không đóng gói hoàn toàn • Đóng gói hoàn toàn nội
nội dung của chúng. dung của chúng.
• Không dễ bị thay thế. • Dễ bị thay thế.

18
 Hai lớp có liên quan chức năng với nhau

v Mô hình thiết kế có thể cấu trúc thành các gói và các hệ

thống con.
v Một gói được xác định dựa trên một nhóm các lớp có
chức năng liên quan.
v Bộ tiêu chí đánh giá hai lớp có liên quan chức năng với
nhau:
• Thay đổi hành vi hoặc cấu trúc của lớp này đòi hỏi phải thay đổi
lớp kia.
• Tương tác với nhau thông qua nhiều thông điệp.
• Cùng tương tác với một tác nhân.
• Có quan hệ với nhau (liên kết, kết tập …).

19
 Làm mịn lớp phân tích
thành hệ thống con

v Khi lớp phân tích quá phức tạp:

• Các hành vi của lớp phân tích không thể chỉ là trách nhiệm
của một mình nó.
• Các trách nhiệm của nó cần phải được sử dụng lại.
-> Lớp phân tích đó cần phải được làm mịn thành một 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)

Transaction Database Statement ResultSet

(from com.odi) (from com.odi) (from com.odi) (from com.odi)

32
 Xác định các cơ chế thiết kế

v Xác định các cơ chế thiết kế là một hoạt động trong

luồng công việc làm mịn kiến trúc.
v Mục đích: Làm mịn các cơ chế phân tích thành các cơ
chế thiết kế dựa trên các ràng buộc của môi trường
thực thi.

33
Các cơ chế thiết kế điển hình

v Đọc thêm slides “Identify Design Mechanisms”.

34
 Thiết kế ca sử dụng
v Làm thế nào từng ca sử dụng được thực thi?
v Mục đích: Làm mịn hiện thực hoá ca sử dụng và các
thao tác của các lớp và hệ thống con.
v Input: Mô hình phân tích, các đặc tả bổ sung, các lớp
thiết kế, các hệ thống con …
v Output: Các ca sử dụng được hiện thực hoá ở mức
thiết kế.
v Ánh xạ các cơ chế thiết kế tới các phần tử thiết kế (các
lớp phân tích và các hệ thống con).
v Hiện thực hoá ca sử dụng:
• Khởi tạo trong hoạt động Phân tích ca sử dụng.
• Làm mịn thành các phần tử thiết kế. 35
 Thiết kế các lớp

v Tập trung vào môi trường cài đặt và thực thi.

v Mục đích:
• Đảm bảo các lớp cung cấp các hành vi mà Hiện thực hoá ca
sử dụng yêu cầu.
• Đảm bảo cung cấp đầy đủ thông tin để cài đặt các lớp.
• Nắm bắt các yêu cầu phi chức năng tới các lớp.
• Tích hợp các cơ chế thiết kế được sử dụng bởi các lớp.
v Input: Tài liệu đặc tả bổ sung, các lớp phân tích, các
lớp thiết kế, các mô hình thiết kế.
v Output: Các lớp thiết kế và mô hình thiết kế.

36
 Các bước thiết kế lớp

v Tạo các lớp thiết kế ban đầu

v Xác định các lớp bền vững
v Định nghĩa các thao tác
v Định nghĩa các phương thức
Đọc thêm slides
v Định nghĩa các trạng thái “Class Design”
v Định nghĩa các thuộc tính
v Định nghĩa các phụ thuộc
v Định nghĩa các mối quan hệ
v Xử lý xung đột các ca sử dụng
v Xử lý các yêu cầu phi chức năng
37
 Xử lý các yêu cầu phi chức năng

v Làm thế nào để sử dụng một thành phần hoặc sản

phẩm đã tồn tại?
v Làm thế nào để thích ứng với ngôn ngữ lập trình?
v Làm thế nào để phân bố các đối tượng?
v Làm thế nào để đạt hiệu năng chấp nhận được?
v Làm thế nào để đạt được một số mức an ninh
mong muốn?
v Làm thế nào để xác định được các lỗi?

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