Qualität im Software-Entwurf: Software-Architekturen

Transkript

1 Qualität im Software-Entwurf: Software-Architekturen Eine Veröffentlichung des VSEK-Projekts FKZ 01 IS C39 Autoren: Thomas Zehler (BTU) Report: VSEK/033/D Version Klassifikation: öffentlich

2

3 Zusammenfassung Schlagworte: Software erlangte in den vergangenen Jahren eine immer größer werdende Bedeutung für unsere Gesellschaft. Stetig steigende Anforderungen machen ein Umdenken bei der Software-Entwicklung erforderlich. Eine Verkürzung der Entwicklungszeiten, die Reduzierung der Wartungs- und Entwicklungskosten sowie die Verbesserung der Qualität sind Ziele, die es anzustreben gilt. Erreicht werden soll dies in erster Linie durch einen erhöhten Grad an Wiederverwendung sowie durch die Verbesserung der Software-Entwicklungsprozesse. In beiden Bereichen spielt die Software- Architektur eine wichtige Rolle. Dieses Dokument liefert einen Überblick über den Stand der Technik bei der Erstellung und Etablierung von Software-Architekturen unter dem Gesichtspunkt der Wiederverwendung von Wissen im Entwurfsprozess. Neben der grundlegenden Begriffsklärung wird insbesondere auf den Erstellungsprozess einer Software-Architektur eingegangen. Darüber hinaus werden verschiedene Konzepte zur Wiederverwendung von Wissen im Entwurfsprozess vorgestellt und diskutiert. Der Schwerpunkt liegt hierbei auf der Anwendung architektonischer Muster und Stile. Architekturmuster, Entwurf, Entwurfsmuster, Heuristiken, Muster, Referenzarchitektur, Software-Architekt, Software-Architektur, Wiederverwendung iii

4

5 Inhaltsverzeichnis 1 Einleitung 1 2 Grundlagen Was ist Software-Architektur? Der Begriff der Software-Architektur Warum ist Software-Architektur wichtig? Bedeutung der Software-Architektur Organisatorische Vorteile Technische Vorteile Die zentrale Rolle des Architekten Allgemeine Aufgaben und Eigenschaften Projektbezogene Aufgaben 11 3 Erstellung der Software-Architektur Vorbereitung für den Entwurf Anforderungsanalyse Einflussfaktoren Entwurf, Dokumentation und Bewertung Entwurf von Software-Architekturen Dokumentation der Software-Architektur Bewertung der Software-Architektur Umsetzung Skelett der Architektur 62 4 Wiederverwendung im Software-Entwurf Referenzarchitekturen Beispiele Probleme Architektonische Muster und Stile Architekturtypen/Architekturstile Architekturmuster Entwurfsmuster Entwurfsheuristiken Idiome Anti-Pattern Produktlinien Bibliotheken/Frameworks Bibliotheken Frameworks Literatur 125 v

6 vi Copyright Fraunhofer IESE 2001

7 Einleitung 1 Einleitung Software erlangte in den vergangenen Jahren eine immer größer werdende Bedeutung für unsere Gesellschaft. In immer stärkerem Maße übernehmen Softwaresysteme Aufgaben, die früher durch Hardware oder mechanische Elemente gelöst wurden. Mittlerweile wird Software verstärkt auch in Bereichen eingesetzt, wo ein Versagen nicht nur zu wirtschaftlichen Verlusten führt, sondern auch Menschenleben gefährdet sind. Um den stetig wachsenden Anforderungen zu genügen, werden bei der Software-Entwicklung verschiedene Ziele verfolgt, die auch als Spannungsdreieck der Software-Entwicklung bekannt geworden sind [PBG04]: Verkürzung der Entwicklungszeiten Reduzierung der Wartungs- und Entwicklungskosten Verbesserung der Qualität. Erreicht werden soll dies in erster Linie durch einen erhöhten Grad an Wiederverwendung und eine Verbesserung der Entwicklungsprozesse. Die Software-Architektur spielt sowohl bei der Wiederverwendung als auch bei der Prozessverbesserung eine wichtige Rolle. Sie beschreibt die wesentlichen Mechanismen und Strukturen der Software auf den oberen Hierarchieebenen und entstand aus der Notwendigkeit, immer größer und komplexer werdende Softwaresysteme zu beherrschen. Erste Arbeiten wurden in den 1960er bis 1980er Jahren von Parnas [Par72], Brooks, [Bro75], Dijkstra [Dij68] und anderen veröffentlicht. Weitreichende Aufmerksamkeit erlangte das Thema jedoch erst in den 1990er Jahren, als große Systeme zunehmend die Regel wurden. Im Abschnitt "Grundlagen" wird der Begriff der Software-Architektur aus verschiedenen Blickwinkeln betrachtet und es wird erläutert, welche Aufgaben die Architektur erfüllen muss. Darüber hinaus wird dargelegt, warum Software-Architektur so wichtig ist und welche Vorteile die Entwicklung einer "guten" Software-Architektur mit sich bringt. Der Software-Architekt ist verantwortlich für die Erstellung und Umsetzung der Architektur. Dieser Schlüsselposition wird durch die gesonderte Darstellung der wichtigsten Aufgaben des Architekten im Entwicklungsprozess Rechnung getragen. 1

8 Einleitung Der Abschnitt "Erstellung der Software-Architektur" gibt einen Überblick über die Erstellung der Architektur während des Software- Entwicklungsprozesses. Die Erstellung der Architektur ist ein inkrementeller und iterativer Prozess, der sich vereinfacht in (1) Vorbereitung, (2) Entwurf, Dokumentation und Bewertung und (3) Umsetzung unterteilen lässt. Die Entwicklung großer Softwaresysteme ist mit einem hohen Zeit- und Kostenaufwand verbunden. Die Entwicklungskosten bei Folgeprojekten können signifikant gesenkt werden, wenn das in der Software-Architektur dokumentierte Wissen wieder verwendet wird. Im Abschnitt "Wiederverwendung im Software-Entwurf" wird auf verschiedene Möglichkeiten der Wiederverwendung von Wissen im Entwurfsprozess Bezug genommen. Der Schwerpunkt des Kapitels liegt dabei auf der Betrachtung Architektonischer Muster und Stile. 2

