Architekturmanagement in der Praxis

Transkript

1 Architekturmanagement in der Praxis Dr. Carola Lilienthal C1 WPS GmbH Tel: Inhalt Motivation Vergleich Soll- und Ist-Architektur Zyklenbasierte Analyse Architekturstile Metriken / Maße Trendanalyse Werkzeuge in der Praxis 1

2 ISO 9126 und Architekturanalyse Externe und Interne Qualität Funktionalität Effizienz Zuverlässigkeit Benutzbarkeit Wartbarkeit Portierbarkeit Eignung Verwendbarkeit Genauigkeit Interoperabilität Sicherheit Verstehbarkeit Erlernbarkeit Bedienbarkeit Attraktivität Reife Fehlertoleranz Ausfallsicherheit Datensicher- heit Zeitverhalten Resourcennutzung Analysierbarkeit Änderbarkeit Erweiterbarkeit Stabilität Testbarkeit Anpassbarkeit Installierbarkeit Ersetzbarkeit Konfigurierbarkeit Untersuchung der inneren Struktur eines Software-Produkts, um die Architektur zu verstehen und zu bewerten und dabei potenzielle Gefahren für die Qualität der Software und den zukünftigen (Weiter-)Entwicklungsprozesses aufzudecken. Architektur Erosion Softwaresysteme degenerieren: Zeitdruck führt zu Abkürzungen und Hacks. Verständnis/Wissen über das System ist ungleich im Team verteilt. Verletzungen der Architektur entstehen unbemerkt. Kopplungsgrad und Komplexität wachsen schneller als erwartet. Viele Architekturverletzungen sind manuell nicht zu erkennen. Die innere Softwarequalität ist dem Management nicht wichtig. Erodierte System sind schwer zu verstehen Erweiterungen erzeugen Seiteneffekte durch neue Fehler Kosten für Erweiterungsmaßnahmen steigen kontinuierlich an Seite 4 2

3 Maßnahmen gegen Erosion Refactoring und automatisches Testen Weiterbildung der Entwickler Codierungs- und Architekturrichtlinien Regelmäßige Architekturanalyse Inhalt Motivation Vergleich Soll- und Ist-Architektur Zyklenbasierte Analyse Architekturstile Metriken / Maße Trendanalyse Werkzeuge in der Praxis 3

4 Geplante und implementierte Architektur Findet sich die geplante Architektur (Soll-Architektur) in der Strukturen der implementierten Software (Ist-Architektur) wieder? Soll-Architektur Ist-Architektur Klasse Subsystem/ Komponente Quelltext Schicht Plan und Implementierung stimmen selten überein Neuentwicklung Wichtige Details wurden im Plan nicht beschrieben Der Plan wurde von den Entwicklern falsch verstanden Wegwerfprototypen werden zu Produkten ausgebaut Der Plan konnte aus Zeitdruck nicht umgesetzt werden Die fachlichen und technischen Anforderungen ändern sich Weiterentwicklung Software ist keine Prosa, die einmal geschrieben wird und dann unverändert bleibt. Software wird erweitert, korrigiert, gewartet, portiert, adaptiert, Diese Arbeit wird von unterschiedlichen Personen vorgenommen (manchmal über Jahrzehnte)

5 Architekturanalyse Soll Ist??? Weitgehend konsistente Struktur und Abhängigkeiten Geplante aber nicht vorhandene Architekturelemente und Abhängigkeiten ( Redundanz) Nicht geplante aber vorhandene Architekturelemente und Abhängigkeiten ( Verletzung) Zugriff auf Interna ( Schnittstellenverletzung) Ist-Architektur: Aggregation Subsystem I Subsystem A Klasse A.1 Subsystem II Subsystem C Klasse C.1 Klasse B.1 Klasse B.2 Subsystem B Subsystem I Subsystem A Aggregation Klasse D.1 Subsystem D Subsystem II Subsystem C Subsystem B Subsystem D Aggregation Subsystem I Subsystem II 5

