Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

Ñieàn phieá u yeâu Laä p vaø gôû i maã u

caà u phieá u yeâ u caà u

Gôû i phieá u yeâ u Löu phieá u yeâ u

caà u caà u

Kieåm tra ngaân Kieå m tra hôï p

saù ch danh muï c

[ Khoâng hôïp leä ]

Göû i mail Thoâng baùo PYC
Ñieàu chænh PYC
khoâng hôïp leä

Hình 68. Mô hình xử lý PYC với giải pháp theo lô

Hai sơ đồ trên minh họa hai giải pháp xử lý phiếu yêu cầu, trực tuyến và theo lô. Giải
pháp trực tuyến cho biết nhân viên sẽ kiểm tra liền PYC ngay khi NKH gởi tới bằng cách
tra cứu đối chiếu tính hợp lệ danh mục sách và ngân sách được cấp cho nhà khoa học.
PYC không hợp lệ sẽ được thông báo và NKH có thể điều chỉnh ngay. Giải pháp theo lô
cho biết nhân viên sau khi nhà khoa học gởi nộp PYC sẽ không tiến hành bất kỳ việc gì
ngoại trừ lưu lại PYC và chờ đến thời điểm hết hạn nộp rồi tiến hành kiểm tra đồng loạt
trên tất cả các PYC, sau đó tất cả các PYC không hợp lệ sẽ được thông báo chung.

II.3 Xây dựng mô hình Use case đặc tả yêu cầu phần mềm hệ thống
II.3.1. Xây dựng các use case từ các hoạt động sẽ được tự động hóa
Thiết lập các actor: actor được thiết lập ở mức này là người dùng trực tiếp phần mềm hệ
thống.
Như đã đề cập trong chương 5, đối tượng con người liên quan đến hệ thống tác nghiệp
được chia thành hai loại người làm việc (business worker) và tác nhân hệ thống (business
actor). Trong việc xác định đối tượng sẽ là actor sử dụng phần mềm hệ thống tùy theo
loại hình phần mềm ứng dụng và mức độ tin học hoá của từng hệ thống nhiều hay ít mà
actor được chọn là người làm việc hoặc tác nhân hệ thống cụ thể như sau:
- Người làm việc là actor: đây là trường hợp các ứng dụng phần mềm dạng
application, đa số là ứng dụng client – server. Trường hợp này nhân viên (người
làm việc) sẽ sử dụng phần mềm để quản lý dữ liệu thông tin của hệ thống. Các đối
tượng môi trường (tác nhân hệ thống) làm việc với hệ thống thông qua trao đổi
với nhân viên. Do đó, chương trình được triển khai trong phạm vi của đơn vị nơi

170
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

làm việc của các nhân viên. Các hoạt động của đối tượng môi trường không được
quan tâm tự động hoá.
Ví dụ: khách hàng là đối tượng môi trường làm việc với hệ thống, trường hợp này
khách hàng không sử dụng trực tiếp phần mềm hệ thống mà làm việc thông qua đối
tượng nhân viên bán hàng (đối chiếu với mô hình hoạt động ta thấy lập hóa đơn là
hoạt động thuộc về nhân viên bán hàng) và nhân viên bán hàng là đối tượng sử dụng
phần mềm hệ thống để lưu và in hoá đơn. Do đó, nhân viên là một actor.

Khaù ch haø ng Nhaâ n vieâ n baù n haø n g

Hoaù ñôn Lòch giao haøn g Ñôn ñaë t haø n g

Nhaâ n vieâ n baù n haø n g Laä p hoaù ñôn

Hình 69. Sơ đồ minh hoạ sự chọn lựa actor phần mềm hoạt động Lập hoá đơn trong
Rational Rose
- Tác nhân hệ thống là actor: nếu chúng ta muốn xây dựng hệ thống tự động hoá
hoàn toàn các hoạt động tác nghiệp, ví dụ, chúng ta xây dựng một ứng dụng e-
commerce, một ứng dụng intrenet, internet trên môi trường web,… Có nghĩa là
chúng ta tự động hoá các hoạt động của các tác nhân hệ thống vốn được xem là
đối tượng bên ngoài hệ thống. Điều này cho phép hệ thống tin học hoá tất cả các
hoạt động thay vì chỉ các hoạt động của nhân viên làm việc trong hệ thống như đã
đề cập trên. Các đối tượng bên ngoài có thể sử dụng phần mềm của hệ thống để
trao đổi, làm việc với hệ thống.
Ví dụ về hệ thống Quản lý yêu cầu sách cho thấy, chúng ta muốn xây dựng một ứng
ụng web cho phép nhà khoa học có thể sử dụng để lập và gởi phiếu yêu cầu cũng như
nhận các thông báo từ hệ thống. Do đó, trong mô hình minh hoạ dưới đây cho thấy
Nhà khoa học trở thành actor. Mặt khác việc tự động hoá hoạt động đặt sách không
được tự động hoá các hoạt động của Nhà xuất bản, nhà xuất bản sẽ làm việc với hệ
thống thông qua nhân viên vì vậy Nhà xuất bản không phải là actor mà nhân viên sẽ là
actor sử dụng phần mềm hệ thống.