9 Grundlagen 2 Grundlagen Im Abschnitt "Was ist Software-Architektur?" wird der Begriff der Software-Architektur aus verschiedenen Blickwinkeln betrachtet und es wird erläutert, welche Aufgaben die Architektur erfüllen muss. Darüber hinaus werden wichtige Einflussfaktoren auf eine Software-Architektur näher vorgestellt. Die Architektur des Softwaresystems ist das zentrale Artefakt bei der Software-Entwicklung. Sie dient aufgrund ihrer Abstraktion und Dokumentation als Schlüssel zum Systemverständnis für die Projektbeteiligten. Im Abschnitt "Bedeutung der Software-Architektur" wird dargelegt, warum Software-Architektur so wichtig ist und welche Vorteile die Entwicklung einer "guten" Software-Architektur mit sich bringt. Das Kapitel "Die Rolle des Software-Architekten" beleuchtet die zentrale Stellung des Architekten im Entwicklungsprozess genauer. Software- Architekten sehen sich der Herausforderung gegenübergestellt, zunehmend komplexere Systeme bauen zu müssen und dabei die neuesten Technologien einzusetzen. Zudem müssen die Produkte bei hoher Qualität immer schneller auf den Markt gebracht werden. Neben der Beherrschung des Technologiewandels ist zu berücksichtigen, dass die Systeme so entworfen werden müssen, dass heutige Technologien leicht durch zukünftige ersetzt werden können. 2.1 Was ist Software-Architektur? Der Begriff der Software-Architektur Der Software-Entwurf beinhaltet alle Tätigkeiten zur Festlegung der als Software zu realisierenden Komponenten eines Produkts, ihrer Schnittstellen (untereinander und zu den übrigen Systemkomponenten) und Kooperationen. Ergebnis des Entwurfs ist die Software-Architektur. Als solche wird die Beschreibung der Struktur eines Softwaresystems auf einer geeigneten Abstraktionsebene in Form von Komponenten (Subsysteme, Module, Pakete, Klassen,...) und ihrer Beziehungen zueinander verstanden [Bal00]. Eine weiter gehende Begriffsklärung findet sich in [PBG04]. Die Definition setzt sich aus mehreren Bestandteilen zusammen: 3

10 Grundlagen zeitliche Einordnung in den Entwicklungsprozess Festlegung der Aspekte der Software, die durch die Architektur beschrieben werden Abstraktionsebenen und Detaillierungsgrad der Architektur Kriterien für eine gute Architektur Zeitliche Einordnung in den Entwicklungsprozess Bei der Software-Entwicklung sieht man sich mit dem Problem konfrontiert, die Lücke zwischen Anforderungen und dem lauffähigen System zu überwinden. Systematische Software-Entwicklungsmethoden bieten die Möglichkeit, dieses Problem zu lösen, setzen jedoch viel Erfahrung voraus und sind für jedes System neu auszuführen. Eine andere Möglichkeit ergibt sich aus dem Einsatz der Software-Architektur. Hofmeister et al. sehen diese als Brücke zwischen der Anforderungsanalyse und der Implementierung [HNS00]. Als solche ist sie nach der Anforderungsdefinition und vor dem Feindesign, der Implementierung, der Integration und dem Test anzusiedeln Aspekte der Software, die durch die Architektur beschrieben werden Bass et al. [BCK03] definieren die Software-Architektur als Struktur des Softwareprodukts, welche die Komponenten, deren extern sichtbare Eigenschaften sowie die Beziehungen und Interaktionen zwischen diesen umfasst. Der Definition der Schnittstellen zwischen den Komponenten kommt eine wichtige Bedeutung zu. Ein Softwaresystem beinhaltet viele Strukturen, nicht nur eine. Bei der Dokumentation der Software-Architektur werden diese Strukturen durch verschiedene Sichten dargestellt. Für bestimmte Zwecke sind dabei jeweils ausgewählte Sichten auf ein System relevant. Nähere Ausführungen finden sich im Kapitel "Architektursichten". Ein Softwaresystem ist aus verschiedenen Komponenten zusammengesetzt, die sich je nach Abstraktionsebene in ihrer Komplexität unterscheiden. Auf der untersten Ebene können bereits eine Funktion, Klasse oder Modul als Komponente bezeichnet werden. Auf der nächst höheren Hierarchieebene sind Klassenstrukturen, Frameworks, Pakete, usw. typische Komponenten Detaillierungsgrad und Abstraktionsebenen Die Architektur beschreibt das Softwaresystem auf der Ebene der Hauptbestandteile der Software und dokumentiert die Schnittstellen, 4

11 Grundlagen Beziehungen, das Verhalten und die Instanzen. Es muss sichergestellt sein, dass die einzelnen Bausteine die geforderten Aufgaben und Qualitätsmerkmale erfüllen. Ist dies in der ursprünglichen Fassung nicht gegeben, müssen die Details des jeweiligen Bausteins konkreter betrachtet werden. Der Detaillierungsgrad muss nicht für die gesamte Architektur gleich sein, sondern sollte je nach Risiko angepasst werden. Bei sehr großen Systemen existiert nicht nur eine Architekturebene, sondern mehrere Hierarchieebenen. So werden auf der obersten Ebene Subsysteme, deren Beziehungen, Verhalten und Instanzen definiert. Die darunter liegenden Subsysteme sind wiederum so groß, dass sie erneut in einzelne Komponenten zerlegt werden können. Schritt für Schritt nähert man sich der tiefsten Ebene der Klassen und Methoden und damit der Implementierung. Abbildung 1: Abstraktionsebenen der Software-Architektur [PBG04] Kriterien für eine gute Architektur Bass et al. [BCK03] definieren eine gute Architektur dahingehend, dass es diese einem System ermöglichen muss, seine Verhaltens-, Qualitäts- und Lebenszyklusanforderungen zu erfüllen. Es gibt keine generell richtige Architektur. Eine Software-Architektur ist für eine spezielle Problemstellung mehr oder weniger geeignet und kann im Kontext konkreter Ziele bewertet werden. Darüber hinaus existieren allgemeine Aufgaben und Ziele, die jede 5

12 Grundlagen Architektur erfüllen muss. Eine gut entworfene Architektur setzt sich aus wohl definierten Abstraktionsschichten zusammen und die Dokumentation ist aus Sicht des potentiellen Lesers geschrieben. Weitere allgemeine Ziele werden im Abschnitt "Warum ist Software-Architektur wichtig?" erörtert Warum ist Software-Architektur wichtig? Mit der Etablierung einer Software-Architektur werden nach Posch, Birken und Gerdom [PBG04] vier wesentliche Ziele verfolgt: Projektplanung Risikominimierung Kommunikation Konservierung von Wissen über das System Projektplanung Die Software-Architektur kann die Effizienz des Entwicklungsprojektes auf dreierlei Weise beeinflussen [PBG04]: Software-Architektur bildet die Basis für jeden iterativ inkrementellen Entwicklungsprozess. Die Software-Architektur bildet die Grundlage der Projektplanung, des Projektmanagements und der Projektorganisation. Den einzelnen Bausteinen der Architektur können Teams zugewiesen werden und diesen wiederum Arbeitspakete. Die Software-Architektur abstrahiert und gibt dem Projektmanager Einblick in die Entwicklung auf dem von ihm benötigten Abstraktionsniveau. Die Software-Architektur bildet die Grundlage für ein effektives, unabhängiges und verteiltes Arbeiten des Entwicklungsteams. Sie definiert die Struktur, Beziehungen, Verhalten und Schnittstellen, auf deren Grundlage die Entwicklungsteams zusammengestellt werden und enthält alle Informationen, um ein voneinander unabhängiges Arbeiten der Teams zu ermöglichen Risikominimierung Eine Minimierung der Entwicklungsrisiken kann erreicht werden, indem die entsprechenden Einflussfaktoren frühzeitig betrachtet werden. Hierzu 6

