Entscheidungsprozess für rationale Architekturentscheidungen

Sven Wohlfarth Fachgebiet Softwaresysteme/Prozessinformatik Technische Universität Ilmenau, 98684 Ilmenau, Germany [email protected] Zusammenfassung Eine hohe Architekturqualität geschäftskritischer Softwaresysteme ist eine zentrale Voraussetzung, um auf Marktveränderungen zeitnah reagieren zu können. Die Entscheidung für die richtige Architektur ist jedoch von vielen Faktoren abhängig: Qualitätsziele, Aufwand, Rahmenbedingungen. Erfolgt die Entscheidung auf Basis subjektiver und zu optimistischer Erwartungen drohen negative Konsequenzen, deren Beseitigung mit erheblichem Mehraufwand verbunden ist. Zur Reduzierung der Risiken wird ein Prozess entwickelt, mit dem rationale Entscheidungen bei der Architekturentwicklung ermöglicht werden. Architekturentwicklung, Entscheidungstheorie, Architekturorientieres Refactoring, Softwarequalität

1. Risiken bei Architekturentscheidungen Die immer kürzeren Innovationszyklen bei Technologiegütern zwingen Unternehmen zu Flexibilität und Anpassungsfähigkeit. Mit modernen Mobiltelefonen können z.B. Informationen, Podcasts oder Video-Downloads aus dem Internet geladen werden. Solche Innovationen schaffen ihre eigenen Märkte und Medienunternehmen sind gezwungen diese Inhalte anzubieten. Können die Abrechnungssysteme jedoch nicht zeitnah angepasst werden, drohen Verluste aufgrund zu hoher Kosten. Es ist teuerer, den Podcast-Nutzern Rechnungen zu schicken, als das Inkassosystem des Mobilfunkanbieters zu nutzen. Eine der wichtigsten Voraussetzungen, um geschäftskritische Softwaresysteme zeitnah anpassen zu können, eine hohe Architekturqualität. Die Architektur muss u.a. verständlich, wartungsfreundlich und leicht zu testen sein, damit Veränderungen oder Erweiterungen zügig umgesetzt werden können. Um eine hohe Architekturqualität zu erzielen ist ein strukturiertes und planvolles Vorgehen notwendig. Dies gilt einerseits für die Entwicklung eines neuen Softwaresystems, bei der eine geeignete Architektur zur Erfüllung der Qualitätsziele auszuwählen ist. Andererseits müssen bei der Restrukturierung gewachsener Legacy-Systeme die richtigen Architekturentscheidungen getroffen werden. Bei der Entscheidung für oder gegen eine Architekturalternative (z.B. Einsatz des Architekturmusters Broker)

müssen neben nicht-funktionalen Anforderungen weitere Faktoren berücksichtigt werden: - Konkurrierende Ziel-Beziehungen (z.B. Wartbarkeit versus Performance) - Vermeidung von Einschränkungen an der Funktionalität (z.B. funktionale Restriktionen durch das SandboxPrinzip beim Einsatz von Java-Applets) - Berücksichtigung und Einhaltung organisatorischer und technischer Rahmenbedingungen (z.B. Termine, Budget, Beachtung von Standards) Im Entscheidungsfall müssen alle Faktoren ausgewogen berücksichtigt werden. In der Praxis erfolgt dies häufig auf Basis subjektiver und meist zu optimistischer Erwartungen. Das führt dazu, dass mittelmäßige Kompromisslösungen als ideale Systemstrukturen aufgefasst werden. Es drohen unerwartete negative Seiteneffekte und Veränderungen am funktionalen Verhalten, deren Beseitigung mit einem erheblichen Mehraufwand verbunden ist. Zur Reduzierung des subjektiven Einflusses auf die Entscheidung soll ein Prozess entwickelt werden, um rationale Entscheidungen bei der Architekturentwicklung zu ermöglichen. Das Ziel ist es, Architekturalternativen durch ein geeignetes methodisches Vorgehen systematisch auszuwählen, deren Konsequenzen objektiv zu ermitteln und sie anhand der Erfüllung der Qualitätsziele und Rahmenbedingungen rational zu bewerten. Der Ausgangspunkt für die Prozessentwicklung sind die Konzepte der Entscheidungstheorie. Diese werden im zweiten Kapitel analysiert, um zu bestimmen, welche Anpassungen für Entscheidungen bei der Architekturentwicklung notwendig sind. Der entwickelte Entscheidungsprozess wird im dritten Kapitel anhand eines praktischen Beispiels dargestellt.

