12

Phân Tích Miền

Phân tích miền được coi là giai đoạn tiếp theo của phát triển phần mềm, nó liên
quan đến việc tạo ra một mô hình chính xác, ngắn gọn, dễ hiểu và đúng đắn trong thực tế.
Trước khi xây dựng bất cứ thứ gì phức tạp, người thiết kế phải hiểu các yêu cầu. Các yêu
cầu có thể được nêu bằng lời nói, nhưng thông thường chúng không chính xác và mơ hồ.
Trong quá trình phân tích, chúng ta cần xây dựng các mô hình liên quan và bắt đầu hiểu sâu
hơn các yêu cầu đã đề cập.
Để xây dựng một mô hình miền (Domain Model), bạn phải phỏng vấn các chuyên
gia kinh doanh, kiểm tra các bản báo cáo về các yêu cầu và xem xét kỹ lưỡng các tạo tác liên
quan. Bạn phải phân tích ý nghĩa của các yêu cầu và trình bày lại chúng một cách chặt chẽ.
Điều quan trọng là phải trừu tượng hóa các tính năng quan trọng trước và để các chi tiết nhỏ
sau. Mô hình phân tích thành công là mô hình phải nêu rõ những gì phải được thực hiện mà
không hạn chế cách thức thực hiện và tránh các quyết định bất ngờ.
Trong chương này, bạn sẽ học cách lấy các khái niệm hướng đối tượng và áp dụng
chúng để xây dựng một mô hình miền. Mô hình này có thể phục vụ một số mục đích: làm rõ
các yêu cầu, cung cấp cơ sở cho sự đồng thuận giữa các cổ đông và lập trình viên và là điểm
khởi đầu cho thiết kế và triển khai.

12.1 Tổng Quan Về Phân Tích

Như Hình 12.1 cho thấy, quá trình phân tích bắt đầu với một bản báo cáo vấn đề xuất hiện
trong quá trình hình thành hệ thống. Bản báo cáo có thể không đầy đủ hoặc không chính
thức; việc phân tích làm cho nó chính xác hơn và trình bày rõ sự mơ hồ và mâu thuẫn. Bản
báo cáo về vấn đề không nên được coi là bất biến mà nên dùng làm cơ sở để tinh chỉnh các
yêu cầu thực tế.
Tiếp theo, bạn phải hiểu hệ thống trong thực tế được mô tả bởi báo cáo về vấn đề
và trừu tượng hóa các đặc điểm cơ bản của nó thành một mô hình. Các phát biểu trong ngôn
ngữ tự nhiên thường mơ hồ, không đầy đủ và không nhất quán. Mô hình phân tích là một
biểu diễn chính xác, súc tích của vấn đề cho phép trả lời các câu hỏi và xây dựng giải pháp.
Các bước thiết kế tiếp theo đề cập đến mô hình phân tích, thay vì tuyên bố vấn đề mơ hồ ban
đầu.
186 Chương 12 / Phân Tích Miền

Hình 12.1 Tổng quan về phân tích. Bản báo cáo vấn đề không nên được coi là không thể
thay đổi, mà là cơ sở để tinh chỉnh các yêu cầu

Có lẽ điều quan trọng hơn, quá trình xây dựng một mô hình nghiêm ngặt của miền vấn đề
buộc lập trình viên phải sớm đối mặt với những nhầm lẫn trong quá trình phát triển trong khi
chúng vẫn còn dễ sửa.
Mô hình phân tích đề cập đến ba khía cạnh của đối tượng: cấu trúc tĩnh của đối
tượng (mô hình lớp), tương tác giữa các đối tượng (mô hình tương tác) và lịch sử vòng đời
của đối tượng (mô hình trạng thái). Cả ba mô hình con đều không quan trọng như nhau
trong mọi vấn đề. Hầu như tất cả các vấn đề đều có các mô hình lớp hữu ích bắt nguồn từ
các thực thể trong thực tế. Các vấn đề liên quan đến điều khiển phản ứng và thời gian, chẳng
hạn như giao diện người dùng và điều khiển quy trình, có các mô hình trạng thái quan trọng.
Các vấn đề chứa tính toán quan trọng cũng như các hệ thống tương tác với các hệ thống
khác và các loại người dùng khác nhau có các mô hình tương tác quan trọng.
Phân tích không phải là một quá trình diễn ra quá máy móc. Các miêu tả chính xác
liên quan đến phán đoán và về nhiều mặt là một vấn đề nghệ thuật. Hầu hết các báo cáo vấn
đề đều thiếu thông tin cần thiết, thông tin này phải được lấy từ người yêu cầu hoặc từ kiến
thức của nhà phân tích về miền vấn đề trong thực tế. Ngoài ra, có một sự lựa chọn về mức
độ trừu tượng cho mô hình. Người phân tích phải liên lạc với người yêu cầu để làm rõ sự mơ
hồ và quan điểmbị hiểu lầm. Các mô hình phân tích cho phép giao tiếp chính xác.
Chúng tôi đã chia phân tích thành hai giai đoạn. Phần đầu tiên là phân tích miền,
thứ sẽ được trình bày trong chương này và tập trung vào việc hiểu bản chất thực tế của một
vấn đề. Phần thứ hai là phân tích ứng dụng, điều mà được trình bày trong chương tiếp theo
và được xây dựng trên mô hình miền kết hợp các tạo phẩm ứng dụng chính mà người dùng
nhìn thấy và phải được họ chấp thuận.
12.2 Mô Hình Lớp Miền
Bước đầu tiên khi phân tích các yêu cầu là xây dựng một mô hình lớp miền. Mô hình miền
hiển thị cấu trúc tĩnh của hệ thống thế giới thực và sắp xếp nó thành các phần khả thi. Mô
hình miền mô tả các lớp trong thế giới thực và mối quan hệ của chúng với nhau. Trong quá
trình phân tích, mô hình lớp đứng trước các mô hình trạng thái và tương tác vì cấu trúc tĩnh
có xu hướng được xác định tốt hơn, ít phụ thuộc vào chi tiết ứng dụng và ổn định hơn khi
giải pháp phát triển. Thông tin cho mô hình miền đến từ vấn đề nêu lên, tạo tác từ các hệ
thống liên quan, kiến thức chuyên môn về miền ứng dụng và kiến thức chung về thế giới
thực. Đảm bảo rằng bạn xem xét tất cả thông tin có sẵn và không dựa vào một nguồn duy
nhất.
Tìm các lớp và sự liên kết trước, vì chúng cung cấp cấu trúc tổng thể và cách tiếp cận
vấn đề. Tiếp theo, thêm các thuộc tính để mô tả mạng lưới lớp và liên kết cơ bản. Sau đó kết
hợp và tổ chức các lớp bằng kế thừa. Nỗ lực chỉ định kế thừa trực tiếp mà không cần hiểu
trước các lớp và các thuộc tính của chúng có thể làm sai lệch cấu trúc lớp để phù hợp với các
khái niệm định sẵn. Sự vận hành thường không quan trọng trong một mô hình miền. Mục
đích chính của mô hình miền là nắm bắt nội dung thông tin của một miền.
Tốt nhất là ghi ý tưởng ra giấy trước khi cố gắng sắp xếp chúng quá nhiều để không làm
mất các chi tiết quan trọng, mặc dù chúng có thể dư thừa và không nhất quán. Một mô hình
phân tích ban đầu có khả năng chứa các sai sót phải được sửa chữa bằng các lần làm lặp lại
sau này. Toàn bộ mô hình không cần phải được xây dựng thống nhất. Một số khía cạnh của
vấn đề có thể được phân tích sâu thông qua một số lần lặp lại trong khi các khía cạnh khác
vẫn còn sơ sài.
Bạn phải thực hiện các bước sau để xây dựng mô hình lớp miền.
■ Tìm các lớp. [12.2.1–12.2.2]
■ Chuẩn bị từ điển dữ liệu. [12.2.3]
■ Tìm các mối liên kết. [12.2.4–12.2.5]
■ Tìm thuộc tính của đối tượng và đường liên kết. [12.2.6–12.2.7]
■ Tổ chức và đơn giản hóa lớp bằng kế thừa. [12.2.8]
■ Xác minh rằng đường dẫn truy cập tồn tại cho các truy vấn có khả năng. [12.2.9]
■ Lặp lại và tinh chỉnh mô hình. [12.2.10]
■ Xem xét lại mức độ trừu tượng. [12.2.11]
■ Nhóm các lớp thành các gói. [12.2.12]

12.2.1 Tìm các lớp

Bước đầu tiên trong việc xây dựng một mô hình lớp là tìm các lớp có liên quan cho các đối
tượng từ miền ứng dụng. Các đối tượng bao gồm các thực thể vật lý, chẳng hạn như nhà cửa,
con người và máy móc, cũng như các khái niệm, chẳng hạn như quỹ đạo, chỉ định chỗ ngồi
và lịch thanh toán. Tất cả các lớp phải có ý nghĩa trong lĩnh vực ứng dụng; Tránh các cấu
trúc hoạt động của máy tính, chẳng hạn như danh sách liên kết và chương trình con. Không
phải tất cả các lớp đều rõ ràng trong vấn đề đã được nêu; một số được ngầm hiểu trong lĩnh
vực ứng dụng hoặc kiến thức chung.
186 Chương 12 / Phân Tích Miền

Như Hình 12.2 cho thấy, hãy bắt đầu bằng cách liệt kê các lớp ứng cử viên được tìm
thấy trong mô tả bằng văn bản về vấn đề. Đừng quá chọn lọc; Viết ra mọi lớp nghĩ ra. Các
lớp thường tương ứng với danh từ. Ví dụ: trong câu "một hệ thống đặt chỗ để bán vé xem
các buổi biểu diễn tại các nhà hát khác nhau", các lớp dự kiến sẽ là Sự đặt chỗ, Hệ thống,
Vé, Biểu diễn và Nhà hát. Tuy nhiên, đừng làm một cách mù quáng. Ý tưởng là nắm bắt các
khái niệm; Không phải tất cả các danh từ đều là khái niệm, và các khái niệm cũng được thể
hiện trong các phần khác của lời nói.

Hình 12.2 Tìm các lớp. Bạn có thể tìm thấy nhiều lớp bằng cách xem xét danh từ.

Đừng lo lắng nhiều về kế thừa hoặc các lớp cấp cao; Trước tiên, hãy làm đúng các lớp
cụ thể để bạn không vô thức ngăn chặn khi vào chi tiết hơn khi cố gắng làm phù hợp với cấu
trúc định sẵn. Ví dụ: nếu bạn đang xây dựng hệ thống danh mục và thanh toán cho thư viện,
hãy xác định các loại vật liệu khác nhau, chẳng hạn như sách, tạp chí, báo, hồ sơ, video, v.v.
Bạn có thể sắp xếp chúng thành các danh mục rộng hơn sau này, bằng cách tìm kiếm những
điểm tương đồng và khác biệt.
Ví dụ ATM. Việc kiểm tra các khái niệm trong vấn đề về ATM được nêu từ chương 11
mang lại các lớp dự kiến được thể hiện trong Hình 12.3. Hình 12.4 cho thấy các lớp bổ sung
không xuất hiện trực tiếp trong câu lệnh nhưng có thể được xác định từ kiến thức của chúng
ta về miền vấn đề.

