Software architecture
48364
226114865
2008-07-16T21:51:47Z
128.194.146.134
The => These
{{Software development process}}
The '''software architecture''' of a program or computing system is the structure or structures of the [[software system|system]], which comprise software components, the externally visible properties of those components, and the relationships between them. The term also refers to documentation of a system's software architecture. Documenting software architecture facilitates communication between [[Stakeholder (general)|stakeholders]], documents early decisions about high-level design, and allows reuse of design components and patterns between projects.<ref>
{{cite book|last=Bass|first=Len|coauthors=Paul Clements, Rick Kazman|title=Software Architecture In Practice, Second Edition|publisher = Addison-Wesley|date=2003|location=Boston|pages=p. 21-24|id=ISBN 0-321-15495-9}}
</ref>
==Background==
The field of [[computer science]] has come across problems associated with complexity since its formation.<ref>{{cite web|author=University of Waterloo|title= A Very Brief History of Computer Science |url=http://www.cs.uwaterloo.ca/~shallit/Courses/134/history.html |date=2006|accessdate=2006-09-23}}</ref> 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 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.<ref>{{cite web|author=IEEE Transactions on Software Engineering|title= Introduction to the Special Issue on Software Architecture |url=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
|date=2006|accessdate=2006-09-23}}</ref> During the 1990’s there was a concentrated effort to define and codify fundamental aspects of the discipline. Initial sets of design patterns, styles, best practices, description languages, and formal logic were developed during that time.
{{Who|date=July 2008}}
The software architecture discipline is centered on the idea of reducing complexity through [[Abstraction (computer science)|abstraction]] and separation of concerns. To date there is still no agreement on the precise definition of the term “software architecture”.<ref>{{cite web|author=SEI|title= How do you define Software Architecture?|url= http://www.sei.cmu.edu/architecture/definitions.html |date=2006|accessdate=2006-09-23}}</ref>
As a maturing discipline with no clear rules on the right way to build a system, designing software architecture is still a mix of art and science. The “art” aspect of software architecture is because a commercial software system supports some aspect of a business or a mission. How a system supports key business drivers is described via scenarios as non-functional requirements of a system, also known as quality attributes, determine how a system will behave.<ref name="softwareqa">{{cite web|author=SoftwareArchitectures.com|title= Intro to Software Quality Attributes |url=http://www.softwarearchitectures.com/one/Designing+Architecture/78.aspx |date=2006|accessdate=2006-09-23}}</ref> Every system is unique due to the nature of the business drivers it supports, as such the degree of quality attributes exhibited by a system such as fault-tolerance, backward compatibility, extensibility, reliability, maintainability, availability, security, usability, and such other –ilities will vary with each implementation.<ref name="softwareqa"/>
To bring a software architecture user's perspective into the software architecture, it can be said that software architecture gives the direction to take steps and do the tasks involved in each such user's speciality area and interest e.g. the stake holders of software systems, the software developer, the software system operational support group, the software maintenance specialists, the deployer, the tester and also the business end user{{Fact|date=February 2007}}. In this sense software architecture is really the amalgamation of the multiple perspectives a system always embodies. The fact that those several different perspectives can be put together into a software architecture stands as the vindication of the need and justification of creation of software architecture before the software development in a project attains maturity.
==History==
The origin of software architecture as a concept was first identified in the research work 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<ref>{{cite web|author=SEI|title= Origins of Software Architecture Study |url= http://www.sei.cmu.edu/architecture/roots.html |date=2006|accessdate=2006-09-25}}</ref>. The study of the field increased in popularity since the early 1990s with research work concentrating on architectural styles ([[patterns]]), architecture description languages, architecture documentation, and formal methods<ref>{{cite web|author=Garlan & Shaw |title= An Introduction to Software Architecture |url= http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf |date=1994|accessdate=2006-09-25}}</ref>.
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 brought forward the concepts in Software Architecture, such as [[software component|components]], connectors, styles and so on. 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|ANSI/IEEE 1471-2000: Recommended Practice for Architecture Description of Software-Intensive Systems]]'' is the first formal standard in the area of software architecture, and was recently adopted by ISO as ''[[IEEE 1471|ISO/IEC DIS 25961]]''.
== Describing architectures ==
===Architecture description languages===
[[Architecture description language]]s (ADLs) are used to describe a Software Architecture. Several different ADLs have been developed by different organizations, including [[Architecture analysis and design language|AADL]] (SAE standard), [[Wright (ADL)|Wright]] (developed by Carnegie Mellon), [[Acme (ADL)|Acme]] (developed by Carnegie Mellon), xADL (developed by UCI), [[Darwin (ADL)|Darwin]] (developed by [[Imperial College London]]), DAOP-ADL (developed by University of Málaga). Common elements of an ADL are [[software component|component]], connector and configuration.
===Views===
Software architecture is commonly organized in views<ref name="documenting">{{cite book
| last = Clements
| first = Paul
| coauthors = Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, Judith Stafford
| title = Documenting Software Architectures: Views and Beyond
| publisher = Addison-Wesley
| date = 2003
| location = Boston
| pages = pp. 13-15
| id = ISBN 0-201-70372-6 }}</ref>, which are analogous to the different types of [[blueprint]]s made in building [[architecture]].
Within the ontology established by [[Ieee 1471|ANSI/IEEE 1471-2000]], ''views'' are instances of ''viewpoints'', where a viewpoint exists to describe the architecture in question from the perspective of a given set of stakeholders and their concerns.
Some possible views (actually, ''viewpoints'' in the 1471 ontology) are:
*Functional/logic view
*Code/module view
*Development/structural view
*Concurrency/process/thread view
*Physical/deployment view
*User action/feedback view
*Data view
Several languages for describing software architectures have been devised, but no consensus has yet been reached on which symbol-set and view-system should be adopted. The [[Unified Modeling Language|UML]] was established as a [[Standardization|standard]] ''"to model systems (and not just software),"'' and thus applies to views about software architecture. Others believe that effective development of software relies on understanding unique constraints of each problem, and so universal notations are doomed because each provides a [[notational bias]] that necessarily makes the notation useless or dangerous for some set of tasks{{Fact|date=February 2007}}. They point to the proliferation of [[programming language]]s and a succession of failed attempts to impose a single 'universal language' on programmers, as proof that software thrives on diversity and not on standards.
===Architecture frameworks===
{{Expand-section|date=June 2008}}
*[[4+1]]
*[[Department of Defense Architecture Framework]] (DODAF)
*[[MODAF|UK Ministry of Defence Architectural Framework]] (MODAF)
*[[TOGAF|The Open Group Architecture Framework]] (TOGAF)
*[[Zachman framework]]
*[[Federal Enterprise Architecture]]
*[[RM-ODP|Reference Model of Open Distributed Processing]] (RM-ODP)
*[[Service-Oriented Modeling]] Framework (SOMF)
===The distinction from detailed design===
Software architecture, also described as strategic design, is an activity concerned with global design constraints, such as [[programming paradigms]], architectural styles, [[component-based software engineering]] standards, design principles, and law-governed regularities. Detailed design, also described as tactical design, is an activity concerned with local design constraints, such as [[design patterns]], [[Architectural pattern (computer science)|architectural patterns]], [[programming idioms]], and [[refactorings]]. According to the [[Intension/Locality Hypothesis]], the distinction between strategic and tactical design is defined by the Locality Criterion, according to which a statement about software design is non-local if and only if a program that satisfies it can be expanded into a program which does not. For example, the [[Client-Server]] style is architectural (strategic) because a program that is built by this principle can be expanded into a program which is not client server; for example, by adding [[peer-to-peer]] nodes.
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 (non-architectural design). There aren't rules or guidelines that fit all cases.
==Examples of Architectural Styles / Patterns==<!-- This section is linked from [[Abstraction (computer science)]] -->
There are many common ways of designing computer software modules and their communications, among them:
*[[Blackboard (computing)|Blackboard]]
*[[Client-server]]
*[[Database-centric architecture]]
*[[Distributed computing]]
*[[Event Driven Architecture]]
*[[Implicit invocation]]
*[[Monolithic application]]
*[[Peer-to-peer]]
*[[Pipes and filters]]
*[[Plugin]]
*[[Representational State Transfer]]
*[[Structured Systems Analysis and Design Methodology|Structured]] (module-based but usually monolithic within modules)
*[[Software componentry]] (strictly module-based, usually [[object-oriented programming]] within modules, slightly less monolithic)
*[[Service-oriented architecture]]
*[[Search-oriented architecture]]
*[[Space based architecture]]
*[[Shared nothing architecture]]
*[[Three-tier (computing)|Three-tier model]]
==See also==
*[[Computer architecture]]
*[[Architecture Tradeoff Analysis Method|Architecture Tradeoff Analysis Method (ATAM)]] - an architecture evaluation method.
*[[Dependency Structure Matrix]]
*[[Enterprise architecture]]
*[[Process architecture]]
*[[Software antipatterns]]
*[[Software architect]]
*[[Software Architectural Model]]
*[[Software design pattern]]s
*[[Software design]]
*[[Software system]]
*[[Standard data model]]s
*[[Systems architecture]] / [[Systems architect]]
*[[Systems design]]
*[[Technical architecture]]
*[[Service-Oriented Modeling]] Framework (SOMF)
*[[Common layers in an information system logical architecture]]
==References==
{{reflist}}
== Further reading ==
*Len Bass, Paul Clements, Rick Kazman: ''Software Architecture in Practice, Second Edition''. Addison Wesley, Reading 5/9/2003 ISBN 0-321-15495-9 (This book, now in second edition, eloquently covers the fundamental concepts of the discipline. The theme is centered around achieving quality attributes of a system.)
* Tony Shan and Winnie Hua (2006). [http://doi.ieeecomputersociety.org/10.1109/EDOC.2006.54 ''Solution Architecting Mechanism'']. Proceedings of the 10th IEEE International EDOC Enterprise Computing Conference (EDOC 2006), October 2006, p23-32.
* [[Javier Garzás|Garzás, Javier]], and [[Mario Piattini|Piattini, Mario]]. An ontology for micro-architectural design knowledge, [[IEEE Software]] Magazine, Volume: 22, Issue: 2, March-April 2005. pp. 28 – 33.
*Philippe Kruchten: ''Architectural Blueprints - the 4+1 View Model of Software Architecture''. In: IEEE Software. 12 (6) November 1995, pp. 42-50 (also available online at the [http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf Rational website](PDF))
*Amnon H. Eden, Rick Kazman. [http://www.eden-study.org/articles/2003/icse03.pdf ''Architecture, Design, Implementation.''] On the distinction between architectural design and detailed design.
* {{cite web
| last = SOMF: Bell
| first = Michael
| year = 2008
| url = http://www.amazon.com/Service-Oriented-Modeling-Service-Analysis-Architecture/dp/0470141115/ref=pd_bbs_2
| title = Service-Oriented Modeling: Service Analysis, Design, and Architecture
| publisher = Wiley
}}
==External links==
*Collection of [http://www.sei.cmu.edu/architecture/definitions.html software architecture definitions] at Software Engineering Institute (SEI), Carnegie Mellon University (CMU)
*[http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf Software architecture vs. software design: The Intension/Locality Hypothesis]
*[http://www.wwisa.org/ Worldwide Institute of Software Architects (WWISA)]
*[http://www.iasahome.org/iasaweb/appmanager/home/home/ International Association of Software Architects (IASA)]
*[http://www.softwarearchitectureportal.org/ SoftwareArchitecturePortal.org] — website of IFIP Working Group 2.10 on Software Architecture
*[http://www.softwarearchitectures.com/ SoftwareArchitectures.com] — independent resource of information on the discipline
*[http://www.architecturejournal.net/ Microsoft Architecture Journal]
*[http://msdn.microsoft.com/en-us/arcjournal/cc505970.aspx/ Becoming an Architect]
*[http://www.jools.net/archives/44 Architectural Patterns]
[[Category:Software architecture| ]]
[[Category:Information science]]
[[Category:Software systems]]
[[da:It-arkitektur]]
[[de:Softwarearchitektur]]
[[es:Arquitectura de software]]
[[fa:معماری نرمافزار]]
[[fr:Architecture logicielle]]
[[gl:Arquitectura software]]
[[id:Arsitektur perangkat lunak]]
[[he:ארכיטקטורת תוכנה]]
[[ja:ソフトウェアアーキテクチャ]]
[[pt:Arquitetura de software]]
[[ru:Архитектура программного обеспечения]]
[[fi:Tietojärjestelmäarkkitehtuuri]]
[[vi:Kiến trúc phần mềm]]
[[zh:软件架构]]