Software architecture: Difference between revisions

Revision as of 19:13, 15 January 2020

Revision as of 19:14, 15 January 2020

Line 21:

'''Multitude of stakeholders:''' software systems have to cater to a variety of stakeholders such as business managers, owners, users, and operators. These stakeholders all have their own concerns with respect to the system. Balancing these concerns and demonstrating that they are addressed is part of designing the system.<ref name="SAP2" />{{rp|29–31}} This implies that architecture involves dealing with a broad variety of concerns and stakeholders, and has a multidisciplinary nature.

'''[[Separation of concerns]]:''' the established way for architects to reduce complexity is to separate the concerns that drive the design. Architecture documentation shows that all stakeholder concerns are addressed by modeling and describing the architecture from separate points of view associated with the various stakeholder concerns.<ref name="ISO42010"/> These separate descriptions are called architectural views (see for example the [[4+1 Architecturalarchitectural Viewview Modelmodel]]).

'''Quality-driven:''' classic [[software design]] approaches (e.g. [[Jackson Structured Programming]]) were driven by required functionality and the flow of data through the system, but the current insight<ref name="SAP2"/>{{rp|26–28}} is that the architecture of a software system is more closely related to its [[quality attributes]] such as [[fault-tolerance]], [[backward compatibility]], [[extensibility]], [[reliability (engineering)|reliability]], [[maintainability]], [[availability]], security, usability, and other such –[[ilities]]. Stakeholder concerns often translate into [[requirements]] on these quality attributes, which are variously called [[non-functional requirements]], extra-functional requirements, behavioral requirements, or quality attribute requirements.