Thiết Kế Kiến Trúc 2: Phương Pháp Attribute-Driven Design (ADD)

Phương pháp Attribute-Driven Design (ADD)

• Phương pháp thiết kế kiến trúc để đáp ứng cả yêu cầu về chức năng và chất lượng
• Xác định SA bằng cách phân tách dựa trên các thuộc tính chất lượng
• Quá trình phân rã đệ quy; ở mỗi giai đoạn
  • Chiến thuật được chọn để đáp ứng một số phẩm chất
  • Chức năng được thêm vào để khởi tạo các loại mô-đun được cung cấp bởi chiến thuật
• Đầu vào: tập hợp các kịch bản chất lượng cho trình điều khiển
  • Trình điều khiển chính có thể thay đổi trong quá trình thiết kế, do
    • Hiểu rõ hơn hoặc thay đổi các yêu cầu

Đầu ra ADD

• Một số cấp độ đầu tiên của khung nhìn phân rã mô-đun của một kiến trúc
• Không phải tất cả các chi tiết của khung nhìn đều là do áp dụng ADD
  • Nhất thiết phải được chế tạo thô
• Hệ thống được mô tả là
  • một tập hợp các vùng chứa (containers) cho chức năng
  • tương tác giữa các vùng chứa
• Rất quan trọng để đạt được những phẩm chất mong muốn
• Cung cấp khuôn khổ để đạt được chức năng
• Sự khác biệt giữa đầu ra ADD và một kiến trúc đã sẵn sàng để triển khai
  • Quyết định thiết kế chi tiết bị hoãn lại
  • Uyển chuyển

Nghiên cứu điển hình

• Dụng cụ mở cửa nhà để xe
  • Chịu trách nhiệm nâng và hạ cửa nhà để xe, thông qua
    • Công tắc
    • Điều khiển từ xa
    • Hệ thống thông tin nhà
  • Có thể chẩn đoán sự cố của thiết bị mở từ hệ thống thông tin gia đình (HIF)
• Kiến trúc dòng sản phẩm! (PLA)

Đầu vào mẫu

• ADD giả định các yêu cầu chức năng và các ràng buộc làm đầu vào
• ADD cũng cần các yêu cầu về chất lượng
  • Tập hợp các tình huống chất lượng dành riêng cho hệ thống
  • Những điều này cung cấp một danh sách kiểm tra được sử dụng để phát triển các kịch bản dành riêng cho hệ thống
  • Chỉ những chi tiết cần thiết

Nghiên cứu điển hình: các kịch bản chất lượng

• Thiết bị và điều khiển đóng mở cửa khác nhau đối với các sản phẩm khác nhau trong dòng sản phẩm
  • Có thể bao gồm các điều khiển từ bên trong HIF
  • Kiến trúc sản phẩm cho một tập hợp các điều khiển cụ thể phải được lấy trực tiếp từ PLA
• Bộ xử lý được sử dụng trong các sản phẩm khác nhau sẽ khác nhau
  • Kiến trúc sản phẩm cho từng bộ xử lý cụ thể phải được lấy trực tiếp từ PLA

Nghiên cứu điển hình: các kịch bản chất lượng 2

• Nếu chướng ngại vật (người / đồ vật) được phát hiện bằng cửa nhà để xe trong quá trình đi xuống, nó phải dừng lại hoặc mở lại trong vòng 0,1 giây
• Có thể truy cập thiết bị mở cửa nhà để xe để chẩn đoán và quản lý từ bên trong HMI
  • Sử dụng giao thức chẩn đoán sản phẩm cụ thể
  • Có thể tạo ra trực tiếp một kiến trúc phản ánh giao thức này

Các bước ADD

• Chọn mô-đun (ban đầu là toàn bộ hệ thống) để phân rã
  • Đầu vào bắt buộc có sẵn cho mô-đun đó
