Sotograph Enrico Eczko Testen von Software Sommersemester 2006 2005-12-31

Gliederung 1. Allgemeines 2 Programmumfang 3. Prgrammstruktur 4. Grundlegender Aufbau des Programms 5. Programmaufbau im Detail - Modellbildung - GraphScope - MetricScope - ResultScope - TrendMetricScope 6. Beispiel

Allgemeines zum Sotograph Tomograph zur Softwareanalyse = Softwaretomograph (Sotograph)

Allgemeines Unter den mittleren und großen Unternehmen aus unterschiedlichen Branchen in den USA scheitern schätzungsweise 31% aller Softwareprojekte. So werden Jährlich rund 81 Milliarden Dollar für gescheiterte Softwareprojekte ausgegeben. Softwarepanne kostet BA schon 200 Millionen Euro Arbeitsagentur überweist zu viel an Kassen. Hartz IV-Software: 28 Millionen Euro Schaden Autobahnmaut 16 Monate Verspätung Statistikämter verschwenden Millionen für Software und IT - zwölf Entwicklungsjahre Informationssystem "Genesis" befindet sich noch immer im Probebetrieb - 700.000 € geplant, statt dessen über 10 Millionen € ausgegeben Auswahl einiger Anwender: - Credit Suisse - DaimlerChrysler - Siemens - Deutsche Post IT Solutions - Dresdner Bank - Hamburger Hafen- und Lagerhaus AG - T-Systems - Telekom Austria - Fiducia IT AG - Berater: c1-wps, SQS, SCCH

Allgemeines Funktionen - Software-Architekturvalidierung - Grafische Darstellung der Analyseergebnisse - Zentrales Repository für alle Analysedaten - Auffinden zyklischer Abhängigkeiten - Doppelte Code-Analyse - Zusatzmodul webbasierte Reporting-Engine - 300 vordefinierte Analyse-Abfragen, Metriken, Codierungsregeln Qualitätsmodelle - Mächtige Query-Engine für projektspezifische Analysen - Trend Monitoring zeigt Veränderungen für verschiedene Versionsstände - Hohe Analyse-Performance auch für sehr grosse Softwaresysteme

Allgemeines Szenarios gründliche Qualitätsanalyse: - Analyse eines mittleren Softwaresystems braucht eine bis mehrere Personenwochen und setzt Expertenwissen voraus - Metriken werden genutzt um wichtige Elemente für die weitere Analyse zu identifizieren - starke Nutzung der Visualisierungsmöglichkeiten - wird normalerweise von speziellen Qualitätsberatern durchgeführt Kurzanalyse: Grundlegende Problemanalyse eines Softwaresystems, benötigt ein bis zwei Tage - Überprüfung ob der Systemzustand mit der geplanten Architektur übereinstimmt - Suche nach Zyklen und doppelten Code - Große, komplexe Artefakte identifizieren, welche zu Architekturproblemen führen könnten - Prüfung der source code Qualität auf der Basis von Programmierregeln

Allgemeines Szenarios Kontinuierliche Qualitätsüberwachung Ständige Qualitätsüberwachung, bei der Regeln genutzt werden um in kürzester Zeit neue Probleme in der Architektur und im Code zu erkennen. Wöchentliche Überwachung braucht zwischen 15 und 30 Minuten - Programmierregeln sollten ständig von den Entwicklern in ihren IDEs überprüft werden - Sotograph sorgt nur dafür, dass dies nicht von den Entwicklern vergessen wird - Architekturverletzungen sollten von einem technischen Projektleiter überwacht - sollte möglichst früh zum Einsatz kommen, denn eine frühe Erkennung von Fehlentwicklungen spart Geld

Programmstruktur

Datenbank anlegen

