Tóm tắt nhanh

• UML (Unified Modeling Language): Là ngôn ngữ mô hình hóa tiêu chuẩn, đóng vai trò như một "bản thiết kế kỹ thuật" (blueprint) giúp thống nhất tư duy giữa khách hàng và lập trình viên trước khi bắt tay vào viết code.
• Mục tiêu: Trực quan hóa cấu trúc và hành vi hệ thống, giúp giảm thiểu sai sót và tối ưu hóa thời gian phát triển.
• Structure Diagrams (Biểu đồ Cấu trúc): Tập trung vào khía cạnh tĩnh của hệ thống (hệ thống có những thành phần gì và liên kết ra sao).
• Chúng ta có 7 loại biểu đồ cấu trúc chính:
  1. Class Diagram: Bản thiết kế các lớp và quan hệ (Generalization, Association).
  2. Object Diagram: Ảnh chụp thực tế của các đối tượng tại một thời điểm.
  3. Package Diagram: Tổ chức hệ thống thành các nhóm chức năng (Folders).
  4. Component Diagram: Mô tả các thành phần vật lý (file, thư viện) và giao tiếp Black box/White box.
  5. Composite Structure: Đi sâu vào kết nối nội bộ qua các Port và Connector.
  6. Deployment Diagram: Phân bổ phần mềm lên phần cứng thực tế và các kênh truyền thông.
  7. Profile Diagram: Tùy biến UML cho các chuyên ngành đặc thù (như Hệ thống nhúng/IoT).

1. Khái niệm UML

• Hãy thử tưởng tượng rằng bạn muốn phát triển một software system mà khách hàng yêu cầu. Thử thách đầu tiên mà bạn phải đối mặt không phải là code, cũng không phải platform hay ngôn ngữ lập trình mà nó chính là việc bạn phải thống nhất được với khách hàng về cái mà khách hàng thực sự muốn với cái mà bạn đang hiểu hay không. Đây là bước đầu thực sự quan trọng mà các lập trình viên thường bỏ qua hoặc không làm chuẩn dẫn tới việc tốn nhiều thời gian để xử lý và chỉnh sửa sau này.
• Vậy điều bạn thực sự cần làm là gì? Đơn giản là tạo ra một mô hình cho software của bạn (Modeling). Model này sẽ làm nổi bật những khía cạnh quan trọng của phần mềm trong một khuôn mẫu một cách đơn giản nhất có thể, bỏ qua những chi tiết không liên quan nhưng vẫn làm nổi bật lên những chi tiết quan trọng. Khi này, ngôn ngữ mô hình hóa (modeling language) ra đời, nó cho phép chúng ta có những luật được định nghĩa rõ ràng để mô tả về software như kiến trúc, chức năng, ...
• UML (Unified Modeling Language) là một ngôn ngữ mô hình hóa chuẩn dùng để mô tả, trực quan hóa, xây dựng và làm tài liệu cho các khía cạnh của một hệ thống phần mềm.
• Thay vì dùng code thuần túy hay văn bản dài dòng, UML sử dụng các ký hiệu hình học để biểu diễn cấu trúc và hành vi của hệ thống. Hãy coi UML như một "bản thiết kế kỹ thuật" (blueprint) trong xây dựng; trước khi xây nhà, bạn cần bản vẽ, và UML chính là bản vẽ đó cho phần mềm.
• UML cho phép chúng ta trình bày các khía cạnh rất đa dạng của một hệ thống phần mềm (ví dụ:requirements, data structures, data flows,...) trong một khuôn khổ duy nhất bằng cách sử dụng các khái niệm hướng đối tượng.

2. Diagram

• Trong UML, một mô hình được biểu diễn bằng hình ảnh dưới dạng sơ đồ (Diagram). Một sơ đồ cung cấp một cái nhìn thực tế được mô tả bởi mô hình (model). Đó là những sơ đồ chỉ ra những tính năng người dùng sử dụng và kiến trúc của hệ thống mà không đưa ra việc triển khai hay cài đặt cụ thể.
• UML đề xuất 14 loại sơ đồ mô tả những kiến trúc hoặc hành vi khác nhau của hệ thống như sau:

