software architecture software development core activities processes requirements design engineering construction testing debugging deployment maintenance paradigms and models agile cleanroom incremental prototyping spiral v model waterfall methodologies and frameworks asd devops dad dsdm fdd iid kanban lean sd less mdd msf psp rad rup safe scrum semat tsp up xp supporting disciplines configuration management documentation software quality assurance sqa project management user experience practices atdd bdd cco ci cd ddd pp standup tdd tools compiler debugger profiler gui designer modeling ide build automation release automation infrastructure as code testing standards and bodies of knowledge babok cmmi ieee standards iso 9001 isoiec standards pmbok swebok itil glossaries artificial intelligence computer science electrical and electronics engineering vte software architecture refers to the high level structures of 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 software architecture is about making fundamental structural choices which are costly to change once implemented software architecture choices include specific structural options from possibilities in the design of software for example the systems that controlled the space shuttle launch vehicle had the requirement of being very fast and very reliable therefore an appropriate realtime computing language would need to be chosen additionally to satisfy the need for reliability the choice could be made to have multiple redundant and independently produced copies of the program and to run these copies on independent hardware while crosschecking results documenting software architecture facilitates communication between stakeholders captures early decisions about the highlevel design and allows reuse of design components between projects2935 scope opinions vary as to the scope of software architectures overall 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 the important stuffwhatever 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 that which is fundamental to understanding a system in its environment things that people perceive as hard to change since designing the architecture takes place at the beginning of a software systems 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 nonarchitectural once their irreversibility can be overcome a set of architectural design decisions 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 highlevel intentions to lowlevel details18 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 how they are addressed is part of designing the system2931 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 these separate descriptions are called architectural views see for example the 41 architectural view model qualitydriven classic software design approaches eg jackson structured programming were driven by required functionality and the flow of data through the system but the current insight2628 is that the architecture of a software system is more closely related to its quality attributes such as faulttolerance backward compatibility extensibility reliability maintainability availability security usability and other such ilities stakeholder concerns often translate into requirements on these quality attributes which are variously called nonfunctional requirements extrafunctional requirements behavioral requirements or quality attribute requirements 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 style203205 conceptual integrity a term introduced by fred brooks in the mythical manmonth 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 integrity4150 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 as with conceptual integrity it was fred brooks who introduced it to a wider audience when he cited the paper and the idea in his elegant classic the mythical manmonth calling it conways law motivation software architecture is an intellectually graspable abstraction of a complex system56 this abstraction provides a number of benefits it gives a basis for analysis of software systems behavior before the system has been built a number of techniques have been developed to perform such analyses such as atam it provides a basis for reuse of elements and decisions35 a complete software architecture or parts of it like individual architectural strategies and decisions can be reused 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 systems development deployment and maintenance life31 getting the early highimpact decisions right is important to prevent schedule and budget overruns it facilitates communication with stakeholders contributing to a system that better fulfills their needs2931 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 failure18 it enables cost reduction software architecture is a means to manage risk and costs in complex it projects history the comparison between software design and civil architecture was first drawn in the late 1960s the field of computer science had encountered problems associated with complexity since its formation 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 mid1980s early attempts to capture and explain software architecture of a system were imprecise and disorganized often characterized by a set of boxandline diagrams 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 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 irvines institute for software researchs efforts in software architecture research is directed primarily in architectural styles architecture description languages and dynamic architectures ieee 14712000 recommended practice for architecture description of softwareintensive systems was the first formal standard in the area of software architecture it was adopted in 2007 by iso as isoiec 420102007 in november 2011 ieee 14712000 was superseded by isoiecieee 420102011 systems and software engineering architecture description jointly published by ieee and iso while in ieee 1471 software architecture was about the architecture of softwareintensive 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 isoiec 15288 and isoiec 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 there are many activities that a software architect performs a software architect typically works with project managers discusses architecturally significant requirements with stakeholders designs a software architecture evaluates a design communicates with designers and stakeholders documents the architectural design and more these core architecture activities are performed iteratively and at different stages of the initial software development lifecycle as well as over the evolution of a system architectural analysis is the process of understanding the environment in which a proposed system or systems 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 nonfunctional requirements such as reliability operability performance efficiency security compatibility defined in isoiec 250102011 standard developmenttime nonfunctional requirements such as maintainability and transferability defined in iso 250102011 standard business requirements and environmental contexts of a system that may change over time such as legal social financial competitive and technology concerns the outputs of the analysis activity are those requirements that have a measurable impact on a software systems architecture called architecturally significant requirements 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 improved311326 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 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 nonfunctional requirements and design contexts from various stakeholders and provides 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 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 in 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 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 a 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 kruchtens 41 view suggests a description of commonly used views for documenting software architecture examples of documentation activities are writing a specification recording a system design model documenting a design rationale developing a viewpoint documenting views software architecture topics software architecture description software architecture description software architecture description involves the principles and practices of modeling and representing architectures using mechanisms such as architecture description languages architecture viewpoints and architecture frameworks architecture description languages architecture description language an architecture description language adl is any means of expression used to describe a software architecture isoiecieee 42010 many specialpurpose adls have been developed since the 1990s including aadl sae standard wright developed by carnegie mellon acme developed by carnegie mellon xadl developed by uci darwin developed by imperial college london daopadl developed by university of mlaga sbcadl developed by national sun yatsen university and byadl university of laquila italy architecture viewpoints view model 41 architectural view model software architecture descriptions are commonly organized into views which are analogous to the different types of blueprints made in building architecture each view addresses a set of system concerns following the conventions of its viewpoint where a viewpoint is a specification that describes the notations modeling and analysis techniques to use in a view that express the architecture in question from the perspective of a given set of stakeholders and their concerns isoiecieee 42010 the viewpoint specifies not only the concerns framed ie to be addressed but the presentation model kinds used conventions used and any consistency correspondence rules to keep a view consistent with other views architecture frameworks architecture framework an architecture framework captures the conventions principles and practices for the description of architectures established within a specific domain of application andor community of stakeholders isoiecieee 42010 a framework is usually implemented in terms of one or more viewpoints or adls architectural styles and patterns architectural pattern an architectural pattern is a general reusable solution to a commonly occurring problem in software architecture within a given context architectural patterns are often documented as software design patterns following traditional building architecture a software architectural style is a specific method of construction characterized by the features that make it notable architectural style an architectural style defines a family of systems in terms of a pattern of structural organization a vocabulary of components and connectors with constraints on how they can be combined architectural styles are reusable packages of design decisions and constraints that are applied to an architecture to induce chosen desirable qualities there are many recognized architectural patterns and styles among them blackboard clientserver 2tier 3tier ntier cloud computing exhibit this style componentbased datacentric eventdriven or implicit invocation layered or multilayered architecture microservices architecture monolithic application peertopeer p2p pipes and filters plugins representational state transfer rest rulebased serviceoriented shared nothing architecture spacebased architecture some treat architectural patterns and architectural styles as the same with which to describe classes of systems software architecture and agile development agile development 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 tradeoffs of upfront design and agility to the interaction between agility and architecture software architecture erosion software architecture erosion or decay refers to the gap observed between the planned and actual architecture of a software system as realized in its implementation the gap between planned and actual architectures is sometimes understood in terms of the notion of technical debt as an example consider a strictly layered system where each layer can only use services provided by the layer immediately below it any source code component that does not observe this constraint represents an architecture violation if not corrected such violations can transform the architecture into a monolithic block with adverse effects on understandability maintainability and evolvability various approaches have been proposed to address erosion these approaches which include tools techniques and processes are primarily classified into three general categories that attempt to minimize prevent and repair architecture erosion within these broad categories each approach is further broken down reflecting the highlevel strategies adopted to tackle erosion these are processoriented architecture conformance architecture evolution management architecture design enforcement architecture to implementation linkage selfadaptation and architecture restoration techniques consisting of recovery discovery and reconciliation there are two major techniques to detect architectural violations reflexion models and domainspecific languages reflexion model rm techniques compare a highlevel model provided by the systems architects with the source code implementation there are also domainspecific languages with a focus on specifying and checking architectural constraints software architecture recovery software architecture recovery software architecture recovery or reconstruction or reverse engineering includes the methods techniques and processes to uncover a software systems architecture from available information including its implementation and documentation architecture recovery is often necessary to make informed decisions in the face of obsolete or outofdate documentation and architecture erosion implementation and maintenance decisions diverging from the envisioned architecture practices exist to recover software architecture as static program analysis this is a part of subjects covered by the software intelligence practice related fields design software design architecture is design but not all design is architectural in practice the architect is the one who draws the line between software architecture architectural design and detailed design nonarchitectural design there are no rules or guidelines that fit all cases although there have been attempts to formalize the distinction according to the intensionlocality hypothesis according to which a statement about software design is nonlocal architectural if and only if a program that satisfies it can be expanded into a program that does not for example the clientserver style is architectural strategic because a program that is built on this principle can be expanded into a program that is not clientserverfor example by adding peertopeer nodes requirements engineering requirements engineering requirements engineering and software architecture can be seen as complementary approaches while software architecture targets the solution space or the how requirements engineering addresses the problem space or the what requirements engineering entails the elicitation negotiation specification validation documentation and management of requirements both requirements engineering and software architecture revolve around stakeholder concerns needs and wishes 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 constrains etc are usually illdefined 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 aim to exploit the synergistic relation between requirements and architecture other types of architecture computer architecture systems architecture and enterprise architecture computer 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 systems architecture the term systems architecture has originally been applied to the architecture of systems that consists 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 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 topdown approach architectural pattern computer science antipattern attributedriven design computer architecture distributed data management architecture distributed relational database architecture systems architecture systems design software architecture analysis method timetriggered system paul clements felix bachmann len bass david garlan james ivers reed little paulo merson robert nord judith stafford documenting software architectures views and beyond second edition addisonwesley 2010 isbn0321552687 this book describes what is software architecture 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 len bass paul clements rick kazman software architecture in practice third edition addison wesley 2012 isbn0321815734 this book now in third edition eloquently covers the fundamental concepts of the discipline the theme is centered on achieving quality attributes of a system amnon h eden rick kazman architecture design implementation on the distinction between architectural design and detailed design javier garzs and mario piattini an ontology for microarchitectural design knowledge ieee software magazine volume 22 issue 2 marchapril 2005 pp28 33 philippe kruchten architectural blueprints the 41 view model of software architecture in ieee software 12 6 november 1995 pp4250 also available online at the rational website shan tony hua winnie october 2006 solution architecting mechanism proceedings of the 10th ieee international edoc enterprise computing conference 2332 doi101109edoc200654 isbn9780769525587cs1 maint date and year link martin fowler with ralph johnson who needs an architect ieee software julaug 2003 bell michael 2008 serviceoriented modeling service analysis design and architecture wiley asin0470141115cs1 maint asin uses isbn link wikimedia commons has media related to software architecture wikiquote has quotations related to software architecture explanation on ibm developerworks collection of software architecture definitions at software engineering institute sei carnegie mellon university cmu international association of it architects iasa global formerly known as the international association for software architects iasa softwarearchitectureportalorg website of ifip working group 210 on software architecture softwarearchitecturescom independent resource of information on the discipline software architecture chapter 1 of roy fieldings rest dissertation when good architecture goes bad the spiral architecture driven development the sdlc based on spiral model is to reduce the risks of ineffective architecture software architecture real life case studies vtesoftware engineeringfields computer programming requirements engineering software deployment software design software maintenance software testing systems analysis formal methods concepts data modeling enterprise architecture functional specification modeling language orthogonality programming paradigm software software archaeology software architecture software configuration management software development methodology software development process software quality software quality assurance software verification and validation structured analysis orientations agile aspectoriented object orientation ontology service orientation sdlc modelsdevelopmental agile eup executable uml incremental model iterative model prototype model rad up scrum spiral model vmodel waterfall model xp other spice cmmi data model er model function model information model metamodeling object model systems model view model languages idef uml usl sysml softwareengineers victor basili kent beck grady booch fred brooks barry boehm peter chen danese cooper ward cunningham tom demarco edsger w dijkstra delores m etter martin fowler adele goldstine margaret hamilton c a r hoare lois haibt mary jean harrold grace hopper watts humphrey michael a jackson ivar jacobson alan kay nancy leveson stephen j mellor bertrand meyer david parnas trygve reenskaug winston w royce james rumbaugh mary shaw peri tarr elaine weyuker niklaus wirth edward yourdon related fields computer science computer engineering project management risk management systems engineering category commons vteedsger dijkstranotable works a primer of algol 60 programming book structured programming book a discipline of programming book a method of programming book predicate calculus and program semantics book selected writings on computing a personal perspective book selected papers ewd manuscripts a note on two problems in connexion with graphs cooperating sequential processes solution of a problem in concurrent programming control the structure of the themultiprogramming system go to statement considered harmful notes on structured programming the humble programmer programming considered as a human activity how do we tell truths that might hurt on the role of scientific thought selfstabilizing systems in spite of distributed control on the cruelty of really teaching computer science main research areas theoretical computing science software engineering systems science algorithm design concurrent computing distributed computing formal methods programming methodology programming language research program design and development software architecture philosophy of computer programming and computing science scientific contributionsconcepts and methods algol 60 implementation call stack concurrency concurrent programming cooperating sequential processes critical section deadly embrace deadlock dining philosophers problem dutch national flag problem faulttolerant system gotoless programming guarded command language layered structure in software architecture levels of abstraction multithreaded programming mutual exclusion mutex producerconsumer problem bounded buffer problem program families predicate transformer semantics process synchronization selfstabilizing distributed system semaphore programming separation of concerns sleeping barber problem software crisis structured analysis structured programming the multiprogramming system unbounded nondeterminism weakest precondition calculus algorithms bankers algorithm dijkstras algorithm djp algorithm prims algorithm dijkstrascholten algorithm dekkers algorithm generalization smoothsort shuntingyard algorithm tricolor marking algorithm concurrent algorithms distributed algorithms deadlock prevention algorithms mutual exclusion algorithms selfstabilizing algorithms related people shlomi dolev per brinch hansen tony hoare olejohan dahl leslie lamport david parnas adriaan van wijngaarden niklaus wirth other topics dijkstra prize edsger w dijkstra prize in distributed computing centrum wiskunde informatica ew dijkstra archive university of texas at austin list of pioneers in computer science list of important publications in computer science list of important publications in theoretical computer science list of important publications in concurrent parallel and distributed computing international symposium on stabilization safety and security of distributed systems wikiquote authority control gnd 41216775 