Trong thế giới phát triển phần mềm, việc hình dung, thiết kế và tài liệu về các hệ thống và quy trình phần mềm là rất quan trọng. Để đạt được mục tiêu này, các nhà phát triển đã tạo ra một công cụ mạnh mẽ: UML (Unified Modeling Language). Trong bài này, chúng ta sẽ cùng tìm hiểu UML là gì và các loại UML phổ biến.

1. UML là gì?

UML (viết tắt của Unified Modeling Language - Ngôn ngữ mô hình thống nhất) là một công cụ mô hình hóa tiêu chuẩn được sử dụng rộng rãi trong quá trình phát triển phần mềm.

Vào năm 1981, với mong muốn chuẩn hóa các hệ thống ký hiệu khác nhau và các phương pháp tiếp cận thiết kế phần mềm, UML được tạo ra ở Rational Software - doanh nghiệp thành lập bởi Paul Levvy và Mike Devlin.

Đến năm 2005, UML trở nên phổ biến toàn cầu vì được Tổ chức Tiêu chuẩn hóa Quốc tế (ISO) và Ủy ban Kỹ thuật Điện Quốc tế (IEC) công bố là tiêu chuẩn ISO/IEC 19501.

2. Tác dụng của UML trong phát triển phần mềm

Dưới đây là một số tác dụng chính của UML trong phát triển phần mềm:

2.1. Phân tích và thiết kế hệ thống

UML cho phép các nhà phát triển và các bên liên quan hình dung hệ thống thông qua các biểu đồ khác nhau, giúp hiểu rõ cấu trúc và hành vi của hệ thống trước khi bắt đầu quá trình lập trình. Điều này là cực kỳ quan trọng trong việc định hình yêu cầu và giảm thiểu rủi ro sai sót trong quá trình phát triển.

2.2. Tài liệu hóa hệ thống

UML cung cấp một phương tiện tiêu chuẩn để tài liệu hóa các yếu tố của hệ thống, bao gồm cấu trúc dữ liệu, logic kinh doanh, luồng công việc, và các tương tác giữa các đối tượng. Việc tài liệu hóa giúp đảm bảo rằng thông tin về hệ thống có thể được chia sẻ một cách dễ dàng và hiệu quả giữa các nhóm phát triển và bảo trì.

2.3. Giao tiếp

UML cung cấp một ngôn ngữ chung cho các nhà phát triển, kiến trúc sư, quản lý dự án, và các bên liên quan khác, giúp cải thiện giao tiếp và hiểu biết chung về hệ thống. Sử dụng UML giảm thiểu khả năng hiểu lầm và sai sót trong quá trình thiết kế và phát triển.

2.4. Quản lý rủi ro và đánh giá tác động

UML cho phép các nhà phát triển và quản lý dự án đánh giá tác động của các thay đổi trước khi chúng được thực hiện, giúp quản lý rủi ro một cách hiệu quả. Các biểu đồ UML giúp nhìn nhận trước được các vấn đề tiềm ẩn và tìm ra giải pháp trước khi chúng trở nên nghiêm trọng.

3. Các loại UML hay dùng

UML bao gồm nhiều loại biểu đồ khác nhau, mỗi loại phục vụ một mục đích cụ thể, có thể tạm chia UML thành 2 nhóm chính, chứa các loại UML hay dùng như sau:

1. Behavior diagrams (Biểu đồ hành vi): Use case digram, activity diagram, sequence diagram.
2. Structure diagrams (Biểu đồ cấu trúc): Class diagram, component diagram, deployment diagram.

3.1. Use case diagram

Use case diagram tập trung vào việc mô tả chức năng của hệ thống từ quan điểm của người dùng cuối. Nó hiển thị các tình huống sử dụng cụ thể (use case) và các actor liên quan, giúp làm rõ các yêu cầu và tương tác giữa người dùng và hệ thống, qua đó đảm bảo rằng sản phẩm phần mềm cuối cùng sẽ đáp ứng được nhu cầu thực tế.

Use case diagram thường được sử dụng trong giai đoạn thu thập yêu cầu và phân tích yêu cầu của dự án phần mềm.

3.1.1. Các thành phần chính của use case diagram

Use case diagram bao gồm 4 thành phần chính:

1. Actor: Đại diện cho một người dùng hoặc một hệ thống bên ngoài tương tác với hệ thống. Actors có thể là người dùng cuối, hệ thống bên ngoài, hoặc quá trình tự động. Trong biểu đồ, một actor thường được biểu diễn bằng một hình người.
2. Use case: Một use case mô tả một chuỗi hành động mà hệ thống thực hiện để mang lại kết quả có giá trị cho một actor. Mỗi Use case thể hiện một chức năng cụ thể hoặc một quy trình công việc mà hệ thống cần phải thực hiện.
3. Mối quan hệ: Mối quan hệ giữa các actors và use cases được mô tả thông qua 4 kiểu khác nhau là association, extend, include và generalization. Mối quan hệ này giúp làm rõ cách các actors tương tác với use cases và mối liên hệ giữa các use cases với nhau.
4. Hệ thống: Là ranh giới chỉ ra phạm vi của hệ thống đang được mô tả. Mọi use case đều nằm bên trong ranh giới của hệ thống, và các actor thì nằm bên ngoài.

3.1.2. Các bước cơ bản để tạo use case diagram

Các bước cơ bản để tạo use case diagram bao gồm:

1. Phân tích yêu cầu của hệ thống
2. Xác định actors: Xác định ai sẽ sử dụng hệ thống, bao gồm cả người dùng cuối và các hệ thống khác có tương tác.
3. Xác định use cases: Liệt kê tất cả các chức năng mà hệ thống phải cung cấp cho các actors. Điều này bao gồm cả việc mô tả chi tiết các bước thực hiện cho mỗi chức năng.
4. Mô tả mối quan hệ: Mô tả các mối quan hệ giữa các use cases (như extend và include) và giữa actors và use cases thông qua các ký hiệu cụ thể (được gọi là notation).
5. Vẽ biểu đồ: Sử dụng các biểu tượng tiêu chuẩn để vẽ actors, use cases, và mô tả các mối quan hệ giữa chúng.

3.1.3. Ví dụ về use case diagram

Để mô tả cách tạo use case diagram, tôi sẽ lấy ví dụ về hệ thống cho mượn sách.

Dưới đây là những requirement của hệ thống:

• Mô hình kinh doanh chủ yếu từ việc cho mượn sách.
• Người dùng phải đăng ký thẻ thành viên để thuê sách, với mức phí làm thẻ dựa trên các gói Basic, Standard và Premium. Người dùng có thể thanh toán bằng tiền mặt hoặc qua ví điện tử.
• Khi người dùng đăng ký mượn sách, nếu sách đã bị thành viên khác mượn, hệ thống sẽ ghi nhận lại và thông báo qua email và tin nhắn khi sách được hoàn trả.
• Khi người dùng đăng ký mượn sách, nếu sách không tồn tại trong hệ thống thì hệ thống sẽ ghi nhận và thông báo qua email và tin nhắn khi sách được nhập về.
• Thủ thư là người tiếp nhận các yêu cầu đăng ký thành viên, mượn/trả sách.
• Hệ thống sẽ gửi email đề xuất các đầu sách phù hợp cho từng thành viên.

Từ những requirement trên, chúng ta thấy hệ thống bao gồm có 3 actor: thành viên (member), thủ thư (librarian) và hệ thống (system).

Các use case của hệ thống bao gồm:

• Đăng ký thẻ thành viên (Register for a membership card)
• Thanh toán (Payment) bằng tiền mặt (With cash) hoặc bằng ví điện tử (With eWallet).
• Mượn sách (Borrow book)
• Trả sách (Return book)
• Đăng ký mượn sách chưa có trong cửa hàng (Pre-register if book is not available).
• Đặt hàng sách mới (Restock book).
• Thông báo sách được trả qua email (Notify return timings via email).
• Thông báo sách được trả qua tin nhắn (Notify return timings via phone message).
• Thông bao sách mới đã về qua email (Notify restock timings via email).
• Thông bao sách mới đã về qua tin nhắn (Notify restock timings via phone message).

Tôi vẽ được use case diagram như hình dưới. Trong đó, hình chữ nhật màu xanh lá biểu diễn cho hệ thống. Các hình elip màu trắng nằm trong hình chữ nhật xanh lá là các use case của hệ thống. Hình người là các actor. Người dùng trong hệ thống sẽ có 2 loại là member và librarian.