2.1. Structure Diagram

• Structure Diagram là một nhóm các biểu đồ dùng để mô tả kiến trúc, mối quan hệ bên trong của một hệ thống. Nếu ví hệ thống là một ngôi nhà thì Structure Diagram chính là một bản vẽ mặt bằng, sơ đồ điện nước và các kết cấu bê tông cột dầm. Nó cho phép chúng ta biết hệ thống có những thành phần gì và chúng liên kết với nhau như thế nào nhưng không cần quan tâm đến việc các thành phần đó hoạt động ra sao hay tương tác với nhau như thế nào.
• UML đề xuất 7 kiểu sơ đồ cho việc mô hình hóa kiến trúc (Modeling structure) của một hệ thống từ những góc độ khác nhau như Class Diagram, Object Diagram, Package Diagram, Component Diagram, Compossition Structure Diagram, Deployment Diagram và Profile Diagram.

2.1.1. The Class Diagram

• Khái niệm Class diagram bắt nguồn từ khái niệm mô hình hóa dữ liệu (data modeling) và phát triển phần mềm theo hướng đối tượng (object-oriented software development). Những khái niệm này được sử dụng để chỉ ra kiến trúc dữ liệu (data structure) và kiến trúc đối tượng (object structure) của một hệ thống. Class Diagram một cách cơ bản được dựa trên khái niệm class, tính khái quát hóa (generalization) và sự kết hợp (association). Ví dụ, một class diagram, bạn có thể model những class Course, Student và Professor xuất hiện trong hệ thống. Professor sẽ dạy hóa học và Student sẽ tham gia khóa học. Tuy nhiên, Student và Professor lại có những đặc điểm chung như là cả hai đều là con người (Person). Và để biểu hiện được các khía cạnh này, chúng ta sẽ thể hiện bằng một quan hệ khái quát hóa (generalization relationship).

2.1.2. The Object Diagram

• Dựa trên định nghĩa liên quan tới Class Diagram, một Object Diagram đưa ra một cái nhìn tổng thể của trạng thái hệ thống (system state) tại một thời điểm thực thi cụ thể. Ví dụ, một Object Diagram có thể đưa ra rằng một Professor tên là Henry Foster dạy khóa hoạc Object-Oriented Modeling và Object Oriented Programming. Hiểu đơn giản thì Class Diagram cho chúng ta một cái nhìn tổng quan về một Class trong khi Object Diagram cho chúng ta những đặc điểm chi tiết hơn của object (một instance của class) tại một thời điểm cụ thể.

2.1.3. The Package Diagram

• Pakage Diagram là một sơ đồ dùng trong việc nhóm các diagram hoặc các thành phần của model theo như những đặc điểm chung của chúng (chẳng hạn như các chức năng liên kết - functional cohesion). Ví dụ, trong một hệ thống quản lý trường đại học, bạn có thể giới thiệu những packages chứa các thông tin về giảng dạy, nghiên cứu và quản lý.
• Hãy tưởng tượng bạn có hàng trăm Class (Lớp) trong một dự án. Nếu để tất cả ở một nơi, bạn sẽ bị "ngộp". Package đóng vai trò như các thư mục (folders) trên máy tính. Bạn gom những thứ liên quan lại với nhau để dễ quản lý.
• Các packages thường được tích hợp trong những biểu đồ khác hơn là hiển thị trong những sơ đồ riêng biệt. Điều này có nghĩa rằng trong một biểu đồ lớn, người ta sẽ vẽ một "Cái hộp" lớn đại diện cho Package bao quanh các class giúp người xem hiểu được rằng nhóm này thuộc về module nào.

• Như hình trên, ta có thể thấy trong pakages web lại chứa các pakages khác như serviets, transformers,...

2.1.4. The Component Diagram

• Trong UML, Component Diagram là một loại biểu đồ cấu trúc dùng để mô tả cách một hệ thống phần mềm được chia thành các thành phần vật lý (components) và mối quan hệ phụ thuộc giữa các thành phần đó.

• Một component là một đơn vị độc lập, có thể thực thi và cung cấp có các component khác những service hoặc sử dụng services của những components khác.