6 Analyse von Schichten/Schnitten Produkt 1 Produkt 2 Verletzung der Subsystem-APIs: Immer illegal Abhängigkeit innerhalb einer Schicht (optional) Interface Illegale Benutzungsbeziehungen: LOC 3 Schichten Verfolgung illegaler Beziehungen: Zoomen bis in den Code Produkt 1 Produkt 2 Von Subsystemen Aufwärtsreferenz: Interface Immer Fachlogik illegal nach Packages/Directories i nach Verletzung der Klassen/Dateien Subsystem-APIs: Immer illegal nach Methoden/Funktionen bis zum Sprung in die entsprechende Source-Code-Stelle Aufwärtsreferenz: Immer illegal Abhängigkeit innerhalb einer Schicht (optional) Oberfläche Fachlogik Aufwärtsreferenz: Immer illegal Datenhaltung Oberfläche Datenhaltung Illegale Benutzungsbeziehungen: LOC 3 Schichten 6

7 Architekturanalyse Anforderungen Zerlegung in Teilsysteme Spezifizierte Abhängigkeiten und Schnittstellen Ist- Architektur Architektur- Entwurf Soll- Architektur Vergleich Differenz - Architektur Maßnahmen Rekonstruktion Übereinstimmungen Verletzungen Code Abbildungsvorschrift Sind Teilsysteme im Code repräsentiert? Werden Abhängigkeiten eingehalten? Werden Schnittstellen wie geplant genutzt? Abbildung der Soll- auf die Ist-Architektur Ist die Abbildung der Architektur im Code erkennbar? Module sollten sich anhand ihres Namens (Package-Name, Projektname) und/oder als Teil-Package-Bäume wiederfinden lassen. Schnittstellen von Modulen sollten ebenfalls auffindbar sein (z.b. Package api oder impl )

8 Sotoplatform Plattform für Sotographie Über 20 Jahren Erfahrung im Bereich objektorientierter Softwareprojekte und Datenbank- Design Kommerzielles Produkt seit 2002 Zusammenschluss mit Hello2Morrow/SonarJ in 2008 Viele Referenzkunden, u.a. Siemens, Lufthansa, HHLA, Kühle&Nagel, Daimler, Infineon Arbeitet Datenbank-gestützt Analysiert Java, C++, C# und bietet offene Schnittstelle für weitere Parser Architekturmodellierungskonzepte Eine Sotoarc-Architektur besteht aus einer Anzahl Module, die den Quellcode auf höherer Abstraktionsebene strukturieren. Module Enthalten Pakete oder wiederum Module Haben eine optionale Schnittstelle Drei Modularten Independent Subsysteme -> dürfen sich gegenseitig g g nicht verwenden Unrestricted Subsysteme -> keine architekturellen Restriktionen Schichten -> dürfen keine höheren Schichten verwenden Software-Tomography GmbH

9 Aufbau der Sotograph Plattform ModelManager Sotograph SotoArc Result Scope Query Scope C/C++ Parser Java Parser Repository Fill Interface Repository RDBMS Xref- Scope Graph Scope C# Parser CodeChecker Plugin Interface Metrics Scope DupliScope IDE Interaction PMD, CheckStyle FindBugs, Code Inspector,... SotoWeb SotoReport Eclipse, IntelliJ Idea, SNiFF+, Emacs, UltraEdit,... Software-Tomography GmbH 2008 Plattform: In Java entwickelt Repository: MySQL Ein etwas größeres Beispiel: Spring Spring AOP Source Level Metadata AOP Infrastructure Spring ORM Hibernate JDO support Spring DAO Transaction infrastructure JDBC, DAO Spring Web Web application context Spring Context Application context, UI, JNDI, EJB, Remoting, Mail, Validation Spring Web MVC MVC Framework Spring Core Beans Container, Supporting Utils LOC 583 Klassen 73 Packages 7 Subsysteme 9

10 Schichtenarchitektur von Spring LOC 583 Klassen 73 Packages 7 Subsysteme 5 Schichten Inhalt Motivation Vergleich Soll- und Ist-Architektur Zyklenbasierte Analyse Architekturstile Metriken / Maße Trendanalyse Werkzeuge in der Praxis 10

