›
›

Bài giảng Phân tích và thiết kế hướng đối tượng - Bài 3: Biểu đồ Use Case phân tích yêu cầu hệ thống

pdf 54 trang phuongnguyen 4201
Download
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Phân tích và thiết kế hướng đối tượng - Bài 3: Biểu đồ Use Case phân tích yêu cầu hệ thống", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

  • pdfbai_giang_phan_tich_va_thiet_ke_huong_doi_tuong_bai_3_bieu_d.pdf

Nội dung text: Bài giảng Phân tích và thiết kế hướng đối tượng - Bài 3: Biểu đồ Use Case phân tích yêu cầu hệ thống

  1. PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG OBJECT ORIENTED ANALYSIS AND DESIGN DR. DAO NAM ANH Bài giảng 3: BIỂU ĐỒ USE CASE PHÂN TÍCH YÊU CẦU HỆ THỐNG 1
  2. RESOURCE - REFERENCE 1. Ian Sommerville, Software Engineering, Ninth Edition, 2011 2. Bernd Bruegge & Allen H. Dutoit. Object-Oriented Software Engineering: Using UML, Patterns, and Java, Third Edition, Prentice Hall, 2010 3. Russell C. Bjork, ATM Simulation Links, Gordon College 4. Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David Fado, UML 2 Toolkit, John Wiley & Sons Inc, 2003 5. Dương Kiều Hoa – Tôn Thất Hoà An, Phân tích và thiết kế Hệ thống thông tin với UML, 2006 6. Đào Nam Anh, Giáo Trình Phân Tích Và Thiết Kế Hướng Đối Tượng, Đại học Điện lực, 2013 2
  3. CONTENT – NỘI DUNG Phương pháp hướng đối tượng và quá trình phát triển hệ thống phần mềm 1. Giới thiệu về hệ thống phần mềm 2. Sự phát triển hệ thống 3. Các cách tiếp cận trong phát triển phần mềm 4. Quá trình phát triển phần mềm hợp nhất 3
  4. Nội dung 1. Biểu đồ Use Case phân tích yêu cầu hệ thống 2. Tập hợp yêu cầu hệ thống 3. Biểu đồ Use Case 4. Mô hình hóa với Use Case 4
  5. Giới thiệu  Yêu cầu là chức năng mà hệ thống phải có hoặc là điều kiện mà hệ thống phải đáp ứng theo đề nghị của khách hàng.  Để xác định các yêu cầu của hệ thống cần làm hai việc: tập hợp yêu cầu, mà kết quả là tài liệu đặc tả hệ thống viết cho khách hàng hiểu được; và việc phân tích, mà kết quả là một mô hình phân tích với các Use Case giải thích rõ ràng cho các lập trình viên 5
  6. 1. Tập hợp yêu cầu hệ thống  Tập hợp yêu cầu có nhiều thách thức vì nó cần có sự cộng tác của nhiều người tham gia với các nền tảng nghiệp vụ khác nhau.  Một mặt, khách hàng và người sử dụng là các chuyên gia trong phạm vi của họ và họ có ý tưởng chung về hệ thống cần làm những gì, nhưng họ thường có ít kinh nghiệm trong phát triển phần mềm.  Mặt khác, các nhà phát triển có kinh nghiệm trong việc xây dựng hệ thống, nhưng thường có ít kiến thức về môi trường nghiệp vụ của người sử dụng. 6
  7. 1. Tập hợp yêu cầu hệ thống  Cảnh kịch (scenario) và các Use Case là để lấp khoảng trống này. Cảnh kịch mô tả ví dụ sử dụng hệ thống là một loạt các tương tác giữa người dùng và hệ thống.  Use Case là mô hình trìu tượng của cảnh kịch. Cảnh kịch được viết bằng ngôn ngữ tự nhiên, dễ hiểu cho người dùng. Nhà phát triển tìm ra những yêu cầu bằng cách quan sát và phỏng vấn người sử dụng. Nhà phát triển đầu tiên trình bày các quy trình công việc hiện tại của người sử dụng trong dạng cảnh kịch, sau đó phát triển cảnh kịch thể hiện chức năng của hệ thống tương lai trong ngôn ngữ của khách hàng. 7
  8. 1. Tập hợp yêu cầu hệ thống  Use Case là một công cụ xuất sắc để khuyến khích những người sử dụng tiềm năng nói về hệ thống từ hướng nhìn của họ. Đối với người dùng, mô tả những ý định trong việc sử dụng hệ thống cũng việc không dễ dàng.  Người sử dụng thường biết nhiều hơn những gì mà họ có thể diễn tả ra: Công cụ Use Case sẽ giúp cho nhóm phát triển phá "lớp băng" đó. 8
  9. 1. Tập hợp yêu cầu hệ thống  Ý tưởng chủ đạo là lôi cuốn được người dùng tham gia vào những giai đoạn đầu tiên của quá trình phân tích và thiết kế hệ thống.  Việc này sẽ nâng cao xác suất cho việc hệ thống được xây dựng sẽ trở thành một công cụ quen thuộc đối với các người dùng – thay vì một tập hợp khó hiểu và rối rắm của các khái niệm máy tính mà người dùng trong nghiệp vụ của mình có cảm giác không bao giờ hiểu được và không thể làm việc cùng. 9
  10. 1. Tập hợp yêu cầu hệ thống Ví dụ ATM: scenarios Hệ thống ngân hàng tự động ATM  Phần mềm được thiết kế sẽ kiểm soát máy rút tiền tự động (ATM) có một đầu đọc thẻ ATM, một giao diện với khách hàng gồm có bàn phím và màn hình, một khe trả phong bì, một khay tiền tiền mặt (bội số của 20$), một máy in biên lai, và một phím để khởi động hoặc dừng máy. ATM sẽ giao tiếp với máy tính của ngân hàng thông qua một đường truyền thông.  ATM sẽ phục vụ một khách hàng tại một thời điểm. Một khách hàng sẽ được yêu cầu nạp một thẻ ATM và nhập mã số cá nhân (PIN) - cả hai sẽ được gửi đến ngân hàng để xác nhận. Các khách hàng sau đó sẽ có thể thực hiện một hoặc nhiều giao dịch. 10
  11. 2. Biểu đồ Use Case  Nếu một hệ thống được xem là có chất lượng cao, nó phải đáp ứng các yêu cầu của người sử dụng. Vì vậy khi phân tích hệ thống phân tích cách tiếp cận theo định hướng người sử dụng là thích hợp.  Cần xác định người sử dụng của hệ thống và các nhiệm vụ mà họ phải thực hiện với hệ thống. Đồng thời tìm thông tin về những nhiệm vụ quan trọng nhất của họ, để có thể lập nên cảnh kịch sử dụng phù hợp. 11
  12. 2. Biểu đồ Use Case  Có thể coi một biểu đồ Use Case như là tập hợp của một loạt các Use Case, mô hình hóa cảnh kịch về việc sử dụng hệ thống.  Mỗi cảnh kịch mô tả một chuỗi các sự kiện.  Mỗi một chuỗi này sẽ được kích hoạt bởi một người nào đó, một hệ thống khác hay là một phần trang thiết bị nào đó, hoặc là một chuỗi thời gian.  Những thực thể kích hoạt nên các chuỗi sự kiện như thế được gọi là các Tác Nhân (Actor). 12
  13. 2. Biểu đồ Use Case  'Người sử dụng' và 'nhiệm vụ' trong UML thực tế chính là tác nhân (Actor) và Use Case.  Tác nhân là mô hình của người sử dụng của hệ thống trong một vai trò xác định. Tác nhân cũng có thể là một hệ thống bên ngoài có tương tác với hệ thống đang phân tích. 13
  14. 2. Biểu đồ Use Case 2.1 Thành phần Use Case  Những thành phần quan trọng nhất của một mô hình Use Case là Use Case, tác nhân và hệ thống. Ranh giới của hệ thống được định nghĩa qua chức năng tổng thể mà hệ thống sẽ thực thi.  Chức năng tổng thể được thể hiện qua một loạt các Use Case và mỗi một Use Case đặc tả một chức năng trọn vẹn, có nghĩa là Use Case phải thực thi toàn bộ chức năng đó, từ sự kiện được kích hoạt đầu tiên bởi một tác nhân ngoại cảnh cho tới khi chức năng đòi hỏi được thực hiện hoàn tất.  Một Use Case luôn phải cung cấp một giá trị nào đó cho một tác nhân, giá trị này là những gì mà tác nhân mong muốn từ phía hệ thống. Tác nhân là bất kỳ một thực thể ngoại cảnh nào mong muốn tương tác với hệ thống. 14
  15. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Một biểu đồ Use Case thể hiện [32]:  Hệ thống  Tác nhân  Use Case. Ví dụ biểu đồ Use Case trong UML, trong đó hình chữ nhật thể hiện hệ thống, tác nhân được thể hiện qua ký hiệu hình người, Use Case được thể hiện qua hình ellipse. Check Balance Card Holder Withdraw Cash 15
  16. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Hệ thống Vì hệ thống là một thành phần của mô hình Use Case nên ranh giới của hệ thống mà ta muốn phát triển cần phải được định nghĩa rõ ràng.  Lưu ý một hệ thống không phải bao giờ cũng nhất thiết là một hệ thống phần mềm; nó có thể là một chiếc máy, hoặc là một nghiệp vụ.  Định nghĩa các ranh giới và trách nhiệm của hệ thống không phải dễ dàng, bởi không phải bao giờ người ta cũng rõ ràng nhìn ra nghiệp vụ nào có khả năng được tự động hóa tốt nhất ở hệ thống này và nghiệp vụ nào thì tốt nhất nên thực hiện thủ công hoặc dành cho các hệ thống khác. 16
  17. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Tác nhân  Một tác nhân là một người hoặc một vật nào đó tương tác với hệ thống, sử dụng hệ thống.  Trong khái niệm "tương tác với hệ thống", ý muốn nói rằng tác nhân sẽ gửi thông điệp đến hệ thống hoặc là nhận thông điệp xuất phát từ hệ thống, hoặc là thay đổi các thông tin của với hệ thống. Nói một cách ngắn gọn, tác nhân thực hiện các Use Case.  Một tác nhân có thể là người mà cũng có thể là một hệ thống khác (ví dụ đó là một chiếc máy tính khác được kết nối với hệ thống của chúng ta hoặc một loại trang thiết bị phần cứng nào đó tương tác với hệ thống). 17
  18. 2. Biểu đồ Use Case 2.1 Thành phần Use Case  Một tác nhân giao tiếp với hệ thống bằng cách gửi hoặc là nhận thông điệp, giống như khái niệm chúng ta đã quen biết trong lập trình hướng đối tượng.  Một Use Case bao giờ cũng được kích hoạt bởi một tác nhân gửi thông điệp đến cho nó.  Khi một Use Case được thực hiện, Use Case có thể gửi thông điệp đến một hay nhiều tác nhân. Những thông điệp này cũng có thể đến với các tác nhân khác, hay chính tác nhân đã kích hoạt Use Case. 18
  19. 2. Biểu đồ Use Case 2.1 Thành phần Use Case  Tác nhân cũng có thể được xếp loại. Tác nhân còn có thể được định nghĩa theo dạng tác nhân chủ động (active actor) hay tác nhân thụ động (passive actor).  Một tác nhân chủ động là tác nhân gây ra Use Case, trong khi tác nhân thụ động không bao giờ gây ra Use Case mà chỉ tham gia vào một hoặc nhiều Use Case. 19
  20. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Tìm tác nhân  Khi nhận diện tác nhân, có nghĩa là chúng ta lọc ra các thực thể đáng quan tâm theo khía cạnh sử dụng và tương tác với hệ thống.  Sau đó chúng ta có thể thử đặt mình vào vị trí của tác nhân để cố gắng nhận ra các yêu cầu và đòi hỏi của tác nhân đối với hệ thống và xác định tác nhân cần những Use Case nào. 20
  21. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Tìm tác nhân Có thể nhận diện ra các tác nhân qua các câu hỏi như sau:  Ai sẽ sử dụng những chức năng chính của hệ thống?  Ai sẽ cần sự hỗ trợ của hệ thống để thực hiện những tác vụ hàng ngày của họ?  Ai sẽ cần bảo trì, quản trị và đảm bảo cho hệ thống hoạt động?  Hệ thống sẽ phải xử lý và làm việc với những trang thiết bị phần cứng nào?  Hệ thống cần phải tương tác với các hệ thống khác nào?  Ai hay cái gì quan tâm đến đầu ra của hệ thống? 21
  22. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Tìm tác nhân  Khi đi tìm những người sử dụng hệ thống, đừng quan sát những người đang ngồi ở trước màn hình máy tính. Lưu ý người sử dụng có thể là bất kỳ người nào hay bất kỳ vật nào tương tác hoặc trực tiếp hoặc gián tiếp với hệ thống và sử dụng các dịch vụ của hệ thống này để đạt đến một kết quả nào đó 22
  23. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Tìm tác nhân  Để có thể nhận dạng được tốt nhiều tác nhân khác nhau, hãy tiến hành nghiên cứu những người sử dụng của hệ thống hiện thời (một hệ thống thủ công hoặc một hệ thống đang tồn tại), hỏi xem họ đóng những vai trò nào khi thực thi công việc hàng ngày với hệ thống.  Cũng người sử dụng đó có thể thực thi nhiều vai trò khác nhau tại nhiều thời điểm khác nhau, tùy thuộc vào việc chức năng nào trong hệ thống đang được sử dụng. 23
  24. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Biểu diễn tác nhân trong ngôn ngữ UML Tác nhân trong UML là một lớp với biệt ngữ "Actor" (Tác nhân) và tên của lớp này là tên của tác nhân, phản ánh vai trò của tác nhân. Một lớp tác nhân có thể vừa có thuộc tính (attribute) lẫn hành vi (method) cũng như một thuộc tính tài liệu (document) mô tả tác nhân đó. Một lớp tác nhân có một biểu tượng chuẩn hóa và biểu tượng "hình nhân": 24
  25. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Quan hệ giữa các tác nhân Một tác nhân thường có Liên hệ để sử dụng các trường hợp phải được nhị phân. Tác nhân cũng có thể có mối quan hệ tổng quát giữa họ, với g ngữ nghĩa điển hình là các con có thể làm những gì cha mẹ làm và sau đó làm thêm việc khác. Khi có nhiều tác nhân nhiều, một số tác nhân có thể là tổng quát của tác nhân khác. Khái quát giữa các đối tượng được hiển thị như đoạn thẳng với một hình tam giác rỗng đẩu chỉ vào tác nhân tổng quát hơn, như thể hiện trong hình dưới. 25
  26. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Quan hệ giữa các tác nhân Manager Registered User Administrator Staff 26
  27. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Use Case  Một Use Case là đại diện cho một chức năng nguyên vẹn mà một tác nhân nhận được.  Một Use Case trong ngôn ngữ UML được định nghĩa là một tập hợp của các chuỗi hành động mà một hệ thống thực hiện để tạo ra một kết quả có thể quan sát được, tức là một giá trị đến với một tác nhân cụ thể.  Những hành động này có thể bao gồm việc giao tiếp với nhiều tác nhân cũng như thực hiện tính toán và công việc nội bộ bên trong hệ thống. 27
  28. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Use Case Các tính chất tiêu biểu của một Use Case là:  Một Use Case bao giờ cũng được gây ra bởi một tác nhân, được thực hiện nhân danh một tác nhân nào đó. Tác nhân phải ra lệnh cho hệ thống để thực hiện Use Case đó, dù là trực tiếp hay gián tiếp.  Một Use Case phải cung cấp một giá trị cho một tác nhân. Giá trị đó không phải bao giờ cũng cần thiết phải thể hiện ra ngoài.  Một Use Case là phải hoàn tất. Một trong những lỗi thường gặp là phân rã một Use Case thành các Use Case nhỏ hơn, và các Use Case này thực thi lẫn nhau giống như việc gọi hàm cho một ngôn ngữ lập trình. 28
  29. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Use Case  Một Use Case là một lớp, chứ không phải một thực thể. Nó mô tả trọn vẹn một chức năng, kể cả các giải pháp bổ sung và thay thế có thể có, các lỗi có thể xảy ra cũng như những ngoại lệ có thể xảy ra trong quá trình thực thi.  Một kết quả của sự thực thể hóa một Use Case được gọi là một cảnh kịch (scenario) và nó đại diện cho một sự sử dụng cụ thể của hệ thống (một cách thực thi riêng biệt qua hệ thống).  Ví dụ một cảnh kịch của Use Case "Ký hợp đồng bảo hiểm" có thể là "John liên hệ với hệ thống qua điện thoại rồi sau đó ký hợp đồng bảo hiểm ô tô cho chiếc xe Toyota Carolla mà anh ta vừa mua." 29
  30. 2. Biểu đồ Use Case 2.1 Thành phần Use Case Tìm Use Case Quá trình tìm các Use Case bắt đầu với các tác nhân đã được xác định ở phần trước. Đối với mỗi tác nhân, hãy hỏi các câu hỏi sau:  Tác nhân này cần những chức năng nào từ hệ thống? Hành động chính của tác nhân là gì ?  Tác nhân có cần phải đọc, phải tạo, phải hủy bỏ, phải sửa chữa, hay là lưu trữ một loại thông tin nào đó trong hệ thống?  Tác nhân có cần phải báo cho hệ thống biết về những sự kiện nào đó? Những sự kiện như thế sẽ đại diện cho những chức năng nào? 30
  31. 2. Biểu đồ Use Case 2.2. Quan hệ giữa các Use Case Có ba loại quan hệ Use Case:  Quan hệ mở rộng,  Quan hệ sử dụng và  Quan hệ tạo nhóm. Quan hệ mở rộng và quan hệ sử dụng là hai dạng khác nhau của tính thừa kế. Quan hệ tạo nhóm là một phương cách để đặt nhiều Use Case chung với nhau vào trong một gói. 31
  32. 2. Biểu đồ Use Case 2.2. Quan hệ giữa các Use Case Quan hệ mở rộng Ta thấy một số Use Case đã tồn tại cung cấp một phần những chức năng cần thiết cho một Use Case mới. Trong một trường hợp như vậy, có thể định nghĩa một Use Case mới là Use Case cũ cộng thêm một phần mới. Một Use Case như vậy được gọi là một Use Case mở rộng (extended use case). Trong quan hệ mở rộng, Use Case gốc được dùng để mở rộng phải là một Use Case hoàn thiện. Use Case mở rộng không nhất thiết phải sử dụng toàn bộ hành vi của Use Case gốc. Quan hệ mở rộng giữa các Use Case được biểu thị bằng đoạn thẳng ngắt quãng, trỏ về phía Use Case được dùng để mở rộng, đi kèm với stereotype >. 32
  33. 2. Biểu đồ Use Case 2.2. Quan hệ giữa các Use Case Quan hệ sử dụng  Khi một nhóm các Use Case cùng chung một hành vi nào đó thì hành vi này có thể được tách riêng ra thành một Use Case riêng biệt và nó có thể được sử dụng bởi các Use Case kia, một mối quan hệ như vậy được gọi là quan hệ sử dụng.  Trong quan hệ sử dụng, phải sử dụng toàn bộ Use Case khái quát hóa, nói một cách khác, ta có một Use Case này sử dụng toàn bộ một Use Case khác.  Quan hệ sử dụng giữa các Use Case được biểu thị bằng đoạn thẳng với hình tam giác rỗng trỏ về phía Use Case được sử dụng, đi kèm với stereotype >. 33
  34. 2. Biểu đồ Use Case 2.2. Quan hệ giữa các Use Case Quan hệ chung nhóm  Khi một số các Use Case cùng xử lý các chức năng tương tự hoặc có thể liên quan đến nhau theo một phương thức nào đó, người ta thường nhóm chúng lại với nhau.  Nhóm các Use Case được thực hiện bằng khái niệm "Gói" (Package) của UML. Gói không cung cấp giá trị gia tăng cho thiết kế.  Ví dụ: Tất cả các Use Case có liên quan đến sinh viên sẽ được nhóm thành "Student related" Student related Staff related General 34
  35. 2. Biểu đồ Use Case 2.3. Miêu tả Use Case  Miêu tả Use Case  Miêu tả một Use Case thường được thực hiện trong văn bản. Đây là lời đặc tả đơn giản và nhất quán về việc các tác nhân và các Use Case tương tác với nhau ra sao.  Nó tập trung vào ứng xử đối ngoại của hệ thống và không đề cập tới việc thực hiện nội bộ bên trong hệ thống. Ngôn ngữ và các thuật ngữ được sử dụng trong lời miêu tả chính là ngôn ngữ và các thuật ngữ được sử dụng bởi khách hàng/người dùng. 35
  36. 2. Biểu đồ Use Case 2.3. Miêu tả Use Case Văn bản miêu tả cần phải bao gồm những điểm sau:  Mục đích của Use Case: Mục đích chung cuộc của Use Case là gì? Cái gì cần phải được đạt tới?  Use Case được khởi chạy như thế nào: Tác nhân nào gây ra sự thực hiện Use Case này? Trong hoàn cảnh nào?  Các thông điệp giữa tác nhân và Use Case: Use Case và các tác nhân trao đổi thông điệp hay sự kiện nào để thông báo lẫn cho nhau, cập nhật hoặc nhận thông tin và giúp đỡ nhau quyết định? 36
  37. 2. Biểu đồ Use Case 2.3. Miêu tả Use Case Văn bản miêu tả cần phải bao gồm những điểm sau:  Dòng chảy thay thế trong một Use Case: Một Use Case có thể có những dòng thực thi thay thế tùy thuộc vào điều kiện. Hãy nhắc đến các yếu tố này, nhưng chú ý đừng miêu tả chúng quá chi tiết đến mức độ chúng có thể “che khuất“ dòng chảy chính của các hoạt động trong trường hợp căn bản. Những động tác xử lý lỗi đặc biệt sẽ được miêu tả thành các Use Case khác.  Use Case sẽ kết thúc với một giá trị đối với tác nhân như thế nào: Miêu tả khi nào Use Case được coi là đã kết thúc, và loại giá trị mà nó cung cấp đến tác nhân. 37
  38. 2. Biểu đồ Use Case 2.4. Kiểm tra Use Case  Sau khi các Use Case đã được miêu tả, cần phải thực hiện thẩm tra xem các mối quan hệ có được nhận diện không. Trước khi tất cả các Use Case được miêu tả, nhà phát triển chưa thể có được những kiến thức hoàn tất và tổng thể để xác định các mối quan hệ thích hợp, kiểm thử làm theo phương thức đó có thể sẽ dẫn đến một tình huống nguy hiểm. 38
  39. 2. Biểu đồ Use Case 2.4. Kiểm tra Use Case Trong thời gian thực hiện công việc này, hãy trả lời các câu hỏi sau:  Tất cả các tác nhân liên quan đến một Use Case có mối liên kết giao tiếp với Use Case đó không?  Có tồn tại những sự tương tự giữa một loạt các tác nhân minh họa một vai trò chung và nhóm này có thể được miêu tả là một lớp tác nhân căn bản?  Có tồn tại những sự tương tự giữa một loạt các Use Case, minh họa một dòng chảy hành động chung? Nếu có, điều này có thể được miêu tả là một mối quan hệ sử dụng đến với một Use Case khác?  Có tồn tại những trường hợp đặc biệt của một Use Case có thể được miêu tả là một mối quan hệ mở rộng? 39
  40. 2. Biểu đồ Use Case 2.5 Use Case kiểm thử  Một trong các mục đích chính của Use Case là kiểm thử (testing). Có hai loại kiểm thử khác nhau được thực hiện ở đây: kiểm tra (verification) và phê duyệt xác nhận (validation).  Kiểm tra đảm bảo là hệ thống đã được phát triển đúng đắn và phù hợp với các đặc tả đã được tạo ra.  Phê duyệt xác nhận đảm bảo rằng hệ thống sẽ được phát triển chính là thứ mà khách hàng hoặc người sử dụng cuối thật sự cần đến. 40
  41. 2. Biểu đồ Use Case 2.5 Use Case kiểm thử  Use Case đóng một phần không thể thiếu trong việc giúp đội kiểm thử lập tổ chức việc kiểm thử.  Các Test Case được tạo ra từ các Use Case. Giá trị đầu vào khác nhau sẽ được kiểm thử điều kiện biên. Dòng chảy trong Use Case cũng sẽ có ích cho các Test Case. 41
  42. 2. Biểu đồ Use Case 2.6 Thực hiện các Use Case  Use Case là những lời miêu tả độc lập với sự thực thi các chức năng của hệ thống.  Điều đó có nghĩa là Use Case sẽ được thực hiện (thực thể hóa) trong hệ thống, vậy trách nhiệm để thực thi các hành động được miêu tả trong tài liệu Use Case được phân bổ cho các đối tượng cộng tác thực thi chức năng đó. 42
  43. 2. Biểu đồ Use Case 2.6 Thực hiện các Use Case  Jacobson sử dụng phương pháp định nghĩa ba loại đối tượng căn bản (có nghĩa là ba loại lớp):  các đối tượng biên (boundary objects) ,  đối tượng chỉ huy (control objects) và  đối tượng thực thể (entity objects). Đối với mỗi Use Case, các loại đối tượng này được sử dụng để miêu tả một sự cộng tác thực thi Use Case. 43
  44. 2. Biểu đồ Use Case 2.6 Thực hiện các Use Case  Đối tượng biên: loại đối tượng này nằm gần đường ranh giới của hệ thống mặc dù vẫn nằm bên trong hệ thống. Chúng tương tác với các tác nhân nằm bên ngoài hệ thống và nhận thông điệp cũng như gửi thông điệp đến các loại đối tượng khác nằm bên trong hệ thống. 44
  45. 2. Biểu đồ Use Case 2.6 Thực hiện các Use Case  Đối tượng chỉ huy: loại đối tượng này chỉ huy sự tương tác giữa các nhóm đối tượng. Một đối tượng như thế có thể đóng vai trò "bộ phận điều khiển” cho toàn bộ một Use Case hoàn tất, hay nó có thể thực thi một chuỗi hành động chung của nhiều Use Case. Thường thì một đối tượng như vậy chỉ tồn tại trong quá trình thực thi Use Case. 45
  46. 2. Biểu đồ Use Case 2.6 Thực hiện các Use Case  Đối tượng thực thể: loại đối tượng này đại diện cho các thực thể của bài toán nằm trong phạm vi mà hệ thống xử lý. Thường chúng mang tính thụ động, theo khái niệm là chúng không tự gây nên các tương tác đối với chúng. Trong một hệ thống thông tin, các đối tượng thực thể thường mang tính trường tồn (persistent) và được lưu trữ trong một hệ ngân hàng dữ liệu. Các đối tượng thực thể thường tham gia vào nhiều Use Case khác nhau. 46
  47. 2. Biểu đồ Use Case 2.6 Thực hiện các Use Case 47
  48. 3. Mô hình hóa với Use Case  Trong kỹ thuật mô hình hóa Use Case, hệ thống sẽ có hình dạng của một "hộp đen" và cung cấp các Use Case.  Hệ thống làm điều đó như thế nào, các Use Case được thực thi ra sao, đó là những khía cạnh chưa được đề cập tới trong giai đoạn này.  Trong thực tế, nếu mô hình hóa Use Case được thực hiện trong những giai đoạn đầu của dự án thì thường nhà phát triển sẽ không biết Use Case sau này sẽ được thực thi (tức là biến thành những dòng code thật sự) như thế nào. 48
  49. 3. Mô hình hóa với Use Case Mục tiêu chính yếu đối với các Use Case là để:  Mô tả các yêu cầu chức năng của hệ thống, đây là kết quả rút ra từ sự thỏa thuận giữa khách hàng, người sử dụng cuối) và nhóm phát triển phần mềm.  Tạo nên một mô tả rõ ràng và nhất quán về việc hệ thống cần phải làm gì, làm sao để mô hình có thể được sử dụng nhất quán suốt toàn bộ quá trình phát triển, được sử dụng làm công cụ giao tiếp cho tất cả những người tham gia và để tạo nên một nền tảng cho các mô hình thiết kế các chức năng.  Tạo nên một nền tảng cho việc kiểm thử hệ thống, đảm bảo hệ thống thỏa mãn đúng những yêu cầu do người sử dụng đưa ra. 49
  50. 3. Mô hình hóa với Use Case Mục tiêu chính yếu đối với các Use Case là để:  Cung cấp khả năng theo dõi các yêu cầu về mặt chức năng được chuyển thành các lớp cụ thể cũng như các thủ tục cụ thể trong hệ thống.  Đơn giản hóa việc thay đổi và mở rộng hệ thống qua việc thay đổi và mở rộng mô hình Use Case, sau đó chỉ theo dõi riêng những Use Case đã bị thay đổi cùng những hiệu ứng của chúng trong thiết kế hệ thống và xây dựng hệ thống. 50
  51. 3. Mô hình hóa với Use Case Những công việc cụ thể cần thiết để tạo nên một mô hình Use Case bao gồm: 1. Định nghĩa hệ thống (xác định phạm vi hệ thống) 2. Tìm ra các tác nhân cũng như các Use Case 3. Mô tả Use Case 4. Định nghĩa mối quan hệ giữa các Use Case 5. Kiểm tra và phê chuẩn mô hình. 51
  52. 4 Tạo lập biểu đồ Use Case trong Rational Rose 52
  53. Tóm tắt 1. Biểu đồ Use Case phân tích yêu cầu hệ thống 2. Tập hợp yêu cầu hệ thống 3. Biểu đồ Use Case 4. Mô hình hóa với Use Case 53
  54. DISCUSSION – CÂU HỎI hing/objectorientedanalysisanddesign 54