Chương IV. Tổng quan về ngôn ngữ mô hình hóa thống nhất uml và phương pháp hướng đối tượng pot

CHƯƠNG IV – TỔNG QUAN VỀ NGÔN NGỮ MÔ HÌNH HÓA THỐNG NHẤT
UML VÀ PHƯƠNG PHÁP HƯỚNG ĐỐI TƯỢNG.
1. Sự ra đời của phương pháp hướng đối tượng
Phân tích hệ thống theo phương pháp hướng đối tượng (object-oriented
analysis, OOA) là một kỹ thuật đặc tả nửa hình thức. Hiện nay cũng có khá
nhiều kỹ thuật phân tích hướng đối tượng, nhưng về bản chất chúng tương
đương nhau. Giống như các kỹ thuật nửa hình thức, phân tích hướng đối
tượng cũng dùng các biểu tượng đồ họa để biểu diễn các đối tượng và các quá
trình xử lý. OOA ra đời vào đầu những năm 90 của thế kỷ trước. Năm 1991,
Rumbaugh (New york) và các cộng sự đưa ra kỹ thuật mô hình hóa hướng đối
tượng (object modeling technique, OMT), được sử dụng cho phân tích và
thiết kế hướng đối tượng. Năm 1994 Grady Booch (Rational, California) cũng
phát triển một kỹ thuật OOA mà về bản chất cũng tương tự như của
Rumbaugh. Năm 1994 Rumbaugh gặp Booch tại Rational và hai ông đã cùng
nhau phát triển công cụ gọi là phương pháp luận thống nhất (unified
methodology), tuy nhiên hai ông đã nhanh chóng nhận ra rằng thực chất
không phải là phương pháp, mà đơn thuần chỉ là các biểu tượng dùng để biểu
diễn sản phẩm phần mềm hướng đối tượng (HĐT), và đã đổi tên công cụ
thành "ngôn ngữ mô hình hóa thống nhất" (unified modeling language, gọi tắt
là UML). Năm 1995 Ivar Jacobson, người tiên phong trong lĩnh vực công
nghệ phần mềm HĐT, đã gặp Rumbaugh và Booch tại Rational. Jacobson đã
nghiên cứu phương pháp HĐT từ năm 1967 và năm 1992 cho ra đời phương
pháp mang tên "công nghệ phần mềm hướng đối tượng" (object-oriented
software engineering). Phiên bản 1.0 của ngôn ngữ UML đã được xuất bản
năm 1997, được coi là công trình chung của ba tác giả Rumbaugh, Jacobson
và Booch. UML hiện nay trở thành chuẩn quốc tế, đang được hiệu chỉnh,
phát triển dưới sự giám sát của nhóm quản lý hướng đối tượng (Object
Management Group), là hiệp hội các công ty trên phạm vi toàn thế giới có
hoạt động tích cực trong phương pháp HĐT.
Jacobson, Booch và Rumbaugh đã cùng nhau xây dựng công cụ được gọi
là Rational Unified Process là quy trình phát triển phần mềm thống nhất dựa

trên UML đầu tiên. (Quy trình này có tên là Rational, là nơi công cụ này ra
đời). Một phương pháp quan trọng khác dựa vào UML là Catalysis do
D'Souza và Wills xây dựng năm 1999. UML được chấp nhận rộng rãi trên
toàn thế giới và có thể khẳng định gần như chắc chắn rằng, các phương pháp
phát triển phần mềm trong tương lai cũng sẽ lấy UML làm cơ sở.
62
Trong tài liệu này UML được dùng để biểu diễn cả phân tích và thiết kế
HĐT.
Phân tích hướng đối tượng chính là cách nhìn nhận phần mềm được tạo
thành bởi các đối tượng có mối liên quan với nhau. Vì OOA hay OOD đều
sử dụng UML làm công cụ diễn đạt, do đó trước hết chúng ta sẽ tìm hiểu qua
về ngôn ngữ này.
2. Tổng quan về ngôn ngữ mô hình hoá thống nhất UML
2.1. UML là gì?
UML là ngôn ngữ trực quan (tức là sử dụng các biểu tượng để mô
tả các vấn đề và công việc) được dùng trong pha phân tích và pha thiết kế
trong quy trình xây dựng một phần mềm hướng đối tượng. UML là một ngôn
ngữ đặc tả nửa hình thức (semiformal specification language, tuy nhiên cũng
có tài liệu cho rằng UML là ngôn ngữ hình thức).
Giống như những ngôn ngữ khác (ngôn ngữ tự nhiên, ngôn ngữ lập trình,
ngôn ngữ cho người khiếm thính ), UML cũng có một tập các phần tử và tập
các quy tắc để diễn đạt vấn đề. Tuy nhiên UML không phải là ngôn ngữ lập
trình, nghĩa là bạn không thể sử dụng nó để viết chương trình. UML cũng
không phải là một phương pháp, phương pháp luận hay quy trình phát triển
phần mềm.
Hầu hết các phần tử của UML là các biểu tượng đồ họa như đoạn thẳng,
hình chữ nhật, hình ôvan Các phần tử này thường có nhãn để chỉ rõ tác dụng
của nó. Có thể sử dụng UML để tạo ra một mô hình có dạng chuẩn dữ liệu
(giống như CORBA và XMI DTD). Tuy nhiên cách biễu diễn bằng hình ảnh
của UML vẫn được sử dụng nhiều vì dễ hiểu hơn.

2.2. Một số khái niệm và thành phần cơ bản của UML
2.2.1. Mô hình (Model)
Theo từ điển tiếng Việt, từ mô hình có hai nghĩa:
1. Là vật cùng hình dạng nhưng làm thu nhỏ lại nhiều lần, dùng để mô
phỏng cấu tạo và hoạt động của một vật khác với mục đích trưng bày và
nghiên cứu (ví dụ: mô hình máy bay triển lãm mô hình nhà ở kiểu mới).
2. Là hình thức diễn đạt hết sức gọn theo một ngôn ngữ nào đó các đặc
trưng chủ yếu của một đối tượng để nghiên cứu đối tượng ấy. Mô hình hóa
(modeling) là tạo ra mô hình để trên mô hình ấy nghiên cứu một đối tượng
nào đó.
63
Trong UML từ mô hình được hiểu theo nghĩa thứ hai, nhưng ngôn ngữ sử
dụng là ngôn ngữ trực quan. Tuy nhiên, thường thì mô hình không chỉ một
biểu diễn cụ thể, mà là tập hợp của một số biểu diễn, ví dụ mô hình use-case
có nghĩa là tập hợp các biểu đồ use-case, mô hình động là tập hợp các biểu đồ
biểu diễn sự thay đổi theo thời gian như biểu đồ trạng thái, biểu đồ tương tác,
biểu đồ hoạt động
2.2.2. Hướng nhìn
Hướng nhìn (có một số tài liệu gọi là khung nhìn, hay góc nhìn)
là một khái niệm trong UML, chứ không phải là một thành phần biểu diễn có
thể nhìn thấy được như use-case, biểu đồ, lớp Trong đời thường, khi quan
sát một vật thể phức tạp ta phải nhìn từ nhiều hướng khác nhau. Khi biểu diễn
các vật đó trên giấy cũng không thể chỉ biểu diễn trong một bản vẽ duy nhất
mà phải dùng nhiều bản vẽ, mỗi bản vẽ biểu diễn vật từ một hướng nhìn. Với
một phần mềm phức tạp cũng vậy, ta cũng phải quan sát từ những hướng khác
nhau. Tuy nhiên hướng ở đây không còn được hiểu theo nghĩa đen nữa, vì
phần mềm không phải là một vật có thể quan sát một cách rõ ràng như ngôi
nhà, chiếc cầu Hướng nhìn ở đây được hiểu là các khía cạnh khác nhau cần
mô tả, mô hình hoá và trừu tượng hoá của hệ thống. Mỗi hướng nhìn gồm một
số loại biểu đồ khác nhau.