171
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

Nhaø khoa hoïc Nhaâ n vieâ n Nhaø xuaát baû n

Danh saù ch nhaø xuaá t baû n Phieáu ñaët mua saùch Danh muï c saùch Soå ngaân saùch haø ng naê m

Laä p phieá u yeâ u caà u

Nhaø khoa hoï c Xöû lyù PYC Nhaâ n vieâ n

Ñaë t mua saù ch

Hình 70. Sơ đồ minh hoạ sự chọn lựa Actor Nhà khoa học trong Rational Rose
Xác định Use case tự động hoá
Từ các hoạt động được quyết định tự động hoá chúng ta lập bảng xác định use case phần
mềm hệ thống. Chúng ta có thể gom chung nhiều hoạt động mô tả cùng một ngữ nghĩa
trong cùng một use case.
Mô hình Use case phần mềm đặc tả bán hàng NGK được xác định như sau:
Use case chức năng phần Hoạt động Actor (user)
mềm hệ thống
Lập hoá đơn Lập hoá đơn thanh toán Nhân viên bán hàng
Xử lý đặt hàng Xác định công nợ Nhân viên bán hàng
Lưu đơn hàng Nhân viên bán hàng
Xử lý thanh toán đơn hàng Lập thanh toán Nhân viên văn phòng
Giao hàng Lên lịch giao hàng Nhân viên bán hàng
Lập phiếu giao hàng Kho
Cập nhật đơn hàng đã giao Kho
Xác định tồn kho Xác định tồn kho Kho

172
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

Mô hình Use case phần mềm đặc tả đặt mua NGK được xác định như sau:
Use case chức năng phần Hoạt động Actor (user)
mềm hệ thống
Xác định tồn kho Xác định tồn kho Kho
Lập đặt mua NGK Lập đơn mua NGK Kho
Duyệt đơn hàng Kho
Giao nhận hàng NGK Lưu phiếu giao hàng và Kho
cập nhật lại đơn hàng đã
giao
Lập thanh toán Lập thanh toán cho nhà Nhân viên văn phòng
cung cấp

- Đối với các đối tượng trong hệ thống (nhân viên, kho,…), kiểm tra lại mô hình
hoạt động xem các chức năng tự động hoá có được sử dụng bởi các đối tượng này
không, nếu có thì xác định đối tượng đó chính là một actor

Laä p hoù a ñôn

Nhaâ n vieâ n baù n haø ng

Xöû lyù ñaë t haø ng

Nhaâ n vieâ n
Xaù c ñònh toà n kho
<<Use>>
Giao haø ng

Thuû kho

Xöû lyù thanh toaù n ñôn haø ng

Nhaâ n vieâ n vaê n phoø ng

<<Use>>
Laä p ñaë t mua NGK Xaù c ñònh toà n kho

Kho

Nhaâ n vieâ n Giao nhaä n haø n g NGK

Nhaâ n vieâ n vaê n phoø n g

Laä p thanh toaù n

173
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

Hình 71. Các sơ đồ Use case biểu diễn chức năng phần mềm cho hoạt động mua bán
NGK

II.3.2. Xây dựng các use case khai thác và theo dõi hệ thống
Gồm các use case mô tả các khai thác dữ liệu hệ thống (các thống kê, báo cáo, tìm kiếm,
xem xét kết quả quá trình hoạt động,…). Trong quá trình xử lý thủ công, các hoạt động
xử lý thông tin này thường tốn kém rất nhiều về nhân sự và kéo dài thời gian tính toán (do
phải thu gom và tính toán số liệu). Tuy nhiên, đối với hệ thống tự động hóa, khả năng tính
toán trên máy tính được xem như là vô hạn, do đó, các xử lý thông kê báo cáo số liệu phải
được khai thác càng nhiều càng tốt vì như vậy là chúng ta đã khai thác tiềm năng và sức
mạnh của máy tính.
Đối với hệ thống cửa hàng NGK, chúng ta tinh chế use case Quản trị và theo dõi hệ thống
dựa vào các yêu cầu được thiết lập và mở rộng thêm các thống kê để giúp cho nhà quản lý
theo dõi được tình hình của đơn vị.

In thoá ng keâ nhaä p xuaá t toà n

Nhaâ n vieâ n vaê n phoø ng

Kho
Xaù c ñònh coâ ng nôï khaù ch haø n g