2. Adaption der Entscheidungstheorie Im Rahmen der Entscheidungstheorie werden der deskriptive und der präskriptive Ansatz unterschieden [1]. Während ersterer das Entscheidungsverhalten von Individuen auf kognitiver Ebene beschreibt, ist das Ziel des präskriptiven Ansatzes die Festlegung eines Vorgehens, um Entscheidungen rational treffen zu können. Ein rationales Handeln liegt vor, wenn die Entscheidungsfindung systematisch und objektiv ist.

Außerdem sind konsistente Entscheidungsgrundlagen (Ziele, Annahmen) erforderlich. Um rationale Entscheidungen zu ermöglichen wird im Rahmen der präskriptiven Entscheidungstheorie eine Dekomposition angestrebt [1]. Das Entscheidungsproblem wird aufgeteilt, um durch die isolierte Betrachtung der Teilprobleme die Komplexität zu reduzieren. Danach umfasst ein rationaler Entscheidungsprozess die folgenden Aktivitäten: - Strukturierung der Ziele: Der Ausgangspunkt ist die widerspruchsfreie Strukturierung der Ziele, die durch den Einsatz einer Alternative zu erreichen sind. - Vorauswahl der Alternativen: Im Rahmen der Vorauswahl werden jene Alternativen ausgewählt, welche zur Zielerreichung prinzipiell geeignet sind. - Analyse der Konsequenzen: Im Anschluss werden die Konsequenzen ermittelt. Das sind die Ergebnisse (z.B. Qualitätsverbesserungen), die nach der Entscheidung und Umsetzung einer Alternative zu erwarten sind. - Bewertung der Alternativen: Abschließend wird der Wert der Alternativen für den Entscheidungsträger bestimmt. Eine Alternative wird umso höher bewertet, je stärker die Konsequenzen zur Zielerreichung beitragen. Auf rationaler Ebene ist die Alternative mit dem höchsten Wert auszuwählen, da diese vom Entscheidungsträger am stärksten präferiert, bzw. bevorzugt wird. Der Entscheidungsträger im Rahmen von Architekturentscheidungen ist der Entwickler. Im Kontext von Architekturentscheidungen sind zwei weitere Aspekte zu beachten. Zur Ermittlung der kritischen Architekturbereiche sowie zur Bestimmung der Eignung von Alternativen ist eine Beschreibung der Architektur erforderlich. Darüber hinaus ist durch geeignete Verfahren zu analysieren, ob durch die Implementierung einer Alternative Einschränkungen an der Funktionalität drohen. Die Relevanz der beiden Aspekte wird an einem vergleichbaren, bereits vorgestellten Entscheidungsprozess für architekturorientiertes Refactoring deutlich [3]. Refactoring ist eine Form der Restrukturierung eines Softwaresystems, bei dem die Qualität verbessert, das funktionale Verhalten jedoch nicht verändert wird [4]. Die Refactoringalternativen sind – neben Qualitätsaspekten – danach zu bewerten, ob Änderungen am funktionalen Verhalten drohen. Für diese Analyse ist eine Beschreibung der relevanten Komponenten erforderlich.

3. Entscheidungsprozess für rationale Architekturentscheidungen Der Entscheidungsprozess zur Bewertung von Architekturalternativen umfasst vier Phasen. Die Aktivitäten des im vorangegangenen Kapitel dargestellten Entscheidungsprozesses wurden um die zwei zusätzlichen Aspekte erweitert (vgl. Abb.1). Die ersten beiden Phasen stehen in engem Zusammenhang zueinander und sind daher nebeneinander angeordnet. Zur Identifizierung der Ziele müssen u.a. die kritischen Bereiche der Architektur

bekannt sein. Daran schließt sich die Auswahl und Konkretisierung der Alternativen an. Zur Auswahl stehen Muster, Stile, Technologien oder Softwareprodukte. In der vierten Phase werden die die Konsequenzen ermittelt, mit Schwerpunkt auf die funktionalen Auswirkungen, und es erfolgt die abschließende Bewertung der Alternativen. (1) Strukturierung der Ziele und Rahmenbedingungen

(2) Beschreibung der Architektur

(3) Vorauswahl und Konkretisierung der Alternativen

Basis: Muster, Stile, Technologien und Softwareprodukte

(4) Ermittlung der Konsequenzen und Bewertung der Alternativen

Abb. 1: Entscheidungsprozess bei Architekturalternativen

