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

Chia sẻ: Luongnguyenviet Cuong | Ngày: | Loại File: PDF | Số trang:4

Thêm vào BST

Báo xấu

857
lượt xem 102
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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 case Trong 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...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: BÀI 6: GIỚI THIỆU VỀ USE CASE

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 case Trong 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 trong một hệ thống. Chúng ta sẽ chuyển sang các diagram cung cấp một cá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ủa nó 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ởi ngườ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 Soda Giả 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ỏng vấ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ãy cù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 6
Hình 6.1 Mộ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à “buy soda”. 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 động kị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át nướ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 soda khá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 soda thế 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 soda nà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ại soda 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áy cũ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ều kiện (precondition) là một khách hàng khát nước. Hậu điều kiện (postcondition) là hoặc một lon 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 cho khá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 đưa và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ổ sung Chú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ẫn cò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ạo thêm ít nhất 2 use case nữa là “Nạp soda” (Restock) và “Thu tiền“ (Collect money). Trang 2 – Bài 6
Hã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 lon soda 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ời gian đã đến. Họ theo các trình tự như trong “Restock”, mở khóa, rồi mở bên trong máy soda. 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ều kiệ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 thu ngâ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. Trong ví 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ỉ quan tâ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àm gì? 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 soda và 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ạn như 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 case khô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 use case phụ. Ta hãy gom các bước mở khóa và mở máy vào một use case tên “Mở máy”. Gom các bước đóng khóa và khóa máy vào một use case tên “Đóng máy”. Với các use case mới trên, 2 use case “Restock” và “Collect” sẽ cùng bắt đầu bằng use case “Mở máy” và cùng kết thúc với use case “Đóng máy”. Ta gọi trường hợp này là “Restock” và “Collect” bao gồm các use case mới. Mở rộng một use case (extending a use case) Có thể dùng lại một use case theo cách khác ngoài cách bao gồm (inclusion). Đôi khi, ta tạo một use case mới bằng cách thêm một vài bước vào một use case sẵn có. Trở lại với use case “Restock”. Trước khi đặt một lon soda vào máy, đại diện nhà cung cấp có thể chú ý đến những nhãn hiệu nào bán chạy và ngược lại. Thay vì đơn giản là nạp đầy đủ tất cả các nhãn hiệu, nhà cung cấp có thể thay thế các nhãn hiệu ít người mua bằng nhãn hiệu bán chạy hơn. Các bước sau đó vẫn như cũ. Nếu ta thêm các bước như trên vào use case “Restock”, ta sẽ có một use case mới mà ta gọi là “Restok according to sales”. Use case mới này là một sự mở rộng của use case ban đầu và kỹ thuật này gọi là mở rộng một use case (extending a use case). Trang 3 – Bài 6
Tóm lược Một use case là một cấu trúc nhằm mô tả cách mà những người dùng tương lai nhìn nhận một hệ thống. Mỗi use case là một tập kịch bản (scenario) được kích hoạt bởi một thực thể gọi là actor. Một use case cần đem lại một kết quả nào đó cho chính actor kích hoạt nó hoặc cho một actor khác. Có thể tái sử dụng các use case. Cách thứ nhất (inclusion) là dùng các bước từ một use case này như là một phần trong chuỗi các bước trong một use case khác. Cách thứ hai (extension) là tạo một use case mới bằng cách thêm các bước vào một use case có sẵn. Phỏng vấn người dùng là kỹ thuật tốt nhất để dẫn ra các use case. Khi dẫn ra một use case cần chú ý các tiền điều kiện (precondition) để kích hoạt use case và các hậu điều kiện (postcondition) được xem như hậu quả của use case. Thực hiện phỏng vấn người dùng sau khi phỏng vấn khách hàng và tạo một danh sách các lớp dự tuyển (candidate class). Điều này giúp ta có một nền tảng về thuật ngữ dùng để nói chuyện với người dùng. Nên phỏng vấn một nhóm người dùng. Mục tiêu là dẫn ra các use case dự tuyển và tất cả các actor có thể. Câu hỏi 1. Thực thể kích hoạt một use case được gọi là gì? 2. Việc bao gồm một use case nghĩa là gì? 3. Việc mở rộng một use case nghĩa là gì? 4. Một use case có giống một kịch bản (scenario) không? Bài tập 1. Đối với ví dụ về máy bán Soda, hãy tạo một use case khác bao gồm các use case “expose the inside” và “unexpose the inside”. 2. Các use case giúp bạn phân tích một công việc kinh doanh cũng như một hệ thống. Hãy quan tâm đến 1 cửa hàng máy tính có bán phần cứng, thiết bị ngoại vi và phần mềm. Các actor là ai? Các use case chính là gì? Nêu vài kịch bản cho mỗi use case? Trang 4 – Bài 6