Thoá ng keâ tình hình nhaä p NGK

In baù o caù o doanh thu

II.3.3. Xây dựng các use case mô tả chức năng quản trị hệ thống
Gồm các chức năng quản trị an toàn hệ thống (đăng nhập, người dùng, quyền sử dụng,
nhóm người dùng,…), tham số hệ thống, danh mục, …

Ñaê ng nhaä p heä thoá n g

Nhaâ n vieâ n

Quaû n trò ngöôø i duø ng

Quaû n trò heä thoá n g

II.3.4. Tinh chế các mô hình Use case

- Xác định lại các use case có thể tách ra để sử dụng liên kết ‘use’: xem xét lại trong
các hoạt động của các mô hình use case xem có những hoạt động nào chung, hoặc

174
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

gần giống nhau để có thể tách ra thanh một use case mới, rồi tạo liên kết ‘use’ với
use case đang tồn tại. Việc tách ra các use case để thiết lập quan hệ ‘use’ cho phép
chúng ta xác định việc tái sử dụng rất sớm của quá trình phát triển hệ thống ở giai
đoạn phân tích, tạo ra một kiến trúc đẹp và tránh được sự trùng lắp công việc
trong các giai đoạn thiết kế và lập trình sau này.
Trong use case Xử lý đặt hàng của hoạt động bán hàng ta có hoạt động xác định công
nợ của khách hàng. Trong use case Xác định công nợ khách hàng của hoạt động quản
trị theo dõi cũng có chung thao tác xử lý tính công nợ, rồi sau đó in ra công nợ trên
một form xác định. Vậy ta tách ra một use case mới là Tính công nợ rồi tạo liên kết
‘use’ tới hai use case còn lại.
- Xác định lại các use case để có thể tạo liên kết ‘extends’:
o Xác định xem trong các mô hình use case có những use case nào mà hoạt
động của nó cùng thuộc chung một bản chất thì có thể tạo ra một use case
tổng quát và tạo liên kết ‘extends’ từ use case tổng quát đến các use case
đó.
Chúng ta tạo ra một use case Lập chứng từ là use case tổng quát cho các use
case: Lập hoá đơn, Xử lý đặt hàng, Xử lý thanh toán đơn hàng, Lập thanh
toán, Lập đặt mua NGK.
o Xác định xem trong một use case có những tính huống xử lý nào là một
trường hợp riêng, đặc biệt cần làm rõ thì nên tạo một use case để mô tả cho
trường hợp đó, sau đó tạo liên kết ‘extends’ từ use case mới thanh lập đến
use case tổng quát.
Trong use case In báo cáo doanh thu, chúng ta phát triển một use case mô tả
trường hợp riêng là In báo cáo doanh thu theo tháng.

<<Extend>>
Laä p chöù n g töø
Laä p hoù a ñôn

<<Extend>>

Xöû lyù ñaë t haø n g <<Use>> Tính coâ n g nôï

Nhaâ n vieâ n baù n haø n g

Nhaâ n vieâ n <<Extend>>

Xaù c ñònh toà n kho

Giao haø n g <<Use>>

Kho

Xöû lyù thanh toaù n ñôn haø n g

Nhaâ n vieâ n vaê n phoø n g

Baù n haø n g Ñaë t mua NGK Thoá ng keâ theo doõ i

175
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

<<Use>>
Laä p ñaë t mua NGK Xaù c ñònh toà n kho

Kho
<<Extend>>

Nhaâ n vieâ n Giao nhaä n haø n g NGK

<<Extend>>

Laä p chöù ng töø

Nhaâ n vieâ n vaê n phoø ng <<Extend>>
Laä p thanh toaù n

Baù n haø n g Ñaë t mua NGK Thoá ng keâ theo doõ i

In thoá ng keâ nhaä p xuaá t toà n Tính coâ ng nôï

Nhaâ n vieâ n vaê n phoø ng

<<Use>>

Kho

Xaù c ñònh coâ ng nôï khaù ch haø ng

In baù o caù o doanh thu

<<Extend>>

Thoá ng keâ tình hình nhaä p NGK

In baù o caù o doanh thu thaù ng

Baù n haø n g Ñaë t mua NGK Thoá ng keâ theo doõ i

176
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

Ñaê n g nhaä p heä thoá ng

Nhaâ n vieâ n

Quaû n trò ngöôø i duø n g

Quaû n trò heä thoá ng

Hình 72. Các mô hình Use case mô tả chức năng phần mềm của hệ thống quản lý Cửa
hàng NGK

Laä p phieá u yeâ u caà u <<Use>>

Ñaê ng nhaä p

Nhaø khoa hoï c <<Use>>

Xöû lyù PYC

<<Use>>

Nhaâ n vieâ n Ñaë t mua saù ch

