Chương 5 : Áp dụng UML
5.1 Pha khởi đầu(Inception)
5.1.1 Khái quát
Hầu hết các dự án cần có một bƣớc khởi đầu ngắn, trong đó các câu hỏi sau đây đƣợc tìm hiểu:
- Nghiệp vụ cũng nhƣ bức tranh tổng thể của dự án là gì? - Có khả thi hay không?
- Sẽ mua sản phẩm hay tự xây dựng? - Chi phí sơ bộ cho dự án là bao nhiêu? - Chúng ta nên tiếp tục hay dừng lại?
Để xác đinh bức tranh tổng thể cũng nhƣ đánh giá chi phí sơ bộ thì chúng ta cần phải thực hiện tìm hiểu yêu cầu. Tuy nhiên mục đích của pha Khởi đầu này không phải là để xác định tất cả các yêu cầu, hay tạo ra các đánh giá chi phí và kế hoạch dự án một cách chính xác mà ý tƣởng ở đây chỉ là thực hiện điều tra đủ để hình thành những ý kiến hợp lý về mục đích tổng thể và tính khả thi của một hệ thống mới, và quyết định nó có đáng để đầu tƣ xem xét sâu hơn không.
Với mục đích của pha Khởi đầu nhƣ trên ngoài sơ đồ Use Case đơn giản không xuất hiện các sơ đồ khác của UML, hầu hết các sơ đồ UML sẽ xuất hiện trong pha tiếp theo là pha Chuẩn bị(Elaboration)
5.1.2 Các sản phẩm(Artifact) có thể bắt đầu trong pha khởi đầu
- Bức tranh tổng thể và tình huống nghiệp vụ(Vision and Business Case): Mô tả các mục tiêu, ràng buộc mức cao, mô tả các tình huống nghiệp vụ
- Mô hình Use-Case: Mô tả các yêu cầu chức năng và yêu cầu phi chức năng - Bảng đặc tính phụ: Mô tả các yêu cầu khác
- Bảng thuật ngữ: Các thuật ngữ nghiệp vụ chính
- Danh sách các nguy cơ và kế hoạch quản lý mạo hiểm: Mô tả các mạo hiểm về kinh doanh, kỹ thuật, nguồn lực, lịch trình và các ý kiến để giảm thiểu nguy cơ cũng nhƣ kế hoạch hành động khi tình huống mạo hiểm xảy ra
- Nguyên mẫu và bằng chứng của các khái niệm: Làm rõ bức tranh tổng thể và xác nhận lại các sáng kiến kỹ thuật
- Kế hoạch pha và kế hoạch phát triển phần mềm: Dự đoán sơ bộ về thời gian và nguồn lực cần thiết cho pha Chuẩn bị(Elaboration). Các công cụ, con ngƣời, đào tạo và các nguồn lực khác
- Tình huống phát triển(Development Case): Mô tả các bƣớc và sản phẩm(artifact) trong quy trình RUP đƣợc thiết lập tùy biến cho dự án
5.1.3 Tìm hiểu yêu cầu(Requirement)
Yêu cầu là những năng lực và điều kiện mà hệ thống hay nói rộng hơn là dự án phải đáp ứng. Một trong những thử thách chính của công việc tìm hiểu yêu cầu đó là tìm ra, giao tiếp và ghi nhớ những thứ thực sự cần thiết theo một định dạng mà khách hàng và thành viên của đội phát triển có thể hiểu một cách rõ ràng
Trong quy trình phần mềm RUP, các yêu cầu đƣợc phân loại dựa trên mô hình FURPS+, nó có nghĩa nhƣ sau:
- Funtional(Chức năng): Các đặc điểm, các khả năng và tính an toàn
- Usability(Khả năng dễ sử dụng): Các nhân tố con ngƣời, trợ giúp, tài liệu
- Reliability(Tính tin cậy): Tần suất gặp lỗi, khả năng phục hồi, khả năng dự đoán - Performance(Hiệu năng): Thời gian đáp ứng, năng lực chịu tải, độ chính xác,
tính sẵn sàng, sử dụng tài nguyên.
- Supportibility(Khả năng hỗ trợ): Khả năng thích ứng, khả năng duy trì, khả năng quốc tế hóa và khả năng cấu hình.
Dấu + trong FURPS+ chỉ một số nhân tố con, phụ thuộc nhƣ sau:
- Implementation(Thực hiện): Hạn chế tài nguyên, các ngôn ngữ, công cụ, phần cứng...
ngoài
- Operations(Điều hành): Quản lý hệ thống trong thiết lập hoạt động của nó - Packaging(Đóng gói)
- Legal(Hợp pháp): Giấy phép ...
Sử dụng mô hình FURPS+ nhƣ là một danh sách kiểm tra cho việc tìm hiểu yêu cầu rất hữu dụng để có thể giảm thiểu nguy cơ bỏ sót những vấn đề quan trọng của hệ thống
Trong sử dụng thông thƣờng, các yêu cầu thƣờng đƣợc phân loại thành Yêu cầu chức năng và Yêu cầu phi chức năng
Các yêu cầu chức năng đƣợc tìm hiểu và ghi nhớ trong Mô hình Use Case và trong danh sách đặc tính của Vision artifact(Bức tranh tổng thể)
Các yêu cầu khác có thể đƣợc ghi nhớ trong các Use Case liên quan tới nó hoặc trong bảng đặc tính phụ
5.1.4 Mô hình Use Case: Viết yêu cầu trong ngữ cảnh
Các Use Case đƣợc sử dụng rộng rãi để tìm ra và ghi nhớ các yêu cầu(Đặc biệt là các yêu cầu chức năng). Viết các Use Case là một kỹ thuật rất tốt để hiểu và mô tả các yêu cầu. Quy trình RUP định nghĩa Mô hình Use Case trong Requirement Discipline, về cơ bản đây là một tập hợp các Use Case, hoặc một mô hình các chức năng và môi trƣờng của hệ thống
Use Case là các tài liệu dạng mô tả bằng lời, không phải các sơ đồ và công việc mô hình hóa Use Case về cơ bản là hành động viết chứ không phải vẽ. Tuy nhiên UML định nghĩa ra sơ đồ Use Case để minh họa tên của các Use Case và các Actor cũng nhƣ quan hệ giữa chúng
Use Case là một tập hợp các tình huống thành công hoặc thất bại có liên hệ với nhau mà mô tả các tác nhân sử dụng hệ thống để hỗ trợ một mục tiêu cụ thể
Các loại và các định dạng Use Case
Use Case hộp đen là loại thông dụng và đƣợc khuyên dùng nhất, nó không mô tả hoạt động bên trong của hệ thống cũng nhƣ các thành phần hoặc thiết kế, mà ngƣợc lại hệ thống đƣợc mô tả là có trách nhiệm gì, một hình thức của tƣ duy hƣớng đối tƣợng. Bằng cách định nghĩa trách nhiệm của hệ thống với các Use Case hộp đen chúng ta có thể xác định hệ thống phải làm gì(Các yêu cầu chức năng) mà không phải quyết định nó sẽ làm nhƣ thế nào(Thiết kế). Trong phân tích yêu cầu cần tránh đƣa ra các quyết định “nhƣ thế nào” và chỉ xác định hành xử bên ngoài của hệ thống nhƣ là một hộp đen. Sau này, trong giai đoạn thiết kế sẽ tạo ra các giải pháp đáp ứng các đặc tính yêu cầu.
- Vắn tắt: Một đoạn tổng kết súc tích, thƣờng là mô tả tình huống thành công chính yếu nhất
- Bình thƣờng: Định dạng các đoạn mô tả không chính thống. Nhiều đoạn văn mô tả các tình huống khác nhau.
- Đầy đủ: Dạng kỹ lƣỡng nhất, tất cả các bƣớc và các tình huống đƣợc viết chi tiết đồng thời có các phần hỗ trợ nhƣ là các điều kiện tiên quyết và các đảm bảo thành công
Định dạng của một Use Case loại đầy đủ có thể có các phần nhƣ sau: - Tác nhân chính
- Các thành phần tham gia hệ thống và mối quan tâm tƣơng ứng - Điều kiện tiên quyết
- Điều kiện xác định thành công - Tình huống thành công chính yếu - Các tình huống mở rộng
- Các yêu cầu đặc biệt
- Danh mục các công nghệ và dữ liệu - Tần suất xuất hiện
- Các vấn đề để mở
Mục tiêu và phạm vi của một Use Case
Làm thế nào xác định đƣợc các Use Case? Chúng ta thƣờng không chắc chắn một Use Case tạo ra liệu có hợp lý hoặc hữu dụng không. Các nhiệm vụ có thể nhóm với nhau theo nhiều mức, từ một hay vài bƣớc nhỏ cho tới cấp các hoạt động của doanh nghiệp. Vậy Use Case nên đƣợc diễn đạt ở mức nào và phạm vi nào?
Để phân tích yêu cầu cho một ứng dụng phần mềm ta tập trung vào các Use Case ở mức EBP(Quy trình tác nghiệp cơ sở)
EBP là thuật ngữ trong lĩnh vực quy trình tác nghiệp đƣợc định nghĩa nhƣ sau: Một nhiệm vụ đƣợc thực hiện bởi một ngƣời trong một nơi tại một thời điểm để đáp ứng một sự kiện tác nghiệp mà đem lại một giá trị nghiệp vụ có ý nghĩa đồng thời để lại dữ liệu ở trạng thái ổn định
Đôi khi ta cũng không phải tuân thủ quá chặt chẽ từng câu chữ của định nghĩa, chẳng hạn liệu một Use Case có vi phạm EBP nếu cần thiết có 2 ngƣời, hoặc có một ngƣời phải chuyển động vòng quanh. Use Case không phải là một bƣớc nhỏ nhƣ “Xóa một dòng” hay “In tài liệu” mà một tình huống thành công chính yếu có thể bao gồm 5 hay 10 bƣớc, nó không kéo dài cả ngày và qua nhiều phiên làm việc, nó là công việc hoàn thành trong một phiên làm việc đơn lẻ
Các tác nhân có mục tiêu và sử dụng ứng dụng để thỏa mãn các mục tiêu này. Do vậy một Use Case mức EBP đƣợc gọi là một Use Case mức mục tiêu ngƣời sử dụng, để
nhân chính. Điều này dẫn tới thủ tục sau đây:
1. Chọn biên của hệ thống. Nó chỉ là ứng dụng phần mềm, phần cứng kết hợp ứng dụng, cộng với ngƣời sử dụng nó, hay là toàn bộ tổ chức?
2. Xác định các tác nhân chính là ngƣời sử dụng có mục tiêu đƣợc đáp ứng qua việc sử dụng các dịch vụ của hệ thống
3. Với mỗi tác nhân, xác định các mục tiêu ngƣời sử dụng. Đƣa chúng lên mức cao nhất của mục tiêu ngƣời sử dụng mà thỏa mãn định nghĩa EBP
4. Định nghĩa các Use Case mà thỏa mãn các mục tiêu ngƣời dùng; Đặt tên chúng theo các mục tiêu của chúng. Thông thƣờng thì có sự tƣơng ứng một một giữa các Use Case mức mục tiêu ngƣời dùng và các Mục tiêu ngƣời dùng