Mô hình hóa ca sử dụng

I, Khái niệm:

- Hành vi của hệ thống là cách hệ thống hoạt động và phản ứng, bao gồm các hành động và hoạt
động của hệ thống
- Hành vi của hệ thống được ghi lại trong các trường hợp sử dụng
- Các ca sử dụng mô tả sự tương tác giữa hệ thống và môi trường của nó

*Mô hình ca sử dụng(Use-Case Model):

- Mô hình mô tả yêu cầu chức năng của hệ thống theo trường hợp sử dụng

- Một mô hình dự định của hệ thống gồm chức năng (trường hợp sử dụng) và môi trường của
nó( Tác nhân)

II, Các khái niệm chính trong use-case

1, Modeling:

Actor: Đại diện cho bất kỳ thực thể nào tương tác với hệ thống (người dung, thiết bị khác, bất kì thứ gì
gửi dữ liệu hoặc yêu cầu đến hệ thống), Actor không phải là một phần của hệ thống (External)

Use case: Mô tả một chuỗi sự kiện do hệ thống thực hiện nhằm mang lại một kết quả, có thể quan sát
được, cho một Actor cụ thể., mô hình cuộc đối thoại giữa một hoặc nhiều tác nhân và hệ thống
III, Biểu đồ ca sử dụng:

- Trong mô hình hóa hệ thống, "Include" là một cách để tận dụng lại các hành động chung giữa
các tình huống sử dụng. Nó cho phép nhúng một chuỗi hành động cụ thể (tình huống sử dụng
con) vào một tình huống sử dụng lớn hơn (tình huống sử dụng chính). Điều thú vị là tình huống
sử dụng con hoàn toàn có thể hoạt động độc lập, riêng biệt khỏi tình huống sử dụng chính.

- Hình ảnh mô tả mối quan hệ Include giữa các trường hợp sử dụng (Use Cases) trong hệ thống
quản lý bán hàng.
- Mối quan hệ Include giúp chia nhỏ Use Case Thanh toán thành các Use Case nhỏ hơn, dễ quản lý
và tái sử dụng.
- Xác thực thanh toán và Ghi nhận thanh toán là các chức năng phụ, cần thiết cho Thanh toán
nhưng có thể được sử dụng trong các Use Case khác.
- Việc sử dụng Include giúp tăng tính mô đun cho hệ thống, dễ dàng bảo trì và mở rộng.

- Trong mô hình hóa hệ thống, khái niệm "Tổng quát hóa" thể hiện mối quan hệ cha-con giữa các tình
huống sử dụng. Tình huống sử dụng tổng quát hơn đại diện cho các chức năng chung, trong khi tình
huống sử dụng chuyên biệt hơn mô tả các chức năng cụ thể hơn kế thừa từ tình huống sử dụng tổng
quát. Giống như di truyền, tình huống sử dụng đặc biệt "thừa hưởng" tất cả các thuộc tính (tính năng) từ
tình huống sử dụng tổng quát. Tuy nhiên, tình huống sử dụng đặc biệt có thể "bổ sung thêm các thuộc
tính mới" hoặc "thay thế các thuộc tính" hiện có để đáp ứng nhu cầu cụ thể của nó.

Biểu đồ mô tả mối quan hệ giữa các trường hợp sử dụng trong hệ thống đặt vé máy bay. Mối quan hệ
"cha-con" giúp tái sử dụng các chức năng chung và thể hiện các chức năng riêng của từng trường hợp sử
dụng đặc biệt.

. Generalization (Tổng quát hóa):

Mối quan hệ cha-con giữa các trường hợp sử dụng.

Hủy vé là trường hợp sử dụng tổng quát.

Hủy vé phút chót và Hủy vé thông thường là các trường hợp sử dụng đặc biệt kế thừa từ Hủy vé.

2. Special Use Case (Trường hợp sử dụng đặc biệt):

Kế thừa từ trường hợp sử dụng tổng quát và có thêm các đặc điểm riêng.

Hủy vé phút chót:

Kế thừa các bước cơ bản từ Hủy vé.

Có thêm các bước như:

Phí phạt hủy vé.

Xác nhận lại với khách hàng.

Hủy vé thông thường:

Kế thừa các bước cơ bản từ Hủy vé.

Không có thêm bước nào so với Hủy vé.

3. Cancel Last Minute (Hủy vé phút chót):

Là trường hợp sử dụng đặc biệt của Hủy vé.

Áp dụng cho việc hủy vé sát giờ bay.

Có thêm các bước và quy trình riêng so với Hủy vé thông thường.

4. Special Use Case (Trường hợp sử dụng đặc biệt):

Hủy vé thông thường:

Là trường hợp sử dụng đặc biệt của Hủy vé.

Áp dụng cho việc hủy vé trước giờ bay một khoảng thời gian nhất định.

Không có thêm bước nào so với Hủy vé.

Biểu đồ thể hiện:

Mối quan hệ "cha-con" giữa các trường hợp sử dụng.

Các trường hợp sử dụng đặc biệt kế thừa các chức năng từ trường hợp sử dụng tổng quát và có thêm
các chức năng riêng.

Ví dụ:

Khách hàng muốn hủy vé máy bay đã đặt.

Hệ thống sẽ xác định loại hủy vé dựa trên thời gian hủy so với giờ bay.

Nếu hủy vé sát giờ bay, hệ thống áp dụng quy trình Hủy vé phút chót.

Nếu hủy vé trước giờ bay một khoảng thời gian nhất định, hệ thống áp dụng quy trình Hủy vé thông
thường.

Lợi ích:

Giúp mô hình hóa hệ thống rõ ràng, dễ hiểu.

Tái sử dụng các chức năng chung giữa các trường hợp sử dụng.

Giảm thiểu lỗi và sự phức tạp trong hệ thống.

*Extend Use Cases:

- Mở rộng (Extension) định nghĩa các biến thể và trường hợp đặc biệt, trong đó trường hợp mở rộng bổ
sung thêm chức năng cho trường hợp cơ bản. Nói cách khác, trường hợp mở rộng có thể được chèn vào
hành vi của trường hợp cơ bản.