Quaû n trò heä thoá ng Thoá ng keâ thoâ ng tin mua saù ch

Hình 73. Mô hình Use case mô tả chức năng phần mềm hệ Quản lý yêu cầu sách
Kết quả phân tích này sẽ phải được hiểu và công nhận bởi thành viên tham gia, do đó nên
tổ chức một cuộc họp để trình bày và kiểm tra lại. Như đã trình bày trong phần qui trình,
quá trình phân tích là một quá trình lặp. Nên cần chắc chắn rằng kết quả phân tích này
phải là một kết quả phải được chấp nhận cao nhất, các thay đổi sẵn sàng được thẩm định
và kiểm tra để làm giảm tối đa các thay đổi trong các giai đoạn sau.

III. Các tiên đề và hệ luận trong thiết kế hướng đối

tượng
III.1 Các tiên đề
Theo Suh, trong tiếp cận thiết kế hướng đối tượng có hai tiên đề được áp dụng, các tiên đề
là:

177
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

III.1.1. Tiên đề 1: tiên đề độc lập.

Duy trì sự độc của các thành phần: Trong quá trình thiết kế, chúng ta đi từ yêu cầu và use
case đến một thành phần hệ thống, mỗi thành phần phải thoã mãn yêu cầu mà không ảnh
hưởng đến những thành phần khác.

III.1.2. Tiên đề 2: tiên đề thông tin.

Giảm tối đa nội dung thông tin thiết kế. Tiên đề này nói về tính đơn giản hoá trong thiết
kế. Mục đích chính là giảm tối đa tính phức tạp, bởi vì các đối tượng sẽ dễ bảo trì và nâng
cấp hơn. Trong thiết kế hướng đối tượng, cách tốt nhất để giảm độ phức tạp là sử dụng
tính thừa kế. (xem hệ luận 6)

III.2 Các hệ luận

Từ hai tiên đề trên, có nhiều hệ luận được trích dẫn. Những hệ luận này sẽ mang lại lợi
ích hơn trong việc quyết định thiết kế các tình huống cụ thể, vì chúng có thể áp dụng tới
các tình huống thực tế dễ dàng hơn so với tiên đề gốc ban đầu.

III.2.1. Hệ luận 1: thiết kế độc lập với việc giảm tối thiểu thông tin trao đổi
(Uncouple Design with Less Information)
Sự cố kết giữa các đối tượng cao có thể làm giảm tính liên kết giữa chúng. Bởi vì chỉ một
lượng nhỏ các thông tin cần thiết trao đổi giữa các đối tượng đó.
Coupling: Ở giai đoạn thiết kế, coupling được dùng để đo mức độ liên kết giữa các đối
tượng hoặc giữa thành phần phần mềm. Coupling là một mối kết hợp nhị phân, và là một
khái niệm quan trọng khi đánh giá một thiết kế bởi vì nó giúp chúng ta tập trung đúng vào
vấn đề quan trọng của thiết kế. Ví dụ, một thành phần trong hệ thống thay đổi sẽ có một
tác động tối thiểu đến những thành phần khác. Coupling trong các đối tượng càng mạnh
càng mạnh thì hệ thống càng phức tạp. Mức độ của coupling có thể được đánh giá trên:
- Mức độ phức tạp của kết nối
- Kết nối tham chiếu đến chính bản thân đối tượng hoặc bên ngoài đối tượng
- Những gì gởi đi hoặc nhận được
Mức độ coupling giữa hai thành phần được xác định bằng mức độ phức tạp của thông tin
trao đổi giữa chúng. Coupling càng gia tăng thì càng làm gia tăng độ phức tạp hoặc mơ
hồ, tối nghĩa của giao diện. Coupling càng giảm khi sự kết nối được thiết lập ở thành
phần giao diện thay vì ở thành phần bên trong. Trong thiết kế hướng đối tượng, có hai
loại coupling là coupling tương tác và coupling thừa kế:
Coupling tương tác: thể hiện qua số lượng và độ phức tạp của các thông điệp giữa những
thành phần, sự tương tác càng ít thì càng được ưu tiên. Coupling cũng áp dụng tới mức độ
phức tạp của thông điệp. Một chỉ dẫn chung là giữ các thông điệp càng đơn giản và càng
ít xảy ra thì càng tốt. Tổng quát, nếu một kết nối thông điệp gồm ba tham số trở lên thì
kiểm tra xem có thể làm đơn giản hoá nó nữa được không. Một đối tượng được kết nối
với nhiều thông điệp phức tạp thì gọi là tightly coupled, có nghĩa là bất kỳ có sự thay đổi
nào có thể tác động đến sự thay đổi trong những cái khác.

178
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

A B D

Hình 74. Ví dụ về biểu diễn coupling và B là tightly coupled

