Die Architektur eines Softwaresystems beschreibt dieses als Komponenten zusammen mit den Verbindungen, die zwischen den Komponenten bestehen. Eine Software-Architektur beschreibt noch nicht den detaillierten Entwurf, vielmehr geht es darum, die Zusammenhänge zwischen den Anforderungen und dem zu konstruierenden System zu beschreiben. Die Architektur eines Softwaresystems beschreibt dieses als Komponenten zusammen mit den Verbindungen, die zwischen den Komponenten bestehen. Eine Software-Architektur beschreibt noch nicht den detaillierten Entwurf, vielmehr geht es darum, die Zusammenhänge zwischen den Anforderungen und dem zu konstruierenden System zu beschreiben, möglichst mit einer Begründung für die Entwurfsentscheidungen. Die Wahl einer bestimmten Architektur hat dann einen erheblichen Einfluss auf die nicht-funktionalen, qualitativen Eigenschaften der resultierenden Systeme. Der Begriff Software-Architektur Eine detaillierte Terminologiediskussion des Begriffs Software-Architektur möchten wir hier nicht führen: Am Software Engineering Institute der Carnegie Mellon University gibt es beispielsweise eine lange Auflistung von vorgeschlagenen Definitionen [17]. Stattdessen konzentrieren wir uns auf die Aufgaben und den Zweck der Beschreibung von Software-Architekturen und verwenden die Terminologie des IEEE-Standards 1471-2000 zur Software Architekturbeschreibung [8]. Definition (Software-Architektur) Die grundlegende Organisation eines Systems, dargestellt durch dessen Komponenten, deren Beziehungen zueinander und zur Umgebung sowie den Prinzipien, die den Entwurf und die Evolution des Systems bestimmen. Architekturmuster und stile Entwurfsmuster [14] können als Mikro-Architekturen betrachtet werden. Beispielsweise beschreibt das Composite-Muster für den objektorientierten Entwurf eine bewährte Struktur für die hierarchische, rekursive Strukturierung zusammengesetzter Objekte. Architekturmuster hingegen beschreiben den Stil der Gesamtarchitektur eines Systems. Ein bewährtes Architekturmuster ist die hierarchische Schichtenarchitektur, bei der Komponenten einer Schicht immer nur auf Komponenten darunter liegender Schichten, evtl. auch über mehrere Schichten hinweg, zugreifen dürfen. Die Client/Server- Architektur ist ein solches Architekturmuster, bei dem zumeist viele Clients auf wenige Server zugreifen. Das Client/Server-Architekturmuster wurde beispielsweise im SAP R/3 System schon frühzeitig auf drei Schichten erweitert, wobei zwischen der Datenhaltungs-, der Geschäftslogik- und der Präsentationsschicht unterschieden wird. Diese Drei-Schichten-Architektur hat sich inzwischen für betriebliche Informationssysteme etabliert. Bei Web-Informationssystemen wird die Präsentationsschicht noch weiter in den Web-Server und Web-Browser aufgeteilt. Eine exakte zwischen Entwurfsmustern und Architek turmustern ist nicht immer möglich. Beispielsweise kann das Client/Server-Architekturmuster mit dem Observer-Entwurfsmuster so kombiniert werden, dass beim Server registrierte Clients automatisch über Änderungen im Server informiert werden. Eine Erweiterung des Client/Server-Architekturmusters stellen Peer-To-Peer-Architekturen dar [18]. In Peer-To-Peer-Architekturen kann jede Komponente sowohl die Rolle eines Clients als auch eines
Servers einnehmen. Dieses Architekturmuster kann noch speziali siert werden zu rein dezentralen strukturierten (z. B. Chord) und unstrukturierten (z. B. Free net) Architekturen sowie zentralisierten hybriden (z. B. Napster) und Super-Peer-Architekturen (z. B. KaZaA). In Service-orientierten Architekturen [16] werden Dienste über einen Enterprise Service Bus lose gekoppelt. Hinter Dienst-Schnittstellen stehen dann Dienst-Implementierungen (Komponenten), die über den Bus aufgerufen werden können. Auf technologischer Ebene werden die Schnittstellen beispielsweise mit CORBA in IDL und mit Web Services in WSDL spezifiziert. Service-orientierte Architekturen sind zur Zeit sehr populär im Kontext betrieblicher Informationssysteme, da bei entsprechender Unterstützung aus dem Management eine ganzheitliche Sicht auf die Integration von Softwaresystemen erreicht werden kann, in der insbesondere auch die Geschäftsprozesse durch Orchestrierung der Dienstaufrufe unterstützt werden können. Komponenten-orientierte Architekturen, wie z. B. Autosar, verwenden auch einen zentralen Bus zum gegenseitigen Aufruf der Komponenten, berücksichtigen aber auch das Zusammensetzen einzelner Komponenten zu größeren Komponenten sowie generell deren Installationskontext (Deployment). Architekturen für konkrete Softwaresysteme sollten dann derartigen Mustern folgen, um auf bewährten Strukturen zu basieren. Ein Grundprinzip von Architektur- und Entwurfsmustern besteht darin, dass nur solche Lösungsstrukturen als Muster katalogisiert werden dürfen, die sich in mindestens 23 relevanten Projekten erfolgreich bewährt haben. Die Beschreibung von Mustern erfolgt üblicherweise in Katalogen mit einer einheitlichen Strukturierung. Beispielsweise wird für jedes Architekturmuster von Fowler et al. [5] zunächst das Problem beschrieben, dann die Funktionsweise erläutert (u.a. mittels UML), dann der sinnvolle Einsatzkontext eingegrenzt, evtl. weiterführende Literaturhinweise angegeben und abschließend einige Beispielimplementierungen skizziert (in Java und C#). Die eher abstrakte Musterbeschreibung in der UML wird anhand beispielhafter Implementierungen illustriert. Aufgaben und Zweck der Modellierung von Software-Architekturen Jedes Softwaresystem hat eine Architektur, auch wenn diese nicht explizit modelliert wurde. Es stellt sich die Frage, zu welchem Zweck die Architekturen eigentlich modelliert werden sollten und welche Aufgaben dabei zu erledigen sind. Die Modellierung erfordert einen Aufwand, der gerechtfertigt sein sollte. Die konzeptuelle Karte [12] in Abb. 1 wurde vor diesem Hintergrund auf der Tagung Modellierung 2005 erarbeitet [7] und im GI-Arbeitskreis Software-Architekturen diskutiert [6]. Ziel der entsprechenden Diskussionen in diesem Rahmen war eine Erhebung der Aufgaben und des Zwecks der Modellierung von Software-Architekturen. Die Modellierung von Software-Architekturen sollte keinen Selbstzweck darstellen, sondern einen Mehrwert bieten, damit sich der damit verbundene Aufwand lohnt, insbesondere wenn formale Techniken eingesetzt werden. Die Aspekte der Modellierung von Software-Architekturen können wie folgt charakterisiert werden: Beschreibung Anfang der neunziger Jahre wurden insbesondere in den USA diverse Forschungsprojekte unter dem Titel Software-Architektur gestartet, die sich zunächst überwiegend auf die Entwick lung spezieller Sprachen für die Beschreibung von Software-Architekturen konzentrierten, so genannte Architekturbeschreibungssprachen [11]. Mit der Version 2 der UML sind inzwischen mit den Kompositionsstrukturdiagrammen auch Möglichkeiten zur Software-Architekturbeschreibung in die UML eingeflossen [9]. Mit den UML-Verteilungsdiagrammen war bereits in älteren Versionen der UML eine (beschränkte) Möglichkeit zur Beschreibung von Systemarchitekturen gegeben. Beschreibungen können mit unterschiedlichen Notationen erfolgen, evtl. sogar mathematisch formal bezüglich der Beschreibungstechniken und der zugehörigen Konzepte der Viewpoints und Views sei auf den
IEEE-Standard verwiesen [8]. Ziele Die Modellierung von Software-Architekturen dient der Dokumentation, Kommunikation und Verständigung über Architekturen [3]. Darüber hinaus ist es für das strategische Informationsmanagement ein wichtiges Werkzeug zur Beschreibung von betrieblichen Informationssystemen. Die Modellierung der Architektur ist der erste Schritt zum Systementwurf, der dann noch weiter detailliert werden muss. Eine frühzeitige Bewertung des Entwurfs ist bereits auf dieser Ebene möglich und sinnvoll (siehe nächster Punkt). Evaluation/Bewertung Die Modellierung von Software-Architekturen zielt insbesondere auch auf die Bewertung nichtfunktionaler, qualitativer Aspekte von Softwaresystemen, so dass die Evaluation in Abb. 1 als eigener Zweig dargestellt und ausgebreitet wird. Ein zentrales Ziel ist dabei die Bewertung der Qualität der modellierten Softwaresysteme, bevor diese realisiert werden. Die Genauigkeit der Bewertungen sollte am später realisierten System überprüft werden, um zukünftige Vorhersagen zu verbessern. Software- Architekturen werden analysierbar und quantitativ/qualitativ vergleichbar, um bei der Auswahl von Architekturvarianten systematisch als Vorhersagetechnik eingesetzt zu werden [15, Teil IV]. Prototyping und Simulation zur experimentellen Exploration von Entwurfsalternativen werden ermöglicht [2]. Prozess, Wiederverwendung, Evolution, Rahmenbedingungen Der Prozess zur Modellierung sollte, wie die Entwicklung generell, iterativ und inkrementell erfolgen sowie die Weiterentwicklung der beschriebenen Systeme unterstützen [15, Teil II]. Wiederverwendung wird durch Muster, Stile und Referenzarchitekturen unterstützt [15, Teil V]. Während der Entwicklung sind diverse Rahmenbedingungen zu beachten, die den Architekturentwurf beeinflussen. Software- Architekturen unterstützen das Verständnis und damit die Wiederverwendung und Weiterentwicklung von (Alt-)Systemen. Viele Konzepte treffen generell auf die Modellierung in der Informatik zu, die Konzepte mit für die Architekturmodellierung spezifischen Anforderungen und Techniken sind in Abb. 1 durch das Piktogramm markiert. Insbesondere für die Wiederverwendung und die Weiterentwicklung spielen Software-Architekturen in diversen Zusammenhängen eine zentrale Rolle. Auch für die
Berücksichtigung existierender Infrastrukturen und deren Reverse Engineering gibt es besondere Anforderungen. Die Bewertung von Architekturen zielt auf Qualitätseigenschaften, die wir im Folgenden betrachten. Qualitätseigenschaften von Software-Architekturen Grundsätzlich ist zu unterscheiden zwischen den Qualitätseigenschaften der Architekturen selbst und den Qualitätseigenschaften der beschriebenen Softwaresysteme. Die Qualität der Architekturmodelle selbst ist schwer zu quantifizieren. Eigenschaften wie Verständlichkeit und Ästhetik werden im Allgemeinen sehr subjektiv bewertet. Qualitätsmerkmale von Softwaresystemen wurden im ISO/IEC- Standard 9126 standardisiert [10]. Dabei wird zwischen Charakteristika und Systemattributen unterschieden. Charakteristika (z. B. Effizienz) werden durch Systemattribute (z. B. Durchsatz oder Antwortzeit) bestimmt und durch Metriken gemessen (z. B. Anzahl bearbeiteter Aufträge je Zeiteinheit oder Millisekunden). Während der Entwicklung einer Software-Architektur sind verschiedenste Entscheidungen zu treffen. In der Praxis kann die Vielzahl der Ziele selten vollständig erfüllt werden, häufig widersprechen sie sich sogar. Beispielsweise wird eine Erhöhung der Sicherheit häufig die Performanz beeinträchtigen. Ziele sollten deshalb priorisiert werden, um sie im Fall eines Konflikts gegeneinander abwägen zu können. Die Entscheidung für bestimmte Architekturmuster und -stile für ein zu entwickelndes System ist die erste wesentliche Weichenstellung zur Erreichung bestimmter Qualitätsmerkmale. Die Rolle der Software-Architekten Häufig wird die Rolle der Software-Architekten mit der Rolle der Gebäudearchitekten verglichen [13]. Eine Ursache für diesen Vergleich dürfte in der populären Analogie zwischen Entwurfsmustern [14] und Gebäudemustern [1] liegen. Gerade bei der Betrachtung großer, komplexer Software- Architekturen z. B. für betriebliche Informationssysteme muss dieser Vergleich jedoch erweitert werden. Für betriebliche Informationssysteme müssen im Allgemeinen viele heterogene Informationssysteme geeignet gekoppelt werden, wie es im so genannten Enterprise Application Integration angestrebt wird [4]. In derartigen Umgebungen passt die Analogie zur Stadtplanung besser. Auch bei der Stadtplanung müssen viele, teils konkurrierende Interessen (fließender Straßenverkehr, öffentlicher Nahverkehr, ruhiger Wohnraum etc.) vereinbart werden. Das trifft auch für den Entwurf komplexer betrieblicher Informationssysteme zu. Die zu berücksichtigenden Interessen sind im Allgemeinen wesentlich zahlreicher als das beim Bau einzelner Gebäude der Fall ist. Dies soll nicht heißen, dass der Gebäudeentwurf eine einfache Aufgabe darstellt; der Hausbau ist eine anschauliche Analogie zur Konstruktion einzelner Softwaresysteme. Ausblick: Software-Architekturen für verlässliche und vertrauenswürdige Systeme Zukünftig wird die Erreichung einer hohen Qualität von Softwaresystemen eine zunehmende Bedeutung erlangen, damit wir auf die Verlässlichkeit und Sicherheit dieser Systeme vertrauen können [19]. Software-Architekturen werden ein wichtiges Instrument zur Erreichung dieser Ziele darstellen, natürlich nicht das einzige. Die Entscheidung für ein bestimmtes Architekturmuster bestimmt noch nicht die Architektur eines konkreten Systems, diese muss noch konkretisiert werden. Eine wichtige Entscheidung, die dann zu treffen ist, ist die Frage des Detaillierungsgrades einer Architekturbeschreibung. Mit der UML beispielsweise können Architekturen auf eher abstraktem Niveau beschrieben werden, aber auch schon als Detailentwurf bis hin zur automatischen Transformation in ein Programm, wie es mit der Model Driven Architecture der OMG angestrebt wird. Eine gute Software-
Architektur allein garantiert noch keine verlässlichen und sicheren Systeme, sie ist aber eine wichtige Grundlage zur Erreichung dieser Ziele. Literatur: 1. 2. 3. 4. 5. Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I. und Angel, S.: A Pattern Language: Towns/Buildings/Construction. Oxford University Press, New York, 1977. Bardram, J.E., Christensen, H.B., Corry, A.V., Hansen, K.M. und Ingstrup, M.: Exploring Quality Attributes using Architectural Prototyping. In: Proc. First International Conference on the Quality of Software Architectures (QoSA 2005), LNCS, Erfurt, Germany, September 2005. Springer-Verlag. Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R. und Stafford, J.: Documenting Software Architectures: Views and Beyond. Addison-Wesley, 2002. Conrad, S., Hasselbring, W., Koschel, A. und Tritsch, R.: Enterprise Application Inte gration. Spektrum Akademischer Verlag, 2006. Fowler, M., Rice, D., Foemmel, M., Hieatt, E., Mee, R. und Stafford, R.: Patterns of Enterprise Application Architecture. Addison-Wesley, 2003. 6. GI-Arbeitskreis: Software-Architekturen. se.informatik.uni-oldenburg.de GIAKSoftArch/. 7. Hasselbring, W.: Modelling Software Architectures. In: Paech, B. und Desel, J. (Hrsg.): Tagungsband zur Modellierung 2005, Seite 47, Heidelberg, März 2005. www.es.tu-darmstadt.de/gimodellierung/archive/gesamtberichtmod2005.pdf. IEEE: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, 2000. IEEE Standard 1471-2000. 8. 9. 10. Jeckle, M., Rupp, C., Hahn, J., Zengler, B. und Queins, S.: UML 2 glasklar. Hanser Fachbuchverlag, 2005. Jung, H.-W., Kim, S.-G. und Chung, C.-S.: Measuring Software Product Quality: A Survey of ISO/IEC 9126. IEEE Software, 21 (5):8892, 2004. Medvidovic, N. und Taylor, R.N.: A Classification and Comparison Framework for Software Architecture Description Languages. IEEE Transactions on Software Engi neering, 26(1):7093, Januar 2000. 11. Nückles, M., Gurlitt, J., Pabst, T. und Renkl, A: Mind Maps und Concept Maps: Vi 12. sualisieren Organisieren Kommunizieren. Beck-Wirtschaftsberater im dtv, Mün chen, 2004. 13. Pfister, C. und Weck, W.: How to Fit the Architect into the Project Team? In: Bal zer, B. und Obbink, H. (Hrsg.): Fourth International Software Architecture Workshop (ISAW-4), S. 2730, Limerick, Ireland, Juni 2000. 14. Quibeldey-Cirkel, K.: Entwurfsmuster Das aktuelle Schlagwort. Informatik Spek trum, 19(6):326327, 1996. 15. Reussner, R. und Hasselbring, W. (Hrsg.): Handbuch Software-Architektur. Dpunkt Verlag, 2006. 16. Richter, J.-P., Haller, H. und Schrey, P.: Serviceorientierte Architektur Das aktuelle Schlagwort. Informatik Spektrum, 28(5):413416, 2005. 17. 18. 19. Software Engineering Institute (SEI), Carnegie Mellon University: How Do You De fine Software Architecture? www.sei.cmu.edu/architecture/definitions.html, 2005. Steinmetz, R. und Wehrle, K.: Peer-to-Peer-Networking & -Computing Das aktuelle Schlagwort. Informatik Spektrum, 27(1):5154, 2004. TrustSoft: Trustworthy software systems. www.trustsoft.org. Autor & Copyright
Wilhelm Hasselbring Carl-von-Ossietzky Universität Oldenburg Uhlhornsweg 26129 Oldenburg E-Mail: hasselbring(at)informatik.uni-oldenburg.de Springer-Verlag 2006 http://www.gi.de/service/informatiklexikon/detailansicht.html