Softwarearchitektur

Der Begriff Softwarearchitektur bezieht sich auf die grundlegenden Strukturen eines Softwaresystems und die Disziplin der Erstellung solcher Strukturen und Systeme. Jede Struktur umfasst Softwareelemente, Beziehungen zwischen ihnen und Eigenschaften von Elementen und Beziehungen. Die Architektur eines Softwaresystems ist eine Metapher, die mit der Architektur eines Gebäudes vergleichbar ist. Sie dient als Blaupause für das System und das Entwicklungsprojekt und legt die Aufgaben fest, die von den Entwicklungsteams ausgeführt werden müssen. ⓘ

Bei der Softwarearchitektur geht es darum, grundlegende strukturelle Entscheidungen zu treffen, die nach der Implementierung nur mit hohem Aufwand zu ändern sind. Zu den Entscheidungen für die Softwarearchitektur gehören spezifische strukturelle Optionen, die sich aus den Möglichkeiten des Softwareentwurfs ergeben. Die Systeme zur Steuerung der Space Shuttle-Trägerrakete mussten zum Beispiel sehr schnell und sehr zuverlässig sein. Daher musste eine geeignete Echtzeit-Computersprache gewählt werden. Um den Anforderungen an die Zuverlässigkeit gerecht zu werden, könnte man sich außerdem für mehrere redundante und unabhängig voneinander erstellte Kopien des Programms entscheiden und diese Kopien auf unabhängiger Hardware laufen lassen, während die Ergebnisse gegengeprüft werden. ⓘ

Die Dokumentation der Softwarearchitektur erleichtert die Kommunikation zwischen den Beteiligten, hält frühe Entscheidungen über das High-Level-Design fest und ermöglicht die Wiederverwendung von Designkomponenten zwischen Projekten. ⓘ

Software_Architektur_Aktivitäten ⓘ

Eine Softwarearchitektur ist einer der Architekturtypen in der Informatik und beschreibt die grundlegenden Komponenten und deren Zusammenspiel innerhalb eines Softwaresystems. Als spezialisierte Tätigkeit hat sich der Softwarearchitekt herausentwickelt, der für das High Level Design und die Planung neuer Softwareprodukte verantwortlich ist. ⓘ

Umfang

Über den Umfang von Softwarearchitekturen gibt es unterschiedliche Auffassungen:

Makroskopische Systemstruktur: Dies bezieht sich auf die Architektur als eine übergeordnete Abstraktion eines Softwaresystems, das aus einer Sammlung von Rechenkomponenten zusammen mit Konnektoren besteht, die die Interaktion zwischen diesen Komponenten beschreiben.
Das Wichtige - was auch immer das ist: Dies bezieht sich auf die Tatsache, dass Softwarearchitekten sich mit den Entscheidungen befassen sollten, die große Auswirkungen auf das System und seine Beteiligten haben.
Das, was für das Verständnis eines Systems in seiner Umgebung grundlegend ist
Dinge, die in den Augen der Menschen schwer zu ändern sind: Da der Entwurf der Architektur am Anfang des Lebenszyklus eines Softwaresystems steht, sollte sich der Architekt auf Entscheidungen konzentrieren, die beim ersten Mal richtig sein "müssen". Diesem Gedankengang folgend, können architektonische Designfragen zu nicht-architektonischen werden, sobald ihre Irreversibilität überwunden werden kann.
Eine Reihe von architektonischen Entwurfsentscheidungen: Softwarearchitektur sollte nicht nur als eine Reihe von Modellen oder Strukturen betrachtet werden, sondern auch die Entscheidungen, die zu diesen speziellen Strukturen führen, sowie die dahinter stehenden Überlegungen umfassen. Diese Erkenntnis hat zu umfangreichen Forschungsarbeiten im Bereich des Wissensmanagements für Softwarearchitekturen geführt. ⓘ

Es gibt keine scharfe Unterscheidung zwischen Software-Architektur und Design und Requirements Engineering (siehe Verwandte Bereiche unten). Sie sind alle Teil einer "Absichtskette", die von den übergeordneten Absichten bis zu den Details auf niedriger Ebene reicht. ⓘ

Merkmale

