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..........................................................................................4Was dieses Dokument leistet (und nicht leistet)..............................................................5

Softwarearchitektur im Kontext..............................................................................6Begriff der Softwarearchitektur....................................................................................6Referenzarchitekturen................................................................................................7Softwarearchitektur in zeitlicher Betrachtung.................................................................9

Bewertung von Softwarearchitekturen..................................................................11Indikatoren für Architekturprobleme, die Architectural Smells.........................................11Vorgehen bei der Bewertung......................................................................................12Kriterien bei der Bewertung.......................................................................................13Einflussgrößen - die Metrik........................................................................................14

Dokumentation................................................................................................14Entwurfsprinzipien und Pattern...........................................................................14Verwendung von Richtlinien und Standards..........................................................15Technisch-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............................................................7Illustration 2: Entstehen von Referenzarchitekturen........................................................7Illustration 3: Referenzarchitektur von Mocrosoft............................................................8Illustration 4: SOA Referenzarchitektur der OMG............................................................8Illustration 5: Änderbarkeit von Software im Zeitablauf...................................................9Illustration 6: Relation von Kosten und Verständlichkeit von Software..............................10Illustration 7: Kriterien zur Softwarequalität nach ISO 9126...........................................13


EinleitungThere 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 thatthere are no obvious deficiencies. The first method is far more difficult.

-- C.A.R Hoare

Überblick über das ProjektDas 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 2 nd und 3 rd Level Support für die internen Module sowie kleine Bugfixes und Erweiterungen mit einem Umfang von wenigerals 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 extremteuer.


http://de.wikipedia.org/wiki/Support_(Dienstleistung)#Kompetenzen-Aufteilung





http://de.wikipedia.org/wiki/Tony_Hoare

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 Aspektehinweisen. 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 KontextDer 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 inits components, their relationships to each other and to

the environment and the principles guiding its designand evolution.

[IEEE1471]

The software architecture of a program or computingsystem is the structure or structures of the system,

which comprise software elements, the externally visibleproperties of those elements, and the relationships

among them.[Bass2003], Chapter 1

Die einheitliche Definition des Begriffs der Softwarearchitektur gibt es nicht, auf der Webseitedes 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 thesystem of interest, itscontext and theorganizations creating thesystem

Increasing dynamics andintegration: shorter time tomarket, moreinteroperability, rapidchanges and adaptations inthe field.

A Reference Architecture provides aproven template solution for anarchitecture 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 und2. 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 existierendeArchitekturen nach diesenbewährten Konzeptendurchsucht. Für dieRenovierung von Architekturenund die Validierung vonInnovationen kann aufReferenzarchitekturenzurückgegriffen werden.Referenzarchitekturen lassensich in mannigfaltigenAusprägungen finden, es gibteine SOA Referenzarchitekturder OMG, die ProactiveInfrastructure (PAI) beiMercedes, …


Illustration 1: Umfeld von Referenzarchitekturen

Illustration 2: Entstehen von Referenzarchitekturen

http://en.wikipedia.org/wiki/Antoine_de_Saint-Exup%C3%A9ry

Die nebenstehende Grafik bildetexemplarisch eine Referenzarchitektur ab,hier die von Microsoft empfohlene “common application architecture withcomponents grouped by different areas ofconcern.”

Als eine weitere Referenzarchitektur solldie von der OMG publizierte SOA ReferenceArchitecture angeführt werden1.Gemeinsam ist beidenReferenzarchitekturen die horizontaleTeilung in verschiedene Layer und dieFokussierung auf Services. Microsoftverortet den Business Workflow innerhalbdes Business Layers, eine Auffassung, dieunterstellt, dass dieser Workflow wohl nichtmit den Service Interfaces interagiert. Ausdieser Annahme heraus wird für dieAnalyse die SOA Referenzarchitekturherangezogen innerhalb derer zwischenBusiness Processes und und der ServiceImplementierung 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

http://msdn.microsoft.com/en-us/library/ee658124.aspx





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. Entireengineering 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 ‘degenerationof architecture’ welche eintritt, wenn dieüber den Zeitablauf auftretendenÄnderungen Einfluß auf die Architektur desSystems nehmen. Diese “Degeneration”macht Änderungen schwieriger undkostenintensiver und Degeneration kannletztendlich dazu führen, dass einvollstä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 Softwaredokumentation2. Fehlende technische Infrastruktur wie Versionsverwaltung, Datensicherung,

Build-Tools, Kontinuierliche Integration3. Hintanstellen, Verzicht oder ungenügende Umsetzung automatisierter Modultests

und Regressionstests4. Hintanstellen der Korrektur von zu großem oder zu komplexen Code und Design5. 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

http://en.wikipedia.org/wiki/Ward_Cunningham

http://en.wikipedia.org/wiki/Manny_Lehman_(computer_scientist)

http://en.wikipedia.org/wiki/Ward_Cunningham

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 Level3. 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 undvorteilhaft sein kann wurde mehrfach gezeigt.Als typisches Beispiel soll hier RedHat’s JBossangeführt werden. Der Applikationsserver wurdenach mehreren Releases mit kleinerenÄnderungen im administrativen Bereich oder imBereich des Messaging aber mit zunehmenderKomplexität des Produktes in seiner Version 7vollständig überarbeitet und ist nunmehr einerder performantesten Applikationsserver auf demMarkt. Ein ähnliches Beispiel ist das populäreHibernate-Framework welches von Release 3.x zuRelease 4.x vollständig überarbeitet wurde, auchum 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 vonSoftwarearchitekturen

