Software architecture

from Wikipedia, the free encyclopedia

A software architecture is one of the architecture types in computer science and describes the basic components and their interaction within a software system .

definition

A definition by Helmut Balzert describes the term as “a structured or hierarchical arrangement of the system components and a description of their relationships”. The architecture components form a breakdown of the overall system, which means that each software element is assigned to exactly one architecture component.

Paul Clements describes software architecture as "the structures of a software system: software parts, the relationships between them and the properties of the software parts and their relationships".

The software architecture is part of the software design (see SWEBOK ), within which it arises as a rough breakdown of the components. While software design also relates to local aspects within the architectural framework of the software and can therefore be very detailed, the software architecture is a global property of the overall system.

Classification and demarcation

In the context of software development , the software architecture represents the earliest software design decision (architecture draft). It is essentially determined by software quality criteria , i.e. non-functional properties such as modifiability , maintainability , security or performance (see for example FURPS ). A software architecture that has been set up can only be changed later with great effort. The decision about its design is therefore one of the most critical and important points in the software development process.

In its economic perspective, a software architecture is very dependent on surrounding aspects. Therefore, in order to function successfully, a software architecture needs a suitable coordination with the other most important factors of the software project. For users and developers of the software project, a well-designed software architecture easily gives a basic understanding of the system. Important factors that influence the suitability of the software architecture are project planning , risk analysis , organization , development process , work processes , hardware , quality assurance and requirements .

example

Wikimedia server architecture diagram

In the case of a web application, for example, an architecture description includes the structure of the system from databases, web / application servers, e-mail and cache systems - see Wikipedia itself.

history

Beginnings (1960–1990)

The beginnings of describing and using an explicit software architecture go back to the 1960s, when the first larger software systems emerged. The complexity of the systems (e.g. OS / 360 ) made it necessary to distribute the implementation tasks to different teams and to define interfaces . The term "software architecture" was first mentioned in the proceedings of a NATO-funded conference on software technology in 1969 in Rome. Visitors to this conference were numerous IT pioneers, such as B. Tony Hoare , Edsger W. Dijkstra , Alan Perlis , Per Brinch Hansen , Friedrich L. Bauer , and Niklaus Wirth .

In the 1970s and 1980s, the word “architecture” in IT was often used in connection with system architectures (ie physical computer system structures) or specifically referred to processor families. In 1972 David Parnas published an influential article on criteria for module decomposition of software systems. Although he did not use the term "software architecture", he anticipated some of the later concepts and ideas for software architecture. In 1975 the book The Mythical Man Month by Frederick P. Brooks was published , in which key concepts for the design and organization of software systems were discussed. Further articles by Parnas and Brooks in the 1980s deepened these ideas and concepts.

Establishment (1990-2000)

Software architecture only became an independent branch of software technology in the 1990s . In 1992, Dewayne Perry and Alexander Wolf published a seminal article called Foundations for the Study of Software Architecture . In it they introduced the formula “elements + form + justification = software architecture”. Many researchers interpreted "elements" as software components and connectors. As a result, a number of architecture description languages (C2, Rapide, Darwin, Wright, ACME, Unicon) emerged at various universities , which, however, were hardly used industrially.

From 1995 the software architecture gained increasing importance in both industrial and academic environments. The Software Engineering Institute (SEI) in Pittsburgh published the Software Architecture Analysis Method (SAAM). The concept of architectural views was reflected in various approaches such as Rationals “4 + 1 views” or Siemens “Four views”. In 1996 the book Pattern-oriented Software Architecture was published , which transferred the concept of design patterns to software architectures . Siemens, Nokia, Philips, Nortel, Lockheed Martin, IBM and other major software companies used software architecture to make software more reusable and designed software product lines . In 1999, the first international conference (WICSA 1) specifically on the subject of software architecture took place in the USA.

Current (2000-today)

In 2000, the IEEE 1471 : 2000 standard Recommended Practice for Architectural Description of Software-Intensive Systems was published for describing the architecture of software systems. In the same year, Bill Gates, one of the most prominent people in the IT sector, took over the title of Chief Software Architect at Microsoft . The SEI developed the scenario-based architecture evaluation method Architecture Trade-off Analysis Method (ATAM), which was subsequently used in numerous industrial projects. The Unified Modeling Language (UML) from version 2.0 from 2003 is also suitable for the documentation of software architectures. In 2003 the now most cited book on software architecture ( Software Architecture in Practice ) was published and emphasized the importance of quality attributes for the design and evaluation of software architectures.

