Với SAD tổng quan, hệ thống lớn đƣợc thiết kế thành các hệ thống nhỏ. Khi đó thành phần là các SS. Từ SAD tổng quan rất khó có thể đi tới thiết kế SDD, mà phải tiếp tục cần thiết kế SAD cho các SS đó. Câu hỏi đặt ra là vậy khi nào sẽ dừng lại? Từ thực tế cho thấy khi các thành phần sẽ tƣơng ứng với các dự án hoặc gói thì có thể dừng lại để thiết kế SDD. Trong SAD có các thành phần chính là: thành phần, kết nối, giao diện, cấu hình. Còn trong SDD thì quan tâm tới các thành phần chính là: lớp (class), phƣơng thức (method), giao diện, biểu đồ lớp (class diagram), biểu đồ trình tự (sequence diagram), biểu đồ họat động (activity diagram). Khi có tài liệu SAD thì quá trình làm SDD sẽ trở lên dễ dàng hơn rất nhiều. Sẽ có một quá trình ánh xạ từ các thành phần trong SAD vào các thành phần trong SDD.
Bảng 5.1: Ánh xạ các thành phần trong SAD với SDD
STT SAD SDD Ánh xạ
1 Component Project,
Package, Class
Từ một thành phần thƣờng ánh xạ sang một hoặc nhiều dự án hoặc gói. Mỗi dự án đảm nhiệm những chức năng chuyên biệt chung nào đó.Trong mỗi dự án đó sẽ chứa một hoặc nhiều lớp. Ví dụ dự án đảm nhiệm công việc thao tác với các file dữ
liệu khác nhau nhƣ: *.txt file, *.xml file… Khi đó dự án này sẽ đƣợc thiết kế sao cho việc đọc, ghi dữ liệu vào các loại file một cách dễ dàng, tiện lợi nhất.
Khi biết đƣợc chức năng chung của dự án đó, ta sẽ thiết kế các lớp trong đó sao cho hợp lý, hiệu quả. Ta có thể dựa vào một số nguyên lý thiết kế trong hƣớng đối tƣợng để thiết kế các lớp này nhƣ sau [1]:
o Nguyên lý đóng mở (The Open
Close Principle): Một module cần “mở” đối với việc phát triển thêm tính năng nhƣng phải “đóng” (hạn chế hoặc không cho phép) đối với việc sửa đổi mã nguồn. Ý nghĩa của nguyên lý này là: Chúng ta có thể thêm hoặc mở rộng tính năng của một lớp mà không cần quan tâm đến những thay đổi bên trong bản thân lớp. Tất cả các kỹ thuật này đều chủ yếu dựa vào sự trừu tƣợng hóa (abstraction) trong lập trình hƣớng đối tƣợng. Khi áp dụng nguyên lý này sẽ giảm thiểu đƣợc việc phải thay đổi các đoạn mã nguồn có sẵn khi thêm các tính năng mới vào phần mềm. Nhờ đó hệ thống không bị phá vỡ.
o Nguyên lý thay thế Liskov (The
Liskov Substitution Principle): Các lớp cơ sở đều có thể thay thế đƣợc bằng các lớp con (lớp kế thừa). Ý nghĩa của nguyên lý trên là các chức năng của hệ thống vẫn thực hiện đúng đắn nếu ta thay bất kì một lớp đối tƣợng nào bằng đối tƣợng kế thừa.
o Nguyên lý nghịch đảo phụ (The
thuộc vào mức trừu tƣợng. Không phụ thuộc vào mức chi tiết. Nguyên lý này phát biểu rằng, các module không nên phụ thuộc vào cài đặt mà chỉ nên phụ thuộc vào sự trừu tƣợng của các lớp đối tƣợng. Hay nói cách khác, chúng ta không nên để các lớp chi tiết phụ thuộc nhau mà để sự phụ thuộc đó xảy ra tại lớp trừu tƣợng.
o Nguyên lý ISP (The Interface
Segregation Principle): Nên có nhiều giao diện đặc thù với bên ngoài hơn là chỉ có một giao diện dùng chung cho một mục đích. Nguyên lý này phát biểu rằng, thay vì chúng ta dồn hết các chức năng vào trong lớp đối tƣợng đó thì chúng ta sẽ phân loại các chức năng ứng với nhu cầu của từng client.
2 Connector Lời gọi
hàm, cách trao đổi thông điệp giữa các đối tƣợng
Cầu nối giữa các dự án. Khi các dự án đƣợc chia nhỏ thành các lớp thì kết nối sẽ thể hiện giao tiếp làm việc giữa các lớp này. Mỗi loại kết nối khác nhau sẽ thể hiện lời gọi hàm, cách trao đổi thông điệp giữa các đối tƣợng là khác nhau. Việc này sẽ thể hiện vào sơ đồ lớp và sơ đồ tuần tự trong SDD.
3 Interface Interface,
method
Giao diện trong SAD thể hiện mức tổng quát việc gửi nhận thông điệp, tƣơng tác giữa các thành phần ra sao. Mỗi kiểu kiến trúc sẽ giao diện khác nhau. Còn trong SDD thì phải mô tả rõ chi tiết ý nghĩa của từng tham số, đầu vào, đầu ra của các giao diện, phƣơng thức này. Từ một giao diện trong SAD có thể sẽ phải chia nhỏ ra thành nhiều giao diện, phƣơng thức trong SDD để phù hợp với thiết kế. Ví dụ với kiểu
kiến trúc là Message-bus thì giao diện chỉ nói chung chung đầu vào là thông điệp dƣới định dạng là xml, còn đầu ra là mã lỗi. Nhƣng vào SDD thì phải xác định rõ ràng cấu trúc của xml gồm những phần tử nào, ý nghĩa của từng phần tử đó ra sao. Mã lỗi trả về phải có xác định rõ ràng ý nghĩa của lỗi ứng với giá trị của mã lỗi. Khi đó có thể ta phải xây dựng một phƣơng thức để đọc, phân tích xml, lấy ra giá trị cần thiết. Khi đó phƣơng thức này cũng phải xác định rõ ràng đầu vào là gì, đầu ra là gì. 4 Configurati on Đối tƣợng tham gia vào quá trình tƣơng tác, xử lý. Logic xử lý trong biểu đồ trình tự. Các thành phần tham gia trong sơ đồ lớp
Cấu hình trong SAD thể hiện sự tƣơng tác, phục thuộc giữa các thành phần. Trong SDD phải làm chi tiết sự phụ thuộc này. Điều này sẽ thể hiện số lƣợng các dự án, lớp trong sơ đồ lớp và logic xử lý trong biểu đồ tuần tự. Ví dụ dữ liệu của hệ thống đƣợc lƣu trữ ở các loại CSDL khác nhau nhƣ SQL Server, Access, hoặc ở dƣới dạng các file xml. Tùy thuộc vào cấu hình của ngƣời dùng mà hệ thống sẽ phải lấy dữ liệu từ một trong các nơi đó. Khi đó sẽ xuất hiện thêm các lớp, phƣơng thức để xử lý chuyên biệt với từng loại dữ liệu đó. Đồng thời khi xử lý phải mô tả rõ khi nào thì dùng loại dữ liệu nào (có thể quy định dựa vào giá trị nào đó), và sẽ phải gọi tới phƣơng thức nào đó cho phù hợp.