Von Sotograph unterstützte Abstraktionslevel Strukturkonzepte sind die zentrale Vorbereitung für eine erfolgreiche Analyse großer Softwaresysteme. Source files: - sind die atomaren Grundlagen, höhere Abstraktionen bauen auf ihnen auf - werden in der Regel nicht zur Analyse verwendet Files: - sind aggregierte source files, in Java sind diese identisch - C/ C++ in Header und Implementation geteilt, werden gruppiert Package: - werden in Java direkt übernommen, in C/ C++ aus der Directory Struktur abgeleitet Subsysteme: - Abstraktion auf Paket-Ebene noch zu feingranular bei großen Projekten - Pakete werden zu Subsystemen zusammengefasst Architecture: - klare Richtlinien wie Subsysteme sich gegenseitig nutzen dürfen - zum Prüfen ob festgelegte Designs eingehalten werden - unterstützt Schichten- und Grapharchitekturen

Programmaufbau

Programmaufbau im Detail Modellbildung - Paket- und die Subsystemebene lassen sich flexibel modellieren - kann in Form von Architekturmodellen beschreiben wie Subsysteme zusammenarbeiten - ModelManager dient dazu, diese drei Ebenen der logischen Modellierung zu definieren - Architekturmodelle beschreiben Sollarchitekturen - Sotograph kann automatisch prüfen, an welchen Stellen eine vorgegebene Sollarchitektur verletzt wird

Programmaufbau im Detail Graphscope Arbeiten mit dem GraphScope - Überblick über das System zu verschaffen - Ergebnisse aus dem Resultscope markieren oder einfügen - Zyklen, Interfaces, Architekturverstöße markieren Graphlayouts Topologielayout: Sortierung der Knoten nach Benutzung Links werden die benutzenden Knoten abgebildet Rechts die eher benutzten Knoten „spring embedder“ Layout: ordnet die Knoten nach einem physikalischen Modell an Kanten werden als Federn betrachtet, die je nach Dicke eine unterschiedliche Zugkraft haben Knoten ohne verbindende Pfeile stoßen sich ab Leicht erkennbar, welche Knoten zentrale Elemente sind (stark gekoppelt) Architektur Layout: - ordnet Knoten nach einem vorher definierten Architekturmodell

Programmaufbau im Detail MetricScope Arbeiten mit dem Metricscope - ermöglicht die Analyse eines Softwaresystems mit Hilfe von Metriken und Regeln - Unterscheidung interne vs externe Softwarequalität Externe: - bestimmt durch Qualitätsaspekte, die der Endnutzer wahrnimmt Interne: - bestimmt durch Wartbarkeit einer Applikation, strukturelle Aspekte - Einhalten der geplanten Architektur und vorgegebener Code-Level

Programmaufbau im Detail MetricScope Rules: - definieren Bedingungen, die erfüllt werden müssen, Verletzungen sind meist Fehler - Unterscheidung zwischen Architektur- und Programmierregeln Architektur: - keine durch das Architekturmodel verbotenen Referenzen - Keine Interface-Verletzungen - zirkuläre Abhängigkeiten zwischen Artefakten sollten vermieden werden - Vervielfältigung großer Codesegmente soll vermieden werden Programmierregeln: - diverse Arten von Exception-Behandlungsroutinen, wie leere Catch-Blöcke - Überprüfung projektspezifischer Namensgebung, Formatierung und Dokumentierung Measures - helfen eventuell problematische Strukturen auf allen Abstraktions-Level zu finden - in der Literatur oftmals Metriken genannt - im Gegensatz zu Rules nicht so eindeutig, gutes Systemverständnis und viel Analyse sind notwendig - wird empfohlen um große, stark vernetzte Strukturen zu identifizieren

Programmaufbau im Detail ResultScope - Ergebnisse von Analysen werden im ResultScope angezeigt - Ausgangspunkt für graphische Darstellung - Möglichkeit sich bis auf die niedrigste Ebene „durchzuhangeln“, um den Sourcecode zu betrachten

