CHƢƠNG 3: PHÂN TÍCH HƢỚNG ĐỐI TƢỢNG Giới thiệu: Chƣơng này trình bày các bƣớc phân tích hƣớng đối tƣợng, các khái niệm và quy tắc liên quan đến quá trình phân tích hệ thống. Nội dung cụ thể gồm: - Tổng quan các bƣớc của pha phân tích hƣớng đối tƣợng - Bƣớc xây dựng mô hình usecase và kịch bản - Bƣớc xây dựng mô hình lớp - Bƣớc xây dựng mô hình động dựa trên biểu đồ trạng thái Mục tiêu: - Giải thích đƣợc các khái niệm usecase, actor - Minh họa các usecase và actor trong các mô hình usecase sử dụng ký pháp UML - Giải thích việc phát sinh luồng các sự kiện từ một usecase. - Phân biệt giữa các đối tƣợng và các lớp - Liệt kê các đặc trƣng của một lớp. - Phân tích các lớp từ một luồng các sự kiện - Mô tả và nhóm các biên, thực thể, và các stereotype - Vẽ các sơ đồ usercase, sơ đồ lớp trong UML Nội dung chính: I.
TỔNG QUAN VỀ PHÂN TÍCH HƢỚNG ĐỐI TƢỢNG 1. Vai trò của pha phân tích Trong các bƣớc của vòng đời phát triển phần mềm nói chung, pha phân tích (hay đặc tả) có các nhiệm vụ sau: - Thiết lập một cách nhìn tổng quan rõ ràng về hệ thống và các mục đích chính của hệ thống cần xây dựng. - Liệt kê các nhiệm vụ mà hệ thống cần thực hiện. - Phát triển một bộ từ vựng để mô tả bài toán cũng nhƣ những vấn đề liên quan trong miền quan tâm của bài toán.
- Đƣa ra hƣớng giải quyết bài toán. 47 Nhƣ vậy, pha phân tích chỉ dừng lại ở mức xác định các đặc trƣng mà hệ thống cần phải xây dựng là gì, chỉ ra các khái niệm liên quan và tìm ra hƣớng giải quyết bài toán chứ chƣa quan tâm đến cách thức thực hiện xây dựng hệ thống nhƣ thế nào. Nhƣ cách nói trong ngôn ngữ tiếng Anh, pha phân tích nhằm trả lời cho câu hỏi “what”, còn câu hỏi “how” sẽ đƣợc trả lời trong pha thiết kế. Các bƣớc phân tích hƣớng đối tƣợng Phân tích hƣớng đối tƣợng đƣợc chia làm ba bƣớc tƣơng ứng với ba dạng mô hình UML là: • Mô hình usecase: bƣớc này nhằm xây dựng mô hình chức năng của sản phẩm phần mềm.
Các chức năng này đƣợc nhìn từ quan điểm của những ngƣời sử dụng hệ thống. Kết quả của bƣớc này là một biểu đồ usecase đƣợc phân cấp cùng các scenario tƣơng ứng của từng usecase, trong đó biểu diễn đầy đủ các chức năng của hệ thống và đƣợc khách hàng chấp nhận. • Mô hình lớp: biểu diễn các lớp, các thuộc tính và mối quan hệ giữa các lớp. Từ tập các usecase và scenario, nhóm phát triển hệ thống sẽ phải chỉ ra các lớp, xác định các thuộc tính, các phƣơng thức và các mối quan hệ giữa các lớp.
• Mô hình động: biểu diễn các hoạt động liên quan đến một lớp hay lớp con. Các hoạt động này đƣợc biểu diễn dƣới dạng tƣơng tự nhƣ sơ đồ máy trạng thái hữu hạn và đƣợc gọi là biểu đồ trạng thái. Ngoài biểu đồ trạng thái, trong mô hình động còn có các biểu đồ khác là: biểu đồ tƣơng tác (gồm cả biểu đồ tuần tự, biểu đồ cộng tác) và biểu đồ động. Tuy nhiên, trong pha phân tích, ngƣời phát triển hệ thống chỉ quan tâm đến biểu đồ trạng thái cho mỗi lớp đã xác định đƣợc trong mô hình lớp.
Ví dụ Để minh họa cho các bƣớc phân tích cũng nhƣ trong pha thiết kế ở Chƣơng 4, chúng ta hãy xét một hệ quản lý thư viện đơn giản. Giới hạn của hệ thống này đƣợc thể hiện qua các yêu cầu sau: - Tài liệu trong thƣ viện bao gồm: sách, báo, tạp chí. đƣợc mô tả chung gồm các thuộc tính: tên tài liệu, tác giả, nhà xuất bản, năm xuất bản, số lƣợng hiện có. 48 - Đối với các bạn đọc: thực hiện các thao tác tìm tài liệu, mƣợn, trả tài liệu và xem xét các thông tin về tài liệu mà mình đang mƣợn.
Việc tìm kiếm tài liệu đƣợc thực hiện trực tiếp qua mạng. Tuy nhiên, giao dịch mƣợn và trả sách phải thực hiện trực tiếp tại thƣ viện. - Quá trình mƣợn và trả tài liệu thông qua một thẻ mượn ghi đầy đủ nội dung liên quan đến bạn đọc và tài liệu đƣợc mƣợn; thời gian bắt đầu mƣợn và thời hạn phải trả. - Đối với ngƣời quản lý thƣ viện (thủ thƣ): đƣợc phép cập nhật các thông tin liên quan đến tài liệu và bạn đọc.
Bài toán này sẽ đƣợc sử dụng làm ví dụ trong quá trình thực hiện các bƣớc phân tích và thiết kế hệ thống (Chƣơng 3, 4). MÔ HÌNH USECASE VÀ KỊCH BẢN 1. Vai trò của mô hình usecase Khi bắt đầu xây dựng một sản phẩm phần mềm, nhóm phát triển phải xác định các chức năng mà hệ thống cần phải thực hiện là gì. Biểu đồ usecase đƣợc sử dụng để xác định các chức năng cũng nhƣ các tác nhân (ngƣời sử dụng hay hệ thống khác) liên quan đến hệ thống đó.
Có thể coi một usecase là tập hợp của một loạt các kịch bản (scenario) liên quan đến việc sử dụng hệ thống theo một cách thức nào đó. Mỗi kịch bản (scenario) mô tả một chuỗi các sự kiện mà một ngƣời hay một hệ thống khác kích hoạt vào hệ thống đang phát triển theo tuần tự thời gian. Những thực thể tạo nên các chuỗi sự kiện nhƣ thế đƣợc gọi là các tác nhân (Actor). Một hệ thống sẽ bao gồm nhiều usecase, liên kết với nhau bởi các mối quan hệ nào đó.
Biểu đồ usecase đƣợc phân rã thành các mức tƣơng ứng với các chức năng ở các cấp độ khác nhau, nhìn từ quan điểm ngƣời sử dụng hệ thống. Sự cần thiết phải xây dựng biểu đồ usecase thể hiện qua một số điểm sau: - Usecase là một công cụ tốt để ngƣời dùng tiếp cận và mô tả các chức năng của hệ thống theo quan điểm của mình. Biểu đồ usecase đƣợc biểu diễn trực quan, do đó khách hàng và những ngƣời dùng tiềm năng của hệ thống có thể dễ dàng mô tả đƣợc những ý định thực sự của mình. 49 - Biểu đồ usecase sẽ làm cho khách hàng và ngƣời dùng tiềm năng tham gia cùng nhóm phát triển trong bƣớc khởi đầu của quá trình phân tích thiết kế hệ thống.
Điều này sẽ giúp cho nhóm phát triển và khách hàng có đƣợc sự thống nhất chung về các chức năng thực sự cần thiết của hệ thống. - Biểu đồ usecase là cơ sở cho những bƣớc tiếp theo của quá trình phân tích thiết kế hệ thống phần mềm. Dựa trên biểu đồ usecase và các scenario, ngƣời phát triển hệ thống sẽ chỉ ra các lớp cần thiết cũng nhƣ các thuộc tính của các lớp đó. Các mục tiêu chính cần đạt đƣợc của các usecase là: - Cần chỉ ra và mô tả đƣợc các yêu cầu mang tính 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 (và/hoặc ngƣời sử dụng cuối) và nhóm phát triển phần mềm.
- Đƣa ra 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 trong suốt toàn bộ quá trình phát triển và tạo thành nền tảng cho việc thiết kế các chức năng sau này. - Tạo nên một nền tảng cho các bƣớ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. Trong thực tế thƣờng là để trả lời câu hỏi: Liệu hệ thống cuối cùng có thực hiện những chức năng mà khởi đầu khách hàng đã đề nghị hay không? - Cung cấp khả năng theo dõi quá trình chuyển các yêu cầu về mặt chức năng thành các lớp cụ thể cũng nhƣ các phƣơng thứ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 Usecase.
Khi hệ thống cần thay đổi (thêm bớt các chức năng nào đó), ngƣời phát triển hệ thống chỉ cần bổ sung trong biểu đồ usecase cho phù hợp, sau đó chỉ theo dõi riêng những usecase đã bị thay đổi cùng những ảnh hƣởng của chúng trong thiết kế hệ thống và xây dựng hệ thống. Những công việc cụ thể cần thiết để tạo nên một mô hình Usecase bao gồm: 1. Xác định các tác nhân và các Usecase 2. Xác định các mối quan hệ và phân rã biểu đồ usecase 3.
Biểu diễn các usecase thông qua các kịch bản 4. Kiểm tra và hiệu chỉnh mô hình 50 Nội dung cụ thể thực hiện trong mỗi bƣớc này sẽ đƣợc trình bày cụ thể trong phần sau của tài liệu. Xây dựng biểu đồ usecase Phần này sẽ trình bày quá trình xây dựng biểu đồ usecase theo UML và áp dụng trong bộ công cụ Rational Rose. Bƣớc 1: Tìm các tác nhân và các usecase Để tìm các tác nhân, ngƣời phát triển hệ thống cần trả lời các câu hỏi sau: - Ai (hay hệ thống nào) sẽ là ngƣời sử dụng những chức năng chính của hệ thống? (trả lời câu hỏi này ta sẽ tìm đƣợc các tác nhân chính).
- Ai cần sự hỗ trợ của hệ thống để thực hiện những công việc 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 (tác nhân phụ)? - 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 nào khác? Cần phân biệt hệ thống mà chúng cần phải xây dựng với các hệ thống sẽ tƣơng tác với nó. Nghĩa là, cần xác định rõ biên giới giữa hệ thống yêu cầu xây dựng với hệ thống khác có thể bao gồm các hệ thống máy tính cũng nhƣ các ứng dụng khác trong chính chiếc máy tính mà hệ thống này sẽ hoạt động trong tƣơng lai. - Ai hay cái gì quan tâm đến kết quả mà hệ thống sẽ sản sinh ra? Xem xét bài toán quản lý thƣ viện, các chức năng chính của hệ thống quản lý thƣ viện đƣợc thực hiện bởi thủ thƣ và bạn đọc của thƣ viện đó. Nhƣ vậy, chúng ta có hai tác nhân là thủ thư và bạn đọc, trong đó bạn đọc không phân biệt là sinh viên hay giáo viên.
Từ các tác nhân đã tìm đƣợc ở trên, ngƣời phát triển hệ thống sẽ tìm ra các usecase qua việc xem xét các câu hỏi sau trên mỗi tác nhân: - Tác nhân đó cần chức năng nào từ hệ thống. Hành động chính của tác nhân này là gì? 51 - Tác nhân cần phải xem, cập nhật hay lƣu trữ thông tin gì trong hệ thống? - Tác nhân có cần thông báo cho hệ thống những sự kiện nào đó hay không?