architekturmanagement in der praxis - uzh
TRANSCRIPT
1
Architekturmanagement in der Praxis
Dr. Carola LilienthalC1 WPS GmbH
@[email protected]: +49 170 184 77 11
Inhalt
• Motivation• Vergleich Soll und Ist Architektur• Vergleich Soll- und Ist-Architektur• Zyklenbasierte Analyse• Architekturstile• Metriken / Maße• Trendanalyse• Werkzeuge in der Praxis
© C1 Group, 2008
Werkzeuge in der Praxis
2
ISO 9126 und Architekturanalyse
Externe undInterneQualität
Funktiona-lität
Eignung
Verwendbar-keit
Genauigkeit
Interoperabilität
Zuverlässig-keit
Benutz-barkeit
Effizienz Wartbar-keit
Portier-barkeit
Reife
Fehlertoleranz
Ausfallsicher-heit
Datensicher-
Verstehbarkeit
Erlernbarkeit
Bedienbarkeit
Attraktivität
Zeitver-halten
Resourcen-nutzung
Analysier-barkeit
Änderbarkeit
Erweiterbar-keit
Anpassbar-keit
Installierbar-keit
Ersetzbarkeit
© C1 Group, 2008
Interoperabilität
Sicherheit
Datensicherheit Stabilität
Testbarkeit
Konfigurier-barkeit
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.
© C1 Group, 2008 Seite 4
• 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
14.11.2008
3
Maßnahmen gegen Erosion
• Refactoring und automatisches Testen• Weiterbildung der Entwickler• Codierungs- und Architekturrichtlinien• Regelmäßige Architekturanalyse
© C1 Group, 2008
Inhalt
• Motivation• Vergleich Soll- und Ist-Architektur• Vergleich Soll- und Ist-Architektur• Zyklenbasierte Analyse• Architekturstile• Metriken / Maße• Trendanalyse• Werkzeuge in der Praxis
© C1 Group, 2008
Werkzeuge in der Praxis
4
Geplante und implementierte Architektur
Findet sich die geplante Architektur (Soll-Architektur) in der Strukturen der implementierten Software (Ist-Architektur) wieder?
KlasseSubsystem/Komponente
Soll-Architektur Ist-Architektur
≠
© C1 Group, 2008 29.01.2009
Quelltext
Schicht
≠
Plan und Implementierung stimmen selten überein
Neuentwicklung• Wichtige Details wurden im Plan nicht beschriebeng• 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
© C1 Group, 2008 29.01.2009
• 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
IstSoll
?
??
• Weitgehend konsistente Struktur und Abhängigkeiten
?
© C1 Group, 2008
• Zugriff auf Interna ( Schnittstellenverletzung)
• Geplante aber nicht vorhandene Architekturelemente und Abhängigkeiten ( Redundanz)
• Nicht geplante aber vorhandene Architekturelemente und Abhängigkeiten ( Verletzung)
Ist-Architektur: Aggregation
Subsystem II
Subsystem C
Klasse C.1
Subsystem I
Subsystem A
Klasse A.1
Subsystem DKlasse D.1
Aggregation
Subsystem II
Subsystem C
Subsystem I
Subsystem A
Subsystem B
Klasse B.1
Klasse B.2
© C1 Group, 2008
Subsystem IISubsystem I
Aggregation
Subsystem DSubsystem B
6
Produkt 1 Produkt 2
Ober-flächeAbhängigkeit
innerhalb einer
Analyse von Schichten/Schnitten
Fach-logik
Interface
Aufwärts-referenz:
innerhalb einer Schicht (optional)
Verletzung derSubsystem-APIs:Immer illegal
© C1 Group, 2008
Daten-haltung
Immer illegal
Illegale Benutzungsbeziehungen:500.000 LOC 3 Schichten
Produkt 1 Produkt 2
Ober-flächeAbhängigkeit
innerhalb einer
Von Subsystemen
h P k /Di t i
Verfolgung illegaler Beziehungen:Zoomen bis in den Code
Fach-logik
Interface
Aufwärts-referenz:
Verletzung derSubsystem-APIs:Immer illegal
innerhalb einer Schicht (optional)
nach Packages/Directories
nach Klassen/Dateien
nach Methoden/Funktionen
bis zum Sprung in die entsprechendeSource-Code-Stelle
Aufwärts-referenz: Immer illegal
© C1 Group, 2008
500.000 LOC 3 Schichten
Daten-haltung
Immer illegal
Illegale Benutzungsbeziehungen:
7
Architekturanalyse
Anforderungen
• Zerlegung in Teilsysteme
„Differenz“-Architektur
Vergleich Maßnahmen
• Übereinstimmungen• Verletzungen
Ist-Architektur
Rekonstruktion
Architektur-Entwurf
Soll-Architektur
• Zerlegung in Teilsysteme• Spezifizierte Abhängigkeiten und Schnittstellen
© C1 Group, 2008
Verletzungen
Sind Teilsysteme im Code repräsentiert?Werden Abhängigkeiten eingehalten?Werden Schnittstellen wie geplant genutzt?
Abbildungs-vorschrift
Architektur
Code
Abbildung der Soll- auf die Ist-Architektur
© C1 Group, 2008 29.01.2009
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-DesignKommerzielles Produkt seit 2002Zusammenschluss mit Hello2Morrow/SonarJ in 2008Viele Referenzkunden, u.a.
© C1 Group, 2008
,Siemens, Lufthansa, HHLA, Kühle&Nagel, Daimler, InfineonArbeitet Datenbank-gestütztAnalysiert Java, C++, C# und bietet offene Schnittstelle für weitere Parser
www.hello2morrow.de
Architekturmodellierungskonzepte
Eine Sotoarc-Architektur besteht aus einer Anzahl Module, die den Quellcode auf höherer Abstraktionsebene strukturieren.ModuleModule
Enthalten Pakete oder wiederum ModuleHaben eine optionale Schnittstelle
Drei Modularten
Independent Subsysteme-> dürfen sich gegenseitig nicht verwenden
Software-Tomography GmbH © 2008
Schichten -> dürfen keine höheren Schichten verwenden
Unrestricted Subsysteme -> keine architekturellen Restriktionen
g g g
9
Aufbau der Sotograph Plattform
ResultScope
ModelManager
SotoArc
Sotograph
Xref-Scope
GraphScope
Reposi-tory
RDBMS
QueryScope
p
C/C++ Parser
C#P
JavaParser
RepositoryFill Interface
Software-Tomography GmbH © 2008
Metrics Scope
SotoWebSotoReport
Plattform: In Java entwickeltRepository: MySQL
IDE Interaction
Eclipse, IntelliJ Idea,SNiFF+, Emacs,
UltraEdit,...
ParserCodeChecker
Plugin Interface
PMD, CheckStyleFindBugs,
Code Inspector, ...
DupliScope
Ein etwas größeres Beispiel: Spring
Spring AOPSource Level
MetadataAOP Infrastructure
Spring Web MVC
MVC FrameworkSpring DAOTransaction
infrastructureJDBC, DAO
Spring ORMHibernate
JDO support
Spring WebWeb application
context
Spring ContextApplication context, UI, JNDI,
EJB, Remoting, Mail, Validation
50.547 LOC 583 Klassen 73 Packages 7 Subsysteme
Spring CoreBeans Container, Supporting Utils
JDBC, DAO Validation
10
Schichtenarchitektur von Spring
50.547 LOC 583 Klassen 73 Packages 7 Subsysteme 5 Schichten
Inhalt
• Motivation• Vergleich Soll und Ist Architektur• Vergleich Soll- und Ist-Architektur• Zyklenbasierte Analyse• Architekturstile• Metriken / Maße• Trendanalyse• Werkzeuge in der Praxis
© C1 Group, 2008
Werkzeuge in der Praxis
11
Zyklen und Zyklengruppen
A B
C D
FE
© C1 Group, 2008
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 ausgetauschtwerden.
E f h i ß P j kt i t d
© C1 Group, 2008
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
12
Einfache Zyklengruppe
© C1 Group, 2008
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
© C1 Group, 2008
Sieben Klassen in einer Zyklengruppe, mehrere direkte Zyklen zwischen Klassen
das Auflösen dieser Zyklengruppe ist nur durch ein Refactoring der Klassen möglich
13
Zyklen auf verschiedenen Ebenen
Package-Zyklus
Package A Package B
Class A Class C
KlassenzyklusPackage A Package B
Class A Class C
Class B Class DClass B Class D
Subsystem-Zyklus Subsystem BSubsystem A
Subsystem C
© C1 Group, 2008
Package B Package C
Class C Class D
Class E
Subsystem APackage A
Class A
Class B
Package D
Class F
Class G
Inhalt
• Motivation• Vergleich Soll und Ist Architektur• Vergleich Soll- und Ist-Architektur• Zyklenbasierte Analyse• Architekturstile• Metriken / Maße• Trendanalyse• Werkzeuge in der Praxis
© C1 Group, 2008
Werkzeuge in der Praxis
14
Architekturstile
SubsystemarchitekturSchichtenarchitektur
[Bass et al. 2003] [Brügge /Dutroit 2004]
[Fowler 2003][Jacobson et al. 1999]
[Siedersleben 2004]
Erweiterte Schichtenarchitektur
Referenzarchitektur
[ ][Züllighoven 2005]
Architekturstil„Ein Architekturstil ist eine prinzipielle Lösungsstruktur, die für ein Softwaresystem durchgängig und unter weitgehendem Verzicht auf Ausnahmen angewandt werden sollte.“
© C1 Group, 2008
Erlaubte Beziehungen Elementart Zusammengesetzte
Elementart
Legende
Subsystem
SchnittstelleSchicht
SchnittstelleSchnittSchnitt
WAMQuasarProjekteigene
[Reussner et al. 2006]
QuasarWAM
Referenzarchitekturen: Stile auf der Klassen-Ebene
Client
Komplexes WerkzeugMono-Werkzeug
Monotool
Gui
Funktion
Interaktion
Gui
Service
Tool
Anwendungs-Entitätstyp-Verwalter
Anwendungs-Fall
© C1 Group, 2008
Fachwert
Material
Anwendungsfallkomponente
Anwendungs-Datentyp
Anwendungs-Entitätstyp
Erlaubte Benutzt-BeziehungName Elementart Name Zusammengesetzte Elementart
15
Zyklenfreiheit auf der Klassen-Ebene
60
70
80
ykle
n
0
10
20
30
40
50
0 1 2 3 4Referenzarchitektur Schichtenarchitektur Subsystemarchitektur
% K
lass
en in
Zy
© C1 Group, 2008 29.01.2009
y
Auf Klassen-Ebene haben Referenzarchitekturendeutlich weniger Zyklen als andere Architekturstile.Klassenzyklen sind bei Schichten- und Subsystem-architekturen oft nicht lokal.
WebServices 1Ca. 200.000 LOCs
Schichtenarchitektur
Die Schichten spiegeln den Aufbau
Services 2
Tools 1
Tools 2
Tools 3
Services 1
Client
© C1 Group, 2008
spiegeln den Aufbau einer Client-Server-Architektur wieder: Anwendungen, Client, Server und Basis.
Tools 4
WebServices 2
16
Ohne Referenzarchitektur:Chaos in Subsystemen30% der Klassen sind in Klassenzyklen60% der Packages sind in Zyklen
Problem A
Problem B
© C1 Group, 2008
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
70
80
90
100
klen
0
10
20
30
40
50
60
% S
ubsy
stem
e in
Zyk
Schichtenarchitektur Referenzarchitektur Subsystemarchitektur
10 Fallstudien
© C1 Group, 2008
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.
y
17
Der Zwang zur Zyklenfreiheit führt zu größeren Subsystemen
© C1 Group, 2008 29.01.2009
80% des Sourcecodes
9 Komponenten = 17 Subsysteme
Inhalt
• Motivation• Vergleich Soll und Ist Architektur• Vergleich Soll- und Ist-Architektur• Zyklenbasierte Analyse• Architekturstile • Metriken / Maße• Trendanalyse• Werkzeuge in der Praxis
© C1 Group, 2008
Werkzeuge in der Praxis
18
Größenverhältnisse
• Ist das System auf den verschiedenen Ebenen ausgewogen?• Welche Code-Abschnitte fallen durch ihre Größe besonders auf?
© C1 Group, 2008 Seite 35
Metriken:• LOC pro Methode• LOC pro File/Klasse• Duplizierter Code • Zyklomatische Komplexität (Anzahl der Pfade durch einzelne Prozeduren)
29.01.2009
Große Einheiten vermeiden
• Ein bekanntes Anti-Pattern - die „Gott-Klasse“:• Sie ist für alles zuständig und hält 90%
des Quelltextesdes Quelltextes.
• Methoden, die mehrere Bildschirmseiten lang sind, sind schlecht wartbar.
• Klassen mit mehreren hundert Methoden oder Exemplarvariablensind meist zu groß!
Wenn einzelne Einheiten zu groß werden ist dies ein Hinweis auf
© C1 Group, 2008
• 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.
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
© C1 Group, 2008
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?
© C1 Group, 2008
BadSmell: Bottleneck
20
Inhalt
• Motivation• Vergleich Soll und Ist Architektur• Vergleich Soll- und Ist-Architektur• Zyklenbasierte Analyse• Architekturstile• Metriken / Maße• Trendanalyse• Werkzeuge in der Praxis
© C1 Group, 2008
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
© C1 Group, 2008
Punktbeobachtungen (Soll Richtung der Werteentwicklung meist bekannt, aber keine absoluten Schranken)
• Problem: richtige Bewertung des Trends relativ zum Systemwachstum
21
Trend: Architekturvergleich
R li i t A hit ktTrend über die Zeit?
ZeitVersion 1 Version 2 Version 3
Realisierte Architekturen
Probleme:
• Veränderung der Ist-
© C1 Group, 2008
Geplante Architektur
Architektur und deren Abbildung auf Soll-Architektur (Umstrukturierungen, Umbenennungen etc.)
• Bewertung des Systemwachstums
Beispiel: ArgoUML
Time0.156 0.161 0.171
241
230
235
240
245
© C1 Group, 2008
219222
205
210
215
220
225
argouml0156 argouml0161 argouml0171
Anzahl Verletzungen
22
Beispiel: ArgoUML
Time0.156 0.161 0.171
4,23 4,22
4,72
2 632,943,00
3,50
4,00
4,50
5,00Verletzungen pro 1000LOC
Verletzungen pro 10Klassen
V l t 1000
Normalisierungder VerletzungengegenG öß ß
Violations per 1000 LOC
Violations per 100 classes
© C1 Group, 2008
1,17 1,17 1,10
1,66 1,68 1,80
2,63 2,572,19 2,22
2,41
0,00
0,50
1,00
1,50
2,00
2,50
argouml0156 argouml0161 argouml0171
Verletzungen pro 1000Referenzen
Verletzungen pro 100Schicht-übergreifendenReferenzenVerletzungen absolut
Größenmaße Violations per 1000 references
Violations per 100 layer-crossing referencesViolations total
Inhalt
• Motivation• Vergleich Soll und Ist Architektur• Vergleich Soll- und Ist-Architektur• Zyklenbasierte Analyse• Architekturstile• Metriken / Maße• Kriterien für die Analyse• Trendanalyse
© C1 Group, 2008
Trendanalyse• Werkzeuge in der Praxis
23
Lattix
• Amerikanisches Firma• Amerikanisches Firma, unterstützt vom MIT
• DSM-Theorie = Dependency oder Design Structure Matrix
• Kommerzielles Produkt seit 2004
• Große Kunden: EMC, Ericsson Invensys PTC
© C1 Group, 2008
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 Referenzen
© C1 Group, 2008
A Referenzen A A
Referenzen A B
B Referenzen B A
Referenzen B B
24
Ablesbare Architekturzustände
S hi ht hit kt
Strenge Schichtenarchitektur
(Jede Schicht benutzt ausschließlich die direkt darunterliegende Schicht.)
Schichtenarchitektur
© C1 Group, 2008
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• Gelbe Markierung: Verbotene Beziehung• Rote Markierung: Verletzte Beziehung
© C1 Group, 2008
25
Sotoarc
AnwendungsfälleArchitekturmodellierung und –überprüfungArchitekturmodellierung und überprüfungSimulation und Planung von RestrukturierungenVerstehen von SoftwaresystemenZyklenanalyse auf verschiedenen Abstraktionsebenen
ZielgruppenSoftware-ArchitektenT h i h P j kt t tli h
Software-Tomography GmbH © 2008
Technische ProjektverantwortlicheQualitätsverantwortliche
Unterstützte ProgrammiersprachenJava, C#, C++
Soto-Werkzeugfamilie
Software-Tomography GmbH © 2008
26
Ihr System
Das Vorgehen
Ihr System
User Interface
Business Logic
Data Access
Contr
acts
Cust
om
er
Use
r
Com
mon
Natürliche Subsysteme
© C1 Group, 2008
• Schritt 1: Horizontale Aufteilung in Layers
• Schritt 2: Vertikale Aufteilung in fachliche Schnitte
• Schritt 3: Definition erlaubter Benutzungsbeziehungen
Beispiel: Schichten und Schnitte
© C1 Group, 200860.000 LOC 507 Klassen 90 Packages 8 Subsysteme 3 Schichten 4 Produkte
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
G t E b i b B täti d tä k V t i d
© C1 Group, 2008
• 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 notwendigKontinuierliche Qualitätsüberwachung
• Mit kleinem wöchentlichen Aufwand ö li h
QualitätssicherungArchitekturstil
© C1 Group, 2008
möglich• Basisanalyse und Einarbeitung:
2-3 Tage
Pair ProgrammingArchitekturreviewsProjektreviewsUnit-TestsAkzeptanztestsLive TestsLasttests
28
Vielen Dank für Ihre Aufmerksamkeit!
29.01.2009