Architekturmanagement in der Praxis - UZH

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


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


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


© C1 Group, 2008


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


© C1 Group, 2008


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


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


© C1 Group, 2008


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


Technische ProjektverantwortlicheQualitätsverantwortliche

Unterstützte ProgrammiersprachenJava, C#, C++

Soto-Werkzeugfamilie


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

Documents

Architekturmanagement in der Praxis - UZH