Architekturbewertung

Copyright and all intellectual property belongs to Brockhaus Group 1
Architekturbewertung
- einer Java Legacy Applikation
Auszug aus der Ergebnisdokumentation

Inhaltsverzeichnis
Einleitung...............................................................................................................4
Überblick über das Projekt..........................................................................................4
Was dieses Dokument leistet (und nicht leistet)..............................................................5
Softwarearchitektur im Kontext..............................................................................6
Begriff der Softwarearchitektur....................................................................................6
Referenzarchitekturen................................................................................................7
Softwarearchitektur in zeitlicher Betrachtung.................................................................9
Bewertung von Softwarearchitekturen..................................................................11
Indikatoren für Architekturprobleme, die Architectural Smells.........................................11
Vorgehen bei der Bewertung......................................................................................12
Kriterien bei der Bewertung.......................................................................................13
Einflussgrößen - die Metrik........................................................................................14
Dokumentation................................................................................................14
Entwurfsprinzipien und Pattern...........................................................................14
Verwendung von Richtlinien und Standards..........................................................15
Technisch-konzeptionelle Aspekte.......................................................................15
Bewertungsmatrix....................................................................................................16
Appendix A: Erläuterung der Merkmale für Softwarequalität nach ISO 9126.........17
Appendix B: Entwurfsprinzipien1..........................................................................19
Literatur...............................................................................................................21

Grafiken
Illustration 1: Umfeld von Referenzarchitekturen............................................................7
Illustration 2: Entstehen von Referenzarchitekturen........................................................7
Illustration 3: Referenzarchitektur von Mocrosoft............................................................8
Illustration 4: SOA Referenzarchitektur der OMG............................................................8
Illustration 5: Änderbarkeit von Software im Zeitablauf...................................................9
Illustration 6: Relation von Kosten und Verständlichkeit von Software..............................10
Illustration 7: Kriterien zur Softwarequalität nach ISO 9126...........................................13

Einleitung
There are two ways of constructing a software design: One way is to make it so simple that
there are obviously no deficiencies, and the other way is to make it so complicated that
there are no obvious deficiencies. The first method is far more difficult.
-- C.A.R Hoare
Überblick über das Projekt
Das Produkt wird seit mehr als 15 Jahren beim Endkunden konzeptioniert und von
verschiedenen Dienstleistern implementiert. Seit dem Januar 2014 werden Support und
Weiterentwicklungen seitens des Consultingunternehmens umgesetzt. Im Wesentlichen
erstrecken sich die Aufgaben des Consultingsunternehmens auf zwei Bereiche, den Support
des Tools und die Weiterentwicklung. Gehostet wird die Applikation im Rechenzentrum des
Endkunden. Der Support - intern als Service benannt - umfasst 2nd
und 3rd
Level Support für
die internen Module sowie kleine Bugfixes und Erweiterungen mit einem Umfang von weniger
als 10 PT.
Die Weiterentwicklung - intern Projekte genannt - umfasst Change Requests. Hier existieren
bereits eine ganze Reihe dieser Projekte. Alle diese Projekte setzen auf dem aktuellen
Softwarestand auf, erweitern die Funktionalität zum Teil erheblich. Einige dieser Projekte
weisen bereits einen signifikanten Zeitverzug auf, der Service arbeitet nicht kostendeckend,
die Weiterentwicklungen sind aufgrund unüberschaubarer Interdependenzen der Module,
eines veralteten Build-Systems und einer Vielzahl technisch redundanter Frameworks extrem
teuer.

Was dieses Dokument leistet (und nicht leistet)
Qualität: die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer
Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse beziehen
-- ISO 9000
Gernot Starke und Stefan Tilkov1
formulieren drei prägnante Fragen zum Kontext
Softwarearchitektur:
 Wissen alle Stakeholder, wo die Probleme in der Architektur liegen?
 Sind sich alle über die Konsequenzen einig?
 Gibt es klare Strategien zur Verbesserung?
Diese Fragen - die aller Voraussicht nach in jedem Projekt mit ‘nein’ beantwortet werden -
motivieren generell einen Architekturreview (wahrscheinlich sind deshalb ja auch suggestiv
gestellt).
Die Erwartungshaltung der maßgeblichen Stakeholder scheint hoch, es wird eine stringent
ausformulierte, realisierbare Handlungsempfehlung erwartet. Diese Handlungsempfehlung
soll eine Analyse des bestehenden Systems respektive der Beurteilung der vorgefundenen
Architektur beinhalten, die Definition einer Zielarchitektur und schlussendlich ein möglicher
Weg dorthin. Um es prägnant auszudrücken: das kann im Rahmen dieser Analyse nicht
geleistet werden.
Die Analyse kann und wird das System anhand bestimmter Kriterien durchleuchten,
versuchen positive und negative Aspekte zu finden und auf die Konsequenzen dieser Aspekte
hinweisen. Auch können Hinweise gegeben werden, wie moderne Architekturen oder eine
mögliche Zielarchitektur aussehen; die Beschreibung der Transition - und sei es nur in
Teilbereichen - kann nur Gegenstand nachgelagerter, detaillierter Feinanalysen sein.
1[Starke2014]

