Bài giảng Phân tích và thiết kế hướng đối tượng - Bài 4: Phân tích hệ thống-Mô hình khái niệm và biểu đồ lớp

PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 
OBJECT ORIENTED ANALYSIS AND DESIGN 
DR. DAO NAM ANH 
 Bài giảng 4: 
PHÂN TÍCH HỆ THỐNG – 
MÔ HÌNH KHÁI NIỆM VÀ BIỂU ĐỒ LỚP 
1 
RESOURCE - REFERENCE 
1. Ian Sommerville, Software Engineering, Ninth Edition, 2011 
2. Bernd Bruegge & Allen H. Dutoit. Object-Oriented 
Software Engineering: Using UML, Patterns, and Java, 
Third Edition, Prentice Hall, 2010 
3. Russell C. Bjork, ATM Simulation Links, Gordon College 
4. Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David 
Fado, UML 2 Toolkit, John Wiley & Sons Inc, 2003 
5. Dương Kiều Hoa – Tôn Thất Hoà An, Phân tích và thiết kế 
Hệ thống thông tin với UML, 2006 
6. Đào Nam Anh, Giáo Trình Phân Tích Và Thiết Kế Hướng 
Đối Tượng, Đại học Điện lực, 2013 
2 
CONTENT – NỘI DUNG 
Phân tích hệ thống – Mô hình khái niệm và biểu 
đồ lớp 
4.1 Mô hình khái niệm – mô hình đối tượng 
4.2 Xác định các lớp, đối tượng 
4.3 Mối quan hệ giữa các lớp đối tượng 
4.4 Nâng cấp mô hình 
3 
1. Mô hình khái niệm – mô hình đối tượng 
1.1 Đối tượng và lớp 
 Trong mô hình hóa hướng đối tượng, những phần tử cấu 
thành căn bản nhất của mô hình là lớp, đối tượng và 
mối quan hệ giữa chúng với nhau. 
 Lớp và đối tượng sẽ mô hình hóa những gì có trong hệ 
thống mà chúng ta muốn miêu tả, các mối quan hệ sẽ 
biểu thị cấu trúc. 
 Khi sử dụng lập trình hướng đối tượng để xây dựng các 
hệ thống phần mềm thì lớp và các mối quan hệ của 
chúng là các thông tin cơ bản để xây dựng sản phẩm 
phần mềm. 
4 
1. Mô hình khái niệm – mô hình đối tượng 
1.2 Trạng thái, ứng xử và nhận diện của đối tượng 
 Cho đến nay, lớp là không có gì mới. Darwin là người đã 
sử dụng các lớp để mô tả các nhóm sinh vật. Ông nhóm 
các loài vào các lớp để mô tả lý thuyết tiến hóa. 
 Thiết kế hướng đối tượng phân loại thông tin một cách 
tương tự. Song UML cung cấp một điều mới: một sự 
phân biệt rõ ràng giữa lớp và đối tượng. 
5 
1. Mô hình khái niệm – mô hình đối tượng 
1.2 Trạng thái, ứng xử và nhận diện của đối tượng 
 Đối tượng (object) tồn tại trong thế giới thực. Nó có thể 
là một phần của bất kỳ loại hệ thống, ví dụ, một máy 
tính, một tổ chức, hoặc một nghiệp vụ. 
 Một số đối tượng có xu hướng lý thuyết (chẳng hạn như 
các đối tượng thực hiện trong một hệ thống phần mềm): 
 Ta có thể lấy chúng bằng cách phân tích cấu trúc và hành 
vi của các đối tượng trong thế giới thực. Các đối tượng, 
trong cách này hay cách khác, đại diện cho sự hiểu biết 
của bạn về thế giới thực. 
6 
1. Mô hình khái niệm – mô hình đối tượng 
1.2 Trạng thái, ứng xử và nhận diện của đối tượng 
7 
1. Mô hình khái niệm – mô hình đối tượng 
1.2 Trạng thái, ứng xử và nhận diện của đối tượng 
 Trạng thái (state) của một đối tượng thường sẽ thay đổi 
theo thời gian, và được định nghĩa qua một tổ hợp các 
thuộc tính. 
 Ví dụ một danh sách ghi danh cho một lớp trong hệ 
thống trường học có thể có hai trạng thái: trạng thái đóng 
và trạng thái mở. 
 Nếu danh sách sinh viên ghi danh cho lớp này còn nhỏ 
hơn số tối đa cho phép (ví dụ là 10), thì trạng thái của 
bảng ghi danh này là mở. 
 Một khi đã đủ 10 sinh viên ghi danh cho lớp, danh sách 
sẽ chuyển sang trạng thái đóng 
8 
1. Mô hình khái niệm – mô hình đối tượng 
1.2 Trạng thái, ứng xử và nhận diện của đối tượng 
 Ứng xử (Behaviour) xác định một đối tượng sẽ phản ứng 
như thế nào trước những yêu cầu từ các đối tượng khác, 
nó tiêu biểu cho những gì mà đối tượng này có thể làm. 
 Ứng xử được thực thi qua loạt các Phương thức 
(operation) của đối tượng. 
 Trong ví dụ trường đại học, một đối tượng bảng ghi danh 
