2005-12-31

Your NameYour Title

Your Organization (Line #1)Your Organization (Line #2)

SotographEnrico EczkoTesten von SoftwareSommersemester 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- 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

5

AllgemeinesFunktionen

- 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 werden

- 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ßerSoftwaresysteme.

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 DetailModellbildung

- 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

GraphlayoutsTopologielayout:- 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 DetailGraphscope

Arbeiten mit dem GraphScope

- Überblick über das System zu verschaffen- Ergebnisse aus dem Resultscope markieren oder einfügen

- Zyklen, Interfaces, Architekturverstöße markieren

14

Programmaufbau im DetailMetricScope

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 DetailMetricScope

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 DetailResultScope

- 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 DetailTrendMetricScope

- 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

BeispielUntersuchung 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

Beispielwichtigsten Pakete ermitteln

1. Beziehungen zwischen wichtigen Paketen betrachten

Grundidee:- zwei Strategien zur Analyse großer Softwarepakete

1. Subsystem-Modell erstellen und die Architektur analysieren2. 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

Beispielwichtigsten 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

BeispielVererbungsbeziehungen untersuchen

22

BeispielAufrufbeziehungen untersuchen

23

BeispielAufrufbeziehungen untersuchen

24

BeispielAnalyze 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