Skip to the content
Khung nhìn mô-đun
- Mục đích chính:
- Tiếp cận gần hơn với việc triển khai hệ thống trong phần mềm
- Khung nhìn khái niệm
- Các mối quan hệ chức năng rõ ràng
- Khung nhìn mô-đun
- Ánh xạ chức năng đến các mô-đun (triển khai) là rõ ràng
- Mối quan hệ giữa các phần tử triển khai rõ ràng
- Cách hệ thống sử dụng nền tảng SW (ví dụ: OS)
- Không chỉ là sự tinh chỉnh của khung nhìn khái niệm: còn là sự phân vùng lại
Khung nhìn khái niệm và mô-đun
- Khung nhìn khái niệm
- Chức năng nằm trong các thành phần
- Tương tác thông qua các kết nối
- Chức năng điều khiển tinh vi
- Khung nhìn mô-đun
- Chức năng + điều khiển thành các mô-đun
- Mô-đun yêu cầu và cung cấp giao diện
- Không thực thi
- Không cấu hình
- Đi kèm trong khung nhìn thực thi
Nhiệm vụ thiết kế
- Phân tích toàn cục , thiết kế trung tâm, thiết kế giao diện
- Thiết kế trung tâm sử dụng
- Thẻ vấn đề từ phân tích toàn cục
- Các thành phần, kết nối, cấu hình từ khung nhìn khái niệm
- Thiết kế trung tâm sản xuất
- Mô-đun, hệ thống con, lớp (layers)
- Chúng sẽ được sử dụng trong thiết kế giao diện, cộng với các nhiệm vụ thiết kế trung tâm của các khung nhìn thực thi và mã
- Phản hồi
Nhiệm vụ thiết kế
Phân tích toàn cục
- Các yếu tố cụ thể
- Tổ chức: kỹ năng nhân viên, quy trình và môi trường phát triển, ngân sách phát triển
- Công nghệ: phần cứng đa năng, công nghệ phần mềm, tiêu chuẩn
- Các chiến lược cụ thể
- Liên quan đến khả năng sửa đổi, tính di động, tái sử dụng
- Cũng liên quan đến hiệu suất, độ tin cậy, phát hiện lỗi, báo cáo, phục hồi
Nhiệm vụ thiết kế trung tâm
- Việc cần làm
- Ánh xạ các phần tử khái niệm vào các hệ thống con và mô-đun
- Tạo các lớp
- Gán các mô-đun cho các lớp
- Hướng dẫn
- Các chiến lược từ phân tích toàn cục
- Kinh nghiệm với các sản phẩm trước đây
- Kinh nghiệm kỹ thuật SW chung
Mô-đun
- Ánh xạ các phần tử khái niệm với hệ thống con và mô-đun
- Hệ thống con
- Thành phần khái niệm cấp cao hơn (chứa các thành phần và trình kết nối khác)
- Có thể chứa các hệ thống con và mô-đun khác
- Mô-đun
- Tương ứng với một hoặc nhiều phần tử khái niệm
- Có thể được phân tách thành các mô-đun khác
- Mô-đun cha chỉ là một thùng chứa; chỉ các mô-đun lá tương ứng với mã
biểu đồ mô-đun
Siêu mô hình hệ thống con và mô-đun
- Mô-đun
- Đóng gói dữ liệu và hoạt động để cung cấp một dịch vụ
- Các dịch vụ được cung cấp (provided services) được xác định bởi các giao diện được cung cấp (provided interfaces)
- Các dịch vụ bắt buộc (required services) được xác định bởi các giao diện được yêu cầu (required interfaces)
- Sử dụng phụ thuộc
- Các quan hệ yêu cầu và cung cấp
Xác định các mô-đun
- Các phần tử khái niệm được ánh xạ tới các mô-đun
- Các mô-đun
- Nhận trách nhiệm
- Phân rã
- Sử dụng phụ thuộc
- Sau khi ánh xạ ban đầu
- Tinh chỉnh và chia nhỏ các mô-đun (để phát triển độc lập)
- Kết hợp các mô-đun (để hiệu quả)
Xác định các mô-đun, 2
- Thêm mô-đun (hỗ trợ) mới
- Không có đối tác trong khung nhìn khái niệm
- Do các yếu tố không ghìm chặt vào thành phần cụ thể
- Phục hồi, phát hiện hư hỏng
- Do các dịch vụ cần thiết bởi các mô-đun hiện có nhưng không được cung cấp bởi nền tảng SW
- Phân rã cho đến khi hiểu rõ
- trách nhiệm của mô-đun
- Rủi ro về triển khai và tích hợp
Xác định các mô-đun, 3
- Mô-đun chứa
- Các mô-đun chứa được kết hợp chặt chẽ hơn các mô-đun chứa trong một hệ thống con
- Được chỉ định như vậy (mô-đun thùng chứa) cho một nhóm / người phát triển
- Các mô-đun lá
Các lớp
- Tổ chức các mô-đun thành một hệ thống phân cấp có thứ tự từng phần (partially ordered hierarchy)
- Mô-đun trong một lớp
- Có thể sử dụng bất kỳ mô-đun nào khác trong lớp đó
- Có thể sử dụng các mô-đun trong các lớp khác
- Các giao diện được yêu cầu và cung cấp của các mô-đun đó cũng được yêu cầu và cung cấp bởi lớp
- Được sử dụng để hạn chế sự phụ thuộc sử dụng
- Có thể chứa các lớp con
- Cấu trúc bổ sung bên trong lớp
biểu đồ các lớp
Sử dụng các lớp
- Giảm độ phức tạp
- Đóng gói các thành phần bên ngoài
- Tách các dịch vụ hệ thống khỏi SW giao diện người dùng
- Hỗ trợ tái sử dụng
- Gán các dịch vụ chung cho một lớp dịch vụ ứng dụng
- Cung cấp tính độc lập về thiết kế
- Thay đổi trong HĐH không ảnh hưởng đến toàn bộ hệ thống
Mô-đun hay lớp đầu tiên?
- Bắt đầu xác định các lớp khi xác định các mô-đun
- Từ dưới lên
- Các lớp và sự phụ thuộc giữa chúng phát triển từ trách nhiệm của mô-đun và các phụ thuộc của chúng
- Từ trên xuống
- Bắt đầu với tập hợp các lớp (trải nghiệm với các dự án khác trong miền)
- Khi được xác định, các mô-đun được gán cho các lớp
- Các lớp là hướng dẫn để xác định các mô-đun
- Điển hình: sự kết hợp
- Kiến trúc sư có ý tưởng phân chia lớp rộng
- Ứng dụng, giao diện người dùng, các dịch vụ hệ thống
- Khi các mô-đun được xác định, chúng tinh chỉnh mô hình lớp
- Thêm các lớp bổ sung cho chức năng của miền cụ thể (domain-specific functionality)
- Tạo các lớp con khi lớp quá phức tạp
Đánh giá toàn cục
- Nhiều nguồn hướng dẫn cho nhiệm vụ thiết kế trung tâm
- Thiết kế khung nhìn khái niệm
- Chiến lược phân tích toàn cục
- Kinh nghiệm SA
- Kiến thức chung về kỹ thuật SA và SW
- Nguồn thông tin nào vào thời điểm nào
Đánh giá toàn cục, 2
- Khía cạnh thứ hai của GE
- Tìm kiếm phản hồi cho các nhiệm vụ và quyết định được đưa ra trước đó trong thiết kế
- Tìm kiếm các yếu tố, vấn đề, chiến lược bổ sung để cung cấp lại cho phân tích toàn cục
- Bất kỳ quyết định nào về các mô-đun và các lớp sẽ thay đổi một số điều trong thiết kế khung nhìn khái niệm
Đánh giá toàn cục, 3
- Khía cạnh thứ ba
- Đánh giá các quyết định về khung nhìn mô-đun đối với nhau
- Điều chỉnh các mô-đun và hệ thống con dựa trên các quyết định về lớp và ngược lại
- Xác định giao diện mới
- Sửa đổi giao diện
Nhiệm vụ thiết kế cuối cùng: thiết kế giao diện
- Mô tả các giao diện cho từng mô-đun và lớp đã xác định
- Thực hiện sau khi hoàn thành nhiệm vụ thiết kế trung tâm
- Có thể cần
- Xác định giao diện mới
- Tách / kết hợp các giao diện
- Phản hồi cho nhiệm vụ thiết kế trung tâm
Giao diện ví dụ