Softwarearchitektur im Kontext
Der folgende Abschnitt beschreibt grundsätzliche Begriffe und Aspekte im Kontext
Softwarearchitektur; er dient der Einführung und der Erläuterung wichtiger Begrifflichkeiten.
Begriff der Softwarearchitektur
The fundamental organisation of a system embodied in
its components, their relationships to each other and to
the environment and the principles guiding its design
and evolution.
[IEEE1471]
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 relationships
among them.
[Bass2003], Chapter 1
Die einheitliche Definition des Begriffs der Softwarearchitektur gibt es nicht, auf der Webseite
des Software Engineering Institute der Carnegie Mellon University werden über 50
Definitionen genannt1
.
Gängige Definitionen beschreiben die Architektur eines Softwaresystems als die Strukturen
eines Softwaresystems - beispielsweise die Komponenten/ Module - deren Schnittstellen und
deren Beziehungen; Architektur beschreibt sowohl statische Aspekte (im Sinne eines
Bauplans) als auch dynamische Aspekte (im Sinne eines Ablaufplans). Auch wenn nicht
explizit ausformuliert oder dokumentiert, so hat doch jedes System eine Softwarearchitektur
(ggf. nicht die gewünschte Softwarearchitektur oder eine Softwarearchitektur minderer
Qualität).
Aus den Definitionen wird ersichtlich, dass der Softwarearchitektur erhebliche Bedeutung für
die Qualität und die Lebensdauer der Software zukommt; je größer das System ist, desto
entscheidender ist der Beitrag der Softwarearchitektur für den Erfolg.
Weiterhin sollte ersichtlich sein, dass die geeignete Softwarearchitektur wesentlich mehr ist
als die Auswahl eines geeigneten Frameworks oder das Aufsetzen eines geeigneten
Softwareentwicklungsprozesses. Die Auswahl einer Technologie - als Beispiel seien JSPs
genannt - stellt keinesfalls den Erfolg der Software sicher; werden in den JSPs einer großen
Applikation Elemente der Geschäftslogik oder der Persistenz implementiert, dann ist der
Grundstein zu im Zeitablauf immer schwieriger wartbarer oder immer schwieriger zu
erweiternder Software gelegt. Umgekehrt sind JSPs - sofern als reine Viewtechnologie
genutzt - erfolgreich in einer Vielzahl von Projekten zum Einsatz gekommen. Auch die
Erfahrungen aus der Anwendung von EJBs in den frühen Jahren zeigen, dass man eine
Technologie auf unterschiedliche Art und Weise nutzen kann. Die Art und Weise der Nutzung
- niedergelegt in Softwarearchitekturbeschreibungen - hatte maßgeblichen Einfluß auf den
Erfolg des Gesamtprojektes.
Es gilt - unter Berücksichtigung technologischer Restriktionen - die geeignete Architektur zu
entwickeln, zu validieren, zu kommunizieren und permanent zu überprüfen. Der
Entwicklungsprozess hin zu einer adäquaten Architektur soll hier nicht betrachtet werden,
hier wird beispielsweise auf [Starke2011], [Bass2003], [Microsoft2009] verwiesen.
1http://www.sei.cmu.edu/architecture/start/glossary/community.cfm

Referenzarchitekturen
“It seems that perfection is reached not when there is nothing left to add, but when there is
nothing left to take away”
Antoine de Saint Exupery
In all domains we see two simultaneous trends:
 Increasing complexity,
scope and size of the
system of interest, its
context and the
organizations creating the
system
 Increasing dynamics and
integration: shorter time to
market, more
interoperability, rapid
changes and adaptations in
the field.
A Reference Architecture provides a
proven template solution for an
architecture for a particular domain. It also provides a common vocabulary with which to
discuss implementations, often with the aim to stress commonality.
[Muller2007]
Zusammengefasst lässt sich zu einer Referenzarchitektur festhalten, dass sie:
1. auf bewährten Konzepten basiert und
2. mehr als Technologie und Pattern ist.
Ziele einer Referenzarchitektur sind:
• die Steigerung der Produktivität über die Vereinheitlichung der Problemlösung,
• die Verkürzung der Auslieferungszeiten durch die Produktivitätssteigerung verbunden
mit der Notwendigkeit nur Code zu implementieren der einen direkten Bezug zu den
Anforderungen hat und
• die Steigerung der Qualität und Verminderung des Risikos durch die Nutzung
wiederverwendbarer, getesteter Komponenten.
Häufig werden existierende
Architekturen nach diesen
bewährten Konzepten
durchsucht. Für die
Renovierung von Architekturen
und die Validierung von
Innovationen kann auf
Referenzarchitekturen
zurückgegriffen werden.
Referenzarchitekturen lassen
sich in mannigfaltigen
Ausprägungen finden, es gibt
eine SOA Referenzarchitektur
der OMG, die Proactive
Infrastructure (PAI) bei
Mercedes, …
Illustration 1: Umfeld von Referenzarchitekturen
Illustration 2: Entstehen von Referenzarchitekturen

Die nebenstehende Grafik bildet
exemplarisch eine Referenzarchitektur ab,
hier die von Microsoft empfohlene
“common application architecture with
components grouped by different areas of
concern.”
Als eine weitere Referenzarchitektur soll
die von der OMG publizierte SOA Reference
Architecture angeführt werden1
.
Gemeinsam ist beiden
Referenzarchitekturen die horizontale
Teilung in verschiedene Layer und die
Fokussierung auf Services. Microsoft
verortet den Business Workflow innerhalb
des Business Layers, eine Auffassung, die
unterstellt, dass dieser Workflow wohl nicht
mit den Service Interfaces interagiert. Aus
dieser Annahme heraus wird für die
Analyse die SOA Referenzarchitektur
herangezogen innerhalb derer zwischen
Business Processes und und der Service
Implementierung immer die Services genutzt werden, das User Interface jedoch nicht
notwendigerweise Business Processes nutzen muss.
Illustration 4: SOA Referenzarchitektur der OMG
1[OMG2011]
Illustration 3: Referenzarchitektur von Mocrosoft

