Software-Tomography GmbH © 2003 Dr. Walter Bischofberger1...we make the invisible visible...

Präsentation zum Thema: "Software-Tomography GmbH © 2003 Dr. Walter Bischofberger1...we make the invisible visible..."—  Präsentation transkript:

1 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger1...we make the invisible visible...

2 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger2 Inhalt n Patterns und Antipatterns n Automatisches Suchen von Antipatterns n Erfahrungen

3 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger3 Patterns und Antipatterns n Patterns o Muster wie man Software organisieren kann o -> Konstruktion n Antipatterns o Muster für verbreitete Fehler und Probleme o -> Analyse n Patterns und Antipatterns gibt es auf Code-, Mikroarchitektur- und Architekturebene

4 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger4 Code-Smells n Stil o Einrückungen o Namensgebung n Inkonsistenzen o JavaDoc entspricht strukturell nicht dem Quelltext n Schlecht wartbarer Code o Schlechtes Exceptionhandling o Duplizerter Code o Kompizierte boolsche Ausdrücke n Gefährlicher Code o Connections die nicht geschlossen werden

5 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger5 Bad-Smells (Mikroarchitektur) n Fehlende oder falsche Abstraktionen o Abstrahierbare Methoden- und Attributgruppen o Implementationsvererbung (Subklassen überschreiben nichts) o Vererbungshierarchie ohne polymorphe Zuweisungen n Kopplungs und Kohäsionsprobleme o Flaschenhälse o Zyklen auf Klasseneben o Law of Demeter o Typabfragen n Grössenprobleme o Zu grosse Klassen o Methoden mit duzenden von Parametern n Unbenutzte Artefakte o Klassen, Methoden, Attribute

6 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger6 Architektur-Smells n Quelltext enspricht nicht der Architektur o Architekturverletzungen durch illegale Beziehungen zwischen Artefakten n Kopplungs und Kohäsionsprobleme o Starke Kopplung, mangelnde Kohäsion o Zyklische Beziehungen zwischen Artefakten n Geschichte o Artefakte die über längere Zeiträume immer verändert werden o Artefakte an denen viele Entwickler gleichzeitig arbeiten n Anderes o Übergeneralisierung

7 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger7 Aufbau des Sotographen Java Parser Xref- Scope Metrics Scope SNiFF+ C/C++ Graph Scope Reposi- tory (RDBMS) Query Scope IDE Interaction Architecture Scope Query Developer Metrics & Transformation Engine Java Source Parser Repository Fill Interface Custom Fill Interfaces Component Structure EJB Analyzer CM Information

8 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger8 Analyse auf Symbolebene 500.000 LOC 50.000 Symbole

9 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger9 Analyse auf Klassen/Dateiebene 4.000 Klassen

10 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger10 Analyse auf Paket/Verzeichnisebene 250 Packages

11 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger11 Analyse auf Subsystemebene 20 Subsysteme

12 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger12 Subsystemschnittstellen

13 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger13 Schichtenarchitektur Illegale Benutzungsbeziehungen: Product Line 1Product Line 2 Layer 1 Layer 2 Layer 3 Interface Überspringen von Schichten (optional) Aufwärts- Benutzung: Immer illegal Abhängigkeit innerhalb einer Schicht (optional) Benutzung am Interface vorbei: Immer illegal

14 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger14 Zyklenbasierte Architekturanalyse n Wieso sind zyklische Beziehungen problematisch? o Artefakte die zyklisch gekoppelt sind können nicht einzeln getestet werden. o Artefakte die in verschiedenen Zyklen gebraucht werden spielen dabei häufig mehrere Rollen, was sie schlecht verständlich macht. o Artefakte die in verschiedenen Zyklen gebraucht werden können nicht mehr einfach ausgetauscht werden. n Erfahrung in grossen Projekten zeigt dass o Zyklen die Wartbarkeit deutlich verschlechtern o das Auflösen von Zyklen nicht mehr Wartbare Systeme wieder erweiterbar machen kann

15 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger15 Metrik- und regelbasierte Analyse n Arten o Architekturmetriken Z.B. Stabilitätsmetriken von Robert C. Martin o Grössen- und Kopplungsmetriken Z.B. Anzahl Klassen pro Package, Anzahl verwendeter Packages o Komplexitätsmetriken Z.B. Cyclomatic Complexity o Regeln Z.B eine Klasse darf die von ihr abgeleiteten Klassen nicht kennen o Bad Smells Z.B. Flaschenhälse, unbenutzte Artefakte

16 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger16 Metrik- und Regelbasierte Analyse n Schwierigkeiten o Sehr grosse Menge Messwerte Filtern o Verstehen der Ursache eines Messwerts Erklärungen Visualisierung im Kontext des Softwaresystems o Das Untersuchen einer Version genügt oft nicht Trend-Unterstützung o Definieren eigener Metriken Ermöglicht durch Einfaches Datenmodell im Repository

17 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger17 Erfahrungen aus der Praxis n Kurzanalysen durch uns o Ein halber Tag genügt um den Finger in die offenen Wunden zu legen. o Die Kunden sind sich dieser Ursachen ihrer Probleme häufig nicht bewusst. n Software Qualitätsanalyse durch Qualitätsberater o Sehr tiefgehende Qualitätsanalysen grosser, komplexer Softwaresysteme zwei Personenwochen Aufwand o Aufwand: Zwei Personenwochen versus 10 Personenwochen n Architektur-Reengineering bei einer Schweizer Grossbank o 2'000'000 LOC o Identifizierung des Problems o Überwachung der iterativen Verbesserung o Basisanalyse und Einarbeitung: drei Tage

18 Software-Tomography GmbH © 2003 Dr. Walter Bischofberger18 www.software-tomography.com Software-Tomography GmbH Cottbus, München, Zürich