Các hướng nhìn thường sử dụng là:
Use-case view (Hướng nhìn theo trường hợp sử dụng).
Mô tả các chức năng của hệ thống có ý nghĩa cho các tác nhân. Tác nhân ở
đây có thể là người sử dụng hoặc một hệ thống khác. Hướng nhìn use-case
mang tính trung tâm, vì nó là cơ sở cho các hướng nhìn khác.
Logical view (Hướng nhìn logic).
Ngược lại với hướng nhìn use-case, hướng nhìn logic nhìn vào bên trong
hệ thống. Nó mô tả các cấu trúc tĩnh (lớp, đối tượng, quan hệ), cũng như
tương tác động giữa các đối tượng.
Component view (Hướng nhìn theo thành phần).
Deployment view (Hướng nhìn triển khai).
Concurrency view (Hướng nhìn song song).
Trong các hướng nhìn trên đây thì hướng nhìn use-case và hướng nhìn
logic đóng vai trò quan trọng cốt yếu trong phân tích và thiết kế hướng đối
tượng.
64
2.2.3. Biểu đồ (Diagram)
Mỗi biểu đồ là một loại hình vẽ mô tả phần mềm trong một
khung nhìn.
Các dạng biểu đồ thường gặp (các biểu đồ hay sử dụng hơn được in đậm):
Use-case diagram (biểu đồ trường hợp sử dụng)
Class diagram (biểu đồ lớp)
Object diagram (biểu đồ đối tượng)
Activity diagram (biểu đồ hoạt động)
State diagram (biểu đồ trạng thái)
Sequence diagram (biểu đồ tuần tự)
Collaboration diagram (biểu đồ tương tác)
Component diagram (biểu đồ thành phần)
Deployment diagram (biểu đồ triển khai)
Concurrency diagram (biểu đồ song song)

Trong các biểu đồ trên thì hai loại biểu đồ quan trọng nhất là biểu đồ use-
case và biểu đồ lớp. Các biểu đồ use-case cho ta bức tranh toàn cảnh về
những gì đang xảy ra trong hệ thống (hiện tại hoặc dự định xây dựng), hay nói
một cách khác thì mô hình này cung cấp một cách nhìn tổng thể về những gì
hệ thống sẽ làm và ai sẽ dùng nó.

Biểu đồ lớp (gồm các lớp cùng mối quan hệ giữa chúng) cho ta một cách
nhìn tĩnh về cấu trúc của các thành phần (lớp) tạo nên phần mềm. Như vậy
biểu đồ này đã phần nào cho ta cách nhìn vào "bên trong" của hệ thống.
Biểu đồ hoạt động mà một dạng đặc biệt của nó là biểu đồ trạng thái cho ta
biết những hoạt động hay trạng thái nào cần phải trải qua để đi từ một hoạt
động hoặc trạng thái này đến hoạt động hoặc trạng thái khác. Ba khái niệm
quan trọng được sử dụng trong loại biểu đồ này là hoạt động (activity), trạng
thái (state) và chuyển tiếp (transition). Thực ra, hai khái niệm trạng thái và
hoạt động gần như tương đương nhau. Theo một nghĩa nào đó thì có thể xem
khái niệm trạng thái là khái niệm rộng hơn, vì trạng thái cũng có thể thực hiện
các hành động. Tuy nhiên, thông thường thì hoạt động phải thực hiện hành
động, còn trạng thái ngầm chỉ việc chờ đợi. Ví dụ máy điện thoại đang ở trạng
thái gác máy hay máy bận. Ta cũng có thể nói máy điện thoại đang ở trạng
thái quay số (hoạt động) hay bị ngắt kết nối. Mặc dù rất khó phân biệt hai
khái niệm biểu đồ trạng thái và biểu đồ hoạt động, nhưng người ta vẫn xem
xét hai loại biểu đồ này một cách riêng biệt. Nếu như sự chú ý được tập trung
vào các hoạt động thì ta gọi biểu đồ là biểu đồ hoạt động. Khi đó biểu đồ có
65
thể có các trạng thái nhưng trạng thái chỉ biểu diễn các điểm chờ trước khi
xảy ra hoạt động tiếp theo. Nếu sự chú ý là các trạng thái, thì biểu đồ có thể
chứa các hoạt động, nhưng chỉ nhằm mô tả hàng động xảy ra trước khi
chuyển đến một trạng thái mới.
Nếu như các "điểm dừng" giữa các chuyển tiếp trong biểu đồ hoạt động là
hoạt động hoặc trạng thái thì trong biểu đồ tương tác (interaction diagram)

các "điểm dừng" lại là các đối tượng hoặc tác nhân (tác nhân cũng là đối
tượng). Biểu đồ này mô tả các tương tác theo thứ tự thời gian giữa các đối
tượng để thực hiện một công việc gì đó (thường là công việc gắn với use-
case). Có hai loại biểu đồ tương tác là tuần tự (sequence diagram) và cộng tác
(collaboration diagram). Cả hai loại biểu đồ đều chỉ ra trình tự thực hiện các
hành động, nhưng nếu thời gian được nhấn mạnh thì người ta sử dụng biểu đồ
tuần tự, còn nếu hành động được nhấn mạnh thì người ta dùng biểu đồ cộng
tác.
2.2.4. Phần tử mô hình (Model element)
Mỗi khái niệm được sử dụng trong biểu đồ được gọi là phần tử
mô hình.

2.2.5. Gói (package)
UML được tổ chức thành các gói, mỗi gói chứa một số biểu đồ.
2.2.6. Hệ thống con (sub-system)
Hệ thống con biểu diễn các bộ phận của hệ thống vật lý, chúng
có thể được tổ chức trong các package.
2.2.7. Khuôn mẫu (Stereotype)
Được sử dụng để định nghĩa một loại phần tử mô hình mới dựa
vào một loại phần tử đã có.
2.2.8. Đặc tả (Specification) Mô tả chi tiết một phần tử.
Đặc tả (Specification): mô tả chi tiết một phần tử.
2.2.9. Cơ chế chung (General Merchanism)
Cơ chế chung (General Merchanism)
66
2.2.10. Trang trí (Adornment)
Trang trí (Adornment)
2.2.11. Ghi chú (Note)
Ghi chú (Note)
2.2.12. Giá trị đính kèm (Tagged value).

Giá trị đính kèm (Tagged value).
2.2.13. Ràng buộc (Constraint)
Ràng buộc (Constraint)
2.2.14. Các công cụ (Tools)
Các công cụ (Tools )
3. Mô hình use-case
3.1. Biểu đồ use-case
Use-case như tên gọi của nó, là một trường hợp sử dụng của hệ
thống, nó mô tả một chuỗi hành động mà hệ thống sẽ thực hiện để đạt được
kết quả có ý nghĩa đối với một tác nhân nào đó.
Tác nhân (actor) ở đây có thể là người hoặc hệ thống tương tác với use-
case. Thường actor là một người sử dụng hệ thống. Trong UML, tác nhân
thường là một lớp.
Một biểu đồ use-case (use-case diagram) được tạo ra từ các hình ô van
(biểu diễn use-case) và hình người (biểu diễn tác nhân sử dụng user-case).
Tên của tác nhân (actor) được đặt phía dưới hình người, tên của use-case
được đặt bên trong hình ô van hoặc phía dưới. Chúng được liên kết với nhau
bằng các đoạn thẳng để chỉ rõ tác nhân nào sử dụng use-case nào.
Các biểu đồ use-case (sẽ được gọi là mô hình use-case) cung cấp một bức
tranh toàn cảnh về những gì đang xảy ra trong hệ thống (hiện tại hay dự định
xây dựng), cụ thể hơn, mô hình use-case cho ta câu trả lời cho câu hỏi: ai
(hoặc hệ thống nào) sử dụng phần mềm và sử dụng để làm gì. Các use-case
được Jacobson đưa ra vào năm 1992, ban đầu được được thực hiện trong công
ty Ericsson, Thụy điển. Trong cách tiếp cận của Jacobson thì use-case là điểm
bắt đầu trong quá trình xây dựng một hệ thống phần mềm mới. Trong thuật
ngữ UML thì gói use-case là một gói con (sub-package) của gói Behavioural
67
Element (phần tử hành vi). Nghĩa là nó được sử dụng để xác định hành vi của
một thực thể. Use-case không xác định chi tiết các hành vi được thực hiện
như thế nào, chi tiết này sẽ được thảo luận trong các mô hình khác của quy

