Thiết kế các biểu đồ cộng tác và các lớp đối tượng
Việc tạo lập các biểu đồ cộng tác phụ thuộc vào các kết quả trong pha phân tích: Mô hình khái niệm: từ những mô hình này, người thiết kế có thể chọn để định nghĩa các lớp ứng với từng khái niệm trong hệ thống. Các đối tượng của những lớp này tương ...
Việc tạo lập các biểu đồ cộng tác phụ thuộc vào các kết quả trong pha phân tích:
- Mô hình khái niệm: từ những mô hình này, người thiết kế có thể chọn để định nghĩa các lớp ứng với từng khái niệm trong hệ thống. Các đối tượng của những lớp này tương tác với nhau và được thể hiện trong các biểu đồ tương tác như biểu đồ trình tự, biểu đồ trạng thái.
- Các hợp đồng hoạt động của hệ thống: từ những đặc tả này, người thiết kế xác định được các trách nhiệm và các điều kiện (Pre-condition, Post- condition) trong các biểu đồ tương tác.
- Các ca sử dụng cốt yếu và thực tế: từ những trường hợp này, người thiết kế có thể lượm lặt được những thông tin về những nhiệm vụ mà các biểu đồ tương tác phải thoả mãn.
Những ca sử dụng được xác định trong pha phân tích các yêu cầu thường là ít liên quan đến kỹ thuật cài đặt và cũng chưa có liện hệ nhiều với giao diện sử. Ở đây chúng ta thảo luận thêm về một loại ca sử dụng được gọi là cốt yếu và thực tế.
Một ca sử dụng được gọi là cốt yếu nếu nó mô tả quá trình hoạt động chủ yếu và các động cơ thúc đẩy những hoạt động đó.
Ngược lại, ca sử dụng được gọi là thực tế nếu nó mô tả một quá trình hoạt động thông qua những thiết kế theo thực tế và được uỷ thác để thực hiện theo công nghệ vào/ra đã được xác định trước.
Như vậy, ca sử dụng thực tế là một thiết kế cụ thể về một ca sử dụng, trong đó đã xác định kỹ thuật vào / ra và hỗ trợ cho cài đặt.
Hãy mô tả ca sử dụng thực tế cho ca sử dụng Thanh toán tiền mặt. Như trước đã qui ước, ca sử dụng Thanh toán tiền mặt được mô tả như sau:
Ca sử dụng: Thanh toán tiền mặt (Buy Items with Cash)
Tác nhân: Người mua (khách hàng), người bán hàng
Mục đích: Ghi nhận các thông tin về phiên bán hàng và thu tiền hàng
Mô tả tóm tắt: Sau khi chọn đủ hàng, người mua đưa giỏ hàng (xe hàng) đến quầy trả tiền. Người bán ghi nhận thông tin về các mặt hàng và thu tiền bán hàng bằng tiền mặt. Thanh toán xong, khách hàng có thể đưa hàng ra khỏi cửa hàng.
Kiểu: Thực tế
Tham chiếu: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1.
Trên cơ sở khảo sát bài toán thực tế, người thiết kế có thể xây dựng màn hình (màn hình giao diện) thực hiện nhiệm vụ trên như sau:
Cửa hàng Sao Mai: Bán hàng
Màn hình giao diện của ca sử dụng thực tế “Bán hàng”
Kịch bản mô tả ca sử dụng thực tế trên được viết cụ thể như sau:
| Hoạt động của tác nhân | Hoạt động của hệ thống |
| 1. Ca sử dụng bắt đầu khi khách đưa hàng đến quầy trả tiền. | |
| 2. Với mỗi mặt hàng, người bán nhập vào cửa sổ A mã upc. Nếu số lượng mua nhiều hơn 1 thì nhập số đó vào cửa sổ E. Ấn H (nút Enter Item) sau mỗi lần nhập xong một mặt hàng. | 3. Bổ sung các thông tin của từng mặt hàng vào phiên bán hàng.Mô tả của mặt hàng vừa nhập vàođược hiển thị ở ô F và giá bán ở ô B. |
| 4. Khi nhập xong các mặt hàng thì ấnI (nút End Sale). | 5. Tính toán và hiển thị tổng số tiền phải trả ở ô C. |
| 6. Khách hàng đưa một số tiền để trả tiền mua hàng, người nhập số đó vào ô D và ấn J (nút Make Payment), số đó thường lớn hơn total. | 7. Hệ thống xác định số tiền trả lại cho khách và hiển thị ở ô G. |
| . . . |
Nhiệm vụ chính của người thiết kế là định nghĩa được các lớp để các đối tượng của chúng thực hiện được những nhiệm vụ mà hệ thống yêu cầu. Muốn vậy, chúng ta phải thiết kế được chi tiết các biểu đồ cộng tác mô tả chính xác từng hoạt động của hệ thống và gán nhiệm vụ cho các lớp đối tượng.
Trách nhiệm
Trách nhiệm (Responsibility) được mô tả trong hợp đồng, là nghĩa vụ của từng đối tượng. Hoạt động (hành vi) của các đối tượng liên quan chặt chẽ tới các trách nhiệm của các đối tượng đó.
Nói chung có hai loại trách nhiệm:
1. Các trách nhiệm thực hiện: đó là những hoạt động mà đối tượng thực hiện bao gồm:
- Tự động thực hiện cái gì đó,
- Khởi động một hoạt động hoặc kích hoạt một thao tác của những đối tượng khác,
- Điều khiển hoặc phối hợp các hành động giữa các đối tượng khác nhau,
2. Những trách nhiệm để biết: những hiểu biết về các đối tượng, bao gồm:
- Hiểu biết về dữ liệu riêng được bao gói và bị che giấu,
- Hiểu biết về những đối tượng liên quan,
- Hiểu biết về những sự vật có thể xuất phát hoặc những tính toán nào đó.
Tất cả các thông tin trong hệ thống hướng đối tượng đều được lưu trữ theo cá đối tượng và nó chỉ được xử lý khi các đối tượng đó được ra lệnh thực hiện những nhiệm vụ tương ứng. Để sử dụng được các đối tượng, ngoài các thuộc tính, chúng ta phải biết cách giao tiếp với chúng, nghĩa là phải biết chúng có những hàm thành phần nào. Điều này có thể tìm thấy trong các biểu đồ cộng tác.
Các bước thiết kế biểu đồ cộng tác
Việc tạo ra biểu đồ cộng tác có thể thực hiện như sau:
1. Xác định các trách nhiệm từ các ca sử dụng, mô hình khái niệm (biểu đồ lớp) và các hợp đồng hành động của hệ thống,
2. Gán trách nhiệm cho các đối tượng, quyết định xem đối tượng nào phải thực thi những trách nhiệm trên,
3. Lặp lại hai bước trên cho đến khi gán hết các trách nhiệm trong biểu đồ cộng tác.
Các trách nhiệm của đối tượng sẽ được cài đặt trong lớp của những đối tượng đó bằng các hàm thành phần (phương thức).Trong UML, các trách nhiệm sẽ được gán cho đối tượng khi tạo ra biểu đồ cộng tác và biểu đồ cộng tác thể hiện cả hai khía cạnh, gán trách nhiệm và sự cộng tác giữa các đối tượng trong biểu đồ đó.
Mẫu gán trách nhiệm
Những người thiết kế hướng đối tượng có kinh nghiệm thường sử dụng những nguyên lý chung và những phương pháp giải phù hợp với một ngôn ngữ lập trình, được gọi là mẫu (pattern) hướng dẫn để tạo ra phần mềm. Một cách đơn giản hơn, mẫu là cách gọi một cặp (bài toán / lời giải) có thể áp dụng trong những ngữ cảnh mới, với những lời khuyên làm thế nào để áp dụng được vào tình hình mới.
Sau đây chúng ta sẽ xét năm mẫu gán trách nhiệm cơ bản (GRASP: General Responsibility Assignment Software Patterrn):Expert (Chuyên gia), Creator (Tạo lập mới), Low Coupling (Móc nối yếu), Hight Cohension (Cố kết chặt), và Controller (Điều khiển).
1. Gán trách nhiệm theo chuyên gia (Expert)
Trong hệ thống bán hàng HBH, một số lớp cần phải biết số tiền của mỗi phiên bán hàng và để gán được các trách nhiệm thì phải trả lời:
Ai có trách nhiệm để biết về số tiền của mỗi phiên bán hàng?
Theo ý kiến chuyên gia, để trả lời câu hỏi trên thì phải tìm những lớp chứa những thông tin trên. Đó là: Tất cả các dòng bán hàng của mỗi phiên bán hàng, trong đó cần tính tổng (total) của các mục thành tiền (isubtotal) của từng dòng bán hàng.
Chỉ có phienBanHang (đối tượng phiên bán hàng hiện thời) biết về thông tin này, vì vậy, theo chuyên gia thì gán trách nhiệm cho lớp PhienBanHang.
Chúng ta bắt đầu vẽ biểu đồ cộng tác liên quan đến việc gán trách nhiệm tính tiền bán hàng (total()) cho lớp PhienBanHang.
Phần đầu của biểu đồ cộng tác
Sau khi gán total() cho lớp PhienBanHang thì lại phải biết thêm là ai cung cấp những mục con (số tiền bán từng mặt hàng). Thông tin này được xác định thông qua hàm subtotal(). Vì vậy, :PhienBanHang phải gửi tiếp thông điệp subtotal() cho từng : DongBanHang như hình 3.
Trao đổi giữa các đối tượng để tính được total()
Để biết và tính được subtotal() thì :DongBanHang phải biết thông tin về giá bán được lấy từ đâu. Như hình 6-11 thì subtotal() được xác định từ :DongBanHang và là tích của DongBanHang.soluong * MoTaMatHang.giaBan, do vậy biểu đồ cộng tác của hoạt động tính total() sẽ được xây dựng như hình 4.
Trao đổi giữa các đối tượng để tính được total()
Biểu đồ cộng tác thực hiện việc tính total()
2. Mẫu gán trách nhiệm tạo lập mới (Creator)
Tạo lập các đối tượng khi cần thiết là một trong những hoạt động quan trọng của hệ thống hướng đối tượng. Do đó cần phải có nguyên lý chung để gán trách nhiệm tạo lập đối tượng trong hệ thống.
Phương pháp giải: Gán trách nhiệm cho lớp B để tạo ra đối tượng của lớp A (B là phần tử tạo lập các đối tượng của A) nếu có một trong các điều kiện sau:
- B gồm các đối tượng của A ,
- B chứa các đối tượng của A ,
- B ghi chép các thể hiện của A ,
- B sử dụng trực tiếp các đối tượng của A ,
- B có những dữ liệu ban đầu sẽ được truyền cho các đối tượng của A khi chúng được tạo ra.
Hãy xét một phần của mô hình khái niệm như hình 6
Một phần của biểu đồ lớp
Một :PhienBanHang chứa (thực chất là bao gồm) nhiều đối tượng :DongBanHang, do vậy theo mẫu này thì có thể gán trách nhiệm PhienBanHangđể tạo lập các đối tượng của DongBanHang. Trách nhiệm này được gán khi có yêu cầu cần tạo ra một dòng bán hàng với Nđơn vị, nghĩa là khi :PhienBanHang nhận được thông điệp makeLineItem(N)thì nó sẽ gửi cho :DongBanHang thông điệp create(N)như hình 7.
Tạo ra DongBanHang
3. Mẫu móc nối yếu (Low Coupling)
Độ móc nối là một độ đo về sự kết nối của một lớp để biết về, hoặc phụ thuộc vào các lớp khác như thế nào. Một lớp có độ móc nối yếu thì không phụ thuộc nhiều vào nhiều lớp khác. Ngược lại, một lớp có độ móc nối mạnh thì phụ thuộc vào nhiều lớp khác.
Do đó, khi gán trách nhiệm cho một lớp, hãy cố gắng sao cho độ móc nối giữa các lớp ở mức yếu.
Hãy xét mối quan hệ giữa các lớp ThanhToan,HBHvà PhienBanHang trong hệ thống bán hàng. Giả sử cần phải tạo ra đối tượng :ThanhToan tương ứng với :PhienBanHang và :HBH nhận được yêu cầu thanh toán makePayment(). Bởi vì HBH phải “ ghi nhận” :ThanhToan nên theo mẫu tạo lập mới ở trên thì lớp HBHlà đại biểu để tạo lập. Điều này dẫn đến thiết kế biểu đồ cộng tác như hình 8.
HBH tạo ra :ThanhToan
Với cách gán trách nhiệm như hình 8 thì HBHphải biết về lớp ThanhToan. Nhưng thực tế điều này không đòi hỏi, vì chỉ cần PhienBanHangcần biết về ThanhToanlà đủ. Từ đó chúng ta có thiết kế tốt hơn, thể hiện được mức độ móc nối lỏng hơn như hình 9. Sau đó lại áp dụng các qui tắc khác để gán trách nhiệm cho các đối tượng.
ThanhToan tạo ra đối tượng :ThanhToan
Trong các ngôn ngữ lập trình hướng đối tượng như C++, Java, ClassA với ClassB được móc nối với nhau khi:
- ClassA có những thuộc tính mà đối tượng của ClassB cần tham khảo
- ClassA có những hàm mà đối tượng của ClassB cần sử dụng, hay tham chiếu
- ClassA là lớp con của ClassB.
4. Cố kết cao (Hight Cohension)
Cố kết là độ đovề mức độ liên kết trong lớp, tập trung vào các trách nhiệm được gán cho mỗi lớp. Một lớp có tínhcốkếtcaonếu các nhiệm vụ có liên quan chức năng với nhau. Lớp cố kết là lớp có tối thiểu số các hàm đơn giản và chúng phải có liên hệ chức năng với nhau.
Vấn đề quan trọng trong thiết kế hướng đối tượng là phải gán được trách nhiệm cho các lớp sao cho một mặt phù hợp với thực tế của bài toán, mặt khác đảm bảo có mối liên hệ chặt chẽ về chức năng nhưng không để có những lớp phải làm việc quá tải.
Khi xét mối quan hệ giữa các lớp ThanhToan,HBHvà PhienBanHang trong hệ thống bán hàng ta có thể đưa ra một thiết kế biểu đồ cộng tác .Vì HBH là lớp chính, nên việc để cho lớp HBHđảm nhận vai trò tạo lập create():ThanhToan và thực hiện thêm nhiều công việc khác có thể dẫn đến quá tải. Mặt khác, nhiệm vụ create()không thực sự liên hệ với các nhiệm vụ còn lại, nên có thể gán trách nhiệm này cho lớp PhienBanHangnhư hình 9 thì hợp lý hơn.
Những lớp không cố kết sẽ khó hiểu, khó sử dụng lại và rất khó duy trì hoạt động của hệ thống cho có hiệu quả.
5. Mẫu điều khiển (Controller)
Như trên đã phân tích, những sự kiện vào (input) sẽ tác động và làm cho hệ thống
được kích hoạt. Việc gán trách nhiệm để xử lý các sự kiện vào của hệ thống cho các lớp được thực hiện như sau:
- Gán trách nhiệm cho những lớp đại diện cho cả hệ thống (điều khiển bề mặt),
- Gán trách nhiệm cho những lớp đại diện cho toàn bộ nghiệp vụ hoặc cho cả tổ chức (điều khiển bề mặt),
- Gán trách nhiệm cho những lớp đại diện cho cái gì đó trong thế giới thực mà nó là tích cực và có thể bị lôi kéo theo trong công việc (điều khiển vai trò),
- Gán trách nhiệm cho những lớp đại diện cho bộ phận nhân tạo để xử lý các sự kiện vào ở mỗi ca sử dụng thường được đặt tên “<UseCaseName> Handler” (điều khiển ca sử dụng).
Trong hệ thống bán hàng, chúng ta đã xác định một số thao tác chính như: enterItems() (nhập dữ liệu của mặt hàng), endSale() (kết thúc việc nhập dữ liệu của một phiên bán hàng) và makePayment() (thu tiền, thanh toán), v.v.
Trong pha phân tích, những thao tác này của hệ thống đã được ghi nhận vào lớp HeThong.
Các thao tác của hệ thống được ghi nhận vào lớp có tên là HeThong
Tuy nhiên, điều này không có nghĩa là lớp có tên HeThong phải thực hiện tất cả những nhiệm vụ đó. Trong giai đoạn thiết kế, những thao tác của hệ thống có thể được gán cho lớp điều khiển.
Do vậy, ở pha thiết kế có thể gán trách nhiệm thực hiện các thao tác của hệ thống cho một hay một số lớp điều khiển như gán cho lớp HBH: đại diện cho cả hệ thống.
Gán các thao tác của hệ thống cho lớp điều khiển
