Architekturanalyse mit Sotograph

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Architekturanalyse mit Sotograph im Rahmen des Seminars Qualitätssicherung in der Software-Entwicklung Jan P. Heck Themensteller / Betreuer: Prof. Dr. Herbert Kuchen Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Motivation der Architekturanalyse Grundlagen der Architekturanalyse Ziel und Funktionsweise des Sotographen Konzept der Abstraktionsebenen Definition der Subsystem- und Architekturmodelle Werkzeuge des Sotographen Werkzeuggestützte Architekturanalyse mit Sotograph Architektur-Smells Architektur-Smells in Delegations- / Vererbungsbeziehungen Architektur-Smells auf Package-Ebene Architektur-Smells auf Subsystem-Ebene Architektur-Smells zwischen Schichten Werkzeuggestützte Architekturanalyse Metrikbasierte Architekturanalyse Zyklenbasierte Architekturanalyse Trendanalyse der Architektur Zusammenfassung und Ausblick Anhang A Software-Qualität Anhang B Architekturmodell Literaturverzeichnis II

3 Kapitel 1: Motivation der Architekturanalyse 1 Motivation der Architekturanalyse In der Praxis steht meist im Mittelpunkt einer Software-Entwicklung, dass die Software nach Fertigstellung funktionsfähig ist. Die zugrunde liegende Architektur rückt dabei oftmals in den Hintergrund. Ein wesentliches Merkmal für die Qualität einer Software ist jedoch die Software-Architektur, da sie das Grundgerüst dieser darstellt. Dabei reicht die zweckmäßige Definition einer den Anforderungen entsprechenden Architektur indes nicht aus, weil auch die Realisierung dieser Architektur im Entwicklungsprozess und ihr Erhalt bei Wartungsarbeiten im Evolutionsverlauf der Software geprüft werden muss. Ziel dieser Ausarbeitung ist es, die im Rahmen der Software-Entwicklung auftretenden Architekturprobleme zu beschreiben und den vom Software-Produkts Sotograph geleisteten Beitrag zur Qualitätssicherung im Rahmen der Realisierung von Software- Architekturen darzustellen. Dazu sollen die verschiedenen Analysemöglichkeiten erläutert und deren Möglichkeiten zur Verbesserung der Software-Qualität dargestellt werden. Im Folgenden werden zunächst die Grundlagen der Architekturanalyse und die hierzu notwendigen Konzepte eingeführt. Dabei wird auch der dieser Arbeit zugrunde liegende Qualitätsbegriff erarbeitet und insbesondere eine Abgrenzung der unterschiedlichen Arten der Qualitätsbetrachtung vorgenommen. Im anschließenden Kapitel werden häufig auftretende Architekturprobleme dargestellt und in Bezug dazu die wesentlichen - durch den Sotographen realisierbaren - Möglichkeiten zur Lokalisierung von Qualitätsproblemen im Hinblick auf die Software-Architektur erläutert und an Analysebeispielen veranschaulicht. Abschließend wird zu den Möglichkeiten einer Verbesserung der Qualitätssicherung durch die Verwendung des Sotographen Stellung genommen und dieser bewertet werden. 2 Grundlagen der Architekturanalyse Bei der Betrachtung von Software gilt es im Rahmen dieser Ausarbeitung in Anlehnung an [Ba00] zwischen dem Software-System, das die innere Sichtweise eines Software- Entwicklers beschreibt und dem Software-Produkt, das die Software aus Sicht des Kunden oder Auftraggebers von außen betrachtet und den Funktionsumfang beschreibt, zu differenzieren. [Ba00, S. 24] Das Grundgerüst eines Software-Systems bildet dabei eine Software-Architektur, die allgemein betrachtet die Strukturen eines Software-Systems 3

4 Kapitel 2: Grundlagen der Architekturanalyse durch Systemkomponenten und deren Beziehungen zueinander beschreibt. [Ba00, S.696] Die Software-Architektur ist, nach in der Literatur (z.b. [Si04], [Bo00]) verbreiteter Definition, im Anschluss an [BCK03, S. 3] folgendermaßen definiert: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationship among them. Im Zuge der Software-Entwicklung treten verschiedene Situationen auf, die eine qualitative Überprüfung der Software-Architektur notwendig machen: Überprüfung der Qualität eines (Teil-) Software-Systems, das zur Weiterentwicklung oder zur Integration in ein Gesamtsystem verwendet werden soll; Prüfung der Auswirkungen einer Veränderung (What-If-Analyse) im Zusammenhang mit dem Refactoring eines Software-Systems; [LR04, S. 253] Kontinuierliche Qualitätsprüfung im Entwicklungsprozess im Hinblick darauf, ob die Architekturvorgaben eingehalten worden sind. [SM06a, S. 1] Die Software-Qualität ist nach DIN ISO 9126 definiert als [ ] die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. [Ba98, S. 257] Folgende Qualitätsmerkmale sind hierbei festgelegt: Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit. [Ba98, S. 257 f.] Zu differenzieren ist bei der Betrachtung der Software-Qualität zwischen der - hier im Kern betrachteten - Architektur- und der Codequalität. Die Architekturqualität - beschrieben durch die konzeptionelle Integrität der Bestandteile, die Fehlerfreiheit und Vollständigkeit des Modells sowie dessen Realisierbarkeit - spielt insbesondere für die Zuverlässigkeit, Effizienz, Änderbarkeit und Übertragbarkeit eines Software-Produkts eine zentrale Rolle. [BCK03, S. 96 f.] Hierbei wird die Software-Architektur mit zunehmender Größe und Evolution der Software komplexer und unübersichtlicher, gewinnt zugleich aber für die Qualität der Software an Bedeutung. Von der Architekturqualität abzugrenzen ist die Codequalität, welche die Umsetzung der geforderten Funktionalität im Quellcode angibt und demzufolge die Funktionalität und Benutzbarkeit der Software determiniert. (Zur Veranschaulichung der Software-Qualität vgl. Anhang A.) Der Sotograph ist ein kommerzielles Produkt der Software Tomography GmbH [ST06], der das Ziel verfolgt, Anwendungen automatisiert hinsichtlich der Software-Qualität zu 4