lớp có thể có ứng xử là bổ sung thêm một sinh viên hay 
xóa đi tên của một sinh viên khi sinh viên đăng ký học 
hay bãi bỏ đăng ký. 
9 
1. Mô hình khái niệm – mô hình đối tượng 
1.2 Trạng thái, ứng xử và nhận diện của đối tượng 
 Sự nhận diện (Identity) đảm bảo rằng mỗi đối tượng là 
duy nhất – dù trạng thái của nó có thể giống với trạng 
thái của các đối tượng khác. 
 Ví dụ, khóa học đại số 101 chương 1 và khóa học đại số 
101 chương 2 là hai đối tượng trong hệ thống ghi danh 
trường học. 
 Mặc dù cả hai đều thuộc loại bảng ghi danh, mỗi khóa 
học vẫn có sự nhận dạng duy nhất của mình. 
10 
1. Mô hình khái niệm – mô hình đối tượng 
1.3 Biểu đồ lớp 
 Một biểu đồ lớp (class diagram) là một dạng mô hình 
tĩnh. 
 Một biểu đồ lớp miêu tả hướng nhìn tĩnh của một hệ 
thống bằng các khái niệm lớp và mối quan hệ giữa 
chúng với nhau. 
 Mặc dù có những nét tương tự với một mô hình dữ liệu, 
nhưng các lớp không chỉ thể hiện cấu trúc thông tin mà 
còn miêu tả cả hành vi. 
 Một trong các mục đích của biểu đồ lớp là tạo nền tảng 
cho các biểu đồ khác, thể hiện các khía cạnh khác của hệ 
thống. 
11 
1. Mô hình khái niệm – mô hình đối tượng 
1.3 Biểu đồ lớp 
 Một lớp trong một biểu đồ lớp có thể được thực thi trực 
tiếp trong một ngôn ngữ hướng đối tượng có hỗ trợ trực 
tiếp khái niệm lớp. 
 Một biểu đồ lớp chỉ chỉ ra các lớp, nhưng bên cạnh đó 
còn có một biến tấu hơi khác đi một chút chỉ ra các đối 
tượng thật sự là các thực thể của các lớp này (biểu đồ đối 
tượng). 
12 
1. Mô hình khái niệm – mô hình đối tượng 
1.3 Biểu đồ lớp 
13 
 Để tạo một biểu đồ lớp, đầu tiên ta 
phải nhận diện và miêu tả các lớp. 
Một lớp được biểu diễn bằng hình 
chữ nhật. Ô trên cùng là tên lớp. Ô 
tiếp theo là các thuộc tính, ô cuối 
cùng chỉ các hành vi. Một khi đã 
có một số lượng các lớp, ta sẽ xét 
đến quan hệ giữa các lớp đó với 
nhau. 
2. Xác định các lớp, đối tượng 
 Cần phải sử dụng kiến thức của các chuyên gia trong 
lĩnh vực chuyên môn, với sự hiểu biết của người sử dụng 
và hệ thống để nắm bắt được hệ thống. 
 Các lớp phản ánh được vấn đề và có tên gọi, không gây 
nhầm lẫn. 
 Mô hình Use Case tốt sẽ giúp rất nhiều trong tìm kiếm 
lớp. 
 Dựa trên mô hình Use Case và đặc tả yêu cầu trong việc 
tìm kiếm cho các lớp. 
14 
2. Xác định các lớp, đối tượng 
Thông tin nào cần được lưu trữ hoặc phân tích? Nếu có bất 
kỳ thông tin cần được lưu trữ, chuyển đổi, phân tích, hoặc 
xử lý, thì nó là một ứng viên có thể cho một lớp. Các thông 
tin có thể bao gồm những khái niệm cần phải được đăng 
ký trong hệ thống, các sự kiện hoặc giao dịch xảy ra tại 
một thời điểm cụ thể. 
 Có tồn tại hệ thống bên ngoài? Hệ thống bên ngoài có 
thể được xem như lớp mà hệ thống của bạn có tương tác. 
 Có mô hình tái sử dụng, các thư viện lớp, hoặc các thành 
phần nào không? Nếu có các mô hình, thư viện lớp, hoặc 
các thành phần từ các dự án trước đó, từ đồng nghiệp 
hoặc nhà sản xuất, thì có các ứng viên lớp. 
15 
2. Xác định các lớp, đối tượng 
 Hệ thống phải xử lý các thiết bị nào mà? Bất kỳ thiết bị 
kỹ thuật kết nối với hệ thống có thể là ứng viên lớp. 
 Có các bộ phận tổ chức nào? Đại diện cho một tổ chức 
có thể được thực hiện với các lớp, đặc biệt là trong các 
mô hình nghiệp vụ. 
 Những vai trò của tác nhân trong nghiệp vụ? Những vai 
trò này có thể được xem như các lớp, chẳng hạn như 
người sử dụng, hệ thống điều hành, khách hàng. 
Tìm các lớp cũng có dẫn đến việc sửa đổi, cải thiện các mô 
hình Use Case hoặc đặc tả yêu cầu. 
16 
2. Xác định các lớp, đối tượng 
2.1 Tên lớp 
 Ngăn trên cùng của hình chữ 
nhật lớp chứa tên của lớp. 
 Tên gọi nên càng rõ ràng 
càng tốt, phải là một danh từ 
ví dụ “hóa đơn”. Tên lớp 
không nên có một tiền tố 
hoặc hậu tố. 
17 
2. Xác định các lớp, đối tượng 
2.2 Thuộc tính của lớp 
 Lớp có các thuộc tính mô tả các 
