Nền tảng của Mô hình hóa và UML

1. Mô hình là gì?

Một mô hình là một mô tả đầy đủ của một hệ thống từ một góc nhìn nhất định và hoạt động như một biểu diễn đơn giản hóa của thực tế. Bạn xây dựng mô hình vì các hệ thống phức tạp không thể được hiểu toàn diện.

Bốn mục tiêu cốt lõi của mô hình hóa:

1. Trực quan hóa một hệ thống theo cách mong muốn.

2. Xác định cấu trúc hoặc hành vi của một hệ thống.

3. Cung cấp một mẫu để hướng dẫn việc xây dựng hệ thống.

4. Tài liệu hóa các quyết định thiết kế.

Bốn nguyên tắc của mô hình hóa

• Mô hình bạn chọn trực tiếp ảnh hưởng đến cách tiếp cận vấn đề.

• Mỗi mô hình có thể được biểu diễn ở các mức độ chính xác khác nhau.

• Những mô hình hiệu quả nhất vẫn giữ liên kết chặt chẽ với thực tế.

• Không có mô hình nào là đủ; các hệ thống phức tạp đòi hỏi nhiều góc nhìn.

UML là gì?

Ngôn ngữ mô hình hóa thống nhất (UML) Unified Modeling Language (UML) là một ngôn ngữ đồ họa chuẩn hóa được quản lý bởi Nhóm Quản lý Đối tượng (OMG). Nó rõ ràng là không phải là một phương pháp hay quy trình, mà là một tài liệu kỹ thuật và đồ họa được sử dụng để:

“Trực quan hóa, xác định, xây dựng và tài liệu hóa các thành phần của một hệ thống tập trung vào phần mềm.”

UML cung cấp một định dạng bản vẽ tổng quát cho cả các yếu tố khái niệm (quy trình kinh doanh, chức năng hệ thống) và các triển khai cụ thể (các câu lệnh mã nguồn, lược đồ cơ sở dữ liệu, các thành phần có thể tái sử dụng).

Bốn trụ cột của UML

Mục đích	Mô tả
Trực quan hóa	Đảm bảo tất cả các bên liên quan sử dụng cùng một ngôn ngữ. Các mô hình rõ ràng loại bỏ sai sót trong giao tiếp và tiết lộ những khía cạnh hệ thống không thể nhìn thấy nếu không có mô hình hóa.
Xác định	Tạo ra các định nghĩa hệ thống chính xác, rõ ràng và đầy đủ.
Xây dựng	Trực tiếp ánh xạ sang các ngôn ngữ lập trình (Java, C++, VB), các bảng RDBMS hoặc các kho lưu trữ OODBMS. Hỗ trợ kỹ thuật xây dựng từ mô hình (mô hình → mã nguồn) và kỹ thuật ngược lại (mã nguồn → mô hình).
Tài liệu hóa	Ghi lại kiến trúc hệ thống, yêu cầu, kế hoạch kiểm thử, lịch trình dự án và quản lý phát hành.

---

2. Hệ sinh thái sơ đồ UML

UML 2.2 định nghĩa 14 loại sơ đồ, được phân loại thành hai nhóm chính:

1. Mô hình cấu trúc (kiến trúc tĩnh)

2. Mô hình hành vi và tương tác (quy trình động)

Các sơ đồ khác nhau phục vụ các quan điểm khác nhau của các bên liên quan:

• Góc nhìn trường hợp sử dụng: Chức năng dành cho người dùng cuối

• Góc nhìn logic: Nhà phân tích và nhà thiết kế (cấu trúc hệ thống)

• Xem xét quy trình: Quản lý phần mềm (hiệu suất, khả năng mở rộng, băng thông)

• Xem xét triển khai: Lập trình viên (các thành phần cụ thể)

• Xem xét triển khai: Nhà tích hợp hệ thống (kiến trúc, cài đặt, giao tiếp)

---

3. Giải thích các sơ đồ UML cốt lõi

🔹 Sơ đồ trường hợp sử dụng

• Mục đích: Mô hình hóa các chức năng dự kiến của hệ thống và môi trường của nó. Hoạt động như một hợp đồng giữa khách hàng và nhà phát triển.

• Thành phần: Người dùng, Trường hợp sử dụng và các mối quan hệ giữa chúng.

• Các sơ đồ hỗ trợ: Hoạt động (luồng bên trong một trường hợp sử dụng), Chuỗi (hợp tác giữa các đối tượng để thực hiện một trường hợp sử dụng).

🔹 Sơ đồ hoạt động