- Các phần mở rộng được bao gồm (included), có thể tùy chọn (optional), tại các điểm mở rộng
(extension points).

- Một trường hợp sử dụng có thể có nhiều điểm mở rộng.

- Một trường hợp mở rộng có thể mở rộng một hoặc nhiều điểm mở rộng này.
Hình ảnh mô tả mối quan hệ Extend giữa các trường hợp sử dụng (Use Cases) trong hệ thống quản lý
thư viện.

Mối quan hệ Extend:

Mượn sách là Use Case chính (Base Use Case).

Gia hạn mượn sách là Use Case được Extend từ Mượn sách.

Phân tích:

Mối quan hệ Extend giúp thêm chức năng gia hạn mượn sách vào Use Case Mượn sách.

Gia hạn mượn sách là chức năng bổ sung, không bắt buộc, chỉ được thực hiện khi cần thiết.

Việc sử dụng Extend giúp tăng tính linh hoạt cho hệ thống, dễ dàng thêm chức năng mới mà không ảnh
hưởng đến chức năng cũ.

Taxonomic relationship:

Các Actor (người dùng, thiết bị, v.v.) có thể có mối quan hệ phân loại. Chẳng hạn, "Giám đốc điều hành"
là một loại "Nhân viên" với các quyền hạn và trách nhiệm bổ sung. Tuy nhiên, trong sơ đồ trường hợp sử
dụng(use case diagrams), thường người ta không thể hiện mối quan hệ này trực tiếp. Thay vào đó, các
biểu đồ actor riêng biệt có thể được sử dụng để mô tả chi tiết hơn về các loại actor khác nhau và tương
tác của họ với hệ thống.
Sơ đồ mô tả quy trình đăng ký lớp học, lựa chọn môn học giảng dạy và quản lý thông tin sinh viên

B, Biểu đồ hoạt động:

- Một biểu đồ hoạt động trong mô hình use case có thể được sử dụng để nắm bắt các hoạt động
và hành động được thực hiện trong một use case
- Về cơ bản, nó là một biểu đồ luồng công việc, hiển thị luồng điều khiển từ hoạt động hoặc hành
động này sang hoạt động hoặc hành động khác.
- Hoạt động là sự miêu tả hành vi được thể hiện dưới dạng luồng thực thi thông qua việc sắp xếp
tuần tự các đơn vị phụ thuộc
- Các đơn vị phụ thuộc bao gồm cả các hoạt động được lồng nhau và cuối cùng là các hành động
riêng lẻ.
- Hoạt động có thể chứa các ràng buộc biểu thức logic khi hoạt động được kích hoạt hoặc thoát.
 -

*Swimlane thể hiện các hành động và hoạt động được thực hiện bởi một đơn vị, đối tượng hoặc lớp,
thường đồng thời với các hành động, hoạt động khác.

Swimlane này mô tả quy trình đặt hàng và giao hàng của một doanh nghiệp bán hàng qua thư.

Quy trình được chia thành hai phần chính: hành động của khách hàng và hành động của doanh nghiệp
bán hàng qua thư.

Các hành động được sắp xếp theo thứ tự thời gian.
Biểu đồ tương tác:

1. Vật thể cần hợp tác:

Ý nghĩa: Các đối tượng trong lập trình hướng đối tượng (OOP) không thể hoạt động độc lập để giải quyết
vấn đề. Chúng cần phối hợp với nhau để đạt được mục tiêu chung.

Ví dụ: Trong một chương trình mô phỏng bán hàng, đối tượng "Giỏ hàng" cần tương tác với các đối
tượng "Sản phẩm" và "Thanh toán" để thực hiện chức năng thêm sản phẩm, tính tổng tiền và thanh
toán.

2. Trách nhiệm của mỗi đối tượng:

Ý nghĩa: Mỗi đối tượng có trách nhiệm riêng về hành vi và trạng thái của nó. Điều này có nghĩa là mỗi đối
tượng biết cách thực hiện các hành động (methods) của riêng nó và duy trì dữ liệu liên quan
(properties).

Ví dụ: Đối tượng "Sản phẩm" có trách nhiệm lưu trữ thông tin về tên, giá và số lượng. Nó cũng có thể có
các hành động như "thêm vào giỏ hàng" hoặc "cập nhật số lượng".

3. Giao tiếp giữa các đối tượng:

Ý nghĩa: Các đối tượng giao tiếp với nhau bằng cách gửi và nhận tin nhắn. Tin nhắn này thường chứa yêu
cầu thực hiện một hành động cụ thể trên đối tượng nhận.

Ví dụ: Khi người dùng thêm một sản phẩm vào giỏ hàng, đối tượng "Giỏ hàng" sẽ gửi tin nhắn đến đối
tượng "Sản phẩm" yêu cầu thêm một sản phẩm vào danh sách. Đối tượng "Sản phẩm" sau đó cập nhật
trạng thái của nó (ví dụ: tăng số lượng) và gửi phản hồi lại cho "Giỏ hàng".

- Đối tượng tương tác với tin nhắn:

Một tin nhắn cho biết cách một đối tượng yêu cầu một đối tượng khác thực hiện một số hoạt
động

Biểu đồ tương tác là gì?

Biểu đồ tương tác (Interaction Diagram) là một thuật ngữ chung được sử dụng để chỉ một nhóm các
biểu đồ tập trung vào việc thể hiện sự tương tác giữa các đối tượng trong lập trình hướng đối tượng.
Biểu đồ tương tác:

Thuật ngữ chung áp dụng cho một số sơ đồ nhấn mạnh sự tương tác giữa các đối tượng:

Biểu đồ trình tự (Sequence Diagram) : là một loại biểu đồ tương tác tập trung nhấn mạnh thứ tự theo
thời gian của các tin nhắn được trao đổi giữa các đối tượng.

Biểu đồ này giúp hiển thị:

Các đối tượng tham gia tương tác: Liệt kê các đối tượng liên quan đến một hành động hoặc quá trình cụ
thể.