đặc tính của các đối tượng. 
 Lớp Printer với các thuộc tính 
serialNumber, memory, status. 
Các thuộc tính chính xác bản 
nhất đế mô tả lớp. 
 Tuy nhiên, chỉ có các thuộc tính 
có ích trong hệ thống mới được 
chọn. Mục đích của hệ thống ảnh 
hưởng đến việc lựa chọn các 
thuộc tính 
18 
2. Xác định các lớp, đối tượng 
2.2 Thuộc tính của lớp 
 Thuộc tính có các giá trị trong 
các đối tượng của lớp. 
 Thuộc tính có kiểu cho biết loại 
của thuộc tính, như thể hiện trong 
hình bên. 
 Loại thuộc tính điển hình là số 
nguyên, boolean, chuỗi, ngày, số 
thực được gọi là các kiểu dữ liệu. 
 Với mỗi ngôn ngữ lập tình, thuộc 
tính được có các kiểu dữ liệu cụ 
thể của ngôn ngữ lựa chọn. 
19 
2. Xác định các lớp, đối tượng 
2.2 Thuộc tính của lớp 
 Các thuộc tính có thể có khả 
năng hiển thị khác nhau. Khả 
năng hiển thị mô tả liệu thuộc 
tính có thể được tham khảo từ 
các lớp như thế nào. 
20 
2. Xác định các lớp, đối tượng 
2.2 Thuộc tính của lớp 
 Nếu một thuộc tính là public, nó 
có thể được sử dụng và xem bên 
ngoài lớp đó. 
 Nếu một thuộc tính có khả năng 
hiển thị private, bạn không thể 
truy cập nó từ các lớp khác, ký 
hiệu bằng ổ khóa. 
 Nếu một thuộc tính được 
protected, nó là private, nhưng 
hiển thị cho bất kỳ lớp con của 
lớp này, ký hiệu bằng chìa khóa 
21 
2. Xác định các lớp, đối tượng 
2.3 Phương thức của lớp 
 Phương thức định nghĩa các hoạt động mà lớp có thể 
thực hiện. Tất cả các đối tượng được tạo từ một lớp sẽ có 
chung thuộc tính và phương thức. Phương thức được sử 
dụng để xử lý thay đổi các thuộc tính cũng như thực hiện 
các công việc khác. 
 Phương thức thường được gọi là các hàm (function), 
nhưng chúng nằm trong một lớp và chỉ có thể được áp 
dụng cho các đối tượng của lớp này. 
22 
2. Xác định các lớp, đối tượng 
2.3 Phương thức của lớp 
 Vì nhóm các phương thức 
miêu tả những dịch vụ mà 
lớp có thể cung cấp nên 
chúng được coi là giao 
diện của lớp này. 
 Giống như thuộc tính, 
phương thức cũng có tính 
trông thấy được như 
public, private và 
protected. 
23 
2. Xác định các lớp, đối tượng 
2.4 Ký hiệu đối tượng 
 Đối tượng là thực thể của các lớp nên ký hiệu dùng cho 
đối tượng cũng là ký hiệu dùng cho lớp. 
 Các thuộc tính được gán giá trị, đây là các giá trị khi lớp 
được thực thể hóa. Chú ý rằng ký hiệu đối tượng không 
chứa phần phương thức. 
 Ví dụ dưới đây có lớp House và 3 đối tượng của lớp này 
với các giá trị cụ thể. 
24 
2. Xác định các lớp, đối tượng 
2.5 Tìm các lớp và đối tượng 
 Nắm vững khái niệm lớp, chúng ta có thể tương đối dễ 
dàng tìm thấy các lớp và đối tượng trong phạm vi vấn 
đề. 
 Một nguyên tắc thô sơ thường được áp dụng là danh từ 
trong các lời phát biểu bài toán thường là các ứng viên 
để chuyển thành lớp và đối tượng. 
25 
2. Xác định các lớp, đối tượng 
2.5 Tìm các lớp và đối tượng 
Một số gợi ý thực tế cho việc tìm lớp trong phạm vi vấn 
đề: 
 Bước đầu tiên là cần phải tập trung nghiên cứu kỹ: 
◦ Các danh từ trong những lời phát biểu bài toán 
◦ Kiến thức chuyên ngành thuộc phạm vi bài toán 
◦ Các Use Case 
 Ví dụ trong lời phát biểu "Có một số account có tiền 
lãi", ta thấy có hai danh từ là account và tiền lãi. Chúng 
có thể là các lớp tiềm năng cho mô hình ngân hàng. 
26 
2. Xác định các lớp, đối tượng 
2.5 Tìm các lớp và đối tượng 
 Thứ hai, chú ý đến các nhóm vật thể trong hệ thống hiện 
thời như: 
◦ Các thực thể vật lý của hệ thống: những vật thể tương 
tác với hệ thống, ví dụ khách hàng. 
◦ Các vật thể hữu hình: các vật thể vật lý mà ta có thể 
nhìn và sờ thấy. Ví dụ như công cụ giao thông, sách 
vở, một con người, một ngôi nhà,. Trong một ngân 
hàng, đó có thể là tập sec, phiếu đề nghị rút tiền, sổ 
tiết kiệm, các loại form cần thiết. 
27 
2. Xác định các lớp, đối tượng 
2.5 Tìm các lớp và đối tượng 
 Các sự kiện (event): Một chiếc xe bị hỏng, một cái cửa 