Năm mức độ coupling tương tác
Data coupling: kết nối giữa các thành phần hoặc là dữ liệu dạng nguyên tố hoặc là hoặc
cấu trúc tổng hợp tất cả yếu tố được dùng bởi đối tượng nhận. Đây là loại coupling tốt
nhất và là mục đích của thiết kế kiến trúc. Các đối tượng trao đổi với nhau thông qua các
dữ liệu thành tố hoặc các cờ hiệu thông tin. Thành phần này không quan tâm đến bất cứ gì
bên trong thành phần khác mà chỉ quan tâm đến dữ liệu gì nó cần và dữ liệu gì nó gởi trả.
Class_A Class_B

+ Operation_A () : Integer + Operation_B (Integer Para_1) : Integer

integer Operation_A()
Operation_A không quan tâm đến nội
{ dung thực hiện của Operation_B mà
chỉ quan tâm đến dữ liệu gởi đến và
int x,y;
nhận từ Operation_B
Class_B cB;
….
y = cB.Operation_B(x);
…
}

Stamp coupling: trong stamp coupling, dữ liệu trao đổi là một phần của cấu trúc hoặc toàn
bộ cấu trúc. Loại coupling này được đánh giá là thấp hơn so với data coupling bởi vì sự
trao đổi là một cấu trúc thay vì một yếu tố đơn nên làm cho nó phức tạp hơn. Một thay
đổi trong cấu trúc sẽ ảnh hưởng đến tất cả đối tượng sử dụng nó. Stamp coupling làm cho
các thành phần phụ thuộc nhiều hơn đến thành phần khác, bởi vì, để tránh những lỗi có
thể xảy ra, những thành phần sẽ phải có hiểu biết về hoạt động bên trong của thành phần
khác sử dụng cùng cấu trúc dữ liệu.
Class_A
Class_B
+ Attribute_A1 : Integer
+ Attribute_A2 : Integer
+ Operation_A () : Integer + Operation_B (Class_A s_Para) : Integer

179
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

integer Operation_A()
{ Operation_B nhận dữ liệu là cấu trúc
Class_A để thực hiện. Do đó, nội dung
int x,y; của nó sẽ sử dụng dữ liệu từng thành
Class_B cB; phần của cấu trúc Class_A. Một sử
thay đổi trong cấu trúc này sẽ ảnh
…. hưởng đến Operation_B
y = cB.Operation_B(this);
…
}

Control coupling: khi một thành phần thành phần gởi một thông tin điều khiển tới một
thành phần khác, hai thành phần này được gọi là có control coupling. Thông tin điều
khiển có thể xuất hiện dưới dạng cờ hiệu thông báo cho thành phần khác hành động sẽ
thực hiện. Khi thông tin điều khiển được gởi đi, thành phần gởi phải biết về hoạt động
bên trong của thành phần nhận, do đó nó tạo ra một sự phụ thuộc giữa các thành phần.
Common coupling: khi hai thành phần tham khảo đến cùng một vùng dữ liệu chung toàn
cục thì có liên kết common coupling. Liên kết này cũng nên tránh bởi vì nó tạo ra một cơ
hội lớn về lỗi trên toàn bộ hệ thống. Một lỗi phát sinh trong bất kỳ một thành phần nào sử
dụng dữ liệu toàn cục này có thể gây ra lỗi trong bất kỳ thành phần khác sử dụng cùng dữ
liệu này.
Content coupling: loại coupling được xếp thấp nhất là content coupling. Bởi vì loại này
giới thiệu một thành phần tham khảo trực tiếp hoạt động bên trong của một thành phần
khác. Ví dụ, một method có thể thay đổi dữ liệu trong một method khác hoặc thay đổi
một đoạn code trong method khác. Hiện nay, các ngôn ngữ lập trình (đặc biệt là ngôn ngữ
lập trình hướng đối tượng) đều không cho phép tạo ra content coupling.
Tên coupling Xếp hạng phụ thuộc
Data coupling Rất thấp
Stamp coupling Thấp
Control coupling Trung bình
Common coupling Cao
Content coupling Rất cao

Coupling thừa kế: là coupling giữa class tổng quát và class chuyên biệt. Một class
chuyên biệt liên kết với class tổng quát của nó thông qua thuộc tính và method. Không
như coupling tương tác, coupling thừa kế càng cao thì càng ưu tiên. Tuy nhiên, để đạt
được mức độ cao coupling thừa kế trong một hệ thống. Mỗi class chuyên biệt không nên
thừa kế những method và thuộc tính không liên quan hoặc không cần thiết. Ví dụ, nếu
một class chuyên biệt chồng lên hầu hết các method hoặc không sử dụng nó từ class tổng
quát, điều này cho thấy coupling thừa kế là thấp và lúc đó thiết kế viên phải thay đổi lại
cách xây dựng tổng quát hoá và chuyên biệt hoá này.
Cohesion
Trong khi coupling đề cập đến mức độ tương tác giữa các đối tượng thành phần thì
cohesion lại đề cập đến sự tương tác bên trong một đối tượng thành phần. Cohesion phản

