Die Beschreibung einer Softwarearchitektur ist die Gesamtheit der Praktiken zum Ausdrücken, Kommunizieren und Analysieren von Softwarearchitekturen (auch Architekturdarstellung genannt) sowie das Ergebnis der Anwendung solcher Praktiken durch ein Arbeitsprodukt, das eine Softwarearchitektur ausdrückt ( ISO/IEC/IEEE 42010 ).

Architekturbeschreibungen (ADs) werden manchmal auch als Architekturdarstellungen , Architekturspezifikationen [ 1 ] oder Softwarearchitekturdokumentation bezeichnet .

Konzepte

Die Architekturbeschreibung definiert die Praktiken, Techniken und Darstellungsformen, die Softwarearchitekten zur Dokumentation einer Softwarearchitektur verwenden. Sie ist im Wesentlichen eine Modellierungsaktivität ( Softwarearchitekturmodell ). Architekturmodelle können verschiedene Formen annehmen, darunter Text, informelle Zeichnungen, Diagramme oder andere Formalismen ( Modellierungssprache ). Eine Architekturbeschreibung verwendet häufig mehrere verschiedene Modelltypen , um unterschiedliche Zielgruppen – die Stakeholder (wie Endbenutzer, Systemverantwortliche, Softwareentwickler, Systemingenieure, Projektmanager) – und verschiedene architektonische Aspekte (wie Funktionalität, Sicherheit, Bereitstellung, Zuverlässigkeit und Skalierbarkeit) effektiv zu berücksichtigen.

Die Modelle einer Architekturbeschreibung sind häufig in mehrere Architektursichten unterteilt, wobei jede Sicht spezifische Belange verschiedener Stakeholder des Systems berücksichtigt. [ 2 ] Eine Architektursicht ist eine Betrachtungsweise eines Systems ( RM ODP ). Jede Sicht in einer Architekturbeschreibung sollte eine Dokumentation der relevanten Belange und Stakeholder sowie der verwendeten Modellarten, Notationen und Modellierungskonventionen enthalten ( ISO/IEC/IEEE 42010 ).

Die Verwendung mehrerer Ansichten ist zwar effektiv für die Kommunikation mit verschiedenen Interessengruppen sowie für die Erfassung und Analyse unterschiedlicher Anliegen, birgt aber auch potenzielle Probleme: Da Ansichten in der Regel nicht unabhängig sind, kann es aufgrund möglicher Überschneidungen zu Redundanzen oder Inkonsistenzen zwischen den Ansichten eines einzelnen Systems kommen. [ 3 ] Verschiedene Mechanismen können eingesetzt werden, um Korrespondenzen zwischen Ansichten zu definieren und zu verwalten, Details auszutauschen, Redundanzen zu reduzieren und Konsistenz zu gewährleisten.

Ein häufiges Missverständnis bezüglich Architekturbeschreibungen (ADs) ist, dass sie sich ausschließlich mit technischen Aspekten befassen. Tatsächlich müssen ADs jedoch Belange vieler Stakeholder berücksichtigen. Einige Aspekte sind technischer Natur, viele jedoch nicht: ADs dienen Architekten, ihren Kunden und anderen Beteiligten dazu, Kosten, Termine und Prozesse zu steuern. Ein damit verbundenes Missverständnis ist, dass ADs nur die strukturellen Aspekte eines Systems behandeln. Dies genügt jedoch selten den Bedürfnissen der Stakeholder, deren Anliegen oft strukturelle, verhaltensbezogene, ästhetische und weitere „nicht-funktionale“ Aspekte umfassen.

Geschichte

Die frühesten Architekturbeschreibungen verwendeten informelle Bilder und Diagramme sowie zugehörigen Text. Informelle Beschreibungen sind nach wie vor die am weitesten verbreiteten Darstellungsformen in der Industrie. [ 4 ] Einflüsse auf die Architekturbeschreibung kamen aus den Bereichen Software-Engineering (wie Datenabstraktion und Programmierung im großen Maßstab) und Systemdesign (wie SARA [ 5 ] ).

Die Arbeit an Programmiersprachen im großen Maßstab, wie beispielsweise Modulverbindungssprachen (MILs), konzentrierte sich auf die Beschreibung der großskaligen Eigenschaften von Software: [ 6 ] Module (einschließlich Programme, Bibliotheken, Unterprogramme und Subsysteme) und Modulbeziehungen (Abhängigkeiten und Verbindungen zwischen Modulen). Diese Arbeiten beeinflussten sowohl das architektonische Denken über Programmiersprachen (z. B. Ada) als auch Entwurfs- und Architekturnotationen (wie Buhr-Diagramme und Anwendungsfalldiagramme, kodifiziert in den Architekturmerkmalen von UML: Pakete, Subsysteme, Abhängigkeiten) und einen Großteil der Arbeit an Architekturbeschreibungssprachen. Zusätzlich zu MILs wurden, beeinflusst durch die etablierte Forschung in den Bereichen Anforderungsmanagement und Entwurf innerhalb der Softwareentwicklung, verschiedene Arten von Modellen aus der Softwareentwicklung und dem Entwurf übernommen, um sie zur Beschreibung von Architekturen anzuwenden. Dazu gehörten Funktions- und Aktivitätsmodelle aus der strukturierten Analyse (SADT) , Datenmodellierungstechniken (Entity-Relationship-Modell) und objektorientierte Techniken.

Perry und Wolf [ 1 ] führten das Beispiel der Gebäudearchitektur für die Rolle mehrerer Ansichten an: „Ein Gebäudearchitekt arbeitet mit dem Kunden mittels einer Reihe unterschiedlicher Ansichten zusammen, in denen jeweils ein bestimmter Aspekt des Gebäudes hervorgehoben wird.“

Perry und Wolf postulierten, dass die Darstellung von Architekturen Folgendes umfassen sollte: { Elemente, Form und Begründung } , wobei sie drei Arten von Elementen (und somit drei Arten von Ansichten) unterschieden:

  • Verarbeitung: wie die Daten transformiert werden;
  • Daten: Informationen, die genutzt und transformiert werden;
  • Verbindung: Klebstoff, der die anderen Elemente zusammenhält;

Perry und Wolf identifizierten vier Ziele oder Verwendungszwecke für Architekturbeschreibungen (in ihrer Arbeit als „Architekturspezifikationen“ bezeichnet):

  • architektonische Beschränkungen vorschreiben, ohne Lösungen zu überspezifizieren
  • Ästhetik und Technik trennen
  • die verschiedenen Aspekte der Architektur jeweils auf angemessene Weise zum Ausdruck bringen
  • Architekturanalysen durchführen, insbesondere Abhängigkeits- und Konsistenzanalysen.

Im Anschluss an die Arbeit von Perry und Wolf entwickelten sich zwei Denkrichtungen zur Beschreibung von Softwarearchitekturen:

  • Schule mit mehreren Ansichten
  • Strukturalistische Schule

Mechanismen zur Architekturbeschreibung

Für die Architekturbeschreibung werden mehrere gängige Mechanismen verwendet. Diese Mechanismen erleichtern die Wiederverwendung bewährter Beschreibungsstile, sodass diese auf viele Systeme angewendet werden können:

  • Architekturperspektiven
  • Architekturbeschreibungssprachen
  • Architektur-Frameworks

Architekturperspektiven

Softwarearchitekturbeschreibungen sind üblicherweise in Sichten organisiert , analog zu den verschiedenen Arten von Bauplänen . Jede Sicht behandelt eine Reihe von Systemaspekten gemäß den Konventionen ihres Standpunkts . Ein Standpunkt ist eine Spezifikation, die die Notationen und Modellierungstechniken beschreibt, die in einer Sicht verwendet werden, um die betreffende Architektur aus der Perspektive bestimmter Stakeholder und ihrer Anliegen darzustellen ( ISO/IEC 42010 ). Der Standpunkt spezifiziert nicht nur die dargestellten (d. h. zu behandelnden) Aspekte, sondern auch die Darstellung, die verwendeten Modelltypen, die Konventionen und alle Konsistenzregeln, um die Konsistenz einer Sicht mit anderen Sichten zu gewährleisten.

Beispiele für Standpunkte sind:

  • Funktionale Sichtweise
  • Logischer Standpunkt
  • Informations-/Datenperspektive
  • Modulperspektive
  • Komponenten- und Verbindungsansicht
  • Anforderungen aus Sicht der Anforderungen
  • Entwickler-/Implementierungsperspektive
  • Sichtweise auf Parallelität/Prozesse/Laufzeit/Threads/Ausführung
  • Leistungsperspektive
  • Sicherheitsperspektive
  • Physische/Bereitstellungs-/Installationsperspektive
  • Sichtweise auf Nutzeraktionen/Feedback

Der Begriff Viewtype bezeichnet Kategorien ähnlicher Ansichten, die einen gemeinsamen Satz von Elementen und Beziehungen aufweisen. [ 4 ]

Architekturbeschreibungssprachen

Eine Architekturbeschreibungssprache ( ADL ) ist ein Ausdrucksmittel zur Beschreibung einer Softwarearchitektur ( ISO/IEC/IEEE 42010 ). Seit den 1990er-Jahren wurden zahlreiche spezialisierte ADLs entwickelt, darunter AADL (SAE-Standard), Wright (Carnegie Mellon University), Acme (Carnegie Mellon University), xADL (UCI), Darwin ( Imperial College London ), DAOP-ADL (Universität Málaga) und ByADL (Universität L’Aquila, Italien). Frühe ADLs legten den Schwerpunkt auf die Modellierung von Systemen anhand ihrer Komponenten, Konnektoren und Konfigurationen. Neuere ADLs (wie ArchiMate und SysML) sind eher „breitbandige“ Sprachen, die neben Komponenten und Konnektoren auch eine Vielzahl anderer Aspekte durch mehrere Subsprachen beschreiben können. Neben Spezialsprachen können auch bestehende Sprachen wie UML als ADLs „für die Analyse, den Entwurf und die Implementierung softwarebasierter Systeme sowie für die Modellierung von Geschäftsprozessen und ähnlichen Prozessen“ verwendet werden .

Architektur-Frameworks

Ein Architektur-Framework erfasst die „Konventionen, Prinzipien und Praktiken zur Beschreibung von Architekturen, die innerhalb eines spezifischen Anwendungsbereichs und/oder einer bestimmten Interessengruppe etabliert sind“ ( ISO/IEC/IEEE 42010 ). Ein Framework wird üblicherweise anhand eines oder mehrerer Sichtweisen oder Architekturbeschreibungsebenen (ADLs) implementiert. Zu den relevanten Frameworks in der Softwarearchitektur gehören:

Mehrere Ansichten

Dieser Ansatz, der in Kruchtens einflussreicher Arbeit von 1995 zum „4+1-Sichtmodell“ dargestellt wird , betont die zu modellierenden unterschiedlichen Interessengruppen und Anliegen. [ 2 ]

Strukturalismus

Zweitens, wie sie in Arbeiten der CMU und anderer Institutionen zum Ausdruck kommt, die Vorstellung, dass Architektur die übergeordnete Organisation eines Systems zur Laufzeit ist und dass Architektur anhand ihrer Komponenten und Verbindungen beschrieben werden sollte: „Die Architektur eines Softwaresystems definiert dieses System anhand von Rechenkomponenten und Interaktionen zwischen diesen Komponenten.“ [ 7 ]

In den 1990er- und 2000er-Jahren konzentrierte sich die akademische Arbeit zu Architekturbeschreibungsmodellen (ADLs) größtenteils auf das Paradigma von Komponenten und Konnektoren. Diese ADLs fanden jedoch in der Industrie kaum Anwendung. [ 8 ] Seit den 1990er-Jahren hat sich eine Angleichung der Ansätze zur Architekturbeschreibung vollzogen. Die IEEE-Norm 1471 aus dem Jahr 2000 kodifizierte bewährte Verfahren: Sie unterstützt, aber schreibt nicht vor, mehrere Sichtweisen in einer Architekturbeschreibung zu berücksichtigen.

Architekturbeschreibung durch Entscheidungen

Aufbauend auf der Begründungsaspekt der ursprünglichen Formel von Perry und Wolf hat sich eine dritte Denkrichtung herausgebildet, die Entscheidungen und deren Begründungen als wesentliches Mittel zur Konzeption und Darstellung einer Softwarearchitektur dokumentiert. [ 9 ] Dieser Ansatz behandelt Entscheidungen als gleichberechtigte Elemente der Architekturbeschreibung und macht damit explizit, was in früheren Darstellungen oft implizit war.

Verwendung von Architekturbeschreibungen

Architekturbeschreibungen dienen einer Vielzahl von Zwecken, unter anderem ( ISO/IEC/IEEE 42010 ):

  • zur Steuerung des Systemaufbaus und der Systemwartung
  • zur Unterstützung der Systemplanung, Kostenkalkulation und Weiterentwicklung
  • als Medium zur Analyse, Bewertung oder zum Vergleich von Architekturen dienen
  • um die Kommunikation zwischen den Systembeteiligten hinsichtlich der Architektur und des Systems zu erleichtern
  • Architekturwissen über den Rahmen einzelner Projekte hinaus zu dokumentieren (z. B. Software-Produktlinien und Produktfamilien sowie Referenzarchitekturen).
  • um wiederverwendbare architektonische Idiome (wie Architekturstile und -muster) zu erfassen

Referenzen

  1. ^ a b Perry, DE; Wolf, AL (1992). „Grundlagen für das Studium der Softwarearchitektur“. ACM SIGSOFT Software Engineering Notes 17 (4): 40. doi:10.1145/141874.141884
  2. ^ a b P. B. Kruchten, „Das '4+1'-Sichtmodell der Architektur“, IEEE Software, Bd. 12, Nr. 6, S. 42–50, November 1995
  3. ^ A. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein und M. Goedicke. Viewpoints: Ein Rahmenwerk zur Integration multipler Perspektiven in die Systementwicklung. International Journal of Software Engineering and Knowledge Engineering, 2(1):31-58, 1992.
  4. ^ a b P. C. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord und J. Stafford, Documenting Software Architectures: views and beyond. Addison Wesley, 2003.
  5. ^ G. Estrin , RS Fenchel, RR Razouk, MK Vernon , "TheSystem AR chitect 's Apprentice ", IEEE Transactions of Software Engineering, 1986.
  6. ^ F. DeRemer und HH Kron, „Programming-in-the-Large Versus Programming-in-the-Small“, IEEE Transactions on Software Engineering, 1976.
  7. ^ M. Shaw und D. Garlan, Software Architecture: perspectives on an emerging discipline, Prentice Hall, 1996.
  8. ^ E. Woods und R. Hilliard, „Architekturbeschreibungssprachen in der Praxis“ http://doi.ieeecomputersociety.org/10.1109/WICSA.2005.15
  9. ^ A. Jansen und J. Bosch, „Software Architecture as a Set of Architectural Design Decisions“ Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture, 2005.

Siehe auch