11 Zyklen und Zyklengruppen A B C D E F Ein Zyklus aus vier Knoten Eine Zyklengruppe aus sechs Knoten und mehreren einzelnen Zyklen Zyklenbasierte Architekturanalyse Wieso sind zyklische Beziehungen problematisch? Komponenten, die zyklisch gekoppelt sind, können nicht einzeln getestet werden. Komponenten, die in verschiedenen Zyklen gebraucht werden, spielen dabei häufig mehrere Rollen, was sie schlecht verständlich macht. Komponenten, die in verschiedenen Zyklen gebraucht werden, können nicht mehr einfach ausgetauscht werden. Ef Erfahrung in großen Projekten zeigt, dass Zyklen die Wartbarkeit deutlich verschlechtern das Auflösen von Zyklen nicht mehr wartbare Systeme wieder erweiterbar machen kann 11

12 Einfache Zyklengruppe 16 Klassen in einer Zyklengruppe, eine Beziehung (Zugriff auf zwei Konstanten) ist die Ursache das Auflösen dieser Zyklengruppe ist durch das Verschieben von zwei Konstanten möglich Schwierige Zyklengruppe Sieben Klassen in einer Zyklengruppe, mehrere direkte Zyklen zwischen Klassen das Auflösen dieser Zyklengruppe ist nur durch ein Refactoring der Klassen möglich 12

13 Zyklen auf verschiedenen Ebenen Klassenzyklus Package-Zyklus Package A Package B Package A Package B Class A Class C Class A Class C Class B Class D Class B Class D Subsystem-Zyklus Subsystem A Package A Subsystem B Package B Package C Subsystem C Package D Class A Class C Class D Class F Class B Class E Class G Inhalt Motivation Vergleich Soll- und Ist-Architektur Zyklenbasierte Analyse Architekturstile Metriken / Maße Trendanalyse Werkzeuge in der Praxis 13

14 Architekturstile Subsystemarchitektur [Bass et al. 2003] [Brügge /Dutroit 2004] Schichtenarchitektur [Fowler 2003] [Jacobson et al. 1999] [Siedersleben 2004] [Züllighoven 2005] Architekturstil Ein Architekturstil ist eine prinzipielle Lösungsstruktur, die für ein Softwaresystem Referenzarchitektur durchgängig und unter weitgehendem Verzicht auf Ausnahmen angewandt werden sollte. Erweiterte Schichtenarchitektur [Reussner et al. 2006] WAM Quasar Projekteigene Legende Schnittstelle Subsystem Schnittstelle Schicht Schnitt Erlaubte Beziehungen Elementart Zusammengesetzte Elementart Referenzarchitekturen: Stile auf der Klassen-Ebene WAM Quasar Komplexes Werkzeug T o o l Gui Interaktion Funktion Mono-Werkzeug Gui Monotool Service Material Fachwert Client Anwendungs- Fall Anwendungs- Entitätstyp- Verwalter Anwendungs- Entitätstyp Anwendungs- Datentyp Anwendungsfallkomponente Name Elementart Name Zusammengesetzte Elementart Erlaubte Benutzt-Beziehung 14

15 Zyklenfreiheit auf der Klassen-Ebene % Klassen in Zy yklen Referenzarchitektur 1 Schichtenarchitektur 2 Subsystemarchitektur 3 4 Auf Klassen-Ebene haben Referenzarchitekturen deutlich weniger Zyklen als andere Architekturstile. Klassenzyklen sind bei Schichten- und Subsystemarchitekturen oft nicht lokal Schichtenarchitektur WebServices 1 Ca LOCs Services 1 Tools 1 Client Services 2 Tools 2 Tools 3 Tools 4 Die Schichten spiegeln den Aufbau einer Client-Server- Architektur wieder: Anwendungen, Client, Server und Basis. WebServices 2 15

16 Ohne Referenzarchitektur: Chaos in Subsystemen 30% der Klassen sind in Klassenzyklen 60% der Packages sind in Zyklen Problem B Problem A BadSmell: God Class 98% der Klassen haben zu weniger als 10 Klassen Beziehungen Problem A kennt 21 Klassen und wird von 49 benutzt Problem B kennt 63 Klassen und wird von 18 Klassen benutzt Zyklenfreiheit auf Subsystem-Ebene % Subsysteme in Zyk klen Fallstudien Schichtenarchitektur Referenzarchitektur Subsystemarchitektur Auf Subsystem-Ebene haben Schichtenarchitekturen in der Messung die wenigsten Zyklen. Häufig werden zyklische Strukturen in den Subsystemen versteckt, besonders wenn Technologien eingesetzt werden, die Zyklenfreiheit erzwingen. 16