13 Grundlagen gehören unter anderem Qualitäts- oder Managementanforderungen. Die Software-Architektur ist das erste Artefakt, welches ausdrückt, wie die Software die Anforderungen erreichen will. Demzufolge kann auch sie unter dem Gesichtspunkt der Einflussfaktoren analysiert und bewertet werden. Daraus lassen sich Vorhersagen ableiten, ob eine bestimmte Architektur die gestellten Anforderungen erfüllen kann oder nicht. Beispiele: technische Risiken: die Middleware tut nichts organisatorische Risiken: das Team versteht die Architektur nicht Kommunikation Die Software-Architektur dient als Kommunikationsplattform zwischen den Stakeholdern und insbesondere zwischen allen Mitarbeitern des Entwicklungsprojekts. Der Begriff Stakeholder beinhaltet dabei alle Personen, die ein Interesse am System haben (z.b. Kunde, Manager, Architekt, Entwickler, Tester usw.). Auf Grundlage der Architektur können unterschiedliche Forderungen ausgedrückt, verhandelt und gelöst werden. Die Software-Architektur wird aus verschiedenen Sichten dokumentiert, wobei jede eine andere Menge an Informationen, einen anderen Ausschnitt der Gesamtarchitektur betrachtet. Die Nutzung verschiedener Sichten und die damit einhergehende Reduzierung der Komplexität ermöglicht die Mitsprache vieler Beteiligten und erleichtert das Abwägen alternativer Lösungen Konservierung von Wissen über das System Die Software-Architektur kann als übertragbares Modell für Systeme mit ähnlichen Anforderungen dienen. Dies kann sich bis zur Entwicklung einer Produktlinie auf Grundlage einer gemeinsamen Basisarchitektur erstrecken. Die Etablierung einer Software-Architektur verursacht auf Seiten des Unternehmens zum Teil beträchtliche Kosten, so dass eine Wiederverwendung anstreben ist. Die Architektur wird zu einem wertvollen geistigen Eigentum des Unternehmens. Entsteht bei der Systementwicklung keine Architektur, sondern nur der Quellcode, so ist eine Übertragung des Wissens auf künftige Projekte schwierig und nur möglich, wenn bei der Entwicklung auf die gleichen Personen zurückgegriffen werden kann. Davon kann jedoch in der Realität nicht ausgegangen werden. Vielmehr werden häufig andere Personen das neue System entwickeln. Liegt keine gut dokumentierte Software-Architektur vor, so können diese nicht aus dem bereits entwickelten System lernen, da eine 7

14 Grundlagen Einarbeitung in die Strukturen und Beziehungen des Quellcodes in der Regel zu aufwändig ist. 2.2 Bedeutung der Software-Architektur Die Architektur des Softwaresystems ist das zentrale Artefakt bei der Software-Entwicklung. Sie dient allen Projektbeteiligten infolge ihrer Abstraktion und der aus unterschiedlichen Perspektiven erfolgenden Dokumentation als Schlüssel zum Systemverständnis. In der Architektur werden die wichtigsten Designentscheidungen für das Softwaresystem festgehalten, wodurch wesentlich bestimmt wird, ob das System in der Lage sein wird, die gestellten Anforderungen zu erfüllen. Ein wesentliches Merkmal einer Software-Architektur ist der hohe Return on Investment (ROI) der getätigten Investitionen in Bezug auf Qualität, Zeitplan und Kosten. Wiederverwendung auf Basis einer Software-Architektur ist effektiv, weil dabei auf ein bereits bewährtes und erfolgreich angewandtes Konzept zurückgegriffen wird. Gut dokumentiert bewahrt die Software- Architektur das vorhandene, praktische Wissen im Unternehmen. Kurzfristig gesehen werden durch den Einsatz einer Software-Architektur die Effizienz des Projekts gesteigert und mögliche Risiken vermindert. Langfristig erhöht sich das Wissen des Unternehmens und das Potenzial für eine Wiederverwendung. Eine gute Software-Architektur legt die Grundlage für die weitere Entwicklung im Lebenszyklus des Softwareprojekts: Entwicklung, Integration, Test, Änderungen, Wartung, Weiterentwicklung usw. Nur auf Basis einer gelungenen Architektur ist es möglich, komplexe Softwareprojekte effektiv zu managen. Posch, Birken und Gerdom sprechen von der Software-Architektur als "Rückgrat" einer jeden Software- Entwicklung [PBG04]. Eine erfolgreiche Software-Architektur kann darüber hinaus Einfluss auf die Entwicklung zukünftiger Systeme im Unternehmen haben. Sie stellt ein hochwertiges Know-how dar, das dem Unternehmen einen wichtigen Wettbewerbsvorteil verschaffen kann. Eine dedizierte Software-Architektur bringt sowohl dem Unternehmen als auch den dort durchgeführten Projekten eine Reihe von Vorteilen. Diese lassen sich in technische und organisatorische Vorteile gliedern [ASQF03]. 8

15 Grundlagen Organisatorische Vorteile Der Einsatz einer Software-Architektur bringt eine Reihe organisatorischer Vorteile mit sich [ASQF03]. Software-Architektur schafft den Übergang von der Analyse zur Realisierung und ermöglicht die Erfüllung der Systemanforderungen, ermöglicht die Kommunikation des High-Level-Designs und vermittelt einen Gesamtzusammenhang, erlaubt die Aufteilung der weiteren Aktivitäten in geschlossene Arbeitsblöcke, dokumentiert Systeme und macht sie für alle Projektbeteiligten verständlich Technische Vorteile Nichts desto weniger ergeben sich aus der Verwendung von Software- Architekturen auch technische Vorteile [ASQF03]. Software-Architektur ermöglicht es, die Komplexität von Systemen zu beherrschen, stellt einen Rahmen für Wiederverwendung dar (Verwendung von bereits existierenden und zugekauften Komponenten), ist die Basis für Flexibilität und Erweiterbarkeit, reduziert Kosten für Wartung und Weiterentwicklung. 2.3 Die zentrale Rolle des Architekten Der Software-Architekt ist verantwortlich für die Erstellung und Umsetzung der Architektur. Er trifft wichtige Entscheidungen und spielt eine zentrale Rolle bei der Software-Entwicklung. Die folgende Abbildung verdeutlicht den Zusammenhang anschaulich. 9

16 Grundlagen Abbildung 2: Die zentrale Rolle des Software-Architekten [BL04]. Es hat sich in der Praxis als sinnvoll erwiesen, eine formale, im Unternehmen und Projekt festgeschriebene Position des Software- Architekten zu definieren. Vor allem in der Implementierungsphase kann die Architektur ohne einen aufmerksamen Software-Architekten leicht untergraben werden. Man spricht von "dirty hack", wenn kurzfristige, nicht saubere Lösungen implementiert werden, die aus Zeitdruck später beibehalten werden. Dieses Vorgehen führt mit Fortschreiten der Implementierung zu zunehmenden Problemen, da einzelne Teile nicht mehr zueinander passen und diese Baustellen entsprechend geflickt werden müssen. Die Architektur wird zunehmend ausgehöhlt und weicht stark vom beabsichtigten Design ab [PBG04]. Im Englischen spricht man vom architecture drift. Im folgenden soll auf die Aufgaben und Eigenschaften eines Software- Architekten eingegangen werden [PBG04]: Allgemeine Aufgaben und Eigenschaften Projektbezogene Aufgaben Wechselwirkung zu anderen Rollen (Projekt, Unternehmen) Allgemeine Aufgaben und Eigenschaften Der Architekt muss ein umfassendes theoretisches und praktisches Wissen über Technologien, Methoden und Werkzeuge besitzen, die in seinem Anwendungsbereich zum Einsatz kommen. Darüber hinaus sollte er über solide Programmiererfahrung sowie Kenntnisse der Anwendungsdomäne 10