Để làm rõ hơn cách sử dụng các ký hiệu trong use case diagram, mời các bạn tham khảo bài viết khác có nội dung chi tiết hơn là Giải thích các ký hiệu trong use case diagram.

3.2. Class diagram

Class diagram là một trong những loại biểu đồ UML phổ biến nhất, cung cấp cái nhìn tổng quan về cấu trúc của hệ thống. Nó mô tả các class, properties, method và mối quan hệ giữa chúng, như kế thừa và liên kết, giúp xác định rõ cấu trúc và thiết kế của phần mềm.

3.2.1. Các thành phần chính của class diagram

Class diagram bao gồm 3 thành phần chính:

1. Class: Được biểu diễn bằng một hình chữ nhật chia làm ba phần: tên class, thuộc tính, và phương thức.
2. Interface: Được biểu diễn tương tự như class nhưng với từ khóa «interface».
3. Mối quan hệ: Mối quan hệ giữa các class và interface được mô tả thông qua 6 kiểu khác nhau là association, inheritance , implementation, dependency, aggregation và composition.

3.2.2. Các bước cơ bản để tạo class diagram

Các bước cơ bản để tạo class diagram bao gồm:

1. Phân tích yêu cầu của hệ thống
2. Xác định class và interface: Xác định class và interface từ yêu cầu của hệ thống.
3. Xác định thuộc tính và phương thức: Liệt kê tất cả các thuộc tính và phương thức mà class/interface phải cung cấp dựa vào chức năng và nhiệm vụ của chúng.
4. Mô tả mối quan hệ: Mô tả các mối quan hệ giữa các class (như extend và include) và giữa class và interface thông qua các ký hiệu cụ thể (được gọi là notation).
5. Vẽ biểu đồ: Sử dụng các biểu tượng tiêu chuẩn để vẽ class, interface và mô tả các mối quan hệ giữa chúng.

3.2.3. Ví dụ về class diagram

Tôi sẽ sử dụng bài toán thiết kế hệ thống cho mượn sách ở ví dụ về use case diagram ở mục 3.1.3 để vẽ class diagram.

3.3. Component diagram

Component diagram được sử dụng để biểu diễn các thành phần phần mềm khác nhau và mối quan hệ giữa chúng trong hệ thống. Biểu đồ này chủ yếu tập trung vào các khía cạnh vật lý của hệ thống phần mềm, bao gồm việc triển khai và tổ chức của code, thư viện, và các mô-đun.

3.3.1. Các thành phần chính của component diagram

Component diagram bao gồm 3 thành phần chính:

1. Component: Được biểu diễn bằng một hình chữ nhật có biểu tượng bốn hình chữ nhật nhỏ ở góc. Mỗi thành phần đại diện cho một mô-đun của code hoặc một nhóm các chức năng có liên quan, ví dụ như một thư viện, một gói phần mềm, hoặc một dịch vụ web.
2. Interface: Mô tả một tập các hoạt động mà một component cung cấp hoặc yêu cầu từ các component khác. Interface được biểu diễn bằng một hình chữ nhật nhỏ hoặc một hình lục giác đính kèm bên ngoài thành phần.
3. Quan hệ phụ thuộc: Mô tả sự phụ thuộc giữa các thành phần, chẳng hạn như khi một thành phần sử dụng dịch vụ hoặc chức năng từ thành phần khác.

3.3.2. Các bước cơ bản để tạo component diagram

Các bước cơ bản để tạo component diagram bao gồm:

1. Phân tích yêu cầu của hệ thống
2. Xác định component và interface: Xác định class và interface từ yêu cầu của hệ thống.
3. Mô tả mối quan hệ: Mô tả các mối quan hệ giữa các class (như extend và include) và giữa class và interface thông qua các ký hiệu cụ thể (được gọi là notation).
4. Vẽ biểu đồ: Sử dụng các biểu tượng tiêu chuẩn để vẽ component, interface và mô tả các mối quan hệ giữa chúng.

3.3.3. Ví dụ về component diagram

Ví dụ về component diagram cho BookService và RequestService.

3.4. Sequence diagram

Sequence diagram chủ yếu tập trung vào cách các đối tượng trong hệ thống tương tác với nhau theo thời gian. Nó mô tả trình tự các thông điệp được trao đổi giữa các đối tượng để thực hiện một chức năng, là công cụ hữu ích để phân tích và thiết kế luồng điều khiển.

3.4.1. Các thành phần chính của sequence diagram

Component diagram bao gồm 4 thành phần chính:

1. Object: Được biểu diễn bằng một hình chữ nhật trên cùng của một cột và có tên đối tượng bên trong. Mỗi đối tượng có một cột thời gian (lifeline) xuống dưới, biểu diễn trên trục dọc.
2. Lifeline: Một đường thẳng dọc biểu diễn sự tồn tại của đối tượng trong quá trình tương tác.
3. Message: Các thông điệp hoặc hành động được truyền từ đối tượng này sang đối tượng khác, biểu diễn bằng mũi tên. Thông điệp có thể là đồng bộ (solid line), bất đồng bộ (dashed line), hoặc trả về (dotted line).
4. Activation: Một hình chữ nhật nhỏ trên lifeline chỉ thời gian một đối tượng thực hiện một hành động nào đó.

3.4.2. Các bước cơ bản để tạo sequence diagram

Các bước cơ bản để tạo sequence diagram bao gồm:

1. Phân tích yêu cầu của hệ thống
2. Xác định object: Xác định các object từ yêu cầu của hệ thống.
3. Mô tả lifeline của object: Vẽ một lifeline dọc cho mỗi đối tượng đã xác định. Lifeline biểu diễn sự tồn tại của một đối tượng trong quá trình tương tác được mô tả.
4. Xác định message: Xác định tất cả các message (hoặc hành động) diễn ra giữa các object trong quá trình và thêm chúng vào biểu đồ. Message được biểu diễn dưới dạng mũi tên giữa các lifeline. Mỗi message nên có tên và được sắp xếp theo trình tự thời gian từ trên xuống dưới.
5. Mô tả activation: Activation biểu diễn khoảng thời gian một đối tượng thực hiện một công việc nào đó. Nếu cần, bạn có thể thêm các hình chữ nhật nhỏ trên lifeline để mô tả thời gian thực thi của một hành động hoặc quy trình.
6. Vẽ biểu đồ: Sử dụng các biểu tượng tiêu chuẩn để vẽ object, lifeline, message, activation và mô tả các mối quan hệ giữa chúng.

3.4.3. Ví dụ về sequence diagram

Đây là ví dụ sequence diagram cho luồng tìm kiếm sách và mượn sách.

• Luồng tìm kiếm sách: User tương tác với giao diện FE để tìm kiếm sách. FE gọi request tới BE server. BE server kiểm tra membership của user, nếu có membership thì trả về thông tin sách trong DB.
• Luồng mượn sách: User tương tác với giao diện FE để tạo request mượn sách. Tương tự, FE gọi request tới BE server. BE server kiểm tra membership của user, nếu có membership, tiếp tục check xem sách có tồn tại trong hệ thống hoặc chưa được người khác mượn, nếu ok thì tạo request mượn sách cho user.

4. Tổng kết

UML (viết tắt của Unified Modeling Language - Ngôn ngữ mô hình thống nhất) là ngôn ngữ mô hình hóa trực quan nhằm cung cấp một cách tiêu chuẩn để trực quan hóa thiết kế của một hệ thống.

UML bao gồm nhiều loại biểu đồ khác nhau, mỗi loại phục vụ một mục đích cụ thể, có thể tạm chia UML thành 2 nhóm chính: behavior diagram và structure diagram.

Mỗi loại biểu đồ UML có mục đích riêng và được sử dụng tại các giai đoạn khác nhau trong chu trình phát triển phần mềm. Sự kết hợp linh hoạt của các biểu đồ này không chỉ giúp các nhà phát triển và các bên liên quan hiểu rõ hơn về hệ thống mà còn hỗ trợ quá trình thiết kế và triển khai phần mềm một cách hiệu quả.

Đọc thêm các bài viết hữu ích khác từ blog 200Lab:

• DevOps Cloud là gì?
• Concurrency Pattern trong Golang - phần 1
• Làm thế nào để trở thành Cloud DevOps Engineer chuyên nghiệp?