Softwarearchitektur in zeitlicher Betrachtung
"Shipping first time code is like going into debt. A little debt speeds development so long as
it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid.
Every minute spent on not-quite-right code counts as interest on that debt. Entire
engineering organizations can be brought to a stand-still under the debt load of an
unconsolidated implementation, object-oriented or otherwise."
-- Ward Cunningham
Lindvall1
prägte den Begriff der ‘degeneration
of architecture’ welche eintritt, wenn die
über den Zeitablauf auftretenden
Änderungen Einfluß auf die Architektur des
Systems nehmen. Diese “Degeneration”
macht Änderungen schwieriger und
kostenintensiver und Degeneration kann
letztendlich dazu führen, dass ein
vollständiges Redesign notwendig wird.
Empirisch wurde nachgewiesen2
, dass sich ohne geeignete Gegenmassnahmen die
Möglichkeit, auf Änderungen in den Requirements software- und entwicklungsseitig zu
reagieren, im Zeitablauf verringert. Dieses wurde bereits in den 80-er Jahren von Lehman
erforscht und beschrieben und in dem nach ihm benannten Gesetz formuliert:
“As an evolving program is continually changed, its complexity, reflecting deteriorating
structure, increases unless work is done to maintain or reduce it.”
Ward Cunningham griff die These auf und schreibt die Degeneration u.a. dem Aufbauen von
sog. technischen Schulden (Technical Debt) zu. Hierbei wird ausgeführt, dass die
Hintanstellung von Maßnahmen zur Sicherung und Erhöhung technischer Qualität die
Softwareentwicklung nicht beschleunigt, sondern vielmehr verlangsamt – je länger die
Massnahmen ausbleiben desto langsamer wird die Entwicklung.
Beispiele für technische Schulden sind:
1. Hintanstellen technischer und fachlicher Softwaredokumentation
2. Fehlende technische Infrastruktur wie Versionsverwaltung, Datensicherung,
Build-Tools, Kontinuierliche Integration
3. Hintanstellen, Verzicht oder ungenügende Umsetzung automatisierter Modultests
und Regressionstests
4. Hintanstellen der Korrektur von zu großem oder zu komplexen Code und Design
5. Fehlerhafte Definition oder Umsetzung der Architektur durch enge Kopplung,
zyklische Abhängigkeiten der Komponenten oder das Fehlen geeigneter
Schnittstellen und Fassaden
1[Lindvall2005]
2[Lindvall2005]
Illustration 5: Änderbarkeit von Software im Zeitablauf

Die Gründe für das Aufbauen technischer Schulden sind vielfältig, exemplarisch nennt
Krafzig1
:
1. Schlüsselexperten und das Projektmanagement sind nicht mehr in dem Projekt,
das Know-How für Weiterentwicklungen hat sich verringert.
2. Übergabe an Wartungsteam mit ggf. geringerem Skill Level
3. Motivationsdefizite aufgrund des Verlustes des Supports seitens des
Managements.
4. Kostendruck kann die Wartung generell negativ beeinflussen und führt u.U. zu
“ad hoc” Änderungen ohne Analyse der Auswirkungen auf die
Softwarearchitektur.
Dass ein Redesign durchaus praktikabel und
vorteilhaft sein kann wurde mehrfach gezeigt.
Als typisches Beispiel soll hier RedHat’s JBoss
angeführt werden. Der Applikationsserver wurde
nach mehreren Releases mit kleineren
Änderungen im administrativen Bereich oder im
Bereich des Messaging aber mit zunehmender
Komplexität des Produktes in seiner Version 7
vollständig überarbeitet und ist nunmehr einer
der performantesten Applikationsserver auf dem
Markt.
Ein ähnliches Beispiel ist das populäre
Hibernate-Framework welches von Release 3.x zu
Release 4.x vollständig überarbeitet wurde, auch
um neuen Anforderungen aus der JPA Spezifikation zu implementieren.
Auch ist die geschilderte Konsequenz der Degeneration nicht unvermeidbar, die Vermeidung
bedingt aber kontinuierliche Architektur-Evaluationen und ggf. die Modernisierung von
Teilbereichen des Systems - auch wenn diese Massnahmen aus Kostengründen zunächst
unpopulär erscheinen da kein damit einhergehender funktionaler Zuwachs die Kosten
gegenüber dem Kunden rechtfertigt.
1[Krafzig2003]
Illustration 6: Relation von Kosten und
Verständlichkeit von Software

Bewertung von
Softwarearchitekturen
Without undertaking a formal analysis process, the
organization cannot ensure that the architectural decisions
made—particularly those which affect the achievement of
quality attribute such as performance, availability, security,
and modifiability—are advisable ones that appropriately
mitigate risks.
[Kazmann2000]
Typische Formulierungen von Stakeholdern sind:
• Das System soll robust sein.
• Das System soll hochgradig veränderbar sein.
• Die Architektur soll korrekt sein.
• Die Architektur soll „state of the art“ sein.
Solche unspezifischen Anforderungen lassen sich überhaupt nicht erfüllen, denn die
Qualitätsattribute sind keine absoluten Größen, sie existieren nur innerhalb eines
spezifischen Kontexts und können daher auch nur in diesem spezifischen Kontext gemessen
und interpretiert werden.
Indikatoren für Architekturprobleme, die
Architectural Smells
All parts of the architectural design were easy to understand. The architecture was
expressed in a kind of idiomatic way, where the same principles have been applied to
different parts. The partitioning of the overall operating system in different layers and
components with clear responsibilities helped me grasping the details easily.
On the other hand, I have also experienced bad architectures with over-generic designs,
where it took me weeks to get the slightest clue what they were trying to implement.
--- Michael Stal
Defizite in der Architektur lassen sich oftmals an bestimmten Anzeichen festmachen, den
sog. Architectural Smells1
. Beispielhaft seien die folgenden erwähnt:
• Zyklen in Abhängigkeiten
• Unklare Komponentennamen
• Überladen der Komponenten mit Verantwortlichkeiten
• Unnötige Indirection Layers oder Abstraction Layers
• Zu generisches Design
Treten diese Indikatoren auf, dann ist eine detaillierte Analyse oftmals indiziert.
1Vergl. [Stal2011]

