Sotograph Enrico Eczko Testen von Software Sommersemester 2006

Präsentation zum Thema: "Sotograph Enrico Eczko Testen von Software Sommersemester 2006"—  Präsentation transkript:

1 Sotograph Enrico Eczko Testen von Software Sommersemester 2006

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

3 Allgemeines zum Sotograph
Tomograph zur Softwareanalyse = Softwaretomograph (Sotograph)

4 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 € 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

5 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

6 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

7 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

8 Programmstruktur

9 Datenbank anlegen

10 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

11 Programmaufbau

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 Beispiel Vererbungsbeziehungen untersuchen

22 Beispiel Aufrufbeziehungen untersuchen

23 Beispiel Aufrufbeziehungen untersuchen

24 Beispiel Analyze von Paketmetriken

25 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.“

26 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