được mở ra. Trong một ngân hàng là sự đáo hạn một 
account đầu tư, hiện tượng rút quá nhiều tiền mặt trong 
một account bình thường. 
 Các vai trò (role): Ví dụ như khách hàng, người bán 
hàng. Trong một ngân hàng, vai trò có thể là nhân 
viên, nhà quản trị, khách hàng. 
 Các sự tương tác (interactions): Ví dụ việc bán hàng là 
một chuỗi tương tác bao gồm khách hàng, người bán 
hàng và sản phẩm. Trong một ngân hàng, việc mở một 
account mới sẽ yêu cầu một chuỗi tương tác giữa nhân 
viên và khách hàng. 
28 
2. Xác định các lớp, đối tượng 
2.5 Tìm các lớp và đối tượng 
 Vị trí (location): Một đồ vật nào đó hoặc một người nào 
đó được gán cho một vị trí nào đó. Ví dụ: Ôtô đối với 
nhà để xe. Trong một ngân hàng ta có thể thấy nhân viên 
thu ngân luôn đứng ở cửa sổ thu ngân. 
 Đơn vị tổ chức (organisation unit): Ví dụ các phòng ban, 
phòng trưng bày sản phẩm, các bộ phận. Trong một ngân 
hàng có thể có bộ phận account bình thường, bộ phận 
account tiết kiệm, bộ phận account đầu tư. 
29 
2. Xác định các lớp, đối tượng 
2.5 Tìm các lớp và đối tượng 
Bên cạnh đó, có nhiều câu hỏi khác để tìm ra lớp: 
 Có thông tin cần được lưu trữ hoặc cần được phân tích 
không? Nếu có thông tin cần phải được lưu trữ, biến đổi, 
phân tích hoặc xử lý trong một phương thức nào đó thì 
chắc chắn đó sẽ là ứng viên cho lớp. Những thông tin 
này có thể là một khái niệm luôn cần phải được ghi 
trong hệ thống hoặc là sự kiện, giao dịch xảy ra tại một 
thời điểm cụ thể nào đó. 
 Có các hệ thống ngoại vi không? Nếu có, thường chúng 
cũng đáng được quan tâm tới khi tạo dựng mô hình. Các 
hệ thống bên ngoài có thể được coi là các lớp chứa hệ 
thống của chúng ta hoặc tương tác với hệ thống của 
chúng ta. 
 30 
2. Xác định các lớp, đối tượng 
2.5 Tìm các lớp và đối tượng 
Nguồn thông tin cho việc tìm lớp 
Như vậy nguồn thông tin chính cần đặc biệt chú ý khi tìm 
lớp là: 
 Các lời phát biểu yêu cầu 
 Các Use Case 
 Sự trợ giúp của các chuyên gia ứng dụng 
 Nghiên cứu hệ thống hiện thời 
31 
2. Xác định các lớp, đối tượng 
2.5 Tìm các lớp và đối tượng 
 Ngoài ra, nghiên cứu những hệ thống tương tự cũng có 
thể sẽ mang lại cho ta các lớp ứng viên khác. 
 Loạt các lớp đầu tiên được tìm thấy thường được gọi là 
các lớp ứng viên (candidate class). Khi nghiên cứu hệ 
thống hiện thời, hãy để ý đến các danh từ và các khái 
niệm then chốt để nhận ra lớp ứng viên. 
 Không nên đưa các lớp đã được nhận diện một lần nữa 
vào mô hình chỉ bởi vì chúng được nhắc lại ở đâu đó 
theo một tên gọi khác. Ví dụ, một hệ thống ngân hàng có 
thể coi cùng một khách hàng với nhiều vị trí khác nhau 
là nhiều khách hàng khác nhau. Cần chú ý khi phân tích 
những lời miêu tả như thế để tránh dẫn đến sự trùng lặp 
trong quá trình nhận diện lớp. 
32 
2. Xác định các lớp, đối tượng 
2.5 Tìm các lớp và đối tượng 
 Có nhiều nguồn thông tin mà thiết kế viên cần phải chú 
ý tới khi thiết kế lớp và chỉ khi làm như vậy, ta mới có 
thể tin chắc về khả năng tạo dựng một mô hình tốt. 
 Các Use Case là nguồn tốt nhất cho việc nhận diện lớp 
và đối tượng. Cần nghiên cứu kỹ các Use Case để tìm 
các thuộc tính (attribute) báo trước sự tồn tại của đối 
tượng hoặc lớp tiềm năng. Ví dụ nếu Use Case yêu cầu 
phải đưa vào một số account (account-number) thì điều 
này trỏ tới sự tồn tại của một đối tượng account. 
33 
2. Xác định các lớp, đối tượng 
2.5 Tìm các lớp và đối tượng 
 Một nguồn khác để nhận ra lớp/đối tượng là các Input và 
Output của hệ thống. Nếu Input bao gồm tên khách hàng 
thì đây là tín hiệu cho biết sự tồn tại của một đối tượng 
khách hàng, bởi nó là một attribute của khách hàng. 
 ...  xác hơn, nó không được phép có bất kỳ trường 