• Tinh chỉnh mô-đun theo các bước sau
  • Chọn trình điều khiển kiến trúc
  • Chọn chiến thuật / kiểu kiến trúc thỏa mãn các trình điều khiển
  • Khởi tạo mô-đun và phân bổ chức năng
  • Xác định giao diện của các mô-đun con
  • Xác minh và tinh chỉnh các trường hợp sử dụng và kịch bản chất lượng và đặt chúng trở thành các ràng buộc đối với các mô-đun con
• Lặp lại các bước ở trên cho mọi mô-đun cần phân rã thêm

Chọn mô-đun để phân rã

• Mô-đun: hệ thống, hệ thống con, mô-đun con
• Nghiên cứu điển hình:
  • Hệ thống mở cửa nhà để xe là hệ thống
  • Một hạn chế: trình mở phải tương tác với hệ thống thông tin gia đình (HIS)

Chọn trình điều khiển kiến trúc

• Trình điều khiển kiến trúc: các yêu cầu về chức năng và chất lượng định hình nên kiến trúc
  • Trong số các yêu cầu ưu tiên hàng đầu cho mô-đun
  • Được giải quyết trong quá trình phân rã ban đầu của hệ thống
• Nghiên cứu điển hình:
  • Hiệu suất thời gian thực
  • Khả năng sửa đổi để hỗ trợ các dòng sản phẩm
  • Hỗ trợ chẩn đoán trực tuyến

Thông tin thêm về trình điều khiển kiến trúc

• Việc xác định các trình điều khiển này không chỉ nằm trong giai đoạn đầu của quá trình
  • Exp: chúng ta cần xem một ví dụ về cửa nhà để xe để biết rằng chúng ta muốn nó dừng lại sau 0,1 giây
• Các yêu cầu ít quan trọng hơn được thỏa mãn trong các ràng buộc của các yêu cầu quan trọng nhất
  • Chúng ta phân rã dựa trên trình điều khiển

Chọn kiểu kiến trúc

• Đối với mỗi thuộc tính chất lượng có
  • Các chiến thuật và kiểu có thể xác định để hiện thực chúng
  • Mỗi chiến thuật được thiết kế để thực hiện một / nhiều thuộc tính
  • Kiểu mà các chiến thuật được nhúng vào có tác động đến các thuộc tính khác
  • Cân bằng giữa các phẩm chất cần thiết
    • Khi hợp phần của các chiến thuật được sử dụng
• Chúng ta cần xác định các mô-đun con cần thiết để hiện thực các chiến thuật

Chọn kiểu kiến trúc 2

• Mục tiêu của bước này
  • Thiết lập kiểu tổng thể bao gồm các loại mô-đun
  • Kiểu sẽ đáp ứng các trình điều khiển
  • Được xây dựng bằng cách hợp thành các chiến thuật đã chọn
  • Lựa chọn được hướng dẫn bởi
    • Trình điều khiển
    • Tác dụng phụ của chiến thuật đối với các phẩm chất khác

Chọn kiểu kiến trúc: ví dụ 1

• Khả năng sửa đổi tại thời điểm thiết kế
  • Chiến thuật “bản địa hóa các thay đổi”: tính nhất quán ngữ nghĩa và che giấu thông tin
    • Tách các trách nhiệm liên quan đến giao diện người dùng, giao tiếp, cảm biến, chẩn đoán
    • 3 máy ảo đầu tiên: chúng sẽ khác nhau đối với các sản phẩm khác nhau có nguồn gốc từ PLA

Chọn kiểu kiến trúc: ví dụ 2

• Hiệu suất
  • Chiến thuật “nhu cầu tài nguyên” và “phân xử tài nguyên”: tăng hiệu quả tính toán và chọn chính sách lập lịch trình
    • Các tính toán quan trọng về hiệu suất được thực hiện hiệu quả
    • Các tính toán quan trọng về hiệu suất được lên lịch để đạt được thời hạn

Khởi tạo mô-đun

• Bước trước
  • Chúng ta đã xác định các loại mô-đun của bước phân rã
• Bây giờ
  • Chúng ta khởi tạo chúng