17 Grundlagen und des Zielmarktes verfügen. Letztere ermöglichen ihm, die an das zu entwickelnde Produkt gestellten Anforderungen zu verstehen und ggf. Lücken oder Unstimmigkeiten zu erkennen. Der Software-Architekt interagiert und kommuniziert in seiner Funktion mit einer Vielzahl von Personen. Er verhandelt, vermittelt, organisiert, berät und setzt Entscheidungen durch. Oftmals fungiert er als Schnittstelle zwischen den Projektbeteiligten, so z.b. zwischen den Entwicklern und dem Projektleiter. Der Software-Architekt muss mehr als nur technische Fähigkeiten besitzen. Er muss gut kommunizieren, verhandeln und organisieren können, d.h. über ausgeprägte Führungseigenschaften und menschliche Fähigkeiten verfügen. Eine wichtige Herausforderung für den Software-Architekten ist es, auf dem Laufenden zu bleiben. Das Wissen in der Informationstechnik veraltet sehr schnell, so dass er sich ständig mit technischen Innovationen, neuen Technologien, Forschungsergebnissen und Erfahrungen aus dem eigenen und aus fremden Unternehmen beschäftigen muss. Der Architekt sollte beispielsweise neue Technologien und Vorgehensweisen hinsichtlich der Einsetzbarkeit im eigenen Unternehmen bewerten [PBG04]. Der Software-Architekt muss im Unternehmen Verantwortung über das eigentliche Projekt hinaus übernehmen und versuchen, vorausschauend zu denken, z.b. hinsichtlich der Wiederverwendbarkeit einer Architektur. Er sollte die Software-Architektur als Bestandteil im allgemeinen Entwicklungsprozess etablieren und ggf. Änderungen in der Organisation einfordern, sofern sie für die Erfüllung seiner Aufgaben notwendig sind Projektbezogene Aufgaben Der Software-Architekt hat im Laufe des Entwicklungsprojekts eine Reihe phasenübergreifender bzw. phasenspezifischer Aufgaben zu erfüllen Phasenübergreifende Aufgaben Unabhängig von der jeweiligen Projektphase ist der Software-Architekt an allen wichtigen technischen Entscheidungen beteiligt. Dies betrifft den Einsatz von Methoden, Technologien und Werkzeugen ebenso wie die Strukturen und Mechanismen der Architektur. Es ist oft zweckmäßiger, diese Entscheidungen frühzeitig zu treffen und im Nachhinein zu modifizieren, als den gesamten Entwicklungsprozess aufgrund nicht getroffener Entscheidungen aufzuhalten [PBG04]. Der Software-Architekt kennt die technischen Details des Projekts und weiß, wie Dinge zueinander passen oder voneinander abhängen, z.b. mit 11

18 Grundlagen welchen Architekturbausteinen ein anderer kommuniziert. Aufgrund dieses Wissens fungiert der Architekt als wichtigster technischer Berater im Projekt. Es muss sein Ziel sein, das Systemverständnis bei allen an der Entwicklung Beteiligten sicherzustellen. Der Software-Architekt arbeitet während des gesamten Projekts eng mit dem Projektmanager zusammen, unterstützt und berät diesen. Der Architekt koordiniert die Aktivitäten der Teammitglieder, deren Aufgaben durch die Software-Architektur beeinflusst werden. Dies betrifft in erster Linie die Kommunikation zwischen den einzelnen Entwicklungsteams. Der Architekt muss bei der Vielfalt der an ihn herangetragenen Aufgaben sicherstellen, dass er sich nicht in Details verliert. Ist an bestimmten Stellen eine feingranulare Betrachtung bestimmter Sachverhalte nötig, so sollte er die Aufgaben an andere Experten delegieren Phasenspezifische Aufgaben Die phasenspezifischen Aufgaben lassen sich grob in drei Bereiche gliedern: Analyse Architekturdesign Implementierung. Aufgaben während der Analysephase Die Software-Architektur fungiert als Brücke zwischen Anforderungen und Implementierung. Für den Architekten ist es wichtig, alle Arten von Anforderungen, Einschränkungen und Interessen des Projekts so zeitig wie möglich zu verstehen. Er muss die einzelnen Stakeholder identifizieren, um sich aktiv mit deren Erwartungen und Wünschen zu beschäftigen. Der Software-Architekt überprüft die Anforderungen an das Softwareprodukt auf deren technische Umsetzbarkeit im Rahmen der vorgegebenen Kostenund Zeitpläne, weshalb er möglichst zeitig in den Analyse- und Definitionsprozess eingebunden werden sollte. Der Architekt kann aufgrund seiner Stellung eventuell vorhandene Konflikte zwischen gestellten Anforderungen und den für deren Realisierung verfügbaren Ressourcen erkennen, mit dem Management diskutieren und abwägen. Aufgaben beim Architekturdesign Der Schwerpunkt dieser Phase liegt im Entwurf der Software-Architektur, d.h. in der Transformation der Anforderungsspezifikation in die Architektur 12

19 Grundlagen des Systems. Die Vielzahl an Aufgaben, die der Software-Architekt dabei zu erfüllen hat, lässt sich in folgende vier Gebiete untergliedern [PBG04]: Entwurf Bewertung Implementierung Dokumentation und Kommunikation. Entwurf Laut Posch, Birken und Gerdom [PBG04] beinhaltet der Entwurf das Erschaffen einer Vision unter Berücksichtigung von Einflussfaktoren, Abwägungen sowie möglichen zukünftigen Änderungen. Die Vision ist eine Abbildung der Anforderungen auf Struktur und Mechanismen einer Software. Der Software-Architekt muss die technischen Schlüsselentscheidungen treffen und die Design-Entscheidungen festlegen. Hierzu gehören die Auswahl von Technologien, Architekturstilen und Architekturmustern. Globale Entscheidungen sollten frühzeitig getroffen und die damit verbundenen Risiken identifiziert werden. Nach Starke [Sta02] arbeitet ein Software-Architekt im Rahmen des Entwurfs mit einer Vielzahl von Methoden, Techniken und Werkzeugen. Hierzu gehören Modelle, Heuristiken, Architekturstile, Muster, Compiler, Debugger, Prototypen und Techniken wie Zerlegung, Zusammensetzung und Iteration. Bewertung Durch regelmäßige Analyse und Bewertung der Architektur in der Designphase soll sichergestellt werden, dass die Architektur alle Einflussfaktoren (z.b. funktionale Anforderungen und Qualitätsmerkmale) erfüllt. Der Analyse- und Bewertungsprozess umfasst nicht nur die reine Durchführung der Überprüfungen, sondern auch die Planung und Realisierung von Prototypen, Simulationen und formalen Analysen. Ziel muss es sein, umfassende Informationen zu sammeln, um so potentielle Risiken zu identifizieren, zu verstehen und zu reduzieren. Implementierung Vereinzelt implementiert der Software-Architekt noch selbst und erstellt Prototypen mit oder entwirft Codevorlagen von Architekturbausteinen für die spätere Implementierungsphase. Diese Codevorlagen enthalten bereits 13

