Kinh nghiệm tạo biểu đồ Use Case

Theo đặc tả UML thì một biểu đồ use case (UC) là “biểu đồ mô tả mối quan hệ giữa các tác nhân (actor) và các use case trong một hệ thống”. Biểu đồ use case thường được sử dụng để:

• Cung cấp cách nhìn tổng quan về toàn bộ hoặc một phần các yêu cầu chức năng của một hệ thống hoặc một tổ chức dưới dạng một mô hình cô đọng (Constantine and Lockwood 1999; Ambler 2001) hay một mô hình tác nghiệp (Rational Corporation 2002)
• Trao đổi về phạm vi của một dự án phát triển (cái này theo tôi thấy rất quan trọng, thường người lập trình hay phải làm nhiều hơn những gì đã trao đổi với khách hàng)
• Mô hình hóa kết quả phân tích các yêu cầu chức năng dưới dạng một mô hình use case hệ thống (Cockburn 2001; Ambler 2001)

Một mô hình use case là tổ hợp của một hay nhiều biểu đồ UC và tất cả các tài liệu hỗ trợ như các đặc tả UC và các định nghĩa các tác nhân. Trong hầu hết các mô hình UC thì các đặc tả UC thường là nhân tố cơ bản nhất đóng vai trò hỗ trợ cho tính liên kết giữa các yêu cầu được mô hình hóa. Mô hình UC cần được phát triển trên góc độ của những người liên quan đến dự án (stakeholders) chứ không phải dưới góc độ của người phát triển (thường bị nhìn dưới góc độ kỹ thuật)
1. Use Cases (UC)

Một UC mô tả một dãy các hoạt động để cung cấp một chức năng nào đó cho một tác nhân. UC được biểu diễn bằng hình ellipse bẹt trong biểu đồ UC như trong hình 1.

1.1 Tên UC cần bắt đầu bằng một động từ mạnh

Vì UC mô tả một dãy các hoạt động nên nó phải có một tên phải ánh đúng thực tế này, tên cần bắt đầu bằng một động từ mạnh. Ví dụ một tên UC tốt là “Rút tiền”, “Đăng ký tham gia hội thảo” hay “Chuyển hàng” vì chúng cho biết rõ là UC làm gì

Các UC bắt đầu bằng các động từ yếu (chung chung) như là “xử lý”, “thực hiện” hay “làm”, “giải quyết” thường sẽ gây vấn đề. Những tên như vậy sẽ dẫn tới những khó khăn trong việc trao đổi giữa những người liên quan, đặc biệt là người trả tiền vì họ là những người quen với những cụm từ “rút tiền” hơn là “xử lý một thao tác rút tiền”, vì như vậy sẽ hạn chế việc chúng ta có thể hiểu đúng được các yêu cầu của họ. Thêm vào đó những tên như “Xử lý thao tác rút tiền” hay “Thực hiện việc đăng ký hội thảo” làm người ta có cảm giác các UC được viết dưới góc độ của hệ thống chứ không phải góc độ của người dùng, và vì thế có thể dẫn đến khả năng không phản ánh được đúng những yêu cầu của người chi tiền cho dự án.

1.2 Tên UC nên dùng thuật ngữ chuyên ngành

Tên của UC phải có ý nghĩa thật rõ ràng đối với người chi tiền cho dự án. Ví dụ nếu người ta không thể đoán ra nghĩa của cụm “Phân phối sản phẩm qua các phương tiện vận chuyển” thì có thể dùng cụm từ “Chuyển hàng”. Hãy nhớ rằng biểu đồ UC cung cấp cái nhìn tổng thể về các yêu cầu chức năng của hệ thống vì thế nó phải phản ảnh những thuật ngữ được dùng phổ biển trong chuyên nghành mà hệ thống phục vụ.

1.3 Đặt những UC cơ bản nhất vào góc trên bên trái của biểu đồ

Thói quen chúng ta là đọc từ trái qua phải, từ trên xuống dưới và bắt đầu bằng góc trên bên trái. Vì thế khi nhìn vào biểu đồ chúng ta thường nhìn vào đó đầu tiên, và đó chính là vị trí tốt nhất để đặt các UC mô tả những chức năng quan trọng nhất mà hệ thống cung cấp.

1.4 Ngầm ám chỉ thứ tự thời gian bằng cách sắp xếp chồng các UC