Praxisbeispiel: Typo3-Architekturveränderung Die Phasen werden anhand einer Architekturveränderung von Typo3 dargestellt. Typo3 ist ein quelloffenes Content-Management-System, um die Inhalte (Content) von umfangreichen und komplexen Webseiten zu verwalten [5]. Über verschiedene Werkzeuge (z.B. RTFEditoren) werden die Inhalte einer Webseite eingegeben und in einer Datenbank gespeichert. Bei Anfrage eines Clients erfolgen die Abfrage der Inhalte aus der Datenbank und die dynamische Generierung der Webseiten. Gerade für kommunikationsintensive Unternehmen und Bildungseinrichtungen ist Typo3 kritisches Softwaresystem. So erfolgt z.B. der gesamte Webauftritt der TU Ilmenau auf Basis von Typo3. Die Einsatzmöglichkeiten von Typo3 in der Version 3.8.1 sind jedoch beschränkt, da ausschließlich MySQLDatenbanken eingesetzt werden können. Gerade im Unternehmensumfeld können jedoch z.B. aus Sicherheitsgründen häufig keine MySQL-Datenbanken installiert werden. Durch eine qualitätsorientierte Architekturveränderung ist dieses Portabilitätsproblem zu beheben.

3.1 Ziele und Rahmenbedingungen In der ersten Phase werden die zu erfüllenden Qualitätsziele identifiziert und widerspruchsfrei strukturiert. Darüber hinaus sind die organisatorischen und technischen Rahmenbedingungen zu ermitteln. Sind die Schwachstellen noch nicht im Detail bekannt, können sie durch szenariobasierte Architekturanalysen ermittelt werden. Eine der wichtigsten Analysemethoden ist die Architecture-Tradeoff-Analysis-Method (ATAM) [6]. Auf Basis von Szenarien werden zentrale Bereiche der Architektur analysiert, in wie weit sie geeignet sind, festgelegte Qualitätsziele zu erfüllen. Es wird z.B. analysiert, ob bei kritischen Fehlern in einer Komponente die Zuverlässigkeit gewahrt bleibt. Im Anschluss an die Identifizierung erfolgt die widerspruchsfreie Strukturierung der Qualitätsziele. ZielMittel- sowie konkurrierende Beziehungen zwischen Zielen sind aufzulösen. Hierfür wird in der Ent-

scheidungstheorie eine Klassifikationsmethode vorgeschlagen [2]. Die Ziele werden in Fundamental- und Instrumentalziele klassifiziert. Die Erfüllung von stets niederrangigen Instrumentalzielen ist die Voraussetzung zur Erreichung der Fundamentalziele. Die Verständlichkeit ist z.B. ein Instrumentalziel zur Verbesserung der Wartbarkeit. Zusätzlich sind die organisatorischen und technischen Rahmenbedingungen zu ermitteln [7]. Organisatorische sind z.B. Budget- und Terminvorgaben, sowie die Anzahl der verfügbaren Mitarbeiter zur Implementierung einer Alternative. Technische Rahmenbedingungen sind z.B. verfügbare Hardwareressourcen, einzuhaltende Standards (z.B. Protokolle) oder bereits implementierte Systemstrukturen (z.B. Muster oder Stile). Die zu erwarteten Qualitätsauswirkungen und der Implementierungsaufwand wird von diesen Faktoren maßgeblich beeinflusst. In Abb. 2 sind die Qualitätsziele für die Typo3Architekturveränderung aufgeführt. Das Fundamentalziel ist die Verbesserung der Portabilität. Um dies zu erreichen ist eine Restrukturierung des Datenbankzugriffes erforderlich. Eine erste Grobanalyse zeigte, dass hierfür die Kapselung des Datenbankzugriffes durch eine Abstraktionsschicht sinnvoll ist. In dieser Schicht soll die notwendige Funktionalität implementiert sein, um auf verschiedene Datenbanken (z.B. MySQL, Oracle) zugreifen zu können. Ein konkurrierendes Ziel ist die Performance im Hinblick auf die Datenbank-Zugriffszeiten. Diese dürfen keinesfalls negativ verändert werden. Portabilität (Fundamental)

Performance (Konkurrierendes Ziel)

Restrukturierung des Keine Veränderungen Datenbankzugriffs an den Zugriffszeiten Instrumentalziel 1 Kapselung des Datenbankzugriffes durch API Instrumentalziel 2

Abb. 2: Qualitätsziele für Tyop3-Architekturveränderung