trình thiết kế hệ thống. Thông thường, cách thực hiện một use-case được định
nghĩa trong một hoặc nhiều mô hình cộng tác (collaboration diagram) nhằm
biểu diễn sự tương tác giữa các đối tượng cùng hoạt động.
Mục đích của biểu đồ use-case:
- Dùng để mô hình hóa các chuỗi hành động của hệ thống.
- Cung cấp một cách nhìn tổng thể về những gì mà hệ thống sẽ làm và ai
sẽ dùng nó.
- Đưa ra cơ sở để xác định giao tiếp người-máy của hệ thống.
- Dùng để mô hình hóa các kịch bản (scenario) cho một trường hợp sử
dụng.
- Để người dùng cuối có thể hiểu được và có thể giao tiếp với hệ thống ở
mức tổng thể.
- Làm cơ sở cho việc phác thảo ra các đặc tả kiểm tra.
Ví dụ về use-case: trong một hệ thống quản lý công văn của một cơ quan
có thể có biểu đồ use-case như sau:
Nếu các use-case là các thành phần của một hệ thống hoặc hệ thống con
thì chúng được nhóm lại trong một hình chữ nhật được đặt tên (chính là tên hệ
thống).
Ví dụ: Hệ thống bán hàng
Hình 4.1. Các use-case trong một hệ thống (con)
68
Xem công văn
Văn thư
Bán hàng
Bán hàng
Xem
bảng giá
Khách
hàng
Nhân viên

bán hàng
Tìm Actor bằng cách trả lời câu hỏi: actor nào thao tác với hệ thống và vai
trò của actor đó là gì?
Xác định Use-case bằng cách trả lời câu hỏi: một Actor sẽ làm gì để thao
tác với hệ thống?
Các kiểu kết hợp (association) và quan hệ (relationship) giữa các use-
case:
Kết hợp generalization (tổng quát hóa):
+ Kết hợp generalization giữa các use-case: kết hợp này được biểu diễn
bằng một đoạn thẳng có mũi tên hình tam giác đi từ một use-case đến
use-case tổng quát hơn.
Hình 4.2. Kết hợp generalization giữa các use-case
Hình 4.2. chỉ sự kết hợp tổng quát hoá giữa các use-case nhập số liệu với
nhập từ bàn phím và nhập từ tệp. Ở đây nhập số liệu là use-case tổng quát,
còn các use-case còn lại là các trường hợp riêng. Đôi khi một use-case tổng
quát có thể không bao giờ tồn tại trong hệ thống thực. Nó chỉ đóng vai trò
chung cho các use-case cụ thể (như trường hợp trên đây). Trong trường hợp
này chúng ta gọi là abstract use-case. Tên của loại use-case này được in
nghiêng. Các use-case không phải là abstract thì được gọi là concret use-case
hoặc real use-case.
+ Kết hợp generalization giữa các Actor: kết hợp này được biểu diễn bằng
một đoạn thẳng có mũi tên hình tam giác đi từ một Actor đến Actor tổng
quát hơn, ví dụ:
Hình 4.3. Kết hợp generalization giữa các Actor
69
Người sử dụng
Nhập số liệu
Nhập từ bàn phím Nhập từ tệp
Văn thưNhân viên cơ quan
Hình 4.3. có nghĩa: tác nhân văn thư là trường hợp riêng của tác nhân

nhân viên. Điều này phù hợp với thực tế: văn thư cũng là nhân viên cơ quan,
nhưng nhân viên cơ quan có thể không phải là văn thư. Vậy văn thư là trường
hợp riêng của nhân viên.
Trong các ngôn ngữ lập trình hỗ trợ HĐT, generalization thường được cài
đặt bằng kỹ thuật kế thừa (inheritance).
Có 2 loại quan hệ giữa các use-case:
+ Quan hệ include (bao hàm) giữa các use-case. Quan hệ này được biểu
diễn bằng mũi tên đứt nét từ use-case bao hàm đến use-case con. Từ
<<include>> được đặt cạnh đoạn thẳng này như hình 7.4.
Ví dụ:
Hình 4.4. Quan hệ include giữa các use-case
Hình 4.4. có nghĩa là: thao tác bán hàng bao gồm một số thao tác, trong đó
có thao tác In hóa đơn. Điều này có nghĩa là nếu Bán hàng thì phải In hóa
đơn nhưng ngược lại thì chưa chắc.
+ Quan hệ extend (mở rộng) giữa các use-case. Quan hệ này cũng được
biểu diễn bằng mũi tên đứt nét từ use-case cần mở rộng đến use-case được mở
rộng. Từ <<extend>> được đặt cạnh đoạn thẳng này như hình 7.5.
Ví dụ:
Hình 4.5. Quan hệ extend giữa các use-case
Hình 4.5. có nghĩa là use-case bán hàng được mở rộng sang use-case ký
hợp đồng bảo hành. Điều này có nghĩa là: trong điều kiện bình thường thì
70
Bán
hàng
In hóa đơn
<<include>>
Bán
hàng
Ký hợp đồng
bảo hành