Mặc dù các biểu đồ UC KHÔNG hề phản ánh thứ tự thời gian thực hiện các UC như kiểu phải làm xong UC A thì mới đến UC B nhưng trên thực tế chúng ta có thể làm biểu đồ UC trở nên dễn đọc hơn bằng các bố trí các UC nhằm ám chỉ thời gian. Một trong những cách đó là xếp chồng chúng lên nhau như trong hình 1, ngầm nói lên các UC nằm trên thường được thi hành trước là các UC nằm dưới nó. Ví dụ phải mở tài khỏan trước khi có thể nộp tiền vào hoặc rút tiền ra và việc đóng tài khoản là làm sau cùng. Lưu ý rằng thứ tự đó chỉ là ngầm hiểu vì trong suốt thời gian tồn tại của một tài khoản thì việc nộp tiền và rút tiền không phải lúc nào cũng theo thứ tự đó. Và cũng chỉ nên thực hiện việc sắp xếp nếu bạn thực sự quen thuộc với các nguyên tắc tác nghiệp. (không thì hỏi khách hàng)

Hình 1. Ngầm ám chỉ thứ tự thời gian giữa các UC.

Nếu muốn ấn định rõ ràng thứ tự thời gian giữa các UC, ví dụ như một người mua hàng qua mạng bắt buộc phải cung cấp địa chỉ ngầm định trước khi có thể thực hiện các thao tác đặt hàng, hay một user phải được tạo ra trước khi đăng nhập hệ thống, khi đó chúng ta sẽ một tả các tiền điều kiện (precondition) vào bên trong các UC để thể hiện yêu cầu này.

Để ý là trong hình 1 có một chút mâu thuẫn với hướng dẫn là đặt các UC quan trọng nhất lên góc trên bên trái. Trong trường hợp này, nếu muốn nhấn mạnh về chức năng chung của hệ thống thì việc cố gắng bám theo thứ tự thời gian là kém cần thiết hơn.

2. Tác nhân (actor)

Một tác nhân có thể là một người, một tổ chức hoặc một hệ thống ngoài đóng vai trò tương tác với hệ thống cần xây dựng. Tác nhân được biểu diễn bằng hình người rơm trong biểu đồ UC.

2.1 Đặt các tác nhân cơ bản vào góc trên bên trái của biểu đồ

Thói quen bắt đầu đọc từ góc trên bên trái biến góc này thành góc để biểu diễn những thông tin quan trọng nhất vì thể các tác nhân cơ bản nên đặt gần góc này. Điều này cũng rất nhất quán với nguyên tắc đặt các UC cơ bản nhất vào góc trên bên trái vì thường các tác nhân cơ bản nhất cũng lại thường liên quan đển những UC cơ bản.

Ví dụ trong hình 2 thì tác nhân Khách hàng được đặt gần góc trên bên trái của biểu đồ, nếu không có khách hàng thì hệ thống bán hàng trực tuyến sẽ gặp rắc rối to. Đối diện với đó là tác nhân Hỗ trợ khách hàng được đặt ở bên phải. Đồng thời cũng thấy rằng 2 UC quan trọng nhất để hỗ trợ cho việc bán một sản phẩm trên web cũng được đặt ở góc trên bên trái. Nguyên tắc ám chỉ thứ tự thời gian cũng được áp dụng để biểu diễn thứ tự Tim mặt hàng rồi mới đến Đặt hàng.

Hình 2. Mua hàng trực tuyến.

2.2 Vẽ các tác nhân ra ngoài diềm của biểu đồ UC

Mặc dầu các tác nhân tương tác với hệ thống nhưng họ vượt ra ngoài phạm vi kiểm soát của dự án. Điều này có thể thể hiện bằng cách vẽ các tác nhân ra ngoài diềm của biểu đồ UC. Trong hình 2 có thể thấy các tác nhân được đặt bên ngoài của biểu đồ chứ không phải là đặt vào trong lòng.

2.3 Đặt tên tác nhân bằng các danh từ đơn liên quan đến tác nghiệp

Tên của một tác nhân phải phản ảnh đúng vai trò của nó trong mô hình. Tên tác nhân thường là một danh từ đơn như là “Khách hàng”, “Quản trị” hay “Người duyệt”.

2.4 Mỗi tác nhân đều phải gắn với UC

Mỗi tác nhân đều phải liên quan đến ít nhất là 1 UC và UC nào cũng phải liên quan đến ít nhất 1 UC. Nhớ lại định nghĩa về UC là nó cung cấp một dịch vụ hữu ích nào đó cho một tác nhân. Nếu một UC không cung cấp được một dịch vụ nào cho ít nhất một tác nhân thì chúng ta cần UC đó làm gì? Một tác nhân không tham gia một UC nào thì tại sao phải mô hình hóa nó. (lập trình hướng chức năng thì cứ làm chức năng mà chẳng cần quan tâm là sau ai dùng!) Không nhất thiết là phải có tương ứng một – một giữa UC và tác nhân. Ví du trong hình 2, tác nhân “Khách hàng” liên quan đến vài UC trong khi đó UC “Nhận trợ giúp” lại có tới 2 tác nhân liên quan.

2.5 Tác nhân đại diện cho vai trò chứ không phải chức vụ

Một lỗi rất hay gặp với những người mới làm mô hình UC là thường sử dụng chức vụ của mọi người chứ không phải vai trò mà người đó đảm nhiệm khi đặt tên cho các tác nhân. Điều này sẽ dẫn tới một loạt tác nhân kiểu “Nhân viên tập sự”, “Nhân viên chính”, “Phó phòng” thay cho một tác nhân duy nhất là “Hỗ trợ khách hàng” như trong hình 2. Một dấu hiệu dễ thấy khi bạn mắc phải lỗi sử dụng chức vụ thay cho vai trò là có một số tác nhân với một số tên na na nhau đều liên quan đến cùng một (hay nhiều) UC.

Việc mô hình hóa vai trò chứ không dùng chức vụ không chỉ giúp đơn giản hóa biểu đồ UC mà con giúp cho biểu đồ UC của bạn có được tính độc lập với cấu trúc tổ chức bộ máy hành chính trong đơn vị sử dụng: bạn chắc chắn không muốn phải đổi tên tác nhân chỉ vì phòng tổ chức cán bộ đổi chức danh của “Cán bộ hỗ trợ kỹ thuật” thành “Chuyên viên mạng”. Cũng từ điều này chúng ta thấy “người rơm” trong biểu đồ UC phải gọi là “vai trò” mới đúng chứ không nên gọi là “tác nhân”

Tuy nhiên phải nhắc đến một yếu tố là nếu bạn làm việc trong một môi trường tương đối coi trọng tính “chính trị” thì việc đưa vào một vài tác nhân mang tên các chức vụ có thể mang lại những sự ủng hộ nhất định thì cũng nên cân nhắc ;). Ví dụ như khi xây dựng hệ thống hỗ trợ bán hàng qua mạng cho một công ty có một công đoàn mạnh đại diện cho cả ngàn nhân viên bán hàng, biểu đồ của chúng ta có thể đưa vào một vài vị trí trong đội ngũ bán hàng làm tên tác nhân để làm yên lòng công đoàn là các công đoàn viên sẽ không bị mất việc vào tay hệ thống tự động.

(Tôi cũng làm hệ thống trong đó tác nhân có tên như “Giám đốc” hay “Chủ tịch” gây được hứng thú đặc biệt cho khách hàng, trong khi đó thực ra tác nhân đó phải đặt tên là “người ký duyệt” – nghe hơi tầm thường)

2.6 Sử dụng kiểu để biểu diễn các tác nhân hệ thống

Trong hình 2 ta có thể nhận ra là “Bộ xử lý thanh toán” là một hệ thống tự động chứ không phải con người hay một tổ chức bởi vì có kiểu chỉ định rõ ràng. Kiểu được sử dụng trong các biểu đồ UC cụ thể trong đó quyết định về kiến trúc đã rõ ràng chứ không áp dụng cho khác biểu đồ UC cơ bản ban đầu khi phân tích hay không sử dụng trong biểu đồ UC tác nghiệp vì các biểu đồ này cần được độc lập với công nghệ.

2.7 Các tác nhân không tương tác với nhauCho dù trên thực tế các tác nhân có thể tương tác với nhau nhưng thông tin nay không thể được biểu diễn trong biểu đồ UC – bạn không bao giờ được phép vẽ một liên kết từ mội tác nhân tới một tác nhân khác (quan hệ thừa kế giữa 2 tác nhân thì tồn tại nhưng không hề biểu diễn sự tương tác). Điều này vẫn đúng kể cả khi UC mô tả sự tương tác giữa 2 tác nhân trong hệ thống. Ví dụ UC “Nhận trợ giúp” trong hình 2 mô tả việc một người nào đó trong vai trò “Hỗ trợ khách hàng” thực hiện việc trợ giúp một ai đó đang ở vai trò “Khách hàng”. Lúc này vấn đề chi tiết của quá trình tương tác giữa hai tác nhân này sẽ được viết trong phần mô tả UC chứ không phải được mô tả bằng một đường kẻ giữa hai tác nhân trong biểu đồ.

(Bài viết của anh Bùi Trường Sơn - PTIT)
--YHT