Lộ trình của khóa học
- Kiến trúc phần mềm là gì?
- Thiết kế kiến trúc phần mềm
- Yêu cầu: thuộc tính chất lượng (quality attributes) hoặc phẩm chất (qualities)
- Cách đạt được yêu cầu: chiến thuật (tactics)
- Chiến thuật dẫn đến kiểu kiến trúc (architectural styles) như thế nào
- Nghiên cứu điển hình (Case studies) về kiểu kiến trúc, quan sát những phẩm chất đã đạt được (the achieved qualities)
- Phương pháp ADD
- Lập tài liệu kiến trúc phần mềm
- Bass và những người khác
- Hôm nay: Hofmeister và những người khác → “bốn khung nhìn”
Nguồn gốc của bốn khung nhìn
- Nghiên cứu về SA cho các hệ thống CÔNG NGHIỆP lớn và phức tạp
- Mục đích nghiên cứu
- Hiểu các vấn đề kiến trúc mà các nhà thiết kế phải đối mặt
- Hiểu các thực hành hiện tại và các thực hành tốt nhất
- Tìm ra điểm chung giữa các lĩnh vực
- Tìm ra các nguyên tắc cơ bản dẫn đến SA tốt và hữu ích
Các mục tiêu nghiên cứu chính xác
- Đối với mỗi hệ thống
- Hiểu vấn đề
- Hiểu SA và cách nó giải quyết vấn đề
- Tìm ra các phương pháp và cách tiếp cận được các kiến trúc sư sử dụng trong việc thiết kế SA
- Tìm hiểu cách SA được sử dụng trong quá trình phát triển (development), bảo trì (maintenance), tiến triển (evolution), các sản phẩm khác trong cùng một họ (same family), các sản phẩm kế thừa của sản phẩm
Kết quả nghiên cứu rộng rãi
- SA được tách thành các khung nhìn
- Không phải là một ý tưởng mới
- Không phải là một thỏa thuận chung về các khung nhìn nào là hữu ích nhất
- Việc tách các khía cạnh khác nhau thành các khung nhìn khác nhau sẽ giúp quản lý tính PHỨC TẠP (complexity)
- Các khung nhìn khái niệm (Conceptual), mô-đun (module), thực thi (execution) và mã (code)
Bốn khung nhìn
- Dựa trên các quan sát thực tế
- Các kiến trúc sư không nhất thiết phải công nhận chúng là các khung nhìn riêng biệt
- Giải quyết các mối quan tâm về kỹ thuật khác nhau
- Mỗi khung nhìn mô tả một loại cấu trúc (structure) khác nhau
- Các cấu trúc được ghép nối lỏng lẻo giữa các khung nhìn
Bốn khung nhìn là gì
- Khung nhìn mã
- Tổ chức mã nguồn thành mã đối tượng, thư viện, mã nhị phân, sau đó lần lượt thành các phiên bản, tệp và thư mục
- Khung nhìn mô-đun
- Phân rã hệ thống và phân chia các mô-đun thành các lớp (layers)
- Do phức tạp
- Khung nhìn thực thi
- Phân bổ các thành phần chức năng cho các thực thể thời gian chạy; giao tiếp, phối hợp, đồng bộ giữa chúng; ánh xạ tới HW
- Khung nhìn khái niệm
- Mô tả hệ thống về các phần tử thiết kế chính của nó và mối quan hệ giữa chúng; gắn chặt với miền ứng dụng
Khung nhìn khái niệm: các mối quan tâm về kỹ thuật
- Chức năng hệ thống được ánh xạ tới các thành phần (components) khái niệm
- Điều phối và trao đổi dữ liệu được xử lý bởi các trình kết nối (connectors)
- Độc lập với các kỹ thuật SW và HW
- Luồng điều khiển lô gic
- Mối quan tâm
- Hệ thống đáp ứng các yêu cầu như thế nào?
- Các thành phần COTS
- HW / SW hợp nhất theo miền cụ thể
- Chức năng được phân chia thành các bản phát hành sản phẩm
- Thế hệ sản phẩm trước, thế hệ tương lai
- Dòng sản phẩm
- Tác động của những thay đổi trong yêu cầu hoặc miền
Khung nhìn mô-đun: các mối quan tâm về kỹ thuật
- Các thành phần và kết nối được ánh xạ thành hệ thống con (subsystems) và mô-đun (modules)
- Giải pháp khái niệm được thực hiện với các công nghệ và nền tảng SW và HW hiện tại
- Mối quan tâm
- Sản phẩm được ánh xạ đến nền tảng SW như thế nào?
- Hỗ trợ hệ thống hoặc các dịch vụ được sử dụng, ở đâu?
- Hỗ trợ kiểm tra
- Cách giảm thiểu sự phụ thuộc giữa các mô-đun
- Cách tối đa hóa việc tái sử dụng các mô-đun / hệ thống con
- Cách bảo vệ sản phẩm khỏi những thay đổi trong COTS SW, nền tảng SW, những thay đổi trong tiêu chuẩn
Khung nhìn thực thi: các mối quan tâm về kỹ thuật
- Các mô-đun được ánh xạ thành các phần tử nền tảng thời gian chạy (runtime platform elements) và các phần tử này được ánh xạ tới kiến trúc HW (HW architecture)
- Xác định các thực thể thời gian chạy của hệ thống và các thuộc tính của chúng (sử dụng bộ nhớ, gán HW)
- Luồng điều khiển được nhìn thấy từ nền tảng thời gian chạy
- Mối quan tâm
- Làm thế nào hệ thống đáp ứng các yêu cầu về hiệu suất, phục hồi, cấu hình lại của nó
- Cân bằng việc sử dụng tài nguyên
- Sự cần thiết đồng thời (concurrency), sao chép (replication), phân phối (distribution) mà không cần thêm nhiều độ phức tạp cho các thuật toán điều khiển?
- Giảm thiểu tác động của những thay đổi trong nền tảng thời gian chạy
Khung nhìn mã: các mối quan tâm về kỹ thuật
- Các thực thể thời gian chạy được ánh xạ tới các thành phần triển khai (ví dụ: thực thi được)
- Các mô-đun được ánh xạ tới các thành phần nguồn (source components)
- Cách các thành phần nguồn tạo ra các thành phần triển khai
- Mối quan tâm
- Giảm thời gian và nỗ lực cho việc nâng cấp sản phẩm
- Quản lý các phiên bản (versions) và bản phát hành (releases) sản phẩm
- Giảm thời gian xây dựng (build time)
- Các công cụ cần thiết cho môi trường phát triển
- Hỗ trợ tích hợp và thử nghiệm
Sử dụng bốn khung nhìn
- Ưu tiên các quyết định thiết kế và xác định sự phụ thuộc giữa chúng
- Kết quả: tập hợp các hoạt động thiết kế và một thứ tự dựa trên sự phụ thuộc của chúng
- Không phải tất cả các quyết định đều có thể được đưa ra trước
- Kiến trúc sư đưa ra các quyết định hợp lý nhất
- Lặp lại kiến trúc và thực hiện các thay đổi khi cần thiết
Kỳ vọng từ việc sử dụng bốn khung nhìn
- Truy tìm các yếu tố ảnh hưởng và yêu cầu xuyên suốt kiến trúc
- Trình tự các hoạt động thiết kế
- Đánh đổi thiết kế
- Hỗ trợ các phẩm chất của hệ thống (hiệu suất…)
- Hỗ trợ các phẩm chất chung (khả năng xây dựng…)
- Đảm bảo không có khía cạnh nào của kiến trúc bị bỏ qua
- Tạo tài liệu hữu ích về kiến trúc
Nhiệm vụ thiết kế cho từng khung nhìn
- Phân tích toàn cục
- Xác định các yếu tố ảnh hưởng bên ngoài và các yêu cầu quan trọng có thể ảnh hưởng đến kiến trúc
- Phân tích những điều trên để đưa ra chiến lược thiết kế kiến trúc
- Nhiệm vụ thiết kế trung tâm
- Xác định các phần tử của khung nhìn và mối quan hệ của chúng, cách chúng được cấu hình
- Đánh giá toàn cục: nhiệm vụ đang thực hiện
- Nguồn thông tin nào vào thời điểm nào (từ nhiều nguồn đầu vào)
- Các quyết định ở đây có tác động đến các nhiệm vụ thiết kế trước đó không?
- Đánh giá các quyết định thiết kế trung tâm để tác động lẫn nhau
- Nhiệm vụ thiết kế cuối cùng
- Exp: lập ngân sách tài nguyên, định nghĩa giao diện
Phân tích toàn cục
- Mục đích
- Xác định các yếu tố bên ngoài ảnh hưởng đến kiến trúc
- Phân tích các yếu tố trên và phát triển các chiến lược để đưa chúng vào kiến trúc
- Bảng yếu tố
- Có mục đích bổ sung cho phân tích rủi ro và phân tích yêu cầu
- Các yếu tố
- Tổ chức
- Công nghệ
- Sản phẩm
Các yếu tố tổ chức
- Ràng buộc các lựa chọn thiết kế
- Một số chỉ áp dụng cho việc phát triển sản phẩm (lịch trình phát triển, ngân sách)
- Một số áp dụng cho tất cả các sản phẩm của tổ chức (quan điểm của tổ chức, quy trình SW)
- Ghi lại kết quả của quá trình phân tích
- Các nhà phát triển cá nhân nên sử dụng chúng khi đưa ra quyết định để giải quyết các lựa chọn thiết kế cụ thể
- Kiến trúc sư nên theo dõi hiệu quả và mức độ phù hợp của các chiến lược đã chọn, thực hiện các thay đổi nếu cần
Yếu tố công nghệ và sản phẩm
- Yếu tố công nghệ
- Ảnh hưởng rõ ràng đến kiến trúc
- Phần cứng, phần mềm, tiêu chuẩn
- Thay đổi theo thời gian
- Yếu tố sản phẩm
- Ảnh hưởng chính đến kiến trúc
- Tính năng chức năng của sản phẩm
- Chất lượng
- Cần hỗ trợ những thay đổi trong tương lai
Hoạt động phân tích toàn cục
Phân tích các yếu tố
- Xác định và mô tả các yếu tố
- Có ảnh hưởng toàn cục đáng kể
- Có thể bản địa hóa ảnh hưởng của yếu tố đó không?
- Yếu tố quan trọng trong giai đoạn phát triển nào
- Chuyên môn và kỹ năng mới cho yếu tố này?
- Có thể thay đổi trong quá trình phát triển
- Khó thỏa mãn
- Có ít kinh nghiệm
- Có ảnh hưởng toàn cục đáng kể
Phân tích các yếu tố, 2
- Tính linh hoạt của yếu tố: điều gì có thể thương lượng
- Với bất kỳ bên liên quan nào
- Thông tin cần thiết khi các yếu tố xung đột hoặc không thể thực hiện được
- Làm thế nào để xác định
- Có thể ảnh hưởng / thay đổi yếu tố để nhiệm vụ kiến trúc trở nên dễ dàng hơn?
- Có thể bị ảnh hưởng như thế nào?
- Có thể bị ảnh hưởng ở mức độ nào?
Phân tích các yếu tố, 3
- Khả năng thay đổi của yếu tố: điều gì có thể thay đổi
- Trong bản thân yếu tố
- Theo cách bạn sử dụng nó trong tương lai
- Cách xác định
- Yếu tố có thể thay đổi theo cách nào?
- Nó sẽ thay đổi như thế nào trong / sau khi phát triển?
- Bao lâu một lần?
- Yếu tố sẽ bị ảnh hưởng bởi sự thay đổi của các yếu tố khác?
Phân tích các yếu tố, 4
- Phân tích tác động của các yếu tố
- Về kiến trúc
- Nếu một yếu tố thay đổi thì yếu tố nào sẽ bị ảnh hưởng và như thế nào:
- Yếu tố khác?
- Các thành phần?
- Các phương thức hoạt động của hệ thống?
- Các quyết định thiết kế khác?
Bảng yếu tố
Phát triển chiến lược
- Xác định các vấn đề và các yếu tố ảnh hưởng của chúng
- Vấn đề có thể phát sinh từ các hạn chế / ràng buộc do các yếu tố áp đặt
- Exp: lịch trình tích cực không thể bao gồm tất cả các yêu cầu
- Vấn đề có thể xuất phát từ nhu cầu giảm tác động của khả năng thay đổi của các yếu tố
- Exp: giảm chi phí chuyển sang một hệ điều hành khác
- Vấn đề có thể phát triển do khó đáp ứng các yếu tố sản phẩm
- Exp: thông lượng cao có thể làm quá tải CPU
- Vấn đề có thể phát sinh do cần có giải pháp chung cho các yêu cầu toàn cục
- Exp: xử lý lỗi, khôi phục
- Vấn đề có thể phát sinh từ các hạn chế / ràng buộc do các yếu tố áp đặt
Phát triển chiến lược, 2
- Phát triển các giải pháp và chiến lược cụ thể nhằm giải quyết các mục tiêu:
- Giảm hoặc khoanh vùng ảnh hưởng của yếu tố
- Giảm tác động của khả năng thay đổi của yếu tố đối với thiết kế và các yếu tố khác
- Giảm hoặc khoanh vùng các lĩnh vực chuyên môn hoặc kỹ năng cần thiết
- Giảm thời gian và nỗ lực tổng thể
Phát triển chiến lược, 3
- Xác định các chiến lược liên quan
- Không trùng lặp chiến lược
- Định dạng tiêu chuẩn (Thẻ vấn đề) để mô tả
- Mỗi vấn đề, các yếu tố ảnh hưởng và tác động của chúng
- Thảo luận chung về giải pháp của nó
- Các chiến lược giải quyết nó
- Tên có ý nghĩa cho các chiến lược
Thẻ vấn đề (Issue card)
Các loại nhân tố ảnh hưởng điển hình
| Yếu tố tổ chức | Yếu tố công nghệ | Yếu tố sản phẩm |
| O1: Quản lý | T1: phần cứng cho mục đích chung | P1: Tính năng chức năng |
| O2: Kỹ năng, sở thích, điểm mạnh, điểm yếu của nhân viên | T2: phần cứng theo miền | P2: Giao diện người dùng |
| O3: Quy trình và môi trường phát triển | T3: công nghệ phần mềm | P3: hiệu suất |
| O4: lịch trình phát triển | T4: công nghệ kiến trúc | P4: độ tin cậy |
| O5: ngân sách phát triển | T5: tiêu chuẩn | P5: phát hiện lỗi, báo cáo, phục hồi |
| P6: dịch vụ | ||
| P7: Giá thành sản phẩm |
Yếu tố tổ chức điển hình
Ví dụ
Ví dụ 2
Ví dụ 3
Ví dụ 4
Ví dụ 5