20 Grundlagen vorgeschriebene Mechanismen für die Kommunikation oder Initialisierung des Bausteins. Bei riskanten Systemteilen ist es unter Umständen notwendig, dass der Architekt beim Entwurf ins Detail geht, um Designrückwirkungen der Implementierung zu beachten. Hierzu kann es erforderlich sein, umfangreichere Szenarien in Form eines Prototyps auf der Ebene der Implementierung durchzuspielen [PBG04]. Dokumentation und Kommunikation Der Architekt muss die von ihm entworfene Software-Architektur ausreichend dokumentieren und gewährleisten, dass sie von allen involvierten Stakeholdern verstanden wird. Hierzu muss er die Architektur gegenüber den Beteiligten kommunizieren und seine Entscheidungen und die Vision der Architektur vermitteln. Aufgaben in der Implementierungsphase Der Schwerpunkt in der Implementierungsphase liegt in die Umsetzung der Software-Architektur in das lauffähige Softwaresystem. Entwickler entwerfen das erforderliche Feindesign und übernehmen die endgültige Implementierung. In der Theorie trägt der Software-Architekt in der Implementierungsphase keine Verantwortung für ein bestimmtes Entwicklungspaket oder team. In der Praxis schaut dies jedoch zumeist anders aus. Hier übernimmt der Architekt ebenso Aufgaben eines Entwicklers. Im Wesentlichen muss der Architekt in der Implementierungsphase folgende Bereich abdecken [PBG04]: Kommunikation und Sicherstellen des Verständnisses Beratung und Training Kontrolle und Pflege. Kommunikation und Sicherstellen des Verständnisses Der Software-Architekt muss die am Entwicklungsprojekt Beteiligten davon überzeugen, dass die Architektur implementiert werden kann. Hierzu ist ein ständiger Dialog mit den Entwicklern zwingend erforderlich. Der Architekt muss mit den Entwicklern diskutieren, ihnen wichtige Aspekte der Architektur vermitteln und ihr Feedback entgegennehmen. Dafür eignen sich Schulungen, Präsentationen oder Workshops. Für die Umsetzung der Architektur in ein lauffähiges Programm ist es notwendig, dass die Entwickler ihre aus der Architektur abgeleiteten Arbeitspakete genau verstehen. Der Software-Architekt muss viel Zeit und Anstrengungen 14

21 Grundlagen investieren, um jedem Mitglied des Entwicklungsteams seine Vorstellungen nahezubringen. Beratung und Training Der Software-Architekt sollte die Entwickler als Coach bei Feindesign- und Implementierungsaufgaben beraten, die die Software-Architektur betreffen. Er steht dabei allen Mitgliedern des Entwicklungsteams als Mentor zur Verfügung, wenn Fragen auftreten. Kontrolle und Pflege Ein wichtiges Aufgabengebiet des Software-Architekten umfasst die Kontrolle und Pflege der Software-Architektur, um das Abdriften von der ursprünglichen Idee und dem Zusammenbruch der konzeptuellen Integrität entgegenzutreten. Um die Kontrolle und Pflege zu gewährleisten, muss der Software-Architekt sicherstellen, dass die Architektur befolgt wird, d.h. dass die Implementierung konform zur Software-Architektur erfolgt und Architekturstil, -muster, Schnittstellen und weitere Vorgaben beachtet werden. Für den Software-Architekten ist es am einfachsten, wenn er die Schlüsselschnittstellen der Software kontrolliert. Er sollte zudem die Qualität des Feindesigns verfolgen und überprüfen, ob die Abhängigkeiten im Code mit der Architektur übereinstimmen. 15

22 Erstellung der Software- Architektur 3 Erstellung der Software-Architektur Das folgende Kapitel gibt einen umfassenden Überblick über die Erstellung der Software-Architektur im Rahmen des Software-Entwicklungsprozesses. Die Erstellung der Architektur ist ein inkrementeller und iterativer Prozess, der sich vereinfacht in drei Phasen unterteilen lässt [PBG04]: Vorbereitung Entwurf, Dokumentation und Bewertung Umsetzung. Die folgende Abbildung gibt einen Überblick über den Ablauf und das Zusammenspiel der einzelnen Aktivitäten: Abbildung 3: Vorgehen zur Erstellung der Software-Architektur [PBG04]. 16

23 Erstellung der Software- Architektur Grundvoraussetzung für die Erstellung einer Software-Architektur ist die Durchführung einer Anforderungsanalyse. Hierzu gehört die Anforderungsspezifikation, bestehend aus der Analyse der funktionalen, nicht funktionalen sowie technischen Anforderungen und einem dazu passenden fachlichen Modell. Im Anschluss daran werden die Einflussfaktoren bestimmt, an denen sich der Entwurf ausrichten muss. Der eigentliche Entwurf der Architektur erfolgt durch den Architekten oder ein Architektenteam. Neben den verschiedenen Faktoren orientiert sich der Architekt bei seiner Tätigkeit an bekannten Entwurfsprinzipien und zielen und wendet Heuristiken und spezielles Wissen über den Architekturentwurf an. Parallel zum Entwurf der Software-Architektur müssen die Architekturentscheidungen nachvollziehbar dokumentiert werden. Hierfür bieten sich unterschiedliche Notationen (z.b. UML 2.0) an. Die Software-Architektur sollte während des Architekturentwurfs in unterschiedlichen Abständen bewertet werden. Hierfür kommen verschiedene Bewertungsmethoden, z.b. die Ad-hoc-Bewertung, das Early Discovery Review oder ein umfangreiches Assessment zum Einsatz. Auf Grundlage der Bewertung wird der Entwurf der Architektur iterativ vervollkommnet. Erscheint die Architektur stabil und ausgereift, kann mit der Umsetzung begonnen werden. Hierbei sollte idealerweise zunächst ein Architekturskelett implementiert werden, welches den Integrationsrahmen für die sich anschließende Implementierungsphase bildet. Die Architektur ist bei der Umsetzung jedoch nicht eingefroren, sondern wird Anpassungen erfahren und muss gepflegt werden. Demzufolge ist unter Umständen eine ständige Überarbeitung erforderlich. Es gibt keinen Prozess, der für jede Art von Projekt passt. Vielmehr müssen die Prozesse den gegebenen Umständen angepasst werden. Man spricht in diesem Zusammenhang auch von Prozesstailoring. 3.1 Vorbereitung für den Entwurf Vor dem Entwurf der Software-Architektur muss die Anforderungsanalyse sowie eine Spezifikation der Einflussfaktoren erfolgen. Die Anforderungsanalyse ist ein sehr weit gefasstes Gebiet, auf das im vorliegenden Dokument nur überblicksweise eingegangen werden soll. Die folgenden Aussagen beziehen sich zumeist auf den von Robertson [Rob99] propagierten Volere-Anforderungsprozess und die zugehörige Dokumentvorlage zur Anforderungsspezifikation. Weiterführende Informationen zum Anforderungsmanagement finden sich auch im Buch von Schienmann [Sch02]. 17