Softwarearchitektur zeichnet sich durch folgende Merkmale aus: Eine Vielzahl von Interessengruppen: Softwaresysteme müssen einer Vielzahl von Interessengruppen gerecht werden, z. B. Geschäftsführern, Eigentümern, Benutzern und Betreibern. Diese Interessengruppen haben alle ihre eigenen Anliegen in Bezug auf das System. Diese Belange auszugleichen und nachzuweisen, dass sie berücksichtigt werden, ist Teil der Systemgestaltung. Dies bedeutet, dass die Architektur den Umgang mit einer Vielzahl von Anliegen und Interessengruppen beinhaltet und einen multidisziplinären Charakter hat. ⓘ

Trennung der Belange: Der bewährte Weg für Architekten, die Komplexität zu reduzieren, ist die Trennung der Belange, die den Entwurf bestimmen. Die Architekturdokumentation zeigt, dass alle Belange der Beteiligten berücksichtigt werden, indem die Architektur aus verschiedenen Blickwinkeln modelliert und beschrieben wird, die mit den verschiedenen Belangen der Beteiligten verbunden sind. Diese separaten Beschreibungen werden als Architektursichten bezeichnet (siehe z. B. das 4+1-Architektursichtmodell). ⓘ

Qualitätsorientiert: Klassische Softwareentwurfsansätze (z. B. Jackson Structured Programming) wurden durch die erforderliche Funktionalität und den Datenfluss durch das System bestimmt, aber die heutige Einsicht ist, dass die Architektur eines Softwaresystems enger mit seinen Qualitätsattributen wie Fehlertoleranz, Rückwärtskompatibilität, Erweiterbarkeit, Zuverlässigkeit, Wartbarkeit, Verfügbarkeit, Sicherheit, Benutzerfreundlichkeit und anderen solchen Eigenschaften verbunden ist. Die Anliegen der Interessengruppen äußern sich häufig in Anforderungen an diese Qualitätsmerkmale, die auch als nichtfunktionale Anforderungen, extrafunktionale Anforderungen, Verhaltensanforderungen oder Anforderungen an die Qualitätsmerkmale bezeichnet werden. ⓘ

Wiederkehrende Stile: Wie bei der Gebäudearchitektur haben sich auch in der Softwarearchitektur Standardverfahren entwickelt, um wiederkehrende Probleme zu lösen. Diese "Standardmethoden" werden auf verschiedenen Abstraktionsebenen mit unterschiedlichen Namen bezeichnet. Gängige Begriffe für wiederkehrende Lösungen sind Architekturstil, Taktik, Referenzarchitektur und Architekturmuster. ⓘ

Konzeptionelle Integrität: Ein Begriff, der von Fred Brooks in seinem Buch The Mythical Man-Month von 1975 eingeführt wurde, um die Idee zu bezeichnen, dass die Architektur eines Softwaresystems eine Gesamtvision dessen darstellt, was es tun sollte und wie es dies tun sollte. Diese Vision sollte von ihrer Implementierung getrennt werden. Der Architekt übernimmt die Rolle des "Bewahrers der Vision", der sicherstellt, dass Ergänzungen zum System mit der Architektur übereinstimmen und somit die konzeptionelle Integrität bewahrt wird. ⓘ

Cognitive constraints (kognitive Beschränkungen): eine Beobachtung, die erstmals 1967 von dem Computerprogrammierer Melvin Conway gemacht wurde, wonach Organisationen, die Systeme entwerfen, gezwungen sind, Entwürfe zu erstellen, die eine Kopie der Kommunikationsstrukturen dieser Organisationen sind. Wie bei der konzeptionellen Integrität war es Fred Brooks, der diesen Begriff einem breiteren Publikum bekannt machte, als er ihn in seinem eleganten Klassiker The Mythical Man-Month zitierte und ihn "Conway's Law" nannte. ⓘ

Motivation

Softwarearchitektur ist eine "intellektuell fassbare" Abstraktion eines komplexen Systems. Diese Abstraktion bietet eine Reihe von Vorteilen:

Sie bietet eine Grundlage für die Analyse des Verhaltens von Softwaresystemen, bevor das System gebaut wurde. Die Möglichkeit, zu überprüfen, ob ein künftiges Softwaresystem die Anforderungen der Beteiligten erfüllt, ohne es tatsächlich bauen zu müssen, bedeutet eine erhebliche Kosteneinsparung und Risikominderung. Es wurde eine Reihe von Techniken entwickelt, um solche Analysen durchzuführen, wie z. B. ATAM oder die Erstellung einer visuellen Darstellung des Softwaresystems.
Sie bietet eine Grundlage für die Wiederverwendung von Elementen und Entscheidungen. Eine komplette Software-Architektur oder Teile davon, wie z. B. einzelne architektonische Strategien und Entscheidungen, können in mehreren Systemen wiederverwendet werden, deren Beteiligte ähnliche Qualitätsattribute oder Funktionalitäten benötigen, was Designkosten spart und das Risiko von Designfehlern mindert.
Es unterstützt frühe Designentscheidungen, die sich auf die Entwicklung, den Einsatz und die Wartung eines Systems auswirken. Die richtigen Entscheidungen zu treffen ist wichtig, um Termin- und Budgetüberschreitungen zu vermeiden.
Sie erleichtert die Kommunikation mit den Beteiligten und trägt zu einem System bei, das deren Anforderungen besser erfüllt. Die Kommunikation über komplexe Systeme aus der Sicht der Beteiligten hilft ihnen, die Konsequenzen ihrer Anforderungen und der darauf basierenden Entwurfsentscheidungen zu verstehen. Die Architektur bietet die Möglichkeit, über Entwurfsentscheidungen zu kommunizieren, bevor das System implementiert wird, wenn sie noch relativ leicht anzupassen sind.
Sie hilft beim Risikomanagement. Software-Architektur hilft, Risiken und die Wahrscheinlichkeit von Fehlern zu verringern.
Sie ermöglicht Kostensenkungen. Softwarearchitektur ist ein Mittel zur Risiko- und Kostenkontrolle bei komplexen IT-Projekten. ⓘ

Geschichte

Der Vergleich zwischen Software-Design und (ziviler) Architektur wurde erstmals Ende der 1960er Jahre gezogen, aber der Begriff "Software-Architektur" wurde erst in den 1990er Jahren allgemein verwendet. Die Informatik war seit ihrer Entstehung mit Problemen der Komplexität konfrontiert. Frühere Komplexitätsprobleme wurden von den Entwicklern durch die Wahl der richtigen Datenstrukturen, die Entwicklung von Algorithmen und die Anwendung des Konzepts der Trennung von Belangen gelöst. Obwohl der Begriff "Softwarearchitektur" in der Branche relativ neu ist, wurden die grundlegenden Prinzipien dieses Bereichs von Pionieren der Softwaretechnik seit Mitte der 1980er Jahre sporadisch angewandt. Frühe Versuche, die Software-Architektur eines Systems zu erfassen und zu erklären, waren ungenau und unorganisiert und oft durch eine Reihe von Kasten- und Liniendiagrammen gekennzeichnet. ⓘ

Das Konzept der Softwarearchitektur hat seinen Ursprung in den Forschungen von Edsger Dijkstra im Jahr 1968 und David Parnas in den frühen 1970er Jahren. Diese Wissenschaftler betonten, dass die Struktur eines Softwaresystems wichtig ist und dass es entscheidend ist, die richtige Struktur zu finden. In den 1990er Jahren gab es konzertierte Bemühungen, grundlegende Aspekte der Disziplin zu definieren und zu kodifizieren, wobei sich die Forschungsarbeit auf Architekturstile (Patterns), Architekturbeschreibungssprachen, Architekturdokumentation und formale Methoden konzentrierte. ⓘ

Forschungseinrichtungen haben eine herausragende Rolle bei der Förderung der Softwarearchitektur als Disziplin gespielt. Mary Shaw und David Garlan von Carnegie Mellon schrieben ein Buch mit dem Titel Software Architecture: Perspectives on an Emerging Discipline" (1996), in dem Softwarearchitekturkonzepte wie Komponenten, Konnektoren und Stile vorgestellt werden. Das Institute for Software Research der University of California, Irvine, beschäftigt sich in der Softwarearchitekturforschung hauptsächlich mit Architekturstilen, Architekturbeschreibungssprachen und dynamischen Architekturen. ⓘ