5 Kapitel 2: Grundlagen der Architekturanalyse analysieren. Dabei werden Anwendungen die auf Basis von Java oder C/C++ entwickelt wurden - beziehungsweise werden - unterstützt. Auf diese Weise soll hinsichtlich der inneren Code- und Architekturqualität Transparenz für den Nutzer entstehen. [BBS03, S. 22] Bei der Überprüfung der Zweckmäßigkeit der Architekturvorgabe bezüglich der Erfüllung der fachlichen Anforderungen ist eine Automatisierung nur bedingt möglich, weshalb diese Aufgabe dem Modellierer der Architektur obliegt. Jedoch lässt sich im Rahmen eines Soll-Ist-Vergleiches ermitteln, inwieweit eine Architekturvorgabe in der Entwicklung eingehalten wird. Dadurch wird bei einer den Anforderungen entsprechenden, zweckmäßigen Architekturvorgabe die Software-Qualität automatisiert quantifizierbar. Im Weiteren wird von einem Software-System auf Basis der Programmiersprache Java ausgegangen; die einzelnen Analysen lassen sich analog auch auf anderen Systemen, die in einer der durch den Sotographen unterstützten, objektorientierten Programmiersprache realisiert sind, durchführen. Vollständige Analysen zur Qualitätssicherung der Architektur von Software-Systemen lassen sich nicht mit Hilfe der durch eine integrierte Entwicklungsumgebung - wie etwa Eclipse oder Visual Studio.NET - bereitgestellten Werkzeuge realisieren. Deren Analysemöglichkeiten (z.b. Ermittlung nicht verwendeter Methoden oder Informationen darüber, welche Systemteile beim Umbenennen einer Klasse betroffen sind) bewegen sich auf Ebene des Quellcodes. Architekturvorgaben werden auf höheren Abstraktionsebenen definiert. Zur Erzeugung aussagekräftiger Informationen über die Qualität der Software-Architektur ist es notwendig, die definierte Architekturvorgabe möglichst automatisiert - mit der realisierten Software-Architektur zu vergleichen. Die Definition einer Architekturvorgabe wird vom Sotographen unterstützt und in den Abschnitten 2.2 und 2.3 detailliert erläutert. Die mit dem Sotographen hinsichtlich der Code- und Architekturqualität erstellten Analysen lassen sich durch die Erweiterungen Sotoweb und Sotoreport direkt in den Entwicklungsprozess einbinden. Die hiermit erstellten Berichte ermöglichen es, die Mächtigkeit des Sotographen [bezüglich der Analysemöglichkeiten] auf eine einfache Darstellungsebene zu reduzieren [ST06], wodurch dem individuellen Informationsbedarf des jeweiligen Analysten Rechnung getragen werden kann. 5

6 Kapitel 2: Grundlagen der Architekturanalyse 2.1 Ziel und Funktionsweise des Sotographen Ziel des Sotographen in Hinblick auf die Architekturqualität ist es nicht, die Qualität der Architekturvorgabe hinsichtlich ihrer Erfüllung der fachlichen und technischen Anforderungen zu prüfen, sondern einen Vergleich zwischen der Architekturvorgabe und deren Realisierung im Software-System zu erstellen, um so die realisierte Architekturqualität analysieren zu können. [BCK03, S. 6-14] Bei der Durchführung einer Analyse mit dem Sotographen wird - wie Abbildung 1 veranschaulicht - in einem ersten Schritt das zentrale Repository des Sotographen durch Angabe der entsprechenden Pfade bzw. JAR-Dateien des zu analysierenden Software- Systems mit den im Byte- oder Quellcode enthaltenen Informationen gefüllt (Extraktion). Dabei kommen verschiedene Quellcodeparser zur Extraktion der für die Analyse notwendigen Fakten zum Einsatz. Abbildung 1: Ablauf einer Software-Architektur im Sotographen Ist der Quellcode nicht nur der Bytecode - des analysierten Systems bekannt bzw. wird die Analyse direkt auf Basis des Quellcodes durchgeführt, kann die Ursache für die gefundene Architekturabweichung bei den einzelnen Analysen direkt im Quellcode angezeigt werden. Beim Einlesen werden die verschiedenen Typen von Artefakten (z.b. Klassen, Packages, etc.) sowie verschiedene Arten von Referenzen (Methodenaufruf, Attributbenutzung, Vererbungsbeziehung) zwischen den Artefakten erkannt und in der Datenbank gespeichert. [SM06b, S. 3-5; BW04, S. 242] Zentraler Ausgangspunkt bei jeder Analyse ist die MySQL- Datenbank (Daten- Repository), in der alle notwendigen Informationen über das zu analysierende Software- System enthalten sind (Speicherung). Eine Datenbank bietet neben der Möglichkeit der dauerhaften, zuverlässigen Speicherung von integrierten großen Datenmengen [Ba00, S. 6

7 Kapitel 2: Grundlagen der Architekturanalyse 743] den Vorteil, dass der Anwender mittels der Structured Query Language (SQL) individuelle Abfragen erstellen kann, über welche die durch den Sotographen mitgelieferten Metriken erweitert oder verändert werden können und somit individuelle Analysen realisierbar sind. Zu diesem Zweck ist das zugrunde liegende Datenmodell für den Benutzer des Sotographen zugänglich. Die mit dem Sotographen durchgeführten Architekturanalysen sind statisch: Es findet zu einem fixen Zeitpunkt ein Vergleich zwischen einem Ist- und Soll-Modell statt. Diese Soll-Vorgabe muss neben der Extraktion von Informationen aus dem Quellcode in Form eines Subsystems - und darauf aufbauend eines Architekturmodells - manuell definiert werden (Abschnitt 2.3). Auf Basis dieser Angaben werden die in der Umsetzung auftretenden Soll-Ist-Abweichungen analysiert. [BBS03, S. 22] Die durch eine Analyse auf Basis der verschiedenen Werkzeuge (Abschnitt 2.4) gewonnenen Ergebnisse werden in tabellarischer oder grafischer Form aufbereitet, wobei die Resultate verschiedener Analysen in grafischen Darstellungen kombiniert werden können (Bericht). Neben den Ergebnisberichten der einzelnen Version eines Software- Produktes kann im Rahmen einer Trendanalyse (Abschnitt 3.2.3) auch ein Vergleich zwischen den verschiedenen Versionen zur Betrachtung der Veränderungen im zeitlichen Verlauf erstellt werden. 2.2 Konzept der Abstraktionsebenen Eine Verletzung der Architekturvorgabe entsteht auf Befehlsebene, da jeder Methodenaufruf, jede Attributverwendung oder sonstige Nutzung eines anderen Artefaktes nonkonform zur vorgegebenen Architektur sein kann. Eine Interpretation der Analyseergebnisse auf Befehlsebene dagegen würde eine vollkommene Informationsüberflutung für den Analysten bedeuten. Zwar muss die Analyse jeden einzelnen Programmbefehl in Bezug auf die Konformität mit der Architekturvorgabe überprüfen, für den Benutzer sind die Ergebnisse jedoch strukturiert zusammenzufassen, ohne dass dabei ein Informationsverlust entsteht. Programmiersprachen stellen bereits unterschiedliche Konzepte zur Aggregation von Teilelementen zur Verfügung, die es zu vereinheitlichen gilt. In Java werden Methoden, Klassen und Packages als Abstraktionsebenen bereitgestellt. Nicht alle objektorientierten Programmiersprachen stellen jedoch die Abstraktionsebene der Packages zur Verfügung, weshalb bei der Analyse von Software-Systemen auf Basis solcher Sprachen beim Einlesen des Quellcodes alle in einem Ordner liegenden Da- 7