Trình tự trao đổi tin nhắn: Thể hiện thứ tự các tin nhắn được gửi giữa các đối tượng, cho phép theo dõi
quá trình diễn ra của tương tác theo dòng thời gian.
Biểu đồ giao tiếp (Communication Diagram): là một loại biểu đồ tương tác tập trung nhấn mạnh mối
quan hệ giữa các đối tượng tham gia vào một tương tác cụ thể.

Biểu đồ này giúp hiển thị:

Các đối tượng tham gia tương tác: Giống như biểu đồ tuần tự, liệt kê các đối tượng liên quan đến một
hành động hoặc quá trình cụ thể.

Liên kết giữa các đối tượng: Thể hiện các mối quan hệ giữa các đối tượng tham gia tương tác. Những
liên kết này không nhất thiết ngụ ý thứ tự, mà chỉ đơn giản cho thấy các đối tượng có thể giao tiếp với
nhau.

Tin nhắn truyền giữa các đối tượng: Chỉ ra các tin nhắn được gửi giữa các đối tượng, nhưng không nhấn
mạnh thứ tự cụ thể của chúng.:
*Giống nhau giữa Biểu đồ Tuần tự và Biểu đồ Giao tiếp

Thông tin tương đương về mặt ngữ nghĩa (Semantically equivalent): Cả hai biểu đồ đều thể hiện cùng
một thông tin về mặt logic về sự tương tác giữa các đối tượng. Bạn có thể chuyển đổi từ biểu đồ này
sang biểu đồ khác mà không mất bất kỳ thông tin nào.

Mô hình các khía cạnh động của hệ thống (Model the dynamic aspects of a system): Chúng tập trung mô
tả hành vi của hệ thống theo thời gian, bao gồm các yêu cầu, phản hồi và các hành động qua lại giữa các
đối tượng.

Mô hình tình huống sử dụng (Model a use-case scenario): Cả hai biểu đồ đều có thể được sử dụng để
mô hình hóa một tình huống sử dụng cụ thể, thể hiện các bước cần thiết để thực hiện một nhiệm vụ
nhất định trong hệ thống.

Sequence Diagrams Communication Diagrams

-Hiển thị thứ tự rõ ràng của các tin nhắn: Biểu đồ
này cho thấy từng tin nhắn được gửi và nhận
theo đúng thứ tự, giúp bạn dễ dàng theo dõi
luồng thông tin giữa các đối tượng.
-Hiển thị trình tự thực thi: Biểu đồ chuỗi minh
họa rõ ràng thứ tự các hành động diễn ra trong
hệ thống, bao gồm các hành vi được thực hiện
bởi các đối tượng khác nhau.
- Hiển thị mối quan hệ giữa các đối tượng: Biểu
đồ này tập trung vào việc thể hiện các mối quan
hệ giữa các đối tượng tham gia vào tương tác,
giúp bạn hiểu rõ hơn cách các đối tượng được
liên kết với nhau.
- Hiển thị luồng thông tin tổng thể: Biểu đồ giao
tiếp cung cấp cái nhìn toàn cảnh về cách các đối
tượng giao tiếp, cho phép bạn dễ dàng nắm bắt
 -Ít hữu ích cho việc hiển thị các mối quan hệ: Mặc
dù có thể biểu thị các mối quan hệ giữa các đối
tượng trong biểu đồ chuỗi, nhưng cách thể hiện
này kém trực quan và khó theo dõi so với biểu đồ
giao tiếp.
-Thích hợp hơn để trực quan hóa các mẫu tương
tác theo thời gian: Biểu đồ chuỗi hữu ích trong
việc minh họa cách các đối tượng tương tác qua
lại theo thứ tự nhất định, giúp bạn nắm bắt các
mẫu liên quan đến thời gian trong hệ thống.
luồng thông tin giữa chúng.
- Ít hữu ích cho việc thể hiện trình tự cụ thể: Mặc
dù có thể đánh số các tin nhắn trong biểu đồ giao
tiếp để gợi ý thứ tự, nhưng cách này thường
không trực quan bằng biểu đồ chuỗi để hiển thị
trình tự chính xác.
- Thích hợp hơn để trực quan hóa các mẫu giao
tiếp: Biểu đồ giao tiếp giúp bạn dễ dàng quan sát
các mẫu giao tiếp phức tạp, bao gồm các tin nhắn
được trao đổi giữa các đối tượng.
- Hiển thị tất cả các tác động lên một đối tượng
nhất định: Biểu đồ giao tiếp có thể hữu ích trong
việc xem xét tất cả các tin nhắn được gửi đến và
nhận từ một đối tượng cụ thể.
- Dễ sử dụng hơn cho các buổi thảo luận: Biểu đồ
giao tiếp thường dễ hiểu hơn đối với những
người không quen thuộc với biểu đồ chuỗi, do đó
có thể hữu ích cho các buổi thảo luận ban đầu về
thiết kế

Các biến thể chuyên biệt:

Biểu đồ thời gian (Timing Diagram): Thể hiện thứ tự các tin nhắn tương tự như biểu đồ tuần tự, nhưng
chú trọng vào các khoảng thời gian giữa các tin nhắn.

Biểu đồ Tổng quan tương tác (Interaction Overview Diagram): Cung cấp cái nhìn tổng quan về các tương
tác khác nhau trong hệ thống, bao gồm các đối tượng tham gia, các tin nhắn được trao đổi và các tương
tác phụ thuộc lẫn nhau
Biểu đồ lớp:

Cái nhìn tĩnh của hệ thống:

Trong quá trình mô hình hóa trạng thái tĩnh của hệ thống, sơ đồ lớp thường được sử dụng theo ba cách
chính, để mô hình hóa:

Từ vựng của hệ thống: Các lớp đại diện cho các khái niệm và thuật ngữ chính trong hệ thống. Các thuộc
tính của lớp mô tả các đặc điểm của khái niệm đó, còn các phương thức mô tả các hành vi có thể thực
hiện trên khái niệm đó.