17 Der Zwang zur Zyklenfreiheit führt zu größeren Subsystemen 80% des Sourcecodes 9 Komponenten = 17 Subsysteme Inhalt Motivation Vergleich Soll- und Ist-Architektur Zyklenbasierte Analyse Architekturstile Metriken / Maße Trendanalyse Werkzeuge in der Praxis 17

18 Größenverhältnisse Ist das System auf den verschiedenen Ebenen ausgewogen? Welche Code-Abschnitte fallen durch ihre Größe besonders auf? Metriken: LOC pro Methode LOC pro File/Klasse Duplizierter Code Zyklomatische Komplexität (Anzahl der Pfade durch einzelne Prozeduren) Seite 35 Große Einheiten vermeiden Ein bekanntes Anti-Pattern - die Gott-Klasse : Sie ist für alles zuständig und hält 90% des Quelltextes. Methoden, die mehrere Bildschirmseiten lang sind, sind schlecht wartbar. Klassen mit mehreren hundert Methoden oder Exemplarvariablen sind meist zu groß! Wenn einzelne Einheiten zu groß werden, ist dies ein Hinweis auf niedrige Kohäsion: Wenn eine Einheit sehr viele Aufgaben erfüllt, erfüllt sie vermutlich zu viele Aufgaben. 18

19 Code-Duplizierung vermeiden Wenn ein Stück Quelltext in identischer Form an mehreren Stellen eines Systems definiert ist, sprechen wir von Code-Duplizierung. Code-Duplizierung ist problematisch, weil üblicherweise an einer Stelle nicht erkennbar ist, an welchen anderen Stellen derselbe Quelltext erscheint, und Änderungen an einem der Duplikate eventuell auch an allen anderen Duplikaten ausgeführt werden müssen; dies kann bei der Wartung übersehen werden. Kopien, speziell wenn sie noch leicht angepasst sind, das Testen kompliziert machen. Code-Duplizierung ist ein Zeichen niedriger Kohäsion: Wenn zwei Einheiten dieselbe (Teil-)Aufgabe erledigen, ist bei mindestens einer von beiden die Zuständigkeit falsch zugeordnet. Kopplungsgrad Ist das System auf den verschiedenen Ebenen lose gekoppelt? Welche Code-Abschnitte fallen durch besonders viele Beziehungen auf? BadSmell: Bottleneck 19

20 Inhalt Motivation Vergleich Soll- und Ist-Architektur Zyklenbasierte Analyse Architekturstile Metriken / Maße Trendanalyse Werkzeuge in der Praxis Analyse der Systemevolution Kontinuierliche / wiederholte Anwendung der vorgestellten Analysen auf ein sich entwickelndes System Ermöglicht Verfolgen von Qualitätstrends Entscheidungen lassen sich aufgrund von Trendbeobachtungen oft besser fällen als für Punktbeobachtungen (Soll-Richtung der Werteentwicklung meist bekannt, aber keine absoluten Schranken) Problem: richtige Bewertung des Trends relativ zum Systemwachstum 20

21 Trend: Architekturvergleich Trend über die Zeit? Realisierte i Architekturen Zeit Version 1 Version 2 Version 3 Probleme: Veränderung der Ist- Architektur und deren Abbildung auf Soll- Architektur (Umstrukturierungen, Umbenennungen etc.) Bewertung des Systemwachstums Geplante Architektur Beispiel: ArgoUML Time Anzahl Verletzungen argouml0156 argouml0161 argouml

22 Beispiel: ArgoUML Time 5,00 4,72 Violations Verletzungen per pro ,50 4,23 4,22 LOC Normalisierung 4,00 Verletzungen pro der Verletzungen 3,50 Violations per 100 Klassen classes gegen 3,00 2,94 Größenmaße 263 2,63 2,50 2,57 Violations Verletzungen per pro ,41 2,19 2,22 references Referenzen 2,00 1,66 1,68 1,80 1,50 Violations Verletzungen per pro ,00 1,17 1,17 1,10 layer-crossing Schicht-übergreifenden references Referenzen 0,50 Violations Verletzungen total absolut 0,00 argouml0156 argouml0161 argouml0171 Inhalt Motivation Vergleich Soll- und Ist-Architektur Zyklenbasierte Analyse Architekturstile Metriken / Maße Kriterien für die Analyse Trendanalyse Werkzeuge in der Praxis 22

