SlideShare ist ein Scribd-Unternehmen logo
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
Copyright and all intellectual property belongs to Brockhaus Group 2
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
Copyright and all intellectual property belongs to Brockhaus Group 3
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.
Copyright and all intellectual property belongs to Brockhaus Group 4
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]
Copyright and all intellectual property belongs to Brockhaus Group 5
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
Copyright and all intellectual property belongs to Brockhaus Group 6
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, …
Copyright and all intellectual property belongs to Brockhaus Group 7
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]
Copyright and all intellectual property belongs to Brockhaus Group 8
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]
Copyright and all intellectual property belongs to Brockhaus Group 9
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]
Copyright and all intellectual property belongs to Brockhaus Group 10
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]
Copyright and all intellectual property belongs to Brockhaus Group 11
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]
Copyright and all intellectual property belongs to Brockhaus Group 12
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
Copyright and all intellectual property belongs to Brockhaus Group 13
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
Copyright and all intellectual property belongs to Brockhaus Group 14
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
Copyright and all intellectual property belongs to Brockhaus Group 15
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.
Copyright and all intellectual property belongs to Brockhaus Group 16
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
Copyright and all intellectual property belongs to Brockhaus Group 17
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.
Copyright and all intellectual property belongs to Brockhaus Group 18
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
Copyright and all intellectual property belongs to Brockhaus Group 19
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.
Copyright and all intellectual property belongs to Brockhaus Group 20
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
Copyright and all intellectual property belongs to Brockhaus Group 21
[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/
Copyright and all intellectual property belongs to Brockhaus Group 22
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
Copyright and all intellectual property belongs to Brockhaus Group 23

Weitere ähnliche Inhalte

Andere mochten auch

Dossier de référencement - DU communication
Dossier de référencement -  DU communicationDossier de référencement -  DU communication
Dossier de référencement - DU communication
Pierre-Marie Poirier
 
Duonett D7
Duonett D7Duonett D7
Duonett D7
Aaron P. Gerber
 
Web 2.0 Mini presentation
Web 2.0 Mini presentationWeb 2.0 Mini presentation
Web 2.0 Mini presentation
guest16f4cc3
 
Enlace Ciudadano Nro. 268 - Exhortos Asamblea Nacional
Enlace Ciudadano Nro. 268 - Exhortos Asamblea NacionalEnlace Ciudadano Nro. 268 - Exhortos Asamblea Nacional
Enlace Ciudadano Nro. 268 - Exhortos Asamblea Nacional
Presidencia de la República del Ecuador
 
2008 H2 Sut Su Vaustattungsliste
2008 H2 Sut Su Vaustattungsliste2008 H2 Sut Su Vaustattungsliste
2008 H2 Sut Su Vaustattungsliste
guesta0fe7b
 
Figaronron - Ducasse d'Ath 01 (23-08-2009)
Figaronron - Ducasse d'Ath 01 (23-08-2009)Figaronron - Ducasse d'Ath 01 (23-08-2009)
Figaronron - Ducasse d'Ath 01 (23-08-2009)
Figaronron Figaronron
 
Espresso Meeting v2: La guerre des générations aurat-t-elle lieu ? MS&L France
Espresso Meeting v2: La guerre des générations aurat-t-elle lieu ? MS&L FranceEspresso Meeting v2: La guerre des générations aurat-t-elle lieu ? MS&L France
Espresso Meeting v2: La guerre des générations aurat-t-elle lieu ? MS&L France
michaelp
 
Café numérique Charleroi janvier 2015
Café numérique Charleroi janvier 2015Café numérique Charleroi janvier 2015
Café numérique Charleroi janvier 2015
Lydia Alexandre
 
EC435 Diálogos nacionales
EC435 Diálogos nacionalesEC435 Diálogos nacionales
EC435 Diálogos nacionales
Presidencia de la República del Ecuador
 
Panellets
PanelletsPanellets
Panellets
dolorsgarcia
 
Enlace Ciudadano Nro. 264 - Sistema nacional de registro de datos públicos
Enlace Ciudadano Nro. 264 - Sistema nacional de registro de datos públicosEnlace Ciudadano Nro. 264 - Sistema nacional de registro de datos públicos
Enlace Ciudadano Nro. 264 - Sistema nacional de registro de datos públicos
Presidencia de la República del Ecuador
 
A magia das lanternas
A magia das lanternasA magia das lanternas
A magia das lanternas
Rosa Silva
 
Tecnología aeroespacial C4
Tecnología aeroespacial C4Tecnología aeroespacial C4
Tecnología aeroespacial C4
javiertecteos
 
Escale santé n°2
Escale santé n°2Escale santé n°2
Escale santé n°2
Mutuelle Air France
 
Twinny treibt Sport
Twinny treibt SportTwinny treibt Sport
Twinny treibt Sport
IsabelBB
 
Parte 5
Parte 5Parte 5
Parte 5
KPatyy
 

Andere mochten auch (20)

Dossier de référencement - DU communication
Dossier de référencement -  DU communicationDossier de référencement -  DU communication
Dossier de référencement - DU communication
 
Duonett D7
Duonett D7Duonett D7
Duonett D7
 
Compteur
CompteurCompteur
Compteur
 
Web 2.0 Mini presentation
Web 2.0 Mini presentationWeb 2.0 Mini presentation
Web 2.0 Mini presentation
 
Enlace Ciudadano Nro. 268 - Exhortos Asamblea Nacional
Enlace Ciudadano Nro. 268 - Exhortos Asamblea NacionalEnlace Ciudadano Nro. 268 - Exhortos Asamblea Nacional
Enlace Ciudadano Nro. 268 - Exhortos Asamblea Nacional
 
Bibiche[1]
Bibiche[1]Bibiche[1]
Bibiche[1]
 
EC 402: Yasunidos
EC 402: YasunidosEC 402: Yasunidos
EC 402: Yasunidos
 
2008 H2 Sut Su Vaustattungsliste
2008 H2 Sut Su Vaustattungsliste2008 H2 Sut Su Vaustattungsliste
2008 H2 Sut Su Vaustattungsliste
 
Figaronron - Ducasse d'Ath 01 (23-08-2009)
Figaronron - Ducasse d'Ath 01 (23-08-2009)Figaronron - Ducasse d'Ath 01 (23-08-2009)
Figaronron - Ducasse d'Ath 01 (23-08-2009)
 
Espresso Meeting v2: La guerre des générations aurat-t-elle lieu ? MS&L France
Espresso Meeting v2: La guerre des générations aurat-t-elle lieu ? MS&L FranceEspresso Meeting v2: La guerre des générations aurat-t-elle lieu ? MS&L France
Espresso Meeting v2: La guerre des générations aurat-t-elle lieu ? MS&L France
 
Claudine_Mikey
Claudine_MikeyClaudine_Mikey
Claudine_Mikey
 
Café numérique Charleroi janvier 2015
Café numérique Charleroi janvier 2015Café numérique Charleroi janvier 2015
Café numérique Charleroi janvier 2015
 
EC435 Diálogos nacionales
EC435 Diálogos nacionalesEC435 Diálogos nacionales
EC435 Diálogos nacionales
 
Panellets
PanelletsPanellets
Panellets
 
Enlace Ciudadano Nro. 264 - Sistema nacional de registro de datos públicos
Enlace Ciudadano Nro. 264 - Sistema nacional de registro de datos públicosEnlace Ciudadano Nro. 264 - Sistema nacional de registro de datos públicos
Enlace Ciudadano Nro. 264 - Sistema nacional de registro de datos públicos
 
A magia das lanternas
A magia das lanternasA magia das lanternas
A magia das lanternas
 
Tecnología aeroespacial C4
Tecnología aeroespacial C4Tecnología aeroespacial C4
Tecnología aeroespacial C4
 
Escale santé n°2
Escale santé n°2Escale santé n°2
Escale santé n°2
 
Twinny treibt Sport
Twinny treibt SportTwinny treibt Sport
Twinny treibt Sport
 
Parte 5
Parte 5Parte 5
Parte 5
 

Ähnlich wie Architekturbewertung

Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Steht alles im Wiki? Das kleine 1x1 der ArchitekturdokumentationSteht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
oose
 
TOGAF Architecture Content Framework
TOGAF Architecture Content FrameworkTOGAF Architecture Content Framework
TOGAF Architecture Content Framework
Roland Bruggmann
 
Softwarequalität - Architektur
Softwarequalität - ArchitekturSoftwarequalität - Architektur
Softwarequalität - Architektur
Gerrit Beine
 
Microservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary PatternMicroservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary Pattern
Brockhaus Consulting GmbH
 
DevOps Sepc15
DevOps Sepc15DevOps Sepc15
DevOps Sepc15
Florian Thiévent
 
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
OPEN KNOWLEDGE GmbH
 
Bachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20TscheschnerBachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20Tscheschner
tutorialsruby
 
Bachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20TscheschnerBachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20Tscheschner
tutorialsruby
 
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit ImplementierungsanteilPLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
Intelliact AG
 
Agilität und Qualitätskriterien in der Softwareentwicklung
Agilität und Qualitätskriterien in der SoftwareentwicklungAgilität und Qualitätskriterien in der Softwareentwicklung
Agilität und Qualitätskriterien in der Softwareentwicklung
rico.fritzsche
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
Claudia Haußmann 🦋
 
Fonda: Erfolgsfaktor Benutzeroberfläche
Fonda: Erfolgsfaktor BenutzeroberflächeFonda: Erfolgsfaktor Benutzeroberfläche
Fonda: Erfolgsfaktor Benutzeroberfläche
Fonda Wien
 
Ein Requirements Engineering Referenzmodell
Ein Requirements Engineering ReferenzmodellEin Requirements Engineering Referenzmodell
Ein Requirements Engineering Referenzmodell
Arnold Rudorfer
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshop
mrdoubleb
 
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
Aberla
 
Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung
Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung
Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung
Nico Orschel
 
Projektmanagement-Software Leitfaden
Projektmanagement-Software LeitfadenProjektmanagement-Software Leitfaden
Projektmanagement-Software Leitfaden
Projekt Magazin
 
Software-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenSoftware-Tests in PHP-Anwendungen
Software-Tests in PHP-Anwendungen
Gjero Krsteski
 
Agiles Management für erfolgreiche IT-Projekte
Agiles Management für erfolgreiche IT-ProjekteAgiles Management für erfolgreiche IT-Projekte
Agiles Management für erfolgreiche IT-Projekte
JustRelate
 

Ähnlich wie Architekturbewertung (20)

Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Steht alles im Wiki? Das kleine 1x1 der ArchitekturdokumentationSteht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
Steht alles im Wiki? Das kleine 1x1 der Architekturdokumentation
 
TOGAF Architecture Content Framework
TOGAF Architecture Content FrameworkTOGAF Architecture Content Framework
TOGAF Architecture Content Framework
 
Softwarequalität - Architektur
Softwarequalität - ArchitekturSoftwarequalität - Architektur
Softwarequalität - Architektur
 
Microservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary PatternMicroservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary Pattern
 
DevOps Sepc15
DevOps Sepc15DevOps Sepc15
DevOps Sepc15
 
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
 
Bachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20TscheschnerBachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20Tscheschner
 
Bachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20TscheschnerBachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20Tscheschner
 
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit ImplementierungsanteilPLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
 
Agilität und Qualitätskriterien in der Softwareentwicklung
Agilität und Qualitätskriterien in der SoftwareentwicklungAgilität und Qualitätskriterien in der Softwareentwicklung
Agilität und Qualitätskriterien in der Softwareentwicklung
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
 
Fonda: Erfolgsfaktor Benutzeroberfläche
Fonda: Erfolgsfaktor BenutzeroberflächeFonda: Erfolgsfaktor Benutzeroberfläche
Fonda: Erfolgsfaktor Benutzeroberfläche
 
Ein Requirements Engineering Referenzmodell
Ein Requirements Engineering ReferenzmodellEin Requirements Engineering Referenzmodell
Ein Requirements Engineering Referenzmodell
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshop
 
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
ESEconf2011 - Trost Joachim: "Tool supported technical Code and Design Qualit...
 
Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung
Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung
Links und rechts des Weges: Qualitätssicherung ist mehr als Testfallverwaltung
 
Projektmanagement-Software Leitfaden
Projektmanagement-Software LeitfadenProjektmanagement-Software Leitfaden
Projektmanagement-Software Leitfaden
 
Software-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenSoftware-Tests in PHP-Anwendungen
Software-Tests in PHP-Anwendungen
 
Systementwurf mit UML
Systementwurf mit UMLSystementwurf mit UML
Systementwurf mit UML
 
Agiles Management für erfolgreiche IT-Projekte
Agiles Management für erfolgreiche IT-ProjekteAgiles Management für erfolgreiche IT-Projekte
Agiles Management für erfolgreiche IT-Projekte
 

Mehr von Brockhaus Consulting GmbH

Industrie 40 Symposium an der RFH Köln 7.7.2016
Industrie 40 Symposium an der RFH Köln 7.7.2016 Industrie 40 Symposium an der RFH Köln 7.7.2016
Industrie 40 Symposium an der RFH Köln 7.7.2016
Brockhaus Consulting GmbH
 
Zeitreihen in Apache Cassandra
Zeitreihen in Apache CassandraZeitreihen in Apache Cassandra
Zeitreihen in Apache Cassandra
Brockhaus Consulting GmbH
 
M2M infrastructure using Docker
M2M infrastructure using DockerM2M infrastructure using Docker
M2M infrastructure using Docker
Brockhaus Consulting GmbH
 
Arquillian in a nutshell
Arquillian in a nutshellArquillian in a nutshell
Arquillian in a nutshell
Brockhaus Consulting GmbH
 
Big Data and Business Intelligence
Big Data and Business IntelligenceBig Data and Business Intelligence
Big Data and Business Intelligence
Brockhaus Consulting GmbH
 
OPC -Connectivity using Java
OPC -Connectivity using JavaOPC -Connectivity using Java
OPC -Connectivity using Java
Brockhaus Consulting GmbH
 
Mobile Endgeräte in der Produktion
Mobile Endgeräte in der ProduktionMobile Endgeräte in der Produktion
Mobile Endgeräte in der Produktion
Brockhaus Consulting GmbH
 
Intro 2 Machine Learning
Intro 2 Machine LearningIntro 2 Machine Learning
Intro 2 Machine Learning
Brockhaus Consulting GmbH
 
Messaging im Internet of Things: MQTT
Messaging im Internet of Things: MQTTMessaging im Internet of Things: MQTT
Messaging im Internet of Things: MQTT
Brockhaus Consulting GmbH
 
Industrie 4.0: Symposium an der RFH Köln
Industrie 4.0: Symposium an der RFH KölnIndustrie 4.0: Symposium an der RFH Köln
Industrie 4.0: Symposium an der RFH Köln
Brockhaus Consulting GmbH
 
Java EE Pattern: Infrastructure
Java EE Pattern: InfrastructureJava EE Pattern: Infrastructure
Java EE Pattern: Infrastructure
Brockhaus Consulting GmbH
 
Java EE Pattern: The Entity Layer
Java EE Pattern: The Entity LayerJava EE Pattern: The Entity Layer
Java EE Pattern: The Entity Layer
Brockhaus Consulting GmbH
 
Java EE Pattern: The Control Layer
Java EE Pattern: The Control LayerJava EE Pattern: The Control Layer
Java EE Pattern: The Control Layer
Brockhaus Consulting GmbH
 
Java EE Pattern: The Boundary Layer
Java EE Pattern: The Boundary LayerJava EE Pattern: The Boundary Layer
Java EE Pattern: The Boundary Layer
Brockhaus Consulting GmbH
 
Java EE Pattern: Entity Control Boundary Pattern and Java EE
Java EE Pattern: Entity Control Boundary Pattern and Java EEJava EE Pattern: Entity Control Boundary Pattern and Java EE
Java EE Pattern: Entity Control Boundary Pattern and Java EE
Brockhaus Consulting GmbH
 
Industry 4.0
Industry 4.0Industry 4.0
Big Data in Production Environments
Big Data in Production EnvironmentsBig Data in Production Environments
Big Data in Production Environments
Brockhaus Consulting GmbH
 
BRO 110: Reference Architecture
BRO 110: Reference ArchitectureBRO 110: Reference Architecture
BRO 110: Reference Architecture
Brockhaus Consulting GmbH
 
Bro110 5 1_software_architecture
Bro110 5 1_software_architectureBro110 5 1_software_architecture
Bro110 5 1_software_architecture
Brockhaus Consulting GmbH
 
Work shop worldbank
Work shop worldbankWork shop worldbank
Work shop worldbank
Brockhaus Consulting GmbH
 

Mehr von Brockhaus Consulting GmbH (20)

Industrie 40 Symposium an der RFH Köln 7.7.2016
Industrie 40 Symposium an der RFH Köln 7.7.2016 Industrie 40 Symposium an der RFH Köln 7.7.2016
Industrie 40 Symposium an der RFH Köln 7.7.2016
 
Zeitreihen in Apache Cassandra
Zeitreihen in Apache CassandraZeitreihen in Apache Cassandra
Zeitreihen in Apache Cassandra
 
M2M infrastructure using Docker
M2M infrastructure using DockerM2M infrastructure using Docker
M2M infrastructure using Docker
 
Arquillian in a nutshell
Arquillian in a nutshellArquillian in a nutshell
Arquillian in a nutshell
 
Big Data and Business Intelligence
Big Data and Business IntelligenceBig Data and Business Intelligence
Big Data and Business Intelligence
 
OPC -Connectivity using Java
OPC -Connectivity using JavaOPC -Connectivity using Java
OPC -Connectivity using Java
 
Mobile Endgeräte in der Produktion
Mobile Endgeräte in der ProduktionMobile Endgeräte in der Produktion
Mobile Endgeräte in der Produktion
 
Intro 2 Machine Learning
Intro 2 Machine LearningIntro 2 Machine Learning
Intro 2 Machine Learning
 
Messaging im Internet of Things: MQTT
Messaging im Internet of Things: MQTTMessaging im Internet of Things: MQTT
Messaging im Internet of Things: MQTT
 
Industrie 4.0: Symposium an der RFH Köln
Industrie 4.0: Symposium an der RFH KölnIndustrie 4.0: Symposium an der RFH Köln
Industrie 4.0: Symposium an der RFH Köln
 
Java EE Pattern: Infrastructure
Java EE Pattern: InfrastructureJava EE Pattern: Infrastructure
Java EE Pattern: Infrastructure
 
Java EE Pattern: The Entity Layer
Java EE Pattern: The Entity LayerJava EE Pattern: The Entity Layer
Java EE Pattern: The Entity Layer
 
Java EE Pattern: The Control Layer
Java EE Pattern: The Control LayerJava EE Pattern: The Control Layer
Java EE Pattern: The Control Layer
 
Java EE Pattern: The Boundary Layer
Java EE Pattern: The Boundary LayerJava EE Pattern: The Boundary Layer
Java EE Pattern: The Boundary Layer
 
Java EE Pattern: Entity Control Boundary Pattern and Java EE
Java EE Pattern: Entity Control Boundary Pattern and Java EEJava EE Pattern: Entity Control Boundary Pattern and Java EE
Java EE Pattern: Entity Control Boundary Pattern and Java EE
 
Industry 4.0
Industry 4.0Industry 4.0
Industry 4.0
 
Big Data in Production Environments
Big Data in Production EnvironmentsBig Data in Production Environments
Big Data in Production Environments
 
BRO 110: Reference Architecture
BRO 110: Reference ArchitectureBRO 110: Reference Architecture
BRO 110: Reference Architecture
 
Bro110 5 1_software_architecture
Bro110 5 1_software_architectureBro110 5 1_software_architecture
Bro110 5 1_software_architecture
 
Work shop worldbank
Work shop worldbankWork shop worldbank
Work shop worldbank
 

Kürzlich hochgeladen

Das Biologiestudium an der Universität Duisburg-Essen
Das Biologiestudium an der Universität Duisburg-EssenDas Biologiestudium an der Universität Duisburg-Essen
Das Biologiestudium an der Universität Duisburg-Essen
Team Studienorientierung (Universität Duisburg-Essen)
 
Klimaabkühlung durch die CO2 Kanone, Konvektionskreislauf,Klimaabkühlung stat...
Klimaabkühlung durch die CO2 Kanone, Konvektionskreislauf,Klimaabkühlung stat...Klimaabkühlung durch die CO2 Kanone, Konvektionskreislauf,Klimaabkühlung stat...
Klimaabkühlung durch die CO2 Kanone, Konvektionskreislauf,Klimaabkühlung stat...
Wolfgang Geiler
 
Abortion Pills In Dubai☎️ "+971)555095267 " to buy abortion pills in Dubai, A...
Abortion Pills In Dubai☎️ "+971)555095267 " to buy abortion pills in Dubai, A...Abortion Pills In Dubai☎️ "+971)555095267 " to buy abortion pills in Dubai, A...
Abortion Pills In Dubai☎️ "+971)555095267 " to buy abortion pills in Dubai, A...
kylerkelson6767
 
Lehramt an der Universität Duisburg Essen
Lehramt an der Universität Duisburg EssenLehramt an der Universität Duisburg Essen
Lehramt an der Universität Duisburg Essen
Team Studienorientierung (Universität Duisburg-Essen)
 
Medizin an der Universität Duisburg - Essen
Medizin an der Universität Duisburg - EssenMedizin an der Universität Duisburg - Essen
Medizin an der Universität Duisburg - Essen
Team Studienorientierung (Universität Duisburg-Essen)
 
Psychologie an der Universität Duisburg-Essen
Psychologie an der Universität Duisburg-EssenPsychologie an der Universität Duisburg-Essen
Psychologie an der Universität Duisburg-Essen
Team Studienorientierung (Universität Duisburg-Essen)
 

Kürzlich hochgeladen (6)

Das Biologiestudium an der Universität Duisburg-Essen
Das Biologiestudium an der Universität Duisburg-EssenDas Biologiestudium an der Universität Duisburg-Essen
Das Biologiestudium an der Universität Duisburg-Essen
 
Klimaabkühlung durch die CO2 Kanone, Konvektionskreislauf,Klimaabkühlung stat...
Klimaabkühlung durch die CO2 Kanone, Konvektionskreislauf,Klimaabkühlung stat...Klimaabkühlung durch die CO2 Kanone, Konvektionskreislauf,Klimaabkühlung stat...
Klimaabkühlung durch die CO2 Kanone, Konvektionskreislauf,Klimaabkühlung stat...
 
Abortion Pills In Dubai☎️ "+971)555095267 " to buy abortion pills in Dubai, A...
Abortion Pills In Dubai☎️ "+971)555095267 " to buy abortion pills in Dubai, A...Abortion Pills In Dubai☎️ "+971)555095267 " to buy abortion pills in Dubai, A...
Abortion Pills In Dubai☎️ "+971)555095267 " to buy abortion pills in Dubai, A...
 
Lehramt an der Universität Duisburg Essen
Lehramt an der Universität Duisburg EssenLehramt an der Universität Duisburg Essen
Lehramt an der Universität Duisburg Essen
 
Medizin an der Universität Duisburg - Essen
Medizin an der Universität Duisburg - EssenMedizin an der Universität Duisburg - Essen
Medizin an der Universität Duisburg - Essen
 
Psychologie an der Universität Duisburg-Essen
Psychologie an der Universität Duisburg-EssenPsychologie an der Universität Duisburg-Essen
Psychologie an der Universität Duisburg-Essen
 

Architekturbewertung

  • 1. Copyright and all intellectual property belongs to Brockhaus Group 1 Architekturbewertung - einer Java Legacy Applikation Auszug aus der Ergebnisdokumentation
  • 2. 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 Copyright and all intellectual property belongs to Brockhaus Group 2
  • 3. 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 Copyright and all intellectual property belongs to Brockhaus Group 3
  • 4. 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. Copyright and all intellectual property belongs to Brockhaus Group 4
  • 5. 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] Copyright and all intellectual property belongs to Brockhaus Group 5
  • 6. 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 Copyright and all intellectual property belongs to Brockhaus Group 6
  • 7. 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, … Copyright and all intellectual property belongs to Brockhaus Group 7 Illustration 1: Umfeld von Referenzarchitekturen Illustration 2: Entstehen von Referenzarchitekturen
  • 8. 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] Copyright and all intellectual property belongs to Brockhaus Group 8 Illustration 3: Referenzarchitektur von Mocrosoft
  • 9. 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] Copyright and all intellectual property belongs to Brockhaus Group 9 Illustration 5: Änderbarkeit von Software im Zeitablauf
  • 10. 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] Copyright and all intellectual property belongs to Brockhaus Group 10 Illustration 6: Relation von Kosten und Verständlichkeit von Software
  • 11. 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] Copyright and all intellectual property belongs to Brockhaus Group 11
  • 12. 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] Copyright and all intellectual property belongs to Brockhaus Group 12
  • 13. 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 Copyright and all intellectual property belongs to Brockhaus Group 13
  • 14. 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 Copyright and all intellectual property belongs to Brockhaus Group 14
  • 15. 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 Copyright and all intellectual property belongs to Brockhaus Group 15
  • 16. 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. Copyright and all intellectual property belongs to Brockhaus Group 16
  • 17. 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 Copyright and all intellectual property belongs to Brockhaus Group 17
  • 18. 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. Copyright and all intellectual property belongs to Brockhaus Group 18
  • 19. 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 Copyright and all intellectual property belongs to Brockhaus Group 19
  • 20. 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. Copyright and all intellectual property belongs to Brockhaus Group 20
  • 21. 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 Copyright and all intellectual property belongs to Brockhaus Group 21
  • 22. [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/ Copyright and all intellectual property belongs to Brockhaus Group 22
  • 23. 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 Copyright and all intellectual property belongs to Brockhaus Group 23