Programmaufbau im Detail TrendMetricScope - funktioniert analog zu dem Werkzeug MetricScope, liefert ebenfalls Metrikwerte - diese sind allerdings zusätzlich im Vergleich für zwei verschiedene Versionsstände des zu untersuchenden Softwaresystems dargestellt Grundlegende Idee: - Entwicklung des Systems regelmäßig und dauerhaft beobachten Mit ein paar Minuten Arbeit pro Woche frühzeitig gefährliche Entwicklungstrends entdecken Software veränderungs- Szenarios - Reguläres Wachstum - Augenmerk liegt auf der Entwicklung. - wöchentliche Änderungen der logischen Modelle - Sanierung - folgen meistens auf Wachstums-Phasen, korrigieren starke Abweichungen von den Architekturmodellen - häufigere Änderung der logischen Modelle - Restrukturierung - sehr selten, - falls sich die Anforderungen so stark geändert haben, dass die Architektur angepasst werden muss

Beispiel Untersuchung eines unbekannten Systems JHotDraw - freies, Java-basiertes Rahmenwerk zur Erstellung von grafischen Editoren - UML-Editoren, Workflow-Management-Systeme oder (grafische) Petri-Netz-Simulatoren sind prädestinierte Anwendungen - gut strukturiert und beinhaltet ein Framework, welches analysiert werden kann - ist relativ klein, somit brauchen keine Subsysteme definiert werden

Beispiel wichtigsten Pakete ermitteln 1. Beziehungen zwischen wichtigen Paketen betrachten Grundidee: - zwei Strategien zur Analyse großer Softwarepakete 1. Subsystem-Modell erstellen und die Architektur analysieren 2. geht von den am meisten benutzten Klassen/ Paketen aus (Arbeitstiere) überprüft welche anderen Pakete diese stark nutzen Die wichtigsten Pakete ermitteln - nutzt QueryScope um häufig genutzte Pakete zu identifizieren

Beispiel wichtigsten Pakete visualisieren Beziehungen zwischen wichtigen Paketen darstellen - den „normalen“ Packages Nesting Graph erzeugen - die ermittelten Pakete im Resultscope markieren und im Graph einfärben

Beispiel Vererbungsbeziehungen untersuchen

Beispiel Aufrufbeziehungen untersuchen

Beispiel Aufrufbeziehungen untersuchen

Beispiel Analyze von Paketmetriken

Fazit T-Systems Multimedia Solutions GmbH, Dresden „ In den Projekten in denen wir diese Techniken einsetzen sparen wir ca. 20% Wartungskosten. Christian Federspiel, VOEST-ALPINE Industrieanlagenbau, Linz „Mit Hilfe des Sotographen untersuchen wir unsere Software regelmässig auf Architekturabweichungen. Das frühe Auffinden solcher Abweichungen spart uns erhebliche Kosten bei späteren Erweiterungen und kundenspezifischen Anpassungen. Wir sind sehr froh, dass wir den Sotographen haben!“ Michael Qvortrup, Zühlke Engineering AG, Zürich „Nach ca. einen Tag Aufwand hat mir der Sotograph für ein mittelgrosses Projekt mehr relevante Architekturprobleme gezeigt, als ich nach etwa einer Woche manuellen Review selbst gefunden habe. Besser noch, der Sotograph überprüft danach laufend, ob die Probleme behoben worden sind, oder ob neue dazu gekommen sind.“

Fazit - sehr komplex, benötigt viel Erfahrung um die Ergebnisse interpretieren zu können - hohe Anschaffungskosten für Lizenz, Schulung und Hardware - Benutzerführung ist komplex - Erfordert intensive Schulung der Mitarbeiter - Abgeschwächt durch Zusatzprodukt „Sotoweb“ - Erzeugung der Datenbank benötigt Zeit - Für 12 Mio LoC ca. 6 Stunden Generierung der DB - Darauffolgend ca. 6 Stunden Metrikberechnung - Für „normale“ Projekte (< 2Mio LoC) kein Problem + spart beim richtigen Einsatz viele Kosten + es gibt keine Alternative zum Sotograph