Als organisatorische Rahmenbedingung sollte die Dauer der Architekturveränderung 50 Personentage nicht überschreiten. Unter technischen Gesichtspunkten ist Typo3 vollständig in der Skriptsprache PHP programmiert und benötigt zur Laufzeit einen entsprechenden Webserver. Trotz der Architekturveränderung soll Typo3 zu früheren Versionen abwärtskompatibel sein.

3.2 Beschreibug der Architektur In der zweiten Phase wird die Architektur des Softwaresystems beschrieben. Das ist notwendig, um die Eignung der Alternativen und deren Konsequenzen zu bestimmen. Zur Komplexitätsreduzierung ist es erforderlich die richtige Sicht auf die Architektur zu wählen. Die Architekturbeschreibung sollte alle Komponenten umfassen, die direkt und indirekt von der Architekturveränderung betroffenen sind. Die direkt betroffenen sind die zu ver-

ändernden Komponenten; die indirekt betroffenen Komponenten bauen auf der Funktionalität der veränderten auf. Um die Architektur zu beschreiben muss die Informationsgrundlage analysiert und strukturiert werden. Quellen sind die Dokumentation, bereits existierende Architekturbeschreibungen oder auch der Quellcode. Der Entwickler muss die Validität der Informationen überprüfen, z.B. in wie weit eine evtl. vorliegende Architekturbeschreibung mit dem entwickelten System übereinstimmt. Im Falle der Entwicklung eines neuen Softwaresystems steht noch keine Architektur zur Verfügung. Die Praxis zeigt jedoch, dass häufig zuerst ein Grundkonzept der Architektur erarbeitet wird, um die funktionalen Anforderungen zu erfüllen (z.B. ein Prototyp). Erst im Anschluss erfolgt die Berücksichtigung der Qualitätsaspekte. Somit kann auch in diesem Fall ein Grobkonzept der Architektur oder ein Prototyp beschrieben werden. Für die Beschreibung steht eine Vielzahl an Beschreibungssprachen zur Verfügung: ACME [8], die UML [9] oder die relativ moderne xADL [10]. Da die Vorauswahl der Architekturalternativen erst in der nächsten Phase erfolgt, kann eine Erweiterung der Beschreibung notwendig werden. In Abb. 3 ist ein Überblick über die Architektur von Typo3 dargestellt. Zentrales Element ist der Typo3-Kern, welcher Bibliotheken für die grundlegenden Funktionen enthält (z.B. die Rechteverwaltung). In der Version 3.8.1 existiert mit 'T3lib_db' eine Abstraktionsschicht, welche Funktionen für den ausschließlichen Zugriff auf MySQLDatenbanken zur Verfügung stellt. Dies sind native PHPFunktionen in der Form 'mysql_query(SQL-Statement)'. Für Typo3 steht eine Reihe an Erweiterungen zur Verfügung, die über eine 'Extension API' auf den Kern zugreifen können. Über das Backend erfolgen die Eingabe der Inhalte und die Konfiguration der Webseiten; das Frontend dient zur dynamischen Generierung der Webseiten. Frontend

Backend

Weitere Kernkomponenten, z.B. T3lib_tcemain Database Abstraction Base API (T3lib_db)

Extension API

Extension Extension (...)

Typo3 Kern MySQL-Datenbank

Abb. 3: Überblick über die Typo3-Architektur

3.3 Vorauswahl und Konkretisierung In der dritten Phase erfolgt die Vorauswahl der Alternativen. Dies ist notwendig, um nur die Alternativen zu berücksichtigen, die für die qualitätsorientierte Architekturentwicklung geeignet sind. Zur Auswahl stehen einerseits Architekturmuster und – mit Einschränkungen

