Zum Inhalt springen

Softwarearchitektur

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 21. März 2013 um 10:50 Uhr durch LordSnow~dewiki (Diskussion | Beiträge). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Eine Softwarearchitektur ist eine der Architekturtypen in der Informatik und beschreibt die grundlegenden Komponenten und deren Zusammenspiel innerhalb eines Softwaresystems.

Definition

Eine Definition von Helmut Balzert beschreibt den Begriff als „eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“ (Literatur: Balzert, S. 716). Die Architekturkomponenten bilden eine Zerlegung des Gesamtsystems, was bedeutet, dass jedes Softwareelement mindestens einer Architekturkomponente zugeordnet ist.

Paul Clements beschreibt Softwarearchitektur als „Strukturen eines Softwaresystems: Softwareteile, die Beziehungen zwischen diesen und die Eigenschaften der Softwareteile und ihrer Beziehungen“[1]

Die Softwarearchitektur ist Teil des Softwareentwurfs (siehe SWEBOK), innerhalb dessen sie als Grobgliederung der Komponenten entsteht. Während der Softwareentwurf sich auch auf lokale Aspekte innerhalb des architektonischen Rahmens der Software bezieht und deshalb sehr detailliert sein kann, ist die Softwarearchitektur eine globale Eigenschaft des Gesamtsystems.

Einordnung und Abgrenzung

Die Softwarearchitektur ist Teil des Softwareentwurfs (siehe SWEBOK), innerhalb dessen sie als Grobgliederung der Komponenten entsteht. Während der Softwareentwurf sich auch auf lokale Aspekte innerhalb des architektonischen Rahmens der Software bezieht und deshalb sehr detailliert sein kann, bezieht sich die Softwarearchitektur nur auf globale Eigenschaften des Gesamtsystems.

Im Rahmen der Softwareentwicklung repräsentiert die Softwarearchitektur die früheste Softwaredesign-Entscheidung (Architekturentwurf). Sie wird wesentlich durch Softwarequalitätskriterien, also nicht-funktionale Eigenschaften wie Modifizierbarkeit, Wartbarkeit, Sicherheit oder Performance bestimmt (siehe beispielsweise FURPS). Eine einmal eingerichtete Softwarearchitektur ist später nur mit hohem Aufwand abänderbar. Die Entscheidung über ihr Design ist somit einer der kritischsten und wichtigsten Punkte im Entwicklungsprozess einer Software.

Eine Softwarearchitektur ist in ihrer wirtschaftswissenschaftlichen Perspektive sehr stark von umgebenen Aspekten abhängig. Deswegen benötigt eine Softwarearchitektur, um erfolgreich funktionieren zu können, eine geeignete Abstimmung mit den wichtigsten übrigen Faktoren des Softwareprojekts. Für Benutzer und Entwickler des Softwareprojekts gibt eine gut konstruierte Softwarearchitektur leicht ein grundlegendes Verständnis des Systems. Wichtige Faktoren, die auf die Eignung der Softwarearchitektur Einfluss nehmen, sind Projektplanung, Risikoanalyse, Organisation, Entwicklungsprozess, Arbeitsabläufe, Hardware, Qualitätssicherung und Anforderungen.

Beispiel

Eine Architekturbeschreibung umfasst etwa im Falle einer Web-Anwendung den Aufbau des Systems aus Datenbanken, Web-/Application-Servern, E-Mail- und Cachesystemen − siehe etwa Wikipedia selbst.

Geschichte

Anfänge (1960-1990)

Die Anfänge der Beschreibung und Nutzung einer expliziten Softwarearchitektur reichen zurück bis in die 1960er-Jahre, als die ersten größeren Softwaresysteme entstanden.[2] Die Komplexität der Systeme (z. B. OS/360) machte es notwendig, die Implementierungsaufgaben auf verschiedene Teams aufzuteilen und Schnittstellen zu definieren. Die erste Erwähnung des Begriffs „Softwarearchitektur“ findet sich im Tagungsband einer von der NATO finanzierten Konferenz über Softwaretechnik im Jahre 1969.[3] Besucher dieser Konferenz waren zahlreiche Informatikpioniere, wie z. B. Tony Hoare, Edsger Dijkstra, Alan Perlis, Per Brinch Hansen, Friedrich Bauer, und Niklaus Wirth.

In den 1970er und 1980er Jahren wurde das Wort „Architektur“ im IT-Bereich häufig im Zusammenhang mit Systemarchitekturen (also physischen Computersystemstrukturen) verwendet oder bezog sich speziell auf Prozessorfamilien.[4] 1972 veröffentlichte David Parnas einen einflussreichen Artikel über Kriterien für die Moduldekomposition von Softwaresystemen.[5] Obwohl er dabei nicht den Begriff „Softwarearchitektur“ verwendete, nahm er doch einige der späteren Konzepte und Ideen für Softwarearchitektur vorweg.[4] 1975 erschien das Buch „The Mythical Man Month“ von Frederick P. Brooks, in dem Schlüsselkonzepte zum Entwurf und der Organisation von Softwaresystemen diskutiert wurden.[2] Weitere Artikel von Parnas und Brooks in den 1980er Jahren vertieften diese Ideen und Konzepte.

Etablierung (1990-2000)

Softwarearchitektur wurde erst in den 1990er Jahren ein unabhängiges Teilgebiet der Softwaretechnik. 1992 veröffentlichten Dewayne Perry und Alexander Wolf einen grundlegenden Artikel mit dem Titel „Foundations for the Study of Software Architecture“.[6] Darin führten sie die Formel „Elemente + Form + Rational = Softwarearchitektur“ ein. Viele Forscher interpretierten „Elemente“ als Softwarekomponenten und -konnektoren.[4] Daraufhin entstanden an verschiedenen Universitäten eine Reihe von Architekturbeschreibungssprachen (C2, Rapide, Darwin, Wright, ACME, Unicon), die allerdings kaum industriell eingesetzt wurden.[4]

Ab 1995 gewann die Softwarearchitektur sowohl im industriellen als auch im akademischen Umfeld zunehmend an Bedeutung. Das Software Engineering Institute (SEI) in Pittsburgh veröffentlichte die „Software Architecture Analysis Method“ (SAAM).[7] Das Konzept der Architektursichten spiegelte sich in verschiedenen Ansätzen wie Rationals „4+1 views“[8] oder Siemens „Four views“[9] wider. 1996 erschien das Buch „Pattern-oriented Software Architecture“, welches das Konzept der Entwurfsmuster auf Softwarearchitekturen übertrug.[10] Siemens, Nokia, Philips, Nortel, Lockheed Martin, IBM und andere größere Softwarefirmen nutzten Softwarearchitektur zur besseren Wiederverwendbarkeit von Software und entwarfen Softwareproduktlinien.[4] 1999 fand in den USA die erste internationale Konferenz (WICSA 1) speziell zum Thema Softwarearchitektur statt.[11]

Aktuell (2000-heute)

Im Jahr 2000 erschien die IEEE 1471:2000 Norm „Recommended Practice for Architectural Description of Software-Intensive Systems“ zur Architekturbeschreibung von Softwaresystemen. Im gleichen Jahr übernahm mit Bill Gates eine der prominentesten Personen aus dem IT-Bereich den Titel „Chief Software Architect“ bei Microsoft.[12] Das SEI arbeitete die szenariobasierte Architekturbewertungsmethode „Architecture Trade-off Analysis Method“ (ATAM) aus, die im Folgenden in zahlreichen Industrieprojekten Anwendung fand.[13] Die Unified Modeling Language (UML) eignet sich seit Version 2.0 aus dem Jahr 2003 auch zur Dokumentation von Softwarearchitekturen. 2003 erschien das mittlerweile meistzitierte Buch zur Softwarearchitektur („Software Architecture in Practice“) und hob die Bedeutung von Qualitätsattributen für den Entwurf und die Bewertung von Softwarearchitekturen hervor.[14]

In Deutschland werden mit dem „International Software Architect Qualification Board“ (iSAQB)[15], ein Zusammenschluss deutscher IT Firmen, seit 2003 Zertifikate für Softwarearchitekten vergeben. Bis 2008 wurden so über 400 Softwarearchitekten zertifiziert.[16] 2004 gründete sich ein Arbeitskreis der Gesellschaft für Informatik zum Thema Softwarearchitektur und veröffentlichte 2006 das „Handbuch der Software-Architektur“.[17] 2006 entstand aus dem temporären Arbeitskreis eine permanente GI-Fachgruppe.[18]

Aktuelle Praxisthemen sind z. B. Softwarearchitekturen für Cloud Computing, Mehrkernprozessoren und mobile Endgeräte, sowie Serviceorientierte Architekturen. Aktuelle Forschungsthemen im Bereich Softwarearchitektur sind z. B. Wissensmanagement für Softwarearchitekturen, modellbasierte Analyseverfahren sowie Softwareproduktlinien.

Beschreibung

Die Beschreibung einer Softwarearchitektur enthält Informationen über die Struktur („Komponentisierung“) eines Software-Systems, aber auch Informationen über die Kommunikation zwischen Komponenten, sowie deren Abbildung auf Hardware- oder Software-Ressourcen (Verteilung und Deployment).

Softwarearchitekturbeschreibungen können über den gesamten Lebenszyklus eines Software-Systems genutzt werden. Dazu gehören neben der Entwicklung insbesondere auch Software-Evolution, Software-Installation und Software-Betrieb. Ebenso profitieren neben technischen Tätigkeiten auch Projektmanagement-Tätigkeiten, wie Kostenschätzung, Meilensteinplanung, Planung projektübergreifender Software-Wiederverwendung und die Organisation verteilter Software-Entwicklung von einer guten Architekturbeschreibung.

Verschiedene textuelle oder graphische Notationen werden zur Beschreibung von Softwarearchitekturen eingesetzt. Der Wert von rein grafischen Darstellungen von Softwarearchitekturen ist ebenso umstritten wie der Wert von rein textuellen Darstellungen. Bekannte Beispiele sind[19]:

Entwurf

Der Entwurf einer Softwarearchitektur ist der Erstellungsprozess einer Grobstruktur eines Softwaresystems. Dabei dienen funktionale und nichtfunktionale Anforderungen sowie technische und organisatorische Einflussfaktoren als Eingabe.[20] Der Entwurfsprozess läuft meist iterativ und inkrementell ab.[21] Das Ergebnis des Softwarearchitekturentwurfs ist eine Softwarearchitekturbeschreibung, die die Grundlage für den Feinentwurf bildet.[22]

Softwarearchitekten folgen einer Reihe fundamentaler Entwurfsprinzipien.[23] Mit dem Prinzip der gezielten Abstraktion von Informationen machen sie die Komplexität eines Systems beherrschbar.[24] Das Prinzip der Trennung von Zuständigkeiten (engl. separation of concerns) sorgt dafür, dass jede Komponente einer Architektur nur für eine einzige Aufgabe zuständig ist. [25] Das Innenleben von Komponenten wird durch Schnittstellen verkapselt, was auf das Prinzip des Verbergens von Informationen (engl. information hiding) zurückgeht.[5] Das System wird idealerweise in eine Menge in sich geschlossener, lose gekoppelter Komponenten mit hoher Kohäsion zerlegt (Prinzip der Modularität, siehe auch Packaging-Prinzipien), wodurch es leichter verständlich und anpassbar wird.[26][27] Eine Softwarearchitektur ist zudem häufig hierarchisch aufgebaut.[28] Das Prinzip der konzeptionellen Integrität zielt auf eine durchgängige Anwendung von Entwurfsentscheidungen.[29]

Softwarearchitekten bedienen sich beim Entwurf oft bei bewährten Lösungen, die als so genannte Architekturmuster dokumentiert sind.[30] Diese bieten Vorlagen für die grundlegende Organisation und Interaktion von Softwarekomponenten. Beispiele für Architekturmuster sind Client-Server (z. B. Grundlage für HTTP) oder Schichtenarchitektur (z. B. beim OSI-Modell). Einige Architekturmuster können mit Hilfe vorgefertigter Infrastruktursoftware umgesetzt werden. Beispielsweise kann das Peer-to-Peer Architekturmuster mit einer Referenzbibliothek wie JXTA implementiert werden.

Qualitätsanforderungen (z. B. für Performanz, Wartbarkeit, Zuverlässigkeit und Sicherheit) sind ein wesentlicher Einflussfaktor für den Entwurf einer Softwarearchitektur, da sich funktionale Anforderungen auch mit unstrukturierter Software realisieren lassen.[31] Oftmals ist es die Aufgabe des Softwarearchitekten die technische Machbarkeit sowie die Kosten für nichtfunktionale Anforderungen beim Architekturentwurf zu klären.[32] Dazu können Benutzungsszenarien entworfen werden, ähnliche System untersucht werden und experimentelle Prototypen erstellt werden. Zur Umsetzung von Qualitätsanforderungen wurden eine Reihe von Architekturtaktiken dokumentiert, die als Heuristik den Entwurfsprozess leiten können.[33]

Bewertung

Die wichtigsten Ziele der Softwarearchitekturbewertung sind die Identifikation von potenziellen Risiken, die Beurteilung der Realisierung von Qualitätsanforderungen durch die Architektur und die Identifikation von Möglichkeiten zur Wiederverwendung von Softwarekomponenten und anderen Artefakten.[34]

Ein wichtiges Qualitätsmerkmal von Softwarearchitekturen ist ihre Stetigkeit in Bezug auf Änderungen an den durch die Software zu lösenden Problemen. Kleine Änderungen durch Probleme, sollen nur zu kleinen Änderungen in der Softwarearchitektur führen. Das zentrale Qualitätsmerkmal für die Arbeit eines Softwarearchitekten aus wirtschaftlicher Sicht ist deshalb, ob er schnell genug eine Softwarearchitektur definieren kann, mit der sich gestellte Probleme lösen lassen und die verfügbaren Softwareentwickler besseren Ergebnisse erzielen.

Zur Bewertung von Softwarearchitekturen existieren verschiedene Methoden, die sich in Zielen, Einsatzkontexten, Kosten und Nutzen zum Teil erheblich unterscheiden[35]:

  • Informelle Präsentation
  • Ausfüllen von vorgefertigten Fragebögen und Checklisten
  • Architektursichtungen (engl. Walkthroughs)
  • Szenariobasierte Verfahren
  • Simulation formaler Architekturmodelle
  • Bau und Analyse von Prototypen
  • Erhebung und Überprüfung von Architekturmetriken und -kennzahlen
  • Architekturkonsistenzprüfung mittels statischer Codeanalyse

Abwägungen bei Entwicklung und Aufbau einer Softwarearchitektur

Bei der Entwicklung und dem Aufbau einer Softwarearchitektur in einem Unternehmen sind im Allgemeinen unter anderem folgende Abwägungen durchzuführen:

Form Funktion
Interne Anforderungen Externe Anforderungen
Strenge Kontrolle Flexible Änderungen
Geld- und Zeitkosten Zusätzliche Funktionen
Komplexität Verständlichkeit
Neue Technologien Bewährte Technologien
Top-Down-Planung Bottom-Up-Planung
Fortlaufende Verbesserung Stabilität
Knappe Integration Wenige Interfaces

Siehe auch

Literatur

Deutsch
  • Helmut Balzert: Lehrbuch der Software-Technik. 2. Auflage. Spektrum Akademischer Verlag, Heidelberg 2001, ISBN 3-8274-0301-4.
  • Torsten Posch, Klaus Birken, Michael Gerdom: Basiswissen Softwarearchitektur. dpunkt Verlag, Heidelberg 2004, ISBN 3-89864-270-4.
  • Ralf Reussner, Wilhelm Hasselbring: Handbuch der Software-Architektur. 2. Auflage. dpunkt Verlag, Heidelberg 2008, ISBN 978-3-89864-559-1.
  • Johannes Siedersleben: Moderne Software-Architektur. dpunkt Verlag, Heidelberg 2004, ISBN 3-89864-292-5.
  • Gernot Starke: Effektive Software-Architekturen: Ein praktischer Leitfaden. 3. Auflage. Carl-Hanser-Verlag, München 2008, ISBN 978-3-446-41215-6.
  • Oliver Vogel, Ingo Arnold, Arif Chughtai, Markus Völter: Software-Architektur. Grundlagen - Konzepte - Praxis. Spektrum Akademischer Verlag, Heidelberg 2005, ISBN 3-8274-1534-9.
Englisch
  • Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice Addison-Wesley Professional, 2003, ISBN 978-0321154958
  • Paul Clements, Felix Bachmann, Len Bass, David Garlan, Paulo Merson, James Ivers, Reed Little, Robert Nord: Documenting Software Architectures. Views and Beyond Addison-Wesley Professional, 2010, ISBN 978-0321552686.
  • Paul Clements, Rick Kazman, Mark Klein: Evaluating software architectures. methods and case studies Addison-Wesley Professional, 2002, ISBN 978-0201704822.
  • Nick Rozanski, Eóin Woods: Software Systems Architecture. Working With Stakeholders Using Viewpoints and Perspectives Addison-Wesley, 2011, ISBN 978-0321718334
  • Richard N. Taylor, Nenad Medvidović, Eric M. Dashofy: Software architecture. foundations, theory, and practice Wiley, 2009, ISBN 978-0470167748