• Mục đích: Trực quan hóa luồng các sự kiện theo từng bước bên trong một quy trình hoặc trường hợp sử dụng.

• Các thành phần chính:

  • Hành động: Một bước rời rạc trong quy trình làm việc.

  • Luồng: Thứ tự các hoạt động.

  • Quyết định: Chia tách luồng dựa trên điều kiện bảo vệ[điều kiện].

  • Chia nhánh: Bắt đầu các luồng song song.

  • Ghép nối: Kết thúc các luồng song song (đồng bộ hóa).

• Ví dụ: Luồng đăng ký khóa học với kiểm tra, giải quyết xung đột và cập nhật lịch trình đồng thời.

🔹 Sơ đồ tuần tự

• Mục đích: Hiển thị cách các đối tượng tương tác theo thời gian thời gian để thực hiện một trường hợp sử dụng.

• Các yếu tố chính:

  • Đường sống: Đường thẳng đứng thể hiện sự tồn tại của một đối tượng theo thời gian.

  • Đối tượng/Lớp: Người tham gia trong tương tác.

  • Thông điệp: Dữ liệu hoặc lời gọi phương thức được trao đổi giữa các đối tượng.

  • Sự kiện thực thi: Hình chữ nhật mỏng thể hiện khi một đối tượng đang thực hiện xử lý.

  • Các mảnh kết hợp: opt (thực thi tùy chọn), loop (thực thi lặp lại), ref (tham chiếu đến một tương tác khác).

🔹 Sơ đồ giao tiếp

• Mục đích: Lựa chọn thay thế cho sơ đồ tuần tự. Nhấn mạnh các mối quan hệ cấu trúc giữa các đối tượng thay vì thứ tự theo thời gian.

• Các yếu tố chính: Các đối tượng được liên kết với nhau, với các tin nhắn được đánh số để chỉ trình tự tương tác dọc theo các liên kết.

🔹 Sơ đồ thành phần

• Mục đích: Hiển thị cấu trúc thời gian chạy ở cấp độ thành phần phần mềm.

• Các yếu tố chính: Các phần hệ thống theo mô-đun được ẩn sau các giao diện bên ngoài. Thường bao gồm các lớp để thể hiện các mối quan hệ triển khai.

🔹 Sơ đồ triển khai

• Mục đích: Ánh xạ các thành phần phần mềm sang phần cứng vật lý.

• Các yếu tố chính:

  • Nút: Đại diện cho một máy vật lý hoặc môi trường thực thi.

  • Thành phần: Đại diện cho một tập tin vật lý hoặc đơn vị có thể triển khai.

  • Yếu tố được sở hữu: Thể hiện các mối quan hệ lồng ghép hoặc chứa đựng.

---

4. Nắm vững sơ đồ lớp và các mối quan hệ

Sơ đồ lớp mô tả cấu trúc tĩnh của một hệ thống. Chúng là nền tảng cho các đặc tả dữ liệu (ví dụ: INSPIRE) và không không thể hiện thông tin theo thời gian.

Giải phẫu lớp

Khoang	Mô tả
Tên	Định danh của lớp (ví dụ: CadastralParcel). Thường bao gồm các kiểu dáng như «FeatureType».
Thuộc tính	Các thuộc tính có tên với kiểu dữ liệu (ví dụ như - Địa chỉ : ký tự, - TuổiCây : số nguyên). Các kiểu được hỗ trợ: Số nguyên, Số nguyên dài, Số thực, Ký tự, Ngày, Boolean, Chuỗi, Hình học, v.v.
Thao tác	Hành vi/phương thức của lớp. Định dạng: + tênThaoTac(kiểuĐầuVào) : kiểuTrảVề.

Loại mối quan hệ

Mối quan hệ	Ký hiệu	Ý nghĩa
Liên kết	───────	Liên kết tổng quát giữa các lớp. Bao gồm tên vai trò, mũi tên điều hướng và bội số (1..*, 0..*, 1..2, v.v.).
Tổng quát hóa	─────▷	Kế thừa. Lớp con (nguồn) kế thừa tất cả các đặc điểm của lớp cha (đích).
Tổ hợp	◇─────	Mối quan hệ “thuộc về”. Phần có thể tồn tại độc lậpcủa toàn bộ. (Hình kim cương rỗng)
Thành phần	◆─────	Mối quan hệ “thuộc về” mạnh mẽ. Sự tồn tại của phần phụ thuộc hoàn toànvào toàn bộ. (Hình kim cương đầy)