In Germany, the International Software Architect Qualification Board (iSAQB), an association of German IT companies, has been awarding certificates for software architects since 2003 . By 2013 more than 3000 software architects had been certified according to CPSA-F (Foundation Level). In 2004 a working group of the Society for Computer Science was founded on the subject of software architecture and in 2006 published the manual of software architecture . In 2006, a permanent GI specialist group emerged from the temporary working group.

Current practical topics are e.g. B. software architectures for cloud computing , multi-core processors and mobile devices , as well as service-oriented architectures . Current research topics in the field of software architecture include: B. Knowledge management for software architectures, model-based analysis methods and software product lines .

In agile software development projects , evolutionary software architecture and emergent design are increasingly being used in contrast to previously defined architecture ("Big Design Up Front"). Techniques such as behavior-driven development , test-driven development and, above all, refactoring should ensure that the technical design and architecture are constantly adapted to the requirements in the course of a software development project.

description

The description of a software architecture contains information about the structure ("componentization") of a software system, but also information about the communication between components, as well as their mapping to hardware or software resources (distribution and deployment).

A software architecture can have different characteristics:

  • In a functional architecture (or technical architecture ), the system can be broken down into functions or features.
  • In the component architecture , the rough draft of the system is recorded in individual components .
  • This rough draft can be represented more finely in the fine draft. These are, for example, class hierarchies, modular architectures or programming language-specific source text . The transitions between detailed drafts are partly fluid.

It should be noted that there is no such thing as one software architecture for a system. Depending on the question and point of interest, different views must be used. An example of this is the 4 + 1 view model .

Software architecture descriptions can be used over the entire life cycle of a software system. In addition to development, this also includes software evolution, software installation and software operation. In addition to technical activities, project management activities such as cost estimation, milestone planning, planning of cross-project software reuse and the organization of distributed software development also benefit from a good architecture description.

Various textual or graphic notations are used to describe software architectures. The value of purely graphic representations of software architectures is just as controversial as the value of purely textual representations. Well-known examples are:

draft

The design of a software architecture is the process of creating a rough structure of a software system. Functional and non-functional requirements as well as technical and organizational influencing factors serve as input. The design process is mostly iterative and incremental . The result of the software architecture design is a software architecture description that forms the basis for the detailed design .

Software architects follow a number of fundamental design principles. With the principle of targeted abstraction of information, they make the complexity of a system manageable. The principle of separation of powers (Engl. Separation of concerns ) ensures that each component of an architecture is only responsible for a single task. The interior of the components is carried interfaces encapsulated, which on the principle of concealing information (engl. Information hiding ) decreases. The system is ideally broken down into a number of self-contained, loosely coupled components with high cohesion (principle of modularity , see also packaging principles ), which makes it easier to understand and adapt. A software architecture is also often structured hierarchically . The principle of conceptual integrity aims at a consistent application of design decisions.

When designing, software architects often use proven solutions that are documented as so-called architecture patterns. These provide templates for the basic organization and interaction of software components. Examples of architecture patterns are client-server (e.g. basis for HTTP ) or layered architecture (e.g. in the OSI model ). Some architecture patterns can be implemented with the help of prefabricated infrastructure software. For example, the peer-to-peer architecture pattern can be implemented with a reference library such as JXTA .

Quality requirements (e.g. for performance, maintainability, reliability and security) are an essential influencing factor for the design of a software architecture, since functional requirements can also be realized with unstructured software. It is often the task of the software architect to clarify the technical feasibility and the costs for non-functional requirements in the architectural design. For this purpose, usage scenarios can be designed, similar systems can be examined and experimental prototypes can be created. To implement quality requirements, a number of architectural tactics have been documented that can be used as heuristics to guide the design process.

rating

The most important goals of the software architecture assessment are the identification of potential risks, the assessment of the realization of quality requirements through the architecture and the identification of possibilities for the reuse of software components and other artifacts.

An important quality feature of software architectures is their continuity with regard to changes to the problems to be solved by the software. Small changes to the problem should only lead to small changes in the software architecture. The central quality feature for the work of a software architect from an economic point of view is therefore whether he can define a software architecture that does not have to be changed or only needs to be changed little in the event of small changes in the problem. In agile software development, one speaks in this context of design for change - a software architecture that is open to any changes in the problem. To achieve this one uses emergent design - a successively growing software architecture that is flexible precisely where the requirements often change.

There are various methods for evaluating software architectures, some of which differ considerably in terms of goals, contexts, costs and benefits:

Considerations when developing and setting up a software architecture

When developing and setting up a software architecture in a company, the following considerations must generally be made:

shape function
Internal requirements External requirements
Strict control Flexible changes
Money and time costs Additional functions
complexity Comprehensibility
new technologies Proven technologies
Top-down planning Bottom-up planning
Continuous improvement stability
Scarce integration Few interfaces

See also

literature

German
  • Helmut Balzert: Textbook of software technology . 2nd Edition. Spectrum Akademischer Verlag, Heidelberg 2001, ISBN 3-8274-0301-4 .
  • M. Gharbi, A. Koschel, A. Rausch, G. Starke: Basic knowledge for software architects . dpunkt Verlag, Heidelberg 2012, ISBN 3-89864-791-9 .
  • Ralf Reussner, Wilhelm Hasselbring: Manual of the software architecture. 2nd Edition. dpunkt Verlag, Heidelberg 2008, ISBN 978-3-89864-559-1 .
  • Johannes Siedersleben: Modern software architecture. dpunkt Verlag, Heidelberg 2004, ISBN 3-89864-292-5 .
  • Gernot Starke: Effective Software Architectures: A Practical Guide. 5th edition. Carl-Hanser-Verlag, Munich 2010, ISBN 978-3-446-41215-6 .
  • Gernot Starke, Peter Hruschka: "Software architecture compact", 2nd edition, Springer-Verlag, 2011, ISBN 3-8274-2834-3 .
  • Oliver Vogel, Ingo Arnold, Arif Chughtai, Markus Völter: Software architecture. Basics - Concepts - Practice. Spektrum Akademischer Verlag, Heidelberg 2005, ISBN 3-8274-1534-9 .
English
  • Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice . Addison-Wesley Professional, 2003, ISBN 978-0-321-15495-8 .
  • Nick Rozanski, Eóin Woods: Software Systems Architecture. Working With Stakeholders Using Viewpoints and Perspectives Addison-Wesley, 2011, ISBN 978-0-321-71833-4
  • Richard N. Taylor, Nenad Medvidović, Eric M. Dashofy: Software architecture. foundations, theory, and practice Wiley, 2009, ISBN 978-0-470-16774-8

Web links

Individual evidence

  1. ↑ Helmut Balzert: Textbook of software technology. Vol. 2: Design, implementation, installation and operation, Spektrum Akademischer Verlag, 2011, ISBN 978-3-8274-1706-0 , p. 580.
  2. Jump up ↑ Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford: Documenting Software Architectures: Views and Beyond . 2nd Edition. Addison-Wesley, Boston 2010, ISBN 0-321-55268-7 .
  3. ^ A b Frederick P. Brooks: The mythical man-month: essays on software engineering . Addison-Wesley, Reading (Mass.) 1995, ISBN 978-0-201-83595-3 .
  4. ↑ B. Randell, JN Buxton (Ed.): Software Engineering Techniques. Report of a Conference Sponsored by the NATO Science Committee . Scientific Affairs Division, NATO, 1970, p. 12 .
  5. ↑ a b c d e P. Kruchten, H. Obbink, J. Stafford: The Past, Present, and Future for Software Architecture . In: IEEE software . Vol. 23, No. 2 , 2006, ISSN  0740-7459 , p. 22-30 , doi : 10.1109 / MS.2006.59 .
  6. ↑ a b D. L. Parnas: On the criteria to be used in decomposing systems into modules . In: Communications of the ACM . Vol. 15, No. 12 , 1972, ISSN  0001-0782 , pp. 1053-1058 , doi : 10.1145 / 361598.361623 .
  7. ^ Dewayne E. Perry, Alexander L. Wolf: Foundations for the study of software architecture . In: ACM SIGSOFT Software Engineering Notes . Vol. 17, No. 4 , 1992, ISSN  0163-5948 , pp. 40-52 , doi : 10.1145 / 141874.141884 .
  8. ^ R. Kazman, L. Bass, G. Abowd, M. Webb: SAAM: a method for analyzing the properties of software architectures . 1994, p. 81-90 , doi : 10.1109 / ICSE.1994.296768 .
  9. ^ PB Kruchten: The 4 + 1 View Model of architecture . In: IEEE software . Vol. 12, No. 6 , 1995, ISSN  0740-7459 , p. 42-50 , doi : 10.1109 / 52.469759 .
  10. ↑ Christine Hofmeister, Robert Nord, Dilip Soni: Applied Software Architecture . Addison-Wesley Professional, 2009, ISBN 978-0-321-64334-6 .
  11. ^ Frank Buschmann et al .: Pattern-oriented software architecture . Volume 1: A system of patterns . Wiley, Chichester (New York) 1996, ISBN 978-0-471-95869-7 .
  12. ↑ Archived copy ( Memento of the original from March 6, 2012 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / www.softwarearchitectureportal.org
  13. ↑ http://news.cnet.com/2100-1001-235639.html
  14. ^ Paul Clements, Rick Kazman, Mark Klein: Evaluating software architectures. Methods and case studies . Addison-Wesley Professional, 2002, ISBN 978-0-201-70482-2 .
  15. ^ Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice . Addison-Wesley Professional, 2003, ISBN 978-0-321-15495-8 .
  16. ↑ [1]
  17. ↑ http://www.isaqb.org/index.php?option=com_content&view=category&layout=blog&id=15&Itemid=14&lang=en
  18. ↑ http://www.handbuch-softwarearchitektur.de/
  19. ↑ http://fg-swa.gi.de/
  20. ↑ C2 Wiki for Big Design Up Front
  21. ↑ Mike Cohn: Agile Design: Intentional Yet Emergent. In: Mountain Goat Software Blog. December 4, 2009, accessed November 24, 2014 .
  22. ^ Richard N. Taylor, Nenad Medvidović, Eric M. Dashofy: Software architecture. Foundations, theory, and practice . Wiley, Hoboken 2010, ISBN 978-0-470-16774-8 , pp. 199-241 .
  23. ↑ Torsten Posch, Klaus Birken, Michael Gerdom: Basic knowledge of software architecture . 2004, ISBN 978-3-89864-270-5 , pp. 95 f .
  24. ^ Grady Booch: Object-Oriented Analysis and Design . 1994, ISBN 978-3-89319-673-9 , pp. 291 f .
  25. ↑ Helmut Balzert: Textbook of software technology . tape 2 : design, implementation, installation and operation . Spektrum Akademischer Verlag, 2011, ISBN 978-3-8274-1706-0 , pp. 6 .
  26. ↑ Helmut Balzert: Textbook of software technology . tape 2 : design, implementation, installation and operation . Spektrum Akademischer Verlag, 2011, ISBN 978-3-8274-1706-0 , pp. 29 ff .
  27. ↑ M. Shaw, R. Deline, DV Klein, TL Ross, DM Young, G. Zelesnik: Abstractions for software architecture and tools to support them . In: IEEE Transactions on Software Engineering . Vol. 21, No. 4 , 1995, ISSN  0098-5589 , pp. 314-335 , doi : 10.1109 / 32.385970 .
  28. ^ Edsger Wybe Dijkstra: A discipline of programming . Prentice Hall, 1976, ISBN 978-0-13-215871-8 , pp. 56 .
  29. ^ WP Stevens, GJ Myers, LL Constantine: Structured design . In: IBM Systems Journal . Vol. 13, No. 2 , 1974, ISSN  0018-8670 , p. 115-139 , doi : 10.1147 / sj.132.0115 .
  30. ^ Edward Yourdon, Larry L. Constantine: Structured design. Fundamentals of a discipline of computer program and systems design . 1979, ISBN 978-0-13-854471-3 .
  31. ↑ Vincenzo Ambriola, Genoveffa Tortora: Advances in software engineering and knowledge engineering . World Scientific, 1993, ISBN 978-981-02-1594-1 , pp. 27 .
  32. ^ Frederick P. Brooks: The mythical man-month: essays on software engineering . Addison-Wesley, Reading (Mass.) 1995, ISBN 978-0-201-83595-3 , pp. 44 .
  33. ^ Richard N. Taylor, Nenad Medvidovic, Eric M. Dashofy: Software architecture. Foundations, theory, and practice . Wiley, 2009, ISBN 978-0-470-16774-8 , pp. 99 .
  34. ^ Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice . Addison-Wesley Professional, 2003, ISBN 978-0-321-15495-8 , pp. 71 .
  35. ^ Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice . Addison-Wesley Professional, 2003, ISBN 978-0-321-15495-8 , pp. 13 .
  36. ^ Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice . Addison-Wesley Professional, 2003, ISBN 978-0-321-15495-8 , pp. 99 .
  37. ↑ Muhammed Ali Barbar, Ian Gorton: Software Architecture Review: The State of Practice . In: IEEE Computer . Vol. 42, No. 7 , July 2009, p. 26-32 , doi : 10.1109 / MC.2009.233 .
  38. ^ Nick Rozanski, Eóin Woods: Software Systems Architecture. Working With Stakeholders Using Viewpoints and Perspectives . Addison-Wesley, 2011, ISBN 978-0-321-71833-4 , pp. 191-208 .