IEEE 1471-2000, "Recommended Practice for Architecture Description of Software-Intensive Systems", war der erste formale Standard im Bereich der Softwarearchitektur. Er wurde 2007 von der ISO als ISO/IEC 42010:2007 angenommen. Im November 2011 wurde IEEE 1471-2000 durch ISO/IEC/IEEE 42010:2011, "Systems and software engineering - Architecture description" (gemeinsam von IEEE und ISO veröffentlicht), abgelöst. ⓘ

Während es in IEEE 1471 bei der Softwarearchitektur um die Architektur "softwareintensiver Systeme" ging, definiert als "jedes System, bei dem die Software wesentliche Einflüsse auf das Design, die Konstruktion, den Einsatz und die Entwicklung des Systems als Ganzes hat", geht die Ausgabe 2011 einen Schritt weiter, indem sie die Definitionen von ISO/IEC 15288 und ISO/IEC 12207 für ein System einbezieht, die nicht nur Hardware und Software, sondern auch "Menschen, Prozesse, Verfahren, Einrichtungen, Materialien und natürlich vorkommende Entitäten" umfassen. Dies spiegelt die Beziehung zwischen Softwarearchitektur, Unternehmensarchitektur und Lösungsarchitektur wider. ⓘ

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. Darin führten sie die Formel „Elemente + Form + Begründung = Softwarearchitektur“ ein. Viele Forscher interpretierten „Elemente“ als Softwarekomponenten und -konnektoren. Daraufhin entstanden an verschiedenen Universitäten eine Reihe von Architekturbeschreibungssprachen (C2, Rapide, Darwin, Wright, ACME, Unicon), die allerdings kaum industriell eingesetzt wurden. ⓘ

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). Das Konzept der Architektursichten spiegelte sich in verschiedenen Ansätzen wie Rationals „4+1 views“ oder Siemens „Four views“ wider. 1996 erschien das Buch Pattern-oriented Software Architecture, welches das Konzept der Entwurfsmuster auf Softwarearchitekturen übertrug. Siemens, Nokia, Philips, Nortel, Lockheed Martin, IBM und andere größere Softwarefirmen nutzten Softwarearchitektur zur besseren Wiederverwendbarkeit von Software und entwarfen Softwareproduktlinien. 1999 fand in den USA die erste internationale Konferenz (WICSA 1) speziell zum Thema Softwarearchitektur statt. ⓘ

Architektur-Aktivitäten

Es gibt viele Tätigkeiten, die ein Softwarearchitekt ausführt. Ein Softwarearchitekt arbeitet typischerweise mit Projektmanagern zusammen, bespricht architektonisch wichtige Anforderungen mit Interessengruppen, entwirft eine Softwarearchitektur, bewertet einen Entwurf, kommuniziert mit Designern und Interessengruppen, dokumentiert den Architekturentwurf und vieles mehr. Es gibt vier Kernaktivitäten beim Entwurf einer Softwarearchitektur. Diese Kernaktivitäten der Architektur werden iterativ und in verschiedenen Phasen des anfänglichen Lebenszyklus der Softwareentwicklung sowie im Laufe der Entwicklung eines Systems durchgeführt. ⓘ

Bei der Architekturanalyse geht es darum, die Umgebung zu verstehen, in der ein vorgeschlagenes System arbeiten wird, und die Anforderungen an das System zu bestimmen. Der Input bzw. die Anforderungen für die Analyse können von einer beliebigen Anzahl von Interessengruppen kommen und beinhalten Punkte wie:

was das System im Betrieb tun wird (die funktionalen Anforderungen)
wie gut das System zur Laufzeit nicht-funktionale Anforderungen wie Zuverlässigkeit, Betriebsfähigkeit, Leistungseffizienz, Sicherheit und Kompatibilität erfüllen wird, die in der Norm ISO/IEC 25010:2011 definiert sind
nicht-funktionale Anforderungen zur Entwicklungszeit, wie Wartbarkeit und Übertragbarkeit, definiert in der Norm ISO 25010:2011
Geschäftsanforderungen und Umgebungsbedingungen eines Systems, die sich im Laufe der Zeit ändern können, wie z. B. rechtliche, soziale, finanzielle, wettbewerbsbezogene und technologische Belange ⓘ

Die Ergebnisse der Analyseaktivität sind die Anforderungen, die einen messbaren Einfluss auf die Architektur eines Softwaresystems haben, die so genannten architektonisch bedeutsamen Anforderungen. ⓘ