24 Erstellung der Software- Architektur Anforderungsanalyse Der Volere-Prozess beinhaltet Aussagen darüber, wie Anforderungen ausfindig gemacht und so beschrieben werden können, dass sie im fertigen Softwareprodukt getestet werden können. Abbildung 4: Volere-Prozess [Rob99]. Die Grafik verdeutlicht, dass sich der Volere-Prozess im wesentlichen in vier Schritte unterteilen lässt [PBG04]: Projekt-Blastoff Ausfindigmachen der Anforderungen Festhalten der Anforderungen Qualitätskontrolle. Im Anschluss an die Qualitätskontrolle wird ein fachliches Modell der funktionalen Anforderungen erstellt. 18

25 Erstellung der Software- Architektur Die Anforderungsanalyse ist mit dem Übergang zum Design der Architektur nicht abgeschlossen. Vielmehr unterliegen die Anforderungen permanenten Änderungen und erfordern deshalb stetige Anpassung Projekt-Blastoff Am Anfang findet ein Projekttreffen (sog. Blastoff) statt, um das Projekt vorzubereiten und die Machbarkeit sicherzustellen, noch bevor das Projekt eigentlich startet. Am Treffen nehmen die wichtigsten Projektbeteiligten teil. Es müssen ausreichend Fakten gesammelt werden, um aufzuzeigen, dass das Projekt genügend lohnende Ziele verfolgt, dass es möglich ist, diese zu erreichen und dass genügend Rückhalt durch die Stakeholder vorhanden ist. In der Folge erfolgt der Entwurf eines groben Kontextmodells. Ergänzend dazu wird eine erste Abschätzung der anfallenden Kosten sowie eine erste Risikobewertung durchgeführt Ausfindigmachen der Anforderungen Um die Anforderungen an ein Software-Produkt ausfindig zu machen, muss man zunächst verstehen, was das Produkt exakt leisten soll. Häufig ist hier Detailwissen erforderlich, so dass eine enge Zusammenarbeit zwischen den Anforderungsanalysten und den Stakeholdern, insbesondere den künftigen Anwendern erforderlich ist. Zum Einsatz kommen z.b. Fragetechniken, Interviews oder Use-Case-Workshops. Ist es erforderlich, Anforderungen konkreter zu machen, so können Prototypen oder Szenarien zum Einsatz kommen, um den Anwendern eine Simulation der Anforderungen zeigen zu können. Neben funktionalen Anforderungen sind auch nicht-funktionale (z.b. Antwortzeiten oder die Benutzeroberfläche) und technische Anforderungen von Bedeutung und müssen betrachtet werden Festhalten der Anforderungen Die ermittelten Anforderungen müssen in einer standardisierten Form in der Anforderungsspezifikation festgehalten werden, so dass sie von den späteren Anwendern verstanden werden. Hierzu sollte die Sprache des Anwendungsbereichs verwendet werden. Um gewährleisten zu können, dass das fertige Softwareprodukt die Anforderungen erfüllt, müssen diese in irgendeiner Form messbar sein. Jede Anforderung sollte mit Abnahmekriterien verbunden sein, so dass der Tester leicht ableiten kann, ob das implementierte Produkt die Anforderungen erfüllt oder nicht. 19

26 Erstellung der Software- Architektur Qualitätskontrolle Robertson beschreibt in seinem Buch [Rob99] das sogenannte "Quality Gateway" für die Qualitätskontrolle. Aufgabe des Gateways ist es, jede Anforderung auf Eigenschaften wie Vollständigkeit, Relevanz, Zusammenhang und Verfolgbarkeit zu überprüfen. Erst wenn eine Anforderung das "virtuelle Tor" passiert hat, ist sie Bestandteil der finalen Spezifikation, vorher wird sie als potentielle Anforderung betrachtet. Die vollständige Spezifikation wird abschließend einer umfassenden Betrachtung unterzogen, wobei festgestellt werden soll, ob Anforderungen fehlen, alle Anforderungen konsistent sind und keine ungelösten Konflikte mehr existieren Fachliches Modell Im Anschluss an die Qualitätskontrolle wird ein fachliches Modell der funktionalen Anforderungen erstellt. Hierbei handelt es sich zumeist um ein objektorientiertes Analysemodell, welches aus Klassendiagrammen für die statischen Zusammenhänge und Interaktionsdiagrammen für die dynamischen Zusammenhänge besteht. Das fachliche Modell enthält keine technischen Details einer Lösung und dient in erster Linie als Ausgangsbasis für die Software-Architektur Spezifikation der Einflussfaktoren Wenn die Anforderungsanalyse abgeschlossen ist, sollten zunächst die Faktoren bestimmt werden, welche die Architektur beeinflussen. Manche Einflussfaktoren bestimmen den Entwurf der Architektur maßgeblich mit. Um sich eine teure Überarbeitung zu ersparen, müssen diese Faktoren von Beginn an berücksichtigt werden. Verschiedenste Faktoren haben Einfluss auf die Software-Architektur. Offensichtlich sind Anforderungen wie Reaktionszeiten des Systems, Wartbarkeit und das einzusetzende Betriebssystem. Aber auch Aspekte wie der vorgegebene Zeitplan und das verfügbare Budget müssen sich in der gewählten Architektur wieder finden. Die Menge der Einflussfaktoren lässt sich grob in drei Kategorien einteilen: Organisatorische Faktoren Technologische Faktoren Produktfaktoren. 20

27 Erstellung der Software- Architektur Im Rahmen der Spezifikation der Einflussfaktoren werden diese mit dem Ziel analysiert, die wichtigsten Faktoren zu finden, deren Veränderlichkeit und Einfluss zu bestimmen sowie mögliche Risiken aufzuspüren und Strategien zur Risikominimierung zu entwickeln. Nach Posch, Birken und Gerdom [PBG04] werden bei der Spezifikation der Einflussfaktoren drei Schritte unterschieden: Identifikation und Präzisierung der Faktoren Analyse der Faktoren Identifikation von Architekturthemen und Entwicklung von Strategien Organisatorische Faktoren Der Ursprung organisatorischer Faktoren liegt in der Organisation und Struktur des Unternehmens, welches die Software entwickelt. Diese Art von Einflussfaktoren ist nur schwer, und wenn, dann nur über einen langen Zeitraum zu ändern. Die Flexibilität ist gering, der Architekt muss bei seinen Designentscheidungen damit leben und darauf Rücksicht nehmen. Hoffmeister [HNS00] teilt die organisatorischen Faktoren in Kategorien ein und gibt Beispiele: Management: Entwickeln vs. Kaufen, Zeitplan vs. Funktionalität, Geschäftsziele Mitarbeiter (Fähigkeiten, Interessen, Stärken und Schwächen): Anwendungsdomäne, spezielle Implementierungstechniken, Methoden, Werkzeuge Prozess und Entwicklungsumgebung: Entwicklungsplattform, Entwicklungsprozess und -werkzeuge, Testprozess und werkzeuge Entwicklungszeitplan: Time-to-Market, Meilensteine Entwicklungsbudget: Anzahl der Mitarbeiter, Kosten für Entwicklungswerkzeuge, Budget für Weiterbildungsmaßnahmen Technologische Faktoren Die technologischen Faktoren beschreiben ebenso wie die organisatorischen Faktoren nicht das Produkt an sich. Vielmehr handelt es sich um Hardware-/Softwaretechnologien und Standards, die eingesetzt 21

28 Erstellung der Software- Architektur werden. Die Auswahl der eingesetzten Technologien kann einen wesentlichen Einfluss auf den Entwurf der Software-Architektur haben. Die Faktoren ändern sich aufgrund des technologischen Fortschritts von Zeit zu Zeit. Aus diesem Grund sollten die Architekturen so entworfen werden, dass die Schwierigkeiten für das Anpassen an die neue Technologie minimiert werden. Hoffmeister [HNS00] teilt die technologischen Faktoren in folgende Kategorien und gibt Beispiele: Hardware: Prozessor, Netzwerk, Speicher Softwaretechnologien: Betriebssystem, Programmiersprache, Benutzerschnittstelle Architekturtechnologien: Architekturstile, Architekturmuster, Referenzarchitekturen Standards: Betriebssystem, Datenbanken, Datenformate Produktfaktoren Unter dem Begriff Produktfaktoren werden die funktionalen und nichtfunktionalen Anforderungen an die Software zusammengefasst. Letztere können auch als Qualitätsanforderungen (Qualitätsattribute) bezeichnet werden. Beispiele hierfür sind Wartbarkeit, Leistung oder Sicherheit des Systems. Bass et al. [BCK03] unterscheiden die Produktfaktoren in Qualitätsattribute, die zur Laufzeit des Systems erkennbar sind (z.b. Leistung, Sicherheit, Zuverlässigkeit) Qualitätsattribute, die nicht zur Laufzeit des Systems erkennbar sind (z.b. Testbarkeit, Änderbarkeit, Portierbarkeit). Bei der Anforderungsspezifikation liegt der Fokus in der Regel auf den funktionalen Anforderungen, Qualitätsattribute werden häufig nur unzureichend betrachtet. Für den Entwurf der Software-Architektur ist es jedoch erforderlich, dass eindeutige Aussagen über die geforderten Qualitätsmerkmale gemacht werden Identifikation und Präzisierung der Faktoren Zu Beginn sollten die kritischen Einflussfaktoren aus den Bereichen Organisation, Technologie und Produkt ermittelt werden. Hierbei sollte man 22

29 Erstellung der Software- Architektur sich nach Meinung von Posch, Birken und Gerdon [PBG04] auf die wichtigsten Faktoren beschränken, inbesondere Faktoren, die einen wesentlichen Einfluss auf den Entwurf der Architektur haben (z.b. Anforderungen an die Portierbarkeit und Änderbarkeit des Systems) Faktoren, deren Erfüllung ungewiss ist (z.b. überzogene Leistungsvorstellungen) Faktoren, deren Erfüllung schwierig ist (z.b. unrealistische Zeitpläne) Faktoren, mit denen bisher keine oder nur wenig Erfahrungen gesammelt wurden (z.b. neu einzuführende Technologien) Faktoren, bei denen wahrscheinlich ist, dass sie sich während der Entwicklung ändern (z.b. Anforderungen an die Benutzeroberfläche). Bei der Ermittlung der Faktoren sollte die Anforderungsspezifikation als erste Anlaufstelle dienen. Darüber hinaus müssen das Umfeld kritisch betrachtet und die Stakeholder befragt werden, welche Faktoren sie für sensibel halten. Im Anschluss an die Identifizierung der Einflussfaktoren müssen diese konkretisiert und präzisiert werden. Die Aussagen in der Anforderungsspezifikation sind häufig subjektiv (z.b. "Das System soll leicht änderbar sein.") und für die Umsetzung in Form einer Software-Architektur nicht zu gebrauchen. Die Einflussfaktoren müssen im Rahmen eines konkreten Kontexts definiert werden, um sie messbar zu gestalten. Eben diese Konkretisierung der Faktoren über sog. Profile und Szenarien ist eine der ersten Aufgaben des Architekten. Profile und Szenarien Profile finden als Teil der Anforderungsspezifikation Verwendung, um diese genauer zu beschreiben. Ein Profil besteht aus einer Menge von Szenarien, die zumeist relativ untereinander gewichtet sind. Die Szenarien werden dabei gemeinsam mit den Stakeholdern ausgesucht und spezifiziert. Am bekanntesten ist das Anwendungsprofil, welches aus einer Menge von Anwendungsfällen (engl. use cases) besteht, welche die Benutzung des Systems aus externer Sicht beschreiben. Für andere Arten von Faktoren existieren weitere Arten von Profilen. 23

30 Erstellung der Software- Architektur Analyse der Faktoren Nach der Identifikation und Präzisierung der Faktoren muss eine genauere Analyse ihrer Flexibilität, Veränderbarkeit und ihres Einflusses auf die Architektur erfolgen. Diese Informationen sind für den Architekten dahingehend hilfreich, als dass sie ihm Hinweise geben, wie er die Faktoren bei der Erstellung der Architektur berücksichtigen muss. Hofmeister et al. [HNS00] nutzen zur Dokumentation der Analyseergebnisse eine sog. Faktorentabelle. In der Tabelle werden die einzelnen Faktoren aufgelistet und für jeden Faktor dessen Flexibilität, Veränderbarkeit und Einfluss festgehalten. Es wird vorgeschlagen, für jede der drei Arten von Faktoren (Organisation, Technologie und Produkt) eine eigenständige Tabelle zu führen. Organisatorische Faktoren O1: Faktorkategorie <O1> O1.1: Faktor <1> <Beschreibung des Faktors> O1.2: Faktor <2> <Beschreibung des Faktors> O2: Faktorkategorie: <O2> Flexibilität und Veränderlichkeit Welche Aspekte sind flexibel und veränderbar? Welche Aspekte sind flexibel und veränderbar? Einfluss Architekturaspekte oder andere Faktoren, die durch den Faktor beeinflusst werden Architekturaspekte oder andere Faktoren, die durch den Faktor beeinflusst werden Tabelle 1: Faktorentabelle [HNS00]. Flexibilität Verschiedene Faktoren stehen häufig in Widerspruch zueinander, so dass der Architekt oftmals abwägen muss, welchem Aspekt er den Vorzug einräumt. Das Wissen über die Flexibilität der einzelnen Faktoren ist 24