Hình 12.3 Các lớp ATM được trích xuất từ danh từ trong câu vấn đề

Hình 12.4 Các lớp ATM được xác định từ kiến thức về vấn đề của miền
12.2.2 Giữ lại các lớp chính xác
Bây giờ loại bỏ các lớp không cần thiết và không chính xác theo các tiêu chí sau. Hình 12.5
cho thấy các lớp bị loại khỏi ví dụ ATM.

Hình 12.5 Loại bỏ các lớp không cần thiết ra khỏi vấn đề ATM

■ Các lớp dư thừa. Nếu hai lớp thể hiện cùng một khái niệm, bạn nên giữ tên mô tả nhất.
Ví dụ: mặc dù Khách hàng có thể mô tả một người đi chuyến bay của hãng hàng không,
Hành khách mô tả chính xác hơn. Mặt khác, nếu vấn đề liên quan đến các hợp đồng cho
một chuyến bay được thuê, thì Khách hàng cũng là một từ thích hợp, vì một hợp đồng
có thể liên quan đến một số hành khách.
Ví dụ ATM. Khách hàng và Người dùng là dư thừa; chúng ta giữ lại Khách hàng
vì nó mô tả chính xác hơn.
■ Các lớp không liên quan. Nếu một lớp có ít hoặc không liên quan gì đến vấn đề, hãy loại
bỏ nó. Điều này liên quan đến sự nhận định, bởi vì trong một bối cảnh khác, lớp này có
thể quan trọng. Ví dụ, trong hệ thống đặt vé rạp hát, nghề nghiệp của người giữ vé là
không liên quan, nhưng nghề nghiệp của nhân viên rạp hát có thể quan trọng.
Ví dụ ATM. Phân bổ chi phí nằm ngoài phạm vi của phần mềm ATM.
■ Các lớp mơ hồ. Một lớp nên được cụ thể. Một số lớp dự kiến có thể có ranh giới không rõ
ràng hoặc phạm vi quá rộng.
Vi dụ ATM. Cung cấp hệ thống lưu trữ hồ sơ thì mơ hồ và được xủ lý bởi Công
việc giao dịch. Trong các ứng dụng khác, điều này có thể được bao gồm trong các lớp
khác, chẳng hạn như Bán hàng tồn kho, Gọi điện thoại hoặc Lỗi máy.
186 Chương 12 / Phân Tích Miền

■ Thuộc tính. Thuộc tính. Các tên chủ yếu mô tả các đối tượng riêng lẻ nên được trình bày
lại dưới dạng thuộc tính. Ví dụ: tên, ngày sinh và cân nặng thường là các thuộc tính.
Nếu sự tồn tại độc lập của một thuộc tính là quan trọng, thì hãy biến nó thành một lớp
chứ không phải một thuộc tính. Ví dụ: văn phòng của nhân viên sẽ là một lớp trong ứng
dụng phân công lại văn phòng sau khi tổ chức lại.
Ví dụ ATM. Dữ liệu tài khoản không được chỉ định rõ nhưng có thể mô tả một tài
khoản trong mọi trường hợp. Máy ATM phân phát tiền mặt và biên lai, nhưng ngoài ra,
tiền mặt và biên lai là vấn đề ngoại vi, vì vậy chúng nên được coi là thuộc tính.
■ Sự vận hành. Nếu một tên mô tả một thao tác được áp dụng cho các đối tượng và không
được thao tác theo cách riêng của nó, thì đó không phải là một lớp. Ví dụ, một cuộc gọi
điện thoại là một chuỗi các hành động liên quan đến người gọi và mạng điện thoại. Nếu
chúng ta chỉ đơn giản là xây dựng lớp điện thoại, thì gọi điện là một phần của mô hình
trạng thái chứ không phải là một lớp.
Tuy nhiên, một hoạt động có các tính năng của riêng nó nên được mô hình hóa như
một lớp. Ví dụ: trong hệ thống thanh toán cho các cuộc gọi điện thoại, Cuộc gọi sẽ là
một lớp quan trọng với các thuộc tính như ngày, giờ, nguồn gốc và điểm đến.
■ Vai trò. Tên của một lớp nên phản ánh bản chất tự nhiên của nó và không phải là vai trò
của nó trong một tổ chức. Ví dụ: Chủ sở hữu sẽ là một tên kém cho một lớp trong cơ sở
dữ liệu của nhà sản xuất ô tô. Nếu một danh sách các tài xế được thêm vào sau thì sao?
Còn những người thuê xe thì sao? Các lớp thích hợp là Người (hoặc có thể là Khách
hàng), đảm nhận nhiều vai trò khác nhau, như là chủ, tài xế, and người thuê.
Một thực thể vật lý đôi khi tương ứng với một số lớp. Ví dụ: Người và Nhân viên
có thể là các lớp riêng biệt trong một số trường hợp và dư thừa trong những trường hợp
khác. Từ quan điểm của một cơ sở dữ liệu công ty về nhân viên, cả hai có thể giống hệt
nhau. Trong cơ sở dữ liệu thuế của chính phủ, một người có thể đảm nhiệm nhiều hơn
một công việc, vì vậy điều quan trọng là phải phân biệt Người với Nhân viên; mỗi người
có thể tương ứng với không hoặc nhiều trường hợp thông tin nhân viên.
■ Các cấu trúc triển khai. Loại bỏ các cấu trúc khỏi mô hình phân tích không liên quan
đến thế giới thực. Bạn có thể cần chúng sau này trong quá trình thiết kế, nhưng không
phải bây giờ. Ví dụ: CPU, chương trình con, quy trình, thuật toán và ngắt là các cấu trúc
triển khai cho hầu hết các ứng dụng, mặc dù chúng là các lớp hợp lệ cho một hệ điều
hành. Các cấu trúc dữ liệu, chẳng hạn như danh sách liên kết, cấu trúc cây, mảng và
bảng, hầu như luôn là các cấu trúc triển khai.
Ví dụ ATM. Một số lớp dự kiến thực sự là các cấu trúc triển khai. Nhật ký dữ liệu
đơn giản là tập hợp các dữ liệu; đại diện chính xác của nó là một vấn đề thiết kế. Các
liên kết giao tiếp có thể được hiển thị dưới dạng các tổ chức; Đường liên kết chỉ đơn
giản là việc triển khai vật lý của một liên kết như vậy.
■ Các lớp dẫn xuất. Theo nguyên tắc chung, bỏ qua các lớp có thể dẫn xuất từ các lớp
khác. Nếu một lớp dẫn xuất đặc biệt quan trọng, bạn có thể đưa nó vào, nhưng chỉ làm
như vậy một cách tiết kiệm.
Đánh dấu tất cả các lớp dẫn xuất bằng dấu gạch chéo ('/') trước trong tên lớp.
12.2.3 Chuẩn bị từ điển dữ liệu
Các từ riêng lẻ có quá nhiều cách hiểu, vì vậy hãy chuẩn bị một từ điển dữ liệu cho tất cả các
yếu tố mô hình hóa. Viết một đoạn văn mô tả chính xác từng lớp. Mô tả phạm vi của lớp
trong vấn đề hiện tại, bao gồm bất kỳ giả định hoặc hạn chế nào đối với việc sử dụng nó. Từ
điển dữ liệu cũng mô tả các liên kết, thuộc tính, hoạt động và giá trị liệt kê. Hình 12.6 chỉ ra
một từ điển dữ liệu cho các lớp trong bài toán ATM.

12.2.4 Tìm mối liên hệ

Tiếp theo, tìm mối liên hệ giữa các lớp. Một mối quan hệ cấu trúc giữa hai hoặc nhiều lớp là
một mối liên hệ. Một tham chiếu từ lớp này sang lớp khác là một liên kết. Như chúng ta đã
thảo luận trong Chương 3, các thuộc tính không nên tham chiếu đến các lớp; sử dụng một
liên kết thay thế. Ví dụ, lớp Người không nên có một thuộc tính Người chủ; liên kết lớp
Người và lớp Công ty với liên kết Làm việc cho. Các liên kết thể hiện các mối quan hệ giữa
các lớp ở cùng mức trừu tượng như chính các lớp đó, trong khi các thuộc tính có giá trị đối
tượng che giấu các phụ thuộc và che khuất bản chất hai chiều của chúng. Các liên kết có thể
được triển khai theo nhiều cách khác nhau, nhưng các quyết định triển khai như vậy nên
được loại bỏ khỏi mô hình phân tích để bảo vệ quyền tự do thiết kế.
Các liên kết thường tương ứng với động từ trạng thái hoặc cụm động từ. Chúng bao gồm
vị trí thực tế (NextTo, PartOf, ContainedIn), hành động được chỉ định (Drives), giao tiếp
(TalksTo), quyền sở hữu (Has, PartOf) hoặc sự hài lòng của một số điều kiện (WorksFor,
MarriedTo, Manages). Trích xuất tất cả các ứng cử viên từ câu vấn đề và viết chúng ra giấy
trước; đừng cố tinh chỉnh mọi thứ quá sớm. Một lần nữa, đừng xem xét các dạng ngữ pháp
một cách mù quáng; ý tưởng là nắm bắt các mối quan hệ, tuy nhiên chúng được thể hiện
bằng ngôn ngữ tự nhiên.
Ví dụ ATM. Hình 12.7 cho thấy các liên kết. Phần lớn được lấy trực tiếp từ các cụm
động từ trong câu vấn đề. Đối với một số liên kết, cụm động từ được ẩn trong câu phát biểu.
Cuối cùng, một số liên kết phụ thuộc vào kiến thức thực tế hoặc giả định. Chúng phải được
xác minh với người yêu cầu, vì chúng không có trong câu vấn đề.

12.2.5 Giữ các liên kết phù hợp

Bây giờ loại bỏ các liên kết không cần thiết và không chính xác, sử dụng các tiêu chí sau.
■ Liên kết giữa các lớp bị loại bỏ. Nếu bạn đã loại bỏ một trong các lớp trong liên kết, bạn
phải loại bỏ liên kết hoặc trình bày lại nó dưới dạng các lớp khác.
Ví dụ ATM. Chúng ta có thể loại bỏ Mạng lưới ngân hàng bao gồm các trạm thu
ngân và máy ATM, ATM phân phối tiền mặt, ATM in biên lai, Ngân hàng cung cấp
phần mềm, Chi phí được phân bổ cho ngân hàng, Hệ thống cung cấp lưu trữ hồ sơ và
Hệ thống cung cấp bảo mật.
■ Các liên kết được triển khai hoặc không liên quan. Loại bỏ mọi liên kết nằm ngoài
miền vấn đề hoặc xử lý các cấu trúc triển khai.
Ví dụ ATM. Ví dụ: Hệ thống xử lý truy cập đồng thời là một khái niệm triển khai.
Các đối tượng trong thế giới thực vốn đồng thời; đó là việc thực hiện thuật toán truy cập
phải đồng thời.
186 Chương 12 / Phân Tích Miền