180
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

ánh tính “đơn mục đích” của một đối tượng. Tất cả các lệnh, chức năng trong một thành
phần được định nghĩa gắn liền tới một nhiệm vụ. Trong hệ thống nếu các thành phần đạt
được mức độ cohesion càng cao thì mức độ liên kết coupling giữa các thành phần càng
yếu, do đó để đạt được đỉnh cao của cohesion thì chúng ta phải làm giảm mức độ
coupling. Cohesion cũng trợ giúp trong thiết kế class bằng việc giúp xác định mục đích và
mục tiêu của class một cách rõ ràng.
Method cohesion: một method chỉ nên đảm nhận một chức năng hoặc một nhiệm vụ.
Thông thường cách đặt tên của method cũng phải ngụ ý nói lên chức năng liên quan của
nó. Ví dụ: Chon_nha_cung_cap(), Tinh_ton(),…
Class cohesion: các method và các thuộc tính trong một class phải có mức độ cohesion
cao, nghĩa là phải được dùng bởi các method bên trong class hoặc chính là method phục
vụ cho mục đích của class.
Cohesion thừa kế: các class chuyên biệt và class tổng quát phải cùng mô tả về một loại
đối tượng của hệ thống. Các thuộc tính và method của class tổng quát phải được thừa
hưởng tối đa trong class chuyên biệt theo cách hoặc là phục vụ cho method của class
chuyên biệt hoặc trở thành một method của class chuyên biệt.

III.2.2. Hệ luận 2: đơn mục đích (single purpose)

Mỗi class phải có một mục đích xác định trong việc đạt được mục tiêu hệ thống. Nếu
chúng ta mô tả một class phức tạp thì hãy phân chia nó thành những class nhỏ hơn, đơn
giản và xác định hơn. Mỗi method chỉ cung cấp một dịch vụ, kích thước không quá lớn
(không nên vượt quá một trang coding)

III.2.3. Hệ luận 3: nhiều class đơn. Tạo các class đơn để cho phép tái sử dụng
Kết quả thiết kế hệ thống tốt chính là tạo ra một tập lớn các class đơn giản hơn là một tập
nhỏ class phức tạp. Các class càng ít chuyên biệt thì các vấn đề trong tương lai càng khó
giải quyết hơn thông qua việc kết nối các class đang có và tái sử dụng chúng.
Thiết kế hướng đối tượng luôn đề xuất việc sản sinh thư viện các thành phần tái sử dụng
và nhấn mạnh trên tính bao bọc (encapsulation), đơn vị hoá (modularization), và tính đa
hình (polymorphism) để tái sử dụng khi xây dụng một đối tượng hơn là làm mới.

III.2.4. Hệ luận 4: ánh xạ giữa các giai đoạn (strong mapping)

Giai đọn phân tích và thiết kế dựa trên cùng mô hình, kết quả mô hình. Từ quá trình phân
tích đến cài đặt, các chi tiết sẽ được đưa thêm vào nhưng vẫn duy trì về cơ bản giống
nhau. Ví dụ, trong giai đoạn phân tích chúng ta xác định class Hoá đơn. Trong giai đoạn
thiết kế chúng ta thiết kế class Hoá đơn: method, dữ liệu,…

III.2.5. Hệ luận 5: chuẩn hoá (standardization).

Đề xuất sự chuẩn hoá bằng việc thiết kế các thành phần có thể thay thế và tái sử dụng các
thành phần có sẳn.
Để tái sử dụng, chúng ta phải có một hiểu biết sâu về các class trong môi trường lập trình
hướng đối tượng chúng ta đang dùng. Hầu hết các hệ thống hướng đối tượng đều có các
các lớp thư viện xây dựng sẳn và ngày càng gia tăng khi chúng ta tạo các ứng dụng mới.
Tri thức về các class tồn tại giúp chúng ta xác định những gì một class mới cần có do thừa
kế hơn là phải xây dựng mới. Mặc dù vậy, tài liệu mô tả các lớp thư viện thường không
được biên tập tốt hoặc ít được cập nhật thường xuyên khi có sự điều chỉnh, nâng cấp. Do
đó, trong quá trình xây dựng các hệ thống chúng ta nên tạo ra các lớp thư viện và tích lũy

181
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

dần nó từ việc xây dựng các hệ thống và luôn luôn xem xét việc thừa kế nó khi xây dựng
một hệ thống mới.

III.2.6. Hệ luận 6: thiết kế thừa kế (design inheritance).