31 Erstellung der Software- Architektur deshalb eine essentielle Entscheidungsgrundlage für den Architekten. Er muss wissen, welchen Verhandlungsspielraum er bei den Stakeholdern bzgl. des Faktors besitzt und wo er unter Umständen Abstriche hinnehmen könnte. Neben der grundsätzlichen Angabe, dass ein Faktor flexibel ist, sollte in der Faktortabelle aufgeführt werden, in welchem Maße der Faktor anpassbar ist. Veränderbarkeit Es ist Aufgabe des Architekten, die Software so zu entwerfen, dass zukünftige Veränderungen möglichst nur lokale Auswirkungen in der Software nach sich ziehen. Die Veränderbarkeit der Einflussfaktoren gibt an, was sich an einem Faktor in näherer Zukunft wahrscheinlich ändert. Auch wenn es in erster Linie nur eine Vermutung darstellt, so lässt sich dies, betrachtet man den einzelnen Faktor, wesentlich einfacher vorhersehen und begründen. Neben der reinen Aussage darüber, dass sich etwas ändern kann, sollte in der Faktortabelle auch festgehalten werden, wie wahrscheinlich und häufig sich etwas ändert. Einfluss Bei der Analyse der Einflussfaktoren muss berücksichtigt werden, welchen Einfluss die Änderung der einzelnen Faktoren hat. Die Einfluss kann sich dabei auf die Architektur mit ihren Bausteinen und Mechanismen, aber auch auf andere Faktoren auswirken. Die Einträge in der Faktortabelle, die zumindest am Beginn eher Vermutungen gleichkommen, da noch kein Entwurf der Architektur vorliegt, sind im Lauf des Architekturentwurfs schrittweise zu überarbeiten Identifikation von Architekturthemen und Entwicklung von Strategien Nach Bestimmung der Menge der Einflussfaktoren einschließlich ihrer Auswirkungen auf die Software-Architektur, müssen aus der Gesamtheit der Faktoren die Risiken identifiziert und Strategien für diese entwickelt werden. Bei der Identifizierung von Risiken sollte wie folgt vorgegangen werden: Mit Hilfe der Faktortabelle sucht man nach Themen, die durch die Faktoren und deren Veränderbarkeit beeinflusst werden. Es gilt Themen zu finden, die zentral für das Projekt sind und ein Risiko darstellen (z.b. ein zu enger Zeitplan oder fehlendes Know-how in bestimmten, neuen Technologien). Durch die frühzeitige Identifikation von Risiken können rechtzeitig geeignete Gegenmaßnahmen auf der Ebene des Architekturentwurfs vorgenommen werden. 25

32 Erstellung der Software- Architektur Um die Verbindung zwischen Einflussfaktoren, Risiken und Architekturdesign herzustellen, müssen für die einzelnen Risiken Strategien entworfen werden. Die Strategie legt fest, wie dem Risiko durch geeignete Maßnahmen entgegengewirkt werden kann. Ziel sollte sein, den Einfluss eines Faktors zu reduzieren bzw. seine Auswirkungen lokal zu begrenzen oder allgemein Zeit und Aufwand zu reduzieren. Hofmeister et al. [HNS00] empfehlen, die identifizierten Risiken mit den zugehörigen Strategien in Themenkarten zu dokumentieren. In einer solchen Themenkarte wird jeweils ein Risiko beschrieben und festgehalten, welche Einflussfaktoren damit in Bezug zu bringen sind. Für das Risiko wird eine Lösung diskutiert und es werden konkrete Strategien zur Risikominimierung festgehalten. Abschließend sollte noch auf inhaltlich verwandte Risiken und Strategien aus anderen Themenkarten verwiesen werden. <Beschreibung des Risikos> Beeinflussende Faktoren: <Name des Architekturthemas> <Liste der Faktoren, die das Thema beeinflussen> Lösung: <Allgemeine Diskussion des Lösungsansatzes für den Entwurf> Strategie: <Name der 1. gefundenen Strategie> <Beschreibung der Strategie> Strategie: <Name der 2. gefundenen Strategie> <Beschreibung der Strategie> Verwandte Themen und Strategien: <Referenzliste auf Themen und Strategien, die mit diesem Thema in Beziehung stehen> Tabelle 2: Themenkarte nach [HNS00]. 3.2 Entwurf, Dokumentation und Bewertung 26

33 Erstellung der Software- Architektur Im Rahmen des Entwurfs greifen das Architekturdesign, die Dokumentation der Entwurfsentscheidungen und die Bewertung der Architektur ineinander. Auf Grundlage der Anforderungsanalyse und der Spezifikation der Einflussfaktoren beginnt der Architekt mit dem Entwurf der Software- Architektur. Dabei lässt er sich von den gewonnenen Informationen und seinem Wissen über den Entwurf von Software-Architekturen leiten. Hierzu zählen nach [PBG04] insbesondere Basiswissen (Wissen z.b. aus der Literatur über Entwurfsmethoden, Entwurfsprinzipien, Architekturstile, Architekturmuster) Domänenwissen und Firmen-Know-how (spezielles geistiges Eigentum über Software-Architekturen in einem speziellen Umfeld) Heuristiken (Abstraktion von Erfahrungen im Sinne von Prinzipien, Regeln und Ratschlägen). Parallel zum Entwurf der Architektur muss diese dokumentiert werden. Hierzu werden verschiedene Modelle der Architektur erstellt. Eingesetzt wird in der Regel eine standardisierte Notationsform, z.b. UML. Die Dokumentation wird von unterschiedlichen Personen mit verschiedenen Intentionen verwendet, so dass die Beschreibung aus verschiedenen Perspektiven erfolgen sollte. Es sollte nicht nur festgehalten werden, dass ein bestimmter Architekturstil eingesetzt wird, sondern auch, warum genau dieser für die Erfüllung der Anforderungen geeignet ist. Ist der erste Entwurf der Software-Architektur fertig gestellt, muss er kritisch hinterfragt werden. Eine möglichst frühe Bewertung stellt sicher, dass die weiteren Entwurfsentscheidungen nicht auf falschen Annahmen beruhen. Nach [PBG04] eignet sich für diese Bewertung ein Early Discovery Review. Darauf aufbauend wird die Architektur schrittweise weiter ausgebaut und erweitert, so dass sie alle identifizierten Anforderungen soweit wie möglich erfüllt. Das Ziel muss es sein, eine stabile Architektur zu entwerfen, die alle größeren Architekturrisiken noch vor der Implementierung beseitigt. Beim Entwurf selbst orientiert sich der Architekt fortwährend an den identifizierten Einflussfaktoren, den Entwurfsprinzipien und Entwurfszielen und wendet Heuristiken an, um soweit möglich auf bereits bewährte Lösungsmuster zurückzugreifen. Die Dokumentation der Architektur wird laufend fortgeschrieben und angepasst. Ist die Architektur fast fertig, so wird sie nochmals einer umfassenden Bewertung (sog. Stresstest) unterzogen, um sicherzustellen, dass sie wirklich für das Projekt geeignet ist. Die Ergebnisse dieser Bewertung werden noch eingearbeitet, bevor mit der Umsetzung begonnen wird. 27