Wikibooks

Introduction to Software Engineering/Architecture

< Introduction to Software Engineering
This page may need to be reviewed for quality.

Introduction

edit

When you build your house, you would never think about building it without an architect, correct? However, many medium to large size software projects are built without a software architect. That seems kind of scary, and you might wonder why? Well, the role of the software architect has neither been widely understood, nor his necessity been acknowledged. Even to date there is still no agreement on the precise definition of the term “software architecture”.[1]

Matthew R. McBride writes, "a software architect is a technically competent system-level thinker, guiding planned and efficient design processes to bring a system into existence. He is viewed by customers and developers alike as a technical expert. The architect is the author of the solution, accountable for its success or failure." [2] The term software architecture 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.[3]

Architecture and Design

edit

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.

Architecture is design but not all design is architectural.[4] 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.

Software Architecture

edit

The field of computer science has come across problems associated with complexity since its formation.[5] 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.[6] 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.

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.[7] 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.[7]

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[8].

Views and UML

edit

Although there exist 'architecture description languages' (see below), no consensus exists on which symbol-set or language should be used. However, as already indicated above, UML is a standard used regularly by architects. For instance, UML component, deployment, and package diagrams generally appear in software architecture documents. Thus, the UML is a visual language that is often being used to create software architecture views.

Software architecture views 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. [4] Some possible views 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

Architecture Frameworks

edit

There are several architecture frameworks related to the domain of software architecture, most well known being the '4+1' model. Also the Reference Model of Open Distributed Processing (RM-ODP) and the Service-Oriented Modeling Framework (SOMF) are being used. Other architectures such as the Zachman Framework, DODAF, and TOGAF relate to the field of Enterprise architecture.

Architecture Description Languages

edit

Several languages for describing software architectures ('architecture description language' (ADL) in ISO/IEC 42010 / IEEE-1471 terminology) have been devised. 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.


References

edit
  1. ↑ SEI (2006). "How do you define Software Architecture?". Retrieved 2006-09-23.
  2. ↑ McBride, Matthew R. (2004). The software architect: essence, intuition, and guiding principles. New York: ACM. pp. 230–235. ISBN 1-58113-833-4.
  3. ↑ Bass, Len (2003). Software Architecture In Practice, Second Edition. Boston: Addison-Wesley. pp. 21–24. ISBN 0-321-15495-9. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  4. ↑ a b Clements, Paul (2010). Documenting Software Architectures: Views and Beyond, Second Edition. Boston: Addison-Wesley. ISBN 0321552687. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  5. ↑ University of Waterloo (2006). "A Very Brief History of Computer Science". Retrieved 2006-09-23.
  6. ↑ IEEE Transactions on Software Engineering (2006). "Introduction to the Special Issue on Software Architecture". Retrieved 2006-09-23.
  7. ↑ a b SoftwareArchitectures.com (2006). "Intro to Software Quality Attributes". Retrieved 2006-09-23.
  8. ↑ Garlan & Shaw (1994). "An Introduction to Software Architecture" (PDF). Retrieved 2006-09-25.

Further Reading

edit
  • 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.
  • 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 (IEEE 1471).
edit
Retrieved from "https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Architecture"