8 Kapitel 2: Grundlagen der Architekturanalyse teien zu einem Artefakt der Abstraktionsebene Package zusammengefasst werden. [BW04, S. 242] Für eine aussagekräftige Architekturanalyse ist die Package-Ebene noch zu feingranular, weshalb der Sotograph es ermöglicht, mehrere Packages zu einem logischen Subsystem zusammen zu fassen. [BKL04, S. 1; SH06 S. 9] Die Möglichkeiten zur Definition solcher Subsysteme werden im folgenden Abschnitt detailliert erläutert. Zur vollständigen Abbildung der Soll-Architektur können ein oder mehrere Architekturmodelle hinterlegt werden. Diese geben die Beziehung sowie die Art der erlaubten Zugriffe zwischen den definierten Subsystemen an. Entlang der somit gebildeten Abstraktionsebenen (Methode, Klasse, Package, Subsystem, Architekturmodell) werden die aus der Analyse entstandenen Ergebnisse zusammengefasst. Dies erhöht den Informationswert der Analyse, da für eine z.b. auf Klassenebene durchgeführte Analyse die Ergebnisse für den Analysten auf einer höheren Abstraktionsebene aggregiert werden können. Hierdurch ist es möglich, in einem ersten Schritt einen groben Überblick über den Zustand des Systems zu bekommen und problematische Bereiche für eine darauf folgende Bearbeitung zu lokalisieren. 2.3 Definition der Subsystem- und Architekturmodelle Da durch das Einlesen des Quellcodes nur Artefakte auf Package-Ebene definiert sind, müssen Subsystem- und Architekturmodell manuell vom Benutzer definiert werden. Zur Vereinfachung der Definition der Modelle stehen Bildschirmdialoge zur Verfügung, welche die Definition der Modelle durch die Generierung regulärer Ausdrücke oder die Auflistung der vom Subsystem umfassten Packages auf Grundlage der vom Benutzer eingegebenen Informationen definieren. Dabei kann bei einem Subsystem im Sinne des Sotographen nach [LR04] zwischen einer öffentlichen Schnittstelle und der eigentlichen Implementierung unterschieden werden. Diese Trennung zwischen Schnittstelle und Implementierung ist in der Entwicklung zumeist nur durch eine Konvention des Entwicklerteams erreichbar, da gängige Programmiersprachen hierfür ohne den Einsatz spezieller Werkzeuge keine Möglichkeiten bereitstellen. Zur Prüfung der Einhaltung kann zusätzlich der Pfad des Application Programming Interface (API), über das auf das Subsystem zugegriffen werden soll, angegeben werden. Ähnliches gilt für die Berücksichtigung einer Schichtenarchitektur: Diese lässt sich in einer Entwicklung nur über eine Konvention einhalten und wird durch sinnvolle Benennung von Packages unterstützt. Bei der Prüfung der Einhaltung dieser Vorgaben unterstützen die Modelle 8

9 Kapitel 2: Grundlagen der Architekturanalyse des Sotographen sowohl schichtenbasierte als auch graphenförmige Architekturmodelle. Im Rahmen einer Architektur, die mit Hilfe von Schichten strukturiert wird, werden die einzelnen Subsysteme explizit einer Schicht zugeordnet, wobei höher liegende Schichten von Inhalten der darunter liegenden abstrahieren. Bei einer Strukturierung in Form eines Graphen wird jeweils für ein Paar von Subsystemen angegeben, ob Beziehungen zwischen diesen erlaubt sind oder nicht. [BW04, S. 242; BKL04, S. 2] Die Unified Modeling Language (UML) stellt als allgemein verwendbare Modellierungssprache einen Standard für die Beschreibung von Software-Architekturen im Rahmen von Software-Entwicklungen dar und wird in den meisten Entwicklungen großer Software-Produkte eingesetzt. [Ke05, S.15] Ein Import der vorliegenden UML- Modelle als Basis für die Definition einer Soll-Architektur in den Sotographen ist dennoch nicht möglich, wodurch ein Medienbruch bei der Modellierung der Software- Architektur entsteht. Aufgabe des Sotographen ist dabei nicht die Prüfung der Qualität der vorliegenden Architektur des Software-Systems, sondern vielmehr die Prüfung, ob in Bezug auf die definierte Soll-Architektur architektur-verletzende Referenzen im Quellcode enthalten sind. [SH06, S.14] Die Interpretation der Ergebnisse sowie die Beseitigung dieser Problembereiche und die somit ggf. notwendige Anpassung der Architekturvorgabe obliegen dem jeweiligen Analysten. Die Definition des Subsystemmodells des Sotographen erfolgt in einer Java-kompatiblen Beschreibungssprache und wird auf Grundlage der vom Benutzer angegebenen Informationen generiert: public void generatesubsystemmodel(imodelfactory f, ISubsystemModel sm){ ISubsystem sub; sm.createsubsystemgroupbyregexp("hotelverwaltung", "de.hotelverwaltung.'.*'", sm.chasinterface,sm.crootpackageisinterface); } Vorstehendes Beispiel zeigt die Definition eines Subsystemmodells auf Basis eines regulären Ausdrucks, die für jedes Package unterhalb von de.hotelverwaltung je ein logisches Subsystem erstellt. Der Name der aus dieser Definition resultierenden Subsysteme setzt sich aus einem explizit angegebenen Präfix ( hotelverwaltung ) sowie dem Namen des Packages zusammen. Wird davon ausgegangen, dass im Package de.hotelverwaltung die Packages beans, utils, jdbc und gui liegen, würde für 9

