Vitruvius said architecture encompasses firmness, commodity and delight. In that order. Firmness meant that it has to be substantial and sound. A building that falls down is no good to anyone. Commodity meant that it had to serve a purpose and have value. Enclosing space for no purpose isn't architecture, it's only sculpture. Finally, it has to have beauty and bring pleasure. The first two requirements must be met before the third has any meaning.
Less is more. Even though actually less is a bore, and often yes is more, once you work through those iterations you generally come back to less being more.
The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.[1] The term also refers to documentation of a system's "software architecture." Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.[2]
Contents [hide]
1 Overview
2 History
3 Software architecture topics
3.1 Architecture description languages
3.2 Views
3.3 Architecture frameworks
3.4 The distinction from functional design
4 Examples of architectural styles and patterns
5 See also
6 References
7 Further reading
8 External links
[edit]Overview
The field of computer science has come across problems associated with complexity since its formation.[3] 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.[4] During the 1990s 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.
The software architecture discipline is centered on the idea of reducing complexity through abstraction and separation of concerns. To date there is still no agreement on the precise definition of the term “software architecture”.[5] However, this does not mean that individuals do not have their own definition of what software architecture is. This leads to problems because many people are using the same terms to describe differing ideas.
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.[6] This could be thought of as a parallel to a mission statement and value system in business strategy. 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.[6] 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 specialty area and interest e.g. the stakeholders 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[citation needed]. 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.
[edit]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. 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.[7]
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 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.
The 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 adopted in 2007 by ISO as ISO/IEC 42010:2007.
[edit]Software architecture topics
[edit]Architecture description languages
Architecture description languages (ADLs) are used to describe a Software Architecture. Several different ADLs have been developed by different organizations, including AADL (SAE standard), Wright (developed by Carnegie Mellon), Acme (developed by Carnegie Mellon), xADL (developed by UCI), Darwin (developed by Imperial College London), DAOP-ADL (developed by University of Málaga), and ByADL (University of L'Aquila, Italy). Common elements of an ADL are component, connector and configuration.
[edit]Views
Software architecture is commonly organized in views, which are analogous to the different types of blueprints made in building architecture. A view is a representation of a set of system components and relationships among them.[1] Within the ontology established by ANSI/IEEE 1471-2000, views are responses to viewpoints, where a viewpoint is a specification that describes the architecture in question from the perspective of a given set of stakeholders and their concerns. The viewpoint specifies not only the concerns addressed but the presentation, model kinds used, conventions used and any consistency (correspondence) rules to keep a view consistent with other views.
Some possible views (actually, viewpoints in the 1471 ontology) are:
Functional/logic view
Code/module view
Development/structural view
Concurrency/process/runtime/thread view
Physical/deployment/install view
User action/feedback view
Data view/data model
Several languages for describing software architectures ('architecture description language' in ISO/IEC 42010 / IEEE-1471 terminology) have been devised, but no consensus exists on which symbol-set or language should be used to describe each architecture view. The UML is a standard that can be used "for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes." Thus, the UML is a visual language that can be used to create software architecture.
[edit]Architecture frameworks
Frameworks related to the domain of software architecture are:
4+1
RM-ODP (Reference Model of Open Distributed Processing)
Service-Oriented Modeling Framework (SOMF)
Other architectures such as the Zachman Framework, DODAF, and TOGAF relate to the field of Enterprise architecture.
[edit]The distinction from functional design
The IEEE Std 610.12-1990 Standard Glossary of Software Engineering Terminology defines the following distinctions:
Architectural Design: the process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system.
Detailed Design: the process of refining and expanding the preliminary design of a system or component to the extent that the design is sufficiently complete to begin implementation.
Functional Design: the process of defining the working relationships among the components of a system.
Preliminary Design: the process of analyzing design alternatives and defining the architecture, components, interfaces, and timing/sizing estimates for a system or components.
Software architecture, also described as strategic design, is an activity concerned with global requirements governing how a solution is implemented such as programming paradigms, architectural styles, component-based software engineering standards, architectural patterns, security, scale, integration, and law-governed regularities. Functional design, also described as tactical design, is an activity concerned with local requirements governing what a solution does such as algorithms, design patterns, programming idioms, refactorings, and low-level implementation.
According to the Intension/Locality Hypothesis,[8] the distinction between architectural and detailed design is defined by the Locality Criterion,[8] 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 which 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 which is not client–server; for example, by adding peer-to-peer nodes.
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 aren't rules or guidelines that fit all cases. Examples of rules or heuristics that architects (or organizations) can establish when they want to distinguish between architecture and detailed design include:
Architecture is driven by non-functional requirements, while functional design is driven by functional requirements.
Pseudo-code belongs in the detailed design document.
UML component, deployment, and package diagrams generally appear in software architecture documents; UML class, object, and behavior diagrams appear in detailed functional design documents.
[edit]Examples of architectural styles and patterns
There are many common ways of designing computer software modules and their communications, among them:
Blackboard
Client–server model (2-tier, n-tier, Peer-to-peer, cloud computing all use this model)
Database-centric architecture (broad division can be made for programs which have database at its center and applications which don't have to rely on databases, E.g. desktop application programs, utility programs etc.)
Distributed computing
Event-driven architecture
Front end and back end
Implicit invocation
Monolithic application
Peer-to-peer
Pipes and filters
Plug-in (computing)
Representational State Transfer
Rule evaluation
Search-oriented architecture (A pure SOA implements a service for every data access point.)
Service-oriented architecture
Shared nothing architecture
Software componentry
Space based architecture
Structured (module-based but usually monolithic within modules)
Three-tier model (An architecture with Presentation, Business Logic and Database tiers)
[edit]See also
Architectural pattern (computer science)
Anti-pattern
Architecture Centric Design Method
Architecture Tradeoff Analysis Method (ATAM)
Common layers in an information system logical architecture
Computer architecture
Dependency Structure Matrix
Enterprise architecture
Process architecture
Software architect
Software Architectural Model
Software design
Software design pattern
Software framework
Software system
Standard data model
Systems architect
Systems architecture
Systems design
Technical architecture
Software Architecture Analysis Method
[edit]References
^ a b c 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. ISBN 0321552687.
^ Bass, Len; Paul Clements, Rick Kazman (2003). Software Architecture In Practice, Second Edition. Boston: Addison-Wesley. pp. 21–24. ISBN 0-321-15495-9.
^ University of Waterloo (2006). "A Very Brief History of Computer Science". Retrieved 2006-09-23.
^ IEEE Transactions on Software Engineering (2006). "Introduction to the Special Issue on Software Architecture". Retrieved 2006-09-23.
^ SEI (2006). "How do you define Software Architecture?". Retrieved 2006-09-23.
^ a b SoftwareArchitectures.com (2006). "Intro to Software Quality Attributes". Retrieved 2006-09-23.
^ Garlan & Shaw (1994). "An Introduction to Software Architecture". Retrieved 2006-09-25.
^ a b Amnon H. Eden, Rick Kazman (2003). "Architecture Design Implementation".
[edit]Further reading
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. Addison-Wesley, 2010, ISBN 0321552687. 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, 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.)
Amnon H. Eden, Rick Kazman. Architecture, Design, Implementation. On the distinction between architectural design and detailed design.
Garzás, Javier, and 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 Rational website(PDF))
Tony Shan and Winnie Hua (2006). Solution Architecting Mechanism. Proceedings of the 10th IEEE International EDOC Enterprise Computing Conference (EDOC 2006), October 2006, p23-32
SOMF: Bell, Michael (2008). "Service-Oriented Modeling: Service Analysis, Design, and Architecture". Wiley.
[edit]External links
Excellent explanation on IBM Developerworks
Collection of software architecture definitions at Software Engineering Institute (SEI), Carnegie Mellon University (CMU)
Software architecture vs. software design: The Intension/Locality Hypothesis
International Association of Software Architects (IASA)
SoftwareArchitecturePortal.org — website of IFIP Working Group 2.10 on Software Architecture
Software Architecture — practical resources for Software Architects
SoftwareArchitectures.com — independent resource of information on the discipline
Microsoft Architecture Journal
Architectural Patterns
Software Architecture, chapter 1 of Roy Fielding's REST dissertation
DiaSpec, an approach and tool to generate a distributed framework from a software architecture
When Good Architecture Goes Bad
Software Architecture and Related Concerns, What is Software Architecture? And What Software Architecture Is Not
Handbook of Software Architecture
The Spiral Architecture Driven Development - the SDLC based on Spiral model is to reduce the risks of ineffective architecture
Rationale focused software architecture documentation method
[hide] v d e
Software engineering
Fields
Requirements analysis Systems analysis Software design Computer programming Formal methods Software testing Software deployment Software maintenance
Concepts
Data modeling Enterprise architecture Functional specification Modeling language Programming paradigm Software Software architecture Software development methodology Software development process Software quality Software quality assurance Software archaeology Structured analysis
Orientations
Agile Aspect-oriented Object orientation Ontology Service orientation SDLC
Models
Development models
Agile Iterative model RUP Scrum Spiral model Waterfall model XP V-Model Incremental model Prototype model
Other models
Automotive SPICE CMMI Data model Function model Information model Metamodeling Object model Systems model View model
Modeling languages
IDEF UML
Software
engineers
Kent Beck Grady Booch Fred Brooks Barry Boehm Ward Cunningham Ole-Johan Dahl Tom DeMarco Martin Fowler C. A. R. Hoare Watts Humphrey Michael A. Jackson Ivar Jacobson Craig Larman James Martin Bertrand Meyer David Parnas Winston W. Royce Colette Rolland James Rumbaugh Niklaus Wirth Edward Yourdon Victor Basili
Related fields
Computer science Computer engineering Enterprise engineering History Management Project management Quality management Software ergonomics Systems engineering
How do you define architecture?
In a better fashion to live along with the surrounding eco-logy.
Any man-made building or structure.
A creative or significant man-made building.
A building style or method.
Vitruvius said architecture encompasses firmness, commodity and delight. In that order. Firmness meant that it has to be substantial and sound. A building that falls down is no good to anyone. Commodity meant that it had to serve a purpose and have value. Enclosing space for no purpose isn't architecture, it's only sculpture. Finally, it has to have beauty and bring pleasure. The first two requirements must be met before the third has any meaning.
Those dudes who design computer stuff, right?
Less is more. Even though actually less is a bore, and often yes is more, once you work through those iterations you generally come back to less being more.
How do I define architecture? Like this.
The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.[1] The term also refers to documentation of a system's "software architecture." Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.[2]
Contents [hide]
1 Overview
2 History
3 Software architecture topics
3.1 Architecture description languages
3.2 Views
3.3 Architecture frameworks
3.4 The distinction from functional design
4 Examples of architectural styles and patterns
5 See also
6 References
7 Further reading
8 External links
[edit]Overview
The field of computer science has come across problems associated with complexity since its formation.[3] 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.[4] During the 1990s 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.
The software architecture discipline is centered on the idea of reducing complexity through abstraction and separation of concerns. To date there is still no agreement on the precise definition of the term “software architecture”.[5] However, this does not mean that individuals do not have their own definition of what software architecture is. This leads to problems because many people are using the same terms to describe differing ideas.
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.[6] This could be thought of as a parallel to a mission statement and value system in business strategy. 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.[6] 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 specialty area and interest e.g. the stakeholders 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[citation needed]. 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.
[edit]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. 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.[7]
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 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.
The 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 adopted in 2007 by ISO as ISO/IEC 42010:2007.
[edit]Software architecture topics
[edit]Architecture description languages
Architecture description languages (ADLs) are used to describe a Software Architecture. Several different ADLs have been developed by different organizations, including AADL (SAE standard), Wright (developed by Carnegie Mellon), Acme (developed by Carnegie Mellon), xADL (developed by UCI), Darwin (developed by Imperial College London), DAOP-ADL (developed by University of Málaga), and ByADL (University of L'Aquila, Italy). Common elements of an ADL are component, connector and configuration.
[edit]Views
Software architecture is commonly organized in views, which are analogous to the different types of blueprints made in building architecture. A view is a representation of a set of system components and relationships among them.[1] Within the ontology established by ANSI/IEEE 1471-2000, views are responses to viewpoints, where a viewpoint is a specification that describes the architecture in question from the perspective of a given set of stakeholders and their concerns. The viewpoint specifies not only the concerns addressed but the presentation, model kinds used, conventions used and any consistency (correspondence) rules to keep a view consistent with other views.
Some possible views (actually, viewpoints in the 1471 ontology) are:
Functional/logic view
Code/module view
Development/structural view
Concurrency/process/runtime/thread view
Physical/deployment/install view
User action/feedback view
Data view/data model
Several languages for describing software architectures ('architecture description language' in ISO/IEC 42010 / IEEE-1471 terminology) have been devised, but no consensus exists on which symbol-set or language should be used to describe each architecture view. The UML is a standard that can be used "for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes." Thus, the UML is a visual language that can be used to create software architecture.
[edit]Architecture frameworks
Frameworks related to the domain of software architecture are:
4+1
RM-ODP (Reference Model of Open Distributed Processing)
Service-Oriented Modeling Framework (SOMF)
Other architectures such as the Zachman Framework, DODAF, and TOGAF relate to the field of Enterprise architecture.
[edit]The distinction from functional design
The IEEE Std 610.12-1990 Standard Glossary of Software Engineering Terminology defines the following distinctions:
Architectural Design: the process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system.
Detailed Design: the process of refining and expanding the preliminary design of a system or component to the extent that the design is sufficiently complete to begin implementation.
Functional Design: the process of defining the working relationships among the components of a system.
Preliminary Design: the process of analyzing design alternatives and defining the architecture, components, interfaces, and timing/sizing estimates for a system or components.
Software architecture, also described as strategic design, is an activity concerned with global requirements governing how a solution is implemented such as programming paradigms, architectural styles, component-based software engineering standards, architectural patterns, security, scale, integration, and law-governed regularities. Functional design, also described as tactical design, is an activity concerned with local requirements governing what a solution does such as algorithms, design patterns, programming idioms, refactorings, and low-level implementation.
According to the Intension/Locality Hypothesis,[8] the distinction between architectural and detailed design is defined by the Locality Criterion,[8] 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 which 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 which is not client–server; for example, by adding peer-to-peer nodes.
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 aren't rules or guidelines that fit all cases. Examples of rules or heuristics that architects (or organizations) can establish when they want to distinguish between architecture and detailed design include:
Architecture is driven by non-functional requirements, while functional design is driven by functional requirements.
Pseudo-code belongs in the detailed design document.
UML component, deployment, and package diagrams generally appear in software architecture documents; UML class, object, and behavior diagrams appear in detailed functional design documents.
[edit]Examples of architectural styles and patterns
There are many common ways of designing computer software modules and their communications, among them:
Blackboard
Client–server model (2-tier, n-tier, Peer-to-peer, cloud computing all use this model)
Database-centric architecture (broad division can be made for programs which have database at its center and applications which don't have to rely on databases, E.g. desktop application programs, utility programs etc.)
Distributed computing
Event-driven architecture
Front end and back end
Implicit invocation
Monolithic application
Peer-to-peer
Pipes and filters
Plug-in (computing)
Representational State Transfer
Rule evaluation
Search-oriented architecture (A pure SOA implements a service for every data access point.)
Service-oriented architecture
Shared nothing architecture
Software componentry
Space based architecture
Structured (module-based but usually monolithic within modules)
Three-tier model (An architecture with Presentation, Business Logic and Database tiers)
[edit]See also
Architectural pattern (computer science)
Anti-pattern
Architecture Centric Design Method
Architecture Tradeoff Analysis Method (ATAM)
Common layers in an information system logical architecture
Computer architecture
Dependency Structure Matrix
Enterprise architecture
Process architecture
Software architect
Software Architectural Model
Software design
Software design pattern
Software framework
Software system
Standard data model
Systems architect
Systems architecture
Systems design
Technical architecture
Software Architecture Analysis Method
[edit]References
^ a b c 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. ISBN 0321552687.
^ Bass, Len; Paul Clements, Rick Kazman (2003). Software Architecture In Practice, Second Edition. Boston: Addison-Wesley. pp. 21–24. ISBN 0-321-15495-9.
^ University of Waterloo (2006). "A Very Brief History of Computer Science". Retrieved 2006-09-23.
^ IEEE Transactions on Software Engineering (2006). "Introduction to the Special Issue on Software Architecture". Retrieved 2006-09-23.
^ SEI (2006). "How do you define Software Architecture?". Retrieved 2006-09-23.
^ a b SoftwareArchitectures.com (2006). "Intro to Software Quality Attributes". Retrieved 2006-09-23.
^ Garlan & Shaw (1994). "An Introduction to Software Architecture". Retrieved 2006-09-25.
^ a b Amnon H. Eden, Rick Kazman (2003). "Architecture Design Implementation".
[edit]Further reading
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. Addison-Wesley, 2010, ISBN 0321552687. 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, 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.)
Amnon H. Eden, Rick Kazman. Architecture, Design, Implementation. On the distinction between architectural design and detailed design.
Garzás, Javier, and 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 Rational website(PDF))
Tony Shan and Winnie Hua (2006). Solution Architecting Mechanism. Proceedings of the 10th IEEE International EDOC Enterprise Computing Conference (EDOC 2006), October 2006, p23-32
SOMF: Bell, Michael (2008). "Service-Oriented Modeling: Service Analysis, Design, and Architecture". Wiley.
[edit]External links
Excellent explanation on IBM Developerworks
Collection of software architecture definitions at Software Engineering Institute (SEI), Carnegie Mellon University (CMU)
Software architecture vs. software design: The Intension/Locality Hypothesis
International Association of Software Architects (IASA)
SoftwareArchitecturePortal.org — website of IFIP Working Group 2.10 on Software Architecture
Software Architecture — practical resources for Software Architects
SoftwareArchitectures.com — independent resource of information on the discipline
Microsoft Architecture Journal
Architectural Patterns
Software Architecture, chapter 1 of Roy Fielding's REST dissertation
DiaSpec, an approach and tool to generate a distributed framework from a software architecture
When Good Architecture Goes Bad
Software Architecture and Related Concerns, What is Software Architecture? And What Software Architecture Is Not
Handbook of Software Architecture
The Spiral Architecture Driven Development - the SDLC based on Spiral model is to reduce the risks of ineffective architecture
Rationale focused software architecture documentation method
[hide] v d e
Software engineering
Fields
Requirements analysis Systems analysis Software design Computer programming Formal methods Software testing Software deployment Software maintenance
Concepts
Data modeling Enterprise architecture Functional specification Modeling language Programming paradigm Software Software architecture Software development methodology Software development process Software quality Software quality assurance Software archaeology Structured analysis
Orientations
Agile Aspect-oriented Object orientation Ontology Service orientation SDLC
Models
Development models
Agile Iterative model RUP Scrum Spiral model Waterfall model XP V-Model Incremental model Prototype model
Other models
Automotive SPICE CMMI Data model Function model Information model Metamodeling Object model Systems model View model
Modeling languages
IDEF UML
Software
engineers
Kent Beck Grady Booch Fred Brooks Barry Boehm Ward Cunningham Ole-Johan Dahl Tom DeMarco Martin Fowler C. A. R. Hoare Watts Humphrey Michael A. Jackson Ivar Jacobson Craig Larman James Martin Bertrand Meyer David Parnas Winston W. Royce Colette Rolland James Rumbaugh Niklaus Wirth Edward Yourdon Victor Basili
Related fields
Computer science Computer engineering Enterprise engineering History Management Project management Quality management Software ergonomics Systems engineering
Oh, Miles. That hurts.
http://vimeo.com/3248803
Block this user
Are you sure you want to block this user and hide all related comments throughout the site?
Archinect
This is your first comment on Archinect. Your comment will be visible once approved.