• Máy ảo quản lý giao tiếp và tương tác cảm biến
  • Phần mềm chạy trên máy ảo: một ứng dụng
  • Một mô-đun cho mỗi nhóm chức năng – thể hiện của các loại mô-đun
• Ví dụ của chúng ta
  • Trách nhiệm quản lý việc phát hiện chướng ngại vật và dừng cửa → phần quan trọng về hiệu suất
    • Chức năng này có thời hạn
  • Quản lý nâng / hạ cửa bình thường
    • Không có thời hạn => phần không quan trọng về hiệu suất
    • Tương tự với chẩn đoán
  • Một số trách nhiệm đối với VM => 2 phiên bản VM

Phân bổ chức năng

• Trường hợp sử dụng cho mô-đun mẹ => hiểu phân bổ chức năng
• Thêm / xóa các mô-đun con để đáp ứng các chức năng cần thiết
• Mọi trường hợp sử dụng của mô-đun mẹ: có thể biểu diễn bằng một chuỗi các trách nhiệm trong các mô-đun con
• Khám phá ra trao đổi thông tin cần thiết
  • Quan trọng bây giờ : thông tin và vai trò của mô-đun sản xuất / mô-đun tiêu dùng
  • Bây giờ không quan trọng : thông tin được trao đổi như thế nào
    • Đẩy / kéo
    • Dưới dạng thông điệp hoặc dưới dạng tham số cuộc gọi

Khởi tạo mô-đun và phân bổ chức năng 2

• Đại diện cho kiến trúc với các khung nhìn
  • Thông tin động và triển khai cần thiết để phân tích việc đạt được các phẩm chất
  • Chúng ta cần các khung nhìn bổ sung
    • Khung nhìn phân rã mô-đun
    • Khung nhìn đồng thời
    • Khung nhìn triển khai

Khung nhìn đồng thời

• Mô hình các khía cạnh động
  • Hoạt động song song
  • Đồng bộ hóa
• Xác định
  • Vấn đề tranh chấp tài nguyên
  • Các tình huống bế tắc có thể xảy ra
  • Các vấn đề về tính nhất quán của dữ liệu
• Dẫn đến việc khám phá ra các trách nhiệm mới trong các mô-đun và có thể là các mô-đun mới
  • Được ghi lại trong khung nhìn phân rã mô-đun
  • Ví dụ mô-đun mới: trình quản lý tài nguyên

Khung nhìn đồng thời 2

• Khung nhìn thành phần và kết nối
• Thành phần: các thể hiện của mô-đun
• Kết nối: mang các luồng ảo (virtual threads)
  • Luồng ảo: đường dẫn thực thi thông qua hệ thống hoặc các phần của nó
  • Luồng ảo so với các luồng của hệ điều hành
  • Đồng bộ hóa với (Synchronizes with)
  • Bắt đầu (Starts)
  • Hủy bỏ (Cancels)
  • Giao tiếp với (Communicates with)

Khung nhìn đồng thời 3

• Hiển thị các thể hiện của các mô-đun trong khung nhìn phân rã mô-đun để hiểu ánh xạ giữa các khung nhìn
• Điểm đồng bộ hóa nằm trong một mô-đun nhất định
  • Trách nhiệm này được giao đúng nơi
• Sự giao nhau của hai luồng ảo: dấu hiệu rằng một số đồng bộ hóa cần thiết

Khung nhìn đồng thời 4

• Các trường hợp sử dụng
  1. Hai người dùng làm những việc tương tự cùng một lúc
  2. Một người dùng thực hiện nhiều hoạt động đồng thời
  3. Khởi động hệ thống
  4. Tắt hệ thống

Khung nhìn đồng thời 5

• Đồng thời cũng có thể là một điểm thay đổi
  • Khởi tạo tuần tự cho một số sản phẩm, song song cho những sản phẩm khác
  • Trong trường hợp này, việc phân rã cần hỗ trợ các kỹ thuật để thay đổi phương pháp khởi tạo
    • Trao đổi thành phần

Khung nhìn triển khai

