7.3.1. Biểu đồ use-case
Use-case như tên gọi của nó, là một trường hợp sử dụng của hệ thống, nó mô tả một chuỗi hành động mà hệ thống sẽ thực hiện để đạt được kết quả có ý nghĩa đối với một tác nhân nào đó.
Tác nhân (actor) ở đây có thể là người hoặc hệ thống tương tác với use-case. Thường actor là một người sử dụng hệ thống. Trong UML tác nhân thường là một lớp.
Một biểu đồ use-case (use-case diagram) được tạo ra từ các hình ô van (biểu diễn use-case) và
hình người (biểu diễn tác nhân sử dụng user-case). Tên của tác nhân (actor) được đặt phía dưới hình người, tên của use-case được đặt bên trong hình ô van hoặc phía dưới. Chúng được liên kết với nhau bằng các đoạn thẳng để chỉ rõ tác nhân nào sử dụng use-case nào.
Các biểu đồ use-case (sẽ được gọi là mô hình use-case) cung cấp một bức tranh toàn cảnh về những gì đang xảy ra trong hệ thống (hiện tại hay dự định xây dựng), cụ thể hơn, mô hình use-
case cho ta câu trả lời cho câu hỏi: ai (hoặc hệ thống nào) sử dụng phần mềm và sử dụng để
làm gì. Các use-case được Jacobson đưa ra vào năm 1992, ban đầu được được thực hiện trong
công ty Ericsson, Thụy điển. Trong cách tiếp cận của Jacobson thì use-case là điểm bắt đầu
trong quá trình xây dựng một hệ thống phần mềm mới. Trong thuật ngữ UML thì gói use- case là một gói con (sub-package) của gói Behavioural Element (phần tử hành vi). Nghĩa là nó được sử dụng để xác định hành vi của một thực thể. Use-case không xác định chi tiết các hành vi được thực hiện như thế nào, chi tiết này sẽ được thảo luận trong các mô hình khác của quy trình thiết kế hệ thống. Thông thường, cách thực hiện một use-case được định nghĩa trong một hoặc nhiều mô hình cộng tác (collaboration diagram) nhằm biểu diễn sự tương tác giữa các đối tượng cùng hoạt động.
Mục đích của biểu đồ use-case:
- Dùng để mô hình hóa các chuỗi hành động của hệ thống.
- Cung cấp một cách nhìn tổng thể về những gì mà hệ thống sẽ làm và ai sẽ dùng nó. - Đưa ra cơ sở để xác định giao tiếp người-máy của hệ thống.
- Dùng để mô hình hóa các kịch bản (scenario) cho một trường hợp sử dụng.
- Để người dùng cuối có thể hiểu được và có thể giao tiếp với hệ thống ở mức tổng thể. - Làm cơ sở cho việc phác thảo ra các đặc tả kiểm tra.
Ví dụ về use-case: Trong một hệ thống quản lý công văn của một cơ quan có thể có biểu đồ use- case như sau:
Nếu các use-case là các thành phần của một hệ thống hoặc hệ thống con thì chúng được nhóm lại trong một hình chữ nhật được đặt tên (chính là tên hệ thống).
Ví dụ: Hệ thống bán hàng
Hình 7.1. Các use-case trong một hệ thống (con)
Tìm Actor bằng cách trả lời câu hỏi:Actor nào thao tác với hệ thống và vai trò của actor đó là gì?
Xác định Use-case bằng cách trả lời câu hỏi: Một Actor sẽ làm gì để thao tác với hệ thống?
Bán h ngà Bán h ngà Xem bảng giá Khách h ngà Nhân viên bán h ngà Xem công văn Văn thư
Chương 7. Tổng quan về UML v phà ương pháp hướng đối tượng
Các kiểu kết hợp (association) và quan hệ (relationship) giữa các use-case:
Kết hợp generalization (tổng quát hóa):
+ Kết hợp generalization giữa các use-case. Kết hợp này được biểu diễn bằng một đoạn thẳng có mũi tên hình tam giác đi từ một use-case đến use-case tổng quát hơn.
Hình 7.2. Kết hợp generalization giữa các use-case
Hình 7.2. chỉ sự kết hợp tổng quát hoá giữa các use-case nhập số liệu với nhập từ bàn phím và
nhập từ tệp. Ở đây nhập số liệu là use-case tổng quát, còn các use-case còn lại là các trường hợp riêng. Đôi khi một use-case tổng quát có thể không bao giờ tồn tại trong hệ thống thực. Nó chỉ đóng vai trò chung cho các use-case cụ thể (như trường hợp trên đây). Trong trường hợp này chúng ta gọi là abstract use-case. Tên của loại use-case này được in nghiêng. Các use-case không phải là abstract thì được gọi là concret use-case hoặc real use-case.
+ Kết hợp generalization giữa các Actor. Kết hợp này được biểu diễn bằng một đoạn thẳng có
mũi tên hình tam giác đi từ một Actor đến Actor tổng quát hơn, ví dụ: (adsbygoogle = window.adsbygoogle || []).push({});
Hình 7.3. Kết hợp generalization giữa các Actor
Hình 7.3. có nghĩa là tác nhân văn thư là trường hợp riêng của tác nhân nhân viên. Điều này phù hợp với thực tế: văn thư cũng là nhân viên cơ quan, nhưng nhân viên cơ quan có thể không phải là văn thư. Vậy văn thư là trường hợp riêng của nhân viên.
Trong các ngôn ngữ lập trình hỗ trợ HĐT, generalization thường được cài đặt bằng kỹ thuật kế thừa (inheritance).
Có 2 loại quan hệ giữa các use-case:
+ Quan hệ include (bao hàm) giữa các use-case. Quan hệ này được biểu diễn bằng mũi tên đứt
nét từ use-case bao hàm đến use-case con. Từ <<include>> được đặt cạnh đoạn thẳng này như hình 7.4.
Ví dụ:
Hình 7.4. Quan hệ include giữa các use-case
Hình 7.4. có nghĩa là: thao tác Bán hàng bao gồm một số thao tác, trong đó có thao tác In hóa đơn. Điều này có nghĩa là nếu Bán hàng thì phải In hóa đơn nhưng ngược lại thì chưa chắc.
+ Quan hệ extend (mở rộng) giữa các use-case. Quan hệ này cũng được biểu diễn bằng mũi tên
đứt nét từ use-case cần mở rộng đến use-case được mở rộng. Từ <<extend>> được đặt cạnh đoạn
51 Văn thư
h ngà Nhân viên cơ quan
Bán h ngà In hóa đơn <<include>> Ngưới sử dụng Nhập số liệu Nhập từ b n phímà Nhập từ tệp
thẳng này như hình 7.5. Ví dụ:
Hình 7.5. Quan hệ extend giữa các use-case
Hình 7.5. có nghĩa là use-case bán hàng được mở rộng sang use-case ký hợp đồng bảo hành. Điều này có nghĩa là: trong điều kiện bình thường thì thao tác bán hàng không dẫn tới việc ký hợp đồng bảo hành. Chỉ trong một số điều kiện nào đó thì mới có sự mở rộng, ví dụ như khi bán các thiết bị tin học chẳng hạn. Vậy use-case mở rộng (ở hình 7.5 là "ký hợp đồng bảo hành") có thể coi là một tình huống phát sinh từ use-case được mở rộng (ở trên là "bán hàng"). Tuy nhiên trong cách biểu diễn thì có phần ngược với cách suy nghĩ, cũng giống như generalization, mũi tên đi từ cái phát sinh đến cái gốc. Để chỉ rõ điều kiện phát sinh, người ta viết thêm điều kiện trong use- case gốc và gọi phần điều kiện này là các điểm mở rộng (extension points). Ví dụ với use-case
bán hàng có thể viết như sau:
Hình 7.5b. Quan hệ extend giữa các use-case
Có thể so sánh sự khác biệt giữa generalization, extend và include thông qua hình sau đây:
Hình 7.6. So sánh giữa generalization, extend và include.
Ta có thể đọc như sau: Thao tác giao hàng được thực hiện bằng một trong hai cách: giao ở cửa hànghoặcmang đến tận nhà. Hai cách giao hàng này có thể có một thao tác chung là "đóng gói hàng" nằm ở nút giao hàng. Như vậy trong kết hợp generalization thì các thao tác chung nằm ở nút gốc (nếu có), còn các trường hợp riêng nằm ở các nút con. Thao tác bán hàng được thực hiện bằng hai thao tác: In hóa đơn và xuất hàng. Thao tác bán hàng trong điều kiện bình thường thì được thực hiện suôn sẻ. Tuy nhiên có một tình huống phát sinh làm cho thao tác bán hàng không thực hiện được đó là tình hưống hết hàng. Tình huống hết hàng có thể phát sinh tình huống nhập hàng từ nhà cung cấp. Vậy thao tác nhập hàng từ nhà cung cấp cũng có thể coi là được phát sinh
Bán h ngà Ký hợp đồng bảo h nh à <<extend>> Bán h ngà Các điểm mở rộng: Bán các thiết bị tin học Ký hợp đồng bảo h nh à <<extend>> Giao h ngà Giao ở cửa h ngà Mang đến tận nhà Bán h ngà
In hóa đơn Xuất h ngà
<<include>> <<include>> Bán h ngà <<extend>> <<extend>> <<extend>> Nhập h ng tà ừ nh cung cà ấp Hết h ngà
Chương 7. Tổng quan về UML v phà ương pháp hướng đối tượng
từ thao tác bán hàng.
Chú ý. Trong UML phiên bản 1.1, include và extend được gọi là uses và extends. Ngoài ra các use-case liên quan đến nhau có thể được nhóm lại thành gói, ví dụ:
Hình 7.7. Các gói chứa use-case
7.3.2. Mô hình use-case (adsbygoogle = window.adsbygoogle || []).push({});
Mô hình use-case là tập hợp các biểu đồ use-case. Biểu đồ use-case lại là tập hợp của một số use-case cùng các kết hợp và các tác nhân sử dụng chúng. Trong UML, use-case được sử dụng để
nắm bắt các yêu cầu ở mức ngoài về chức năng sử dụng của hệ thống (to capture high level user-functional requirements of the system). Nên lưu ý là use-case không nên sử dụng để mô tả các yêu cầu phi chức năng hay "bên trong" các chức năng (tức là cách thực thi các chức năng), vì use-case trước hết là kỹ thuật phi hình thức và không hoàn toàn chính xác. Tuy nhiên use-case giúp chúng ta xác định cấu trúc và các yêu cầu chính của sản phẩm phần mềm.
Mô hình use-case đưa ra câu trả lời cho câu hỏi: hệ thống làm gì khi quan sát từ bên ngoài? Use-case là một thành phần của dự toán và là thành phần nhỏ bé nhất của sản phẩm chuyển giao. Nếu sản phẩm được tinh chỉnh theo nhiều bước và chuyển giao nhiều lần thì mỗi lần chuyển giao
lại có một mô hình use-case kèm theo. Các use-case không phải là mô hình phân rã chức năng,
cũng không phải nhằm nắm bắt tất cả các yêu cầu của hệ thống. Mô hình use-case chỉ là bước ban đầu. Để diễn tả sâu hơn cấu trúc và cách hoạt động của hệ thống, ta cần đến các kỹ thuật mô hình hóa khác. Mô hình đối tượng (Object model) mô tả cấu trúc tĩnh của hệ thống và quan hệ giữa các lớp. Mô hình động gồm các biểu đồ như biểu đồ tuần tự, biểu đồ trạng thái, sẽ mô tả chi tiết cách ứng xử của hệ thống, nhằm trả lời cho câu hỏi: hệ thống thực hiện các chức năng như thế nào. Mô hình quy trình công việc (business process model) sẽ cho biết trình tự các công việc được thực hiện như thế nào, cả phần tin học hóa và phần thủ công.
Use-case không phải là kỹ thuật bắt buộc trong mô hình hóa hướng đối tượng. Và cũng
không có lý do cơ bản nào để ngăn cản việc ứng dụng nó như một công cụ ban đầu của phương
pháp phát triển có cấu trúc. Tuy nhiên chúng không được dùng trong phân tích có cấu trúc vì
những người sáng tạo ra chúng đang tập trung sự chú ý vào việc phát triển các phương pháp hướng đối tượng.
7.3.3. Xây dựng mô hình use-case như thế nào?
Như đã nói đến trong phần trước, theo thuật ngữ của UML thì người hoặc hệ thống sử dụng phần
mềm mà ta đang xem xét được gọi là tác nhân của phần mềm đó, còn use-case như tên gọi của
nó, là một trường hợp sử dụng của phần mềm liên quan đến tác nhân nào đó. Để xây dựng mô hình này, ta cần trả lời hai câu hỏi:
1) Ai (hoặc hệ thống nào) trực tiếp sử dụng phần mềm? Câu trả lời sẽ đưa ra danh sách các tác nhân.
Từ danh sách các tác nhân đầu tiên ta chọn ra tác nhân quan trọng nhất, sau đó là tác nhân quan trọng thứ nhì,... Với mỗi tác nhân ta nêu câu hỏi:
2) Tác nhân muốn làm gì với hệ thống (tức là phần mềm)? Câu trả lời sẽ là các use-case.
Ban đầu mỗi tác nhân cùng các use-case liên quan sẽ là một biểu đồ. Tuy nhiên sau đó ta cần xem xét các use-case của các tác nhân khác nhau. Nếu ta thấy có nhiều điểm chung thì nên dùng một
use-case cho các tác nhân. Ví dụ use-case mượn sách của tác nhân bạn đọc cũng tương tự như
use-case cho mượn sách của thủ thư nên ta gộp hai use-case này thành một và gọi là use-case
53 Quản lý kho
mượn sách.
Nếu trình bày một cách có hệ thống thì để xác định một use-case đơn giản (a simple use-case
recipe) ta cần thực hiện 8 bước như sau:
Bước 1. Nhận diện xem ai sẽ là người trực tiếp sử dụng hệ thống, ví dụ người sẽ ngồi vào bàn phím và gõ vào bàn phím để sử dụng chương trình. Họ là các tác nhân. Tác nhân có thể là một hệ thống khác, để tìm tác nhân loại này ta nêu câu hỏi: hệ thống nào tương tác với hệ thống này?
Bước 2. Hãy chọn một phần tử trong các tác nhân. Ví dụ đó là thư ký nhận đơn đặt hàng (sales order clerk), mà ta sẽ gọi đơn giản là người bán hàng.
Bước 3. Hãy xác định xem tác nhân này muốn làm gì với hệ thống. Những việc tác nhân này muốn thực hiện trên hệ thống sẽ trở thành các use-case.
Bước 4. Với mỗi use-case hãy xác định dòng công việc (course) thường xuyên nhất khi actor sử dụng hệ thống (the most usual course when the actor is using the system).
Bước 5. Mô tả dòng công việc cơ sở này trong phần diễn tả use-case (the description for the use- case).
Hãy mô tả theo cách "tác nhân làm cái gì đó, hệ thống sẽ làm cái gì đó...", tuy nhiên chỉ giữ ở mức bên ngoài. Bạn hãy chỉ mô tả những điều hệ thống làm mà tác nhân nhận biết được và ngược lại, những điều tác nhân làm mà hệ thống nhận biết được. Trước mắt chưa cần quan tâm đến các quan hệ đặc biệt như <<extend>> hay <<include>>.
Hình 7.17. Diễn tả dòng công việc cho mỗi use-case (adsbygoogle = window.adsbygoogle || []).push({});
Người bán h ngà Nhập đơn đặt h ngà Diễn tả (description) Người bán h ng nhà ập họ của khách h ng. Hà ệ thống hiện trên m n hình tà ất cả các khách h ng có cùng hà ọ. Người bán h ng à chọn một người trong số n y. Các thông tin chi tià ết về khách h ng n y à à được hiện ra trên m n hình.à
Với mỗi mặt h ng khách muà ốn đặt mua, người bán h ng nhà ập các thông tin chi tiết về mặt h ng trong mà ột dòng. Khi tất cả các mặt h ng à đã được nhập thì hệ thống xác nhận đơn đạt h ng à (confirm). Kiểm tra tiền nợ của khách h ngà Diễn tả Người bán h ng nhà ập họ của khách h ng. Hà ệ thống hiện trên m n hình tà ất cả các khách h ng à có cùng họ. Người bán h ng chà ọn một người trong số n y. Các thông tin chi tià ết về khách h ng à n y à được hiện ra trên m n hình.à
Đồng thời, hệ thống hiện trên m n hình là ịch trình trả nợ của khách trong sáu tháng gần đây
Chương 7. Tổng quan về UML v phà ương pháp hướng đối tượng
Bước 6. Nếu bạn cảm thấy vừa lòng với các dòng công việc cơ bản thì hãy xem xét đến các khả năng khác và bổ sung các khả năng này.
Hình 7.18. Bổ sung thêm use-case ứng với khả năng khác
Bước 7. Đọc lại các diễn tả và đối chiếu so sánh. Nếu phát hiện thấy có phần chung thì nên tách ra thành các use-case cho các dòng công việc chung.
Hình 7.19. Tách dòng công việc chung thành use-case dùng chung
55
Diễn tả (description)
Người bán h ng nhà ập họ của khách h ng. Hà ệ thống hiện trên m n hình tà ất cả các khách h ng có cùng hà ọ. Người bán h ng à chọn một người trong số n y. Các thông tin chi tià ết về khách h ng n y à à được hiện ra trên m n hình.à
Với mỗi mặt h ng khách muà ốn đặt mua, người bán h ng nhà ập các thông tin chi tiết về mặt h ng trong mà ột dòng. Khi tất cả các mặt h ng à đã được nhập thì hệ thống xác nhận đơn đạt h ng à (confirm). Người bán h ngà Nhập đơn đặt h ngà Kiểm tra tiền nợ của khách h ngà Diễn tả Người bán h ng nhà ập họ của khách h ng. Hà ệ thống hiện trên m n hình tà ất cả các khách h ng à có cùng họ. Người bán h ng chà ọn một người