10 Kapitel 2: Grundlagen der Architekturanalyse jedes dieser Packages ein eigenes Subsystem erstellt. Diese würden nach erfolgter Speicherung des Subsystemmodells in der Datenbank in allen Werkzeugen des Sotographen für Analysen zur Verfügung stehen. Im Architekturmodell für eine schichtenbasierte Architektur wird neben der Definition der einzelnen Schichten hinterlegt, welche Subsysteme zu einer Schicht gehören und welche Zugriffe innerhalb und zwischen den Schichten zulässig sind. Die Schichten werden hierbei entsprechend ihres Abstraktionsniveaus angeordnet (vgl. Anhang B). 2.4 Werkzeuge des Sotographen Der Sotograph umfasst verschiedene Analyse- und Administrationswerkzeuge, die im Rahmen der Analyse integriert zum Einsatz kommen. Die wesentlichen Werkzeuge für eine Architekturanalyse werden im Folgenden vorgestellt. Der GraphScope visualisiert den strukturellen Aufbau eines Software-Systems sowie die Ergebnisse von Analysen anderer Werkzeuge. Neben der Option, die zu visualisierenden Referenzarten (Methodenaufruf, Attributzugriff, Vererbung) individuell auf den Analysezweck hin anzupassen, ist es ferner möglich, das Layout der ausgegebenen Graphen zur Hervorhebung bestimmter Aspekte zu verändern und die Analyseergebnisse unterschiedlicher Analysen zu verknüpfen bzw. in die strukturelle Abbildung des Software-Systems zu integrieren. Mit dem ResultScope werden Analyseergebnisse in tabellarischer Form angezeigt und eine gezielte Filterung der Ergebnisse ermöglicht. Die gesamte (oder Teile der) Ergebnisliste kann als neuer Graph des GraphScope angezeigt oder farblich gekennzeichnet in einen bestehenden Graphen eingefügt werden. Von einer Analyse auf z.b. Subsystem- Ebene lassen sich die aggregierten Ergebnisse auf Quellcode-Ebene verfeinern und die verursachenden Stellen im Quellcode finden. Das Administrationswerkzeug ModelManager ist die Grundlage für die Definition der Subsystem-/Architekturmodelle, die zur Festlegung der höheren Abstraktionsebenen benötigt werden (vgl. Abschnitt 2.3). Mit Hilfe des MetricScope bzw. im Rahmen der Trendanalyse mit dem TrendMetric- Scope lassen sich vordefinierte Metriken auf einzelne Artefakte anwenden oder die Artefakte verschiedener Versionen der Software miteinander vergleichen (vgl. Abschnitt 3.2.3). 10

11 Kapitel 3: Werkzeuggestützte Architekturanalyse mit Sotograph 3 Werkzeuggestützte Architekturanalyse mit Sotograph 3.1 Architektur-Smells Betrachtet ein erfahrener Entwickler ein Software-System, bekommt er meist ein Gefühl dafür, an welchen Stellen das System Schwächen hat. Solche Schwachstellen sind Auffälligkeiten, die nicht unbedingt zu Problemen führen müssen, oftmals jedoch ein Indiz für problematische Bereiche sind, die es zu überprüfen gilt. Man bezeichnet diese Auffälligkeiten - in der Anlehnung daran, dass ein System nach Problemen riecht - als Smells. Dabei unterscheidet man je nach Art in Code-Smells, wie z.b. die Duplizierung von Quellcode zu sehr ähnlichen Methoden, und Architektur-Smells, wie z.b. die Aufwärtsreferenzierung in einer Schichtenarchitektur. [LR04, S. 33] Auf die verschiedenen Architektur-Smells und die daraus resultierenden Probleme für die Qualität der Software-Architektur wird im Folgenden eingegangen Architektur-Smells in Delegations- / Vererbungsbeziehungen Delegation und Vererbung stellen Beziehungen zwischen Klassen dar, auf deren Basis es zu verschiedenen Verletzungen der vorgegebenen Architektur kommen kann, wenn die Beziehungen nicht konform mit der Soll-Architektur sind. Ein Indikator für eine zu überarbeitende Vererbungsstruktur ist die Verwendung von Typabfragen (instanceof). Diese sind ein Hinweis darauf, dass die Vererbungsbeziehung nicht nur in den Klassen, sondern auch im darauf zugreifenden Client ausgedrückt wird, was bei einer Veränderung der Vererbungshierarchie auch zu Anpassungsaufwand im Client führen würde. [LR04, S. 45] Der Einsatz von Vererbung macht nur Sinn, wenn es dabei auch zur Verwendung von polymorphen Zuweisungen kommt. Wird lediglich eine Generalisierung geschaffen, ohne dass für die generalisierten Klassen auch Zuweisungen existieren, kann die Vererbungshierarchie aufgelöst werden. Smells dieser Art lassen sich nicht unmittelbar mit dem Sotographen aufdecken: Es können lediglich Indizien - wie eine große Anzahl von Instanziierungen von Objekten der Unterklassen, die einer deutlich geringeren Anzahl von Objekt-Instanziierungen der Oberklasse gegenübersteht - gesammelt werden. Eine Vererbungsstruktur ist dann kritisch zu prüfen, wenn Unterklassen keine Methoden ü- 11

12 Kapitel 3: Werkzeuggestützte Architekturanalyse mit Sotograph berschreiben, sondern lediglich Funktionalität hinzufügen, da sich in diesem Fall die Vererbungsbeziehung durch eine flexiblere Delegationsbeziehung ersetzen lässt. Darüber hinaus kann es unbenutzte Artefakte geben, die dadurch entstehen, dass von Entwicklern Funktionalität implementiert wird, die später nicht zum Einsatz kommt oder diese Klassen im Rahmen eines Refactoring-Prozesses irrelevant geworden sind. Ein Beispiel dafür sind auf Grundlage einer Webservice Description Language (WSDL)-Datei erzeugte Zugriffsklassen, bei denen der Webservice im Entwicklungsverlauf durch einen anderen ersetzt wurde und die Zugriffsklassen nicht weiter genutzt werden. Diese Artefakte belasten ein Software-System unnötig und können somit entfernt werden. Parallele Vererbungshierarchien, bei denen - wie in Abbildung 2 gezeigt - z.b. analog zur Hierarchie der Datenobjekte auch die passende Vererbungshierarchie der Anzeigeobjekte erzeugt wird, sorgen bei einer Veränderung für eine Vervielfachung des Modifikationsaufwandes, da an zwei Stellen dieselbe Entwurfsentscheidung getroffen wurde und in der Konsequenz auch beide Stellen zu modifizieren sind. [LR04, S.50] Abbildung 2: Parallele Vererbungshierarchien (in Anlehnung an [LR04, S. 50]) Eine solche Struktur kann dadurch aufgelöst werden, indem eine der Vererbungshierarchien bestehen bleibt und die verwendeten Klassen durch flexiblere Delegationsstrukturen angebunden werden. Zyklische Beziehungen zwischen Artefakten führen dazu, dass die einzelnen Systemteile enger gekoppelt werden. Diese gekoppelten Elemente können nur gemeinsam als Konstrukt betrachtet werden, was einerseits das Verständnis erschwert, andererseits die Wiederverwendung und Testbarkeit des Gesamtsystems aufwändiger gestaltet, da das gesamte Geflecht von Artefakten verwendet oder getestet werden muss. Zudem ist kaum zu verhindern, dass durch die enge Kopplung mit anderen Artefakten Veränderungen im Rahmen von Wartungsarbeiten ungewollte Auswirkungen auf andere Teilbereiche nach sich ziehen. [LR04, S.40,53; BBS03, S. 25] Dabei ist zu beobachten, dass 12