• Các trách nhiệm mới cần triển khai
  • Trên nhiều bộ xử lý hoặc phần cứng chuyên dụng
• Khung nhìn triển khai phân rã các luồng ảo
  • Các luồng ảo trên các bộ xử lý riêng biệt
  • Thông điệp giữa chúng
• Cơ sở để phân tích lưu lượng mạng, xem khả năng tắc nghẽn

Khung nhìn triển khai 2

• Quyết định xem có cần nhiều phiên bản của một số mô-đun hay không
  • Độ tin cậy
• Hỗ trợ lý luận về việc sử dụng phần cứng cho mục đích đặc biệt
• Trình điều khiển kiến trúc giúp xác định việc phân bổ các thành phần cho phần cứng
  • Nhân rộng so với lập lịch thời gian thực

Xác định giao diện của các mô-đun con

• Giao diện mô-đun
  • Các dịch vụ và thuộc tính được cung cấp và yêu cầu
  • Khác với chữ ký
  • Ghi lại những gì người khác có thể sử dụng và những gì họ có thể phụ thuộc
• Các tài liệu khung nhìn phân rã mô-đun
  • Mô-đun sản xuất / mô-đun tiêu dùng trên thông tin
  • Các mô hình tương tác yêu cầu các mô-đun cung cấp và sử dụng dịch vụ

Xác định giao diện của các mô-đun con 2

• Các tài liệu khung nhìn đồng thời
  • Tương tác giữa các luồng, dẫn đến giao diện mô-đun cung cấp hoặc sử dụng dịch vụ
  • Thông tin mà một thành phần đang hoạt động
    • Đang chạy luồng riêng (ví dụ)
  • Thông tin mà một thành phần đồng bộ hóa, tuần tự, chặn các cuộc gọi

Xác định giao diện của các mô-đun con 3

• Các tài liệu khung nhìn triển khai
  • Yêu cầu phần cứng (HW cho mục đích đặc biệt)
  • Yêu cầu về thời gian
    • Exp: tốc độ tính toán của bộ xử lý
  • Yêu cầu giao tiếp
    • Exp: cập nhật thông tin không quá một lần mỗi giây

Xác minh và tinh chỉnh

• Việc phân rã thành các mô-đun cần được xác minh
• Các mô-đun con cần chuẩn bị cho quá trình phân rã của chính chúng
• Hoàn thành cho
  • Yêu cầu chức năng
  • Ràng buộc
  • Yêu cầu chất lượng

Yêu cầu chức năng

• Mô-đun con có trách nhiệm
  • Bắt nguồn từ việc phân rã các yêu cầu chức năng
  • Như các trường hợp sử dụng cho mô-đun
  • Tách và tinh chỉnh các trường hợp sử dụng chính
    • khả năng truy xuất nguồn gốc
  • Exp: các ca sử dụng khởi tạo toàn bộ hệ thống
    • Chia thành quá trình khởi tạo hệ thống con

Nghiên cứu điển hình

• Trách nhiệm ban đầu
  • Đóng / mở cửa theo yêu cầu
    • Tại chỗ hoặc từ xa
  • Dừng cửa trong vòng 0,1 giây khi phát hiện chướng ngại vật
  • Tương tác với HIS
  • Hỗ trợ chẩn đoán từ xa

Nghiên cứu tình huống 2

• Phân chia trách nhiệm
  • Giao diện người dùng: nhận ra các yêu cầu của người dùng và chuyển chúng thành dạng mà mô-đun cửa nâng / hạ thấp mong đợi
  • Mô-đun nâng / hạ cửa:
    • Điều khiển bộ truyền động để nâng / hạ cửa
    • Dừng cửa khi đóng hoàn toàn hoặc mở hoàn toàn
  • Phát hiện chướng ngại vật

Nghiên cứu tình huống 3