Tài khoản— một tài khoản duy nhất tại một ngân hàng mà các giao dịch có thể được áp
dụng. Tài khoản có thể thuộc nhiều loại khác nhau, chẳng hạn như séc hoặc tiết kiệm. Một
khách hàng có thể giữ nhiều hơn một tài khoản.
ATM— một trạm cho phép khách hàng nhập các giao dịch của riêng họ bằng cách sử dụng
thẻ tiền mặt làm giấy tờ tùy thân. Máy ATM tương tác với khách hàng để thu thập thông tin
giao dịch, gửi thông tin giao dịch đến máy tính trung tâm để xác nhận và xử lý, đồng thời
phân phối tiền mặt cho người dùng. Chúng tôi cho rằng một máy ATM không cần phải hoạt
động độc lập với mạng lưới.
Ngân hàng— một tổ chức tài chính giữ tài khoản cho khách hàng và phát hành thẻ tiền mặt
cho phép truy cập vào tài khoản qua mạng lưới ATM.
Máy tính ngân hàng—máy tính thuộc sở hữu của một ngân hàng giao tiếp với mạng ATM
và các trạm thu ngân của ngân hàng. Một ngân hàng có thể có máy tính nội bộ riêng để xử
lý tài khoản, nhưng chúng tôi chỉ quan tâm đến máy giao tiếp với mạng ATM.
Thẻ rút tiền—thẻ được chỉ định cho khách hàng của ngân hàng cho phép truy cập tài khoản
bằng máy ATM. Mỗi thẻ chứa một mã ngân hàng và một số thẻ. Mã ngân hàng xác định
ngân hang duy nhất trong các tập đoàn. Số thẻ xác định các tài khoản mà thẻ có thể truy cập.
Thẻ không nhất thiết phải truy cập vào tất cả các tài khoản của khách hàng. Mỗi thẻ rút tiền
thuộc sở hữu của một khách hàng, nhưng có thể tồn tại nhiều bản sao của nó, vì vậy phải
xem xét khả năng sử dụng đồng thời cùng một thẻ từ các máy khác nhau.
Thu ngân—một nhân viên của ngân hàng được ủy quyền thực hiện các giao dịch tại các
quầy thu ngân và chấp nhận cũng như phân phối tiền mặt và séc cho khách hàng. Các giao
dịch, tiền mặt và xử lý bởi mỗi nhân viên thu ngân phải được ghi lại và hạch toán chính xác.
Quầy thu ngân—một trạm mà nhân viên thu ngân nhập các giao dịch cho khách hàng.
Nhân viên thu ngân phân phối và chấp nhận tiền mặt và séc; trạm in biên lai. Trạm thu ngân
giao tiếp với máy tính của ngân hàng để xác thực và xử lý các giao dịch.
Máy tính trung tâm— một máy tính được vận hành bởi tập đoàn thực hiện các giao dịch
giữa các máy ATM và máy tính của ngân hàng. Máy tính trung tâm xác thực mã ngân hàng
nhưng không xử lý giao dịch trực tiếp.
Tập đoàn— một tổ chức của các ngân hàng ủy thác và vận hành mạng lưới ATM. Mạng chỉ
xử lý các giao dịch cho các ngân hàng trong tập đoàn.
Khách hàng—chủ sở hữu của một hoặc nhiều tài khoản trong ngân hàng. Một khách hàng
có thể bao gồm một hoặc nhiều người hoặc tập đoàn; sự tương đồng không liên quan đến
vấn đề này. Cùng một người mở tài khoản tại một ngân hàng khác nhau được coi là một
khách hàng khác nhau.

Giao dịch—một yêu cầu không thể thiếu cho các hoạt động trên tài khoản của một khách
hàng. Chúng tôi chỉ xác định rằng các máy ATM phải phân phối tiền mặt, nhưng chúng tôi
không nên loại trừ khả năng in séc hoặc nhận tiền mặt hoặc séc. Chúng tôi cũng có thể
muốn cung cấp sự linh hoạt để hoạt động trên các tài khoản của các khách hàng khác nhau,
mặc dù điều đó chưa bắt buộc.

Hình 12.6 Từ điển dữ liệu cho các lớp ATM. Chuẩn bị một từ điển dữ liệu
cho tất cả các yếu tố mô hình hóa.
 Các cụm động từ
Mạng lưới ngân hàng bao gồm các quầy thu ngân và máy ATM
Các tập đoàn chia sẻ chung máy ATM
Ngân hàng cũng cấp máy tính dành cho ngân hàng
Máy tính ngân hàng duy trì tài khoản
Máy tính ngân hàng xủ lý giao dịch đối với tài khoản
Ngân hàng sở hữu quầy thu ngân
Quầy thu ngân giao tiếp với máy tính ngân hàng
Thu ngân nhập giao dịch cho tài khoản
Máy ATM giao tiếp với máy tính trung tâm về giao dịch
Máy tính trung tâm xóa giao dịch với ngân hàng
ATM chấp nhận thẻ rút tiền
ATM tương tác với ngườidùng
ATM phát tiền mặt
ATM in hóa đơn
Hệ thống xử lí truy cập đồng thời
Ngân hàng cung cấp phần mềm
Chi phí phân bổ cho các ngân hàng
Cụm động từ ẩn
Tập đoàn bao gồm các ngân hàng
Ngân hàng giữ tài khoản
Tập đoàn sở hữu máy tính trung tâm
Hệ thống cung cấp lưu trữ hồ sơ
Hệ thống cung cấp bảo mật
Khách hàng có thẻ rút tiền
Kiến thức về miền vấn đề
Thẻ rút tiền truy cập tài khoản
Ngân hàng tuyển nhân viên thu ngân

Hình 12.7 Những liên kết từ vấn đề ATM

■ Hành động. Một liên kết nên mô tả một thuộc tính cấu trúc của miền ứng dụng, không
phải là một sự kiện nhất thời. Đôi khi, một yêu cầu được thể hiện dưới dạng một hành
động hàm ý một mối quan hệ cấu trúc cơ bản và bạn nên diễn đạt lại yêu cầu đó cho phù
hợp.
Ví dụ TM. ATM chấp nhận thẻ rút tiền mô tả một phần của chu trình tương tác
giữa máy ATM và khách hàng, không phải là mối quan hệ vĩnh viễn giữa máy ATM và
thẻ rút tiền. Chúng tôi cũng có thể loại bỏ tương tác ATM với người dùng. Máy tính
trung tâm xóa giao dịch với ngân hàng mô tả một hành động ngụ ý mối quan hệ cấu
trúc Máy tính trung tâm giao tiếp với ngân hàng.
■ Liên kết ba ngôi. Bạn có thể phân tách hầu hết các liên kết giữa ba hoặc nhiều lớp thành
các liên kết nhị phân hoặc diễn đạt chúng dưới dạng các liên kết đủ điều kiện. Nếu một
thuật ngữ trong một liên kết ba ngôi hoàn toàn mang tính mô tả và không có tính của
riêng nó, thì thuật ngữ đó là một thuộc tính trên một liên kết nhị phân. Liên kết Công ty
trả lương cho nhân viên có thể được viết lại như liên kết nhị phân Công ty tuyển dụng
người với một giá trị tiền lương cho mỗi liên kết Công ty-Người.
186 Chương 12 / Phân Tích Miền

Đôi khi, một ứng dụng sẽ yêu cầu một liên kết ba ngôi chung. Giáo sư dạy khóa
học trong phòng không thể được tách ra mà không làm mất thông tin. Chúng ta không
gặp phải các liên kết với bốn lớp trở lên khi làm.
Ví dụ ATM. Máy tính ngân hàng xử lý giao dịch đối với tài khoản có thể được chia
thành máy tính ngân hàng xử lý giao dịch và tài khoản liên quan đến giao dịch. Thu
ngân nhập giao dịch cho tài khoản cũng có thể được chia ra tương tự. ATM giao tiếp với
máy tính trung tâm về giao dịch thực ra là liên kết nhị phân ATM giao tiếp với máy tính
trung tâm và Giao dịch được nhập trên ATM.
■ Liên kết phát sinh. Bỏ qua các liên kết có thể được xác định theo các liên kết khác, bởi vì
chúng là dư thừa. Ví dụ: GrandparentOf có thể được định nghĩa theo một cặp liên kết
ParentOf. Cũng bỏ qua các liên kết được xác định bởi các điều kiện trên các thuộc tính.
Ví dụ: youngThan thể hiện điều kiện về ngày sinh của hai người, không phải thông tin
bổ sung.
Các lớp, thuộc tính và liên kết trong mô hình lớp nên biểu diễn thông tin độc lập
càng nhiều càng tốt. Nhiều đường dẫn giữa các lớp đôi khi biểu thị các liên kết phát sinh
là thành phần của các liên kết đầu tiên. Tập đoàn chia sẻ máy ATM là một thành phần
của liên kết Tập đoàn sở hữu máy tính trung tâm và máy tính trung tâm giao tiếp với
máy ATM.
Hãy cẩn thận, bởi vì không phải tất cả các liên kết tạo thành nhiều đường dẫn giữa
các lớp đều biểu thị sự dư thừa. Đôi khi sự tồn tại của một liên kết có thể bắt nguồn từ
hai hoặc nhiều liên kết nguyên thủy và nhiều hơn nữa thì không thể. Giữ liên kết bổ
sung nếu ràng buộc bổ sung đa dạng là quan trọng. Ví dụ, trong hình 12.8 một công ty
thuê nhiều người và sở hữu nhiều máy tính. Mỗi nhân viên được chỉ định không hay
nhiều máy tính cho mục đích sử dụng cá nhân; một số máy tính được sử dụng chung và
không được giao cho bất kì ai. Tính đa dạng của liên kết giao việc không thể được suy
ra từ liên kết thuê and chủ.
Employs
Company Person
1 *
1 `` 0..1

Owns AssignedTo
* Computer *

Hình 12.8 Liên kết không dư thừa. Không phải tất cả các liên kết hình thành nhiều
đường dẫn giữa các lớp đều biểu thị sự dư thừa.