Ví dụ từ tài liệu đào tạo:

• Người → Người chặt gỗ (Đặc hóa: Người chặt gỗ kế thừa Tên, Giới tính)

• Rừng ◇─ Cây (Tổng hợp: Cây có thể tồn tại mà không cần một rừng cụ thể)

• Người chặt gỗ ◆─ Nhân viên (Thành phần: Nhân viên không thể tồn tại độc lập với thực thể Người chặt gỗ trong bối cảnh này)

---

5. Ứng dụng thực tế: Mô hình hóa Địa chính INSPIRE

Tài liệu đào tạo sử dụng Tiêu chuẩn dữ liệu INSPIRE về Địa chính để minh họa ứng dụng UML trong thực tế.

Bài tập 1: Mô hình hóa một lớp cốt lõi

Nhiệm vụ: Tạo lớp CadastralParcel lớp.
Cấu trúc giải pháp:

«featureType» CadastralParcel
- Địa chỉ : char
- APN (Số thửa) : char
- Biên giới : GM_Surface
- Tâm thửa : GM_Point
- Nhãn : char
- Tham chiếu quốc gia về thửa đất : String
- Giá trị diện tích : double (tùy chọn)
- Điểm tham chiếu : GM_Point (tùy chọn)

Ghi chú: Nhiều giải pháp hợp lệ tồn tại. Các thuộc tính nên phản ánh các đặc điểm phổ biến trong thực tế.

Bài tập 2: Mô hình hóa mối quan hệ

Nhiệm vụ: Kết nối CadastralParcel, CadastralBoundary, và AdministrativeZone.
Các quyết định mô hình hóa chính:

• CadastralParcel ──── CadastralBoundary: Liên kết/Tổ hợp (biên giới xác định thửa đất; thường 1..1 hoặc 1..* độ bội). Vai trò: +isBorder / +hasBorder.

• Lô đất ◇── Vùng hành chính: Tổ hợp/Quan hệ. Sự tồn tại của vùng này không phụ thuộc vào lô đất. Lô đất thuộc về nhiều vùng phân cấp (1..* đến 0..*).

• Bài học: Chọn loại quan hệ dựa trên mối quan hệ phụ thuộc vào vòng đời và quy tắc kinh doanh. Các sơ đồ phải phản ánh thực tế, không ép buộc các ràng buộc nhân tạo.

---

6. Các thực hành tốt nhất cho mô hình hóa UML hiệu quả

1. Sử dụng sơ đồ một cách chiến lược: Sơ đồ trực quan hóa các góc nhìn cụ thể. Không hệ thống phức tạp nào có thể được hiểu chỉ từ một sơ đồ duy nhất.

2. Tái sử dụng các thành phần trên nhiều sơ đồ: Một lớp duy nhất có thể xuất hiện trên sơ đồ lớp, máy trạng thái, sơ đồ tuần tự và sơ đồ triển khai, mỗi sơ đồ nhấn mạnh một khía cạnh khác nhau.

3. Phù hợp độ chính xác với đối tượng người xem: Điều chỉnh độ phức tạp của sơ đồ dựa trên việc người xem là người dùng cuối, nhà phát triển, nhà tích hợp hệ thống hay nhà quản lý dự án.

4. Kiểm tra tính đúng đắn với thực tế: Liên tục xác minh rằng các thành phần mô hình, mối quan hệ và các số lượng (cardinalities) phản ánh đúng hành vi hệ thống thực tế và các quy tắc lĩnh vực.

5. Tận dụng hỗ trợ từ công cụ: Sử dụng các công cụ tuân thủ UML (ví dụ: Sparx Systems) để thực hiện kỹ thuật chuyển đổi tiến/lùi, kiểm tra tính nhất quán và sinh mã.

---

Kết luận

UML là một ngôn ngữ mạnh mẽ và chuẩn hóa để giao tiếp, thiết kế và tài liệu hóa các hệ thống phần mềm và hệ thống tập trung dữ liệu. Bằng cách thành thạo các sơ đồ cốt lõi (đặc biệt là Sơ đồ lớp, Sơ đồ tuần tự, Sơ đồ hoạt động và Sơ đồ sử dụng) và hiểu rõ ngữ nghĩa các mối quan hệ (Quan hệ, Tổng quát hóa, Tổ hợp, Kết hợp), các chuyên gia có thể tạo ra những bản vẽ chi tiết, phù hợp với thực tế, giúp lấp đầy khoảng cách giữa các yêu cầu khái niệm và triển khai kỹ thuật.