Without undertaking a formal analysis process, theorganization cannot ensure that the architectural decisionsmade—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 wasexpressed in a kind of idiomatic way, where the same principles have been applied todifferent 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 BewertungBei 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 ATAM 1 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 Method2Für dieses und das Folgende vergl.: [Masak2010]


http://www.sei.cmu.edu/architecture/tools/evaluate/atam.cfm

http://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_method

Kriterien bei der BewertungIm 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 Merkmaleum 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


http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm%3Fcsnumber=35683

Einflussgrößen - die MetrikBeschrieben 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ällenunbrauchbar. Im Mittelpunkt der Betrachtung dieser Analysesteht bei der Dokumentation die Beschreibung essentiellerSachverhalte für die Softwareentwicklung wie beispielsweiseArchitektur Guidelines, Code Guidelines, in-line CodeDokumentation etc.. Aber auch Formen der Beschreibung derFachlichkeit spielen eine Rolle, hier sind bspw. Epics, UserStories oder Use Cases von Interesse um die Applikation imfachlichen Kontext zu verstehen. Betriebshandbücher oderAnwenderdokumentation hingegen spielen hier eineuntergeordnete Rolle.

Wichtig im Kontext der Dokumentation sind Aspekte derVollständigkeit und der Aktualität; wünschenswert wäre derEinsatz eines entsprechenden Templates1 und der Einsatz automatisierter Checker wie bspw. das Open Source Produkt Checkstyle.

Entwurfsprinzipien und Pattern Im Kontext des Entwurfs von Softwarearchitekturenexistieren eine Reihe von Entwurfsprinzipien die Aspektewie Kostenminimierung, Wartbarkeit undErweiterbarkeit addressieren. Das sicherlichprominenteste Beispiel ist die Aufteilung der Applikationin Schichten, eine Strukturierung nach technischenGesichtspunkten. Auch die funktionale Zerlegung derApplikation nach fachlichen Aspekten, das Bilden vonKomponenten ist ein prominentes Beispiel für einEntwurfsprinzip 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.html2Eine detaillierte Erläuterung einiger Prinzipien findet sich im Appendix


http://checkstyle.sourceforge.net/

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 eineReihe von Pattern, so sollte eine Enterprise-Applikation mittelsdes MVC-Patterns und des ECB-Patterns realisiert werden. BeidePattern adressieren das Layering sowie - zumindest teilweise -die Bildung von Komponenten und sind sogenannte Meta-Pattern. Hierunter werden Pattern verstanden die mittelsanderer Pattern realisert werden. Eines dieser ‘realisierenden’Pattern ist beispielsweise das DAO-Pattern für den Datenzugriffauf Entities oder das DTO-Pattern. Ob letzteres wirklich undimmer gebraucht wird sollte vom konkreten Kontext abhängiggemacht werden und nicht als obligatorischer Bestandteil derApplikation gesehen werden wohingegen eine Struktur analogzum MVC- oder zum ECB- Pattern durchaus vorhanden seinsollte.

Verwendung von Richtlinien und StandardsRichtlinien im Bereich der Softwareentwicklung konkretisieren bestimmte Aspekte und engenEntscheidungsspielrä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.html3Vergleiche: http://de.wikipedia.org/wiki/Standard


http://en.wikipedia.org/wiki/Data_transfer_object

http://en.wikipedia.org/wiki/Data_access_object

http://en.wikipedia.org/wiki/Metapattern

http://www.oracle.com/technetwork/issue-archive/2011/11-jan/o11java-195110.html

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

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?

Fehlerbehandlung

• 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?

BewertungsmatrixDie 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 solltenden 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.


http://en.wikipedia.org/wiki/Continuous_integration

Appendix A: Erläuterung der Merkmale für Softwarequalität nach ISO 9126

Funktionalität Inwieweit stellt das betrachtete System die a priori gefordertenFunktionen 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 unddie 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“ Schichtnur 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 Komponentenfokusiert 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 einSoftwarepaket, ein WebService, eine Web Resource oder ein Modul welches Daten oder Funktionen kapselt verstanden.

Separation of Concerns Separation of Concerns beschreibt die Aufteilung desSystems 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


http://de.wikipedia.org/wiki/Lose_Kopplung

http://de.wikipedia.org/wiki/Koh%C3%A4sion_(Informatik)

http://de.wikipedia.org/wiki/Koh%C3%A4sion_(Informatik)

http://de.wikipedia.org/wiki/Lose_Kopplung

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-2000Recommended 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-004http://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 Universityhttp://sunset.usc.edu/GSAW/gsaw2003/s13/northrop.pdf

[Li2011] Zude Li: Architectural Degeneration of Software Systems: Characterising and Diagnosing Degeneration of Software Architecturefrom 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 andHow, 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-2000Recommended 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-004http://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 Universityhttp://sunset.usc.edu/GSAW/gsaw2003/s13/northrop.pdf

[Li2011] Zude Li: Architectural Degeneration of Software Systems: Characterising and Diagnosing Degeneration of Software Architecturefrom 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 andHow, 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/


http://aim42.github.io/#_about_aim42

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 undPraktiken, 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, Version1.00 final

[Erl2008] Thomas Erl: SOA Design Pattern, Prentice Hall 2008

[Kulkarni2008] Naveen Kulkarni, Vishal Dwivedi: The Role of Service Granularity in ASuccessful 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-herausforderungen-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-versuch.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


Education

Architekturbewertung