[Hệ Thống Thông Tin] Phân Tích Chức Năng Phần 2

Sau khi đã tìm được use case, tác nhân cần xây dựng bảng theo mẫu sau
Mô tả sơ lược ca sử dụng
Mô tả sơ lược ca sử dụng
Ø  Mô tả mô hình ca sử dụng tổng thể
mô tả ca sử dụng tổng thể

Sau khi đã mô tả xong chúng ta đã sơ lược có thể tạo được giao diện người dùng, tuy
nhiên sẽ được nghiên cứu sâu hơn sau.
Giao diện người dùng
Giao diện người dùng
Là biểu đồ thể hiện sự tương tác, mối quan hệ giữa các Use case và actor trong hệ thống.
Mỗi hệ thống thường có một biểu đồ Use case chính thể hiện phạm vi của hệ thống và các chức năng chính của hệ thống. Số lượng các Use case khác được tạo ra sẽ tùy thuộc vào yêu cầu. Có thể là:

 * Một biểu đồ thể hiện tất cả các Use case liên quan đến một actor nào đó
 * Một biểu đồ thể hiện tất cả các Use case được cài đặt trong một giai đoạn phát triển.
 * Một biểu đồ thể hiện một Use case và tất cả các mối quan hệ của nó.

Tuy nhiên nên cân nhắc để các biểu đồ thể hiện đủ các thông tin cần thiết, nếu quá nhiều biểu đồ sẽ gây ra sự nhầm lẫn và mất đi lợi ích của việc đơn giản hóa. Tập hợp các Use case giúp cho khách hàng dễ dàng xem xét ở mức tổng quát hệ thống mà ta sẽ xây dựng.
Một hệ thống thông thường có từ 20 đến 50 Use case.
Biểu đồ là các hình vẽ bao gồm các ký hiệu phần tử mô hình hóa được sắp xếp để minh họa một thành phần cụ thể hay một khía cạnh cụ thể của hệ thống. Một mô hình hệ thống thường có nhiều loại biểu đồ, mỗi loại có nhiều biểu đồ khác nhau. Một biểu đồ là một thành phần của một hướng nhìn cụ thể; và khi được vẽ ra, nó thường thường cũng được xếp vào một hướng nhìn. Mặt khác, một số loại biểu đồ có thể là thành phần của nhiều hướng nhìn khác nhau, tùy thuộc vào nội dung của biểu đồ.
Công cụ UML trong Rational Rose
Công cụ UML trong Rational Rose
Phần sau miêu tả các khái niệm căn bản nằm đằng sau mỗi loại biểu đồ. Tất cả các chi tiết về biểu đồ, ngữ cảnh của chúng, ý nghĩa chính xác của chúng và sự tương tác giữa chúng với nhau được miêu tả chi tiết trong các chương sau (mô hình đối tượng – mô hình động). Các biểu đồ lấy làm ví dụ ở đây được lấy ra từ nhiều loại hệ thống khác nhau để chỉ ra nét phong phú và khả năng áp dụng rộng khắp của ULM.
Tài liệu ca sử dụng là việc chúng ta thu thập các thông tin về một ca sử dụng nào đó.

Trong biểu đồ use có biểu đồ gộp và biểu đồ chi tiết. Biểu đồ gộp là biểu đồ cho toàn bộ hệ thống và toàn bộ các use case, các mối quan hệ giữa các usecase.
Như vậy một biểu đồ usecase thể hiên
- Hệ thống
- Tác nhân
- Use Case.
biểu đồ Usecase trong UML

Quan hệ giữa Use case và Actor:
Thường gọi là quan hệ tương tác vì nó thể hiện sự tương tác giữa một actor và một Use case. Mối quan hệ này có thể là hai chiều (từ Actor đến Use case và ngược lại), nó cũng có thể chỉ là một chiều, lúc đó chiều của quan hệ sẽ chỉ ra rằng ai là người khởi tạo liên lạc (communicate). Quan hệ này thể hiện bởi một đường thẳng nối giữa actor và Use case (quan hệ hai chiều) hay một mũi tên (quan hệ một chiều).

Quan hệ giữa Use case với 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.
Quan hệ Uses (sử dụng):
Có thể có nhiều Use case có chung một số chức năng nhỏ. Khi đó nên tách chức năng đó thành một Use case riêng hơn là mô tả nó trong tất cả các Use case mà cần chức năng đó. Khi đó có một quan hệ Uses giữa các Use case trên và Use case vừa tạo ra.

Ví dụ: trong hệ thống quản lý thư viện, mọi Use case đều bắt đầu bằng việc kiểm tra định danh của người dùng. Chức năng này có thể mô tả trong một Use case tên là “Đăng nhập hệ thống”, sau đó các Use case khác sẽ sử dụng Use case này khi cần thiết.
Quan hệ mở rộng
Nhiều khi trong quá trình phát triển Use Case, người 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 (Base Use Case ) đượ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.
Biểu đồ sau chỉ ra Use Case “Ký hợp đồng mua ô tô” là Use Case mở rộng của "Ký hợp đồng bảo hiểm”.
Quan hệ mở rộ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 dùng để mở rộng, đi kèm với stereotype <<extends>>.
Không giống như quan hệ Uses trong đó nói rằng khi một Use case A sử dụng Use case B có nghĩa là trong khi thực hiện Use case A phải thực hiện Use case B, quan hệ Extends dùng để chỉ:

 * Các hành vi tùy chọn: có thể thực hiện hoặc không.
  Ví dụ: khi gửi email có thể thực hiện các thao tác bảo mật nội dung thư hoặc là không. Ta có Use case “Bảo mật” có quan hệ extends với Use case “Gửi email”.
 * Các hành vi mà chỉ thực hiện trong một số điều kiện nhất định.
  Ví dụ như: Khi thêm sách mới trong thư viện thì phải nhập các từ khóa cho nó, nếu từ khóa chưa có phải thực hiện thêm từ khóa rồi mới tiếp tục thực hiện thêm các thông tin về sách. Ta có Use case “Thêm từ khóa” có quan hệ extends Use case “Thêm sách”.
 * Một số hành vi khác sẽ được thực hiện phụ thuộc vào sự lựa chọn của người dùng.
  Ví dụ như: người dùng của hệ thống rút tiền tự động có thể chọn Rút tiền nhanh hoặc Rút tiền theo cách bình thường. Ta có Use case “Rút tiền nhanh” có quan hệ extends với Use case “Rút tiền”.

 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. Các hành động trong Use Case khái quát hóa không cần phải được sử dụng trong cùng một tiến trình. Chúng có thể được trộn lẫn với các hành động xảy ra trong Use Case chuyên biệt hóa.
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 <<uses>>.
- 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 sự tương tác giữa khách hàng và nhân viên thu ngân sẽ được nhóm thành "Package Khách hàng- N/v thu ngân" 
Tóm tắt về Use Case với máy ATM trong ngân hàng lẻ:
Cho tới nay chúng ta đã xác định được một vài Use Case, phân tích dòng hành động chính cũng như các dòng hành động thay thế, cũng như rút ra các mối quan hệ giữa chúng. Biểu đồ sau tổng hợp những thông tin đã thu thập được về nhóm các Use Case căn bản của một hệ thống ATM. 
Biểu đồ Use Case Máy ATM Ngân hàng
Biểu đồ Use Case Máy ATM Ngân hàng
Quan hệ Generalization (thừa kế):
Cũng giống như quan hệ thừa kế giữa hai lớp, quan hệ thừa kế giữa use case A và use case B nói lên rằng use case B kế thừa những đặc điểm của use case A ngoài ra nó cũng có thể có thêm những đặc trưng riêng của nó.
Ví dụ: như kiểm tra định danh người dùng có thể theo nhiều cách: Kiểm tra mã số, kiểm tra dấu vân tay...
Khi đó cả hai đều thực hiện một số hành động tương đối giống nhau của một lớp hành động gọi là “Kiểm tra định danh người dùng”.



System Boundary (khung hệ thống)

Các Use Case thường được bao trong một khung chữ nhật biểu thị hệ thống (System Boundary). Khi đó Uses Case đặt bên trong hệ thống và Actor đặt bên ngoài hệ thống. Ví dụ: Use Case Withdraw là một chức năng của hệ thống con («subsystem») ATM.



[Hệ thống thông tin] Phân tích chức năng phần 1

Một Use case là gì? Là môt tả một tập hợp các dãy hành động mà hệ thống thực hiện để đáp lại tác động của tác nhân và kết thúc sẽ cho kết quả có thể quan sát được và có giá trị đối với một tác nhân của nó. Một use case được vẽ bằng một hình elip nét liền, bên trong viết tên usecase (chức năng). Tên này tuân theo quy tắc đặt tên cho hệ thống.


Tài liệu ca sử dụng – Tài liệu trường hợp sử dụng (Use case document)

Hướng nhìn Use case miêu tả chức năng của hệ thống sẽ phải cung cấp do được tác nhân từ bên ngoài mong đợi. Tác nhân là thực thể tưlơng tác với hệ thống; đó có thể là một người sử dụng hoặc là một hệ thống khác. Hướng nhìn Use case là hướng nhìn dành cho khách hàng, nhà thiết kế, nhà phát triển và người thử nghiệm; nó được miêu tả qua các biểu đồ Use case (use case diagram) và thỉnh thoảng cũng bao gồm cả các biểu đồ hoạt động (activity diagram). Cách sử dụng hệ thống nhìn chung sẽ được miêu tả qua một loạt các Use case trong hướng nhìn Use case, nơi mỗi một Use case là một lời miêu tả mang tính đặc thù cho một tính năng của hệ thống (có nghĩa là một chức năng được mong đợi).

Hướng nhìn Use case mang tính trung tâm, bởi nó đặt ra nội dung thúc đẩy sự phát triển các hướng nhìn khác. Mục tiêu chung của hệ thống là cung cấp các chức năng miêu tả trong hướng nhìn này – cùng với một vài các thuộc tính mang tính phi chức năng khác – vì thế hướng nhìn này có ảnh hưởng đến tất cả các hướng nhìn khác. Hướng nhìn này cũng được sử dụng để thẩm tra (verify) hệ thống qua việc thử nghiệm xem hướng nhìn Use case có đúng với mong đợi của khách hàng (Hỏi: "Đây có phải là thứ bạn muốn") cũng như có đúng với hệ thống vừa được hoàn thành (Hỏi: "Hệ thống có hoạt động như đã đặc tả?”).
Trong phần này ta cần phải tìm tác nhân, tìm các ca sử dụng, mô tả ngắn gọn ca sử dụng, mô tả mô hình ca sử dụng tổng thể.
Ca sử dụng, trường hợp sử dụng hay use case là gì? Là công cụ giúp ta mô hình hoá hệ thống từ hướng nhìn của người sử dụng gọi là Use Case.
Use Case là một công cụ trợ giúp cho công việc của nhà phân tích cùng người sử dụng quyết định tính năng của hệ thống. Một tập hợp các Use Case sẽ làm nổi bật một hệ thống theo phương diện những người dùng định làm gì với hệ thống này.
Hãy xét một ngân hàng nhỏ. Hệ thống tương lai trong trường hợp này sẽ só nhiều người sử dụng, mỗi người sẽ giao tiếp với hệ thống cho một mục đích khác biệt:
- Quản trị gia sử dụng hệ thống cho mục đích thống kê
- Nhân viên tiếp khách sử dụng hệ thống để thực hiện các dịch vụ phục vụ khách hàng.
- Nhân viên phòng đầu tư sử dụng hệ thống để thực hiện các giao dịch liên quan đến đầu tư.
- Nhân viên thẩm tra chữ ký sử dụng hệ thống cho mục đích xác nhận chữ ký và bảo trì thông tin liên quan đến khách hàng.
- Khách hàng giao tiếp với hệ thống (nhà băng) cho các hoạt động sử dụng dịch vụ như mở tài khoản, gửi tiền vào, rút tiền mặt, …
Quá trình tương tác giữa người sử dụng và hệ thống trong mỗi một tình huống kể trên sẽ khác nhau và phụ thuộc vào chức năng mà người sử dụng muốn thực thi cùng hệ thống.
Nhóm phát triển hệ thống cần phải xây dựng nên một kịch bản nêu bật sự tương tác cần thiết giữa người sử dụng và hệ thống trong mỗi khả năng hoạt động. Ví dụ như kịch bản cho sự tương tác giữa nhân viên thu ngân và hệ thống của bộ phận tiết kiệm trong suốt tiến trình của một giao dịch. Một kịch bản khác ví dụ là chuỗi tương tác xảy ra giữa bộ phận tiết kiệm và bộ phận đầu tư trong một giao dịch chuyển tiền.
Ø  Xác định tác nhân.
Tác nhân là gì:
- 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.
- Một tác nhân là một dạng của thực thể (1 lớp) chứ không phải là một thực thể.
- Tác nhân mô tả và đại diện cho một vai trò chứ không phải là một người sử dụng thật sự và cụ thể của hệ thống.
- Một tác nhân giao tiếp với hệ thống bằng cách gởi và nhận thông điệp.
- Tác nhân đã kích hoạt và gây ra usecase.
- Tác nhân được xếp loại:
o Tác nhân chính: là tác nhân sử dụng chức năng cơ bản của hệ thống.
o Tác nhân phụ: là tác nhân sử dụng các chức năng phụ của hệ thống.
Cả 2 loại tác nhân này đều được mô hình hoá để đảm bảo mô tả đầy đủ các chức năng của hệ thống.
- Tác nhân có thể được định nghĩa theo dạng tác nhân chủ động (là tác nhân gây ra usecase) hay tác nhân thụ động (là tác nhân không bao giờ gây ra usecase mà chỉ tham gia vào một hoặc nhiều usecase)
• Phương pháp tìm tác nhân:
- Khi nhận diện các 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ể tự đặ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.
- Xác định tác nhân cần usecase nào có thể nhận diện các tác nhân qua việc trả lời một số câu hỏi như sau:
o Ai sẽ sử dụng những chức năng chính của hệ thống? => tác nhân chính.
o 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ọ?
o Ai sẽ cần bảo trì, quản trị và đảm bảo cho hệ thống hoạt động => tác nhân phụ được xác định.
o Hệ thống sẽ phải xử lý và làm việc với những trang thiết bị hệ thống nào?
o Hệ thống cần phải tương tác với các hệ thống khác nào?
- Khi đi tìm những người sử dụng hệ thống dễ bắt gặp nhất là những người đang ngồi trước màn hình máy tính. Một điều nên nhớ rằng một người sử dụng có thể ở bất kỳ nơi nào trực tiếp hay giao tiếp với hệ thống. Có thể là bất kỳ một vật nào tương tác với hệ thống, bất kỳ một dịch vụ nào mà hệ thống đang sử dụng.
Ø  Xác định ca sử dụng - trường hợp sử dụng - usecase.
Usecase là gì:
- Usecase là công cụ giúp chúng ta mô hình hoá hệ thống từ hướng nhìn của người sử dụng.
- Là công cụ giúp cho công việc của một nhà phân tích cùng với người sử dụng quy định tính năng của hệ thống.
- Là một tập hợp các usecase sẽ là nổi bậc một hệ thống theo phương diện những người dùng định làm gì với hệ thống này.
• Các phương pháp để tìm usecase:
- Quá trình tìm các usecase thì phải bắt đầu từ các tác nhân.
  • Actor này cần những chức năng nào từ hệ thống? Hành động chính của Actor là gì ?.
  • Actor 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?
  • Actor 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?
  • Hệ thống có cần phải thông báo cho Actor về những thay đổi bất ngờ trong nội bộ hệ thống?
  • Công việc hàng ngày của Actor có thể được đơn giản hóa hoặc hữu hiệu hóa qua các chức năng mới trong hệ thống (thường đây là những chức năng tiêu biểu chưa được tự động hóa trong hệ thống)?
  • Use Case có thể được gây ra bởi các sự kiện nào khác?
  • Hệ thống cần những thông tin đầu vào/đầu ra nào? Những thông tin đầu vào/đầu ra đó từ đâu tới và sẽ đi đâu?
  • Khó khăn và thiếu hụt chính trong hệ thống hiện thời nằm ở đâu (thủ công /tự động hóa)?
- Đối với mỗi tác nhân phải hỏi các câu hỏi sau đây:

Tác nhân này cần những chức năng nào của hệ thống, hoạt động chính của tác nhân là gì.
Vd: Một giao dịch rút tiền bằng máy ATM hoạt động chính của tác nhân là:

t Tác nhân cần phải đọc, tạo, huỷ bỏ, sửa đổi hay lưu trữ một loại thông tin nào đó trong hệ thống.
t Tác nhân cần phải báo cho hệ thống biết về sự kiện nào đó. Những sự kiện như thế sẽ đại diện cho chức năng nào?
t Hệ thống cần phải thông báo cho tác nhân về những sự thay đổi bất ngờ trong nội bộ của hệ thống.
Trong ví dụ ngân hàng nhỏ ở trên, một số những Use Case dễ thấy nhất là:
- Một khách hàng mở một tài khoản mới.
- Phòng đầu tư tính toán tiền lãi cho các tài khoản đầu tư.
- Một chương trình đầu tư mới được đưa vào áp dụng.
- Yêu cầu chuyển tiền của khách hàng được thực hiện.
- Chuyển tiền theo kỳ hạn từ một tài khoản đầu tư sang một tài khoản tiết kiệm.
Ø  Mô hình hóa usecase
Mô hình Use Case mô tả hướng nhìn Use Case của hệ thống. Hướng nhìn này là rất quan trọng, bởi nó ảnh hưởng đến tất cả các hướng nhìn khác của hệ thống. Cả cấu trúc logic lẫn cấu trúc physic đều chịu ảnh hưởng từ các Use Case, bởi chức năng được đặc tả trong mô hình này chính là những chức năng được thực thi trong các cấu trúc kia. Mục đích cuối cùng là thiết kế ra một giải pháp thỏa mãn các yêu cầu đó.
Mô hình hóa các Use Case chẳng phải chỉ được dùng để nắm bắt các yêu cầu của hệ thống mới; nó cũng còn được sử dụng để hỗ trợ cho việc phát triển một phiên bản mới của hệ thống. Khi phát triển một phiên bản mới của hệ thống đang tồn tại, người ta sẽ bổ sung thêm các chức năng mới vào mô hình Use Case đã có bằng cách thêm vào các tác nhân mới cũng như các Use Case mới, hoặc là thay đổi đặc tả của các Use Case đã có. Khi bổ sung thêm vào mô hình Use Case đang tồn tại, hãy chú ý để không bỏ ra bất kỳ một chức năng nào vẫn còn được cần tới.
Ø  Mô tả sơ lược ca sử dụng
Như đã trình bày, lời 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 (hệ thống) 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.
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 nói chung đều mang tính hướng mục đích và mục đích của mỗi Use Case cần phải rõ ràng.
- 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?
- Chuỗi 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? Yếu tố nào sẽ miêu tả dòng chảy chính của các thông điệp giữa hệ thống và tác nhân, và những thực thể nào trong hệ thống được sử dụng hoặc là bị thay đổi?
- 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: Hãy 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.
Hãy nhớ rằng lời miêu tả này sẽ xác định những gì được thực thi có liên quan đến tác nhân bên ngoài, chứ không phải những sự việc được thực hiện bên trong hệ thống. Văn bản phải rõ ràng, nhất quán, khiến cho khách hàng có thể dễ dàng hiểu và thẩm tra chúng (để rồi đồng ý rằng nó đại diện cho những gì mà anh/cô ta muốn từ phía hệ thống). Tránh dùng những câu văn phức tạp, khó diễn giải và dễ hiểu lầm.
Một Use Case cũng có thể được miêu tả qua một biểu đồ hoạt động. Biểu đồ hoạt động này chỉ ra chuỗi các hành động, thứ tự của chúng, các quyết định chọn lựa để xác định xem hành động nào sau đó sẽ được thực hiện.
Để bổ sung cho lời miêu tả một Use Case, người ta thường đưa ra một loạt các cảnh kịch cụ thể để minh họa điều gì sẽ xảy ra một khi Use Case này được thực thể hóa. Lời miêu tả cảnh kịch minh họa một trường hợp đặc biệt, khi cả tác nhân lẫn Use Case đều được coi là một thực thể cụ thể. Khách hàng có thể dễ dàng hiểu hơn toàn bộ một Use Case phức tạp nếu có những cảnh kịch được miêu tả thực tiễn hơn, minh họa lại lối ứng xử và phương thức hoạt động của hệ thống. Nhưng xin nhớ rằng, một lời miêu tả cảnh kịch chỉ là một sự bổ sung chứ không phải là ứng cử viên để thay thế cho lời miêu tả Use Case.
Sau khi các Use Case đã được miêu tả, một hoạt động và một công việc đặc biệt cần phải thực hiện là thẩm tra xem các mối quan hệ (đã đề cập tới trong phần 2.7) 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, thử nghiệm làm theo phương thức đó có thể sẽ dẫn đến một tình huống nguy hiểm. 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 liệu có thể được miêu tả là một lớp tác nhân căn bản (base class)?
- 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ó, liệu đ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?
- Có tồn tại một tác nhân nào hay một Use Case nào không có mối liên kết giao tiếp? Nếu có, chắc chắn ở đây đã có chuyện lầm lạc, sai trái: Tại sao lại xuất hiện tác nhân này?
- Có lời yêu cầu nào về chức năng đã được xác định, nhưng lại không được bất kỳ một Use Case nào xử lý? Nếu thế, hãy tạo một Use Case cho yêu cầu đó.
Văn bản miêu tả một Use Case đơn giản:
Ví dụ Use Case "Cung Cấp Thông Tin Về Một Tài Khoản Tại Nhà Băng ABC”: Sau khi phân tích hệ thống, ta nhận thấy cần có một Use Case để in lên màn hình của nhân viên nhà băng tất cả những chi tiết về một tài khoản của một khách hàng.

Đặc tả 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.
Chi tiết tài khoản: // tên Use Case
Số Use Case: UCSEC…
Miêu tả ngắn: // miêu tả ngắn gọn Use Case
Use Case "chi tiết tài khoản" cho phép nhân viên nhà băng xem các chi tiết của một tài khoản mà anh ta định tìm hiểu.
Dòng chảy các sự kiện: // dòng logic chung
Nhân viên chọn Chi Tiết Tài Khoản trên menu. Một con đường khác để chỉ ra các thông tin chi tiết của tài khoản là gọi từ Màn Hình Tóm Tắt Thông Tin Về Tài Khoản d.
Dòng hành động chính: // dòng logic chi tiết.
Mỗi khách hàng sẽ có một số định danh gọi là CustomerId. Một khách hàng có thể có nhiều tài khoản. Sau khi nhân viên nhập CustomerId vào hệ thống, màn hình phải in ra tất cả những tài khoản thuộc về khách hàng này và thuộc về nhà băng ABC, rải rác tại tất cả các chi nhánh. Khi chọn tiếp loại tài khoản và số tài khoản, các chi tiết của tài khoản mong muốn sẽ được in ra.
Loại tài khoản tiết kiệm: Nếu loại tài khoản được chọn là tài khoản tiết kiệm, các chi tiết sau đây sẽ được in ra:
- Mức tiền hiện có
- Các tờ sec chưa thanh toán
- Lượng tiền tín dụng được phép
- Lượng tiền lãi cho tới ngày hôm nay
- Lượng tiền tối thiểu cần phải có trong tài khoản
Loại tài khoản đầu tư: Nếu loại tài khoản được chọn là loại đầu tư, các chi tiết sau đây sẽ được in ra.
- Hạn đầu tư
- Số tiền đầu tư
- Ngày đầu tư
- Lượng tiền cuối hạn
- Ngày cuối hạn
- Tỷ lệ lời
Dòng hành động thay thế: // chuỗi logic thay thế
Không tìm thấy chi tiết: Khi chọn một số tài khoản không thích hợp (không có tài khoản tương ứng) dù vì lý do chức năng hay kỹ thuật, hệ thống sẽ đưa ra một màn hình báo lỗi.
Điều kiện thoát: // Use Case kết thúc như thế nào?
Nút Thoát: Khi chọn nút thoát, người sử dụng sẽ quay trở lại màn hình chính.
Nút Xem Thêm: Khi chọn nút này, người sử dụng sẽ được yêu cầu chọn loại tài khoản từ một danh sách đổ xuống.
Nút Xem Giao Dịch: Khi chọn nút này, người sử dụng sẽ được chuyển sang màn hình "Giao dịch" và theo Use Case số giao dịch, màn hình sẽ chỉ ra những giao dịch đã xảy ra đối với tài khoản, bên cạnh những chi tiết chính của tài khoản.
Nút Yêu Cầu In Kết Quả: Khi chọn phần thực đơn này, kết quả giao dịch sẽ được in ra ở một máy in địa phương nối trực tiếp với máy tính của nhân viên.
Các yêu cầu đặc biệt: // các yêu cầu đặc biệt
Hệ thống có khả năng in lên màn hình bằng những ngôn ngữ khác. Chức năng này sẽ được kích hoạt khi người sử dụng chọn mục Ngoại Ngữ trên menu.
Điều kiện trước đó: // điều xảy ra trước khi Use Case được thực hiện
Bảo an: Người sử dụng (nhân viên tiếp khách) được cung cấp một số định danh riêng biệt để truy nhập vào hệ thống.
Dịch chuyển: Người sử dụng chỉ đến được màn hình Chi Tiết Tài Khoản sau khi đã truy nhập thành công và Identify thành công.
Điều kiện sau đó: // điều gì xảy ra sau khi Use Case được thực hiện?

Bài đăng phổ biến

Bài viết mới nhất

Tin học cơ bản - Nền tảng của mọi kỹ năng

Mọi thông tin trên blog đều được giữ bản quyền bởi Tin học cơ bản. Các bạn nếu muốn lấy thông tin từ blog vui lòng ghi rõ nguồn Tinhoccoban.net

TIN HỌC CƠ BẢN