Mặc dù các liên kết dẫn xuất không bổ sung thêm thông tin nhưng chúng rất hữu
ích trong thế giới thực và trong thiết kế. Ví dụ: các mối quan hệ họ hàng như Chú, Mẹ
chồng và Anh họ có tên vì chúng mô tả các mối quan hệ phổ biến được coi là quan trọng
trong xã hội của chúng ta. Nếu chúng đặc biệt quan trọng, bạn có thể hiển thị các liên
kết dẫn xuất trong sơ đồ lớp, nhưng hãy đặt dấu gạch chéo trước tên của chúng để biểu
thị trạng thái phụ thuộc của chúng và để phân biệt chúng với các liên kết cơ bản.
Chỉ định thêm ngữ nghĩa của các liên kết như sau:
■ Liên kết bị sai tên. Đừng hỏi làm thế nào hoặc tại sao một tình huống xảy ra, hãy hỏi nó
là gì.Tên rất quan trọng để hiểu và nên được chọn cẩn thận.
Ví dụ ATM. Máy tính ngân hàng duy trì tài khoản là một tuyên bố hành động; viết
lại là Ngân hàng giữ tài khoản.
■ Tên kết thúc của liên kết. Thêm tên kết thúc liên kết khi thích hợp. Ví dụ: trong liên kết
WorksFor, Công ty là chủ đối với một Người và một Người là nhân viên đối với Công
ty. Nếu chỉ có một liên kết giữa một cặp lớp và ý nghĩa của liên kết là rõ ràng, bạn có
thể bỏ qua các tên cuối của liên kết. Ví dụ, ý nghĩa của các máy ATM giao tiếp với máy
tính trung tâm là rõ ràng từ các tên lớp. Một liên kết giữa hai phiên bản của cùng một
lớp yêu cầu tên kết thúc liên kết để phân biệt các phiên bản. Ví dụ: liên kết Người quản
lý sẽ có tên cuối là ông chủ và công nhân.
■ Liên kết đạt chuẩn. Thông thường, một cái tên xác định một đối tượng trong một số ngữ
cảnh; hầu hết các tên không phải là duy nhất trên toàn cầu. Bối cảnh kết hợp với tên để
xác định duy nhất đối tượng. Ví dụ: tên của một công ty phải là duy nhất trong tiểu bang
đã đăng kí nhưng có thể trùng lặp ở các tiểu bang khác (đã từng có Công ty Standard Oil
ở Ohio, Indiana, California và New Jersey). Tên của một công ty đủ điều kiện liên kết
tiểu bang mà công ty thành lập; Tiểu bang và tên công ty xác định duy nhất đối tượng
Công ty. Một vòng loại phân biệt các đối tượng ở phía "nhiều" của một liên kết.
Ví dụ ATM. Mã ngân hàng đủ kiều kiện phân biệt các ngân hàng khác nhau trong
tập đoàn. Mỗi thẻ rút tiền cần một mã ngân hàng để giao dịch có thể chuyển đến ngân
hàng thích hợp.
■ Sự đa dạng. Chỉ rõ sự đa dạng, nhưng đừng nỗ lực quá mức để làm nó đúng, vì sự đa
dạng thường thay đổi trong quá trình phân tích. Thử thách đa dạng giá trị của “Một”. Ví
dụ, liên kết một Quản lý quán lý nhiều nhân viên ngăn cản ma trận quản lý hay một
nhân viên được phân chia nhiều trách nhiệm. Đối với sự đa dạng giá trị của “nhiều” hãy
xem xét liệu có cần phải đạt điều kiện; cũng như nên đặt câu hỏi các đối tượng có cần
phải sắp xếp theo thứ tự nào không.
■ Liên kết bị mất. Thêm vào bất cứ liên kết bị mất nào khi tìm lại được.
Ví dụ ATM. Chún ta bỏ qua Giao dịch được nhập ở quầy thu ngân, Khách hàng có
tài khoản, và Giao dịch được cho phép qua thẻ rút tiền. Nếu nhân viên chỉ được giới hạn
trong quầy thu ngân cụ thể, thì liên kết Nhân viên thu ngân được ủy quyền ở quầy thu
ngân sẽ cần thiết.
■ Tổng hợp. Tổng hợp rất quan trọng đối với một số loại ứng dụng, đặc biệt đối với những
ứng dụng liên quan đến các bộ phận cơ khí và hóa đơn vật liệu. Đối với các ứng dụng
khác, tổng hợp tương đối nhỏ và có thể không rõ có nên sử dụng tổng hợp hay liên kết
thông thường. Đối với những ứng dụng khác này, đừng dành nhiều thời gian để phân
biệt giữa liên kết và tổng hợp. Tổng hợp chỉ là một liên kết với ý nghĩa bổ sung. Sử
dụng bất cứ điều gì có vẻ tự nhiên hơn vào thời điểm đó và đi tiếp.
Ví dụ ATM. Chúng tôi quyết định rằng Ngân hàng là một phần của Tập đoàn và
xác định mối quan hệ với tổng hợp.
Ví dụ ATM. Hình 12.9 cho thấy một sơ đồ lớp với các liên kết còn lại. Chúng ta chỉ bao
gồm các tên liên kết quan trọng. Lưu ý rằng chúng ta đã chia Giao dịch thành Giao dịch từ
xa và Giao dịch thu ngân để phù hợp với các liên kết khác nhau. Biểu đồ hiển thị các giá trị
186 Chương 12 / Phân Tích Miền

đa dạng. Chúng ta có thể đã thực hiện một số quyết định phân tích khác nhau. Đừng lo lắng;
có nhiều mô hình chính xác có thể có của một vấn đề. Chúng ta đã chỉ ra quá trình phân tích
theo từng bước nhỏ; với thực hành, bạn có thể lướt qua vài bước với nhau trong tâm trí của
bạn.

Consortium bankCode
0..1
Bank 1 * Account * 1
Customer
1
1 1
1 1 1 1 * 1

Employs

1 1
Communicates *
Central With Bank
Computer 1 Computer Cashier
*
1 1 1

CommunicatesWith EnteredBy

* * * *
Communicates Cashier EnteredOn Cashier
With Station 1 Transaction
*

*
EnteredOn Remote * *
ATM CashCard
1 Transaction
* * AuthorizedBy 1 *
Hình 12.9 Sơ đồ lớp ban đầu cho hệ thống ATM

12.2.6 Tìm thuộc tính

Tiếp theo là tìm thuộc tính. Thuộc tính là những tính chất dữ liệu của các đối tượng riêng lẻ,
chẳng hạn như trọng lượng, vận tốc hoặc màu sắc. Giá trị thuộc tính không nên là đối tượng;
sử dụng một liên kết để hiển thị bất kỳ mối quan hệ nào giữa hai đối tượng.
Các thuộc tính thường tương ứng với các danh từ theo sau bởi các cụm từ sở hữu, chẳng
hạn như “màu xe” hoặc “vị trí của con trỏ”. Tính từ thường đại diện cho các giá trị thuộc
tính được nhắc cụ thể, chẳng hạn như màu đỏ, đang bật hoặc đã hết hạn. Không giống như
các lớp và liên kết, các thuộc tính ít có khả năng được mô tả đầy đủ trong tuyên bố vấn đề.
Bạn phải dựa trên kiến thức của mình về miền ứng dụng và thế giới thực để tìm thấy chúng.
Bạn cũng có thể tìm thấy các thuộc tính trong các tạo phẩm của các hệ thống liên quan. May
mắn thay, các thuộc tính hiếm khi ảnh hưởng đến cấu trúc cơ bản của vấn đề.
Đừng dung các thuộc tính phát hiện được quá mức. Chỉ xem xét các thuộc tính liên quan
trực tiếp đến ứng dụng. Nhận các thuộc tính quan trọng nhất đầu tiên; bạn có thể thêm các
chi tiết ổn sau này. Trong quá trình phân tích, hãy tránh các thuộc tính chỉ dành cho việc
triển khai. Đảm bảo đặt cho mỗi thuộc tính một tên có ý nghĩa.
 Thông thường, bạn nên bỏ qua các thuộc tính dẫn xuất. Ví dụ: tuổi được lấy từ ngày
sinh và thời gian hiện tại (là một thuộc tính của môi trường). Không thể hiện các thuộc tính
dẫn xuất dưới dạng các phép toán, chẳng hạn như getAge, mặc dù cuối cùng bạn có thể triển
khai chúng theo cách đó.
Cũng như tìm kiếm các thuộc tính trên các liên kết. Một thuộc tính như vậy là tính chất
của liên kết giữa hai đối tượng, chứ không phải là thuộc tính của một đối tượng riêng lẻ. Ví
dụ: liên kết nhiều-nhiều giữa Cổ đông và Công ty có thuộc tính số lượng sở hữu.

12.2.7 Giữ thuộc tính đúng

Loại bỏ những thuộc tính sai và không cần thiết với những tiêu chuẩn dưới đây.
■ Đối tượng. Nếu sự tồn tại độc lập của một phần tử là quan trọng, thay vì chỉ là giá trị, nó
là một đối tượng. Ví dụ, Chủ thích hợp làm lớp và Lương là một thuộc tính. Sự khác
biệt thường phụ thuộc vào ứng dụng. Ví dụ, trong một danh sách thư tín Thành phố có
thể được xem xét là thuộc tính, trong khi ở điều tra dân số Thành phố sẽ là một lớp với
nhiều thuộc tính và quan hệ của riêng nó. Một phần tử có các tính năng của riêng nó
trong ứng dụng nhất định là một lớp.
■ Đạt chuẩn. Nếu giá trị của một thuộc tính phụ thuộc vào một ngữ cảnh cụ thể, thì hãy
xem xét việc đặt lại thuộc tính đó dưới dạng đạt chuẩn. Ví dụ: Số lượng nhân viên
không phải là thuộc tính duy nhất của một người có hai công việc; nó đủ điều kiện cho
liên kết Công ty thuê người.
■ Tên gọi. Tên thường được mô hình hóa tốt hơn dưới dạng đạt chuẩn hơn là thuộc tính.
Thử nghiệm: Tên có chọn các đối tượng duy nhất từ một bộ không? Một đối tượng
trong tập hợp có thể có nhiều tên không? Nếu vậy, tên đạt chuẩn một liên kết đủ điều
kiện. Nếu một cái tên dường như là duy nhất trên thế giới, bạn có thể đã bỏ lỡ lớp đạt
chuẩn. Ví dụ: tên bộ phận có thể là duy nhất trong một công ty, nhưng cuối cùng
chương trình có thể cần phải xử lý nhiều hơn một công ty. Tốt hơn là ngay lập tức sử
dụng một liên kết đạt chuẩn.
Tên là một thuộc tính khi việc sử dụng nó không phụ thuộc vào ngữ cảnh, đặc biệt
khi nó không cần phải là duy nhất trong một tập hợp nào đó. Tên của người, không
giống như tên của các công ty, có thể bị trùng lặp và do đó là thuộc tính.
■ Định danh. Các ngôn ngữ hướng đối tượng kết hợp khái niệm về một đối tượng định
danh để tham chiếu rõ ràng một đối tượng. Không bao gồm một thuộc tính có mục đích
duy nhất là xác định một đối tượng, vì các đối tượng định danh được ẩn trong các mô
hình lớp. Chỉ liệt kê các thuộc tính tồn tại trong miền ứng dụng. Ví dụ: Mã tài khoản là
một thuộc tính xác thật; Các ngân hàng chỉ định Mã tài khoản và khách hàng nhìn thấy
chúng. Ngược lại, bạn không nên liệt kê một ID giao dịch nội bộ như một thuộc tính,
mặc dù có thể thuận tiện để tạo một ID trong quá trình triển khai.
■ Thuộc tính trong liên kết. Nếu một giá trị yêu cầu sự hiện diện của một liên kết, thì
thuộc tính là một thuộc tính của liên kết chứ không phải của một lớp liên quan. Các
thuộc tính thường rõ ràng trên các liên kết nhiều-nhiều; chúng không thể được gắn vào
một trong hai lớp vì sự đa dạng của chúng. Ví dụ: trong liên kết giữa Người và Câu lạc
bộ, thuộc tính membershipDate thuộc về liên kết, bởi vì một người có thể thuộc về
nhiều câu lạc bộ và một câu lạc bộ có thể có nhiều thành viên. Các thuộc tính tinh tế
186 Chương 12 / Phân Tích Miền

hơn trên các liên kết một-nhiều bởi vì chúng có thể được gắn vào lớp “nhiều” mà
không làm mất thông tin. Kháng cự sự thôi thúc gắn chúng vào các lớp, vì chúng sẽ
không hợp lệ nếu bội số thay đổi. Các thuộc tính cũng tinh tế trên các liên kết một đối
một.
■ Giá trị nội tại. Nếu một thuộc tính mô tả trạng thái bên trong của một đối tượng là vô
hình bên ngoài đối tượng, sau đó loại bỏ nó khỏi phân tích.
■ Chi tiết tốt. Bỏ qua các thuộc tính nhỏ không có khả năng ảnh hưởng đến hầu hết các
hoạt động.
■ Thuộc tính không phù hợp. Một thuộc tính dường như hoàn toàn khác và không liên
quan đối với tất cả các thuộc tính khác có thể chỉ ra một lớp nên được chia thành hai
lớp riêng biệt. Một lớp nên đơn giản và mạch lạc. Trộn lẫn các lớp riêng biệt với nhau
là một trong những nguyên nhân chính gây ra các mô hình rắc rối. Các lớp không tập
trung thường dẫn đến sớm xem xét các quyết định thực hiện trong quá trình phân tích.
■ Thuộc tính Boolean. Xem xét lại tất cả các thuộc tính boolean. Thường thì bạn có thể mở
rộng một thuộc tính boolean và trình bày lại nó dưới dạng liệt kê [Coad-95].
Ví dụ ATM. Chúng tôi áp dụng các tiêu chí này để có được các thuộc tính cho mỗi lớp
(Hình 12.10). Một số thuộc tính dự kiến thực sự là đạt chuẩn trên các liên kết. Chúng tôi
xem xét một số khía cạnh của mô hình.
■ BankCode và cardCode hiện diện trên thẻ. Định dạng của chúng là một chi tiết triển khai,
nhưng chúng tôi phải thêm một liên kết mới Ngân hàng phát hành Thẻ rút tiền.
CardCode là một lớp về liên kết này; bankCode là tiêu chuẩn của Ngân hàng đối với
Consortium.
■ Các máy tính không có trạng thái liên quan đến vấn đề này. Cho dù máy đang mở hay tắt
là một thuộc tính tạm thời là một phần của quá trình triển khai.
■ Tránh bị cám dỗ bỏ qua Consortium, mặc dù nó hiện là duy nhất. Nó cung cấp bối cảnh
cho bộ định tính bankCode và có thể hữu ích cho việc mở rộng trong tương lai.

Hãy nhớ rằng vấn đề ATM chỉ là một ví dụ. Các ứng dụng thực tế, khi được bổ sung, có xu
hướng có nhiều thuộc tính hơn cho mỗi lớp so với Hình 12.10 cho thấy.

12.2.8 Tinh Chỉnh Với Kế Thừa

Bước tiếp theo là tổ chức các lớp bằng cách sử dụng tính kế thừa để chia sẻ cấu trúc chung.
Kế thừa có thể được bổ sung theo hai hướng: bằng cách khái quát hóa các khía cạnh chung
của các lớp hiện có thành một lớp cha (từ dưới lên) hoặc bằng cách chuyên biệt hóa các lớp
hiện có thành nhiều lớp con (từ trên xuống).
■ Khái quát hóa từ dưới lên. Bạn có thể khám phá sự kế thừa từ dưới lên bằng cách tìm
kiếm các lớp có thuộc tính, liên kết và hoạt động tương tự. Đối với mỗi khái quát hóa,
hãy xác định một siêu lớp để chia sẻ các tính năng chung. Bạn có thể phải xác định lại
một chút một số thuộc tính hoặc lớp để phù hợp. Điều này có thể chấp nhận được,
nhưng đừng quá cố gắng nếu nó không phù hợp; bạn có thể có sự khái quát hóa sai.
Một số khái quát sẽ gợi ý dựa trên phân loại hiện có trong thế giới thực; sử dụng các
khái niệm hiện có bất cứ khi nào có thể. Tính đối xứng sẽ gợi ý các lớp còn thiếu.
 Hình 12.10 Mô hình lớp ATM với các thuộc tính

Ví dụ ATM. RemoteTransaction và CashierTransaction tương tự nhau, ngoại trừ

trong sự khởi đầu của chúng và có thể được khái quát hóa bằng Transaction. Mặt khác,
CentralComputer và BankComputer có ít điểm chung cho các mục đích của ví dụ
ATM.
■ Chuyên môn hóa từ trên xuống. Chuyên môn hóa từ trên xuống thường rõ ràng từ miền
ứng dụng. Tìm các cụm danh từ bao gồm các tính từ khác nhau trên lớp tên gọi: đèn
huỳnh quang, đèn sợi đốt; menu cố định, menu bật lên, menu trượt. Tránh trau chuốt
quá mức. Nếu các chuyên ngành được đề xuất không tương thích với một lớp hiện có,
thì lớp hiện có có thể được xây dựng không đúng cách.
■ Khái quát hóa so với liệt kê. Các trường hợp con được liệt kê trong miền ứng dụng là
nguồn chuyên môn hóa thường xuyên nhất. Thông thường, chỉ cần lưu ý rằng một tập
hợp các liệt kê các trường hợp con tồn tại, mà không thực sự liệt kê chúng. Ví dụ: tài
khoản ATM có thể được tinh chỉnh thành Tài khoản kiểm tra và Tài khoản tiết kiệm.
186 Chương 12 / Phân Tích Miền

Trong khi chắc chắn hữu ích trong một số ứng dụng ngân hàng, sự khác biệt này không
ảnh hưởng đến hành vi trong ứng dụng ATM; type có thể được tạo thành một thuộc tính
đơn giản của Tài khoản.
■ Đa kế thừa. Bạn có thể sử dụng đa kế thừa để tăng khả năng chia sẻ, nhưng chỉ khi cần
thiết, vì nó làm tăng cả độ phức tạp về khái niệm và triển khai.
■ Các liên kết tương tự. Khi cùng một tên liên kết xuất hiện nhiều lần với về cơ bản là
cùng một ý nghĩa, cố gắng khái quát hóa các lớp liên quan. Đôi khi các lớp không có
điểm chung nào ngoài sự liên kết, nhưng thường thì bạn sẽ phát hiện ra một tính tổng
quát cơ bản mà bạn đã bỏ qua.
Ví dụ ATM. Giao dịch được nhập trên cả CashierStation và ATM; EntryStation
khái quát hóa CashierStation và ATM.
■ Điều chỉnh mức thừa kế. Bạn phải gán thuộc tính và liên kết cho cụ thể các lớp trong hệ
thống phân cấp lớp. Chỉ định mỗi người vào lớp tổng quát nhất mà nó là phù hợp. Bạn
có thể cần một số điều chỉnh để có được mọi thứ đúng. đối xứng có thể đề xuất các
thuộc tính bổ sung để phân biệt giữa các lớp con rõ ràng hơn.
Hình 12.11 thể hiện mô hình lớp ATM sau khi thêm tính kế thừa.

12.2.9 Kiểm tra đường dẫn truy cập

Theo dõi các đường dẫn truy cập thông qua mô hình lớp để xem liệu chúng có mang lại kết
quả hợp lý hay không. Nơi một giá trị duy nhất được mong đợi, có đường dẫn mang lại kết
quả duy nhất không? Đối với bội số "nhiều" là có cách nào để chọn ra các giá trị duy nhất
khi cần không? Hãy nghĩ về những câu hỏi mà bạn có thể muốn hỏi. Có những câu hỏi hữu
ích mà không thể trả lời? Họ chỉ ra thông tin còn thiếu. Nếu một cái gì đó có vẻ đơn giản
trong thế giới thực lại phức tạp trong mô hình, bạn có thể đã bỏ lỡ điều gì đó (nhưng hãy
đảm bảo rằng sự phức tạp không cố hữu trong thế giới thực).
Có thể chấp nhận việc có các lớp bị “ngắt kết nối” với các lớp khác. Điều này
thường xảy ra khi mối quan hệ giữa một lớp bị ngắt kết nối và phần còn lại của lớp mô hình
là khuếch tán. Tuy nhiên, hãy kiểm tra các lớp bị ngắt kết nối để đảm bảo bạn không bỏ qua
bất kỳ những gì có liên quan.
Ví dụ ATM. Bản thân thẻ tiền mặt không xác định duy nhất một tài khoản, vì vậy
người dùng phải chọn một tài khoản bằng cách nào đó. Nếu người dùng cung cấp một loại
tài khoản (tiết kiệm hoặc séc), mỗi thẻ có thể sử dụng tối đa một tài khoản tiết kiệm và một
tài khoản séc. Điều này có thể hợp lý và nhiều thẻ tiền mặt thực sự hoạt động theo cách này,
nhưng nó hạn chế hệ thống. giải pháp thay thế là để yêu cầu khách hàng nhớ số tài khoản.
Nếu thẻ tiền mặt truy cập vào một tài khoản, sau đó chuyển giữa các tài khoản là không thể.
Chúng ta đã giả định rằng mạng ATM phục vụ cho một nhóm ngân hàng duy nhất.
tiền thật máy móc ngày nay thường phục vụ mạng lưới ngân hàng chồng chéo và chấp nhận
thẻ tín dụng cũng như thẻ tiền mặt. Mô hình sẽ phải được mở rộng để xử lý tình huống đó.
chúng tôi sẽ giả định rằng khách hàng hài lòng với giới hạn này trên hệ thống.

12.2.10 Lặp Lại Mô Hình Lớp

Một mô hình lớp hiếm khi chính xác chỉ sau một lần thử. Toàn bộ quy trình phát triển phần
mềm là một quá trình lặp đi lặp lại liên tục; các phần khác nhau của một mô hình thường ở
các giai đoạn khác nhau trong quá trình hoàn thiện. Nếu thấy thiếu sót, hãy quay lại giai
đoạn trước đó nếu việc sửa là cần thiết . Một số tinh chỉnh chỉ có thể tinh chỉnh khi hoàn
thành các mô hình trạng thái và tương tác.
Có một số dấu hiệu của sự thiếu sót lớp.

Hình 12.11 Mô hình lớp ATM với các thuộc tính và kế thừa

■ Bất đối xứng trong các liên kết và khái quát hóa. Thêm các lớp mới bằng cách tương
tự.
■ Phân biệt các thuộc tính và hoạt động trên một lớp. Tách một lớp để mỗi phần được
mạch lạc.
■ Khó khăn trong việc khái quát hóa một cách rõ ràng. Một lớp có thể đóng hai vai trò.
Tách nó ra và sau đó một vai trò có thể đáp ứng hợp lý.
186 Chương 12 / Phân Tích Miền

■ Các liên kết trùng lặp có cùng tên và mục đích. Tổng quát hóa để tạo siêu lớp còn thiếu
để hợp nhất các liên kết.
■ Một vai trò định hình ngữ nghĩa cho một lớp. Có lẽ nó nên là một lớp riêng biệt. Điều
này thường có nghĩa là chuyển đổi một liên kết thành một lớp. Ví dụ, một người có thể
được tuyển dụng bởi một số công ty với các điều kiện làm việc khác nhau tại mỗi công ty;
Sau đó, nhân viên là một lớp biểu thị một người làm việc cho một công ty cụ thể, bên cạnh
lớp Person và Company.
Cũng tìm kiếm các liên kết bị thiếu.
■ Thiếu đường dẫn truy cập cho các hoạt động. Thêm các liên kết mới để bạn có thể trả
lời các truy vấn.
Một mối quan tâm khác là các yếu tố mô hình không cần thiết.
■ Thiếu các thuộc tính, hoạt động và liên kết trên một lớp. Tại sao lớp là cần thiết?
Tránh sản sinh ra các lớp con chỉ để biểu thị một phép liệt kê. Nếu các lớp con được đề
xuất giống hệt nhau, hãy đánh dấu sự khác biệt bằng cách sử dụng một thuộc tính.
■ Thông tin dư thừa. Xóa các liên kết không thêm thông tin mới hoặc đánh dấu chúng là đã
có nguồn gốc.
Và cuối cùng, bạn có thể điều chỉnh vị trí của các thuộc tính và liên kết.
■ Tên kết thúc liên kết quá rộng hoặc quá hẹp đối với các lớp của chúng. Di chuyển liên
kết lên hoặc xuống trong hệ thống phân cấp lớp.
■ Cần truy cập một đối tượng bằng một trong các giá trị thuộc tính của nó. Hãy xem
xét một liên kết đủ điều kiện.
Trong thực tế, việc xây dựng mô hình không được sắp xếp theo thứ tự cứng nhắc như chúng
tôi đã chỉ ra. Bạn có thể kết hợp nhiều bước khi đã có kinh nghiệm. Ví dụ, bạn có thể tìm các
lớp thành phần, loại bỏ những lớp không đúng mà không cần viết chúng ra và thêm chúng
vào sơ đồ lớp cùng với các liên kết của chúng. Bạn có thể thực hiện một số phần của mô
hình qua một số bước và phát triển chúng một cách chi tiết, trong khi các phần khác vẫn còn
sơ sài. Bạn có thể trao đổi thứ tự các bước khi thích hợp. Tuy nhiên, nếu bạn chỉ đang học
mô hình hóa trên lớp học, chúng tôi khuyên bạn nên làm theo các bước một cách chi tiết đầy
đủ trong vài lần đầu tiên.
Ví dụ ATM. CashCard thực sự có một tính cách riêng biệt—nó vừa là một đơn vị được
ủy quyền trong ngân hàng cho phép truy cập vào tài khoản của khách hàng, vừa là một phần
dữ liệu nhựa mà máy ATM đọc để lấy ID được mã hóa. Trong trường hợp này, các mã thực
sự là một phần của thế giới thực, không chỉ là các tạo tác máy tính; các mã, không phải thẻ
rút tiền, được truyền tới máy tính trung tâm. Chúng tôi nên chia thẻ tiền mặt thành hai loại:
CardAuthorization, quyền truy cập vào một hoặc nhiều tài khoản khách hàng; và CashCard,
một miếng nhựa có chứa mã ngân hàng và số thẻ tiền mặt có ý nghĩa đối với ngân hàng. Mỗi
ủy quyền thẻ có thể có nhiều thẻ rút tiền, mỗi thẻ có một số sê-ri vì lý do bảo mật. Mã thẻ,
xuất hiện trên thẻ vật lý, xác định ủy quyền thẻ trong ngân hàng. Mỗi ủy quyền thẻ xác định
một hoặc nhiều tài khoản—ví dụ: một tài khoản séc và một tài khoản tiết kiệm.
Giao dịch không đủ tổng quát để cho phép chuyển giữa các tài khoản vì nó chỉ liên quan
đến một tài khoản. Nói chung, một giao dịch bao gồm một hoặc nhiều cập nhật trên các tài
khoản cá nhân. Cập nhật là một hành động đơn lẻ (rút tiền, gửi tiền hoặc truy vấn) trên một
tài khoản. Tất cả các cập nhật trong một giao dịch phải được xử lý cùng nhau dưới dạng một
đơn vị nguyên tử; nếu bất kỳ cái nào không thành công, thì tất cả chúng đều bị hủy bỏ.
 Sự khác biệt giữa Bank và BankComputer và giữa Consortium và CentralComputer
dường như không ảnh hưởng đến phân tích. Thực tế là các thông tin liên lạc được xử lý bởi
máy tính thực sự là một tạo phẩm triển khai. Hợp nhất BankComputer thành Bank và
CentralComputer thành Consortium.
Customer dường như không tham gia vào phân tích cho đến nay. Tuy nhiên, khi chúng
tôi xem xét các hoạt động để mở tài khoản mới, nó có thể là một khái niệm quan trọng, vì
vậy hãy để nó yên vào lúc này.
Hình 12.12 cho thấy một sơ đồ lớp đã được sửa đổi đơn giản và rõ ràng hơn.

Hình 12.12 Mô hình lớp ATM sau khi chỉnh sửa thêm

12.2.11 Chuyển đổi mức độ trừu tượng

Cho đến nay trong phân tích, chúng tôi đã thực hiện báo cáo vấn đề theo đúng nghĩa
đen. Chúng tôi đã coi các danh từ và động từ trong phần mô tả vấn đề là những từ tương tự
trực tiếp của các lớp và các liên kết. Đây là một cách tốt để bắt đầu phân tích, nhưng không
phải lúc nào cũng đầy đủ. Đôi khi bạn phải nâng cao mức độ trừu tượng để giải quyết vấn
đề. Bạn nên làm điều này xuyên suốt khi xây dựng mô hình, nhưng chúng tôi đưa ra một
trình tự rõ ràng để đảm bảo bạn không bỏ qua tính trừu tượng.
186 Chương 12 / Phân Tích Miền

Ví dụ: chúng tôi đã gặp một ứng dụng trong đó các nhà phát triển có các lớp riêng biệt
cho IndividualContributor(Người đóng góp cá nhân), Supervisor(Người giám sát), and
Manager(Người quản lý). IndividualContributors báo cáo cho Supervisors và Supervisors
báo cáo cho Managers. Mô hình này chắc chắn là đúng, nhưng nó có một số vấn đề. Có
nhiều điểm chung giữa ba lớp—sự khác biệt duy nhất là hệ thống phân cấp báo cáo. Ví dụ,
tất cả họ đều có số điện thoại và địa chỉ. Chúng tôi có thể xử lý điểm chung với một lớp cha,
nhưng điều đó chỉ làm cho mô hình lớn hơn. Một vấn đề khác phát sinh khi chúng tôi nói
chuyện với các nhà phát triển và họ nói rằng họ muốn thêm một lớp khác cho những người
mà người quản lý đã báo cáo.

Hình 12.13 cho thấy mô hình ban đầu và một mô hình cải tiến trừu tượng hơn. Thay vì
“mã hóa cứng” hệ thống phân cấp quản lý trong mô hình, chúng tôi có thể “mã hóa mềm” nó
với sự liên kết giữa sếp và nhân viên. Một người có employeeType là “individual-
Contributor” là nhân viên báo cáo cho người khác có employeeType là “supervisor”. Tương
tự, một Supervisor báo cáo cho một Manager. Trong mô hình cải tiến, một nhân viên có một
ông chủ tùy chọn, vì hệ thống phân cấp báo cáo cuối cùng cũng dừng lại. Mô hình cải tiến
nhỏ hơn và linh hoạt hơn. Mức báo cáo bổ sung không thay đổi cấu trúc của mô hình; nó chỉ
làm thay đổi dữ liệu được lưu trữ.

Mô hình nguyên bản Mô hình cải tiến trừu tượng hơn

Hình 12.13 Chuyển đổi mức độ trừu tượng. Tính trừu tượng làm cho mô hình trở nên
phức tạp hơn nhưng có thể tăng tính linh hoạt và làm giảm số lớp.

Một cách mà bạn có thể tận dụng sự trừu tượng là suy nghĩ theo các mẫu. Các loại mẫu
khác nhau áp dụng cho các giai đoạn phát triển khác nhau, nhưng ở đây chúng tôi quan tâm
đến các mẫu để phân tích. Một mô hình chắt lọc kiến thức của các chuyên gia và cung cấp
một giải pháp đã được chứng minh cho một vấn đề chung. Ví dụ, phía bên phải của Hình
12.13 là một mẫu để lập mô hình phân cấp quản lý. Bất cứ khi nào chúng tôi gặp phải nhu
cầu về một hệ thống phân cấp quản lý, chúng tôi ngay lập tức nghĩ đến mô hình trên và đặt
nó vào mô hình ứng dụng của chúng tôi. Việc sử dụng các mẫu đã được thử và chứng minh
mang lại cho chúng tôi sự tự tin về cách tiếp cận hợp lý và tăng năng suất của chúng tôi
trong việc xây dựng các mô hình.
 Ví dụ về máy ATM. Chúng tôi đã bao hàm một số khái niệm trừu tượng trong mô hình
ATM. Chúng tôi phân biệt giữa CashCard và CardAuthorization. Hơn nữa, chúng tôi đã đưa
vào khái niệm giao dịch thay vì cố gắng liệt kê từng loại tương tác có thể có.
12.2 Mô Hình Lớp Miền 183

12.2.12 Nhóm các lớp thành các gói

Bước cuối cùng của mô hình hóa lớp là nhóm các lớp thành các gói. Một gói là một nhóm
các phần tử (các lớp, liên kết, khái quát hóa và các gói nhỏ hơn) với một chủ đề chung. Các
gói thực hiện tổ chức một mô hình để thuận tiện cho việc vẽ, in và xem. Hơn nữa, khi bạn
đặt các lớp và các liên kết trong một gói, bạn đang thực hiện một tuyên bố ngữ nghĩa. Nói
chung, các lớp trong cùng một gói có liên quan chặt chẽ hơn so với các lớp trong các gói
khác nhau.
Thông thường, bạn nên giới hạn mỗi liên kết trong một gói duy nhất, nhưng bạn có thể
lặp lại một số lớp trong các gói khác nhau. Để gán các lớp cho các gói, hãy tìm các điểm
giao— điểm giao là một lớp là kết nối duy nhất giữa hai phần bị tách rời khác của một mô
hình. Một lớp như vậy tạo thành cầu nối giữa hai gói. Ví dụ: trong một hệ thống quản lý file,
File là điểm giao giữa cấu trúc thư mục và nội dung file. Cố gắng chọn các gói để giảm số
lượng chồng chéo trong sơ đồ lớp. Với một chút cẩn thận, bạn có thể vẽ hầu hết các sơ đồ
lớp dưới dạng đồ thị phẳng mà không cần cắt các đường thẳng.
Sử dụng lại gói từ thiết kế trước đó nếu có thể, nhưng tránh ép buộc vừa vặn. Việc sử
dụng lại dễ dàng nhất khi một phần của miền sự cố khớp với sự cố trước đó. Nếu vấn đề mới
tương tự như vấn đề trước nhưng có điểm khác, bạn có thể phải mở rộng mô hình ban đầu để
bao gồm cả hai vấn đề. Sử dụng đánh giá của bạn về việc liệu điều này có tốt hơn việc xây
dựng một mô hình mới hay không.
Ví dụ ATM. Mô hình hiện tại nhỏ và sẽ không yêu cầu chia thành các gói, nhưng nó có thể
đóng vai trò là cốt lõi cho một mô hình chi tiết hơn. Các gói có thể là:
■ các giao dịch viên—thu ngân, trạm nhập cảnh, trạm thu ngân, ATM
■ các tài khoản—tài khoản, thẻ rút tiền, ủy quyền thẻ, khách hàng, giao dịch, cập nhật, giao
dịch thu ngân, giao dịch từ xa
■ các ngân hàng—tập đoàn, ngân hàng