23 Lattix Amerikanisches Firma, unterstützt vom MIT DSM-Theorie = Dependency oder Design Structure Matrix Kommerzielles Produkt seit 2004 Große Kunden: EMC, Ericsson. Invensys, PTC and Virtusa Arbeitet im Hauptspeicher Analyse von Java und C/C++, Ada Matrixdarstellung Kopplungsanalyse mit Hilfe von Matrix-Visualisierungen Legt mehr Gewicht auf Aussagen über Beziehungen als Strukturdarstellung Paarweise Gegenüberstellung der Subsysteme Feld A:B gibt Auskunft über die Intensität der Kopplungen zwischen A und B A B A Referenzen A A Referenzen A B B Referenzen B A Referenzen B B 23

24 Ablesbare Architekturzustände Schichtenarchitektur ht hit Strenge Schichtenarchitektur (Jede Schicht benutzt ausschließlich die direkt darunterliegende Schicht.) Schichtenarchitektur mit Verletzungen (Die util-schicht benutzt die application und die model-schicht.) Definition von Architekturregeln Grüne Markierung: Erlaubte Beziehung Gelbe Markierung: Verbotene Beziehung Rote Markierung: Verletzte Beziehung 24

25 Sotoarc Anwendungsfälle Architekturmodellierung und überprüfung Simulation und Planung von Restrukturierungen Verstehen von Softwaresystemen Zyklenanalyse auf verschiedenen Abstraktionsebenen Zielgruppen Software-Architekten Technische h Projektverantwortliche t tli Qualitätsverantwortliche Unterstützte Programmiersprachen Java, C#, C++ Software-Tomography GmbH 2008 Soto-Werkzeugfamilie Software-Tomography GmbH

26 Das Vorgehen Ihr System Natürliche Subsysteme User Interface Business Logic Contracts Customer User Common Data Access Schritt 1: Horizontale Aufteilung in Layers Schritt 2: Vertikale Aufteilung in fachliche Schnitte Schritt 3: Definition erlaubter Benutzungsbeziehungen Beispiel: Schichten und Schnitte LOC 507 Klassen 90 Packages 8 Subsysteme 3 Schichten 4 Produkte 26

27 Wie helfen Analysewerkzeuge bei der Qualitätssicherung? Sichtbar machen der Ist-Architektur erlaubt Einblicke oberhalb des Programmtexts Soll-Architektur definieren Soll- und Ist-Architektur vergleichen Zyklen werden auf allen Ebenen sichtbar und lassen sich mit Hilfe der Analysewerkzeuge untersuchen Die Analysewerkzeuge macht Probleme sichtbar: 2-3 Problem-Artefakte machen den meisten Ärger Die dunklen Ecken sind den Entwicklern meistens bekannt Gute Ergebnisse geben Bestätigung und stärken Vertrauen in den Code Frühzeitige und kontinuierliche Untersuchungen bewahren die Systeme vor dem Zerfall Refactoring-Vorschläge erarbeiten Qualitätssicherung mit der Sotoplatform Kurzanalysen Ein Tag genügt um den Finger in die offenen Wunden zu legen. Die Entwickler sind sich ihrer Probleme aber nicht der Ursachen bewusst. Software-Qualitäts-Analyse durch Qualitätsberater Sehr tiefgehende Qualitäts-Analysen großer, komplexer Softwaresysteme zwei Personenwochen Aufwand Expertenwissen notwendig Kontinuierliche Qualitätsüberwachung Qualitätssicherung Mit kleinem wöchentlichen Aufwand möglich Basisanalyse und Einarbeitung: 2-3 Tage Architekturstil Pair Programming Architekturreviews Projektreviews Unit-Tests Akzeptanztests Live Tests Lasttests 27

28 Vielen Dank für Ihre Aufmerksamkeit!