<<extend>>
thao tác bán hàng không dẫn tới việc ký hợp đồng bảo hành. Chỉ trong một số
điều kiện nào đó thì mới có sự mở rộng, ví dụ như khi bán các thiết bị tin học
chẳng hạn. Vậy use-case mở rộng (ở Hình 4.5 là "ký hợp đồng bảo hành") có
thể coi là một tình huống phát sinh từ use-case được mở rộng (ở trên là "bán
hàng"). Tuy nhiên, trong cách biểu diễn thì có phần ngược với cách suy nghĩ,
cũng giống như generalization, mũi tên đi từ cái phát sinh đến cái gốc. Để chỉ
rõ điều kiện phát sinh, người ta viết thêm điều kiện trong use-case gốc và gọi
phần điều kiện này là các điểm mở rộng (extension points). Ví dụ với use-
case bán hàng có thể viết như sau:
Hình 4.5b. Quan hệ extend giữa các use-case
Có thể so sánh sự khác biệt giữa generalization, extend và include thông
qua hình sau đây:
Hình 4.6. So sánh giữa generalization, extend và include.
Ta có thể đọc như sau: thao tác giao hàng được thực hiện bằng một trong
hai cách: giao ở cửa hàng hoặc mang đến tận nhà. Hai cách giao hàng này có
thể có một thao tác chung là "đóng gói hàng" nằm ở nút giao hàng. Như vậy,
trong kết hợp generalization thì các thao tác chung nằm ở nút gốc (nếu có),
còn các trường hợp riêng nằm ở các nút con. Thao tác bán hàng được thực
hiện bằng hai thao tác: in hóa đơn và xuất hàng. Thao tác bán hàng trong điều
kiện bình thường thì được thực hiện suôn sẻ. Tuy nhiên, có một tình huống
71
Bán hàng
Các điểm mở rộng:
Bán các thiết bị tin
học
Ký hợp đồng
bảo hành
<<extend>>
Giao hàng

Giao ở cửa
hàng
Mang đến
tận nhà
Bán hàng
In hóa đơn Xuất hàng
<<include>> <<include>>
Bán hàng
<<extend>> <<extend>>
<<extend>>
Nhập hàng từ
nhà cung cấp
Hết hàng
phát sinh làm cho thao tác bán hàng không thực hiện được đó là tình hưống
hết hàng. Tình huống hết hàng có thể phát sinh tình huống nhập hàng từ nhà
cung cấp. Vậy thao tác nhập hàng từ nhà cung cấp cũng có thể coi là được
phát sinh từ thao tác bán hàng.
Chú ý: trong UML phiên bản 1.1, include và extend được gọi là uses
và extends.
Ngoài ra các use-case liên quan đến nhau có thể được nhóm lại thành gói,
ví dụ:
Hình 4.7. Các gói chứa use-case
3.2. Mô hình use-case
Mô hình use-case là tập hợp các biểu đồ use-case. Biểu đồ use-case
lại là tập hợp của một số use-case cùng các kết hợp và các tác nhân sử dụng
chúng. Trong UML, use-case được sử dụng để nắm bắt các yêu cầu ở mức
ngoài về chức năng sử dụng của hệ thống (to capture high level user-
functional requirements of the system). Nên lưu ý là use-case không nên sử
dụng để mô tả các yêu cầu phi chức năng hay "bên trong" các chức năng (tức
là cách thực thi các chức năng), vì use-case trước hết là kỹ thuật phi hình

thức và không hoàn toàn chính xác. Tuy nhiên use-case giúp chúng ta xác
định cấu trúc và các yêu cầu chính của sản phẩm phần mềm.
Mô hình use-case đưa ra câu trả lời cho câu hỏi: hệ thống làm gì khi quan
sát từ bên ngoài? Use-case là một thành phần của dự toán và là thành phần
nhỏ bé nhất của sản phẩm chuyển giao. Nếu sản phẩm được tinh chỉnh theo
nhiều bước và chuyển giao nhiều lần thì mỗi lần chuyển giao lại có một mô
hình use-case kèm theo. Các use-case không phải là mô hình phân rã chức
năng, cũng không phải nhằm nắm bắt tất cả các yêu cầu của hệ thống. Mô
hình use-case chỉ là bước ban đầu. Để diễn tả sâu hơn cấu trúc và cách hoạt
động của hệ thống, ta cần đến các kỹ thuật mô hình hóa khác. Mô hình đối
tượng (Object model) mô tả cấu trúc tĩnh của hệ thống và quan hệ giữa các
lớp. Mô hình động gồm các biểu đồ như biểu đồ tuần tự, biểu đồ trạng thái, sẽ
mô tả chi tiết cách ứng xử của hệ thống, nhằm trả lời cho câu hỏi: hệ thống
72
Quản lý khoBán hàng
thực hiện các chức năng như thế nào. Mô hình quy trình công việc (business
process model) sẽ cho biết trình tự các công việc được thực hiện như thế nào,
cả phần tin học hóa và phần thủ công.
Use-case không phải là kỹ thuật bắt buộc trong mô hình hóa hướng đối
tượng. Và cũng không có lý do cơ bản nào để ngăn cản việc ứng dụng nó như
một công cụ ban đầu của phương pháp phát triển có cấu trúc. Tuy nhiên,
chúng không được dùng trong phân tích có cấu trúc vì những người sáng tạo
ra chúng đang tập trung sự chú ý vào việc phát triển các phương pháp hướng
đối tượng.
3.3. Xây dựng mô hình use-case như thế nào?
Như đã nói đến trong phần trước, theo thuật ngữ của UML thì
người hoặc hệ thống sử dụng phần mềm mà ta đang xem xét được gọi là tác
nhân của phần mềm đó, còn use-case như tên gọi của nó, là một trường hợp
sử dụng của phần mềm liên quan đến tác nhân nào đó.
Để xây dựng mô hình này, ta cần trả lời hai câu hỏi:

1) Ai (hoặc hệ thống nào) trực tiếp sử dụng phần mềm? Câu trả lời sẽ đưa
ra danh sách các tác nhân.
Từ danh sách các tác nhân đầu tiên ta chọn ra tác nhân quan trọng nhất,
sau đó là tác nhân quan trọng thứ nhì, Với mỗi tác nhân ta nêu câu hỏi:
2) Tác nhân muốn làm gì với hệ thống (tức là phần mềm)? Câu trả lời sẽ
là các use-case.
Ban đầu mỗi tác nhân cùng các use-case liên quan sẽ là một biểu đồ. Tuy
nhiên, sau đó ta cần xem xét các use-case của các tác nhân khác nhau. Nếu ta
thấy có nhiều điểm chung thì nên dùng một use-case cho các tác nhân. Ví dụ,
use-case mượn sách của tác nhân bạn đọc cũng tương tự như use-case cho
mượn sách của thủ thư nên ta gộp hai use-case này thành một và gọi là use-
case mượn sách.
Nếu trình bày một cách có hệ thống thì để xác định một use-case đơn giản
(a simple use-case recipe) ta cần thực hiện 8 bước như sau:
Bước 1. Nhận diện xem ai sẽ là người trực tiếp sử dụng hệ thống, ví dụ,
người sẽ gõ vào bàn phím để sử dụng chương trình. Họ là các tác nhân. Tác
nhân có thể là một hệ thống khác, để tìm tác nhân loại này ta nêu câu hỏi: hệ
thống nào tương tác với hệ thống này?
73
Bước 2. Hãy chọn một phần tử trong các tác nhân. Ví dụ đó là thư ký nhận
đơn đặt hàng (sales order clerk), mà ta sẽ gọi đơn giản là người bán hàng.
Bước 3. Hãy xác định xem tác nhân này muốn làm gì với hệ thống. Những
việc tác nhân này muốn thực hiện trên hệ thống sẽ trở thành các use-case.
Bước 4. Với mỗi use-case hãy xác định dòng công việc (course) thường
xuyên nhất khi actor sử dụng hệ thống (the most usual course when the actor
is using the system).
Bước 5. Mô tả dòng công việc cơ sở này trong phần diễn tả use-case (the
description for the use-case).
Hãy mô tả theo cách "tác nhân làm cái gì đó, hệ thống sẽ làm cái gì đó ",
tuy nhiên chỉ giữ ở mức bên ngoài. Bạn hãy chỉ mô tả những điều hệ thống

làm mà tác nhân nhận biết được và ngược lại, những điều tác nhân làm mà hệ
thống nhận biết được. Trước mắt chưa cần quan tâm đến các quan hệ đặc biệt
như <<extend>> hay <<include>>.
Hình 4.8. Diễn tả dòng công việc cho mỗi use-case
Bước 6. Nếu bạn cảm thấy vừa lòng với các dòng công việc cơ bản thì hãy
xem xét đến các khả năng khác và bổ sung các khả năng này.
74
Người bán
hàng
Nhập
đơn đặt
hàng
Diễn tả (description)
Người bán hàng nhập họ của khách hàng. Hệ thống hiện trên màn
hình tất cả các khách hàng có cùng họ. Người bán hàng chọn một
người trong số này. Các thông tin chi tiết về khách hàng này được
hiện trên màn hình. Với mỗi mặt hàng khách muốn đặt mua, người
bán hàng nhập các thông tin chi tiết về mặt hàng trong một dòng.
Khi tất cả các mặt hàng đã được nhập thì hệ thống xác nhận đơn
đặt hàng (confirm).
Kiểm tra tiền
nợ của khách
hàng
Diễn tả
Người bán hàng nhập họ của khách hàng. Hệ thống
hiện trên màn hình tất cả các khách hàng có cùng
họ. Người bán hàng chọn một người trong số này.
Các thông tin chi tiết về khách hàng này được hiện
trên màn hình. Đồng thời, hệ thống hiện trên màn
hình lịch trình trả nợ của khách trong sáu tháng gần

đây.
Diễn tả (description)
Người bán hàng nhập họ của khách hàng. Hệ thống hiện trên màn
hình tất cả các khách hàng có cùng họ. Người bán hàng chọn một
người trong số này. Các thông tin chi tiết về khách hàng này được
hiện trên màn hình. Với mỗi mặt hàng khách muốn đặt mua, người
bán hàng nhập các thông tin chi tiết về mặt hàng trong một dòng.
Khi tất cả các mặt hàng đã được nhập thì hệ thống xác nhận đơn
đặt hàng (confirm).
Người bán
hàng
Nhập
đơn đặt
hàng
Kiểm tra tiền
nợ của khách
hàng
Diễn tả
Người bán hàng nhập họ của khách hàng. Hệ thống
hiện trên màn hình tất cả các khách hàng có cùng
họ. Người bán hàng chọn một người trong số này.
Các thông tin chi tiết về khách hàng này được hiện
trên màn hình. Đồng thời, hệ thống hiện trên màn
hình lịch trình trả nợ của khách trong sáu tháng gần
đây.
Nhập lại do
không tìm thấy
khách hàng
Diễn tả
Nếu trong use-case “Kiểm tra tiền nợ khách hàng”,

nếu hệ thống không tìm thấy khách hàng nào có họ
như vừa nhập thì báo lỗi và cho phép người sử
dụng nhập lại họ khác và tiếp tục tìm kiếm
<<extend>>
Hình 4.9. Bổ sung thêm use-case ứng với khả năng khác
Bước 7. Đọc lại các diễn tả và đối chiếu so sánh. Nếu phát hiện thấy có
phần chung thì nên tách ra thành các use-case cho các dòng công việc chung.
Hình 4.10. Tách dòng công việc chung thành use-case dùng chung
(Ta thấy rằng use-case "Nhập lại vì không tìm thấy khách hàng" được mở
rộng từ use-case "Hiện thông tin chi tiết về khách hàng", có nghĩa là use-case
" Hiện thông tin " làm nảy sinh use-case "Nhập lại vì không tìm thấy ").
Bước 8. Lặp lại các bước từ 2 đến 7 cho tất cả các tác nhân.
75
Người bán
hàng
Nhập
đơn đặt
hàng
Diễn tả
Sử dụng use-case “Hiện thông tin ” để
tìm và hiện ra thông tin chi tiết về khách
hàng. Với mỗi mặt hàng khách muốn
đặt mua, người bán hàng nhập các
thông tin chi tiết về mặt hàng trong một
dòng. Khi tất cả các mặt hàng đã được
nhập thì hệ thống xác nhận đơn đặt
hàng (confirm).
Kiểm tra tiền
nợ của khách
hàng

Diễn tả
Sử dụng use-case “Hiện thông
tin ” để tìm và hiện ra thông
tin chi tiết về khách hàng.Đồng
thời, hệ thống hiện trên màn
hình lịch trình trả nợ của khách
hàng trong sáu tháng gần đây
Nhập lại vì
không tìm thấy
khách hàng
Diễn tả
Sử dụng use-case “Hiện thông tin ” để tìm và hiện
ra thông tin chi tiết về khách hàng Nếu hệ thống
không tìm thấy khách hàng nào có họ như vừa
nhập thì báo lỗi và cho phép người sử dụng nhập
lại họ khác và tiếp tục tìm kiếm
<<extend>>
Hiện thông tin
chi tiết về
khách hàng
<<include
>>
<<include
>>
Trên đây là cách khởi đầu tốt cho quá trình mô hình hóa use-case. Tuy
nhiên một lỗi thường gặp là quá nhiều use-case được đưa vào mô hình. Vậy
bước tiếp theo chúng ta xem xét vấn đề: cái gì không nên đưa vào mô hình
use-case?
3.4. Cái gì không nên đưa vào mô hình use-case?
Trong quá trình xây dựng mô hình use-case, có thể còn có một số

thông tin cần thiết và chi tiết mà bạn cần biểu diễn, đừng vội đưa vào mô hình
use-case. Tốt hơn, ta nên sử dụng một kỹ thuật mô hình hóa khác thích hợp
hơn. Nếu muốn mô tả thông tin về mối quan hệ đặc biệt giữa các đối tượng, ví
dụ một đơn đặt hàng có thể chứa một hoặc nhiều dòng thông tin về các mặt
hàng, hay khách hàng ngoài họ ra còn có tên riêng, địa chỉ và các thông tin
khác thì tốt hơn nên dùng mô hình lớp. Hoặc nếu chúng ta muốn mô tả rằng
danh sách khách hàng có thể chọn từ hộp ListBox thì nên dùng biểu đồ tuần
tự hay một bản mẫu GUI hoặc cả hai
Cũng cần thận trong trong việc bổ sung thêm các use-case theo các quan
hệ include và extend để tránh tình trạng đi quá xa, làm cho mô hình trở nên
quá phức tạp. Chỉ nên phát triển ở mức vừa phải, trong phạm vi mục đích của
mô hình use-case là: mô tả các chức năng sử dụng của phần mềm ở mức cao,
tức là mức bên ngoài, làm cơ sở cho việc ước lượng chi phí và chuyển giao.
3.5. Cân chỉnh lại mô hình use-case
Sự cân chỉnh mô hình use-case chính là sự lựa chọn một mô hình
phù hợp giữa trường hợp quá phức tạp (vì chứa quá nhiều use-case dùng
chung và use-case mở rộng), và trường hợp đơn giản nhất là không chứa các
quan hệ mở rộng hoặc sử dụng giữa các use-case. Xuất phát từ mô hình đơn
giản ban đầu, ta bổ sung dần các use-case bằng cách trả lời câu hỏi: đưa thêm
use-case này vào thì có ích hơn cho mô hình không? Tuy nhiên phải lưu ý
rằng không thể mô hình hóa tất cả bằng mô hình use-case. Trong nhiều trường
hợp, bên cạnh mô hình use-case đơn giản, nếu có thêm scenario hoặc một vài
loại biểu đồ nữa thì mô hình sẽ dễ hiểu hơn, như ví dụ về phần mềm điều
khiển hoạt động thang máy sau đây.
3.6. Mô tả use-case (use-case description)
Rõ ràng từ biểu đồ use-case ta mới có ý niệm rất sơ lược về chức
năng của mỗi use-case thông qua tên của nó. Vì vậy, đối với mỗi use-case
người ta thêm phần mô tả bên dưới. Mô tả use-case không có bất kỳ quy tắc
cú pháp nào cả, có thể mô tả bằng bất kỳ dạng nào. Tất nhiên nếu ta làm việc
76