13 Kapitel 3: Werkzeuggestützte Architekturanalyse mit Sotograph ein längerer Zyklus - ein Zyklus, in dem mehr Artefakte enthalten sind - schwerwiegendere Probleme nach sich zieht als ein kürzerer Zyklus, da die daraus resultierenden monolithischen Einheiten größer und damit schwerer zu handhaben sind. Dies gilt insbesondere, wenn die Zyklen über Subsystemgrenzen hinausgehen. [LR04, S. 41] Architektur-Smells auf Package-Ebene Die Strukturierung eines Software-Systems durch Packages ist nur zweckmäßig, wenn diese möglichst selbsterklärend benannt sind und überschneidungsfrei definiert wurden. Die überschneidungsfreie Definition ist im Evolutionsprozess einer Software schwierig einzuhalten, da bei Wartungsarbeiten oder dem Hinzufügen von neuen Funktionalitäten oftmals nicht eindeutig ist, wo diese anzufügen sind. Die Größe der Packages - definiert durch die Anzahl der darin enthaltenen Klassen - spielt eine Rolle für den Grad des Nutzens, der durch das Package erreicht wird. Dabei muss zwischen der durch die Einführung eines Packages entstehenden zusätzlichen Komplexität und der dadurch gewonnenen Strukturierung abgewogen werden. [LR04, S.55] Eine allgemeine Vorgabe für die optimale Große der Packages gibt es ebenso wenig wie eine Möglichkeit zur automatisierten Überprüfung der zweckmäßigen Benennung. Hier gilt es im Entwicklerteam, Grenzwerte für die maximale und minimale Anzahl der Klassen pro Package zu definieren und die Einhaltung dieser Werte mit entsprechenden Metriken zu prüfen. Benennung sowie Struktur der Packages lassen sich über den GraphScope mit Hilfe von Package-Graphen visualisieren und anhand dessen Problembereiche identifizieren Architektur-Smells auf Subsystem-Ebene Die Strukturierung eines Systems in verschiedene Subsysteme hat nach [LR04] die folgenden Vorteile: 1. Erlernbarkeit: Das System ist durch die Untergliederung schneller und einfacher zu verstehen, da ein grobes Verständnis des Software-Systems durch die Zerlegung des Systems in Komponenten sowie in Beziehungen ermöglicht wird. 2. Wartbarkeit: Durch die Trennung von Implementierung und öffentlicher Schnittstelle ist es möglich, die interne Realisierung eines Subsystems zu verbessern oder zu verändern, ohne dass andere Subsysteme betroffen sind. 3. Multiprojektentwicklung: Die Entwicklung eines einzelnen Subsystems kann in individuellen Teams erfolgen, da für die Verwendung des Subsystems keinerlei 13

14 Kapitel 3: Werkzeuggestützte Architekturanalyse mit Sotograph Information über die Implementierung notwendig ist. Durch die Möglichkeit der parallelen Entwicklung wird der Entwicklungsprozess erheblich beschleunigt. 4. Deployment: Anstelle des Komplettsystems können im Deployment-Prozess auch einzelne Teilkomponenten ausgetauscht werden. 5. Testbarkeit: Ein Subsystem kann unabhängig von anderen Subsystemen in sich abgeschlossen getestet werden. Probleme in Bezug auf die Missachtung der Architekturvorgaben auf der Ebene der Subsysteme entstehen hauptsächlich dadurch, dass die gängigen objektorientierten Programmiersprachen keine Konzepte für die Realisierung von Subsystemen bereitstellen. Daher wird hinsichtlich der Unterteilung des Systems in Subsysteme mit Konventionen innerhalb des Entwicklerteams gearbeitet, deren Einhaltung es zu prüfen gilt. Des Weiteren spielt die Größe der Subsysteme für die optimale Strukturierung eine wichtige Rolle, da bei einer zu kleinen Dimensionierung zu viele Subsysteme definiert werden müssen. Hierdurch wird die Erlernbarkeit eingeschränkt, da die Strukturierung, die durch die Subsysteme erreicht werden soll, verloren geht. Eine zu große Dimensionierung der Subsysteme, die im Extremfall mit einem Verzicht auf die Definition von Subsystemen gleichzusetzen ist, führt dazu, dass es nicht zu einer Zerlegung in Komponenten kommt und die damit verbundenen Vorteile verloren gehen Architektur-Smells zwischen Schichten Eine Schichtenarchitektur ist dadurch gekennzeichnet, dass Subsysteme einer Schicht beliebig aufeinander zugreifen können, schichten-übergreifende Zugriffe indes nur bedingt zulässig sind. Im Rahmen einer strikten Schichtenarchitektur sind Zugriffe auf alle Schichten mit niedrigerem Abstraktionsniveau erlaubt. Abbildung 3: Architekturverletzungen in einer Schichtenarchitektur (in Anlehnung an [BW, S. 243; Ba00, S.297]) 14

15 Kapitel 3: Werkzeuggestützte Architekturanalyse mit Sotograph In der restriktiveren, linearen Schichtenarchitektur sind indes nur Referenzen auf die direkt darunter liegende Schicht zulässig. [Ba00, S. 697] Abbildung 3 zeigt die verschiedenen Zugriffsarten zwischen Artefakten, von denen die architektur-verletzenden im Folgenden erläutert werden: 1. Aufwärtsreferenz: Eine höher liegende Schicht abstrahiert von Sachverhalten der darunter liegenden, wobei das allgemeine Ziel eines Schichtenmodells ist, die Austauschbarkeit von einzelnen Schichten ohne eine Beeinflussung anderer Schichten zu gewährleisten. Verwendet ein Subsystem einer unteren Schicht eine Komponente aus einer höher liegenden Schicht, wird dieses Prinzip durchbrochen und es kommt zu einer engeren Kopplung zwischen den Schichten, indem Zyklen zwischen diesen entstehen. [LR04, S.66; Ba00, S.697] 2. Umgehung der Subsystem-API: Eine Umgehung der öffentlichen Schnittstelle stellt eine Architekturverletzung dar, da ein direkter Zugriff auf die Implementierung nicht zulässig ist. Zur Überprüfung von Architekturverletzungen dieses Typs kann im Subsystemmodell der Pfad der API-Schnittstelle definiert werden. 3. Durchbrechen der strikten Schichtung: Diese entsteht z.b. durch direktes Verwenden der Datenschicht von der Oberfläche. Das Architekturmodell des Sotographen ist individueller gestaltbar als die in [Ba00] getroffene Unterscheidung zwischen strikter und linearer Schichtung, da für jede Schicht individuell angegeben werden kann, auf wie viele darunter liegende Schichten zugegriffen werden darf. 3.2 Werkzeuggestützte Architekturanalyse Metrikbasierte Architekturanalyse Allgemein nach [Ba98, S. 225] und in Bezug auf den Sotographen nach [SM06a, S. 3] definiert eine Software-Metrik, wie die Kenngröße eines Software-Produkts oder eines Software-Prozesses gemessen wird. Ziel einer Metrik ist es, im Software- Qualitätsmanagement quantitative Angaben über den Software-Entwicklungsprozess zu generieren. [SM06a, S.3] Als Informationsbasis für die metrikbasierte Architekturanalyse stehen einerseits Informationen wie Referenzen zwischen Artefakten zur Verfügung, die im Rahmen des Extraktionsprozesses ermittelt wurden. Andererseits werden durch 15