Vorgehen bei der Bewertung
Bei der Bewertung von Softwarearchitekturen werden häufig szenariobasierte Ansätze
gewählt. Auf Szenarien basierende Ansätze sind immer dann geeignet, wenn die Qualität
einer Architektur bereits vor der Implementierung zu bewerten ist. Exemplarisch sei hier das
ATAM1
Verfahren genannt, dessen diverse Prozessschritte daraus ausgerichtet sind, Business
Driver und Szenarien zu bestimmen und diese an einer Architektur zu spiegeln. Unter einem
Szenario wird hierbei eine Beschreibung verstanden, welche das Verhalten eines Systems
während einer Interaktion durch einen Benutzer mittels einer kurzen Beschreibung definiert.
Inwiefern die Architektur diese Szenarien unterstützt wird anhand von Metriken gemessen
(wobei allerdings nur qualitative und keine quantitativen Ergebnisse entstehen können).
Aufgrund der Komplexität des Systems und des Zeitrahmens der Bewertung sowie der
lückenhaften oder fehlenden Dokumentation kann bei der vorliegenden Bewertung nicht von
einem szenariobasierten Ansatz ausgegangen werden.
Allen Formen der Bewertung basieren darauf, dass der zu bewertende Gegenstand Kriterien
und Vorgehensweisen unterliegen2
. Wesentliche Bestandteile einer Bewertung sind:
• Bewertungsgegenstand – das zu betrachtende Objekt
• Kriterien – die Charakteristika des Bewertungsgegenstands, die zu beurteilen
sind.
• Metrik oder Standard – eine Idealvorstellung, der gegenüber der
Bewertungsgegenstand verglichen wird
• Datenerhebung – eine Methodik quantifizierbare Daten für die einzelnen Kriterien
zu sammeln
• Synthesetechnik – eine Methodik die einzelnen Daten zu einem Gesamtbild
zusammenzufassen.
• Bewertungsprozess – eine Serie von Aktivitäten, durch die die Bewertung
operationalisiert wird.
Alle obigen Bestandteile müssen explizit definiert sein. Die Definition des
Bewertungsgegenstandes - hier der Softwarearchitektur - ist nicht ganz so einfach, wie man
zunächst vermutet, denn die reine Softwarearchitektur eines Systems lässt sich nur indirekt
als ein “Gegenstand” wahrnehmen, schließlich ist jede Architektur eine Form der Abstraktion
des Systems. Außerdem sollte man berücksichtigen, dass oft die Ursache für ein bestimmtes
Erscheinungsbild der Architektur nicht in der Architektur oder dem System selbst liegt,
sondern seinen tieferen Grund im Entwicklungsprozess des Systems hat. Daher sollte man
für den Fall, dass zukünftige Fehler vermieden werden sollen, die Architektur nie unabhängig
von ihrem Entstehungsprozess oder ihrer jeweiligen Entwicklungsorganisation bzw.
Entwicklungshistorie sehen.
1Architectual Trade-off Analysis Method
2Für dieses und das Folgende vergl.: [Masak2010]

Kriterien bei der Bewertung
Im Gegensatz zur Messung von Quellcode anhand bestimmter Metriken liefert die Bewertung
von Software-Architekturen keine Zahlen, sondern qualitative Aussagen: Sie bewerten
Architekturen danach, inwieweit sie die Erreichung bestimmter Qualitätsmerkmale
ermöglichen1
.
Hinsichtlich einer Softwarearchitektur wird von Starke ausgeführt, dass diese geeignet ist,
wenn sie folgende Kriterien erfüllt2
:
• Das System erfüllt sowohl seine funktionalen als auch nichtfunktionalen
Anforderungen (Qualitätskriterien).
• Das System erfüllt die spezifischen Anforderungen an Flexibilität und Änderbarkeit.
• Das System kann mit den zur Verfügung stehenden Ressourcen realisiert werden.
Sowohl das Budget wie auch der Zeitplan, das Team, die beteiligten Fremd- und
Legacy-Systeme, die vorhandene Basistechnologie und Infrastruktur sowie die
gesamte Organisationsstruktur beeinflussen die Umsetzbarkeit einer Architektur.
Da davon ausgegangen wird, dass fuktionale und nicht-funktionale Anforderungen an das
System nicht Gegenstand dieser Analyse sind, rücken damit die Aspekte der Flexibilität und
Änderbarkeit sowie die Umsetzbarkeit mit den zur Verfügung stehenden Ressourcen in den
Vordergrund.
Etwas feingranularer werden die Merkmale einer Software in der ISO 91263
dargestellt4
:
Illustration 7: Kriterien zur Softwarequalität nach ISO 9126
Auch hier wird für die weitere Analyse wird davon ausgegangen, dass Kriterien wie
Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz und Portabilität nicht im Fokus der
Analyse sind. Es soll untersucht werden, inwiefern die Architektur das Beheben von Fehlern
und die funktionalen Erweiterungen am System unterstützt, somit steht der Aspekt der
Wartbarkeit - innerhalb der ISO als Merkmal bezeichnet - mit den zugehörigen
Unteraspekten / - merkmalen im Mittelpunkt. Wie bereits ausgeführt werden diese Merkmale
um das Merkmal der Umsetzbarkeit erweitert; dieses beschreibt die Möglichkeiten, ein
Softwaresystem mit verfügbaren Ressourcen zu realisieren.
Untersucht wird im Folgenden, welche Einflußgrößen die Analysierbarkeit, die
Modifizierbarkeit, die Stabilität, Testbarkeit und die Umsetzbarkeit beeinflussen.
1Vergleich auch: [Starke2009]
2Vergleiche [Starke2011], Seite 320 ff.
3die Nachfolgenorm ISO 25000 ist in den für den Gang der Arbeit wesentlichen Aspekten weitgehend identisch
4Eine detaillierte Erläuterung findet sich im Appendix