trong một công ty nào đó thì phải tuân thủ những cách thức mà công ty đó
quy ước. Có hai cách thông dụng nhất được sử dụng để mô tả use-case là:
• Viết thành một đoạn văn.
• Liệt kê thành hai cột, một cột là hoạt động của tác nhân, cột còn lại là
đáp ứng của hệ thống.
Có thể thấy rằng cách thứ hai giống như một vở kịch có hai vai: tác nhân
và hệ thống, vì vậy người ta gọi cách trình bày này là kịch bản (scenario). Vì
cách trình bày theo cột có phần bất tiện, sự đáp ứng của hệ thống thường
chiếm phần nhiều hơn, làm cho hai cột không cân đối, do đó người ta thường
trình bày theo chiều dọc như khi trình bày một vở kịch thông thường (xem ví
dụ trong mục 3.7 sau đây).
3.7. Xây dựng mô hình use-case cho bài toán điều khiển hoạt động
thang máy
Giả sử cần xây dựng phần mềm điều khiển n thang máy trong ngôi nhà có
m tầng.
Các thang máy hoạt động theo cách thức như sau:
1. Mỗi thang máy có m nút bấm, mỗi nút tương ứng với một tầng. Các
nút được đánh số bằng số tầng tương ứng. Khi một nút được nhấn thì nó sẽ
sáng lên và thang máy sẽ được chuyển đến tầng tương ứng. Khi thang máy
đến được tầng cần thiết thì thì đèn nút bấm sẽ tắt. Ví dụ khi nút số 5 được
nhấn thì nó sáng lên, thang máy sẽ dịch chuyển đến tầng số 5 và khi đến được
tầng số 5 thì đèn ở nút số 5 cũng tắt.
2. Mỗi tầng, trừ tầng đầu tiên và tầng trên cùng, đều có 2 nút bấm: một
nút yêu cầu thang máy đi lên (up-elevator) và nút còn lại yêu cầu thang máy
đi xuống(down-elevator). Các nút này sẽ bật sáng mỗi khi được nhấn.
Bây giờ chúng ta sẽ xây dựng biểu đồ use-case cho vấn đề này theo các
bước như gợi ý ở trên. Trước hết ta trả lời câu hỏi: ai trực tiếp sử dụng thang
máy? Câu trả lời là: người muốn đi tới các tầng bằng thang máy, mà ta gọi
đơn giản là người sử dụng. Tiếp theo là trả lời câu hỏi: người sử dụng làm gì?
Câu trả lời là "người sử dụng nhấn nút". Ta có biểu đồ đơn giản đầu tiên

như sau:
77
Nhấn nút
hµng
Người sử dụng
Hình 4.11. Biểu đồ use-case đầu tiên cho bài toán thang máy.
Tuy nhiên ta thấy rằng thao tác nhấn nút chưa phải là thao tác có thể thực hiện
vì có hai loại nút: nút thang máy và nút tầng. Do đó ta dùng kết hợp
generalization để tách use-case này thành hai use-case như hình sau:
Hình 4.12. Biểu đồ use-case sau bước tinh chỉnh thứ hai.
Tuy nhiên cũng là trả lời câu hỏi "người sử dụng làm gì?", ta cũng có thể
trả lời là "người sử dụng nhấn nút thang máy hoặc nút tầng’’. Và từ đây ta có
biểu đồ use-case tương đương với biểu đồ trên nhưng hình thức biểu diễn có
khác:
Hình 4.13. Use-case cho vấn đề thang máy.
Mỗi use-case mô tả một chức năng của phần mềm cần xây dựng. Nó cung
cấp mô tả chung về chức năng; còn các scenario lại là các thể hiện cụ thể của
use-case, cũng giống như các đối tượng là các thể hiện của lớp vậy. Scenario
cho ta hiểu rõ hơn về use-case, vì nó chỉ rõ use-case xử lý các tình huống như
thế nào khi nhận được các chỉ thị từ các tác nhân. Các use-case cho ta bức
tranh toàn cảnh về các tác động qua lại giữa các lớp của phần mềm với nhau
và với những tác nhân sử dụng phần mềm. Các scenario chính là tập hợp các
tác động cụ thể giữa các đối tượng và những người sử dụng.
78
Người sử dụng
Nhấn nút
Nhấn nút thang máy
Nhấn nút tầng
Thang máy
Nhấn nút thang máy

Nhấn nút ở mỗi tầng
Người
sử dụng
Chỉ có các khả năng tương tác giữa người sử dụng và các lớp là người sử
dụng bấm vào nút trên thang máy để thang máy chuyển động hoặc bấm vào
nút ở tầng nhà để yêu cầu thang máy dừng lại khi đi đến tầng đó. Bằng việc
phối hợp các thao tác này ta có thể đưa ra rất nhiều scenario. Sau đây là một
scenario chuẩn và một scenario ngoại lệ (UML cung cấp hai loại biểu đồ là
tuần tự và tương tác để biểu diễn các scenario. Tuy nhiên các biểu đồ này
thích hợp hơn cho giai đoạn thiết kế).
Scenario chuẩn (normal scenario):
1. Người sử dụng A đang ở tầng 3 và muốn lên tầng 7. Anh ta nhấn vào
nút ↑ (up-elevator) để gọi thang máy đến.
2. Nút up-floor bật sáng.
3. Thang máy đến tầng 3 và mang theo người sử dụng B. B vào thang
máy ở tầng 1 và đã nhấn nút bên trong thang máy để lên tầng 9.
4. Nút ↑ tắt.
5. Cửa thang máy mở ra.
6. Bắt đầu thời gian chờ đợi (thang máy ở trạng thái đứng yên).
A bước vào thang máy.
7. A nhấn vào nút số 7 trong thang máy.
8. Nút số 7 trong thang máy sáng lên.
9. Cửa thang máy đóng lại.
10.Thang máy chuyển đến tầng 7.
11.Nút số 7 trong thang máy tắt.
12.Cửa thang máy mở ra (để A bước ra ngoài).
13.Bắt đầu thời gian chờ đợi.
A bước ra khỏi thang máy.
14.Cửa thang máy đóng lại sau một khoảng thời gian chờ.
15.Thang máy tiếp tục chuyển động lên tầng 9 mang theo B.

Sau đây là scenario ngoại lệ: A muốn xuống tầng 1 nhưng lại nhấn nhầm
vào nút ↑,
Scenario ngoại lệ (an exception scenario):
1. Người sử dụng A đang ở tầng 3 và muốn xuống tầng 1. Anh ta nhấn
nhầm vào nút ↑.
2. Nút ↑ bật sáng.
3. Thang máy đến tầng 3 và mang theo người sử dụng B. B vào thang
máy ở tầng 1 và đã nhấn nút bên trong thang máy để lên tầng 9.
79
4. Nút ↑ tắt.
5. Cửa thang máy mở ra.
6. Bắt đầu thời gian chờ đợi.
A bước vào thang máy.
7. A nhấn vào nút số 1 trong thang máy.
8. Nút số 1 trong thang máy sáng lên.
9. Cửa thang máy đóng lại.
10.Thang máy chuyển đến tầng 9.
11.Nút số 9 trong thang máy tắt.
12.Cửa thang máy mở ra (để B bước ra ngoài).
13.Bắt đầu thời gian chờ đợi.
B bước ra khỏi thang máy.
14.Cửa thang máy đóng lại sau một khoảng thời gian chờ.
15.Thang máy chuyển động xuống tầng 1 mang theo A.
Ngoài các scenario trên đây có thể đưa ra nhiều scenario nữa để giúp cho
nhóm phát triển hiểu rõ hơn cách hoạt động của hệ thống cần mô hình hóa.
Các thông tin này cần thiết cho bước tiếp theo: xây dựng các lớp và mô hình
lớp. Scenario sẽ còn được dùng trong bước thiết kế.
4. Mô hình lớp
4.1. Biểu đồ lớp
Biểu đồ lớp bao gồm các lớp cùng với các ký hiệu khác biểu diễn