hợp (instance) đối tượng. 
 Một lớp trừu tượng mô tả các thuộc tính và hành vi chung cho các 
lớp khác. Trong hệ thống phân cấp lớp trong hình dưới đây, rất khó 
để tưởng tượng các đối tượng của phương tiện – vehicle, khác với. 
các lớp con là car- xe hơi hay boat - chiếc thuyền. 
 Tuy nhiên, lớp Vehicle nắm bắt sự tương đồng giữa xe và thuyền. 
Vehicle đại diện cho một lớp trừu tượng, mà không có bất kỳ đối 
tượng, nhưng cho thấy đặc điểm chung của các lớp con. Một lớp có 
thể được xác định là trừu tượng bằng cách đặt từ khóa {abstract} 
trong khoang tên của lớp 
80 
3. Mối quan hệ giữa các lớp đối tượng 
3.2 Quan hệ khái quát hóa và chuyên biệt hóa 
81 
Loại cấu trúc lớp như vậy được gọi là một cấu trúc hình cây hoặc cấu 
trúc phân cấp. Khi chúng ta dịch chuyển từ điểm xuất phát của cây 
xuống dưới, chúng ta sẽ gặp các khái niệm càng ngày càng được 
chuyên biệt hóa. Theo con đường đi từ dưới lên các lớp được khái 
quát dần. 
3. Mối quan hệ giữa các lớp đối tượng 
3.2 Quan hệ khái quát hóa và chuyên biệt hóa 
82 
 Tạo lớp trừu tượng 
Lớp Vehicle đứng đầu cây cấu trúc và 
được gọi là lớp căn bản. Lớp căn bản 
của một cây cấu trúc chứa những 
thuộc tính đã được khái quát hóa và có 
thể được áp dụng cho mọi lớp dẫn 
xuất từ nó. 
Trong quá trình khái quát hóa, các 
thuộc tính được dùng chung trong các 
lớp chuyên biệt được đưa lên lớp cha. 
Lớp cha về cuối được tạo bởi các 
thuộc tính chung của tất cả các lớp dẫn 
xuất từ nó. 
3. Mối quan hệ giữa các lớp đối tượng 
3.2 Quan hệ khái quát hóa và chuyên biệt hóa 
83 
 Tạo lớp trừu tượng 
Các lớp Car và Boat là hai lớp chuyên 
biệt dẫn xuất từ lớp Vehicle. 
Chúng có những thuộc tính chuyên 
biệt riêng của chúng bên cạnh phương 
thức chung drive() mà chúng thừa kế. 
3. Mối quan hệ giữa các lớp đối tượng 
3.2 Quan hệ khái quát hóa và chuyên biệt hóa 
84 
 Lớp cụ thể 
 Lớp cụ thể (concrete class) là những 
lớp có thể thực thể hóa. Như đã nói 
từ trước, các lớp cụ thể khi thực thể 
hóa được gọi là các đối tượng. 
 Trong ví dụ trên, các lớp Car và 
Boat có thể được thực thể hóa thành 
đối tượng. Tương tự đối với account 
tiết kiệm và account bình thường. 
3. Mối quan hệ giữa các lớp đối tượng 
3.2 Quan hệ khái quát hóa và chuyên biệt hóa 
Tổng kết về phát triển cây cấu trúc 
Cơ chế khái quát hóa dùng chung thuộc tính và thủ tục 
được gọi là tính thừa kế (inheritance). Sử dụng tính thừa kế 
sẽ dẫn tới việc phát triển một cây cấu trúc. Nên phát hiện 
những ứng xử (behaviour) chung trong một loạt lớp rồi thể 
hiện nó thành một lớp cha. Sự khác biệt trong ứng xử của 
cùng một lớp sẽ dẫn tới việc tạo ra các lớp con. 
85 
3. Mối quan hệ giữa các lớp đối tượng 
3.2 Quan hệ khái quát hóa và chuyên biệt hóa 
Tổng kết về phát triển cây cấu trúc 
 Khi phát triển cây cấu trúc, hãy quan sát ứng xử của các 
lớp. Trong trường hợp có một thuộc tính hay phương 
thức tồn tại từ một lớp cụ thể đến tất cả các lớp con của 
một lớp cha, nên chuyển thuộc tính hay phương thức 
này lên lớp cha. 
 Nếu tồn tại một thuộc tính hay phương thức trong một 
lớp nào đó và một lớp cha, hãy chuyên biệt hóa và nâng 
cao cấu trúc để xác định xem liệu thuộc tính hay phương 
thức này có được áp dụng cho tất cả các lớp con của lớp 
cha đó hay không. Nếu có thì gán nó vào lớp cha, nếu 
không thì dịch xuống cho những lớp con phù hợp. 
86 
3. Mối quan hệ giữa các lớp đối tượng 
3.2 Quan hệ khái quát hóa và chuyên biệt hóa 
Tổng kết về phát triển cây cấu trúc 
87 
3. Mối quan hệ giữa các lớp đối tượng 
3.3 Quan hệ phụ thuộc và nâng cấp 
 Quan hệ phụ thuộc (dependency) là một sự liên quan 
ngữ nghĩa giữa hai phần tử mô hình, một mang tính độc 
lập và một mang tính phụ thuộc 
 Mọi sự thay đổi trong phần tử độc lập sẽ ảnh hưởng đến 