• Trong hệ thống software, một component có thể là một file C/C++, một thư viện .dll, một file thực thi .exe hay thậm chí là một database.

• Khi nói về một Component cụ thể, bạn có thể model chúng theo hai "cách nhìn" như sau:

  • Cái nhìn bên ngoài (External View hay Black Box View): là việc bạn coi thành phần đó như một chiếc hộp kín và không quan tâm bên trong nó có gì, bạn chỉ cần quan tâm nó làm được gì, cho bạn những thông tin, service gì phục vụ cho hệ thống.
  • Cái nhìn bên trong (Internal View hay White Box View): là việc bạn phân tích kỹ bên trong làm việc như thế nào, ngôn ngữ gì, thuật toán ra sao.

2.1.5. The Composition Structure Diagram

• Trong UML, Composite Structure Diagram là một biểu đồ cấu trúc dùng để mô tả cấu trúc bên trong của một thực thể (thường là một Class, một Component hoặc một Collaboration).
• Nó đi sâu vào chi tiết hơn Class Diagram. Nếu Class Diagram chỉ cho biết "Lớp A có quan hệ với Lớp B", thì Composite Structure Diagram sẽ chỉ rõ "Phần nào bên trong A kết nối với phần nào bên trong B thông qua cái cổng (port) nào".

2.1.6. The Deployment Diagram

• Deployment Diagram là một loại biểu đồ cấu trúc dùng để mô tả sự phân bổ vật lý của các thành phần phần mềm trên các thiết bị phần cứng.
• Nếu các biểu đồ trước đó (như Class hay Component Diagram) tập trung vào "phần mềm được thiết kế thế nào", thì Deployment Diagram trả lời câu hỏi: "Phần mềm sẽ được cài đặt và chạy ở đâu trong thế giới thực?".

2.1.7. The Profile Diagram

• Profile Diagram là một loại biểu đồ cấu trúc đặc biệt. Nó không dùng để mô tả hệ thống phần mềm của bạn, mà dùng để mở rộng hoặc tùy biến chính ngôn ngữ UML cho một mục đích, lĩnh vực hoặc công nghệ cụ thể.
• Hãy tưởng tượng UML là một bộ từ điển tiếng Anh chung. Profile Diagram giống như việc bạn tạo ra một cuốn "từ điển chuyên ngành" (ví dụ: tiếng Anh chuyên ngành Y khoa hay Kỹ thuật nhúng) dựa trên cuốn từ điển chung đó, nhằm giúp việc diễn đạt chính xác và sát thực tế hơn.

Kết luận

• Việc nắm vững UML không chỉ dừng lại ở việc biết vẽ các hình khối, mà cốt lõi nằm ở khả năng tư duy hệ thống. Qua bài viết này, chúng ta đã cùng nhau khám phá bức tranh toàn cảnh về Structure Diagrams – nền tảng vững chắc để định hình "bộ khung" cho bất kỳ hệ thống phần mềm nào, từ những ứng dụng quản lý phức tạp đến các hệ thống nhúng đòi hỏi sự chính xác cao.
• Bằng cách sử dụng các biểu đồ cấu trúc, bạn không chỉ tạo ra một tài liệu kỹ thuật chuẩn mực mà còn xây dựng được một "ngôn ngữ chung" để làm việc hiệu quả với khách hàng và đồng nghiệp, giúp dự án đi đúng hướng ngay từ những bước đầu tiên.
• Tuy nhiên, một hệ thống không chỉ cần một bộ khung vững chãi mà còn cần những quy tắc vận hành linh hoạt. Làm thế nào để mô tả các luồng xử lý dữ liệu? Người dùng sẽ tương tác với hệ thống ra sao? Các trạng thái của thiết bị thay đổi như thế nào theo thời gian?
• Câu trả lời sẽ nằm trong bài viết tiếp theo: "Behavior Diagrams – Thổi hồn vào mô hình hệ thống". Chúng ta sẽ cùng tìm hiểu về Use Case, Sequence, State Machine và nhiều hơn thế nữa. Đừng bỏ lỡ nhé!