16 Kapitel 3: Werkzeuggestützte Architekturanalyse mit Sotograph die Definition des Subsystem- und Architekturmodells angegebene Strukturinformationen berücksichtigt. [SM06a, S. 5] Der Sotograph unterstützt grundsätzlich drei verschiedene Arten der Metrikberechnung: 1. Berechnungen von Metrikwerten auf Basis von Informationen, die in der Datenbank vorliegen: Diese Metriken werden durch SQL-Abfragen erstellt. [SM06a, S. 6] Ein Beispiel hierfür stellt die Ermittlung von duplizierten Code-Blocks dar, die beim Einlesen des Quellcodes in der Tabelle DuplicatedCodeBlocks gespeichert werden: SELECT COUNT( DISTINCT d1.blockid ) FROM DuplicatedCodeBlocks d1 WHERE d1.fileid = f.fileid ; 2. Ein regulärer Ausdruck wird zur Berechnung der Anzahl an Fundstellen für einen bestimmten Begriff in den Quellcode-Dateien des zugrunde liegenden Software-Systems verwendet. [SM06a, S. 6] Die Metrik FileToDo nutzt einen regulären Ausdruck zur Ermittlung der Existenz von todo im Quellcode. file_regex_metric ( FileToDo := #[tt][oo] *[dd][oo]# ) 3. Der Sotograph kann durch Plugins erweitert werden, die beliebige Werte auf Basis des Quellcodes ausrechnen können. Die Definition der Metrik selbst enthält in diesem Fall nur den Klassennamen der Plugin-Klasse: file_plugin_metric ( FileCommentedOutCodeLines := com.sotogra.soto.plugins.impl.basiccounts ) Ein Hauptproblem der metrikbasierten Architekturanalyse ist die Vielzahl an Metriken und die daraus resultierende Menge an Ergebnissen, die den Benutzer schnell den Blick für das Wesentliche verliert lässt. Zur Vermeidung dessen und zur Anzeige der lediglich relevanten Werte für den Benutzer stellt der Sotograph im Rahmen des MetricScope verschiedene Funktionalitäten zur Einschränkung der Ergebnismenge zur Verfügung: Aggregierte Ausgabe der Ergebnisse: Die Ergebnisse der Metriken werden auf der o- bersten Abstraktionsebene ausgegeben, die betrachtet wird. Dadurch kann der Benutzer in einem ersten Schritt die betroffenen Bereiche lokalisieren. Abbildung 4 zeigt das Ergebnis der Metrik SysArchViol, die alle im System vorhandenen Architekturverletzungen auf Grundlage der betroffenen Subsysteme zusammengefasst auflistet. Zu erkennen ist, dass es im Gesamtsystem in der Summe (letzte Spalte) 51 Architekturverletzungen 16

17 Kapitel 3: Werkzeuggestützte Architekturanalyse mit Sotograph gibt, die durch Zugriffe der drei Subsysteme (transaction, jdbc, remoting) auf andere Subsysteme verursacht werden. Abbildung 4: Subsysteme mit Architekturverletzungen (SysArchViol) Zur detaillierten Analyse der Entstehung von Architekturverletzungen kann eine der Ergebniszeilen ausgewählt und die entsprechende Liste aller unzulässigen Referenzen, die in diesem Subsystem vorhanden sind, unter Angabe des jeweiligen Referenztyps (Abbildung 5) angezeigt werden. Abbildung 5: Architekturverletzende Referenzen eines Subsystems Dadurch ist es dem Benutzer möglich, das Zustandekommen der aggregierten Analyseergebnisse durch Angabe der entsprechenden Quellcodestelle - welche die Architekturverletzung hervorruft - erklären zu lassen. Der Befehl, welcher die Architekturverletzung hervorruft, lässt sich im Quellcodeeditor des Sotographen anzeigen. Vordefinition von Grenzwerten: Im Sotographen gibt es als Spezialfall der Metrik Regeln, mit denen es möglich ist, explizite numerische Grenzwerte zu definieren. Infolgedessen ist es dem Benutzer möglich, nur die Ergebnisse zu betrachten, die außerhalb dieser Grenzwerte liegen, wodurch die Ergebnismenge eingeschränkt wird. Die vorgegebenen Grenzwerte können individuell angepasst werden. Typisierung der Metriken: Metriken sind einem Typ (Architecture Metrics, Cycle Metrics, Duplicated Code Metrics, Measures, Rules) zugeordnet, wodurch der Benutzer die Metrikauswahl auf eine bestimmte Art der Analyse beschränken kann. Ein Software-Architekt wird beispielsweise vermehrt an der Einhaltung seiner Architektur interessiert sein, wohingegen einen Entwickler interessieren könnte, ob seine Implementierungen korrekt über die Schnittstellen auf eine Subsystem-Funktionalität zugreifen. Ausblenden von Teilsystemen: Teilsysteme (z.b. ein Subsystem oder ein Package), die bereits als grundlegend problematisch erkannt wurden oder im Zuge der Architektur- 17

18 Kapitel 3: Werkzeuggestützte Architekturanalyse mit Sotograph analyse nicht betrachtet werden sollen, lassen sich mittels der Definition regulärer Ausdrücke aus den Ergebnislisten filtern. Diese Filter können einerseits kurzfristig (für eine Analyse) angewendet oder zum Erhalt der Filterinformationen - auch über einen Neustart des Sotographen hinaus - in der Datenbank gespeichert werden. Zum Auffinden der zuvor beschriebenen Architektur-Smells werden durch den Sotographen Metriken zur hierzu notwendigen Informationsgenerierung bereitgestellt: Zur Prüfung der Verwendung der definierten Schnittstelle beim Zugriff auf ein Subsystem gibt die Metrik SubsysIFViol eine Liste von Subsystemen an. Eine hohe Anzahl von Umgehungen der Schnittestelle eines Subsystems deutet darauf hin, dass diese Schnittstelle zu eng definiert ist und zu wenig Funktionalität nach außen bereitstellt. Abbildung 6: Auszug aus der Ergebnisliste SysViol Soll im Zuge des Refactorings eines Software-Systems die Schnittstelle eines Subsystems zur Vermeidung dieser Umgehung erweitert werden, können mit Hilfe der Metrik SubsysInboundIFViolSubsys alle Subsysteme ermittelt werden, deren Schnittstelle umgangen wird und folglich der durch das Refactoring entstehende Aufwand abgeschätzt werden kann. Zusammengefasst lassen sich alle in Abschnitt angesprochenen Architektur-Smells durch die Metrik SysViol ermitteln, welche diese unter Angabe des Typs der Architekturverletzung auflistet (Abbildung 6). Die in Abschnitt angesprochene Problematik der Typabfragen lässt sich mit Hilfe der Metrik FileInstanceOf aufdecken. Diese gibt auf Basis eines entsprechenden regulären Ausdrucks alle Dateien an, in denen der instanceof-befehl zur Abfrage des Datentyps verwendet wird. Werden die Ergebnisse dieser Metrik in einen Graphen, der die Vererbungsbeziehungen zwischen Klassen darlegt, integriert, lassen sich die zu überarbeitenden Vererbungsstrukturen ermitteln. Um unbenutzte Artefakte aufdecken zu können, gibt es auf den entsprechenden Abstraktionsebenen unterschiedliche Metriken: Eine Liste der nicht verwendeten Methoden wird durch die Metrik ClassMethodsNotUsed erzeugt. Eine Abstraktionsebene höher werden mit Hilfe der Metrik PckgClassNotUsed die Klassen aufgelistet, die im System weder durch einen Methodenaufruf noch eine Attributverwendung genutzt werden. 18

19 Kapitel 3: Werkzeuggestützte Architekturanalyse mit Sotograph Zyklenbasierte Architekturanalyse Abbildung 7: Subsystem-Graph mit eingezeichneten Referenzen Eine zyklische Kopplung zwischen Artefakten auf den verschiedenen Abstraktionsebenen liegt vor, wenn Artefakte sich gegenseitig benutzen. Abbildung 7 veranschaulicht die Zugriffe zwischen den Subsystemen des Java-Frameworks Spring, wobei die Dicke der Verbindungen zwischen den Subsystemen die Anzahl der Referenzen zwischen diesen Subsystemen anzeigt. Durch eine kombinierte Analyse farblich hervorgehoben sind die drei Subsysteme, von denen Architekturverletzungen (Metrik: SysViol) ausgehen, sowie die zwei Paare von Subsystemen, zwischen denen Zyklen bestehen (Metrik: SubsysCyclicRefSubsys). Eine Problematik der Analyse von Zyklen eines Software-Systems ist die hohe Menge der gefundenen Zyklen; insbesondere wenn man gleichzeitig Zyklen unterschiedlicher Längen - d.h. Zyklen, in die unterschiedlich viele Elemente gekoppelt sind - betrachtet. Mit dem Sotographen ist eine schrittweise Analyse der Zyklen in der Form möglich, dass zunächst nur Zyklen zwischen zwei Artefakten betrachtet werden, diese im nächsten Schritt aus der Menge der Analyseergebnisse eliminiert und dann längere Zyklen betrachtet werden. Somit ist es möglich, sukzessive Zyklen mit mehr Artefakten analysieren zu können. [BW04, S. 249] Ein Zyklus zwischen verschiedenen Artefakten eines Systems muss nicht in allen Fällen negative Auswirkungen haben. Bei dem Verhaltensentwurfsmuster Iterator, mit Hilfe 19

20 Kapitel 3: Werkzeuggestützte Architekturanalyse mit Sotograph dessen auf Datenstrukturen zugegriffen werden kann, ohne dass deren innere Struktur bekannt ist, wird bewusst ein Zyklus zwischen zwei Klassen erzeugt. [GHJV94] In den meisten anderen Fällen ist eine zyklische Verbindung ein Indiz für eine zu enge Kopplung verschiedener Komponenten, die es aufzulösen gilt Trendanalyse der Architektur Die Erstanalyse eines Systems ist mit hohem Aufwand verbunden und würde sowohl für Entwickler als auch für Projektleiter im laufenden Entwicklungsprozess bei regelmäßiger Anwendung zuviel Zeit in Anspruch nehmen. Zur Betrachtung der Entwicklung eines Software-Systems im zeitlichen Verlauf bietet der Sotograph die Möglichkeit, verschiedene Versionsstände zu vergleichen und ggf. nur die Veränderungen zum vorherigen Stand zu betrachten. Dadurch wird es möglich, einer architekturellen Degeneration im Evolutionsprozess der Software entgegen zu wirken. Zur Durchführung einer Trendanalyse müssen im Sotographen folgende Vorarbeiten getroffen werden: 1. Quellcodeinformationen extrahieren: Für jede betrachtete Version muss der in Abschnitt 2.1 beschriebene Extraktionsprozess vollzogen werden. Dabei wird für jeden Versionsstand eine eigene Datenbank im Sotographen angelegt. 2. Migration des Architekturmodells: Zur Durchführung von Vergleichen über hinzu gefügte Artefakte ist es notwendig, das Architekturmodell, welches für die erste Version erstellt wurde, auf die anderen betrachteten Versionen zu migrieren und dort sukzessiv entsprechend den Veränderungen anzupassen. 3. Definition der Versionsfolge: Die Zusammengehörigkeit sowie die zeitliche Abfolge der Versionen müssen im Sotographen definiert werden. Einen ersten Überblick über die Veränderungen zwischen den Versionen bietet der Trend System Metrics Overview, in welchem eine Reihe von Metriken zusammengefasst ist. Hieraus lassen sich erste Informationen über die Entwicklung der Größe des Gesamtsystems auf Basis der Anzahl der Klassen (SysClasses) sowie die Entwicklung der Architekturverletzungen (SysArchViol) ablesen. Detaillierte Analysen lassen sich mit Hilfe des TrendMetricScope durchführen, in dem alle Metriken des Sotographen auf mehrere Versionsstände vergleichend angewendet werden können. Durch Filter ist es möglich, die Verbesserungen und Verschlechterungen einzelner Metrikwerte hervorzuheben. 20

21 Kapitel 4: Zusammenfassung und Ausblick Abbildung 8: Grafische Darstellung der Metrik SysViol im Trend über drei Versionen Abbildung 8 stellt die grafische Auswertung der Entwicklung der systemweit gefundenen Architekturverletzungen inklusive der Umgehung von Subsystem-Schnittstellen dar. Diese wurden mit Hilfe der Metrik SysViol für die letzten drei Versionen eines Software-Systems ermittelt. Es ist zu erkennen, dass die Anzahl der Architekturverletzungen von Version m1 auf Version m3 um circa 7% angestiegen ist. 4 Zusammenfassung und Ausblick Der Sotograph stellt für die Architekturanalyse sehr mächtige Werkzeuge zur Verfügung, von denen im Rahmen dieser Ausarbeitung nur die Wesentlichen vorgestellt werden können. Mit deren Hilfe lässt sich eine detaillierte Qualitätsanalyse eines Software- Systems durchführen. Besonders hervorzuheben sind dabei die ausgereiften Möglichkeiten der integrierten Visualisierung der Analyseergebnisse sowie des strukturellen Aufbaus der Software, durch die der Benutzer Problembereiche schneller als auf manuelle Art lokalisieren kann. Hinzu kommt die durchgehende Konzeption der verschiedenen Abstraktionsebenen, die nach einer einmaligen Definition dauerhaft in allen Teilwerkzeugen verfügbar sind. Die Aggregation der Ergebnisse entlang der Abstraktionsebenen strukturiert die Interpretation der Analyseergebnisse, ohne sie dabei einzuschränken, und ermöglicht dem Benutzer somit eine konsequente Bearbeitung der Problembereiche. Für die Effizienz und die Genauigkeit der Analyse spielt diese Möglichkeit eine zentrale Rolle. Als nachteilig ist neben den hohen Anschaffungskosten für den Sotographen die lange Einarbeitungszeit aufgrund des Funktionsumfangs anzusehen, die für eine praktische Anwendung nach einer einmaligen Erstanalyse durch die Möglichkeit der Betrachtung 21

22 Kapitel 4: Zusammenfassung und Ausblick von Veränderungen im zeitlichen Verlauf - insbesondere bei Großprojekten - relativiert wird. Für die Realisierung kleinerer Software-Produkte ist der Sotograph überdimensioniert, da viele Teilaspekte wie die Visualisierung von zyklischen Beziehungen zwischen Artefakten durch frei verfügbare Software - etwa das Opensource-Programm ClassCycle - ebenso wie Ansätze einer metrikbasierten Analyse mittels des Eclipse- Metics Plugins realisiert werden können. Zur Durchführung einer integrierten Gesamtanalyse hat der Sotograph besonders in Großprojekten den entscheidenden Vorteil, dass die Analysewerkzeuge stark integriert und einmal definierte Konstrukte - etwa die Subsystem- und Architekturmodelle oder Grenzwerte für Metriken in der Gesamtanalyse - verfügbar sind. Speziell die Verwendung der Trendanalyse ist für einen Einsatz in der Praxis sinnvoll: Hier können sowohl Entwickler, Software-Architekten wie auch Projektleiter ihren individuellen Informationsbedarf decken, indem die Veränderungen in Bezug auf die Software-Qualität in dem für sie jeweils relevanten Bereich und auf dem für sie notwendigen Abstraktionsniveau angegeben werden. In zukünftigen Versionen des Sotographen wird das Spektrum der unterstützten objektorientierten Sprachen der von Microsoft entwickelten Sprache C# auf den NET-Bereich ausgeweitet. Dennoch ist ein für den praktischen Einsatz nicht zu unterschätzender Nachteil des Sotographen die fehlende Möglichkeit der Transformation bestehender UML-Modelle in die Subsystem-/Architekturmodelle des Sotographen. Sind im Rahmen eines Software-Entwicklungsprozesses UML-Modelle auf hohen Abstraktionsebenen (Schichten und Subsysteme) durchgängig, d.h. mit Zuordnung der jeweiligen Packages und Klassen vorhanden, entsteht durch das Fehlen der Transformationsmöglichkeit ein Medienbruch und ergibt sich zudem ein höheres Fehlerpotenzial durch die Notwendigkeit der doppelten Erstellung und Anpassung der unterschiedlichen Modelle. 22

23 Anhang A: Software-Qualität Anhang A Software-Qualität 23

24 Anhang B: Architekturmodell Anhang B Architekturmodell public IArchitectureModel generatearchitecturemodel(imodelfactory f, String name){ //Einlesen des verwendeten Subsystemmodells ISubsystemModel sm= f.getsubsystemmodel("default"); //Erzeugen eines neuen Architekturmodells ILayeredArchitectureModel am = f.createlayeredarchitecturemodel( f.getcurrentmodelscriptname(), sm); IArchitectureLayer al; //Erzeugen einer neuer Architekturschicht "Frontend" //Intra-Schicht-Referenzen sind erlaubt //Frontend darf nur auf die direkt darunter liegende Schicht zugreifen (linear) al= am.createarchitecturelayer("frontend", am.callowintralayerreferences, 1); //Hinzufügen der entsprechenden Subsysteme zu Frontend al.addsubsystem("hotelverwaltung.gui"); //Erzeugen einer neuer Architekturschicht "Logik" al= am.createarchitecturelayer("logik", am.callowintralayerreferences, am.caccessalllowerlayers); al.addsubsystem("hotelverwaltung"); //Erzeugen einer neuer Architekturschicht "Backend" al= am.createarchitecturelayer("backend", am.callowintralayerreferences, am.caccessalllowerlayers); al.addsubsystem("hotelverwaltung.beans"); al.addsubsystem("hotelverwaltung.jdbc"); return am; } 24

25 5 Literaturverzeichnis [Ba00] Helmut Balzert: Lehrbuch der Software-Technik, Bd.1 Software- Entwicklung, 2.Auflage, Spektrum Akademischer Verlag, [Ba98] Helmut Balzert: Lehrbuch der Software-Technik, Software-Management Software-Qualitätssicherung Unternehmensmodellierung, Spektrum Akademischer Verlag, [BCK03] Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, 2. Auflage, Addison-Wesley Pearson Education, [BBS03] Marcel Bennicke, Walter Bischofberger, Frank Simon: Eclipse auf dem Prüfstand: Eine Fallstudie zur statischen Programmanalyse, Objektspektrum 9(5), S , SIGS-DATACOM GmbH, [BKL04] Walter Bischofberger, Jan Kühl, Silvio Löffler: Sotograph: A pragmatic approach to source code architecture conformance checking, Lectures Notes in Computer Science (3047), S. 1-9, Springer, [Bo00] [BW04] Jan Bosch: Design and Use of Software Architectures. Adopting and evolving a product-line approach, Addison-Wesley Professional, Walter Bischofberger, Henning Wolf: Werkzeugbasiertes Erkennen und Vermeiden von Architektur-Smells. In: Refactoring in großen Softwareprojekten, Hrsg.: Martin Lippert, Stefan Roock, dpunkt.verlag, [GHJV94] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns, Elements of Reusable Object-Oriented Softwarem, Addison-Wesley, [Ke05] [LR04] [SC06] [SH06] [Si04] [SM06a] [SM06b] Christoph Kecher: UML 2.0. Das umfassende Handbuch, Galileo Computing, Martin Lippert, Stefan Roock: Refactoring in großen Softwareprojekten. Komplexe Restrukturierungen erfolgreich durchführen, dpunkt.verlag, Sotograph 2.4 Code Comprehension Tutorial. Sotograph Hands-On Overview. Johannes Siedersleben: Moderne Software-Architektur: Umsichtig planen, robust bauen mit Quasar, dpunkt.verlag, Sotograph 2.4 Metrics Tutorial. Sotograph 2.4 Modeling Tutorial. [ST06] Software-Tomography GmbH: Abrufdatum: