Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.[1]
The architecture of a software system is a metaphor, analogous to the architecture of a building.[2] It functions as the blueprints for the system and the development project, which project management can later use to extrapolate the tasks necessary to be executed by the teams and people involved.
Software architecture is about making fundamental structural choices that are costly to change once implemented. Software architecture choices include specific structural options from possibilities in the design of the software. There are two fundamental laws in software architecture:[3][4]
Everything is a trade-off
"Why is more important than how"
"Architectural Kata" is a teamwork which can be used to produce an architectural solution that fits the needs. Each team extracts and prioritizes architectural characteristics (aka non functional requirements) then models the components accordingly. The team can use C4 Model which is a flexible method to model the architecture just enough. Note that synchronous communication between architectural components, entangles them and they must share the same architectural characteristics. [4]
Documenting software architecture facilitates communication between stakeholders, captures early decisions about the high-level design, and allows the reuse of design components between projects.[5]:29–35
Software architecture design is commonly juxtaposed with software application design. Whilst application design focuses on the design of the processes and data supporting the required functionality (the services offered by the system), software architecture design focuses on designing the infrastructure within which application functionality can be realized and executed such that the functionality is provided in a way which meets the system's non-functional requirements.
Opinions vary as to the scope of software architectures:[6]
Macroscopic system structure: this refers to architecture as a higher-level abstraction of a software system that consists of a collection of computational components together with connectors that describe the interaction between these components.[7]
The important stuff—whatever that is: this refers to the fact that software architects should concern themselves with those decisions that have high impact on the system and its stakeholders.[8]
That which is fundamental to understanding a system in its environment[9]
Things that people perceive as hard to change: since designing the architecture takes place at the beginning of a software system's lifecycle, the architect should focus on decisions that "have to" be right the first time. Following this line of thought, architectural design issues may become non-architectural once their irreversibility can be overcome.[8]
A set of architectural design decisions: software architecture should not be considered merely a set of models or structures, but should include the decisions that lead to these particular structures, and the rationale behind them.[10] This insight has led to substantial research into software architecture knowledge management.[11]
There is no sharp distinction between software architecture versus design and requirements engineering (see Related fields below). They are all part of a "chain of intentionality" from high-level intentions to low-level details.[12]:18
Anti-patterns
The following architectural anti-patterns can arise when architects make decisions. These anti-patterns often follow a progressive sequence, where resolving one may lead to the emergence of another. [4]
An architect may delay or avoid making architectural decisions due to the fear of choosing incorrectly. To address this, ongoing and close collaboration with the development team is often necessary, with architectural choices being adjusted based on their feedback. Additionally, decisions are typically made at the "last responsible moment," ensuring there is enough information to justify and validate the decision, while avoiding unnecessary delays that could lead to analysis paralysis and hinder the team's progress. [4]
Characteristics
Software architecture exhibits the following:
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.[5]: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.[13] These separate descriptions are called architectural views (see for example the 4+1 architectural view model).
Recurring styles: like building architecture, the software architecture discipline has developed standard ways to address recurring concerns. These "standard ways" are called by various names at various levels of abstraction. Common terms for recurring solutions are architectural style,[12]:273–277 tactic,[5]:70–72reference architecture and architectural pattern.[14][15][5]:203–205
Conceptual integrity: a term introduced by Fred Brooks in his 1975 book The Mythical Man-Month to denote the idea that the architecture of a software system represents an overall vision of what it should do and how it should do it. This vision should be separated from its implementation. The architect assumes the role of "keeper of the vision", making sure that additions to the system are in line with the architecture, hence preserving conceptual integrity.[16]:41–50
Cognitive constraints: An observation first made in a 1967 paper by computer programmer Melvin Conway that organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.[17] Fred Brooks introduced it to a wider audience when he cited the paper and the idea in The Mythical Man-Month, calling it Conway's Law.
Motivation
Software architecture is an "intellectually graspable" abstraction of a complex system.[5]:5–6 This abstraction provides a number of benefits:
It gives a basis for analysis of software systems' behavior before the system has been built.[2] The ability to verify that a future software system fulfills its stakeholders' needs without actually having to build it represents substantial cost-saving and risk-mitigation.[18] A number of techniques have been developed to perform such analyses, such as ATAM or by creating a visual representation of the software system.
It provides a basis for re-use of elements and decisions.[2][5]:35 A complete software architecture or parts of it, like individual architectural strategies and decisions, can be re-used across multiple systems whose stakeholders require similar quality attributes or functionality, saving design costs and mitigating the risk of design mistakes.
It supports early design decisions that impact a system's development, deployment, and maintenance life.[5]:31 Getting the early, high-impact decisions right is important to prevent schedule and budget overruns.
It facilitates communication with stakeholders, contributing to a system that better fulfills their needs.[5]:29–31 Communicating about complex systems from the point of view of stakeholders helps them understand the consequences of their stated requirements and the design decisions based on them. Architecture gives the ability to communicate about design decisions before the system is implemented, when they are still relatively easy to adapt.
It helps in risk management. Software architecture helps to reduce risks and chance of failure.[12]:18
It enables cost reduction. Software architecture is a means to manage risk and costs in complex IT projects.[19]
History
The comparison between software design and (civil) architecture was first drawn in the late 1960s,[20] but the term "software architecture" did not see widespread usage until the 1990s.[21] The field of computer science had encountered problems associated with complexity since its formation.[22] Earlier problems of complexity were solved by developers by choosing the right data structures, developing algorithms, and by applying the concept of separation of concerns. Although the term "software architecture" is relatively new to the industry, the fundamental principles of the field have been applied sporadically by software engineering pioneers since the mid-1980s. Early attempts to capture and explain software architecture of a system were imprecise and disorganized, often characterized by a set of box-and-line diagrams.[23]
Software architecture as a concept has its origins in the research of Edsger Dijkstra in 1968 and David Parnas in the early 1970s. These scientists emphasized that the structure of a software system matters and getting the structure right is critical. During the 1990s there was a concerted effort to define and codify fundamental aspects of the discipline, with research work concentrating on architectural styles (patterns), architecture description languages, architecture documentation, and formal methods.[24]
Research institutions have played a prominent role in furthering software architecture as a discipline. Mary Shaw and David Garlan of Carnegie Mellon wrote a book titled Software Architecture: Perspectives on an Emerging Discipline in 1996, which promoted software architecture concepts such as components, connectors, and styles. The University of California, Irvine's Institute for Software Research's efforts in software architecture research is directed primarily in architectural styles, architecture description languages, and dynamic architectures.
IEEE 1471-2000, "Recommended Practice for Architecture Description of Software-Intensive Systems", was the first formal standard in the area of software architecture. It was adopted in 2007 by ISO as ISO/IEC 42010:2007. In November 2011, IEEE 1471–2000 was superseded by ISO/IEC/IEEE 42010:2011, "Systems and software engineering – Architecture description" (jointly published by IEEE and ISO).[13]
While in IEEE 1471, software architecture was about the architecture of "software-intensive systems", defined as "any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole", the 2011 edition goes a step further by including the ISO/IEC 15288 and ISO/IEC 12207 definitions of a system, which embrace not only hardware and software, but also "humans, processes, procedures, facilities, materials and naturally occurring entities". This reflects the relationship between software architecture, enterprise architecture and solution architecture.
Architecture activities
Making architectural decisions involves collecting sufficient relevant information, providing justification for the decision, documenting the decision and its rationale, and communicating it effectively to the appropriate stakeholders. [4]
Having a high customer satisfactions requires availability, fault tolerance, security, testability, recoverability, agility and performance in the system.
Doing mergers and acquisitions (M&A) requires extensibility, scalability, adaptability, and interoperability
Constrained budget and time requires feasibility and simplicity
Faster time-to-market requires maintainability, testability and deployability.
There are four core activities in software architecture design.[25] These core architecture activities are performed iteratively and at different stages of the initial software development life-cycle, as well as over the evolution of a system.
Architectural analysis is the process of understanding the environment in which a proposed system will operate and determining the requirements for the system. The input or requirements to the analysis activity can come from any number of stakeholders and include items such as:
what the system will do when operational (the functional requirements)
how well the system will perform runtime non-functional requirements such as reliability, operability, performance efficiency, security, compatibility defined in ISO/IEC 25010:2011 standard[26]
development-time of non-functional requirements such as maintainability and transferability defined in ISO 25010:2011 standard[26]
business requirements and environmental contexts of a system that may change over time, such as legal, social, financial, competitive, and technology concerns[27]
The outputs of the analysis activity are those requirements that have a measurable impact on a software system's architecture, called architecturally significant requirements.[28]
Architectural synthesis or design is the process of creating an architecture. Given the architecturally significant requirements determined by the analysis, the current state of the design and the results of any evaluation activities, the design is created and improved.[25][5]:311–326
Architecture evaluation is the process of determining how well the current design or a portion of it satisfies the requirements derived during analysis. An evaluation can occur whenever an architect is considering a design decision, it can occur after some portion of the design has been completed, it can occur after the final design has been completed or it can occur after the system has been constructed. Some of the available software architecture evaluation techniques include Architecture Tradeoff Analysis Method (ATAM) and TARA.[29] Frameworks for comparing the techniques are discussed in frameworks such as SARA Report[18] and Architecture Reviews: Practice and Experience.[30]
Architecture evolution is the process of maintaining and adapting an existing software architecture to meet changes in requirements and environment. As software architecture provides a fundamental structure of a software system, its evolution and maintenance would necessarily impact its fundamental structure. As such, architecture evolution is concerned with adding new functionality as well as maintaining existing functionality and system behavior.
Architecture requires critical supporting activities. These supporting activities take place throughout the core software architecture process. They include knowledge management and communication, design reasoning and decision-making, and documentation.
Architecture supporting activities
Software architecture supporting activities are carried out during core software architecture activities. These supporting activities assist a software architect to carry out analysis, synthesis, evaluation, and evolution. For instance, an architect has to gather knowledge, make decisions, and document during the analysis phase.
Knowledge management and communication is the act of exploring and managing knowledge that is essential to designing a software architecture. A software architect does not work in isolation. They get inputs, functional and non-functional requirements, and design contexts, from various stakeholders; and provide outputs to stakeholders. Software architecture knowledge is often tacit and is retained in the heads of stakeholders. Software architecture knowledge management activity is about finding, communicating, and retaining knowledge. As software architecture design issues are intricate and interdependent, a knowledge gap in design reasoning can lead to incorrect software architecture design.[31][32] Examples of knowledge management and communication activities include searching for design patterns, prototyping, asking experienced developers and architects, evaluating the designs of similar systems, sharing knowledge with other designers and stakeholders, and documenting experience on a wiki page.
Design reasoning and decision making is the activity of evaluating design decisions. This activity is fundamental to all three core software architecture activities.[10][33] It entails gathering and associating decision contexts, formulating design decision problems, finding solution options and evaluating tradeoffs before making decisions. This process occurs at different levels of decision granularity while evaluating significant architectural requirements and software architecture decisions, and software architecture analysis, synthesis, and evaluation. Examples of reasoning activities include understanding the impacts of a requirement or a design on quality attributes, questioning the issues that a design might cause, assessing possible solution options, and evaluating the tradeoffs between solutions.
Documentation is the act of recording the design generated during the software architecture process. System design is described using several views that frequently include a static view showing the code structure of the system, a dynamic view showing the actions of the system during execution, and a deployment view showing how a system is placed on hardware for execution. Kruchten's 4+1 view suggests a description of commonly used views for documenting software architecture;[34]Documenting Software Architectures: Views and Beyond has descriptions of the kinds of notations that could be used within the view description.[1] Examples of documentation activities are writing a specification, recording a system design model, documenting a design rationale, developing a viewpoint, documenting views.
Software Architecture Design Strategies
Software architecture inherently deals with uncertainties, and the size of architectural components can significantly influence a system's outcomes, both positively and negatively. Neal Ford and Mark Richards propose an iterative approach to address the challenge of identifying and right-sizing components. This method emphasizes continuous refinement as teams develop a more nuanced understanding of system behavior and requirements. [4]
The approach typically involves a cycle with several stages: [4]
A high-level partitioning strategy is established, often categorized as technical or domain-based. Guidelines for the smallest meaningful deployable unit, referred to as "quanta," are defined. While these foundational decisions are made early, they may be revisited later in the cycle if necessary.
Initial components are identified based on the established strategy.
Requirements are assigned to the identified components.
The roles and responsibilities of each component are analyzed to ensure clarity and minimize overlap.
Architectural characteristics, such as scalability, fault tolerance, and maintainability, are evaluated.
Components may be restructured based on feedback from development teams.
This cycle serves as a general framework and can be adapted to different domains.
There are also concerns that software architecture leads to too much big design up front, especially among proponents of agile software development. A number of methods have been developed to balance the trade-offs of up-front design and agility,[35] including the agile method DSDM which mandates a "Foundations" phase during which "just enough" architectural foundations are laid. IEEE Software devoted a special issue to the interaction between agility and architecture.
Software architecture erosion
Software architecture erosion refers to a gradual gap between the intended and implemented architecture of a software system over time.[36] The phenomenon of software architecture erosion was initially brought to light in 1992 by Perry and Wolf alongside their definition of software architecture.[2]
Software architecture erosion may occur in each stage of the software development life cycle and has varying impacts on the development speed and the cost of maintenance. Software architecture erosion occurs due to various reasons, such as architectural violations, the accumulation of technical debt, and knowledge vaporization.[37] A famous case of architecture erosion is the failure of Mozilla Web browser.[38] Mozilla is an application created by Netscape with a complex codebase that became harder to maintain due to continuous changes. Due to initial poor design and growing architecture erosion, Netscape spent two years redeveloping the Mozilla Web browser, showing how important it is to manage architecture erosion to avoid extensive repair efforts, time and cost losses.
Architecture erosion can decrease software performance, substantially increase evolutionary costs, and degrade software quality. Various approaches and tools have been proposed to detect architecture erosion. These approaches are primarily classified into four categories: consistency-based, evolution-based, and defect-based, and decision-based approach.[36] Besides, the measures used to address architecture erosion contains two main types: preventative and remedial measures.[36]
Software architecture recovery (or reconstruction, or reverse engineering) includes the methods, techniques, and processes to uncover a software system's architecture from available information, including its implementation and documentation. Architecture recovery is often necessary to make informed decisions in the face of obsolete or out-of-date documentation and architecture erosion: implementation and maintenance decisions diverging from the envisioned architecture.[39] Practices exist to recover software architecture as static program analysis. This is a part of the subjects covered by the software intelligence practice.
Architecture is design but not all design is architectural.[1] In practice, the architect is the one who draws the line between software architecture (architectural design) and detailed design (non-architectural design). There are no rules or guidelines that fit all cases, although there have been attempts to formalize the distinction. According to the Intension/Locality Hypothesis,[40] the distinction between architectural and detailed design is defined by the Locality Criterion,[40] according to which a statement about software design is non-local (architectural) if and only if a program that satisfies it can be expanded into a program that does not. For example, the client–server style is architectural (strategic) because a program that is built on this principle can be expanded into a program that is not client–server—for example, by adding peer-to-peer nodes.
There is considerable overlap between requirements engineering and software architecture, as evidenced for example by a study into five industrial software architecture methods that concludes that "the inputs (goals, constraints, etc.) are usually ill-defined, and only get discovered or better understood as the architecture starts to emerge" and that while "most architectural concerns are expressed as requirements on the system, they can also include mandated design decisions".[25] In short, required behavior impacts solution architecture, which in turn may introduce new requirements.[42] Approaches such as the Twin Peaks model[43] aim to exploit the synergistic relation between requirements and architecture.
Computer architecture targets the internal structure of a computer system, in terms of collaborating hardware components such as the CPU – or processor – the bus and the memory.
Serverless architecture
Serverless architecture is a cloud computing paradigm that is often misunderstood as being server-free. It essentially shifts server management responsibilities from developers to cloud service providers. This allows businesses to run their backend code on cloud infrastructure, eliminating the need for physical server management. The event-driven approach of serverless architecture relies on small, task-specific functions that are executed on-demand. These functions are known as Function as a Service (FaaS), and they offer cost-efficiency through a pay-as-you-go billing model and dynamic resource scaling based on application demand.[44][bettersourceneeded]
Systems architecture
The term systems architecture has originally been applied to the architecture of systems that consist of both hardware and software. The main concern addressed by the systems architecture is then the integration of software and hardware in a complete, correctly working device. In another common – much broader – meaning, the term applies to the architecture of any complex system which may be of a technical, sociotechnical or social nature.
Enterprise architecture
The goal of enterprise architecture is to "translate business vision and strategy into effective enterprise". Enterprise architecture frameworks, such as TOGAF and the Zachman Framework, usually distinguish between different enterprise architecture layers. Although terminology differs from framework to framework, many include at least a distinction between a business layer, an application (or information) layer, and a technology layer. Enterprise architecture addresses among others the alignment between these layers, usually in a top-down approach.
In software project management, software testing, and software engineering, verification and validation is the process of checking that a software engineer system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"
A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after the business requirements specification (CONOPS). The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction.
In the context of software engineering, software quality refers to two related but distinct notions:
Enterprise architecture (EA) is a business function concerned with the structures and behaviours of a business, especially business roles and processes that create and use business data. The international definition according to the Federation of Enterprise Architecture Professional Organizations is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."
Architecture description languages (ADLs) are used in several disciplines: system engineering, software engineering, and enterprise modelling and engineering.
Software quality assurance (SQA) is a means and practice of monitoring all software engineering processes, methods, and work products to ensure compliance against defined standards. It may include ensuring conformance to standards or models, such as ISO/IEC 9126, SPICE or CMMI.
In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.
The ISO/IEC 15288Systems and software engineering — System life cycle processes is a technical standard in systems engineering which covers processes and lifecycle stages, developed by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). Planning for the ISO/IEC 15288:2002(E) standard started in 1994 when the need for a common systems engineering process framework was recognized.
IEEE 1471 is a superseded IEEE standard for describing the architecture of a "software-intensive system", also known as software architecture.
Legacy modernization, also known as software modernization or platform modernization, refers to the conversion, rewriting or porting of a legacy system to modern computer programming languages, architectures, software libraries, protocols or hardware platforms. Legacy transformation aims to retain and extend the value of the legacy investment through migration to new platforms to benefit from the advantage of the new technologies.
The ISO/IEC/IEEE 42010 Conceptual Model of Architecture Description defines the term architecture framework within systems engineering and software development as:
4+1 is a view model used for "describing the architecture of software-intensive systems, based on the use of multiple, concurrent views". The views are used to describe the system from the viewpoint of different stakeholders, such as end-users, developers, system engineers, and project managers. The four views of the model are logical, development, process, and physical view. In addition, selected use cases or scenarios are used to illustrate the architecture serving as the 'plus one' view. Hence, the model contains 4+1 views:
ISO/IEC/IEEE 42010Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.
A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.
In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.
TRAK is a general enterprise architecture framework aimed at systems engineers. It is based on MODAF 1.2.
Software architecture description is the set of practices for expressing, communicating and analysing software architectures, and the result of applying such practices through a work product expressing a software architecture.
Architecturally significant requirements are those requirements that have a measurable effect on a computer system’s architecture. This can comprise both software and hardware requirements. They are a subset of requirements, the subset that affects the architecture of a system in measurably identifiable ways.
In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.
References
1 2 3 Clements, Paul; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord; Judith Stafford (2010). Documenting Software Architectures: Views and Beyond, Second Edition. Boston: Addison-Wesley. ISBN978-0-321-55268-6.
↑ Ali Babar, Muhammad; Dingsoyr, Torgeir; Lago, Patricia; van Vliet, Hans (2009). Software Architecture Knowledge Management. Dordrecht Heidelberg London New York: Springer. ISBN978-3-642-02373-6.
1 2 3 George Fairbanks (2010). Just Enough Software Architecture. Marshall & Brainerd.
↑ P. Kruchten; H. Obbink; J. Stafford (2006). "The past, present and future of software architecture". IEEE Software. 23 (2): 22. doi:10.1109/MS.2006.59. S2CID2082927.
1 2 3 Christine Hofmeister; Philippe Kruchten; Robert L. Nord; Henk Obbink; Alexander Ran; Pierre America (2007). "A general model of software architecture design derived from five industrial approaches". Journal of Systems and Software. 80 (1): 106–126. doi:10.1016/j.jss.2006.05.024.
↑ Woods, E. (2012). "Industrial architectural assessment using TARA". Journal of Systems and Software. 85 (9): 2034–2047. doi:10.1016/j.jss.2012.04.055. S2CID179244.
↑ Maranzano, J. F.; Rozsypal, S. A.; Zimmerman, G. H.; Warnken, G. W.; Wirth, P. E.; Weiss, D. M. (2005). "Architecture Reviews: Practice and Experience". IEEE Software. 22 (2): 34. doi:10.1109/MS.2005.28. S2CID11697335.
↑ Kruchten, P. (2008). "What do software architects really do?". Journal of Systems and Software. 81 (12): 2413–2416. doi:10.1016/j.jss.2008.08.025.
↑ Babar, M.A.; Dingsøyr, T.; Lago, P.; Vliet, H. van (2009). Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition. Springer. ISBN978-3-642-02373-6.
↑ Tang, A.; Han, J.; Vasa, R. (2009). "Software Architecture Design Reasoning: A Case for Improved Methodology Support". IEEE Software. 26 (2): 43. doi:10.1109/MS.2009.46. hdl:1959.3/51601. S2CID12230032.
↑ C. Shekaran; D. Garlan; M. Jackson; N.R. Mead; C. Potts; H.B. Reubenstein (1994). "The role of software architecture in requirements engineering". Proceedings of IEEE International Conference on Requirements Engineering. pp.239–245. doi:10.1109/ICRE.1994.292379. ISBN978-0-8186-5480-0. S2CID3129363.
Len, Bass (2012). Software Architecture in Practice (3rded.). Addison-Wesley Professional. ISBN9780321815736. - This book covers the fundamental concepts of the discipline. The theme is centered on achieving quality attributes of a system.
Clements, Paul (2010). Documenting Software Architectures: Views and Beyond (2nded.). Addison-Wesley Professional. ISBN9780321552686. - This book describes what software architecture is and shows how to document it in multiple views, using UML and other notations. It also explains how to complement the architecture views with behavior, software interface, and rationale documentation. Accompanying the book is a wiki that contains an example of software architecture documentation.
Bell, Michael (2008). Bell, Michael (ed.). Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley. doi:10.1002/9781119198864. ISBN9780470255704.
Kazman, Rick (May 2003). "Architecture, Design, Implementation"(PDF). Software Engineering Institute. Archived(PDF) from the original on 2015-09-21. - On the distinction between architectural design and detailed design.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
