Khung Nhìn Và Tài Liệu Kiến Trúc (Hofmeister Và Những Người Khác) 3: Khung Nhìn Kiến Trúc Mô-Đun

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ế

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

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á
    • Vẫn còn trừu tượng!

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

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
      • COTS SW, HW
    • 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
    • Thiết kế chi tiết
  • 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ụ

Giao diện ví dụ.

Leave a comment

Your email address will not be published. Required fields are marked *