Mỗi loại biểu đồ có điểm mạnh và điểm yếu, biểu đồ cộng tác có thể vẽ trên diện tích có chiều ngang hẹp, còn biểu đồ tuần tự thì diễn đạt tốt hơn tuần tự các thông điệp
5.2.6 GRASP: Thiết kế các đối tượng cùng các Trách nhiệm
Sau khi xác định yêu cầu và tạo ra mô hình nghiệp vụ, việc thêm các phƣơng thức vào các lớp phần mềm và định nghĩa các thông điệp để đáp ứng các yêu cầu là một cách để mô tả quá trình thiết kế đối tƣợng
GRASP đƣợc biểu diễn nhƣ là các hình mẫu dùng để mô tả các nguyên lý căn bản về thiết kế đối tƣợng và gán trách nhiệm cho đối tƣợng.
UML định nghĩa “Trách nhiệm” nhƣ là một hợp đồng, một bắt buộc đối với một phân lớp, về cơ bản các “Trách nhiệm” này đƣợc chia làm hai loại sau:
- Trách nhiệm biết - Trách nhiệm làm
Trách nhiệm làm của một đối tƣợng bao gồm:
- Tự làm gì đó, chẳng hạn tạo ra một đối tƣợng, hoặc thực hiện một tính toán - Khởi tạo hành động trong các đối tƣợng khác
- Điều khiển và phối hợp hành động trong các đối tƣợng khác Trách nhiệm biết của một đối tƣợng bao gồm:
- Biết dữ liệu đóng gói riêng - Biết các đối tƣợng liên quan
- Biết những điều mà nó có thể thừa kế hoặc tính toán
Trách nhiệm đƣợc gán cho các lớp của đối tƣợng trong khi thiết kế đối tƣợng Năm hình mẫu đầu tiên của GRASP là:
- Information Expert (Chuyên gia thông tin): Gán trách nhiệm cho lớp mà có chứa thông tin cần thiết để đáp ứng trách nhiệm.
- Creator (Ngƣời tạo): Gán trách nhiệm cho lớp B tạo ra thực thể của lớp A khi một trong các điều kiện sau đây là đúng:
o B tập hợp các đối tƣợng của A o B chứa các đối tƣợng của A o B ghi nhớ các thực thể của A o B sử dụng gần các đối tƣợng A
o B có dữ liệu khởi tạo mà sẽ đƣợc truyền cho A khi A đƣợc tạo ra
- High Cohesion (Cố kết cao): Gán trách nhiệm sao cho sự cố kết duy trì ở mức cao
- Low Coupling (Móc nối thấp): Gán trách nhiệm sao cho sự móc nối duy trì ở mức thấp
- Controller (Bộ điều khiển): Gán trách nhiệm nhận và xử lý các thông điệp sự kiện hệ thống cho lớp mà đại diện cho một trong các lựa chọn sau:
o Biểu diễn tổng thể hệ thống, thiết bị, hoặc thiết bị con
o Biểu diễn một ngữ cảnh Use Case trong đó sự kiện hệ thống xảy ra
5.2.7 Mô hình Thiết kế: Hiện thực hóa Use Case với các khuôn mẫu GRASP
Hiện thực hóa Use Case mô tả một Use Case sẽ đƣợc hiện thực nhƣ thế nào trong mô hình thiết kế. Chính xác hơn, một ngƣời thiết kế có thể mô tả thiết kế của một hay nhiều tình huống của Use Case, mỗi công việc này gọi là hiện thực hóa Use Case. Hiện thực hóa Use Case là một thuật ngữ của RUP, hay một khái niệm đƣợc sử dụng để nhắc chúng ta về mối liên kết giữa những yêu cầu đƣợc thể hiện bởi các Use Case và các thiết kế đối tƣợng thỏa mãn những yêu cầu đó.
Các biểu đồ tƣơng tác của UML là ngôn ngữ chung để minh họa việc hiện thực hóa Use Case. Và có các nguyên lý, hình mẫu của thiết kế đối tƣợng, nhƣ là “Chuyên gia Thông tin”, “Móc nối thấp”, có thể áp dụng cho quá trình thiết kế này