Einflussgrößen - die Metrik
Beschrieben wird im Folgenden, welche Größen Einfluss auf die auf die obigen Merkmale
haben.
Dokumentation
„Da steh ich nun, ich armer Tor! Und bin so klug als wie
zuvor.“
--- Goethe, Faust
Software ohne Dokumentation ist in nahezu allen Fällen
unbrauchbar. Im Mittelpunkt der Betrachtung dieser Analyse
steht bei der Dokumentation die Beschreibung essentieller
Sachverhalte für die Softwareentwicklung wie beispielsweise
Architektur Guidelines, Code Guidelines, in-line Code
Dokumentation etc.. Aber auch Formen der Beschreibung der
Fachlichkeit spielen eine Rolle, hier sind bspw. Epics, User
Stories oder Use Cases von Interesse um die Applikation im
fachlichen Kontext zu verstehen. Betriebshandbücher oder
Anwenderdokumentation hingegen spielen hier eine
untergeordnete Rolle.
Wichtig im Kontext der Dokumentation sind Aspekte der
Vollständigkeit und der Aktualität; wünschenswert wäre der
Einsatz eines entsprechenden Templates1
und der Einsatz automatisierter Checker wie bspw.
das Open Source Produkt Checkstyle.
Entwurfsprinzipien und Pattern
Im Kontext des Entwurfs von Softwarearchitekturen
existieren eine Reihe von Entwurfsprinzipien die Aspekte
wie Kostenminimierung, Wartbarkeit und
Erweiterbarkeit addressieren. Das sicherlich
prominenteste Beispiel ist die Aufteilung der Applikation
in Schichten, eine Strukturierung nach technischen
Gesichtspunkten. Auch die funktionale Zerlegung der
Applikation nach fachlichen Aspekten, das Bilden von
Komponenten ist ein prominentes Beispiel für ein
Entwurfsprinzip der Softwarearchitektur. Gängige
Weitere Beschreibungen von Entwurfsprinzipen sind beispielsweise bei Clean Code zu finden2
.
Generell gilt: die Berücksichtigung dieser Prinzipien in existierenden Applikationen erlaubt
Rückschlüsse auf die Qualität der Architektur hinsichtlich der Qualitätsmerkmale.
Pattern beschreiben Lösungsmuster, sind Verallgemeinerungen von spezifischen Lösungen.
Pattern basieren auf den Prinzipien zur Entwicklung robuster Applikationen wie Information
Hiding oder Loose Coupling und addressieren Wartbarkeit und Stabilität eines Systems. Bei
der Anwendung von Pattern ist zu beachten, dass nicht die Anzahl der verwendeten Pattern
zählt sondern die adäquate Art des Einsatzes.
1z.B. arc42: http://www.arc42.de/template/struktur.html
2Eine detaillierte Erläuterung einiger Prinzipien findet sich im Appendix

Hinsichtlich des vertikalen Schnitts - der Bildung von Komponenten - existieren Heuristiken1
und Regeln wie bspw.:
• Komponenten sollen zusammengehörige Fachlichkeit zusammenfassen.
• Komponenten sollen eindeutig einer Software-Kategorie zugeordnet werden
können (A-Komponenten: implementieren nur Fachlichkeit, T-Komponenten:
stellen technische Dienste bereit; möglichst keine AT-Software auf
Komponentenebene)
• Komponenten sollen so geschnitten sein, dass sie intern einen engen
Zusammenhang haben und untereinander gering gekoppelt sind.
• Komponenten sollen so geschnitten sein, dass sie keine zyklischen
Abhängigkeiten haben.
• Komponenten sollen eine handhabbare Größe haben.
Hinsichtlich des horizontalen Schnitts in Layer existieren eine
Reihe von Pattern, so sollte eine Enterprise-Applikation mittels
des MVC-Patterns und des ECB-Patterns realisiert werden. Beide
Pattern adressieren das Layering sowie - zumindest teilweise -
die Bildung von Komponenten und sind sogenannte
Meta-Pattern. Hierunter werden Pattern verstanden die mittels
anderer Pattern realisert werden. Eines dieser ‘realisierenden’
Pattern ist beispielsweise das DAO-Pattern für den Datenzugriff
auf Entities oder das DTO-Pattern. Ob letzteres wirklich und
immer gebraucht wird sollte vom konkreten Kontext abhängig
gemacht werden und nicht als obligatorischer Bestandteil der
Applikation gesehen werden wohingegen eine Struktur analog
zum MVC- oder zum ECB- Pattern durchaus vorhanden sein
sollte.
Verwendung von Richtlinien und Standards
Richtlinien im Bereich der Softwareentwicklung konkretisieren bestimmte Aspekte und engen
Entscheidungsspielräume ein. Beispiele für Richtlinien können die exemplarischer
Implementierungen bestimmer Aspekte, die eindeutige Festlegung der formalen Gestalt des
Sourcecodes oder verbindliche Vorgaben hinsichtlich der Protokollierung sein. Hierbei muss
seltten das Rad neu erfunden werden vielmehr kann auf verbreitete Richtlinien
zurückgegriffen werden2
und diese ggf. für den Anwendungszweck angepasst werden.
Für die Analyse kommt es hier nicht darauf an, wie dieses Richtlinien ausgekleidet sind,
sondern ob sie existieren und konsequent umgesetzt wurden.
Standards und Normen finden insbesondere dann Verwendung, wenn “etwas” durch
entsprechende Gremien vereinheitlich wurde oder wenn es de-facto - bspw. durch die
Marktposition eines Anbieters - als verbindlich oder einheitlich deklariert wurde. Letzendlich
werden durch Standards und Normen Austauschbarkeit, Zusammenarbeit oder die
Produkteigung für den Anwendungszweck verbessert3
.
Im Kontext der Softwareentwicklung mit Java gibt es eine ganze Reihe von Standards,
exemplarisch sollen JavaEE, Spring, log4J, JPA usw. genannt werden. Es kommt bei der
Analyse nicht darauf an eine Wertung hinsichtlich des gewählten Standards zu treffen
sondern vielmehr auf die konsistente Anwendung eines Standards für einen bestimmten
Anwendungszweck und die Anzahl der verwendeten Standards.
Technisch-konzeptionelle Aspekte
1Beinhaltet in erster Linie „Daumenregeln” auf der Grundlage subjektiver Erfahrungen und überlieferter
Verhaltensweisen; wird v.a. in schlecht strukturierten und schwer überschaubaren Problembereichen angewendet.
2z.B. die Code Conventions von google: https://google-styleguide.googlecode.com/svn/trunk/javaguide.html
3Vergleiche: http://de.wikipedia.org/wiki/Standard