mối quan hệ giữa chúng.
Biểu đồ lớp mô tả các kiểu đối tượng trong hệ thống và các mối quan hệ
tĩnh giữa chúng (Class diagrams describe the types of objects in the system
and the various kinds of static relationships that exist among them). Lớp là
khái niệm nền tảng trong phân tích và thiết kế HĐT. Đây là khái niệm khó,
các định nghĩa trong các tài liệu hiện có không hoàn toàn nhất quán và đôi khi
không chặt chẽ. Ví dụ, rất nhiều tài liệu đưa ra định nghĩa: lớp là tập hợp các
đối tượng có chung các thuộc tính và hành vi, ví dụ lớp khách hàng là tập hợp
các khách hàng (của cửa hàng đang khảo sát). Nếu nói như vậy thì không thể
nói rằng họ tên, giới tính, là thuộc tính của lớp; vì đây là thuộc tính của các
phần tử thuộc tập hợp. Định nghĩa UML về lớp theo nguyên văn tiếng Anh
là: "a description of a set of objects that share the same attributes, operations,
methods, relationships, and semantics". Như vậy nếu chỉ lưu ý đến những từ
quan trọng thì có thể đưa ra định nghĩa lớp như sau:
80
Lớp là khái niệm được dùng để mô tả các đối tượng có cùng loại thuộc
tính và hành vi. Như thế, phần lớn các tài liệu đã bỏ qua từ "mô tả", là một từ
mà theo chúng tôi là rất quan trọng. Lớp không phải là tập hợp các đối tượng,
mà là sự mô tả của nhóm các đối tượng có chung một số đặc trưng nào đó mà
thôi. Như vậy lớp khách hàng không phải là tập hợp các khách hàng, mà là sự
mô tả các khách hàng. Như thế các đặc trưng chung của các đối tượng sẽ
được mô tả trong lớp. Lớp đóng vai trò như một cái khung hay như một tờ
khai chưa có thông tin cụ thể. Ví dụ với các khách hàng của một cửa hàng nào
đó thì người ta cần lưu lại các thuộc tính như họ tên, giới tính, số điện thoại;
và ta biết rằng những hành động họ thường làm là tìm kiếm hàng, mua hàng
Với một khách hàng cụ thể thì các thuộc tính và hành vi được xác định, và
ta gọi khách hàng cụ thể là đối tượng thuộc lớp khách hàng. Người ta cũng
thường nói đối tượng là thể hiện của lớp. Như thế, theo chúng tôi có thể đưa
ra định nghĩa rõ hơn về lớp như sau:
Lớp là tập hợp các thuộc tính và phương thức có liên quan với nhau. Lớp

được đặt tên và thường được dùng để mô tả các đối tượng có cùng loại thuộc
tính và hành vi.
Định nghĩa này mở ra khả năng cho phép chúng ta xây dựng thêm các lớp
mới trong phần mềm để cho việc phân tích thiết kế được đơn giản hơn. Các
lớp mới này có thể chỉ đơn giản là một nhóm các dữ liệu, hàm có liên quan
với nhau trong phần mềm, không nhất thiết phải có một lớp các đối tượng
tương ứng trong thực tế.
Người ta cũng thường dùng cách nói trực quan: các lớp là những phần tử
hay các "vật" tạo nên phần mềm.
Trong biểu đồ UML lớp được biểu diễn bằng hình chữ nhật. Tên lớp
thường được viết đậm, các từ được viết liền nhau nhưng chữ đầu từ được viết
hoa, ví dụ BankAccount (không viết là Bank Account). Thể hiện của lớp, tức
là các đối tượng, được quy ước là viết có gạch chân, theo mẫu:
<tên đố i t ượ ng>:<tên l ớ p t ươ ng ứ ng> , :<tên l ớ p> hoặc <tên đố i t ượ ng> .
Ví dụ aDoc:Document, :Document, aDoc.
Các loại kết hợp: aggregation, composition và generalization
Ký hiệu aggregation (kết tập), ví dụ:
81
Hành khách
Chuyến bay
Hành khách
Chuyến bay
*
1
a) b)
Có nghĩa là hành khách là thành phần của chuyến bay, nhưng hành khách
cũng có thể tồn tại độc lập. Như vậy thể hiện của chuyến bay (tức là một
chuyến bay cụ thể nào đó), có chứa các thể hiện của hành khách (tức là các
hành khách cụ thể). Một chuyến bay chứa bao nhiêu hành khách thì tùy thuộc
vào multiplicity ở đầu cuối của kết hợp. Ví dụ ở hình b) có nghĩa là một

chuyến bay có thể không có hành khách nào hoặc có một hoặc nhiều hành
khách.
Ký hiệu composition (hợp thành), ví dụ:
a) b)
Có nghĩa là section là thành phần của document, nhưng section không tồn
tại độc lập. Như vậy thể hiện của document, có chứa các thể hiện của section.
Khi document bị xóa thì section cũng bị xóa.
Như vậy các kết hợp aggregation và composition đều là biểu diễn cấu trúc
whole-part giữa hai lớp. Sự khác biệt là: part trong aggregation có thể tồn tại
độc lập, còn trong composition thì part là thành phần cùng gắn kết với whole
(coincident lifetime).
Ký hiệu generalization (tổng quát hóa hay kế thừa), ví dụ:
có nghĩa là thư ký là trường hợp riêng của nhân viên, hay nhân viên là tổng
quát hóa của thư ký. Nếu nhân viên có thuộc tính gì thì thư ký cũng có các
thuộc tính đó. Tuy nhiên thư ký có thể có các thuộc tính mà nhân viên không
có.
Dạng tối thiểu của biểu diễn lớp là một hình chữ nhật trong đó có tên lớp.
Ví dụ về biểu đồ lớp:
82
Section
Document
Section
Document
*
1
Thư ký
Nhân viên
Hang
HangMua
HoaDon

0 20
1
TaiKhoan
No
Co
1
1
Hình 4.15. Các biểu đồ lớp
Giải thích các ký hiệu:
Lớp HangMua được dẫn xuất từ lớp Hang, hay lớp HangMua là lớp thừa
kế của lớp Hang. Quan hệ này là quan hệ tổng quát hóa (generalization). Ta
cũng gọi lớp Hang là lớp cha, lớp HangMua là lớp con.
No (No là phần nợ, Co là phần có của tài khoản) là thành phần của
TaiKhoan, tuy nhiên nó phụ thuộc vào TaiKhoan. Nếu phía TaiKhoan bị xóa
thì phía No cũng bị xoá theo (Co cũng vậy). Quan hệ này là composition, có
thể coi là trường hợp riêng của aggregation. Khi biễu diễn lớp, ngoài thành
phần bắt buộc là tên lớp, còn có thể có các thuộc tính và các phương thức, ví
dụ:
Hang
TenHang
GiaHang
Nhap()
Xem()
4.2. Xây dựng mô hình lớp (class modeling) như thế nào?
Mô hình lớp đóng vai trò trụ cột trong phân tích và thiết kế hướng
đối tượng. Thành phần của mô hình lớp là các biểu đồ lớp, trong đó biểu diễn
các lớp cùng các mối quan hệ giữa chúng. Mô hình đối tượng chính là thể
hiện của mô hình lớp, trong đó bao gồm các biểu đồ đối tượng là thể hiện của
các biểu đồ lớp. Các biểu đồ lớp được phân làm hai loại. Trong bước phân
tích được gọi là biểu đồ lớp khái niệm (conceptual class diagram).Trong bước