• Phân chia trách nhiệm, hơn thế nữa:
  • Máy ảo truyền thông
    • Quản lý giao tiếp với HIS
  • Cảm biến / bộ truyền động VM
    • Quản lý tương tác với các cảm biến và thiết bị truyền động
  • Lập lịch trình
    • Đảm bảo thời hạn
  • Chẩn đoán
    • Quản lý tương tác với HIS để chẩn đoán

Ràng buộc

• Các ràng buộc của mô-đun mẹ được thỏa mãn bởi
  1. Sự phân rã thỏa mãn các ràng buộc
     • Sử dụng hệ điều hành nhất định
  2. Ràng buộc được thỏa mãn bởi một mô-đun con
     • Giao thức đặc biệt
  3. Ràng buộc được thỏa mãn bởi nhiều mô-đun con
     • Việc sử dụng web yêu cầu hai mô-đun (máy khách và máy chủ)

Nghiên cứu điển hình

• Ràng buộc: liên lạc với HIS được duy trì
  • Máy ảo giao tiếp sẽ nhận dạng nếu điều này không khả dụng
  • Ràng buộc được thỏa mãn bởi một mô-đun con

Kịch bản chất lượng (QS)

• Cần được tinh chỉnh và gán cho các mô-đun con
• Khả năng
  • QS thỏa mãn hoàn toàn bởi việc phân rã
  • QS có thể được thỏa mãn bởi việc phân rã với các ràng buộc trên các mô-đun con
    • Các lớp và khả năng sửa đổi
  • Việc phân rã có thể trung tính đối với QS
    • QS được chỉ định cho các mô-đun con
  • QS không thỏa mãn được bởi việc phân rã
    • Phân rã được xem xét lại hoặc lý do cho điều này được ghi lại
    • Sự đánh đổi điển hình

Nghiên cứu điển hình

• Thiết bị và điều khiển đóng mở cửa khác nhau đối với các sản phẩm khác nhau trong dòng sản phẩm
  • Có thể bao gồm các điều khiển từ bên trong HIF
  • QS được ủy quyền cho mô-đun giao diện người dùng
• Bộ xử lý được sử dụng trong các sản phẩm khác nhau sẽ khác nhau
  • Kiến trúc sản phẩm cho từng bộ xử lý cụ thể phải được lấy trực tiếp từ PLA
  • QS được ủy quyền cho tất cả các mô-đun

Nghiên cứu tình huống 2

• Nếu chướng ngại vật (người / đồ vật) được phát hiện bởi cửa nhà để xe trong quá trình đi xuống, nó phải dừng lại hoặc mở lại trong vòng 0,1 giây
  • QS được ủy quyền cho bộ lập lịch và mô-đun phát hiện chướng ngại vật
• Có thể truy cập thiết bị mở cửa nhà để xe để chẩn đoán và quản lý từ bên trong HMI
  • Sử dụng giao thức chẩn đoán sản phẩm cụ thể
  • QS tách giữa các mô-đun chẩn đoán và giao tiếp

Kết quả bước

• Phân rã một mô-đun thành các mô-đun con
  • Mỗi mô-đun con có
    • Tập hợp các trách nhiệm
    • Tập hợp các trường hợp sử dụng
    • Giao diện
    • Các tình huống chất lượng
    • Tập hợp các ràng buộc
  • Đủ cho lần phân rã tiếp theo

Tiến trình lặp lại

• Từ vựng của các mô-đun và trách nhiệm của chúng
• Nhiều trường hợp sử dụng và kịch bản chất lượng khác nhau và hiểu một số phân nhánh của chúng
• Nhu cầu thông tin của các mô-đun
  • Tương tác của chúng
• Chưa quyết định
  • Ngôn ngữ giao tiếp, thuật toán phát hiện chướng ngại vật, v.v.

Kết quả lặp lại

• Chúng ta đã xác định đủ để phân bổ các nhóm làm việc và giao nhiệm vụ cho họ
  • Nếu chúng ta thiết kế một hệ thống lớn
• Chúng ta có thể tiến hành bước lặp tiếp theo và quyết định câu trả lời cho các câu hỏi
  • Nếu chúng ta thiết kế hệ thống nhỏ