Việc mơ tả hiện thực hố một use case chính là mơ hình hố nội dung hoạt động bên trong của một use case nhằm cung cấp một chức năng hệ thống tới một tác nhân. Việc mơ hình hố này bao gồm: các đối tượng tham gia trong use case và cách thức các đối tượng này hợp tác hoạt động và trao đổi thông điệp với nhau. Chúng ta dùng sơ đồ lớp để mô tả các đối tượng cùng tham dự trong một use case hiện thực hoá và sơ đồ tương tác để biểu diễn sự phối hợp hoạt động và trao đổi thơng điệp giữa các đối tượng này.
Hình 5.44 Mơ tả hiện thực hố use case Sơ đồ lớp cho use case hiện thực hoá
Mỗi use case hiện thực hố có thể có một hoặc nhiều sơ đồ lớp mô tả các lớp tham dự. Một lớp và đối tượng của nó thường tham dự vào một hoặc nhiều use case hiện thực hố. Ví dụ, mơ tả hiện thực hố của use case Truy vấn thông tin tài khoản
Hình 5.45 Sơ đồ lớp cho use case hiện thực hoá Sơ đồ tương tác trong use case hiện thực hố
Sơ đồ tuần tự của hiện thực hố use case Truy vấn thơng tin tài khoản
Mỗi use case hiện thực hố sẽ có một một hoặc nhiều sơ đồ biểu diễn sự tương tác giữa các đối tượng của use case. Trong UML chúng ta diễn đạt sự tương tác này qua hai loại sơ đồ: sơ đồ tuần tự và sơ đồ hợp tác.
Sơ đồ hợp tác của hiện thực hố use case Truy vấn thơng tin tài khoản
Hình 5.47 Truy vấn thơng tin tài khoản
II. Thiết kế gói và hệ thống con 1. Thiết kế gói (package)
Mơ hình thiết kế tổng thể của một hệ thống có thể được hình thành bởi những thành phần nhỏ hơn nhằm giúp cho người tiếp cận dễ hiểu hơn về hệ thống bằng việc gom nhóm các thành phần của hệ thống thành những gói (package) hoặc những hệ thống con (subsystem), sau đó chỉ ra sự liên kết giữa những nhóm này. Thiết kế gói dùng để kết hợp các thành phần thiết kế lại với nhau cho các mục tiêu về tổ chức. Không giống như thiết kế hệ thống con, thiết kế gói khơng đề xuất một giao diện hình thức mà nó cho phép trình bày ra các nội dung của nó (được xem như là public). Thiết kế gói nên được dùng như là một cơng cụ tổ chức mơ hình để
nhóm các thành phần lại với nhau. Nếu chúng thể hiện về các ngữ nghĩa liên quan đến các thành phần thì chúng ta dùng thiết kế hệ thống con. Một cách nào đó, hệ thống con được xem là một loại gói.
Một lớp nằm trong một gói có thể có phạm vi là tồn cục (public) hoặc nội bộ (private). Nếu là tồn cục thì nó có thể có liên kết đến bất kỳ lớp nào kể cả bên ngồi gói đó. Nếu là cục bộ thì nó chỉ có liên kết với các lớp chứa trong lớp đó.
các hệ thống con dựa trên các lý do sau:
- Tạo ra các đơn vị hình thức và chuyển giao khác nhau của hệ thống.
- Khả năng tài nguyên và năng lực của các nhóm phát triển khác nhau yêu cầu phân chia hệ thống thành những nhóm khác nhau phù hợp với tài nguyên và năng lực của nhóm.
- Các hệ thống con có thể được dùng để cấu trúc hóa mơ hình thiết kế nhằm phản ánh tới các loại người dùng. Bởi vì q trình triển khai hệ thống có thể có nhiều thay đổi từ yêu cầu người dùng. Các gói và hệ thống con được thiết kế để đảm bảo rằng các thay đổi yêu cầu của một loại người dùng chỉ ảnh hưởng các phần của hệ thống liên quan đến loại người dùng đó.
Xây dựng gói cho các lớp tầng giao diện
Khi cá lớp tầng giao diện được gom nhóm thành các gói, có hai chiến lược sau đây có thể áp dụng. Việc chọn lựa chiến lược phụ thuộc vào việc đánh giá xem các giao diện của hệ thống thay đổi như thế nào trong tương lai:
- Nếu giao diện của hệ thống sẽ bị thay thế, chịu thay đổi lớn trong tương lai thì giao diện nên được thiết kế tách biệt với các thành phần cịn lại của mơ hình thiết kế. Do đó, khi giao diện có sự thay đổi, chỉ có các gói của giao diện bị ảnh hưởng. Ví dụ, nếu giao diện của hệ thống ATM được xác định là có khả năng thay đổi nhiều trong
tương lai, thì chúng ta có thể tạo các gói cho tầng giao diện như sau:
Hình : gói cho các lớp tầng giao diện
Trong đó, gói “Giao diện giao dịch” gom nhóm tất cả các lớp giao diện liên quan đến cung cấp các chức năng giao dịch của hệ thống với khách hàng. Gói “Giao diện hệ thống” gom nhóm tất cả các giao diện còn lại liên quan đến đãng nhập và quản trị hệ thống. Gói “Nghiệp vụ” gom nhóm các lớp tầng nghiệp vụ của hệ thống.
- Nếu các giao diện được xác định là sẽ khơng có sự thay đổi và sẽ ổn định trong tương lai. Thì một thay đổi tới hệ thống nên được hiểu là một thay đổi bên trong thay vì thay đổi chỉ giao diện. Do đó, các lớp ở tầng giao diện sẽ được gom nhóm chung với các lớp tầng nghiệp vụ thành một gói.
Nếu giao diện của của hệ thống ATM được xác định là ổn định và khơng có thay đổi trong tương lai. Chúng ta có thể phân chia hệ thống thành các gói như sau:
Hình : phân chia hệ thống thành các gói
Theo cách phân chia gói như trên, trong mỗi gói có tất cả các lớp của tầng giao diện lẫn tầng nghiệp vụ và tầng cơ sở dữ liệu.
- Nếu các lớp tầng giao diện mà khơng có liên hệ về mặt chức năng với bất kỳ lớp nào ở tầng nghiệp vụ thì nên gom chung vào một gói với các lớp tầng giao diện khác cùng phụ thuộc vào một giao diện.
Gói “Quản trị” có các lớp khơng có liên quan đến bất kỳ một lớp nghiệp vụ nào, theo tiêu chuẩn này thì chúng ta gom chung lớp MáyATM_GD với các lớp GiaoDịchGD, TàiKhoảnGD vì có sự phụ thuộc. Ví dụ: chúng ta chuyển lớp MáyATM_GD qua gói “Dịch vụ”.
- Nếu một lớp giao diện có liên quan tới một dịch vụ tùy chọn, thì gom nhóm chung các lớp cùng hợp tác với lớp đó vào một gói.
Xây dựng gói cho các lớp liên quan về chức năng
Một nhóm nên gom chung các lớp có quan hệ với nhau về mặt chức năng. Sau đây là một vài tiêu chuẩn được áp dụng khi nhận thấy rằng có hai lớp có liên hệ về mặt chức năng: - Nếu các thay đổi trên hành vi hoặc cấu trúc của một lớp mà có ảnh hưởng đến một lớp khác thì hai lớp này có quan hệ về mặt chức năng.
Hai lớp TàiKhoản và GiaoDịch có quan hệ về mặt chức năng. Bởi vì nếu chúng ta thay đổi nội dung của một method của lớp GiaoDịch (ví dụ: hành vi gánThơngTinGiaoDịch()) thì phải cập nhật lại lớp TàiKhoản.
- Nếu chúng ta tìm thấy rằng một lớp có quan hệ chức năng với một lớp khác bằng cách bắt đầu bởi một lớp chúng ta kiểm tra sự ảnh hưởng của nó bằng việc xố nó khỏi hệ thống. Nếu bất kỳ lớp nào còn lại được xác định là dư thừa (không tham gia vào hoạt động của hệ thống) thì chúng ta nói rằng các lớp này có quan hệ phụ thuộc vào lớp bị xoá. - Hai lớp có quan hệ chức năng với nhau nếu cùng tương tác với cùng tác nhân. Nếu hai lớp khơng liên quan đến cùng tác nhân, thì chúng khơng cùng nằm trong một gói.
- Hai lớp có quan hệ chức năng với nhau nếu giữa chúng có các mối kết hợp (association, aggregation, …).
Hai tiêu chuẩn không cho phép hai lớp thuộc cùng một gói:
- Hai lớp liên quan đến các tác nhân khác nhau thì khơng nên cùng thuộc một gói - Lớp bắt buộc và lớp tùy chọn khơng nên thuộc cùng một gói
Kết hợp với các tieu chuẩn phân chia gói cho các lớp tầng giao diện các lớp liên quan về chức, có những giải pháp phân chia hệ thống ATM thành các gói như sau:
Giải pháp 1: tách biệt giữa các tầng, một gói chỉ chứa các lớp thuộc một tầng.
Hình : tách biệt giữa các tầng, một gói chỉ chứa các lớp thuộc một tầng.
Hình :trộn lẫn giữa các tầng, đặc biệt là tầng giao diện và tầng nghiệp vụ Mơ tả sự phụ thuộc giữa các gói
Nếu một lớp trong một gói có mối kết hợp với một lớp trong một gói khác thì những gói này có sự phụ thuộc lẫn nhau. Sự phụ thuộc giữa các gói được mơ hình hố dùng mối kết hợp phụ thuộc (dependency). Mối kế hợp này giúp chúng ta đánh giá hệ quả của sự thay đổi: một gói có các gói khác phụ thuộc vào thì sẽ khó thay đổi hơn một gói khơng có gói khác phụ thuộc.
Hình : sự phụ thuộc giữa các gói
Đối với giải pháp 2
Hình : sự phụ thuộc giữa các gói
Với giải pháp 1, dễ thấy rằng các lớp giao diện của dịch vụ sẽ phụ thuộc vào các lớp tương ứng tầng nghiệp vụ.
Với giải pháp 2, gói “Đãng nhập” có quan hệ phụ thuộc tới gói “Dịch vụ” vì lớp KháchHàng có quan hệ với lớp TàiKhoản và lớp KháchHàngGD phụ thuộc vào lớp MáyATM_GD; tất cả các gói “Đãng nhập” và “Dịchvụ” đều phụ thuộc tới gói “CSDL” vì lớp KháchHàng và lớp TàiKhoản có quan hệ và tham chiếu đến lớp NgânHàngDB.
Đánh giá sự liên kết giữa các gói
Liên kết giữa các gói có thể là tốt và khơng tốt; tốt, bởi vì phản ánh việc tái sử dụng; khơng tốt, bởi vì phản ánh sự phụ thuộc làm cho hệ thống khó để thay đổi, tiến hoá và bảo tŕ. Một vài nguyên lý đánh giá như sau:
- Hai gói khơng nên có quan hệ phụ thuộc qua lại
Hình : sự quan hệ phụ thuộc giữa các gói
Hình biểu diễn ớ mức thấp khơng nên phụ thuộc vào các gói ở mức cao hơn
- Các phụ thuộc của các gói khơng nên nhảy mức
Hình :phụ thuộc của các gói khơng nên nhảy mức
- Một gói khơng nên phụ thuộc vào một hệ thống con mà chi nên phụ thuộc vào một gói khác hoặc một giao diện.