này các lớp cùng các thuộc tính sẽ được đưa ra và biểu diễn theo biểu đồ thực
thể-quan hệ (entity-relationship diagram). Hiện tại chỉ xác định các thuộc tính
của các lớp. Các phương thức (các hàm thành phần) của các lớp sẽ được đưa
vào trong giai đoạn thiết kế (cũng có tài liệu cho rằng cần nêu cả phương
thức, nhưng chỉ cần theo ngôn ngữ của người sử dụng). Biểu đồ lớp trong giai
đoạn thiết kế được gọi là biểu đồ lớp thiết kế (design class diagram).
Một trong những phương pháp xác định các lớp là dẫn xuất chúng từ các
use-case. Điều này có nghĩa là các nhà phát triển cần xem xét kỹ các kịch bản,
cả trường hợp chuẩn và ngoại lệ, từ đó rút ra những thành phần tham gia trong
các use-case. Ví dụ trong bài toán thang máy thì từ các scenario trên đây ta có
83
thể rút ra các lớp ứng cử viên là: các nút thang máy, các nút ở mỗi tầng, các
thang máy, các cửa, và các dụng cụ đo thời gian (timers). Như chúng ta sẽ
thấy, các lớp ứng cử viên này khá gần với các lớp thực được đưa ra trong quá
trình xây dựng mô hình lớp. Tuy nhiên trong thực tế có rất nhiều scenario và
do đó số lớp ứng cử viên có thể rất lớn. Đối với những người phát triển ít kinh
nghiệm thì việc lựa chọn ra các lớp thích hợp nhất là điều khá khó khăn.
Thường thì việc thêm một lớp dễ hơn là loại bỏ một lớp từ tập đã có.
Một cách tiếp cận khác trong việc lựa chọn các lớp khá hiệu quả là sử
dụng các thẻ CRC (class-responsibility-collaboration). Tuy nhiên đối với
những kỹ sư phần mềm chưa quen lĩnh vực này thì nên dùng kỹ thuật trích
danh từ (noun extraction) sẽ được giới thiệu sau đây.
4.3. Kỹ thuật trích danh từ (noun extraction)
Kỹ thuật trích danh từ được thực hiện trong ba bước sau đây:
Bước 1. Phát biểu bài toán một cách gọn và cô đọng (concise problem
definition). Mô tả vấn đề càng ngắn càng tốt, và nên gói gọn trong một câu.
Ví dụ với bài toán thang máy có thể mô tả như sau:
Các nút trong thang máy và trên mỗi tầng điều khiển hoạt động của n thang
máy trong ngôi nhà có m tầng.
Bước 2. Diễn tả hoạt động của hệ thống (hay còn gọi là chiến lược phi

hình thức, informal strategy). Mô tả hoạt động của hệ thống một cách ngắn
gọn, tốt nhất là trong một đoạn văn (paragraph). Đoạn này thường bao gồm
phần phát biểu ngắn gọn bài toán rồi bổ sung thêm các điều kiện ràng buộc.
Ví dụ với vấn đề thang máy có thể diễn tả như sau:
Các nút trong thang máy và trên mỗi tầng điều khiển hoạt động của n
thang máy trong ngôi nhà có m tầng. Các nút bật sáng mỗi khi được nhấn để
yêu cầu thang máy dừng lại ở một tầng nào đó. Sự bật sáng kết thúc khi yêu
cầu được thực hiện xong. Khi không có yêu cầu thì thang máy dừng ở tầng và
cửa của nó đóng.
Bước 3. Đánh dấu các danh từ. Bây giờ ta đánh dấu các danh từ mô tả các
vật tồn tại trong thực tế.
Các nút trong thang máy và trên mỗi tầng điều khiển hoạt động của n
thang máy trong ngôi nhà có m tầng. Các nút bật sáng mỗi khi được nhấn để
yêu cầu thang máy dừng lại ở một tầng nào đó. Sự bật sáng kết thúc khi yêu
84
cầu được thực hiện xong. Khi không có yêu cầu thì thang máy dừng ở tầng và
cửa của nó đóng.
Như vậy có các danh từ nút, thang máy, tầng, ngôi nhà và cửa. Tuy nhiên,
trong các danh từ này thì có một số nằm ngoài phạm vi quan tâm của bài toán,
ví dụ: tầng, ngôi nhà, cửa. Vậy chỉ còn lại hai danh từ là thang máy và nút.
Vậy ta sẽ có hai lớp là thang máy và nút. Theo cách đặt tên do UML quy
định thì tên lớp được viết hoa chữ đầu, không chứa dấu cách. Tuy nhiên,
chúng ta sẽ thực hiện điều này khi đặt tên lớp trong lập trình, còn bây giờ ta
sẽ viết bằng tiếng Việt có dấu cho dễ hiểu. Trong thực tế nút được phân làm
hai loại: nút thang máy và nút tầng nhà. Hai loại nút này tương ứng với các
lớp con dẫn xuất từ lớp nút. Vì thang máy hoạt động theo các thông tin gửi từ
các nút nên ta có biểu đồ lớp đầu tiên như sau:
Hình 4.16. Biểu đồ lớp đầu tiên
Trong thực tế thì các nút không gửi thông tin trực tiếp đến các thang máy,
mà gửi đến một bộ điều khiển thang máy. Bộ phận này sẽ xử lý và quyết định

thang máy nào sẽ đáp ứng yêu cầu. Do đó ta có sơ đồ lớp trong bước tinh
chỉnh thứ hai như sau:
85
Nút
Nút thang máy Nút tầng
Thang máy
Trao đổi thông tin với
2m-2
m
1
n
Trao đổi thông tin với
1
1
Nút
Nút thang máy Nút tầng
ĐK thang máy
Trao đổi thông tin với
2m-2
m
Trao đổi thông tin với
Thang máy
Điều khiển
n
1
Hình 4.17. Biểu đồ lớp ở bước tinh chỉnh thứ hai
Bây giờ ta xem xét các thuộc tính có thể của mỗi lớp. Dựa vào scenario ta
có thể thấy rằng thuộc tính có thể thấy ngay của lớp nút là chiếu sáng hay
không, thuộc tính của thang máy là cửa thang máy mở hay đóng. Các thuộc
tính này chỉ nhận hai giá trị có hoặc không, vậy chúng có kiểu logic, hay còn

được gọi là kiểu boolean. Các lớp khác hiện tại chưa thấy thuộc tính nào được
bộc lộ rõ ràng. Ta có bảng sau đây, với tên lớp được đặt lại để sau này tiện
cho việc lập trình:
Button
(nút)
ElevatorButton
(Nút thang máy)
FloorButton
(Nút tầng)
illuminated:Boolean
ElevatorController
(Điều khiển thang máy)
Elevator
(Thang máy)
DoorOpened:Boolean
Trên đây chỉ là mô hình lớp trong vài bước đầu tiên. Mô hình này sẽ còn
được sửa đổi cho phù hợp trong các pha sau này. Sự sửa đổi có thể thực hiện
cho đến pha tích hợp.
Ghi chú: trong thực tế, việc áp dụng kỹ thuật trích danh từ đôi khi không
dễ dàng. Bằng cách này ta đưa ra được một danh sách các danh từ là ứng cử
viên cho lớp, nhưng việc lọc ra các danh từ thực sự cần thiết thì lại là vấn đề
khó. Lấy ví dụ, cần viết chương trình quản lý bán hàng chẳng hạn. Ta thấy
ngay là có thể rút ra các danh từ cần xây dựng lớp là khách hàng, nhân viên
bán hàng, hóa đơn Có thể có nhiều danh từ khác, nhưng đây là ba danh từ
không thể loại bỏ. Chính vì thế, trong hầu hết các chương trình mẫu về bán
hàng đều có lớp khách hàng. Tuy nhiên, nếu ở một siêu thị lớn, khách hàng
rất nhiều và thường xuyên thay đổi thì việc quản lý khách hàng trở nên không
cần thiết. Mặc dầu khi khách hàng mua hàng ta vẫn cần lưu thông tin về họ
như họ tên, địa chỉ, số điện thoại để khi có sự cố có thể liên hệ giải quyết,
nhưng rõ ràng thông tin về mỗi khách hàng chỉ có ý nghĩa khi gắn với hóa

đơn. Trong trường hợp này, ta chỉ nên xem thông tin về khách hàng là các
thuộc tính của hóa đơn mà thôi. Vấn đề sẽ khác đi ở một cơ sở bán buôn. Rõ
86