Logging • Ist das Logging konsequent umgesetzt?
• Wurden einheitliche Formate oder ein einheitlicher Aufbau
der Log-Dateien (hinsichtlich ihrer Existenz, nicht ihrer
internen Struktur) realisert oder wird alles in ein einziges
Server-Log geschrieben?
Fehlerbehandlun
g
• Existiert ein Konzept zur Fehlerbehandlung (werden bspw.
technische Exceptions beim Übergang in den UI Layer
einheitlich gewrapped)?
Transaktionen • Gibt es ein stringentes Transaktionskonzept (Wo wird die
Transaktion gestartet, wo abgeschlossen, was passiert im
Falle eines Rollback)?
• Wird zwischen Geschäftstransaktionen (globalen) und
DB-Transaktionen (lokalen) unterschieden?
• Wird ein Transaktionsmanager eingesetzt?
Tests • Wie werden Tests realisiert?
• Gibt es Unit-Tests, Integrationstests, Regressionstests und
Akzeptanztests?
Buildprozess • Existiert ein entsprechender Buildprozess, ist er ggf. bis hin
zur Continuous Integration implementiert?
Bewertungsmatrix
Die obigen Ausführungen können in der folgenden Matrix zusammengefasst werden:
Dokumen-
tation
Entwurfs-
prinzipien und
Pattern
Richtlinien
und
Standards
Logging Fehlerbehand-
lung
Transaktionen Testauto-
matisierung
Buildprozess
Analysierbarkeit hoch hoch hoch mittel gering gering mittel gering
Modifizierbarkeit hoch hoch hoch gering hoch mittel hoch hoch
Stabilität gering gering hoch hoch hoch hoch gering hoch
Testbarkeit mittel mittel gering hoch hoch gering hoch hoch
Umsetzbarkeit hoch hoch hoch mittel mittel mittel gering mittel
Für die weitere Analyse werden für die einzelnen Merkmale die entsprechenden
Einflussgrößen für die einzelnen Komponenten betrachtet und bewertet. Üblicherweise sollten
den Kriterien und den Messgrößen Gewichte zugeordnet werden und Erfüllungsgrade
analysiert werden. Dieser Ansatz erscheint hier doch oversized, das eine hohe
Testautomatisierung / -abdeckung einen starken Einfluß auf die Modifizierbarkeit hat ist
offensichtlich. Liegen keines Tests vor, dann gibt es keine Automatisierung und das System
hat Defizite hinsichtlich der Modifizierbarkeit. Eine Aussage in der Form gewinnt nicht an
Inhalt dadurch, dass man Zahlenwerte hinterlegt.

Appendix A: Erläuterung der Merkmale für
Softwarequalität nach ISO 9126
Funktionalität Inwieweit stellt das betrachtete System die a priori
geforderten
Funktionen zur Verfügung?
1. Angemessenheit: Eignung von Funktionen für
spezifizierte Aufgaben, z. B. aufgabenorientierte
Zusammensetzung von Funktionen aus
Teilfunktionen.
2. Richtigkeit: Liefern der richtigen oder vereinbarten
Ergebnisse oder Wirkungen, z.B. die benötigte
Genauigkeit von berechnetenWerten.
3. Interoperabilität: Die Fähigkeit, mit vorgegebenen
Systemen zusammenzuwirken.
4. Sicherheit: Die Fähigkeit, unberechtigten Zugriff,
sowohl versehentlich als auch vorsätzlich, auf
Programme und Daten zu verhindern.
5. Ordnungsmäßigkeit: Merkmale von Systemen, die
bewirken, dass die Systeme anwendungsspezifische
Normen oder Vereinbarungen oder gesetzliche
Bestimmungen und ähnliche Vorschriften erfüllen.
Zuverlässigkeit Zuverlässigkeit: Kann das System ein bestimmtes
Leistungsniveau unter bestimmten Bedingungen über einen
bestimmten Zeitraum aufrechterhalten?
1. Reife: Geringe Versagenshäufigkeit durch
Fehlerzustände.
2. Fehlertoleranz: Die Fähigkeit, ein spezifiziertes
Leistungsniveau bei Systemfehlern oder
Nichteinhaltung von spezifizierten Schnittstellen zu
bewahren.
3. Robustheit: Die Fähigkeit, ein stabiles System bei
Eingaben zu gewährleisten, die gar nicht vorgesehen
sind. Das System hält auch unvorhergesehenen
Nutzungen stand.
4. Wiederherstellbarkeit:Die Fähigkeit, bei einem
Versagen das Leistungsniveau wiederherzustellen und
die direkt betroffenen Daten wiederzugewinnen. Zu
berücksichtigen sind die dafür benötigte Zeit und der
benötigte Aufwand.
5. Konformität: Grad, in dem das System Normen oder
Vereinbarungen zur Zuverlässigkeit erfüllt.
Benutzbarkeit Benutzbarkeit: Welchen Aufwand fordert der Einsatz des
Systems von den Benutzern und wie wird es von diesen
beurteilt?
1. Verständlichkeit:Der Aufwand für den Benutzer, das
Konzept und das System zu verstehen.
2. Erlernbarkeit: Der Aufwand für den Benutzer, das
System zu erlernen (z.B.: Bedienung, Ein- und
Ausgabe).
3. Bedienbarkeit: Der Aufwand für den Benutzer, das
System zu bedienen.
4. Attraktivität: Die Anziehungskraft des Systems

gegenüber dem Benutzer.
5. Konformität: Der Grad, in dem das System Normen
oder Vereinbarungen zur Benutzbarkeit erfüllt.
Effizienz
(Performance)
Wie ist das Verhältnis zwischen Leistungsniveau des Systems
und eingesetzten Betriebsmitteln?
1. Zeitverhalten: Die Antwort- und Verarbeitungszeiten
sowie Durchsatz bei der Funktionsausführung.
2. Verbrauchsverhalten: Anzahl und Dauer der
benötigten Betriebsmittel bei der Erfüllung der
Funktionen. Ressourcenverbrauch wie CPU-Zeit,
Festplattenzugriffe usw.
3. Konformität: Der Grad, in dem das System Normen
oder Vereinbarungen zur Effizienz erfüllt.
Wartbarkeit Welchen Aufwand erfordert die Durchführung vorgegebener
Änderungen (Korrekturen, Verbesserungen oder
Anpassungen) an das System?
1. Analysierbarkeit: Der Aufwand, um Mängel oder
Ursachen von Versagen zu diagnostizieren oder um
änderungsbedürftige Teile zu bestimmen.
2. Modifizierbarkeit: Der Aufwand zur Ausführung von
Verbesserungen, zur Fehlerbeseitigung oder
Anpassung an Umgebungsänderungen.
3. Stabilität: Die Wahrscheinlichkeit des Auftretens
unerwarteter Wirkungen von Änderungen.
4. Testbarkeit: Der Aufwand, der zur Prüfung des
geänderten Systems notwendig ist.
Portabilität Wie leicht lässt sich das System in eine andere Umgebung
übertragen?
1 Anpassbarkeit: Die Fähigkeit des Systems, diese an
verschiedene Umgebungen anzupassen.
2 Installierbarkeit: Der Aufwand, der zum Installieren
des Systems in einer festgelegten Umgebung
notwendig ist.
3 Koexistenz: Die Fähigkeit des Systems, neben einer
anderen mit ähnlichen oder gleichen Funktionen zu
arbeiten.
4 Austauschbarkeit: Die Möglichkeit, dieses System
anstelle eines spezifizierten anderen Systems in der
Umgebung jenes anderen Systems zu verwenden,
5 Konformität: Der Grad, in dem das System Normen
oder Vereinbarungen zur Übertragbarkeit erfüllt.