Sự cộng tác: Các lớp tương tác với nhau để thực hiện các chức năng nhất định. Sơ đồ lớp cho thấy các
mối quan hệ giữa các lớp và cách chúng giao tiếp với nhau.

Sơ đồ cơ sở dữ liệu logic: Các lớp có thể được ánh xạ sang các bảng trong cơ sở dữ liệu, với các thuộc
tính lớp tương ứng với các cột bảng và các mối quan hệ giữa các lớp được thể hiện bằng các mối quan
hệ giữa các bảng.

Bằng cách sử dụng sơ đồ lớp theo ba cách này, các nhà phát triển có thể tạo ra một biểu diễn trực
quan và dễ hiểu về cấu trúc của hệ thống.

Liên kết (Association) là gì?

Liên kết là một mối quan hệ ngữ nghĩa giữa hai hoặc nhiều phân loại (classifier), xác định các kết nối giữa
các phiên bản (instance) của chúng.

Nói cách khác, liên kết là một mối quan hệ cấu trúc chỉ ra rằng các đối tượng của một thứ được kết nối
với các đối tượng của một thứ khác.
Đa dạng(Multiplicity) là số lượng phiên bản (instance) của một lớp liên quan đến MỘT phiên bản của lớp
khác. Mỗi liên kết có hai mức độ đa dạng cần xác định, một cho mỗi phía của liên kết.

Ví dụ:

Đa dạng cho lớp Giáo sư (Professor):

Mỗi phiên bản của lớp "Giáo sư" (Professor) có thể liên quan đến nhiều phiên bản của lớp "Giáo trình"
(Course Offering) (nghĩa là một giáo sư có thể dạy nhiều môn).

Đa dạng cho lớp Giáo trình (Course Offering):

Mỗi phiên bản của lớp "Giáo trình" (Course Offering) có thể liên quan đến một hoặc không phiên bản
của lớp "Giáo sư" (Professor) làm giảng viên (nghĩa là một môn học có thể có một hoặc không có giáo
viên được chỉ định).
Gộp (Aggregation) là gì?

Gộp là một dạng đặc biệt của liên kết (association) dùng để mô hình hóa mối quan hệ toàn thể - bộ phận
giữa toàn thể (aggregate) và các bộ phận của nó.

Nói cách khác, gộp là mối quan hệ "là một phần của".

Đa dạng (Multiplicity) của gộp được biểu diễn giống như các liên kết khác.

Tổng quát hóa (Generalization) là gì?

Tổng quát hóa là một mối quan hệ giữa các lớp trong lập trình hướng đối tượng, thể hiện sự kế thừa cấu
trúc và/hoặc hành vi của một hoặc nhiều lớp khác. Nó giúp thiết lập phân cấp trừu tượng (hierarchy of
abstractions), trong đó lớp con (subclass) thừa kế từ một hoặc nhiều lớp cha (superclass).

Đặc điểm của tổng quát hóa:

Quan hệ "là một loại của" (is a kind of): Lớp con được coi là chuyên biệt hóa (specialization) của lớp cha.
Ví dụ, lớp "Sinh viên" (Student) là một loại của lớp "Người" (Person).

Kế thừa: Lớp con kế thừa các thuộc tính và phương thức được định nghĩa trong lớp cha, có thể bổ sung
thêm các thuộc tính và phương thức riêng của mình.

Các loại kế thừa:

Kế thừa đơn (Single inheritance): Lớp con chỉ kế thừa từ một lớp cha duy nhất.

Kế thừa đa (Multiple inheritance): Lớp con có thể kế thừa từ nhiều lớp cha khác nhau (ít được sử dụng
do có thể gây ra sự phức tạp và mâu thuẫn).
Bảng thuật ngữ, thông số bổ sung, v.v……

Phân tích trường hợp sử dụng:

 Hành vi:
Hành vi hoàn chỉnh của một use-case phải được phân bổ cho các lớp phân tích (Analysis Class):

Lớp phân tích là gì?:

1, Boundary Class:

- Lớp Ranh giới: Là những lớp trung gian nằm giữa giao diện của hệ thống và thực thể bên ngoài
của hệ thống, đóng vai trò giải quyết tương tác giữa hệ thống và các thực thể bên ngoài
- Các loại Lớp Ranh giới:
- Lớp giao diện người dùng (User interface classes): Xử lý tương tác với người dùng thông qua các
thành phần giao diện như màn hình, bàn phím, chuột, v.v.
- Lớp giao diện hệ thống (System interface classes): Xử lý tương tác với các hệ thống khác, chẳng
hạn như giao tiếp với cơ sở dữ liệu, dịch vụ web hoặc các hệ thống bên ngoài khác.
- Lớp giao diện thiết bị (Device interface classes): Xử lý tương tác với các thiết bị ngoại vi, chẳng
hạn như máy in, cảm biến, thiết bị mạng, v.v.
- Có một lớp ranh giới cho mỗi cặp actor - trường hợp sử dụng (use case). Điều này đảm bảo mỗi
actor và trường hợp sử dụng(use-case) có một điểm tương tác duy nhất với hệ thống thông qua
lớp ranh giới tương ứng.

-
 -

-
*Lớp Giao Diện Người Dùng (User Interface Classes):
- Trách nhiệm:
- Cung cấp thông tin cho người dùng theo một định dạng dễ hiểu và tương tác, Tập trung vào
những giao thức nào phải được xác định
- Nhận và xử lý đầu vào của người dùng theo cách phù hợp với hệ thống.
- Không tập trung vào các chi tiết cụ thể về giao diện người dùng (UI) như màu sắc, phông chữ, bố
cục. Thay vào đó, chúng nên tập trung vào các trách nhiệm như:
- Hiển thị dữ liệu trong các bảng, biểu mẫu, danh sách, v.v.
- Cho phép người dùng nhập và chỉnh sửa dữ liệu.
- Cung cấp các nút và menu để điều hướng hệ thống.
- Hiển thị thông báo lỗi và xác nhận cho người dùng.
- Tập trung vào trách nhiệm chứ không phải vào chi tiết!

Entity Class(Lớp thực thể): Các khái niệm trừu tượng chính của hệ thống

TÌm các lớp thực thể:

- Sử dụng luồng sự kiện của ca sử dụng làm đầu vào

- Các khái niệm trừu tượng chính của ca sử dụng:
- Sử dụng phương pháp lọc danh từ:
- Gạch chân các cụm danh từ (noun clauses): Xác định các cụm danh từ trong luồng sự kiện của
trường hợp sử dụng. Ví dụ, "hóa đơn đặt hàng của khách hàng" (customer order invoice).
- Loại bỏ các ứng cử viên thừa (Remove redundant candidates): Loại bỏ các danh từ lặp lại hoặc
không cần thiết. Ví dụ, nếu bạn đã có "hóa đơn đặt hàng" (order invoice) thì không cần thêm
"đơn hàng" (order) riêng biệt.
- Loại bỏ các ứng cử viên mơ hồ (Remove vague candidates): Loại bỏ các danh từ quá chung
chung và không rõ ràng. Ví dụ, "thông tin" (information) không cung cấp đủ thông tin để xác
định một lớp thực thể cụ thể.
- Loại bỏ diễn viên (out of scope): Diễn viên là người tương tác với hệ thống và thường không
được coi là lớp thực thể. Loại bỏ các danh từ đại diện cho diễn viên.
- Loại bỏ cấu trúc triển khai (Remove implementation constructs): Loại bỏ các danh từ đề cập đến
các khái niệm cụ thể của việc triển khai, chẳng hạn như "giao diện người dùng" (user interface)
hoặc "cơ sở dữ liệu" (database).
- Loại bỏ thuộc tính (save for later): Thuộc tính thường được xác định sau khi xác định các lớp
thực thể. Trong bước này, hãy tạm thời bỏ qua các thuộc tính.
- Loại bỏ phương thức (Remove operations): Tương tự như thuộc tính, phương thức cũng được
xác định sau khi xác định các lớp thực thể. Trong bước này, hãy tạm thời bỏ qua các phương
thức.
Ví dụ về thực thể ứng viên của lớp học:

Control class(Lớp kiểm soát): Là một lớp trong lập trình hướng đối tượng chịu trách nhiệm điều phối
các hoạt động để hoàn thành một trường hợp sử dụng cụ thể.

 Nên tạo một lớp điều khiển riêng cho mỗi trường hợp sử dụng. Điều này giúp cho mã được tổ
chức rõ ràng hơn và dễ quản lý hơn.
 Trong quá trình phân tích chi tiết hơn, một trường hợp sử dụng phức tạp có thể cần được chia
thành nhiều lớp điều khiển nhỏ hơn. Điều này nhằm mục đích cải thiện tính mô đun và tránh các
lớp điều khiển cồng kềnh.
Phân tích hành vi use – case tới các lớp

Đối với mỗi sự kiện của use – case

- Xác định các lớp phân tích

- Phân bố trách nhiệm use – case cho các lớp phân tihcs
- Phân tích Interaction Diagram

Phân bố trách nhiệm với các lớp:

Sử dụng khuôn mẫu của lớp phân tích:

- Lớp ranh giới:

Hành vi liên quan đến giao tiếp với actor:
- Lớp thực thể:
Hành vi liên quan đến dữ liệu được gói gọn trong trừu tượng
- Lớp điều khiển: Hành vi cụ thể đối với một use – case hoặc một phần của luồng sự kiện rất quan
trọng
- Nếu một lớp có dữ liệu thì đặt trách nhiệm vào dữ liệu:
- Nếu có nhiều lớp có dữ liệu:
 Đặt trách nhiệm vào một lớp và them mối quan hệ với lớp kia
 Tạo một lớp mới, đặt trách nhiệm vào lớp mới và them mối quan hệ với các lớp cần thiết để
thực hiện trách nhiệm
 Đặt trách nhiệm vào lớp điều khiển và them các mối quan hệ vào các lớp cần thiết để thực hiện
trách nhiệm
Phân tích kiến trúc:
Gói (package):
Là một cơ chế tổng hợp chung để tổ chức các thành phần thành nhóm.
Là một phần tử mô hình có thể chứa các phần tử mô hình khác.
Được sử dụng để:
Tổ chức mô hình đang được phát triển.
Là một đơn vị quản lý cấu hình.
Các gói có thể liên quan đến nhau thông qua mối quan hệ phụ thuộc (dependency relationship).
Ý nghĩa của phụ thuộc:
Các thay đổi trong gói cung cấp (supplier package) có thể ảnh hưởng đến gói sử dụng (client
package).
Gói sử dụng không thể được tái sử dụng độc lập vì nó phụ thuộc vào gói cung cấp.

Tránh phụ thuộc vòng tròn:

"Hierarchy should be acyclic" (Phân cấp nên được phi chu trình).
"Circular dependencies make it impossible to reuse one package without the other" (Phụ thuộc
vòng tròn khiến việc tái sử dụng một gói mà không có gói kia trở nên không thể).
Kiểu mẫu và Khung

Kiểu mẫu (Pattern):

Cung cấp giải pháp chung cho một vấn đề thường gặp trong một bối cảnh cụ thể.

Kiểu mẫu phân tích/thiết kế:

Giải quyết một vấn đề kỹ thuật có phạm vi hẹp.

Cung cấp một phần của giải pháp, giống như một mảnh ghép của bức tranh lớn.

Khung (Framework):

Xác định cách tiếp cận tổng thể để giải quyết vấn đề.

Cung cấp khung giải pháp, phần chi tiết có thể được lấp đầy bởi các kiểu mẫu phân tích/thiết kế.

Kiểu mẫu thiết kế (Design Pattern) là gì?

Kiểu mẫu thiết kế là một giải pháp cho một vấn đề thiết kế thường gặp.

Nó bao gồm:

Mô tả vấn đề thiết kế thường gặp.

Trình bày giải pháp cho vấn đề đó.

Thảo luận về những kết quả và đánh đổi khi áp dụng kiểu mẫu.

Vai trò của Kiểu mẫu thiết kế:

Kiểu mẫu thiết kế giúp tái sử dụng các thiết kế thành công, tiết kiệm thời gian và công sức cho lập trình
viên.

Chúng cung cấp một "ngôn ngữ chung" để các lập trình viên giao tiếp và hiểu các giải pháp thiết kế phức
tạp.

Kiểu mẫu Kiến trúc (Architectural Pattern) là gì?

Kiểu mẫu kiến trúc thể hiện cách tổ chức cấu trúc cơ bản cho các hệ thống phần mềm.

Nó cung cấp một tập hợp các hệ thống con được xác định trước, chỉ định trách nhiệm của chúng và bao
gồm các quy tắc, hướng dẫn để tổ chức các mối quan hệ giữa chúng. (Nguồn: Buschman et al, "Pattern-
Oriented Software Architecture - A System of Patterns")

Ví dụ về Kiểu mẫu Kiến trúc:

Kiểu mẫu Lớp (Layers): Chia hệ thống thành các lớp riêng biệt với các trách nhiệm riêng. Ví dụ: lớp giao
diện người dùng (UI), lớp nghiệp vụ (business logic), lớp truy cập dữ liệu (data access).

Kiểu mẫu Kiểu xem-Kiểu điều khiển-Kiểu mô hình (Model-View-Controller - MVC): Phân tách hệ thống
thành ba thành phần: Kiểu mô hình (Model) chứa dữ liệu, Kiểu xem (View) hiển thị dữ liệu, Kiểu điều
khiển (Controller) xử lý tương tác của người dùng.

Kiểu mẫu Ống và Bộ lọc (Pipes and Filters): Xử lý dữ liệu theo luồng, mỗi giai đoạn trong luồng thực hiện
một phép toán hoặc thao tác riêng biệt trên dữ liệu.

Kiểu mẫu Bảng đen (Blackboard): Hệ thống lưu trữ thông tin trung tâm, các thành phần khác trong hệ
thống có thể đọc và ghi thông tin này để phối hợp hoạt động.

M
Mẹo đóng gói: Ranh giớii

Tiêu chí để xác định xem các lớp có liên quan về mặt chức năng hay không:

Thay đổi hành vi và/hoặc cấu trúc của một lớp đòi hỏi phải thay đổi lớp khác: Nếu việc thay đổi một lớp
dẫn đến việc phải thay đổi lớp khác để duy trì tính năng, thì hai lớp có liên quan về chức năng.

Xóa bỏ một lớp ảnh hưởng đến lớp khác: Nếu việc xóa bỏ một lớp khiến lớp còn lại không hoạt động
bình thường, thì hai lớp có liên quan về chức năng.

Hai đối tượng trao đổi một lượng lớn message hoặc có sự tương tác phức tạp: Nếu hai đối tượng giao
tiếp với nhau thông qua nhiều message phức tạp, thì chúng có liên quan về chức năng.

Lớp ranh giới (boundary class) có liên quan về chức năng với một lớp thực thể (entity class) cụ thể: Nếu
chức năng của lớp ranh giới là thể hiện lớp thực thể, thì chúng có liên quan về chức năng.

Hai lớp tương tác với hoặc bị ảnh hưởng bởi thay đổi của cùng một tác nhân (actor): Nếu hai lớp cùng xử
lý hoặc bị ảnh hưởng bởi hành động của cùng một người dùng hoặc hệ thống bên ngoài, thì chúng có
liên quan về chức năng.

Tóm lại, các lớp có liên quan về chức năng nếu chúng phụ thuộc chặt chẽ vào nhau và sự thay đổi của
một lớp ảnh hưởng đến hoạt động của lớp khác. Bằng cách xác định các lớp có liên quan về chức năng,
bạn có thể tổ chức các lớp này thành các gói hợp lý, giúp cải thiện tính mô đun, khả năng đọc và khả
năng bảo trì của hệ thống phần mềm.

Hai lớp có mối quan hệ với nhau: Ví dụ, một lớp kế thừa từ một lớp khác, hoặc hai lớp implements cùng
một giao diện.
Một lớp tạo instance của lớp khác: Điều này cho thấy sự phụ thuộc giữa hai lớp và có thể là dấu hiệu của
sự liên quan về chức năng.

Tiêu chí KHÔNG nên đặt hai lớp trong cùng một gói:

Hai lớp liên quan đến các tác nhân khác nhau: Nếu hai lớp xử lý các yêu cầu từ các tác nhân khác nhau
hoặc thuộc các phần khác nhau của hệ thống, thì việc đặt chúng cùng gói có thể dẫn đến sự phụ thuộc
không cần thiết và làm giảm tính mô đun của hệ thống.

Lớp bắt buộc và lớp tùy chọn: Một lớp bắt buộc là lớp luôn được sử dụng, trong khi lớp tùy chọn chỉ
được sử dụng trong một số trường hợp nhất định. Đặt chúng cùng gói có thể khiến các gói phụ thuộc
vào các lớp tùy chọn ngay cả khi chúng không cần thiết.

Phụ thuộc gói (Package Dependencies):

Mối quan hệ giữa tầm nhìn gói và tầm nhìn lớp: Tầm nhìn của gói không ảnh hưởng đến tầm nhìn của
các lớp bên trong gói đó. Điều này có nghĩa là mặc dù PackageB là riêng tư, lớp B1 bên trong PackageB
vẫn có thể là công khai và có thể truy cập được từ các gói khác.

Tác động đến phụ thuộc: Khi một gói phụ thuộc vào một gói khác, nó chỉ có thể truy cập các thành phần
công khai (public elements) (lớp, giao diện, v.v.) của gói được phụ thuộc. Trong ví dụ này, nếu một gói
khác phụ thuộc vào PackageA, nó có thể truy cập các lớp A, A1 và A2, nhưng nó không thể truy cập
PackageB hoặc lớp B2 vì chúng là riêng tư

Các nguyên tắc về phụ thuộc giữa các gói (package dependencies):

Không nên có sự phụ thuộc chéo giữa các gói (Packages should not be cross-coupled):

Các gói không nên phụ thuộc lẫn nhau theo nhiều hướng, điều này làm phức tạp việc quản lý và bảo trì
hệ thống.

Mỗi gói nên có trách nhiệm rõ ràng và giao tiếp với các gói khác theo một hướng cụ thể.

Các gói ở lớp thấp hơn không nên phụ thuộc vào các gói ở lớp cao hơn (Packages in lower layers should
not be dependent upon packages in upper layers):

Hệ thống thường được tổ chức thành các lớp, với các lớp thấp hơn cung cấp chức năng cơ bản và các
lớp cao hơn xây dựng trên các chức năng này.

Nguyên tắc này ngăn chặn sự phụ thuộc ngược, giúp đảm bảo tính ổn định và khả năng bảo trì của hệ
thống. Các thay đổi trong lớp cao hơn không nên ảnh hưởng đến các lớp thấp hơn.

Nói chung, các phụ thuộc không nên bỏ qua các lớp (In general, dependencies should not skip layers):

Nguyên tắc này khuyến khích tổ chức các phụ thuộc theo một cấu trúc phân cấp rõ ràng.

Các gói nên phụ thuộc vào các gói cùng lớp hoặc lớp thấp hơn, tránh phụ thuộc trực tiếp vào các gói
cách nhiều lớp. Điều này giúp hệ thống dễ hiểu hơn và dễ dàng thay đổi từng lớp riêng lẻ.

Tóm lại, các nguyên tắc này hướng dẫn thiết kế các hệ thống phần mềm với tính mô đun cao, dễ bảo trì
và dễ thích ứng với những thay đổi.
Các gói ở lớp thấp hơn không nên phụ thuộc vào các gói ở lớp cao hơn.

Trong hình, X đánh dấu vi phạm phụ thuộc. Mũi tên từ PackageB (lớp thấp hơn) trỏ đến PackageA (lớp
cao hơn), cho thấy PackageB phụ thuộc vào PackageA, vi phạm nguyên tắc.

Mảnh ghép kết hợp (Combined Fragment) là gì?

Trong một tương tác, mảnh ghép kết hợp là một cấu trúc bao gồm một từ khóa toán tử và một hoặc
nhiều toán hạng tương tác. Mỗi toán hạng tương tác là một phần của một tương tác khác. Nó được thể
hiện như một vùng lồng nhau trong biểu đồ tuần tự.

Toán Hạng Tương Tác (Interaction Operand) là gì?

Mỗi mảnh ghép (fragment) trong một tương tác được tạo thành từ một hoặc nhiều toán hạng tương tác
(interaction operand). Mỗi toán hạng tương tác lại là một phân mảnh (subfragment) của chính mảnh
ghép đó. Số lượng toán hạng phụ thuộc vào loại mảnh ghép kết hợp.

Ví dụ: Một vòng lặp có một toán hạng (thân vòng lặp) và một câu điều kiện có một hoặc nhiều toán hạng
(các nhánh của điều kiện).

Toán hạng tương tác là một phân mảnh lồng nhau của một tương tác.

Mỗi toán hạng tương tác bao phủ các đường đời (lifeline) được bao phủ bởi mảnh ghép kết hợp hoặc
một tập con của chúng
Biểu thức tương tác là một cách xác định phạm vi số lần lặp của một vòng lặp trong biểu đồ tuần tự.
Phạm vi này có thể được chỉ định bằng giá trị tối thiểu và tối đa.

Các điểm chính:

Biểu thức tương tác xác định số lần lặp của một vòng lặp trong tương tác.

Phạm vi được xác định bằng giá trị tối thiểu và tối đa của số lần lặp. Ví dụ, [2..5] cho biết vòng lặp có thể
chạy từ 2 đến 5 lần.

Biểu thức có thể bao gồm một điều kiện bảo vệ được đặt trong dấu ngoặc vuông []. Điều kiện này kiểm
tra trạng thái của một đường đời (lifeline) cụ thể trong tương tác.

Các Bước Tích Hợp JDBC:

1. Cung cấp quyền truy cập vào các thư viện lớp cần thiết để triển khai JDBC:

Cung cấp gói java.sql trong dự án của bạn.

2. Tạo các lớp DBClass cần thiết:

Gán một lớp DBClass cho mỗi lớp lưu trữ (persistent class).

Lớp DBClass chịu trách nhiệm tương tác với cơ sở dữ liệu cho lớp lưu trữ tương ứng.

3. Tích hợp các lớp DBClass vào thiết kế:

Gán các lớp DBClass vào các gói/lớp thích hợp trong kiến trúc ứng dụng của bạn.
Thêm các mối quan hệ từ các lớp sử dụng cơ sở dữ liệu (persistency client) đến các lớp DBClass tương
ứng.

4. Tạo/Cập nhật các biểu đồ tương tác mô tả:

Khởi tạo cơ sở dữ liệu: Mô tả các bước cần thiết để thiết lập kết nối với cơ sở dữ liệu, tạo các bảng và
các cấu trúc dữ liệu khác cần thiết.

Truy cập lớp lưu trữ: Tạo (Create), Đọc (Read), Cập nhật (Update), Xóa (Delete): Mô tả các bước tương
tác với cơ sở dữ liệu để thực hiện các thao tác CRUD (Create, Read, Update, Delete) trên dữ liệu được
quản lý bởi các lớp lưu trữ.

Các Bước Thiết Kế Theo Kiểu Sử Dụng (Use-Case Design):

1. Mô tả tương tác giữa các đối tượng thiết kế:

Xác định cách các đối tượng trong hệ thống giao tiếp với nhau để hoàn thành một mục tiêu cụ thể.

Sử dụng các công cụ như biểu đồ luồng dữ liệu (data flow diagrams) hoặc biểu đồ lớp (class diagrams)
để thể hiện các tương tác này.

2. Giản lược biểu đồ tuần tự bằng cách sử dụng hệ thống con:

Chia nhỏ hệ thống thành các hệ thống con (subsystems) riêng biệt, mỗi hệ thống con chịu trách nhiệm
cho một tập hợp chức năng nhất định.

Sử dụng các tương tác giữa các hệ thống con thay vì mô tả chi tiết các tương tác giữa các đối tượng
trong mỗi hệ thống con.

3. Mô tả hành vi liên quan đến tính lưu trữ:

Xác định cách dữ liệu được lưu trữ, truy cập và cập nhật trong hệ thống.

Mô tả các tương tác với lớp lưu trữ (persistence layer) để thực hiện các hành vi CRUD (Create, Read,
Update, Delete) trên dữ liệu.

4. Tinh chỉnh mô tả luồng sự kiện:

Kiểm tra lại và làm rõ trình tự các sự kiện diễn ra trong use case.

Loại bỏ các bước không cần thiết và đảm bảo tính logic của luồng sự kiện.

5. Hợp nhất các lớp và hệ thống con:

Xác định các lớp và hệ thống con trùng lặp hoặc có chức năng tương tự.

Hợp nhất các lớp và hệ thống con này để tránh trùng lặp mã và cải thiện tổ chức của hệ thống.

Mô tả tương tác giữa các đối tượng thiết kế:

Tinh chỉnh Thực hiện Kiểu Sử Dụng (Use-Case Realization Refinement):

1. Xác định các đối tượng tham gia:

Liệt kê tất cả các đối tượng cần thiết để thực hiện chức năng của use case.

Các đối tượng này có thể bao gồm các lớp được xác định trong thiết kế theo kiểu sử dụng (use-case
design), cùng với các đối tượng bên ngoài hệ thống.

2. Phân bổ trách nhiệm giữa các đối tượng:

Xác định trách nhiệm của từng đối tượng trong việc thực hiện use case.

Trách nhiệm bao gồm các phương thức (method) và hành vi mà mỗi đối tượng thực hiện để góp phần
vào chức năng tổng thể.

3. Mô hình các tin nhắn giữa các đối tượng:

Xác định các tin nhắn được trao đổi giữa các đối tượng trong quá trình thực hiện use case.

Tin nhắn bao gồm dữ liệu được gửi từ một đối tượng sang đối tượng khác để kích hoạt hành vi hoặc yêu
cầu thông tin.

4. Mô tả xử lý kết quả từ các tin nhắn biểu đồ lớp (Class Diagrams):

Xác định cách các đối tượng xử lý các tin nhắn nhận được.

Mô tả các hành vi, tính toán và thao tác dữ liệu được thực hiện bởi mỗi đối tượng dựa trên nội dung của
tin nhắn.

5. Mô hình các mối quan hệ giữa các lớp liên quan:

Xác định các mối quan hệ giữa các lớp được sử dụng trong thực hiện use case.

Các mối quan hệ này có thể bao gồm quan hệ "has-a" (có-một), "is-a" (là-một) hoặc các mối quan hệ
phức tạp hơn như "aggregation" (gộp) hoặc "composition" (thành phần).
Các Bước Tinh Chỉnh Thực Hiện Kiểu Sử Dụng (Use-Case Realization Refinement)

1. Xác định các đối tượng tham gia:

Liệt kê tất cả các đối tượng cần thiết để thực hiện chức năng của use case.

Các đối tượng này có thể bao gồm các lớp được xác định trong thiết kế theo kiểu sử dụng (use-case
design), cùng với các đối tượng bên ngoài hệ thống.

2. Thể hiện các đối tượng trên biểu đồ tuần tự:

Tạo một biểu đồ tuần tự (sequence diagram) để thể hiện các đối tượng tham gia use case.

Trong biểu đồ tuần tự, mỗi đối tượng được biểu diễn bằng một đường đời (lifeline) theo chiều dọc, thể
hiện sự tồn tại của đối tượng trong suốt quá trình thực hiện use case.

3. Bổ sung dần các cơ chế kiến trúc áp dụng:

Xác định các cơ chế kiến trúc (architectural mechanism) thích hợp để thực hiện use case.

Ví dụ, các cơ chế kiến trúc có thể bao gồm:

Mẫu thiết kế (design pattern): Sử dụng các mẫu thiết kế được xây dựng sẵn để giải quyết các vấn đề
thiết kế phổ biến.

Kiểu thiết kế (architectural style): Áp dụng các kiểu thiết kế như lớp (layered), hướng dịch vụ (service-
oriented) hoặc MVC (Model-View-Controller) để tổ chức hệ thống.

Bổ sung dần các cơ chế kiến trúc này vào biểu đồ tuần tự, mô tả cách chúng tương tác với các đối tượng
để đạt được chức năng mong muốn.

iểu diễn các Hệ thống Con trên Biểu đồ Tuần Tự (Sequence Diagram):

1. Giao diện (Interfaces):

Trên biểu đồ tuần tự, giao diện được biểu diễn như một khung hình hộp (box) riêng biệt.

Bên trong khung, ghi chú loại giao diện (ví dụ: IOrderManager).

Bất kỳ thành phần mô hình nào thực hiện giao diện đó đều được đặt bên trong khung hình hộp. Điều
này thể hiện mối quan hệ "thực hiện" (implements) giữa các lớp và giao diện.

Không có mũi tên tin nhắn nào được vẽ ra khỏi khung hình hộp của giao diện. Giao diện chỉ đơn thuần là
một sự phân loại và không trực tiếp gửi tin nhắn.

2. Thành phần Hệ thống Con (Subsystem Component):

Trên biểu đồ tuần tự, một hệ thống con được biểu diễn như một khung hình hộp xếp chồng (stacked
box) đặc biệt.

Bên trong khung, ghi chú tên của hệ thống con (ví dụ: OrderManagementSubsystem).

Các thành phần cụ thể (ví dụ: lớp, dịch vụ) thuộc về hệ thống con được đặt bên trong khung hình hộp.

Mũi tên tin nhắn có thể được vẽ ra từ hệ thống con để thể hiện các tin nhắn được gửi bởi các thành
phần bên trong.