BÀI 6: GIỚI THIỆU VỀ USE CASE

Trong các bài trước, chúng ta đã học về các class và các mối quan hệ giữa chúng. Trong bài này, chúng ta tìm hiểu một mặt khác của UML – đó là use case. nội dung chính của bài: + Use case là gì? + Cách thức tạo use case + Các use case bao gồm (including use case) + Các use case mở rộng (extending use case) + Khởi động việc phân tích một use caseTrong ba bài trước, chúng ta đã làm việc với các diagram cung cấp một cái nhìn tĩnh (static view) về các class...
Nội dung trích xuất từ tài liệu:
BÀI 6: GIỚI THIỆU VỀ USE CASEBÀI 6:GIỚI THIỆU VỀ USE CASETrong các bài trước, chúng ta đã học về các class và các mối quan hệ giữa chúng. Trong bàinày, chúng ta tìm hiểu một mặt khác của UML – đó là use case. nội dung chính của bài: + Use case là gì? + Cách thức tạo use case + Các use case bao gồm (including use case) + Các use case mở rộng (extending use case) + Khởi động việc phân tích một use caseTrong ba bài trước, chúng ta đã làm việc với các diagram cung cấp một cái nhìn tĩnh (staticview) về các class trong một hệ thống. Chúng ta sẽ chuyển sang các diagram cung cấp mộtcái nhìn động (dynamic view) và biểu diễn sự thay đổi của hệ thống cũng như các lớp củanó theo thời gian. Static view giúp một phân tích viên liên lạc với các khách hàng (client),trong khi dynamic view giúp một phân tích viên liên lạc với một nhóm các lập trình viên(developer), giúp các lập trình viên tạo chương trình.Use case là gì?Thuật ngữ: Hãy xem use case như một tập hợp các kịch bản (scenario) về việc sử dụng hệthống. Mỗi kịch bản mô tả một chuỗi các sự kiện (event). Mỗi chuỗi được kích hoạt bởingười, một hệ thống khác, một thiết bị phần cứng hoặc bởi một thời điểm. Các thực thể(entity) kích hoạt chuỗi được gọi là tác nhân (actor). Kết quả của chuỗi phải là cái gì đó sửdụng được cho actor kích hoạt chuỗi hoặc cho actor khác.Ví dụ: máy bán SodaGiả sử chúng ta bắt đầu thiết kế một máy bán soda. Để biết quan điểm người dùng, ta phỏngvấn một số khách hàng tiềm năng về cách thức mà họ sẽ dùng máy.Do chức năng chính của máy bán soda là cho phép một khách hàng mua một lon soda,người dùng dễ dàng cho bạn biết một loạt các kịch bản-gọi là use case “buy soda”. Hãycùng xem xét mỗi kịch bản trong use case này. Các kịch bản này, chú ý rằng, có liên quanđến những cuộc đối thoại với người dùng. Trang 1 – Bài 6Hình 6.1Một use case đặc tảmột tập các kịch bản đểhoàn thành cái gì đócho actor. Trong ví dụnày, use case là “buysoda”.Use case “Mua soda”Actor trong use case này là một khách hàng muốn mua một lon soda. Khách hàng khởi độngkịch bản bằng cách nhét tiền vào máy. Sau đó anh ta lựa chọn. Nếu mọi việc đều thuận lợi,máy có ít nhất 1 lon soda bên trong, thì một lon soda lạnh sẽ được đưa cho khách.Ngoài chuỗi các bước trên, còn một số khía cạnh khác của kịch bản cũng đáng quan tâm.Tiền điều kiện nào khiến khách hàng khởi động kịch bản trong use case “buy soda”. Khátnước là lý do rõ ràng nhất. Sau một chuỗi các bước của kịch bản, kết quả là gì? Một lần nữa,kết quả rõ ràng nhất là khách hàng có lon soda.Kịch bản vừa rồi là duy nhất cho use case “buy soda” hay sao? Rất có thể máy hết loại sodakhách muốn. Cũng có thể khách hàng không trả đủ tiền mua soda. Ta nên thiết kế máy sodathế nào để xử lý các kịch bản này?Hãy cùng xét kịch bản hết soda (out-of-soda), chuỗi các bước trong “buy soda” sẽ khác.Khách hàng khởi động use case bằng cách nhét tiền vào máy. Người khách chọn loại sodanào đó. Máy không còn loại soda mà người khách đã chọn. Máy hiển thị thông báo hết loạisoda mà khách yêu cầu. Nếu tốt hơn, máy sẽ nhắc khách hàng chọn loại soda khác. Máycũng nên cho khách hàng lựa chọn hoặc chọn loại soda khác, hoặc rút lại tiền. Tiền điềukiện (precondition) là một khách hàng khát nước. Hậu điều kiện (postcondition) là hoặc mộtlon soda hoặc tiền được hoàn trả lại.Bây giờ xét đến kịch bản số tiền không đủ (incorrect-amount-of-money). Một lần nữa,khách hàng khởi động use case theo cách thông thường, rồi chọn loại soda. Giả sử máy cònđủ loại soda mà khách đã chọn. Nếu máy còn tiền lẻ phù hợp, nó sẽ trả lại tiền thừa chokhách kèm theo là soda. Ngược lại, máy trả lại tiền và hiện thông báo yêu cầu khách đưavào đúng số tiền. Tiền điều kiện vẫn như cũ. Hậu điều kiện là hoặc lon soda cùng tiền thừađược đưa cho khách hoặc tiền khách đưa được hoàn trả.Các use case bổ sungChúng ta vừa xem xét máy bán soda trên quan điểm một người dùng: đó là khách hàng. Vẫncòn một số user khác trong hệ thống. Một nhà cung cấp (supplier) phải nạp soda vào máy vàngười thu tiền (collector) phải thu lấy tiền tích lũy trong máy. Điều này có nghĩa cần tạothêm ít nhất 2 use case nữa là “Nạp soda” (Restock) và “Thu tiền“ (Collect money). Trang 2 – Bài 6Hãy xét use case “Restock”. Supplier kích hoạt use case này bởi định kỳ thời gian (có thể làmỗi 2 tuần). Nhà cung cấp mở khóa máy soda, kéo mặt trước của máy mở ra và nạp các lonsoda vào đầy các khoang chứa. Ngoài ta, người đại diện cũng nạp đầy đủ kho tiền lẻ để trảlại cho khách. Tiền điều kiện là sự đạt đến một định kỳ thời gian và hậu điều kiện là nhàcung cấp sắp có các lượt bán hàng tiếp theo.Đối với use case “Collect Money”, người thu ngân cũng kích hoạt use case bởi định kỳ thờigian đã đến. Họ theo các trình tự như trong “Restock”, mở khóa, rồi mở bên trong máysoda. Sau đó, người thu ngân sẽ lấy tiền khỏi máy, rồi cũng đóng và khóa máy lại. Tiền điềukiện là sự đạt đến một định kỳ thời gian và hậu điều kiện là tiền trong túi của người thungân.Chú ý rằng khi ta mô tả một use case, ta không bận tâm đến cách nó được thực hiện. Trongví dụ này, ta không quan tâm nhiều đến cấu tạo bên trong của máy soda, không quan tâmđến việc máy làm lạnh như thế nào và làm sao máy có thể lưu giữ tiền. Chúng ta chỉ quantâm đến việc những người sử dụng máy soda (gồm nhiều vai trò khác nhau) sẽ dùng nó làmgì?Mục tiêu là thu thập một tập các use case để trình bày cho những người sẽ thiết kế máy sodavà những người sẽ thực hiện nó.Bao gồm một use case (including a use case)Trong các use case “Restock” và “Collect”, ta thấy có một số bước (step) chung. Chẳng hạnnhư những bước đầu gồm mở khóa, mở máy soda và những bước cuối gồm đóng máy vàkhóa máy soda lại là giống nhau. Chúng ta có thể giảm các bước trùng lặp giữa các use casekhông?Câu trả lời là có thể. Cách làm là lấy những bước chung đó để tạo nên us ...