Appendix B: Entwurfsprinzipien1
Der folgende Abschnitt bietet eine Abriss wichtiger Entwurfsprinzipien ohne Anspruch auf
Vollständigkeit.
Layering Einzelne Aspekte des Softwaresystems werden
konzeptionell einer Schicht (engl. tier oder layer)
zugeordnet. Die erlaubten
Abhängigkeitsbeziehungen zwischen den Aspekten
werden bei einer Schichtenarchitektur dahingehend
eingeschränkt, dass Aspekte einer „höheren“ Schicht
nur solche „tieferer“ Schichten verwenden dürfen.
Eine Schichtenarchitektur reduziert die Komplexität
der Abhängigkeiten innerhalb des Systems
ermöglicht die geringere Kopplung bei gleichzeitig
höherer Kohäsion der einzelnen Schichten.
Componentization oder
Component-based software
engineering
Das Aufteilen der Software in einzelne Komponenten
fokusiert auf die Aufteilung der Funktionalität in
voneinander weitgehend unabhängigen
Komponenten technischer oder fachlicher Natur und
unterstützt explizit das Prinzip des Separation of
Concerns. Als Software Komponente wird hier bei ein
Softwarepaket, ein WebService, eine Web Resource
oder ein Modul welches Daten oder Funktionen
kapselt verstanden.
Separation of Concerns Separation of Concerns beschreibt die Aufteilung des
Systems in einzelne Komponenten mit klar
zuzuordnender Funktionalität und ohne
Überschneidung der Funktionalität.
Wird dieses Prinzip richtig angewendet, erhält man
Komponenten mit hoher Kohäsion und geringer
Kopplung. Wird das Prinzip nicht beachtet, sind
Erweiterungen und Änderungen der Fuktionalität im
Code nach einer gewissen Zeit nicht mehr oder nur
noch mit unverhältnismäßig großem Aufwand
umsetzbar.
Single Responsibility Principle Jede Komponente sollte für genau ein spezifisches
Feature oder eine spezifische Funktionalität
zuständig sein.
Principle of Least Knowledge
(LoD: Law of Demeter)
Dieses auch als Gesetz von Demeter bekannte
Prinzip fordert, dass eine Komponente keinerlei
Annahmen über den internen Aufbau einer anderen
Komponente treffen muss.
Don’t repeat yourself
(DRY)
Alle Aspekte innerhalb der Software sind an nur
einer Stelle implementiert, ähnlich zu dem
Separation of Concerns.
Redundanter Code ist zunächst einmal kein Fehler,
1Vergleiche hierzu: [Microsoft2009], [Martin2009], [CleanCode], [Martin] und diverse andere

birgt aber die Gefahr, dass Änderungen nicht an
allen Stellen erfolgen und können im Zeitablauf
Inkonsistenzen im Verhalten verursachen.
You ain’t gonna need it
(YAGNI)
Dieses Prinzip fordert, dass Funktionalität nur dann
implementiert wird, wenn sie tatsächlich gebraucht
wird.
Keep it simple, stupid
(KISS)
Das System sollte so umgesetzt sein, dass der
geringstmögliche Grad an Komplexität vorhanden
ist.
Interface Segregation Principle Das Prinzip besagt, dass ein Client nicht von Details
eines Service abhängig sein soll, die er gar nicht
benötigt. Je weniger in dessen Interface enthalten
ist, desto geringer ist die Kopplung zwischen den
beiden Komponenten.

Literatur
[Starke2011] Gernot Starke: Effektive Softwarearchitekturen, Carl Hanser Verlag
2011
[Starke2014] Gernot Starke: About aim42, http://aim42.github.io/#_about_aim42
[Bass2003] Len Bass, Paul Clements, Rick Kazmann: Software Architecture in
Practice 2nd Edition, Addison-Wesley 2003
[Hillard2000] Rich Hilliard: IEEE-Std-1471-2000
Recommended Practice for Architectural Description of
Software-Intensive Systems, Präsentation:
http://www.enterprise-architecture.info/Images/Documents/IEEE
%201471-2000.pdf
[Kazmann2000] Rick Kazman, Mark Klein, Paul Clements: ATAM:Method for
Architecture Evaluation, TECHNICAL REPORT CMU/SEI-2000-TR-004
ESC-TR-2000-004
http://resources.sei.cmu.edu/asset_files/TechnicalReport/2000_005_
001_13706.pdf
[Northrop2003] Linda Northrop: The Importance of Software Architecture,
Präsentation des Software Engineering Institute der Carnegie Mellon
University
http://sunset.usc.edu/GSAW/gsaw2003/s13/northrop.pdf
[Li2011] Zude Li: Architectural Degeneration of Software Systems:
Characterising and Diagnosing Degeneration of Software Architecture
from Defect Perspective, LAP LAMBERT Academic Publishing
[Lindvall2005] Lorin Hochstein, Mikael Lindvall: Combating architectural
degeneration: a survey, Journal of Information and Software
Technology Volume 47 Issue 10, July, 2005 Pages 643-656
[Williams] Byron J. Williams, Jeffrey C. Carver: Characterizing Software
Architecture Changes: An Initial Study, Paper des Department of
Computer Science & Engineering Mississippi State University
[IEEE1061] IEEE Standard 1061, 1998
[Muller2007] Gerrit Muller und Eirik Hole: Reference Architectures; Why, What and
How, White Paper Resulting from Architecture Forum Meeting March
12 & 13, 2007 (Hoboken NJ, USA)
[Bloching2013] Team Bloching: MDS Toolset technische Grundlagenbeschreibungen
zur Systemarchitektur, Framework und Design, PowerPoint
Präsentation
[Krafzig2004] Dirk Krafzig, Karl Banke, Dirk Slama: Enterprise SOA:
Service-Oriented Architecture Best Practices, Prentice Hall PTR
[Microsoft2009] Microsoft Application Architecture Guide, 2nd Edition
[Martin2008] Robert C. Martin: Clean Code: A Handbook of Agile Software
Craftsmanship, Prentice Hall

