Bài 3: Mô hình hóa yêu cầu
Sau khi chúng ta đã thu thập được yêu cầu, việc chúng ta cần làm là mô hình chúng. Câu hỏi đặt ra ở đây là tại sao phải mô hình chúng làm gì cho mất công? Vì trong thực tế nếu dùng văn bản viết thì có khả năng không diễn đạt được vấn đề mình muốn nói. Cho nên chúng ta phải dùng hình vẽ để biểu đạt cho người khác dễ hiểu hơn.(vì hình vẽ chỉ có vài qui tắc, còn viết văn bản thì … ngôn ngữ vô số, khi người khác đọc có khả năng bị rào cản ngôn ngữ …) --> một ngôn ngữ ra đời để mô hình các cái mà chúng ta thu thập được.(nói chung là mô tả bằng ngôn ngữ rất dễ gây ra nhầm lẫn và nó không có tính trực quan.).
Chúng ta dùng cái lược đồ use-case để biểu diển.
Trong lược đồ use-case 2 khái niệm đầu tiên cần phải hiểu đó là Actor và UseCase.
1. Actor
Nó bao gồm các phần mềm bên ngoài, phần cứng, và con người mà có tác động trực tiếp đến phần mềm mà chúng ta đang xây dựng.
Hình vẽ của nó: (hình người).
Nói cho dễ nhớ: người đứng dạng chân và giơ hai tay ngang ra (giống như một người đang diễn kịch) -> diễn viên -> Actor.
Lấy ví dụ:
Trong phần mềm là trang web 4rum thì những Actor là người dùng mà bạn có thể dễ dàng chỉ ra là: Admin, Mod, Người Dùng Bình Thường, Khách.
ở đây mình sẽ giải thích tại sao người ta lại dùng từ Actor để gọi chung các cái này. Đó là vì ngoài đời Actor có nghĩa là “Diễn Viên” tức là 1 người có khả năng đóng nhiều vai khác nhau ứng với các bộ phim khác nhau(trong đây là ứng với các góc nhìn khác nhau.). Nói rõ hơn là các UserCase là người dùng nhìn dưới các góc độ của một phần mềm.
Ví dụ trong một phần mềm quản lý: bạn được thuê làm quản lý hệ thống đó. Và sau đó khi yêu cầu công việc cần thêm một người nhập liệu cho chương trình thì bạn xin làm để kiếm thêm thu nhập(thời kỳ lạm phát). Thì khi đó bạn không còn là một admin nữa mà là một người dùng bình thường chỉ có quyền ghi đối với cơ sở dữ liệu.
Đôi khi để cho dễ nhìn hơn trong mô hình usecase người ta còn có nhu cầu tổ chức nói (các quyền của Actor này thì Actor khác đều có thể làm thì bạn có thể chế ra một Actor khác là cha của 2 Actor này.)
Ví dụ trong phần mềm quản lý khách hàng thì khách hàng tiềm năng và khách hàng thông thường đều được quyền đặt hàng.(cái này chỉ có tác dụng là cho đỡ rối hình vẽ thôi) thì chúng ta “chế” ra Actor khách hàng chung. Lưu ý cái này nó chỉ mượn ký hiệu kế thừa bên thiết kế lớp đối tượng chứ không nói là Khách hàng và khách hàng đặc biệt là 2 lớp được kế thừa lại từ lớp khách hàng.
VD:
trước khi chế.
sau khi chế.
Chúng ta dùng cái lược đồ use-case để biểu diển.
Trong lược đồ use-case 2 khái niệm đầu tiên cần phải hiểu đó là Actor và UseCase.
1. Actor
Nó bao gồm các phần mềm bên ngoài, phần cứng, và con người mà có tác động trực tiếp đến phần mềm mà chúng ta đang xây dựng.
Hình vẽ của nó: (hình người).
Nói cho dễ nhớ: người đứng dạng chân và giơ hai tay ngang ra (giống như một người đang diễn kịch) -> diễn viên -> Actor.Lấy ví dụ:
Trong phần mềm là trang web 4rum thì những Actor là người dùng mà bạn có thể dễ dàng chỉ ra là: Admin, Mod, Người Dùng Bình Thường, Khách.
ở đây mình sẽ giải thích tại sao người ta lại dùng từ Actor để gọi chung các cái này. Đó là vì ngoài đời Actor có nghĩa là “Diễn Viên” tức là 1 người có khả năng đóng nhiều vai khác nhau ứng với các bộ phim khác nhau(trong đây là ứng với các góc nhìn khác nhau.). Nói rõ hơn là các UserCase là người dùng nhìn dưới các góc độ của một phần mềm.
Ví dụ trong một phần mềm quản lý: bạn được thuê làm quản lý hệ thống đó. Và sau đó khi yêu cầu công việc cần thêm một người nhập liệu cho chương trình thì bạn xin làm để kiếm thêm thu nhập(thời kỳ lạm phát). Thì khi đó bạn không còn là một admin nữa mà là một người dùng bình thường chỉ có quyền ghi đối với cơ sở dữ liệu.
Đôi khi để cho dễ nhìn hơn trong mô hình usecase người ta còn có nhu cầu tổ chức nói (các quyền của Actor này thì Actor khác đều có thể làm thì bạn có thể chế ra một Actor khác là cha của 2 Actor này.)
Ví dụ trong phần mềm quản lý khách hàng thì khách hàng tiềm năng và khách hàng thông thường đều được quyền đặt hàng.(cái này chỉ có tác dụng là cho đỡ rối hình vẽ thôi) thì chúng ta “chế” ra Actor khách hàng chung. Lưu ý cái này nó chỉ mượn ký hiệu kế thừa bên thiết kế lớp đối tượng chứ không nói là Khách hàng và khách hàng đặc biệt là 2 lớp được kế thừa lại từ lớp khách hàng.
VD:
trước khi chế.
sau khi chế.
2. UseCase
UseCase là những chức năng trong chương trình của bạn cung cấp cho người dùng. Cái này có thể hiểu là một chức năng của hệ thống mang lại một ý nghĩa nhất địn đối với người dùng.
Hình vẽ nó được biểu diễn bằng một hình Elip.
3. Sự tương tác giữa Actor và UseCaseDùng hình vẽ sau để miêu tả nó ( nó là hình mũi tên với đường nét liền). ở đây do mình làm biếng up hình nên vẽ đại vậy chứ hình thiệt nó sẽ hơi khác.
___________________________>
Chiều của mũi tên thể hiện vai trò của sự tương tác: cái nào chủ động gọi cái nào
• Từ Actor vào một User
Vd: trong 4Rom thì tạo Actor Mod được quyền sử dụng UseCase Xóa bài viết.
• Từ User vào một Actor:Ví dụ khi bạn tạo một chương trình chơi game có qui định là chương trình là: sẽ tự động sắp xếp người chơi vào một vị trí.
Sự tương tác giữa Actor và Actor.Đôi lúc trong khi sử dụng Chức năng này(UserCase1) lại có nhu cầu phát sinh chức năng thứ 2 ngay sau đó.
Ví dụ: trong các trang web Eshopping thì chức năng đặt hàng và chức năng thanh toán.
Chức năng đặt hàng sẽ gọi thực hiện một chức năng thanh toán.
Nó có thể được biểu diễn như sau:
Chức năng A luôn luôn gọi chức năng B
Chức năng A thỉnh thoảng gọi chức năng B
4. Dòng sự kiện chính(happy path[con đường hạnh phúc]).Tại đây bạn sẽ mô tả con đường đi chính thức mà chương trình bạn sẽ “đi” từ khi bắt đầu đến khi kết thúc(chỉ nói các sự kiện chính chứ không nói các trương hợp khác ngoài sự kiện chính).
5. Đặc tả UserCase
ứng với mỗi Usecase các bạn nêu các ý sau:
• Tóm tắt.
• Dòng sự kiện
• Các yêu cầu
• Trạng thái hệ thống khi User bắt đầu Usecase
• Trạng thái hệ thống sau khi thực hiện Usecase
• Điểm mở rộng.
Không có nhận xét nào:
Đăng nhận xét