Trước đó ở phần giới thiệu ta đã giải thích mô hình kiến trúc của hệ thống có thể được

dùng để
 Thảo luận về thiết kế và yêu cầu của phần mềm
 Ghi chú lại thiết kế đó cho việc thiết kế và hiện thực cụ thể hơn hoặc cho sự phát
triển sau này của hệ thống

Trong phần này ta sẽ thảo luận 2 vấn đề liên quan là

 Góc nhìn hoặc khía cạnh nào giúp ích cho việc thiết kế và ghi lại kiến trúc của hệ
thống?
 Những ký hiệu, chú thích nào nên được dùng để mô tả hệ thống?

Không thể biểu diễn toàn bộ thông tin về kiến trúc hệ thống trong một mô hình kiến trúc
duy nhất, vì mỗi mô hình chỉ biểu diễn dưới một góc nhìn, ví dụ như:
 Cách hệ thống phân ra thành các modules
 Cách các tiến tương tác trong thời gian chạy
 Cách các thành phần trong hệ thống phân bố trong hệ thống mạng
=> Mỗi khía cạnh đều cần thiết vào những giai đoạn khác nhau nên cần phải biểu diễn
nhiều góc nhìn. Vậy góc nhìn nào là cần thiết?

Krutchen (1995) trong “4+1 kiểu nhìn kiến trúc hệ thống” đề xuất nên có 4 góc nhìn nền
tảng:
 Góc nhìn hướng logic – biểu diễn các khái niệm trừu tượng chính trong hệ thống
bằng object và class.
 Góc nhìn hướng tiến trình – biểu diễn cách hệ thống được tạo thành từ nhiều tiến
trình tương tác với nhau trong thời gian chạy. Hữu ích trong đánh giá yêu cầu phi
chức năng như hiệu năng và tính sẵn sàng.
 Góc nhìn hướng phát triển – biểu diễn cách hệ thống được phân rã thành các thành
phần trong quá trình phát triển. Hữu ích trong quản lý và lập trình phần mềm.
  Góc nhìn hướng vật lý – biểu diễn phần cứng hệ thống và cách phần mềm được
phân bổ giữa các bộ xử lý. Hữu ích trong việc triển khai hệ thống.

Hofmeister et al. (2000) cũng đưa ra đề xuất tương tự và bổ sung thêm khái niệm của góc
nhìn khái niệm (conceptual view):
 Là góc nhìn trừu tượng của hệ thống
 Là nền tảng cho việc phân rã yêu cầu mức cao thành những đặc điểm chi tiết
 Giúp quyết định thành phần nào có thể được sử dụng lại
 Đại diện cho một dây chuyền sản xuất thay vì một hệ thống duy nhất.

 Hình 6.1 là một ví dụ cho góc nhìn khái niệm

 Trong thực tế thường được phát triển trong quá trình thiết kế để hỗ trợ đưa ra
quyết định về kiến trúc
 Là một cách truyền đạt bản chất của hệ thống cho những bên liên quan

Một số cách để mô tả kiến trúc:

  UML – thường được sử dụng một cách không chặt chẽ, không theo quy chuẩn
 Ký hiệu, chú thích không chính thức
 Ngôn ngữ mô tả kiến trúc (ADLs) – các thành phần, liên kết, quy định và hướng
dẫn thiết kế dành riêng cho một lĩnh vực nào đó (e.g. sản xuất ô tô) nên khó hiểu
và áp dụng trong phát triển phần mềm

Khi nào cần tài liệu kiến trúc

 Phương pháp Agile – không đáng thời gian và tiền bạc
 Khi cần truyền đạt với các bên liên quan dưới góc nhìn nào đó, không cần đầy đủ
4 góc nhìn
 Khi hệ thống quan trọng cần được phân tích đánh giá và chịu sự quản lý của bên
ngoài, yêu cầu tài liệu kiến trúc hoàn chỉnh