Các đặc tính chung phải được chuyển lên class tổng quát. Cấu trúc class tổng quát – class
chuyên biệt phải tạo ra ý nghĩa luận lý.

IV. Mẫu thiết kế (design pattern)

IV.1 Patterns
Mẫu thiết kế là một giải pháp chung cho các bài toán phổ biến trong việc thiết kế hệ
thống. Đây là một giải pháp tích lũy kinh nghiệm và đã được công nhận là có giá trị. Nó
giúp cho các nhà thiết kế và phát triển có thể áp dụng để giải quyết những bài toán thực tế
tương tự. Như vậy, mẫu thiết kế là một giải pháp chuẩn được đưa ra nhằm nâng cao khả
năng tái sử dụng đối với các vấn đề lặp lại thường xuyên.
Mẫu được thảo luận đầu tiên vào năm 1990 tại các hội nghị (workshop) và từ đó đã có
nhiều nhà nghiên cứu sưu tập để có thể áp dụng vào các kỹ thuật thiết kế hướng đối tượng
nhằm nâng cao hiệu quả trong việc phát triển phần mềm hướng đối tượng, do đó, mẫu
cũng được xem là cách tổ chức hướng đối tượng và nhằm tích lũy kinh nghiệm của những
người đi trước để trợ giúp cho những người đi sau. Một trong những thành quả quan trọng
của thiết kế mẫu đã đúc kết trong cuốn: Design Patterns – Element of Reusable Object –
Oriented Software do bốn đồng tác giả Gramma, Johnson, Helm và Vhissdes xuất bản
năm 1995 đã làm nỗi bật ảnh hưởng của thiết kế mẫu đối với việc phát triển phần mềm.
Sau đó một sách khác được xuất bản làm cho việc sử dụng pattern phổ cập hơn là :
Pattern – Oriented Software Architecture – Asystem of Patterns của Frank Buschmann
năm 1996.
Mô tả pattern
Mỗi pattern được diễn đạt trong hình thức của một luật (gọi là template) hình thức diễn
đạt này thiết lập một mối quan hệ giữa một ngữ cảnh (context) , một hệ thống các ảnh
hưởng (force) phát sinh bởi ngữ cảnh đó, và một cấu hình (configuration) cho phép những
ảnh hưởng này giải quyết bên trong ngữ cảnh.
Name: tên của pattern
Problem: diễn đạt vấn đề mà mẫu có thể áp dụng để giải quyết
Context: mô tả ngữ cảnh có thể ứng dụng mẫu (trong phân tích nghiệp vụ hoặc thiết kế
kiến trúc) và các điều kiện tiên quyết để mẫu áp dụng thành công để giải quyết vấn đề.
Forces: mô tả các ràng buộc và ảnh hưởng và cách nó tương tác và xung đột với ràng
buộc, ảnh hưởng khác và với mục tiêu chúng ta muốn đạt được. Các ràng buộc sẽ tạo ra
sự mất cân đối và mẫu giúp cân đối ràng buộc.
Solution:
Examples:
Resulting context:
Rationale:
Related pattern:
Known uses:

182
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

IV.2 Framework

IV.3 Một số mẫu pattern thông dụng

IV.3.1. Mẫu Façade

Tên (name): Façade
Nguồn gốc (Rationale) và động cơ (motivation): mẫu façade có thể tạo cho công việc truy
cập một số lượng lớn các các thành phần đơn giản hơn bằng việc cung cấp thêm một mức
giao diện. Khi thiết hệ thống tốt, người thiết kế thường nỗ lực tránh những truy cập liên
kết giữa các thành phần, class. Sử dụng mẫu này làm giảm các tương tác có thể tạo ra một
số lượng lớn các coupling phức tạp. Tóm lại, để thực hiện một công việc truy cập đến
nhiều class, chúng ta tạo ra một class và truy cấp các class khác thông qua class này, class
này gọi là façade. Trường hợp áp dụng của mẫu façade có thể là một trong những trường
hợp sau:
- Chúng ta muốn cung cấp một giao diện đơn giản tới một hệ thống con phức tạp,
- Tách rời hệ thống con với đối tượng truy cập và với các hệ thống con khác và do
đó, gia tăng tính độc lập giữa các hệ thống con,
- Chúng ta muốn phân tầng các hệ thống con.

facade

Các class: trong một hệ mẫu façace có ít nhất bốn class: một cho đối tượng truy cập
(client), façade, các class bên dưới façade (ít nhất là 2). Một class façade nên hạn chế

183
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

cách chứa đựng đoạn mã thực sự mà chỉ cần chứa đựng các lời gọi đến các class mức thấp
hơn.

Facade

ClassA ClassB ClassC

