Tôi đã hỏi nhiều nhà thiết kế kiến trúc phần mềm (Software Architect) mà tôi có dịp tiếp xúc về “Tầm quan trọng của tài liệu kiến trúc hệ thống phần mềm là gì?”. Một vài câu trả lời mà tôi thường nhận được là:
- Thật sự không quan trọng lắm, việc xây dựng lên một kiến trúc quan trọng hơn.
- Phần mềm tôi xây lên không lớn lắm nên việc tài liệu lại kiến trúc thì không thật sự quan trọng.
- Tôi không có thời gian để viết tài liệu kiến trúc, đó là công việc tốn thời gian nhưng không mang lại giá trị.
- Tài liệu kiến trúc ư! Nó là điều xa xỉ với doanh nghiệp tôi đang làm. Nó phù hợp với các sản phẩm thật sự lớn (enterprise product) ở các tập đoàn công nghệ.
Nhưng khi bạn tham gia thiết kế, hoặc tư vấn một giải pháp hệ thống phần mềm cho các đối tác ở thị trường các nước phát triển thì tài liệu kiến trúc phần mềm (Software Architecture Document) là một tài liệu được yêu cầu trình bày trong giai đoạn sơ khởi của dự án và bắt buộc bàn giao trong quá trình phát triển sản phẩm.
Tài liệu hoá kiến trúc phần mềm thật sự quan trọng bởi các lý do sau:
- Để truyền tải kiến trúc hệ thống đến các nhà phát triển phần mềm để giúp họ hiểu lý do đằng sau các quyết định chọn lựa kiến trúc.
- Để truyền đạt sự phát triển thông tin liên quan hệ thống đến các thành viên tham gia thiết kế và phát triển hệ thống.
- Tài liệu hoá những quyết định quan trọng liên quan đến kiến trúc có tính ảnh hưởng sâu rộng đến hệ thống. Nó giúp việc nâng cấp, bảo trì trở nên dễ dàng trong tương lai.
- Tài liệu kiến trúc không những chứa quyết định cuối cùng về kiến trúc mà còn chứa những thông tin (các thuộc tính chất lượng cần ưu tiên theo yêu cầu nghiệp vụ, các kịch bản, bảng đánh giá so sánh các giải pháp thiết kế thay thế,…) liên quan đến việc đưa ra quyết định chọn lựa kiến trúc.
- Cung cấp một tài liệu tham khảo chung cho các thảo luận, hiểu biết về hệ thống đang có.
- Đưa ra các “quy tắc” mà các nhà phát triển, kiến trúc sư hệ thống cần tuân theo trong quá trình phát triển, bảo trì, nâng cấp hệ thống.
- Cung cấp những thông tin cần thiết cho người tích hợp hệ thống tham khảo và đưa ra thiết kế phù hợp để tích hợp giữa hệ thống đang có với các hệ thống khác.
- Cung cấp thông tin tham khảo cho các nhà thiết kế kiến trúc khác tham khảo và tái sử dụng lại (Reuse) cho các sản phẩm khác trong tương lai.
- Cung cấp một cơ sơ cần thiết để cho các nhà phát triển tham khảo và đưa ra hướng ước lượng, lên kế hoạch cho dự án.
- Cung cấp cơ sở cho quá trình hình thành cấu trúc nhóm phát triển.
- Nó là một cơ sở chính để đánh giá hiệu năng của hệ thống trước khi nó được xây dựng.
- Nó cung cấp các ràng buộc (constraints), những hạn hế (limitations) của sản phẩm.
- Nó là nơi quyết định tài liệu kỹ thuật chi tiết khác cần được phát triển để đảm bảo chất lượng phần mềm.
Có thể có nhiều lợi ích khác mà một số doanh nghiệp chú trọng tuỳ theo mức độ và tính nghiêm trọng của sản phẩm phần mềm. Có rất nhiều nhà thiết kế sử dụng công cụ UML modeling để tài liệu hoá kiến trúc của họ, tuy nhiên nó có một số nhược điểm như:
- Nó dễ bỏ dỡ lý do đằng sau của những quyết định chọn lựa kiến trúc hệ thống.
- Không dễ dàng tài liệu hoá các giải pháp kiến trúc thay thế.
- Không dễ để nắm bắt một số quy tắc, hướng dẫn bắt buộc của kiến trúc.
- Với những đối tượng liên quan thiếu hiểu biết về UML thì tài liệu kiến trúc sẽ gây nhiều khó khăn cho họ.
Vì vậy, tốt hơn hết nên tài liệu hoá kiến trúc hệ thống với định dạng Word format. UML có thể dùng để mô tả kiến trúc hoặc mô tả các lược đồ (diagrams) được rõ ràng. Kiến trúc hệ thống tốt luôn tạo ra sự linh hoạt cho việc cải tiến, nâng cấp hệ thống trong tương lai. Tài liệu kiến trúc hệ thống phần mềm là cơ sở để xác định các tài liệu kỹ thuật cần ưu tiên phát triển để kiểm soát chất lượng phần mềm.
Source: APEX Global