[CleanCode] Clean Code Developer, http://www.clean-code-developer.de/
[Starke2011] Gernot Starke: Effektive Softwarearchitekturen, Carl Hanser Verlag
2011
[Starke2014] Gernot Starke: About aim42,
http://aim42.github.io/#_about_aim42
[Bass2003] Len Bass, Paul Clements, Rick Kazmann: Software Architecture in
Practice 2nd Edition, Addison-Wesley 2003
[Hillard2000] Rich Hilliard: IEEE-Std-1471-2000
Recommended Practice for Architectural Description of
Software-Intensive Systems, Präsentation:
http://www.enterprise-architecture.info/Images/Documents/IEEE
%201471-2000.pdf
[Kazmann2000] Rick Kazman, Mark Klein, Paul Clements: ATAM:Method for
Architecture Evaluation, TECHNICAL REPORT CMU/SEI-2000-TR-004
ESC-TR-2000-004
http://resources.sei.cmu.edu/asset_files/TechnicalReport/2000_005_
001_13706.pdf
[Northrop2003] Linda Northrop: The Importance of Software Architecture,
Präsentation des Software Engineering Institute der Carnegie Mellon
University
http://sunset.usc.edu/GSAW/gsaw2003/s13/northrop.pdf
[Li2011] Zude Li: Architectural Degeneration of Software Systems:
Characterising and Diagnosing Degeneration of Software Architecture
from Defect Perspective, LAP LAMBERT Academic Publishing
[Lindvall2005] Lorin Hochstein, Mikael Lindvall: Combating architectural
degeneration: a survey, Journal of Information and Software
Technology Volume 47 Issue 10, July, 2005 Pages 643-656
[Williams] Byron J. Williams, Jeffrey C. Carver: Characterizing Software
Architecture Changes: An Initial Study, Paper des Department of
Computer Science & Engineering Mississippi State University
[IEEE1061] IEEE Standard 1061, 1998
[Muller2007] Gerrit Muller und Eirik Hole: Reference Architectures; Why, What and
How, White Paper Resulting from Architecture Forum Meeting March
12 & 13, 2007 (Hoboken NJ, USA)
[Bloching2013] Team Bloching: MDS Toolset technische Grundlagenbeschreibungen
zur Systemarchitektur, Framework und Design, PowerPoint
Präsentation
[Krafzig2004] Dirk Krafzig, Karl Banke, Dirk Slama: Enterprise SOA:
Service-Oriented Architecture Best Practices, Prentice Hall PTR
[Microsoft2009] Microsoft Application Architecture Guide, 2nd Edition
[Martin2008] Robert C. Martin: Clean Code: A Handbook of Agile Software
Craftsmanship, Prentice Hall
[CleanCode] Clean Code Developer, http://www.clean-code-developer.de/

Zörner[2012] Stefan Zörner: Softwarearchitekturen dokumentieren und
kommunizieren, Hanser 2012
[Masak2010] Dieter Masak: Der Architekturreview; Vorgehensweise, Konzepte und
Praktiken, Springer 2010
[Stal2011] Michael Stal: The Beauty and Quality of Software,
http://stal.blogspot.de/2011/01/beauty-and-quality-of-software.html
[MDS2013] Kai Rehlen, Dr. Lars Meyer (MDS): Codeanalyse MDS-Toolset, Version
1.00 final
[Erl2008] Thomas Erl: SOA Design Pattern, Prentice Hall 2008
[Kulkarni2008] Naveen Kulkarni, Vishal Dwivedi: The Role of Service Granularity in A
Successful SOA Realization – A Case Study, 2008 IEEE Congress on
Services 2008
[Tiemeyer2009] Ernst Tiemeyer: Herausforderungen und Aufgaben für
IT-Verantwortliche,
http://www.business-wissen.de/artikel/it-architekturmanagement-he
rausforderungen-und-aufgaben-fuer-it-verantwortliche/
[Pientka2014] Frank Pientka: Gebaut für den Wandel, bt Magazin 3.2014
[OMG2011] The Open Group: Open Group Standard SOA Reference Architecture,
The Open Group 20122, ISBN 1-937218-01-0
[Martin] Robert C. Martin alias Uncle Bob: The Principles of OOD,
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
[Westphal2014] Ralf Westphal: Warnung vor dem Microservice – Versuch einer
Definition,
http://blog.ralfw.de/2014/08/warnung-vor-dem-microservice-versuc
h.html?
utm_source=feedburner&utm_medium=feed&utm_campaign=Feed
%3A+ralfw+%28One+Man+Think+Tank+Gedanken%29
[Fowler2014] Martin Fowler, James Lewis: Microservices,
http://martinfowler.com/articles/microservices.html
[Hophe2003] Gregor Hophe, Bobby Woolf: Enterprise Integration Patterns:
Designing, Building, and Deploying Messaging Solutions, Addison
Wesley, 2003
[Richardson2014] Chris Richardson: Microservices: Decomposing Applications for
Deployability and Scalability, InfoQ Microservices / eMag Issue 16 -
August 2014, http://www.infoq.com/minibooks/emag-microservices
[Ambler2012] Scott W. Amblre: Agile Architecture: Strategies for Scaling Agile
Development,
http://agilemodeling.com/essays/agileArchitecture.htm

Architekturbewertung

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Architekturbewertung

Similaire à Architekturbewertung (20)

Plus de Brockhaus Consulting GmbH

Plus de Brockhaus Consulting GmbH (20)

Architekturbewertung