Einzelnachweise

  1. ↑ 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, Boston 2010, ISBN 0-321-55268-7.
  2. ↑ a b Frederick P Brooks: The mythical man-month: essays on software engineering Reading, Mass. : Addison-Wesley Pub. Co., 1995., ISBN 978-0201835953
  3. ↑ B. Randell, J.N. Buxton (eds.): Software Engineering Techniques: Report of a Conference Sponsored by the NATO Science Committee Scientific Affairs Division, NATO, 1970, Seite. 12
  4. ↑ a b c d e P. Kruchten, H. Obbink, J. Stafford: The Past, Present, and Future for Software Architecture. In: IEEE Software. 23. Jahrgang, Nr. 2, 2006, ISSN 0740-7459, S. 22–30, doi:10.1109/MS.2006.59.
  5. ↑ a b D. L. Parnas: On the criteria to be used in decomposing systems into modules. In: Communications of the ACM. 15. Jahrgang, Nr. 12, 1972, ISSN 0001-0782, S. 1053–1058, doi:10.1145/361598.361623.
  6. ↑ Dewayne E. Perry, Alexander L. Wolf: Foundations for the study of software architecture. In: ACM SIGSOFT Software Engineering Notes. 17. Jahrgang, Nr. 4, 1992, ISSN 0163-5948, S. 40–52, doi:10.1145/141874.141884.
  7. ↑ R. Kazman, L. Bass, G. Abowd, M. Webb: SAAM: a method for analyzing the properties of software architectures. 1994, S. 81–90, doi:10.1109/ICSE.1994.296768.
  8. ↑ P.B. Kruchten: The 4+1 View Model of architecture. In: IEEE Software. 12. Jahrgang, Nr. 6, 1995, ISSN 0740-7459, S. 42–50, doi:10.1109/52.469759.
  9. ↑ Christine Hofmeister, Robert Nord, Dilip Soni: Applied Software Architecture Addison-Wesley Professional, 2009, ISBN 978-0321643346
  10. ↑ Frank Buschmann et al: Pattern-oriented software architecture: Volume 1 A system of patterns, Chichester, New York, Wiley, 1996, ISBN 978-0471958697
  11. ↑ http://www.softwarearchitectureportal.org/WICSA/conferences/
  12. ↑ http://news.cnet.com/2100-1001-235639.html
  13. ↑ Paul Clements, Rick Kazman, Mark Klein: Evaluating software architectures. methods and case studies Addison-Wesley Professional, 2002, ISBN 978-0201704822
  14. ↑ Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice Addison-Wesley Professional, 2003, ISBN 978-0321154958
  15. ↑ [1]
  16. ↑ http://www.isaqb.org/index.php?option=com_content&view=category&layout=blog&id=15&Itemid=14&lang=en
  17. ↑ http://www.handbuch-softwarearchitektur.de/
  18. ↑ http://fg-swa.gi.de/
  19. ↑ Richard N. Taylor, Nenad Medvidović, Eric M. Dashofy: Software architecture. foundations, theory, and practice Wiley, 2009, ISBN 978-0470167748, S.199-241.
  20. ↑ Torsten Posch, Klaus Birken, Michael Gerdom: Basiswissen Softwarearchitektur 2004, ISBN 978-3898642705, S. 95f
  21. ↑ Grady Booch: Objektorientierte Analyse und Design 1994, ISBN 978-3893196739, S. 291f
  22. ↑ Helmut Balzert: Lehrbuch der Softwaretechnik Bd. 2: Entwurf, Implementierung, Installation und Betrieb Spektrum Akademischer Verlag Gmbh, 2011, ISBN 978-3827417060, S.6
  23. ↑ Helmut Balzert: Lehrbuch der Softwaretechnik Bd. 2: Entwurf, Implementierung, Installation und Betrieb Spektrum Akademischer Verlag Gmbh, 2011, ISBN 978-3827417060, S.29ff
  24. ↑ M. Shaw, R. DeLine, D.V. Klein, T.L. Ross, D.M. Young, G. Zelesnik: Abstractions for software architecture and tools to support them. In: IEEE Transactions on Software Engineering. 21. Jahrgang, Nr. 4, 1995, ISSN 0098-5589, S. 314–335, doi:10.1109/32.385970.
  25. ↑ Edsger Wybe Dijkstra: A discipline of programming Prentice Hall, 1976, ISBN 9780132158718, S. 56
  26. ↑ W. P. Stevens, G. J. Myers, L. L. Constantine: Structured design. In: IBM Systems Journal. 13. Jahrgang, Nr. 2, 1974, ISSN 0018-8670, S. 115–139, doi:10.1147/sj.132.0115.
  27. ↑ Edward Yourdon, Larry L. Constantine: Structured design. fundamentals of a discipline of computer program and systems design 1979, ISBN 978-0138544713
  28. ↑ Vincenzo Ambriola, Genoveffa Tortora: Advances in software engineering and knowledge engineering World Scientific Pub Co Inc, 1993, ISBN 9789810215941, S.27
  29. ↑ Frederick P Brooks: The mythical man-month : essays on software engineering Reading, Mass., Addison-Wesley Pub. Co., 1995, ISBN 9780201835953, S. 44
  30. ↑ Richard N. Taylor, Nenad Medvidovic, Eric M. Dashofy: Software architecture. foundations, theory, and practice Wiley, 2009, ISBN 978-0470167748, S.99
  31. ↑ Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice Addison-Wesley Professional, 2003, ISBN 978-0321154958, S. 71
  32. ↑ Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice Addison-Wesley Professional, 2003, ISBN 978-0321154958, S.13
  33. ↑ Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice Addison-Wesley Professional, 2003, ISBN 978-0321154958, S.99
  34. ↑ Muhammed Ali Barbar, Ian Gorton: Software Architecture Review: The State of Practice. In: IEEE Computer, Vol. 42, No. 7, pp. 26-32, Juli 2009.
  35. ↑ Nick Rozanski, Eóin Woods: Software Systems Architecture. Working With Stakeholders Using Viewpoints and Perspectives Addison-Wesley, 2011, ISBN 978-0321718334, S.191-208.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Softwarearchitektur&oldid=115647695“