Architekturbewertung

732 Aufrufe

Veröffentlicht am

Einführung in die Bewertung von Softwarearchitekturen

Veröffentlicht in: Bildung
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
732
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
53
Aktionen
Geteilt
0
Downloads
3
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Architekturbewertung

  1. 1. Copyright and all intellectual property belongs to Brockhaus Group 1 Architekturbewertung - einer Java Legacy Applikation Auszug aus der Ergebnisdokumentation
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×