phần tử phụ thuộc. 
 Phần tử mô hình ở đây có thể là một lớp, một gói 
(package), một Use Case, .v.v... 
 Có thể nêu một vài ví dụ cho sự phụ thuộc như: một lớp 
lấy tham số là đối tượng của một lớp khác, một lớp truy 
nhập một đối tượng toàn cục của một lớp khác, một lớp 
gọi một thủ tục thuộc thuộc một lớp khác. Trong tất cả 
các trường hợp trên đều có một sự phụ thuộc của một 
lớp này vào một lớp kia, mặc dù chúng không có liên hệ 
rõ ràng với nhau. 88 
3. Mối quan hệ giữa các lớp đối tượng 
3.3 Quan hệ phụ thuộc và nâng cấp 
Quan hệ phụ thuộc được thể hiện bằng đường thẳng gạch 
rời với mũi tên (và có thể thêm một nhãn) giữa các phần tử 
mô hình. 
89 
3. Mối quan hệ giữa các lớp đối tượng 
3.3 Quan hệ phụ thuộc và nâng cấp 
 Quan hệ Nâng cấp (refinement) là một quan hệ giữa hai 
lời miêu tả của cùng một sự vật, nhưng ở những mức độ 
trừu tượng hóa khác nhau. 
 Nâng cấp có thể là mối quan hệ giữa một loại đối tượng 
và lớp thực hiện nó. 
 Các nâng cấp thường gặp khác là quan hệ giữa một lớp 
phân tích (trong mô hình phân tích) và một lớp thiết kế 
(trong mô hình thiết kế) đều mô hình hóa cùng một thứ, 
quan hệ giữa một lời miêu tả có mức trừu tượng hóa cao 
và một lời miêu tả có mức trừu tượng hóa thấp (ví dụ 
một bức tranh khái quát của một sự cộng tác động và 
một biểu đồ chi tiết của cũng cộng tác đó). 
90 
3. Mối quan hệ giữa các lớp đối tượng 
3.3 Quan hệ phụ thuộc và nâng cấp 
 Quan hệ Nâng cấp (refinement) là một quan hệ giữa hai 
lời miêu tả của cùng một sự vật, nhưng ở những mức độ 
trừu tượng hóa khác nhau. 
 Nâng cấp có thể là mối quan hệ giữa một loại đối tượng 
và lớp thực hiện nó. 
 Các nâng cấp thường gặp khác là quan hệ giữa một lớp 
phân tích (trong mô hình phân tích) và một lớp thiết kế 
(trong mô hình thiết kế) đều mô hình hóa cùng một thứ, 
quan hệ giữa một lời miêu tả có mức trừu tượng hóa cao 
và một lời miêu tả có mức trừu tượng hóa thấp (ví dụ 
một bức tranh khái quát của một sự cộng tác động và 
một biểu đồ chi tiết của cũng cộng tác đó). 
91 
3. Mối quan hệ giữa các lớp đối tượng 
3.3 Quan hệ phụ thuộc và nâng cấp 
 Quan hệ nâng cấp còn được sử dụng để mô hình hóa 
nhiều mức thực thi của cùng một thứ (một thực thi đơn 
giản và một thực thi phức tạp hơn, hiệu quả hơn). Quan 
hệ nâng cấp được thể hiện bằng đường thẳng gạch rời 
(dashed line) với mũi tên rỗng, xem ví dụ sau 
92 
3. Mối quan hệ giữa các lớp đối tượng 
3.3 Quan hệ phụ thuộc và nâng cấp 
Quan hệ nâng cấp được sử dụng trong việc phối hợp mô 
hình. Trong các dự án lớn, mọi mô hình đều cần phải được 
phối hợp với nhau. Phối hợp mô hình được sử dụng nhằm 
mục đích: 
 Chỉ ra mối liên quan giữa các mô hình ở nhiều mức độ 
trừu tượng khác nhau. 
 Chỉ ra mối liên quan giữa các mô hình ở nhiều giai đoạn 
khác nhau (phân tích yêu cầu, phân tích, thiết kế, thực 
thi). 
 Hỗ trợ việc quản trị cấu hình. 
93 
3. Mối quan hệ giữa các lớp đối tượng 
3.4 Tìm các quan hệ 
 Thường sẽ có nhiều mối quan hệ giữa các đối tượng 
trong một hệ thống. 
 Quyết định quan hệ nào cần phải được thực thi là công 
việc thụôc giai đoạn thiết kế. 
 Có thể tìm các mối quan hệ qua việc nghiên cứu các lời 
phát biểu vấn đề, các yêu cầu. 
 Giống như danh từ đã giúp chúng ta tìm lớp, các động từ 
ở đây sẽ giúp ta tìm ra các mối quan hệ. 
94 
3. Mối quan hệ giữa các lớp đối tượng 
3.4 Tìm các quan hệ 
Một vài chỉ dẫn tìm quan hệ: 
 Vị trí về mặt vật lý hoặc sự thay thế, đại diện: Mỗi cụm 
động từ xác định hay biểu lộ một vị trí đều là một biểu 
hiện chắc chắn cho quan hệ. Ví dụ: tại địa điểm, ở trong 
 Sự bao chứa: Cụm động từ biểu lộ sự bao chứa, ví dụ 
như: là thành phần của... 
 Giao tiếp: Có nhiều cụm động từ biểu lộ sự giao tiếp, ví 
dụ trao đổi thông tin điệp, nói chuyện với 
 Quyền sở hữu: Ví dụ thuộc về, của 
 Thoả mãn một điều kiện: Những cụm từ như: làm việc 
cho, là chồng/vợ của, quản trị 
95 
3. Mối quan hệ giữa các lớp đối tượng 
3.4 Tìm các quan hệ 
Xử lý các quan hệ không cần thiết 
Sau khi tìm các mối quan hệ, bước tiếp theo đó là phân 
biệt các quan hệ cần thiết ra khỏi các quan hệ không cần 
thiết. Quan hệ không cần thiết có thể bao gồm những quan 
hệ bao chứa các lớp ứng viên đã bị loại trừ hoặc các quan 
hệ không liên quan đến hệ thống. Có những quan hệ được 
tạo ra nhằm mục đích tăng hiệu quả. Những quan hệ như 
thế là ví dụ tiêu tiểu của các chi tiết thực thi và không liên 
quan tới giai đoạn này. 
96 
3. Mối quan hệ giữa các lớp đối tượng 
3.4 Tìm các quan hệ 
Xử lý các quan hệ không cần thiết 
 Cần chú ý phân biệt giữa phương thức và mối quan hệ. 
Người ta thường có xu hướng miêu tả phương thức như 
là quan hệ, bởi cả quan hệ lẫn phương thức đều được 
dẫn xuất từ những cụm từ mang tính động từ trong bản 
miêu tả yêu cầu. 
 Các phương thức đã được thể hiện sai thành quan hệ 
cũng cần phải được loại bỏ. Khi làm việc này, có thể áp 
dụng một nguyên tắc: quan hệ là kết nối mang tính tĩnh 
giữa các đối tượng, trong khi phương thức chỉ là thao tác 
xảy ra một lần. phương thức vì vậy nên được coi là 
phương thức đối với một đối tượng chứ không phải quan 
hệ giữa các lớp. 
97 
3. Mối quan hệ giữa các lớp đối tượng 
3.4 Tìm các quan hệ 
Xử lý các quan hệ không cần thiết 
 Ví dụ với "Ban quản trị ngân hàng tiếp nhận một nhân 
viên", động từ “tiếp nhận” thể hiện phương thức. Trong 
khi đó với “Một nhân viên làm việc cho hãng" thì động 
từ “làm việc" miêu tả quan hệ giữa hai lớp nhân viên và 
hãng. 
 Trong khi cố gắng loại bỏ các quan hệ dư thừa, ta sẽ 
thấy có một số quan hệ dư thừa đã "lẻn vào" mô hình 
trong giai đoạn thiết kế. Hình sau chỉ ra một số loại quan 
hệ dư thừa cần đặc biệt chú trọng. 
98 
3. Mối quan hệ giữa các lớp đối tượng 
3.4 Tìm các quan hệ 
Nâng cấp các quan hệ 
 Một khi các quan hệ cần thiết đã được nhận dạng, bước 
tiếp theo là ngiên cứu kỹ mô hình và nâng cấp các mối 
quan hệ đó. 
 Động tác nâng cấp đầu tiên là xem xét lại tên quan hệ, 
tên vai trò, đặt lại cho đúng với bản chất quan hệ mà 
chúng thể hiện. Mỗi quan hệ cần phải được suy xét kỹ 
về phương diện số lượng thành phần tham gia 
(cardinality). Sự hạn định (qualification) cho quan hệ 
đóng một vai trò quan trọng ở đây, bổ sung yếu tố hạn 
định có thể giúp làm giảm số lượng. Nếu cần thiết, hãy 
bổ sung các quan hệ còn thiếu. Nghiên cứu kỹ các thuộc 
tính, xem liệu trong số chúng có thuộc tính nào thật ra 
thể hiện quan hệ. 99 
4. Nâng cấp mô hình 
Khi nâng cấp mô hình cần chú ý đến các bước sau: 
 a) Nghiên cứu các lớp để tìm các thuộc tính và thủ tục 
không đồng dạng (dissimilar). Nếu có, chia nhỏ lớp 
thành các thành phần để tạo tính đồng nhất (harmony) 
trong lớp. Ví dụ với một lớp đảm nhận hai vai trò khác 
nhau, hãy chia nhỏ lớp này thành các lớp với những thủ 
tục được xác định rõ ràng. 
 b) Nếu phát hiện thấy một chức năng không hướng tới 
một lớp đích nào thì đó là triệu chứng thiếu lớp. Hãy bổ 
sung lớp thiếu và đưa thủ tục kể trên vào lớp đó. 
10
0 
4. Nâng cấp mô hình 
Khi nâng cấp mô hình cần chú ý đến các bước sau: 
 c) Khái quát hóa là còn chưa đủ độ nếu có các quan hệ 
trùng lặp (nhiều quan hệ cùng định nghĩa một quan hệ). 
Trong trường hợp này, cần tạo lớp cha để kết hợp các 
mối quan hệ đó. 
 d) Nếu một vai trò mang một ý nghĩa đặc biệt quan trọng 
đối với hệ thống thì thường nó cần một lớp riêng. Một 
lựa chọn khác là biến định nghĩa vai trò của quan hệ này 
thành một lớp quan hệ. 
 e) Nếu một lớp thiếu cả thuộc tính lẫn thủ tục hoặc quan 