Mỗi gói có thể có thêm chi tiết. Gói tài khoản có thể bao gồm nhiều loại giao dịch, thông tin
về khách hàng, thanh toán lãi và phí. Gói ngân hàng có thể chứa thông tin về chi nhánh, địa
chỉ và phân bổ chi phí.

12.3 Mô Hình Lớp Miền

Một số đối tượng miền đi qua các trạng thái khác biệt về chất trong suốt vòng đời của chúng.
Ở đó có thể là các ràng buộc khác nhau đối với các giá trị thuộc tính, các liên kết hoặc bội số
khác nhau trong các trạng thái khác nhau, các hoạt động khác nhau có thể được gọi, hành vi
khác nhau của các hoạt động, và như thế. Nó thường hữu ích để xây dựng một sơ đồ trạng
thái của một lớp miền như vậy. Nhà nước sơ đồ mô tả các trạng thái khác nhau mà đối tượng
có thể đảm nhận, các thuộc tính và ràng buộc của đối tượng ở các trạng thái khác nhau và
các sự kiện đưa đối tượng từ trạng thái này sang trạng thái khác.
Hầu hết các lớp miền không yêu cầu sơ đồ trạng thái và có thể được mô tả đầy đủ
bằng một danh sách các hoạt động. Tuy nhiên, đối với thiểu số các lớp thể hiện các trạng thái
riêng biệt, một trạng thái mô hình có thể giúp hiểu được hành vi của họ.
184 Chương 12 / Phân Tích Miền

Đầu tiên xác định các lớp miền với các trạng thái quan trọng và lưu ý các trạng thái
của mỗi lớp. Sau đó xác định các sự kiện đưa một đối tượng từ trạng thái này sang trạng thái
khác. Với các trạng thái và các sự kiện, bạn có thể xây dựng sơ đồ trạng thái cho các đối
tượng bị ảnh hưởng. Cuối cùng, đánh giá trạng thái sơ đồ để đảm bảo chúng đầy đủ và chính
xác.
Các bước sau đây được thực hiện trong việc xây dựng mô hình trạng thái miền.
■ Xác định các lớp miền với các trạng thái. [12.3.1]
■ Tìm trạng thái. [12.3.2]
■ Tìm sự kiện. [12.3.3]
■ Xây dựng biểu đồ trạng thái. [12.3.4]
■ Đánh giá sơ đồ trạng thái. [12.3.5]
12.2 Mô Hình Lớp Miền 185

12.3.1 Xác Định Lớp Trạng Thái

Kiểm tra danh sách các lớp miền cho những lớp có vòng đời riêng biệt. Tìm kiếm các lớp có
thể được đặc trưng bởi một lịch sử tiến bộ hoặc thể hiện hành vi tuần hoàn. Xác định các
trạng thái quan trọng trong vòng đời của đối tượng. Ví dụ: bài báo khoa học cho tạp chí
Being written to Under consideration to Accepted or Rejected. Có thể có một số vòng tuần
hoàn nếu người đánh giá có thể yêu cầu sửa đổi, nhưng về cơ bản, vòng tuần hoàncủa đối
tượng này là lũy tiến. Mặt khác, một chiếc máy bay thuộc sở hữu của một hãng hàng không
sẽ trải qua các trạng thái Bảo dưỡng, Xếp hàng, Bay và Dỡ hàng. Không phải mọi trạng thái
đều xảy ra trong mọi chu kỳ và có thể có các trạng thái khác, nhưng vòng đời của đối tượng
này là theo chu kỳ. Cũng có những lớp có vòng đời hỗn loạn, nhưng hầu hết các lớp có trạng
thái là lũy tiến hoặc tuần hoàn.
Ví dụ ATM. Tài khoản là một khái niệm kinh doanh quan trọng và hành vi thích
hợp với máy ATM phụ thuộc vào trạng thái của Tài khoản. Vòng đời của Tài khoản là sự
kết hợp giữa tiến trình và chu kỳ đến và đi từ các trạng thái của vấn đề. Không có lớp ATM
nào khác có mô hình trạng thái miền quan trọng như thế.

12.3.2 Tìm Trạng Thái

Liệt kê các trạng thái của từng lớp. Đặc trưng hóa các đối tượng trong mỗi lớp (Các giá trị
thuộc tính mà đối tượng có thể có, các liên kết mà nó có thể tham gia và tính đa dạng của
chúng, các thuộc tính và liên kết chỉ có ý nghĩa trong các trạng thái nhất định, v.v). Đặt cho
mỗi trạng thái cái tên có ý nghĩa. Tránh những cái tên chi trạng thái hình thành như thế nào;
cố gắng mô tả trực tiếp trạng thái.
Đừng tập trung vào sự khác biệt nhỏ giữa các trạng thái, đặc biệt là sự khác biệt về
số lượng, chẳng hạn như nhỏ, trung bình hoặc lớn. Các trạng thái nên dựa trên sự khác biệt
về chất trong hành vi, thuộc tính hoặc liên kết.
Không cần thiết phải xác định tất cả các trạng thái trước khi kiểm tra các sự kiện.
Bằng cách xem xét các sư kiện và xem xét quá trình chuyển đổi giữa các trạng thái, các
trạng thái còn thiếu sẽ trở nên rõ ràng.
Ví dụ ATM. Dưới đây là một số trạng thái của Tài khoản: Bình thường (sẵn sàng
truy cập bình thường), Đã Đóng (do khách hàng đóng tài khoản nhưng vẫn được lưu trong
hồ sơ ngân hàng), Rút Tiền Vượt Giới Hạn (số tiền khách hàng rút vượt quá số dư trong tài
khoản) và Bị Tạm Ngưng (quyền truy cập vào tài khoản tài khoản bị chặn vì một số lý do).

12.3.3 Tìm Sự Kiện

Khi bạn có một tập hợp sơ bộ các trạng thái, hãy tìm các sự kiện gây ra sự thay đổi giữa các
trạng thái. Hãy nghĩ về các tác nhân khiến trạng thái thay đổi. Trong nhiều trường hợp, bạn
có thể coi một sự kiện là hoàn thành một hành động. Ví dụ, nếu một bài báo kỹ thuậtở trạng
thái Đang Xem Xét, thì trạng thái đó sẽ chấm dứt khi đạt được quyết định về bài báo. Trong
trường hợp này, quyết định có thể là tích cực (Giấy chấp thuận) hoặc tiêu cực (Giấy từ
chuối). Trong trường hợp hoàn thành một hoạt động, các khả năng khác thường có thể xảy
ra và có thể được thêm vào trong tương lai - ví dụ: Chấp nhận với các điều khoản đã được
sửa đổi
186 Chương 12 / Phân Tích Miền

Bạn có thể tìm các sự kiện khác bằng cách suy nghĩ đưa đối tượng vào một trạng
thái cụ thể. Ví dụ: nếu bạn nghe trên điện thoại, nó sẽ chuyển sang trạng thái Đang Nghe.
Nhiều điện thoại có các nút bấm gọi các chức năng cụ thể. Nếu bạn nhấn nút quay số lại,
điện thoại sẽ truyền số và chuyển sang trạng thái Đang gọi. Nếu bạn nhấn nút chương trình,
nó sẽ chuyển sang trạng thái Chương Trình.
Những sự kiện bổ sung có thể xảy ra trong trạng thái và không gây ra chuyển đổi.
Đối với mô hình trạng thái miền, bạn nên tập trung vào các sự kiện gây ra sự chuyển tiếp
giữa các trạng thái. Khi bạn phát hiện ra một sự kiện, hãy nắm bắt mọi thông tin mà sự kiện
đó truyền tải dưới dạng danh sách các tham số.
Ví dụ ATM. Các sự kiện quan trọng bao gồm: đóng tài khoản, rút tiền thừa, nhập
sai mã PIN nhiều lần, nghi ngờ gian lận và hành động hành chính.

12.3.4 Xây Dựng Sơ Đồ Trạng Thái

Lưu ý các trạng thái sử dụng cho các sự kiện. Thêm các hiệu ứng thay đổi để hiển thị sự thay
đổi trạng thái do sự kiện xảy ra khi một đối tượng ở trạng thái cụ thể. Nếu một sự kiện kết
thúc một trạng thái, nó thường sẽ có một lần chuyển từ trạng thái này sang trạng thái khác.
Nếu một sự kiện bắt đầu một trạng thái được chỉ định, thì hãy xem xét nơi nó có thể xảy ra
và thêm các chuyển tiếp từ các trạng thái đó sang trạng thái chỉ định. Xem xét khả năng sử
dụng một chuyển đổi trên một trạng thái kèm theo hơn là thêm một chuyển đổi từ mỗi trạng
thái con sang trạng thái chỉ định. Nếu một sự kiện có các hiệu ứng khác nhau ở các trạng
thái khác nhau, hãy thêm phần chuyển tiếp cho từng trạng thái.
Sau khi bạn đã xác định các chuyển đổi, hãy xem xét ý nghĩa của sự kiện trong các
trạng thái không có chuyển đổi trong sự kiện. Nó có bị bỏ qua không? Sau đó, mọi thứ đều
ổn. Nó có báo lỗi không? Sau đó, thêm một quá trình chuyển đổi sang trạng thái lỗi. Nó có
tác dụng gì mà bạn quên không? Sau đó, thêm một quá trình chuyển đổi khác. Đôi khi bạn
sẽ khám phá ra những trạng thái mới.
Việc xem xét các hiệu ứng khi xây dựng sơ đồ trạng thái cho một lớp miền thường
không quan trọng. Tuy nhiên, nếu các đối tượng trong lớp thực hiện các hoạt động khi
chuyển đổi, hãy thêm chúng vào sơ đồ trạng thái.
Ví dụ ATM. Hình 12.14 cho thấy mô hình trạng thái miền cho lớp Tài khoản.

12.3.5 Đánh Giá Sơ Đồ Trạng Thái