Architektonische Synthese oder Design ist der Prozess der Erstellung einer Architektur. Ausgehend von den durch die Analyse ermittelten architektonisch bedeutsamen Anforderungen, dem aktuellen Stand des Entwurfs und den Ergebnissen der Evaluierungsaktivitäten wird der Entwurf erstellt und verbessert. ⓘ

Bei der Evaluierung der Architektur wird ermittelt, wie gut der aktuelle Entwurf oder ein Teil davon die bei der Analyse ermittelten Anforderungen erfüllt. Eine Bewertung kann immer dann erfolgen, wenn ein Architekt eine Entwurfsentscheidung in Erwägung zieht, sie kann erfolgen, nachdem ein Teil des Entwurfs fertiggestellt wurde, sie kann erfolgen, nachdem der endgültige Entwurf fertiggestellt wurde, oder sie kann erfolgen, nachdem das System gebaut worden ist. Einige der verfügbaren Techniken zur Bewertung von Softwarearchitekturen sind die Architecture Tradeoff Analysis Method (ATAM) und TARA. Rahmenwerke für den Vergleich der Techniken werden in Rahmenwerken wie SARA Report und Architecture Reviews diskutiert: Praxis und Erfahrung. ⓘ

Architekturentwicklung ist der Prozess der Pflege und Anpassung einer bestehenden Softwarearchitektur an veränderte Anforderungen und Umgebungsbedingungen. Da die Softwarearchitektur die grundlegende Struktur eines Softwaresystems darstellt, wirkt sich ihre Entwicklung und Wartung zwangsläufig auf die grundlegende Struktur aus. Die Evolution der Architektur befasst sich also mit dem Hinzufügen neuer Funktionen sowie mit der Pflege bestehender Funktionen und des Systemverhaltens. ⓘ

Die Architektur erfordert wichtige unterstützende Aktivitäten. Diese unterstützenden Aktivitäten finden während des gesamten Kernprozesses der Softwarearchitektur statt. Dazu gehören Wissensmanagement und Kommunikation, Entwurfsüberlegungen und Entscheidungsfindung sowie Dokumentation. ⓘ

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

Softwarearchitekten folgen einer Reihe fundamentaler Entwurfsprinzipien. Mit dem Prinzip der gezielten Abstraktion von Informationen machen sie die Komplexität eines Systems beherrschbar. 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. Das Innenleben von Komponenten wird durch Schnittstellen verkapselt, was auf das Prinzip des Verbergens von Informationen (engl. information hiding) zurückgeht. 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. Eine Softwarearchitektur ist zudem häufig hierarchisch aufgebaut. Das Prinzip der konzeptionellen Integrität zielt auf eine durchgängige Anwendung von Entwurfsentscheidungen ab. ⓘ

Softwarearchitekten bedienen sich beim Entwurf oft bei bewährten Lösungen, die als sogenannte Architekturmuster dokumentiert sind. 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. Oftmals ist es die Aufgabe des Softwarearchitekten die technische Machbarkeit sowie die Kosten für nichtfunktionale Anforderungen beim Architekturentwurf zu klären. Dazu können Benutzungsszenarien entworfen werden, ähnliche Systeme 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. ⓘ

Unterstützende Aktivitäten zur Architektur

Unterstützende Softwarearchitektur-Aktivitäten werden während der Kernaktivitäten der Softwarearchitektur durchgeführt. Diese unterstützenden Aktivitäten helfen einem Softwarearchitekten bei der Durchführung von Analyse, Synthese, Bewertung und Entwicklung. Zum Beispiel muss ein Architekt in der Analysephase Wissen sammeln, Entscheidungen treffen und dokumentieren. ⓘ

Wissensmanagement und -kommunikation ist die Erforschung und Verwaltung von Wissen, das für den Entwurf einer Softwarearchitektur unerlässlich ist. Ein Softwarearchitekt arbeitet nicht in Isolation. Er erhält Inputs, funktionale und nicht-funktionale Anforderungen und Designkontexte von verschiedenen Interessengruppen und liefert den Interessengruppen Outputs. Das Wissen über die Softwarearchitektur ist oft stillschweigend vorhanden und wird in den Köpfen der Beteiligten gespeichert. Beim Wissensmanagement der Softwarearchitektur geht es darum, Wissen zu finden, zu vermitteln und zu bewahren. Da die Fragen des Softwarearchitekturdesigns komplex und voneinander abhängig sind, kann eine Wissenslücke im Designdenken zu einem falschen Softwarearchitekturdesign führen. Beispiele für Wissensmanagement und Kommunikation sind die Suche nach Entwurfsmustern, das Erstellen von Prototypen, das Befragen von erfahrenen Entwicklern und Architekten, die Bewertung der Entwürfe ähnlicher Systeme, der Wissensaustausch mit anderen Designern und Interessengruppen sowie die Dokumentation von Erfahrungen in einer Wiki-Seite.
Design-Argumentation und Entscheidungsfindung ist die Aktivität der Bewertung von Design-Entscheidungen. Diese Tätigkeit ist grundlegend für alle drei Kernaktivitäten der Softwarearchitektur. Sie beinhaltet das Sammeln und Zuordnen von Entscheidungskontexten, das Formulieren von Entscheidungsproblemen, das Finden von Lösungsoptionen und das Bewerten von Kompromissen, bevor Entscheidungen getroffen werden. Dieser Prozess findet auf verschiedenen Ebenen der Entscheidungsgranularität statt, während wichtige architektonische Anforderungen und Softwarearchitekturentscheidungen sowie die Analyse, Synthese und Bewertung der Softwarearchitektur bewertet werden. Beispiele für Argumentationsaktivitäten sind das Verstehen der Auswirkungen einer Anforderung oder eines Entwurfs auf Qualitätsattribute, das Hinterfragen der Probleme, die ein Entwurf verursachen könnte, die Bewertung möglicher Lösungsoptionen und die Evaluierung der Kompromisse zwischen Lösungen.
Dokumentation ist die Aufzeichnung des Entwurfs, der während des Softwarearchitekturprozesses erstellt wird. Der Systementwurf wird mit Hilfe mehrerer Ansichten beschrieben, zu denen häufig eine statische Ansicht gehört, die die Codestruktur des Systems zeigt, eine dynamische Ansicht, die die Aktionen des Systems während der Ausführung zeigt, und eine Bereitstellungsansicht, die zeigt, wie ein System zur Ausführung auf der Hardware platziert wird. Die 4+1-Sicht von Kruchten schlägt eine Beschreibung häufig verwendeter Sichten für die Dokumentation von Softwarearchitekturen vor; Documenting Software Architectures: Views and Beyond enthält Beschreibungen der Arten von Notationen, die innerhalb der Sichtenbeschreibung verwendet werden können. Beispiele für Dokumentationsaktivitäten sind das Schreiben einer Spezifikation, die Aufzeichnung eines Systementwurfsmodells, die Dokumentation einer Entwurfsbegründung, die Entwicklung eines Standpunkts und die Dokumentation von Ansichten. ⓘ

Themen der Softwarearchitektur

Beschreibung der Software-Architektur

Die Beschreibung von Softwarearchitekturen umfasst die Prinzipien und Praktiken der Modellierung und Darstellung von Architekturen unter Verwendung von Mechanismen wie Architekturbeschreibungssprachen, Architekturstandpunkten und Architekturrahmen. ⓘ

Architekturbeschreibungssprachen