– Entwurfsmuster. Dies sind häufig eingesetzte Musterlösungen bei Entwurf von Architekturen oder umfangreichen Komponentenstrukturen [11]. Entwurfsmuster, die lediglich Quellcode-Fragmente umfassen sind aufgrund des geringen Abstraktionsgrades nicht als Architekturalternativen geeignet. Zum Beispiel beschreibt das Singelton lediglich einen Referenzzähler, um die Instanzen einer Klasse zu zählen. Darüber hinaus können Architekturstile sinnvolle Alternativen darstellen. Mit Stilen (z.B. dem Schichten-Stil) werden auf abstrakter Ebene grundlegende Komponentenstrukturen, sowie Kontroll- und Datenflüsse spezifiziert. Andererseits können Technologien und Softwareprodukte als Alternativen eingesetzt werden (z.B. Komponententechnologien, bestimmte Programmiersprachen oder Bibliotheken) [7]. Die Vorauswahl der Alternativen basiert auf deren erwarteten Qualitätsauswirkungen. Für einzelne Muster und Stile sind die Qualitätseigenschaften bekannt [11]. Eine Kapselung von Komponenten kann z.B. durch den Einsatz der Entwurfsmuster Fassade oder Vermittler ermöglicht werden. Ein Qualitätsmodell zur übergreifenden Analyse von Alternativen fehlt indes. Im Rahmen der Vorauswahl erfolgt eine prototypische Modell-Implementierung. Nachdem ca. 5 bis 6 prinzipiell geeignete Alternativen ermittelt wurden, werden sie prototypisch in das bereits vorliegende Architekturmodell implementiert. Ein UML-Klassendiagramm wird z.B. um eine Fassade oder Vermittler ergänzt; die Klassenstruktur wird entsprechend verändert. Auf dieser Basis kann grob abgeschätzt werden, welche Qualitätsauswirkungen zu erwarten sind und ob die Rahmenbedingungen eingehalten werden können. Das Ziel ist die Reduzierung die Menge an Alternativen auf 2 bis 3 besonders geeignete. Eine Übersicht über das Verfahren der Vorauswahl ist in Abb. 4 dargestellt. Menge an Alternativen Bekannte Qualitätsauswirkungen 5 bis 6 Alternativen Prototypische Modell-Implementierung 2 bis 3 Alternativen Geeignete Qualitätsauswirkungen und Erfüllung der Rahmenbedingungen

Abb. 4: Vorauswahl der Alternativen

Im Anschluss erfolgt die Konkretisierung der Alternativen. Für jede der 2 bis 3 Alternativen wird die Folge an Implementierungsschritten ermittelt, die zur Erreichung der Ziele im konkreten Anwendungsfall notwendig sind. Im Falle der Alternative Fassade ist bspw. zu ermitteln, welche Komponenten zur Realisierung der Kapselung hinzuzufügen oder zu verändern sind. Die Konkretisierung ist ein iterativer Prozess. Die Schrittfolge wird so lange ergänzt oder korrigiert, bis die Qualitätsziele im erforderlichen Umfang erfüllt werden. Eine Iteration umfasst die folgenden Schritte:

- Festlegung der Schrittfolge: Ausgangspunkt der Konkretisierung ist die prototypische ModellImplementierung. Auf Basis der schrittweisen Modellveränderung (z.B. der Veränderung des Klassendiagramms) werden die konkreten Implementierungsschritte abgeleitet. Somit wird die zukünftige Architektur des Softwaresystems auf konkreter Basis deutlich (z.B. mit implementierten Fassade-Muster). - Szenarioanalyse: Im Anschluss wird überprüft, ob die erforderlichen Qualitätsziele erreicht werden. Dies erfolgt anhand von Szenarien, die aus den Qualitätszielen abgeleitet werden. Ein Beispiel ist das Szenario 'Austausch einer Komponente' für das Ziel Wartbarkeit. Durch Walkthroughs wird geprüft, ob mit der zukünftigen Architektur die Qualitätsziele erfüllt werden. Ein Walkthrough ist ein Peer-Review eines Szenarios [14]. - Reaktion: Werden die Qualitätsziele nicht oder nur teilweise erfüllt, sind zusätzliche Implementierungsschritte notwendig oder die bisherige Schrittfolge ist zu korrigieren. In diesem Fall wird eine erneute, evtl. reduzierte Szenarioanalyse erforderlich. Andernfalls ist die Konkretisierung der Alternative beendet. Der zu erwartende Qualitätszustand kann jedoch nicht immer mit Sicherheit bestimmt werden. Unsicherheiten treten vor allem dann auf, wenn technische Rahmenbedingungen die Qualitätsauswirkungen der Alternativen beeinflussen. Ein Beispiel sind wahrscheinliche Wechselwirkungen mit einem bereits implementierten Muster. Es werden ergänzende Schritte spezifiziert, die nur dann anzuwenden sind, wenn die Wechselwirkungen tatsächlich eintreten. Somit existieren optimistische und pessimistische Implementierungsvarianten. Um bei Typo3 über eine Datenbank-Abstraktionsschicht transparent auf verschiedene Datenbanksysteme zugreifen zu können sind drei Alternativen prinzipiell geeignet: - ADODB: Es kann die ADODB-Bibliothek eingesetzt werden [12]. Diese beinhaltet Funktionen zur Transformation von SQL-Statements. Transformationen sind aufgrund von Lücken im SQL-Standard notwendig [13]. Da z.B. das Format von Timestamps im aktuellen SQL-Standard nicht festgelegt ist, sind diese bei nahezu jedem Datenbanksystem anders implementiert. - Native Datenbanktreiber: Die zweite Alternative ist die Entwicklung spezieller Bibliotheken für den Zugriff auf die jeweiligen Datenbanksysteme (Oracle, MySQL ...). Darin werden native PHP-Funktionen zum Datenbankzugriff implementiert, z.B. 'ora_parse (SQL-Statement, Parameter)' für den Zugriff auf Oracle. Zur Kapselung der Bibliotheken kann bspw. das Entwurfsmuster Fassade eingesetzt werden. - ANSI-SQL: Eine weitere Alternative ist die Einschränkung der SQL-Statements auf ANSI-SQL [13]. Im Vergleich zur aktuellen Version von SQL (SQL2 oder SQL-92) steht nur ein reduzierter SQL-Syntax zur Verfügung. Dieser ist jedoch bei den aktuellen Datenbanksystemen einheitlich implementiert. Ein im ANSI-

SQL-Syntax formuliertes SQL-Statement erfordert daher keine weiteren Transformationen. Eine prototypische Modell-Implementierung zeigte, dass mit der ANSI-SQL Alternative grundlegende Änderungen am SQL-Syntax notwendig sind; die geforderte Abwärtskompatibilität ist damit nicht mehr gegeben. Die ersten zwei Alternativen erfüllen die Vorauswahl-Kriterien und werden anschließend konkretisiert. In Abb. 5 sind die konkretisierten Typo3-Alternativen dargestellt. Die ersten Schritte der ADODB-Alternative sind die Implementierung der gleichnamigen Bibliothek sowie die Anpassung der 'T3lib_db', damit das Typo3System über die ADODB-Funktionen auf die Datenbank zugreifen kann. Durch die Transformationen drohen erhebliche Performance-Einbußen. Mit einer Wahrscheinlichkeit von 40% sind daher ergänzende Optimierungen notwendig. Im Rahmen der zweiten Alternative sind die entsprechenden Bibliotheken (hier für MySQL und Oracle) zu entwickeln. Analog zur ersten Alternative ist die 'T3lib_db' anzupassen, damit die Bibliotheken vom Typo3-System genutzt werden können. ADODB-Alternative Implementierung ADODBBibliothek

Wahrscheinlichkeit Anpassung T3lib_db 60% Performance Optimierungen 40%

Entwicklung Entwicklung MySQLOracleBibliothek Bibliothek

Anpassung T3lib_db 100%

Native Datenbanktreiber

Abb. 5: Konkretisierte Typo3-Alternativen

3.4 Ermittlung der Konsequenzen und Bewertung In der letzten Phase des Entscheidungsprozesses werden die Konsequenzen der Alternativen ermittelt. Das ist notwendig, da nur auf dieser Basis eine rationale Bewertung und Entscheidung über die Alternativen erfolgen kann. Die folgenden Konsequenzen sind zu berücksichtigen: - Funktionale Einschränkungen: Im ersten Schritt werden drohende Einschränkungen im funktionalen Verhalten ermittelt. Dies erfolgt erneut auf Basis einer Szenarioanalyse. Die Szenarien basieren auf den funktionalen Anforderungen an das Softwaresystem. Über Walkthroughs wird vor allem bei den direkt veränderten Komponenten analysiert, ob die funktionalen Anforderungen erfüllt werden. Werden diese nicht in vollem Umfang erfüllt, sind entweder Korrekturen an den Implementierungsschritten notwendig. Kleinere Probleme können aber auch bei der tatsächlichen Implementierung behoben werden. Gerade für diese Analyse ist es wichtig, dass die Architekturbeschreibung alle relevanten Komponenten und Beziehungen umfasst. - Implementierungsaufwand: Im zweiten Schritt wird der Aufwand in Stunden oder Personentagen ermittelt, der für die Implementierung der Alternative notwendig ist. Die Basis für die Ermittlung sind u.a. historische Vergleichsdaten. Bei Alternativen mit optimistischen und

pessimistischen Implementierungsvarianten werden mehrere Aufwandszahlen ermittelt. - Qualitätsauswirkungen: Es steht zwar bereits fest, dass mit den Alternativen der erforderliche Qualitätszustand erreicht werden kann. Der Grad der Zielerreichung muss durch den Entwickler noch quantifiziert werden (z.B. durch Noten oder Prozentwerte). In Abb. 6 sind die Konsequenzen der beiden Alternativen dargestellt. Die ADODB-Alternative führt in beiden Fällen zu einer Portabilität mit der Note 2. Mit den Optimierungen verbessert sich die Performance um eine Note auf 2, jedoch erhöht sich der Aufwand um 20 auf 50 Personentage (PT). Die zweite Alternative erfordert durch die Entwicklung der Bibliotheken einen hohen Aufwand in Höhe von 50 PT. Das Ergebnis ist jedoch eine hohe Portabilität und Performance (je Note 1). Durch eine Szenarioanalyse konnte ermittelt werden, dass keine funktionalen Einschränkungen drohen, da eine MySQLAbstraktionsschicht ohnehin existiert. Konsequenzen Portabilität / Performance / Aufwand ADODBAlternative

2 / 3 / 30 PT 60%

Performance Optimierungen 40% Native Datenbanktreiber

2 / 2 / 50 PT

1 / 1 / 50 PT

Abb. 6: Konsequenzen der Typo3-Alternativen

Die abschließende Bewertung der Alternativen umfasst zum einen die Normalisierung der Konsequenzen und deren Gewichtung. Sind Wahrscheinlichkeiten zu berücksichtigen ist der Erwartungswert zu berechnen. Dieses rationale Bewertungsverfahren wird im Rahmen der Entscheidungstheorie thematisiert [1]. Im ersten Schritt werden die Konsequenzen aufgrund der unterschiedlich skalierten Werte (Noten, Personentage …) auf ein Intervall zwischen null und eins normalisiert. Die Konsequenzen, die der Entwickler am stärksten präferiert (z.B. geringster Aufwand) werden mit eins normalisiert. Die nicht präferierten Konsequenzen (z.B. keine bis geringe Qualitätsverbesserungen) werden mit null normalisiert. Die Werte zwischen beiden Extremen werden zwischen null und eins verteilt. Die Verteilung kann individuell oder z.B. mittels der DirectRating-Methode erfolgen [15]. Abb. 7 stellt die Normalisierung am Beispiel der Typo3-Alternativen dar. Portabilität / Performance / Aufwand ADODBAlternative

2 / 3 / 30 PT

0/0/1

60%

2 / 2 / 50 PT 40% Native 1 / 1 / 50 PT Datenbank100% treiber

0 / 0.5 / 0 1/1/0

Abb. 7: Normalisierung der Konsequenzen

Im zweiten Schritt werden die normalisierten Konsequenzen gewichtet. Das ist notwendig, da der Gesamtwert der Alternativen mit der Anzahl der betrachteten Konsequenzen stetig ansteigt. Die Gewichtung

erfolgt anhand der Relevanz oder Bedeutung der Ziele. Die Summe müssen alle Faktoren den Wert eins ergeben. Im Rahmen der Typo3-Architekturveränderung sind die Qualitätsziele für den Entwickler doppelt so wichtig wie der Aufwand. Die Gewichtungsfaktoren für die Qualitätsziele sind jeweils 0.4, für den Aufwand 0.2. Die Gewichtung der Konsequenzen ist in Abb. 8 dargestellt. Da bei der Alternative zur Implementierung nativer Datenbanktreiber keine Wahrscheinlichkeiten zu berücksichtigen sind, beträgt der Gesamtwert 0.8. Portabilität / Perform ance / Aufwand ADODBAlternative 60% 40% Native Datenbank100% treiber

0/0/1

0.0 / 0.0 / 0.2

0 / 0.5 / 0

0.0 / 0.2 / 0.0

1/1/0

0.4 / 0.4 / 0.0

Abb. 8: Gewichtung der Konsequenzen

Im letzten Bewertungsschritt wird der Erwartungswert bei Alternativen mit optimistischen und pessimistischen Implementierungsvarianten ermittelt. Das ist der Mittelwert, der mit dem Einsatz der Alternative erwartet werden kann. Zur Berechung werden die normalisierten und gewichteten Konsequenzen mit den entsprechenden Wahrscheinlichkeiten multipliziert. Dies ergibt in der Summe den Erwartungswert der Alternative. Für die ADODBAlternative ist der Erwartungswert 0.2. Unter einer rationalen Betrachtung sollte sich der Entwickler für die Alternative mit dem höchsten Wert entscheiden. Das ist jene Alternative, die er unter rationalen Gesichtspunkten am stärksten präferiert. Im Falle der Typo3-Architekturveränderung präferiert der Entwickler mit einem Wert von 0.8 eindeutig die Alternative zur Implementierung nativer Datenbanktreiber.

4. Zusammenfassung und Fazit In den vorangegangenen Kapiteln wurde ein rationaler Entscheidungsprozess für die Architekturentwicklung vorgestellt. Entsprechend dem Konzept der präskriptiven Entscheidungstheorie erfolgt zum einen eine widerspruchsfreie Strukturierung der Ziele und Rahmenbedingungen sowie die Beschreibung aller relevanten Komponenten der Architektur. Zum anderen wird eine systematische Vorauswahl und Konkretisierung sowie eine rationale Bewertung der Alternativen durchgeführt. Durch die Komplexitätsreduzierung und das objektive Vorgehen werden Entscheidungen auf Basis riskanter und zu optimistischer Erwartungen vermieden. Bei der Typo3-Architekturveränderung konnten z.B. die Schwachpunkte die ADODB-Alternative objektiv begründet werden. Die Ausführungen zeigen, dass für die systematische Entwicklung der Architekturqualität eine rationale Entscheidungsfindung sinnvoll ist. Bei der Entscheidung ist zu beachten, dass kurzfristige Entscheidungen im Vergleich zu Langfristigen nicht pauschal negativ beurteilt werden. Der Entscheidungsträger muss zwischen Risiko und dem Return-on-Invest

abwägen. Erfahrungen aus der Praxis zeigen, dass die langfristige Option nicht immer die Bessere ist. Die Anwendung des Entscheidungsprozesses ist mit zusätzlichem Analyseaufwand verbunden. Dieser ist jedoch gerade bei der Entwicklung der Architektur geschäftskritischer Softwaresysteme gerechtfertigt. Die Erfahrungen aus der Praxis zeigen, dass der Mehraufwand zur Korrektur von Fehlentscheidungen den zusätzlichen Analyseaufwand um ein Vielfaches übersteigt.

5. Literaturverzeichnis [1] F. Eisenführ und M. Weber, Rationales Entscheiden, Springer, Berlin u.a., 2003. [2] E. Forman und M.A. Selly, Decision By Objectives, World Scientific Publishing Company, Washington, 2002. [3] S. Wohlfarth und M. Riebisch, "Evaluating Alternatives for Architecture-Oriented Refactoring", Proceedings of Conference on the Engineering of Computer Based Systems, IEEE Press, Los Alamitos (CA), 2006, S. 73-79. [4] M. Fowler, K. Beck und E. Gamma, Refactoring: Improving the design of existing code, Addison-Wesley, Boston, 2005. [5] K. Skrhj, "TYPO3 Core APIs", http://typo3.org/ documentation/document-library/core-documentation/doc_core_ api/current/view/, Abruf: 2006-09-15. [6] R. Kazman, M. Klein und P. Clements, "ATAM: Method for Architecture Evaluation", http://www.sei.cmu.edu/pub/ documents/00.reports/pdf/00tr004.pdf, Abruf: 2006-09-15. [7] T. Posch, K Birken und M. Gerdom, Basiswissen Softwarearchitektur – Verstehen, entwerfen, bewerten und dokumentieren, dpunkt.verlag, Heidelberg, 2004. [8] D. Garlan, T. Monroe und D. Wile, "Acme: Architectural Description of Component-Based Systems", Proceedings of CASCON`97, 1997. [9] G. Booch, J. Rumbaugh und I. Jacobson, Das UML Benutzerhandbuch, Addison-Wesley, München u.a., 2006. [10] E.M. Dashofy, A. v.d. Hoek und R.N. Taylor, "A HighlyExtensible, XML-Based Architecture Description Language", Proceedings of the Conference on Software Architectures, 2001. [11] J. Bosch, Design & Use of Software Architectures: Adopting and evolving a product line approach, Addison-Wesley, Harlow, 2000. [12] J. Lim, "ADOdb Database Abstraction Library for PHP (…)", http://adodb.sourceforge.net/, Abruf: 2006-09-15. [13] A. Eisenberg und J Melton, "SQL standardization: the next steps", ACM SIGMOD Record - Volume 29 - Issue 1 (März 2000), S. 63 – 67. [14] R.S. Pressman, Software engineering: a practitioner's approach, McGraw Hill, Boston (Mass), 2001. [15] Peter C. Fishburn, "Methods of Estimating Additive Utilities", Management Science - Vol. 13 - No. 7 - Series A, Sciences (1967), S. 435-453.