hệ thì rất có thể đây là một lớp không cần thiết. Hãy loại 
bỏ những lớp đó nếu có thể. 
10
1 
4. Nâng cấp mô hình 
Khi nâng cấp mô hình cần chú ý đến các bước sau: 
 f) Rà sát toàn bộ hệ thống để tìm những vai trò giữa các 
lớp còn chưa được thể hiện. Nếu có, đây là triệu chứng 
thiếu quan hệ. 
 g) Nếu có một quan hệ giữa các đối tượng nhưng lại 
chẳng được thủ tục nào sử dụng tới thì rất có thể đây là 
một quan hệ không cần thiết. Ví dụ ta đã xác định một 
quan hệ giữa nhân viên thu ngân và khách hàng nhưng 
lại không có thủ tục nào được định nghĩa giữa hai người. 
Trong trường hợp này, rất có thể quan hệ đó là không 
cần thiết. 
10
2 
4. Nâng cấp mô hình 
Một số chỉ dẫn thực tế: 
 Nghiên cứu để hiểu thấu đáo vấn đề cần giải quyết: Khi 
xây dựng mô hình đối tượng, không nên bắt đầu bằng 
cách viết ra các cấu trúc lớp, các mối quan hệ cũng như 
những mối quan hệ thừa kế lộ rõ trên bề mặt và đập 
thẳng vào mắt chúng ta. Hãy dành thời gian nghiên cứu 
kỹ bản chất vấn đề. Mô hình đối tượng phải được thiết 
kế để phù hợp với giải pháp cho vấn đề mà chúng ta 
nhắm tới. 
10
3 
4. Nâng cấp mô hình 
Một số chỉ dẫn thực tế: 
 Cẩn thận khi chọn tên: Tên cần được chọn một cách cẩn 
thận bởi nó chứng nhận sự tồn tại các thực thể. Tên cần 
phải chính xác, ngắn gọn, tránh gây tranh cãi. Tên phải 
thể hiện tổng thể đối tượng chứ không chỉ nhắm tới một 
khía cạnh nào đó của đối tượng. Hãy chọn những tên 
nào chứa các danh từ chuyên ngành quen thuộc đối với 
người sử dụng. Những tên xa vời đối với người sử dụng, 
hoặc các thực thể được đặt tên một cách tồi tệ rất dễ gây 
ra nhầm lẫn. 
 10
4 
4. Nâng cấp mô hình 
Một số chỉ dẫn thực tế: 
 Cần giữ cho mô hình đối tượng được đơn giản: Hãy đi 
ngược lại xu hướng tạo ra các mô hình phức tạp, chúng 
chỉ mang lại sự nhầm lẫn, khó hiểu. Trong vòng đầu của 
quy trình mô hình hóa đối tượng, hãy xác định các mối 
quan hệ căn bản và gạt ra ngoài các chi tiết, việc xem xét 
tới các số lượng thành phần tham gia (Cardinality) trong 
quan hệ nên để dành cho giai đoạn sau; rất có thể là ở 
vòng thứ hai. 
10
5 
4. Nâng cấp mô hình 
Một số chỉ dẫn thực tế: 
 Nên sử dụng các mối quan hệ hạn định bất cứ khi nào có 
thể. 
 Tránh khái quát hóa quá nhiều. Thường chỉ nên hạn chế 
ở ba tầng khái quát. 
 Nghiên cứu thật kỹ các mối quan hệ 1-nhiều. Chúng 
thường có thể được chuyển thành các quan hệ 1- 0 hoặc 
1- 1. 
10
6 
4. Nâng cấp mô hình 
Một số chỉ dẫn thực tế: 
 Tất cả các mô hình cần phải được lấy làm đối tượng cho 
việc tiếp tục nâng cấp. Nếu không thực hiện những vòng 
nâng cấp sau đó, rất có thể mô hình của chúng ta sẽ thiếu 
hoàn chỉnh. 
 Động tác để cho người khác xem xét lại mô hình là rất 
quan trọng. Thường sự liên quan quá gần với mô hình sẽ 
khiến chúng không nhận những ra khiếm khuyết của nó. 
Một cái nhìn vô tư trong trường hợp này là rất cần thiết. 
10
7 
4. Nâng cấp mô hình 
Một số chỉ dẫn thực tế: 
 Không nên mô hình hóa các mối quan hệ thành thuộc 
tính. Nếu điều này xảy ra, ta thường có thể nhận thấy 
triệu chứng là mô hình thiếu quan hệ. Thêm vào đó, đã 
có lúc ta bỏ qua sự cần thiết của một yếu tố hạn định. 
 Việc viết tài liệu cho mô hình là vô cùng quan trọng. 
Các tài liệu cần phải nắm bắt thấu đáo những nguyên 
nhân nằm đằng sau mô hình và trình bày chúng chính 
xác như có thể. 
10
8 
Tóm tắt 
Phân tích hệ thống – Mô hình khái niệm và biểu đồ lớp 
4.1 Mô hình khái niệm – mô hình đối tượng 
4.2 Xác định các lớp, đối tượng 
4.3 Mối quan hệ giữa các lớp đối tượng 
4.4 Nâng cấp mô hình 
10
9 
DISCUSSION – CÂU HỎI 
https://sites.google.com/site/daonamanhedu/teac
hing/objectorientedanalysisanddesign 
110