Thuận lợi/ khó khăn: thuận lợi chính của mẫu façade là giúp chúng ta quản lý tốt hơn sự
tương tác giữa các thành phần, class. Một nhược điểm của mẫu này là chúng ta có thể
đánh mất một vài tính năng chứa đựng trong các class mức thấp hơn. Tuy nhiên điều này
cũng còn phụ thuộc vào cách chúng ta thiết kế một façade.
Ví dụ: giả sử rằng chúng ta muốn xây dựng một hệ thống cho phép phòng quản trị thiết bị
phục vụ cho việc giảng dạy của một trường đại học bao gồm một số hữu hạn các đối
tượng như là: phòng học, máy chiếu, màn chiếu, máy tính, micro,…. Và cho phép giáo
viên có thể giao tiếp với hệ thống để sử dụng các dịch vụ mà hệ thống này cung cấp nhằm
phục vụ cho công việc giảng dạy của mình. Ví dụ một dịch vụ là “đăng ký lịch dạy” và
giáo viên sẽ phải tương tác với những đối tượng như phòng học, máy chiếu, màn chiếu,
máy tính, micro,… để thay đổi trạng thái những đối tượng này liên quan đến một ngày
giờ đăng ký lịch dạy của mình.

Giaùo vieân

Phoøng hoïc Maùy chieáu Maùy tính Maøn chieáu

Hình 75. Mức độ tương tác phức tạp giữa giáo viên và các đối tượng hệ thống

184
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

Giaùo vieân

Facade

Maùy chieáu Maøn chieáu Phoøn g hoïc Maùy tính

Hình 76. Sử dụng đối tượng Façade làm đơn giản mức độ tương tác
Sơ đồ đầu tiên cho thấy từ phía đối tượng giáo viên phải tương tác với nhiều đối tượng
khác nhau trong hệ thống để thực hiện một dịch vụ, do vậy, nó tạo ra mức độ coupling
phức tạp giữa đối tượng giáo viên và các đối tượng trong hệ thống. Trong khi đó, trong sơ
đồ thứ hai chúng ta đưa vào một lớp đối tượng Façade đối tượng này làm cầu nối giữa đối
tượng giáo viên và các đối tượng trong hệ thống, và từ đây đối tượng giáo viên chỉ cần
thông qua đối tượng Façade để thực hiện dịch vụ hệ thống, đối tượng Façade sẽ tương tác
với các đối tượng hệ thống, và như trên sơ đồ chúng ta thấy, mức độ coupling giữa giáo
viên và các đối tượng hệ thống rất đơn giản.

IV.3.2. Mẫu singleton

Tên: singleton
Nguồn gốc và động cơ: áp dụng trong những tình huống cần có một thể hiện đơn duy
nhất cho một class. Một điều quan trọng trong cài đặt mẫu này là làm sao để tạo ra một
thể hiện đơn đễ dàng truy cập bởi những đối tượng khác. Làm sao để đảm bảo chỉ có một
thể hiện cho class và thể hiện này dể dàng truy cập? Một giải pháp tốt để có thể là để cho
class theo dõi thể hiện của chính nó. Class có thể đảm bảo rằng không thể có những class
khác có thể được tạo (bằng việc không cho phép các yêu cầu tạo đối tượng mới), và class
này cũng cung cấp một cách để truy cập thể hiện duy nhất này. Đây là mẫu Singleton
Class: mẫu này chỉ cần duy nhất một class được dùng để biểu diễn mẫu
Trường hợp áp dụng: sử dụng mẫu singleton khi:
- Chúng ta muốn đảm bảo chỉ có duy nhất một thể hiện cho class và hể hiện này có
thể được truy cập từ những vị trí thích hợp (public trong phạm vi một ứng dụng)
- Khi một thể hiện duy nhất này có thể mở rộng và người dùng có thể sử dụng một
thể hiện mở rộng ma không cần thay đổi mã nguồn của class.
Singleton
- singletonData
- uniqueInstance
+ instance () kiểu static trả về môt thể hiện
+ getSingletonData () duy nhất
+ singletonOperation ()

185
Phần 3 – Thiết kế Chương 7 - Thiết kế hệ thống

Trong mẫu singleton, một phương thức xác định thể hiện được thêm vào phần định nghĩa
lớp. Phương thức này trả về một tham chiếu cho một thể hiện đơn của lớp hoặc sẽ tạo ra
thể hiện đơn nếu nó chưa được tạo trước đó. Để đảm bảo cho class chỉ có một thể hiện,
một cách chung để làm điều này là che dấu phương thức tạo ra thể hiện của class (đó là,
hoặc nó là một hàm static hoặc là một method khai báo private).
Ví dụ: giả sử của hàng phát triển thành công ty và có nhiều nhiều chi nhánh bán hàng tại
nhiều địa điểm trong thành phố.

Thuận lợi:

IV.3.3. Mẫu proxy

Tên: proxy

186