Eine Architekturbeschreibungssprache (ADL) ist ein beliebiges Ausdrucksmittel, das zur Beschreibung einer Softwarearchitektur verwendet wird (ISO/IEC/IEEE 42010). Seit den 1990er Jahren wurden viele spezielle ADLs entwickelt, darunter AADL (SAE-Norm), Wright (entwickelt von Carnegie Mellon), Acme (entwickelt von Carnegie Mellon), xADL (entwickelt von UCI), Darwin (entwickelt vom Imperial College London), DAOP-ADL (entwickelt von der Universität Málaga), SBC-ADL (entwickelt von der National Sun Yat-Sen University) und ByADL (Universität von L'Aquila, Italien). ⓘ

Architektur-Sichtweisen

4+1 Architektur-Sichtmodell. ⓘ

Software-Architekturbeschreibungen werden üblicherweise in Sichten gegliedert, die den verschiedenen Arten von Entwürfen in der Gebäudearchitektur entsprechen. Dabei ist ein Gesichtspunkt eine Spezifikation, die die Notationen, Modellierungs- und Analysetechniken beschreibt, die in einer Sicht verwendet werden sollen, die die betreffende Architektur aus der Perspektive einer bestimmten Gruppe von Interessengruppen und deren Anliegen ausdrückt (ISO/IEC/IEEE 42010). Der Gesichtspunkt spezifiziert nicht nur die Belange, sondern auch die Darstellung, die verwendeten Modellarten, die verwendeten Konventionen und alle Konsistenzregeln (Korrespondenz), um eine Sicht mit anderen Sichten konsistent zu halten. ⓘ

Architektur-Rahmenwerke

Ein Architekturrahmenwerk erfasst die "Konventionen, Prinzipien und Praktiken für die Beschreibung von Architekturen, die innerhalb eines bestimmten Anwendungsbereichs und/oder einer Gemeinschaft von Interessengruppen festgelegt wurden" (ISO/IEC/IEEE 42010). Ein Framework wird in der Regel in Form von einem oder mehreren Viewpoints oder ADLs implementiert. ⓘ

Architektonische Stile und Muster

Ein Architekturmuster ist eine allgemeine, wiederverwendbare Lösung für ein häufig auftretendes Problem der Softwarearchitektur in einem bestimmten Kontext. Architekturmuster werden häufig als Software-Entwurfsmuster dokumentiert. ⓘ

In Anlehnung an die traditionelle Gebäudearchitektur ist ein 'Software-Architekturstil' eine spezifische Konstruktionsmethode, die durch die Merkmale gekennzeichnet ist, die sie auszeichnen" (Architekturstil). ⓘ

Ein architektonischer Stil definiert: eine Familie von Systemen im Sinne eines strukturellen Organisationsmusters; ein Vokabular von Komponenten und Konnektoren, mit Einschränkungen, wie sie kombiniert werden können. ⓘ

Architekturstile sind wiederverwendbare "Pakete" von Entwurfsentscheidungen und Einschränkungen, die auf eine Architektur angewandt werden, um bestimmte wünschenswerte Eigenschaften zu erreichen. ⓘ

Es gibt viele anerkannte Architekturmuster und -stile, darunter:

Schwarzes Brett
Client-Server (2-Tier, 3-Tier, n-Tier, Cloud Computing weisen diesen Stil auf)
Komponentenbasiert
Datenzentriert
Ereignisgesteuert (oder impliziter Aufruf)
Mehrschichtige (oder mehrschichtige Architektur)
Microservices-Architektur
Monolithische Anwendung
Peer-to-Peer (P2P)
Rohre und Filter
Plug-ins
Reaktive Architektur
Repräsentative Zustandsübertragung (REST)
Regelbasiert
Dienstorientiert
Architektur des geteilten Nichts
Raumbasierte Architektur ⓘ

Einige betrachten Architekturmuster und Architekturstile als dasselbe, andere betrachten Stile als Spezialisierungen von Mustern. Was sie gemeinsam haben, ist, dass sowohl Muster als auch Stile Idiome für Architekten sind, die eine gemeinsame Sprache" oder ein gemeinsames Vokabular" für die Beschreibung von Systemklassen bieten. ⓘ

Softwarearchitektur und agile Entwicklung

Es gibt auch Bedenken, dass die Softwarearchitektur zu viel Big Design Up Front mit sich bringt, insbesondere bei den Befürwortern der agilen Softwareentwicklung. Es wurde eine Reihe von Methoden entwickelt, um die Kompromisse zwischen Up-Front-Design und Agilität auszugleichen, darunter die agile Methode DSDM, die eine "Foundations"-Phase vorschreibt, in der "gerade genug" architektonische Grundlagen gelegt werden. IEEE Software hat der Interaktion zwischen Agilität und Architektur eine Sonderausgabe gewidmet. ⓘ

Erosion der Softwarearchitektur

Die Erosion der Softwarearchitektur (oder der "Verfall") bezieht sich auf die Lücke zwischen der geplanten und der tatsächlichen Architektur eines Softwaresystems, wie sie sich in der Implementierung zeigt. Softwarearchitektur-Erosion tritt auf, wenn Implementierungsentscheidungen entweder die geplante Architektur nicht vollständig erreichen oder anderweitig gegen Beschränkungen oder Prinzipien dieser Architektur verstoßen. ⓘ

Nehmen wir als Beispiel ein streng geschichtetes System, bei dem jede Schicht nur Dienste nutzen kann, die von der unmittelbar darunter liegenden Schicht bereitgestellt werden. Jede Quellcodekomponente, die diese Einschränkung nicht beachtet, stellt eine Verletzung der Architektur dar. Werden solche Verletzungen nicht korrigiert, kann die Architektur in einen monolithischen Block verwandelt werden, was sich negativ auf die Verständlichkeit, Wartbarkeit und Entwicklungsfähigkeit auswirkt. ⓘ

Es wurden verschiedene Ansätze vorgeschlagen, um der Erosion entgegenzuwirken. "Diese Ansätze, zu denen Werkzeuge, Techniken und Prozesse gehören, werden hauptsächlich in drei allgemeine Kategorien eingeteilt, die versuchen, die Erosion der Architektur zu minimieren, zu verhindern und zu beheben. Innerhalb dieser allgemeinen Kategorien wird jeder Ansatz weiter untergliedert und spiegelt die High-Level-Strategien wider, die zur Bekämpfung der Erosion eingesetzt werden. Dabei handelt es sich um prozessorientierte Architekturkonformität, Management der Architekturevolution, Durchsetzung des Architekturdesigns, Verknüpfung von Architektur und Implementierung, Selbstanpassung und Techniken zur Wiederherstellung der Architektur, bestehend aus Wiederherstellung, Entdeckung und Versöhnung". ⓘ

Es gibt zwei Haupttechniken zur Erkennung von Architekturverstößen: Reflexionsmodelle und domänenspezifische Sprachen. Reflexionsmodelltechniken (RM) vergleichen ein von den Systemarchitekten bereitgestelltes High-Level-Modell mit der Quellcode-Implementierung. Es gibt auch domänenspezifische Sprachen, deren Schwerpunkt auf der Spezifizierung und Überprüfung von Architekturbeschränkungen liegt. ⓘ

Wiederherstellung der Softwarearchitektur

Die Wiederherstellung der Softwarearchitektur (oder Rekonstruktion bzw. Reverse Engineering) umfasst die Methoden, Techniken und Prozesse, mit denen die Architektur eines Softwaresystems anhand der verfügbaren Informationen, einschließlich der Implementierung und Dokumentation, aufgedeckt wird. Die Wiederherstellung der Architektur ist oft notwendig, um angesichts veralteter oder nicht mehr aktueller Dokumentation fundierte Entscheidungen zu treffen und Erosion der Architektur: Implementierungs- und Wartungsentscheidungen, die von der geplanten Architektur abweichen. Es gibt Praktiken zur Wiederherstellung der Softwarearchitektur in Form einer statischen Programmanalyse. Dies ist ein Teil der Themen, die von der Software Intelligence Praxis abgedeckt werden. ⓘ

Definition

Eine Definition von Helmut Balzert beschreibt den Begriff als „eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“. Die Architekturkomponenten bilden eine Zerlegung des Gesamtsystems, was bedeutet, dass jedes Softwareelement genau 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“. ⓘ

Insgesamt gibt es eine Reihe von verschiedenen Definitionen für diesen Begriff. ⓘ

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

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 umgebenden 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 ermöglicht eine gut konstruierte Softwarearchitektur 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

Diagramm der Wikimedia-Server-Architektur ⓘ

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. ⓘ

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. ⓘ

Ein wichtiges Qualitätsmerkmal von Softwarearchitekturen ist ihre Stetigkeit in Bezug auf Änderungen an den durch die Software zu lösenden Problemen. Kleine Änderungen der Problemstellung 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 eine Softwarearchitektur definieren kann, die bei kleinen Änderungen in der Problemstellung nicht oder nur wenig geändert werden muss. In der Agilen Softwareentwicklung spricht man in diesem Zusammenhang von Design for Change – eine Softwarearchitektur die offen gegenüber jedweden Änderungen der Problemstellung ist. Diese zu erreichen bedient man sich des emergenten Designs – eine sukzessive wachsende Softwarearchitektur die genau dort flexibel ist, wo sich die Anforderungen oft ändern. ⓘ

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

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