Khác biệt giữa bản sửa đổi của “Kiến trúc phần mềm”

'''Kiến trúc phần mềm''' của một [[phần mềm|chương trình máy tính]] hay một hệ thống tính toán là cấu trúc của các thành phần trong hệ thống đó. ''Kiến trúc phần mềm'' bao gồm các phần tử [[phần mềm]], các thuộc tính và mối quan hệ giữa chúng. Ngoài ra, thuật ngữ ''"kiến trúc phần mềm"'' cũng đề cập đến các tài liệu kiến trúc phần mềm của một hệ thống, thuận tiện cho việc trao đổi thông tin giữa các thành viên trong một dự án. ''Kiến trúc phần mềm'' giúp việc quyết định ở mức cao trong thiết kế phần mềm dễ dàng hơn và cho phép tái sử dụng các thành phần và [[mẫu thiết kế]] của các dự án. <ref name="SoftwareArchitectureInPractice">''Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, Second Edition. Addison Wesley, Reading 5/9/2003. [http://en.wikipedia.org/wiki/Special:BookSources/0321154959]</ref>

Lĩnh vực [[khoa học máy tính]] trải qua sự kết hợp các vấn đề cùng với sự phức tạp của cấu trúc<ref>''University of Waterloo (2006). A Very Brief History of Computer Science [http://www.cs.uwaterloo.ca/~shallit/Courses/134/history.html]</ref>. Lúc đầu, sự phức tạp được giải quyết bởi người phát triển bằng cách lựa chọn các [[cấu trúc dữ liệu]] đúng đắn, phát triển các [[thuật toán]] và áp dụng các thuật toán để chia nhỏ các vấn đề. Thuật ngữ kiến trúc phần mềm liên quan đến sự mới mẻ của ngành công nghiệp này, nhưng nguyên tắc cơ bản của nó đã được áp dụng bởi các chuyên gia tiên phong trong ngành [[công nghệ phần mềm]] từ những năm 1980. Các cố gắng ban đầu để nắm bắt và giải thích kiến trúc phần mềm của một hệ thống thường không chính xác và chưa được tổ chức rõ ràng. Nó được mô tả bởi các lược đồ “box and line” gồm một tập hợp các hộp và các đường kẻ<ref>''IEEE Transactions on Software Engineering (2006). Introduction to the Special Issue on Software Architecture [http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/trans/ts/&toc=comp/trans/ts/1995/04/e4toc.xml&DOI=10.1109/TSE.1995.10003]</ref>.

Khái niệm “Kiến trúc phần mềm” tập trung vào việc giảm tải các phức tạp bằng cách trừu tượng hóa vấn đề và phân chia rõ trách nhiệm công việc. Tuy vậy, đến ngày nay vẫn chưa có một khái niệm thật chính xác và rõ ràng cho thuật ngữ “Kiến trúc phần mềm”<ref>[http://www.sei.cmu.edu/architecture/definitions.html ''SEI (2006). How do you define Software Architecture?[http://www.sei.cmu.edu/architecture/definitions.html]</ref>.

Như vậy mặc dù khái niệm “Kiến trúc phần mềm” đã xuất hiện trong các giảng đường đại học và được đưa vào sử dụng trong ngành [[công nghệ phần mềm]], nhưng việc nó vẫn chưa có các quy tắc, luật lệ chung và chưa rõ ràng nên thiết kế kiến trúc phần mềm vẫn là một sự pha tạp giữa “khoa học” và “nghệ thuật”. Vẻ “nghệ thuật” của kiến trúc phần mềm được lý giải là do có sự xuất hiện của các yêu cầu phi chức năng của hệ thống mà [[phần mềm]] phải đáp ứng được các yêu cầu này, chẳng hạn như các yêu cầu về các thuộc tính chất lượng <ref name="SoftwareArchitecture.com">''SoftwareArchitectures.com (2006). Intro to Software Quality Attributes [http://www.softwarearchitectures.com/one/Designing+Architecture/78.aspx]</ref>. Ngoài ra, phần mềm còn phải thỏa mãn các yêu cầu khác như: khả năng chịu lỗi, tính tương thích với các phiên bản cũ của các phần mềm khác (backward compatibility <ref>''Định nghĩa của backward compatibility[http://en.wikipedia.org/wiki/Backward_compatibility ''Định nghĩa của backward compatibility]</ref>), khả năng mở rộng, tính tin cậy, khả năng bảo trì, tính hiện hữu, tính bảo mật, tính dễ dùng, và một số các yêu cầu khác nữa <ref name="SoftwareArchitecture.com"/>.