Kiểm tra từng mô hình trạng thái. Có phải tất cả các trạng thái đã được kết nối? Đặc biệt chú
ý đến các con đường đi qua nó. Nếu nó đại diện cho một lớp cấp cao, thì có một con đường
từ trạng thái ban đầu đến trạng thái cuối cùng không? Có các biến thể dự kiến nào xuất hiện
không? Nếu nó đại diện cho một lớp tuần hoàn, thì vòng lặp chính có xuất hiện không? Có
bất kỳ trạng thái chết nào chấm dứt chu kỳ không?
12.2 Mô Hình Lớp Miền 187

Hình 12.14 Mô hình trạng thái miền. Mô hình trạng thái miền ghi lại những lớp quan
trọng làm thay đổi trạng thái trong thực tế.
Sử dụng kiến thức của bạn về miền để tìm kiếm các đường dẫn bị thiếu. Đôi khi
các đường dẫn bị thiếu chỉ ra các trạng thái bị thiếu. Khi một mô hình trạng thái hoàn thành,
nó sẽ thể hiện chính xác vòng đời của lớp.
Ví dụ ATM. Mô hình trạng thái của chúng tôi cho Tài khoản rất đơn giản nhưng
chúng tôi hài lòng với nó. Chúng tôi sẽ yêu cầu kiến thức ngân hàng đáng kể để xây dựng
một mô hình sâu hơn.

12.4 Mô Hình Tương Tác Miền

Mô hình tương tác hiếm khi quan trọng đối với phân tích miền. Trong quá trình phân tích
miền, trọng tâm là các khái niệm chính và các mối quan hệ cấu trúc sâu sắc chứ không phải
quan điểm của người dùng về chúng. Tuy nhiên, mô hình tương tác là một khía cạnh quan
trọng của mô hình hóa ứng dụng và chúng ta sẽ đề cập đến nó trong chương tiếp theo.
188 Chương 12 / Phân Tích Miền

12.5 Phân Tích Lặp

Hầu hết các mô hình phân tích yêu cầu nhiều hơn một lượt để hoàn thành. Các bản báo cáo
vấn đề thường chứa các biểu đồ tròn và hầu hết các ứng dụng không thể tiếp cận được theo
cách hoàn toàn tuyến tính, bởi vì các phần khác nhau của vấn đề sẽ tương tác với nhau. Để
hiểu một vấn đề với tất cả các hàm ý của nó, bạn phải tập trung phân tích lặp đi lặp lại,
chuẩn bị ước lượng trước cho mô hình và sau đó thực hiện phân tích lặp khi sự hiểu biết của
bạn tăng lên. Không có giới hạn chắc chắn giữa phân tích và thiết kế, vì vậy đừng lạm dụng
nó. Xác minh những điều đã phân tích cuối cùng với người yêu cầu và các chuyên gia.
12.5.1 Hoàn Thiện Mô Hình Phân Tích
Mô hình phân tích tổng thể có thể cho thấy sự không nhất quán và mất cân đối bên trong và
giữa các mô hình. Lặp lại các phần khác nhau để tạo ra một mô hình rõ ràng hơn, mạch lạc
hơn. Cố gắng hoàn thiện các lớp để tăng chia sẻ và cải thiện cấu trúc. Thêm các chi tiết mà
bạn đã bỏ qua trong lần đầu tiên.
Một số cấu trúc sẽ cảm thấy lúng túng và dường như không phù hợp. Xem xét lại
chúng một cách cẩn thận; bạn có thể có những quan điểm sai lệch trong vấn đề. Đôi khi sự
tái cấu trúc lớn trong mô hình là cần thiết khi sự hiểu biết của bạn tăng lên. Việc thực hiện
bây giờ dễ dàng hơn bao giờ hết, vì vậy đừng né tránh các thay đổi chỉ vì bạn đã có sẵn một
mô hình. Khi có nhiều cấu trúc có vẻ giống nhau nhưng không hoàn toàn ăn khớp với nhau,
có thể bạn đã bỏ sót hoặc hiểu sai một khái niệm tổng quát hơn. Cẩn thận xem xét lại những
khái quát hóa dựa trên những khía cạnh sai lầm.
Một khó khăn phổ biến là một đối tượng vật lý có hai khía cạnh logic khác biệt.
Mỗi khía cạnh nên được mô hình hóa với một đối tượng riêng biệt. Dấu hiệu của vấn đề này
là một lớp không phù hợp hoàn toàn và dường như có hai bộ thuộc tính, liên kết và hoạt
động không liên quan với nhau.
Các dấu hiệu khác cần theo dõi bao gồm các ngoại lệ, nhiều trường hợp đặc biệt và
thiếu tính cân đối dự kiến. Cân nhắc tái cấu trúc mô hình của bạn để nắm bắt các ràng buộc
tốt hơn trong cấu trúc của nó.
Hãy thận trọng với việc hệ thống hóa các hoạt động kinh doanh tùy ý trong mô
hình của bạn. Phần mềm nên tạo điều kiện thuận lợi cho hoạt động kinh doanh và không gây
cản trở những thay đổi hợp lý. Thông thường, bạn có thể đưa ra các khái niệm trừu tượng
giúp tăng tính linh hoạt trong kinh doanh mà không làm tang tính phức tạp đáng kể cho mô
hình.
Loại bỏ các lớp hoặc liên kết trông có vẻ hữu ích nhưng bây giờ lại không còn liên
quan. Thường thì hai lớp trong phân tích có thể được kết hợp với nhau, vì sự khác biệt giữa
chúng không ảnh hưởng đến phần còn lại của mô hình theo dẫu cho bất kỳ cách nào. Xu
hướng cho các mô hình phát triển khi tiến hành phân tích. Đây là một vấn đề đáng lo ngại, vì
số lượng công việc phát triển tăng lên khi một mô hình trở nên có kích thước lớn hơn. Hãy
xem xét kỹ mô hình của bạn để biết các khái niệm nhỏ cần được cắt bỏ hoặc các khái niệm
trừu tượng nào có thể đơn giản hóa mô hình.
Một mô hình tốt cho cảm giác đúng và dường như không có chi tiết thừa. Đừng lo
lắng nếu nó có vẻ không hoàn hảo; ngay cả một mô hình tốt thường sẽ có một vài khu vực
nhỏ trong đó thiết kế phù hợp nhưng không bao giờ cảm thấy hoàn toàn phù hợp.
12.2 Mô Hình Lớp Miền 189

12.5.2 Trình Bày Lại Các Yêu Cầu

Khi quá trình phân tích hoàn tất, mô hình sẽ làm cơ sở cho các yêu cầu và xác định giá trị
của bài diễn văn trong tương lai. Phần lớn các yêu cầu thực tế sẽ là một phần của mô hình.
Ngoài ra, bạn có thể gặp một số hạn chế về hiệu suất; những điều này nên được nêu rõ ràng,
cùng với các tiêu chí tối ưu hóa. Nếu có thể. các yêu cầu khác cần chỉ rõ phương pháp giải
quyết và nên được tách ra.
Bạn nên xác nhận lại mô hình đã hoàn thành với người yêu cầu. Trong quá trình
phân tích, một số yêu cầu có thể không chính xác hoặc không thực tế; xác nhận những yêu
cầu sửa chữa. Ngoài ra, các chuyên gia kinh doanh nên xác minh mô hình phân tích để đảm
bảo rằng nó mô hình chính xác thế giới thực. Chúng tôi nhận thấy các mô hình phân tích là
một phương tiện giao tiếp hiệu quả với các chuyên gia kinh doanh không phải là chuyên gia
máy.
Mô hình phân tích hoàn thiện đã được xác minh đóng vai trò là cơ sở cho kiến trúc,
thiết kế và triển khai hệ thống. Bạn nên sửa lại bản báo cáo vấn đề ban đầu để kết hợp các
sửa chữa và hiểu biết được phát hiện trong quá trình phân tích.
12.5.3 Phân Tích Và Thiết Kế
Mục tiêu của phân tích là xác định vấn đề một cách đầy đủ, rõ ràng mà không đưa ra thành
kiến đối với bất kỳ triển khai cụ thể nào, nhưng trong thực tế không thể tránh được mọi sai
sót trong quá trình triển khai. Không có ranh giới tuyệt đối giữa các giai đoạn phát triển
khác nhau, cũng như không có phân tích nào là hoàn hảo. Đừng xem các quy tắc chúng tôi
đã đưa ra quá cứng nhắc. Mục đích của các quy tắc là duy trì tính linh hoạt và cho phép thay
đổi sau này, nhưng hãy nhớ rằng mục tiêu của việc thiết kế mô hình là hoàn thành toàn bộ
công việc và tính linh hoạt cũng chỉ là phương tiện để đạt được mục đích.
Ví dụ ATM. Chúng tôi không có thêm thay đổi nào đối với mô hình ATM vào lúc
này. Một ứng dụng thực tế có nhiều khả năng được sửa đổi hơn so với một ví dụ trong sách
giáo khoa, bởi vì bạn có những người đánh giá có sự thích thú đối với ứng dụng đó và có
quyền lợi nhất định đối với nó.
12.6 Tóm Tắt Chương
Mô hình miền nắm bắt kiến thức chung về khái niệm ứng dụng và các quan hệ được các
chuyên gia trong miền biết. Mô hình miền có mô hình lớp và đôi khi là mô hình trạng thái,
nhưng hiếm khi có mô hình tương tác. Mục đích của phân tích là để hiểu vấn đề và ứng
dụng để có thể xây dựng một bản thiết kế chính xác. Một bản phân tích tốt sẽ nắm bắt được
các đặc điểm thiết yếu của vấn đề mà không đưa ra các sản phẩm còn nhiều hạn chế trong
khâu thiết kế.
Mô hình lớp miền thể hiện cấu trúc tĩnh của thực tế. Đầu tiên tìm các lớp. Sau đó
tìm mối liên hệ giữa các lớp. Lưu ý các đặc tính, mặc dù bạn có thể trì hoãn các đặc tính
nhỏ. Bạn có thể sử dụng khái quát hóa để tổ chức và đơn giản hóa cấu trúc lớp. Các lóp gộp
lại và được liên kết chặt chẽ thành các gói. Bổ sung các mô hình lớp với một mô tả văn bản
ngắn gọn từ điển dữ liệu, bao gồm cả mục đích và phạm vi của từng thành phần.
Nếu một lớp miền có một số trạng thái khác nhau về chất trong vòng đời của nó,
hãy tạo sơ đồ trạng thái cho nó, nhưng hầu hết các lớp miền sẽ không yêu cầu sơ đồ trạng
thái.
190 Chương 12 / Phân Tích Miền

Các phương pháp luận không bao giờ tuyến tính như trong sách. Điều này cũng
không ngoại lệ. Bất kỳ phân tích phức tạp nào cũng được xây dựng bằng cách lặp lại trên
nhiều cấp độ. Bạn không cần phải chuẩn bị tất cả các phần của mô hình với tốc độ như nhau.
Kết quả phân tích thay thế bảo cáo vấn đề ban đầu và làm nền tảng cho thiết kế.