9. Workshop Software-Reengineering (WSR...

9 Workshop Software-Reengineering (WSR 2007)

Rainer GimnichIBM Software Group SOA

Advanced Technologies

Volker RiedigerUniversitaumlt Koblenz

Institut fuumlr Softwaretechnik

Koblenz

Andreas WinterJohannes Gutenberg-Universitaumlt

Mainz

Institut fuumlr Informatik Mainz

Bad Honnef 2-4 Mai 2007

Die Workshops Software-Reengineering (WSR) imPhysikzentrum Bad Honnef wurden mit dem ersten WSR1999 von Juumlrgen Ebert und Franz Lehner ins Leben geru-fen um neben den internationalen erfolgreichen Tagungenim Bereich Reengineering auch ein deutsch-sprachigesDiskussionsforum zu schaffen

Ziel der Treffen ist es einander kennen zu lernenund auf diesem Wege eine direkte Basis der Kooperati-on zu schaffen so dass das Themengebiet eine weitereKonsolidierung und Weiterentwicklung erfaumlhrt Durch dieaktive und gewachsene Beteiligung vieler Forscher undPraktiker hat sich der WSR als zentrale Reengineering-Konferenz im deutschsprachigen Raum etabliert Dabeiwird er weiterhin als Low-Cost-Workshop ohne eigenesBudget durchgefuumlhrt

Auf Basis der erfolgreichen WSR-Treffen der er-sten Jahre wurde 2004 die GI-Fachgruppe Software-Reengineering gegruumlndet die unterhttpwwwuni-koblenzdesre praumlsent ist Die Fachgrup-pe organisiert inzwischen eine weitere Tagungsrei-he RePro (Reengineering-Prozesse) mit dem Schwer-punkt Software-Migration Auszligerdem organisiert sie ndashmeist gemeinsam mit anderen GI-Fachgruppen ndash wei-tere Workshops mit den Schwerpunkten Reengineeringund Services Reengineering objektorientierter Syste-me Software-Architektur und -Migration und Software-Analyseverfahren

Im Rahmen des WSR 2007 fand auch die Mitglieder-versammlung der GI-Fachgruppe Software-Reengineeringmit Wahl des Leitunggremiums statt Per Akklamationwurden Rainer Gimnich (IBM Software Group SOAAdvanced Technologies stellvertretender Sprecher) UweKaiser (pro et con Innovative InformatikanwendungenGmbH) Jochen Quante (Universitaumlt Bremen) und Andre-as Winter (Johannes-Gutenberg-Universitaumlt Mainz Spre-cher) gewaumlhlt

Der WSR 2007 als zentrale Tagungsreihe bot eine Viel-zahl aktueller Reengineering-Themen die gleichermaszligenwissenschaftlichen wie praktischen Informationsbedarfabdecken sollten Diese Ausgabe der Softwaretechnik-Trends enthaumllt die Kurzfassungen der Beitraumlge des Work-shop Software-Reengineering 2007 Daruumlber hinaus um-

fasste der WSR 2007 eine Demo-Sitzung im Plenum inder ausgewaumlhlte Tools vorgefuumlhrt und diskutiert wurdenWeitere Tools und Demo-Moumlglichkeiten standen im Rah-men des Workshops zur Verfuumlgung

Der Fachgruppenleitung war es immer ein besonderesAnliegen Hochschule und Industrie dh Forschung undPraxis zusammenzubringen und uumlber den WSR die Moumlg-lichkeit des weiteren Austauschs bis hin zu gemeinsamenProjekten zu schaffen In dieser Hinsicht ist es erfreulichdass in 2007 fast die Haumllfte der Beitraumlge aus der Industriekamen und dass die vorgetragenen Praxisthemen vermut-lich auch staumlrker fuumlr die Forschung interessant werden

Die Organisatoren danken allen Beitragenden fuumlr ihrEngagement den Vortragenden Autorinnen und AutorenTool-Demonstranten und Teilnehmern Unser Dank giltauch den Mitarbeiterinnen und Mitarbeitern des Physik-zentrums Bad Honnef die es wie immer verstanden habenein angenehmes und problemloses Umfeld fuumlr den Work-shop zu schaffen

Der naumlchste zehnte Workshop Software-Reengineeringfindet vom 5-7 Mai 2008 ebenfalls im PhysikzentrumBad Honnef statt

Reverse Engineering

Jan Harder (Universitaumlt Bremen)Ruumlckgewinnung von Grammatik und Semantik vonVisual Basic 6 zur Durchfuumlhrung von statischenProgrammanalysen

Markus Knauszlig Jochen Wertenauer (UniversitaumltStuttgart)Minimierung aufwaumlndiger Berechnungen alsGrundlage fuumlr konsistente und interaktiveProgrammvisualisierungen

Roland Kapeller (Kapeller UnternehmensberatungKoumlln)Einsatz einer Basisontologie fuumlr das ReverseSoftware Engineering im Rahmen desAnforderungsmanagements fuumlr Produktlinien

Migrationsprojekte

Rainer Gimnich (IBM Frankfurt)Komponentisierung in der SOA-Migration

Harry M Sneed (ANECON Wien)Migration in eine Service-orientierte Architektur

Code-Analyse und Tool-Demos

Daniel Vinke Meik Tessmer Thorsten Spitta(Universitaumlt Bielefeld)Quelltextanalyse eines groszligen neuenProduktivsystems

Daniel Speicher Tobias Rho Guumlnter Kniesel(Universitaumlt Bonn)JTransformer - Eine logikbasierte Infrastruktur zurCodeanalyse

Dynamische Analyse

Oliver L Boumlhm (agentes)Software-Archaumlologie mit AOP

Martin Burger (Universitaumlt Saarbruumlcken)JINSI Isolation fehlerrelevanter Interaktion inProduktivsystemen

Jochen Quante (Universitaumlt Bremen)Online Construction of Dynamic Object ProcessGraphs

Software-Evolution und -Transformation

Jens Krinke (FernUniversitaumlt Hagen)Changes to Code Clones in Evolving Software

Sven Wenzel (Universitaumlt Siegen)How to trace model elements

Ralf Laumlmmel (Microsoft RedmondUSA)XML Schema Refactorings for X-to-O Mappings

Reengineering und Software-Wartung

Christof Mosler (RWTH Aachen)Reengineering of State Machines inTelecommunication Systems

Stefan Opferkuch (Universitaumlt Stuttgart)Benoumltigen wir einen ldquoCertified Maintainerldquo

Architektur-Analyse und -Migration

Jens Knodel (IESE Kaiserslautern)Three Static Architecture Compliance CheckingApproaches - A Comparison

Johannes Willkomm Markus Voszlig (sdampm Offenbach)Referenzszenarien der Migration inAnwendungslandschaften

Uwe Erdmenger Denis Uhlig (pro et con Chemnitz)Konvertierung der Jobsteuerung am Beispiel einerBS2000-Migration

Qualitaumltssicherung

Klaus Krogmann (Universitaumlt Karlsruhe)Reengineering von Software-Komponenten zurVorhersage von Dienstguumlte-Eigenschaften

Daniel Simon Frank Simon (SQS Koumlln)Statische Code-Analyse als effizienteQualitaumltssicherungsmaszlignahme im Umfeldeingebetteter Systeme

Cathrin Weiszlig Rahul PremraThomas Zimmermann Andreas Zeller (Universitaumlt

Saarbruumlcken)Predicting Effort to Fix Software Bugs

Ruckgewinnung von Syntax und Semantik

zur Analyse von Visual Basic 6 Programmen

Jan HarderArbeitsgruppe Softwaretechnik

Fachbereich 03 Universitat Bremenhttpwwwinformatikuni-bremendest

harderinformatikuni-bremende

20 April 2007

1 Einfuhrung

Visual Basic ist eine BASIC-Variante die fur die Pro-grammierung von Windows-Applikationen erweitertwurde und in der kommerziellen Softwareentwicklungbreite Verwendung findet Im Rahmen der Anpassungan das NET-Framework erfolgte eine Neuausrichtungder Sprache mit so tief greifenden Veranderungen anSyntax und Semantik dass die Abwartskompatibilitatzu den fruheren Versionen gebrochen wurde Die Mi-gration von pre-NET-Programmen ist nur zum Teilautomatisiert moglich und erfordert die manuelle An-passung von Programmsequenzen deren Semantiksich geandert hat Zudem sind die ehemals verwen-deten Systembibliotheken durch Aufrufe der NET-Klassenbibliothek zu ersetzen die uber eine andereAPI verfugt und damit auch andere Nutzungsproto-kolle voraussetzt

Um die Migration leisten zu konnen ist daher ei-ne umfassende Kenntnis der Software und der darinbestehenden Abhangigkeiten notwendig Bei Legacy-Systemen ist das Wissen uber die Implementierung je-doch oft begrenzt da die Software vor geraumer Zeitgeschrieben wurde Dokumentation fehlt oder nie er-stellt wurde Ebenso konnen die einstigen Entwick-ler das Unternehmen mitsamt ihres Wissens verlas-sen haben Der entstehende Aufwand fur das Pro-grammverstehen der schon bei den ublichen Aufga-ben in der Softwarewartung etwa die Halfte der Zeitbeansprucht [1] ist hier also besonders hoch und un-terstutzende Analysen und Werkzeuge um so wertvol-ler

Das Bauhaus-Projekt der Universitaten Bremenund Stuttgart [5] hat es sich zum Ziel gesetzt Soft-wareingenieure bei den Aufgaben des Programmver-stehens zu unterstutzen Der Resource Flow Graph(RFG) ermoglicht es unabhangig von der Program-miersprache die architektonisch relevanten Elementevon Programmquelltexten selektiv darzustellen undverschiedene Analysen durchzufuhren die Aufschlussuber Struktur und Qualitatsaspekte der Software ge-ben Hierbei nimmt insbesondere die Ruckgewinnungder Systemarchitektur aus den Quelltexten eine zen-

trale Rolle ein Um die Migration zu den neuenNET-Versionen zu unterstutzen wurde ein Analy-sewerkzeug realisiert das den RFG fur Visual-Basic-Programme der Version 6 ndash der letzten vor der NET-Umstellung ndash erstellt

2 Ausgangssituation

Zur Generierung des RFG mussen typische Aufga-ben eines Compiler-Frontends durchgefuhrt werdenindem zunachst die Quelltexte geparst und dann diedarin verwendeten Typen und Bezeichner aufgelostwerden Zwar ist reichlich Dokumentation zu Visu-al Basic 6 verfugbar allerdings fehlen Informationendie fur die Analyse unverzichtbar sind So gibt es we-der eine vollstandige und korrekte Grammatik ndash dieeinzige Referenz ist der Compiler dessen Quelltextenicht einsehbar sind Noch sind die Regeln denen dieNamensauflosung zugrunde liegt im Detail beschrie-ben Dieses undokumentierte Wissen uber die Sprachemusste schrittweise in experimentellen Verfahren wie-dergewonnen werden um die Analyse zu ermoglichenDie dazu eingesetzten Vorgehensweisen werden im fol-genden beschrieben

3 Ruckgewinnung der Grammatik

Ralf Lammel und Chris Verhoef haben eine Vorge-hensweise zum Grammar-Recovery fur einen COBOL-Dialekt beschrieben und angewendet [2] Hierbei wirdaus den verfugbaren Informationen wie etwa denHandbuchern eine Ausgangsgrammatik erstellt Die-se wird schrittweise verfeinert indem ein Parser furdie Grammatik erzeugt wird mit dem Programmeder Sprache deren Korrektheit durch den offiziellenCompiler sichergestellt werden kann analysiert wer-den Dabei auftretende Fehler werden behoben undder Test mit den Beispielprogrammen so lange wie-derholt bis diese fehlerfrei analysiert werden konnen

Im Fall von Visual Basic bot die offizielle Referenz[3] einen Ausgangspunkt zum Erstellen der initialenGrammatik Hier ist die Syntax einzelner Anweisun-gen beschrieben jedoch nicht wie sich diese zu ei-nem korrekten VB6-Programm zusammensetzen Die-

ser fehlende Teil der Grammatik musste zunachst auf-grund von Annahmen und Erfahrungen mit anderenSprachen gestaltet werden Einige hilfreiche Informa-tionen lieferten hierbei partielle Grammatiken andererAutoren

Als Testdaten diente eine groszlige Menge industriel-len Visual Basic 6 Codes mit mehr als 800000 SLOCAls besondere Erschwernis erwies sich bei der Verfei-nerung der Grammatik die Unvollstandigkeit und teilsauch Fehlerhaftigkeit der offiziellen Dokumentationdie viele Relikte alter BASIC-Versionen die noch im-mer unterstutzt werden verschweigt

Vieles deutet zudem darauf hin dass der VB6-Compiler nicht auf einer formalen Grammatikdefi-nition beruht sondern von Hand geschrieben wur-de Beispielsweise lasst sich kein allgemeines Re-gelwerk erkennen nach dem sich entscheidet obein Schlusselwort reserviert ist oder nicht Jenach Kontext in dem ein Bezeichner verwendetwird unterscheidet sich die Menge der reservier-ten Schlusselworter stark und ist offenbar willkurlichgewahlt

Dies spiegelt sich auch in einer Vielzahl von Mehr-deutigkeiten in der wenig restriktiven Syntax derSprache wieder die beim Parsen oft einen groszligenLookahead erfordern Daher wurde zur Implementie-rung des Parsers mit ANTLR [4] ein Generator ver-wendet der es erlaubt in Einzelfallen einen beliebigenLookahead zu verwenden der vom fest gewahlten ab-weicht

4 Nachbildung der Namensauflosung

Wahrend fur die Grammatik mit der Sprachreferenzein hilfreicher Ausgangspunkt bestand fehlte fur dieRekonstruktion von Visual Basics Namensauflosungeine solche Quelle Stattdessen fanden sich lediglich ei-nige verstreute Hinweise in der Literatur oft in Formvon Anmerkungen dass bestimmte Bezeichner ein-deutig sein mussen Bedeutende Hintergrundinforma-tionen etwa wie sich der globale Namensraum bei Na-menskonflikten zusammensetzt fehlten ganzlich

Hier wurde zunachst ein initiales Modell aufder Grundlage von Beobachtungen gezielten Testsund Erfahrungen mit anderen Sprachen erstellt DieIdentifikation von Namensraumen war durch diegezielte Generierung von Testfallen die gleichna-mige Bezeichner in unterschiedlichen Kombinatio-nen gegenuberstellten moglich Testfalle die vomVB6-Compiler abgewiesen wurden beinhalteten Na-mensuberschneidungen die die Sprache nicht erlaubtDurch diese und weitere manuell erstellte Tests sowiedem Compiler als Validierungswerkzeug konnte so dasinitiale Modell konstruiert werden

Dieses Modell wurde analog zur Ausgangsgram-matik anhand der Beispielprogramme getestet Auf-tretende Fehler wurden schrittweise behoben Hierbeiist generell zwischen zwei Arten von Fehlern zu unter-scheiden Namen die nicht zugeordnet wurden und

solche die dem falschen Symbol zugeordnet wurdenWahrend erstere Laufzeitfehler verursachen und da-her leicht festzustellen sind fallen falsche Zuordnun-gen nur dann auf wenn sie zu Folgefehlern in der Na-mensauflosung fuhren oder bei manuellen Stichprobenentdeckt werden

5 Ergebnisse

Die Realisierung des Analysewerkzeugs fand in einemZeitraum von etwa drei Monaten statt Zwar sind dieangewandten Methoden nicht exakt ebenso hangendie Ergebnisse stark von der Gute der herangezogenenBeispielprogramme ab Weitergehende Tests mit an-deren VB6-Programmen zeigen jedoch dass das Ana-lysewerkzeug mit nur geringen Modifikationen auchhierfur erfolgreich eingesetzt werden kann

Die erzeugten RFGs liefern Informationen die ausden Quelltexten nicht direkt ersichtlich fur die Mi-gration zu NET jedoch bedeutsam sind So las-sen sich etwa potentielle globale Auswirkungen lo-kaler Anderungen wie sie bei der Anpassung der Se-mantik notig sind abschatzen indem die Kontroll-und Datenabhangigkeiten der geanderten Funktionenuntersucht werden Die Architektur-Ruckgewinnungermoglicht es zudem geeignete architektonische Kom-ponenten fur eine inkrementelle Migration zu iden-tifizieren Dies ist insbesondere bei groszligeren Legacy-Systemen hilfreich bei denen eine vollstandige Migra-tion in nur einem Schritt nicht moglich ist

Zukunftig ist geplant den RFG auch fur NET-Programme zu generieren Hiermit wird es moglichsein die vorhandenen Bauhaus-Werkzeuge zu nutzenum die Einhaltung der Architektur wahrend der Mi-gration durch Refexionsanalysen zu uberwachen

Literatur

[1] R K Fjeldstadt and WT Hamlen Applicati-on program maintenance study Report to our re-spondents In Proceedings of GUIDE 48 1983

[2] Ralf Lammel and Chris Verhoef Semi-automaticGrammar Recovery Software - Practice and Ex-perience Vol 31(15)1395ndash1438 Dezember 2001

[3] Microsoft Developer Network Library -Visual Basic 6 Webseite April 2007httpmsdn2microsoftcomen-uslibraryms950408aspx

[4] Terence Parr and R W Quong Antlr APredicated-LL(k) Parser Generator Software -Practice and Experience Vol 25(7) Juli 1995

[5] Aoun Raza Gunther Vogel and ErhardPlodereder Bauhaus ndash a tool suite for pro-gram analysis and reverse engeneering InReliable Software Technologies ndash Ada-Europe2006 pages 71ndash82 Juni 2006

EinleitungUm ein Programm zu bearbeiten muss es zunaumlchst verstanden werden Das Verstehen wird unterstuumltzt durch berechnete Zusatzinformation wie zum Bei-spiel Programmstruktur oder Aufrufbeziehungen Die Zusatzinformation kann zu dem Programm vi-sualisiert werden Die Visualisierung ist besonders nuumltzlich wenn sie konsistent mit dem bearbeiteten Programm und interaktiv bedienbar ist Die Berech-nung der Zusatzinformation ist aber aufwaumlndig was die Realisierung einer konsistenten und interaktiv bedienbaren Visualisierung schwer macht

Eine Grundlage fuumlr eine konsistente und interak-tiv bedienbare Visualisierung kann die Minimierung der Berechnung der Zusatzinformation sein Die Mi-nimierung wird erreicht indem nicht mehr konsis-tente Zusatzinformation identifiziert und nur diese neu berechnet wird Diese Idee wurde in einer Ar-beit an der Universitaumlt Stuttgart untersucht (Werte-nauer 2007) Resultat ist das Werkzeug codation mit dem nicht mehr konsistente Zusatzinformation identifiziert wird Dieser Artikel berichtet uumlber die Arbeit und die erreichten Ergebnisse

Im naumlchsten Abschnitt beschreiben wir den Louml-sungsansatz Anschlieszligend stellen wir die techni-sche Realisierung als Eclipse-Plugin vor Danach be-richten wir die Ergebnisse einer kleinen Fallstudie in der das Werkzeug evaluiert wurde Abschlieszligend fassen wir zusammen und geben einen Ausblick auf moumlgliche weitere Arbeiten

LoumlsungsansatzDer Loumlsungsansatz beruht auf der Idee Aumlnderungen am Programmcode moumlglichst genau zu erkennen und nur die Zusatzinformation neu zu berechnen die von den Aumlnderungen betroffen ist Um diese Idee zu realisieren sind zwei Fragen zu beantwor-ten

1 Wie koumlnnen Aumlnderungen erkannt werden2 Wie kann die von einer Aumlnderung betroffe-

ne Zusatzinformation erkannt werden

Um die beiden Fragen zu beantworten und die Vorgaben einzuhalten Aumlnderungen moumlglichst ge-nau zu erkennen und nur die Information neu zu be-rechnen die tatsaumlchlich von der Aumlnderung betroffen ist muss zunaumlchst die Frage beantwortet werden

3 Auf welche Teile des Programms bezieht sich die Information

Im Rahmen der Arbeit an der Universitaumlt Stuttgart wurden die Fragen speziell fuumlr Java-Programme be-antwortet Darum beziehen sich die weiteren Aus-fuumlhrungen auf Java-Programme

Die Berechnung der Zusatzinformation fuumlr Java-Programme beruht meist auf dem AST Darum be-zieht sich die Zusatzinformation fuumlr Java-Program-me auf einzelne Knoten des ASTs

Um Aumlnderungen zu erkennen wurde das Pro-gramm vor der Aumlnderung mit dem nach der Aumlnde-rung verglichen Da die Bezuumlge zwischen Programm und Zusatzinformation uumlber die AST-Knoten reali-siert sind muumlssen die beiden ASTs vor und nach der Aumlnderung verglichen werden Der Vergleich ver-wendet den Algorithmus fuumlr die Berechnung der Tree-Edit-Distance Der Algorithmus berechnet die notwendigen Aumlnderungen die vom AST vor der Be-arbeitung zum AST nach der Bearbeitung fuumlhren in O(n1n2) (n1 n2 Knoten des AST vor und nach der Aumlnderung) (Bille 2005)

Da der Vergleich der vollstaumlndigen ASTs des Pro-gramms vor und nach der Aumlnderung zu aufwaumlndig ist wurde der Algorithmus fuumlr Java-Programme an-gepasst Der Algorithmus vergleicht nur noch ASTs von Methoden lokalen Typen oder Variablen die tatsaumlchlich veraumlndert wurden

Ergebnis der Aumlnderungsberechnung sind die ge-aumlnderten AST-Knoten Da sich die Zusatzinformati-on auf die AST-Knoten bezieht kann schnell festge-stellt werden welche Zusatzinformation von Aumlnde-rungen betroffen ist

Technische RealisierungCodation wurde als Eclipse-Plugin realisiert Es ist in Eclipse als Project-Builder registriert Das hat die folgenden Vorteile codation ist unabhaumlngig von der

Minimierung aufwaumlndiger Berechnungen als Grundlage fuumlr konsistente und interaktive Programmvisualisierungen

Markus KnauszligAbteilung Software EngineeringInstitut fuumlr Softwaretechnologie

Universitaumlt Stuttgartwwwinformatikuni-stuttgartdeistese

Jochen Wertenauermailjwertenauerde

Programmiersprache wird bei jedem Speichern uumlber die geaumlnderten Dateien informiert und kann Ressourcen im Workspace aumlndern

Codation implementiert ein Rahmenwerk fuumlr die Aumlnderungserkennung Das Rahmenwerk besteht aus den drei Schnittstellen Annotation-Provider Storage-Provider und File-Link-Provider Mit dem Annotation-Provider werden Zusatzinformationen in codation eingebracht der Storage-Provider kuumlm-mert sich um die Speicherung der Zusatzinformatio-nen und der File-Link-Provider verbindet die Zu-satzinformationen mit dem Programmcode Der File-Link-Provider ist auch zustaumlndig fuumlr die Identi-fikation der nicht mehr konsistenten Zusatzinforma-tionen Der Storage-Provider verwaltet die Zusatzin-formationen und die Bezuumlge zwischen den Zusatz-informationen und dem Programmcode in eigenen Dateien Hierdurch bleibt der Programmcode unver-aumlndert was die Nutzung existierender Werkzeuge ermoumlglicht Soll codation in einem eigenen Projekt genutzt werden dann muumlssen diese drei Schnittstel-len fuumlr die eigene Anwendung implementiert wer-den

Der Ablauf der Aumlnderungsberechnung in codation ist wie folgt

1 Mit den Annotation-Providern werden die von der Aumlnderung betroffenen Zusatzinfor-mationen bestimmt

2 Von der Aumlnderung betroffene Zusatzinfor-mation wird gepruumlft ob eine Aktualisierung notwendig ist

3 Annotation-Provider nicht mehr konsisten-ter Zusatzinformationen werden benach-richtigt

Die Berechnung der Aumlnderungsinformation wird im Hintergrund ausgefuumlhrt um den Entwickler bei seiner Arbeit nicht zu behindern

FallstudieDie Nuumltzlichkeit von codation wurde in einer klei-nen Fallstudie untersucht Fuumlr die Fallstudie wurde eine Anwendung entwickelt mit der Use-Cases mit dem Programmcode verknuumlpft werden koumlnnen So ist es moumlglich Use-Cases zu erkennen deren Reali-sierung nach einer Aumlnderung des Programms zum Beispiel durch Testfaumllle gepruumlft werden muumlssen Es zeigte sich dass codation gut geeignet ist fuumlr die Realisierung der Anwendung und die Aumlnderungs-berechnung sehr genau anzeigt welche Use-Cases gepruumlft werden muumlssen Allerdings ist festgestellt worden dass die im Hintergrund laufende Aumlnde-rungserkennung sehr aufwaumlndig ist und die Arbeit behindern kann

Um die Auswirkungen von Aumlnderungen auf das Laufzeitverhalten von codation naumlher zu untersu-chen wurden Performanzmessungen durchgefuumlhrt Es wurde festgestellt dass die Laufzeit von der Grouml-szlige der geaumlnderten Methoden abhaumlngt Die Groumlszlige ei-ner Methode spiegelt sich in einem groumlszligeren AST wieder was zu einem houmlheren Aufwand in der Aumln-derungsberechnung fuumlhrt Die Anzahl der Metho-den in einer Klasse oder die Art der Aumlnderung spielt hingegen keine Rolle

Zusammenfassung und AusblickDieser Artikel hat einen Ansatz vorgestellt mit dem die aufwaumlndige Berechnungen von Zusatzinformati-on zu einem Programm auf ein Minimum reduziert werden kann Die Minimierung ist notwendig um konsistente und interaktiv bedienbare Visualisierun-gen der Zusatzinformation zu ermoumlglichen Durch die konsistente und interaktiv bedienbare Visualisie-rung wird das Verstehen und Bearbeiten des Pro-gramms zwei wichtige Arbeiten in der Software-Wartung unterstuumltzt Der Ansatz wurde im Werk-zeug codation als Eclipse-Plugin realisiert Fuumlr die Aumlnderungserkennung in Java-Programmen auf Ba-sis des AST wurde der Algorithmus fuumlr die Berech-nung der Tree-Edit-Distance verwendet und ange-passt Die Nuumltzlichkeit und Effizienz des Werkzeugs wurde in einer kleinen Fallstudie untersucht

In zukuumlnftigen Arbeiten kann die Berechnung der Aumlnderungsinformation noch weiter optimiert wer-den zum Beispiel indem Heuristiken eingesetzt werden um die Anzahl der Knoten im untersuchten AST zu reduzieren Ein anderer Ansatzpunkt fuumlr Optimierungen ist zu berechnen ab welcher AST-Groumlszlige es sinnvoller ist eine Methode vollstaumlndig als geaumlndert zu markieren als detaillierte Aumlnderungsin-formationen zu berechnen

codation kann von der Website wwwjwertenau-erdegerunidaindexshtml (342007) herunterge-laden werden Das Werkzeug steht unter der Eclipse Public License (EPL) und kann in eigenen Projekten eingesetzt werden

LiteraturBille Philip (2005) A Survey on Tree Edit Distance

and Related Problems Theoretical Computer Science 337(1-3) 217-239

Wertenauer Jochen (2007) codation ndash Verbindung von Code mit Zusatzinformation Diplomarbeit Nr 2521 Universitaumlt Stuttgart

Gesamtsystem

System

Funktion

Produkt

Komponente

Modul

realisiert

realisiert

realisiert

1N

1N

1N 1N

1N

1N

Sub-system

Subkom-ponente

Einsatz einer Basisontologie fuumlr das Reverse Software Engineering im Rahmen des Anforderungsmanagements fuumlr Produktlinien

Roland KapellerRoland Kapeller Unternehmensberatung Koumlln

rkapellerkapeller-ubde

ZusammenfassungDie steigende Komplexitaumlt elektronischer Steuergeraumlte in Kraftfahrzeugen erzwingt ein leistungsfaumlhiges Anforde-rungsmanagement Die Wiederverwendung von Software die bereits Teil marktgaumlngiger Produkte ist kann durch nachtraumlgliche Modellierung auf Grundlage einer Basisonto-logie effizient gestaltet werden

ZielsetzungDer Ruumlckgriff auf bereits entwickelte Produkte laumlszligt Designentscheidungen (einschlieszliglich der Parametrisierung von Funktionen) als Anforderungen neben den Kundenan-forderungen in die einzelnen Kundenprojekte miteinflie-szligen Diese bdquoSystemarchaumlologieldquo sollte stets mit den Gestal-tungsgrundsaumltzen der Systemspezifikation uumlbereinstimmen Gefordert wird daher ein durchgaumlngig im System-Entwick-lungsprozeszlig anwendbarer und universeller Ansatz der Klas-sifikation von Aussagen uumlber (vorhandene) Produkte und (zu realisierende) Zielsysteme

Ansatz Es zeigt sich daszlig eine Basisontologie in deren Zentrum ein uumlbersichtliches Metamodell steht den Workflow bei mehreren wichtigen Aktivitaumlten unterstuumltzen kannbull Definition einer Produktdefinition als Basis der pro-

jekt- bzw auftragsspezifischen Systemspezifikationenbull Analyse des Lastenhefts einschlieszliglich des Ver-

gleichs mit der Basisspezifikationbull Reverse Engineering vorhandener HW und SW zur

Wiedergewinnung von Basisanforderungen (ein-schlieszliglich der Anforderungen der Entwicklung)

BasisontologieBei Analyse und Design von Systemen wird zumeist (etwa in der MDA) zwischen zwei Beschreibungsebenen (bzw Sichten) unterschieden Im Requirements Management ist die Verwendung weiterer Sichten sinnvoll [1] Das Mini-mum scheinen jedoch drei zu sein Die Verhaltensbe-schreibung beinhaltet rein funktionale Anforderungen Alle Festlegungen hinsichtlich des Systemdesigns gehoumlren hin-gegen zur Strukturbeschreibung Wenn beide Sichten hierarchisch gegliedert sind koumlnnen die Beschreibungs-Elemente (Klassen) der verschiedenen Schichten einander zugeordnet werden (siehe folgende Abbildung)

Als dritte Sicht beinhaltet die Schnittstellenbeschreibung die in Verhalten und Struktur verwendeten Groumlszligen aller Art Fuumlr die Instanzen der Elemente aller Sichten ist festge-legt was zu ihrer Definition neben einem eindeutigen Na-men angegeben werden muszlig Die Kernelemente der Ver-haltenssicht selbst sind dabei wie folgt definiertbull Ein System besteht aus Subsystemen oder Funktionen

und entspricht (genau) einer Funktionalitaumltbull Ein Subsystem ist ein System das einer Teilfunktiona-

litaumlt (ihres uumlbergeordneten Systems) entsprichtbull Ein Gesamtsystem ist ein System das kein Subsystem

istbull Eine Funktion ist fuumlr das Erfuumllltsein von Bedingungen

innerhalb einer Funktionalitaumlt verantwortlich Dies be-zieht sich auf die Systemgrenzen Funktionen inner-halb eines Systems sollten daher nicht durch Groumlszligen verkettet werden

Um diesen Kern gruppieren sich weitere Basiselementebull Bedingung (beinhaltet Groumlszligen)bull Ereignis (beinhaltet Bedingung mit Zeitpunktbezug)bull Groumlszlige (Informationen Signale Daten mechanische

oder uumlberhaupt physikalische Wirkungen)bull Zustand (eines Systems einer Funktion Zustandsuumlber-

gaumlnge sind abhaumlngig von Bedingungen und Zustaumlnden)bull Fehlerfall (als benannter Bedingung innerhalb eines

Systems)

Zu beschreiben sind damit (unter anderem)bull Schnittstellen (von Systemen Funktionen Komponenten

und Modulen)bull Systemsteuerung (Zustandsmodell von Systemen

Vorbedingungen von Funktionen)

PCF

PEF

REP

DIA

CTR

EDT

SDI

CEI

CAD

EDID

ODACDACDACD DD

OPDED

OPD

OPD

bull Wirkungsweise (von Funktionen insbesondere Be-triebs- und Nachbedingungen)

bull Realisierungen (von Produkten Komponenten und Mo-dulen)

Bei der vorgestellten Basisstruktur handelt es sich um ein Beispiel das im folgenden noch domaumlnenspezifisch verfeinert wird Ihre praktische Anwendung kann auch die Klassifika-tion von Aussagen innerhalb der Spezifikation und die Formulierung von Systemanforderungen umfassen [2]

Die Elemente der Struktursicht sind uumlber die in der Graphik angegebenen Beziehungen definiert Module sind elektronische (HW) oder elektromechanische Module oder SW-Module (als Pakete aufzufassen)

System-MetamodellDer funktionale Aufbau elektronischer Steuergeraumlte laumlszligt sich verallgemeinern und fuumlhrt zu einer bdquoZwiebelstrukturldquo aus Systemen und Funktionen (sowie deren Gruppen)bull Sensorik (setzt an der Systemgrenze beispielsweise

physikalische in elektrische Groumlszligen um)bull Steuerung

bull Eingangssignaltransformation (setzt Signale in Da-ten um etwa als AD-Converter)

bull Verarbeitung Ablaufkontrollebull Ausgangssignaltransformation (setzt Daten in Si-

gnale um etwa als DA-Converter)bull Aktorik (setzt bspw elektrische in mechanische Grouml-

szligen an der Systemgrenze um)

Die Verarbeitung Ablaufkontrolle besteht als Kern des eingebetteten Systems naturgemaumlszlig aus Datenverarbei-tung (SW) die nach folgendem Modell folgt strukturiert werden kann (siehe folgende Abbildung)

Die dargestellten Elemente stellen Funktionsgruppen dar de-ren Funktionen einen der folgenden Stereotypen besitzenbull CTR = System Controlbull EDT = Error Detection

bull PCF = Processing Core Functionbull PEF = Processing Error Functionbull REP = Reporting (Ausgabe der Fehler und Diagnose-

ergebnisse)bull DIA = Diagnosis (von externem System initiiert)bull SDI = Self Diagnosis (steuert die Aktorik)

Auszligerhalb der Verarbeitung Ablaufkontrolle bestehen weite-re Funktionen mit eigenen Stereotypen etwa fuumlr die Initia-lisierung und das Remote Control Interface

Fluumlsse sind ebenfalls typisiert Auf dieser Ebenebull ID = Input Databull CEI = Control Error Identificationbull CAD = Control Activation amp Deactivationbull ED = Error Databull ACD = Actuator Control Data (Ansteuerung)bull OPD = Operation Data (Betriebsdaten)bull DD = Diagnosis Databull OD = Output Data (= ACD+OPD+ED+DD)

Anwendung im SW-ReengineeringEs wird empfohlen vor Erstellung der Strukturbeschreibung die Funktionalitaumlt der SW zu untersuchen Arbeitsschritte1 Synthese zu Funktionen (in der Beschreibungsform von

Bedingungen) und Zuweisung des jeweils passenden Stereotypen Bildung von Funktionsgruppen

2 Beschreibung der Schnittstellen ohne Parameter3 Zusammenfassung der Funktionen zu Systemen wel-

che diese Funktionen steuern Parametrisierung

Nuumltzlich ist dabei ein CASE-Tool (heute eher SASD als UML spaumlter SysML) Jedoch sollte dann ein Anforde-rungsmanagementtool die Anforderungen verwalten

FazitWie die Praxis bei einem namhaften Automobilzulieferer zeigt bringt die Methode neben der Beschleunigung der Angebotserstellung und der Erhoumlhung der Wiederver-wendungsgrades groszligen Nutzen durch die Foumlrderung einheitlicher Denk- und Kommunikationsmuster bei den Mitarbeitern Zudem werden vielfach produktbezo-gene Verbesserungsmoumlglichkeiten entdeckt

Literaturhinweise[1] Geisberger Wuszligmann Requirements Engineering ein-gebetteter Systeme (Softwaretechnik-Trends 231 S 6)[2] Kapeller Erstellung vollstaumlndiger Systemspezifikatio-nen im Embedded Computing (Softwaretechnik-Trends 261 S 15)

Komponentisierung in der SOA-Migration

Rainer Gimnich IBM Software Group

SOA Advanced Technologies Wilhelm-Fay-Str 30-34 D-65936 Frankfurt

gimnichdeibmcom

Zusammenfassung Service-orientierte Architektur (SOA) ist eine geschaumlftlich mo-tivierte IT-Architektur die die Integration von Geschaumlftsfunk-tionen als verbundene wiederverwendbare Dienste (Services) unterstuumltzt SOA-Migration bezeichnet die Umsetzung existie-render Architekturen ndash die sehr unterschiedlich geartet sein koumlnnen ndash in eine SOA Hierbei liegt der Schwerpunkt meist auf der Anwendungsarchitektur Bei der SOA-Migration bieten Komponenten und Komposition auf unterschiedlichen Ebenen wichtige Hilfestellungen Diese Leistungen werden hier unter-sucht und anhand von Projektbeispielen beschrieben

1 SOA-Migration Service-Orientierung bei Unternehmensarchitekturen ermoumlg-licht eine Reihe von Vorteilen ua houmlhere Flexibilitaumlt kuumlrzere Produktzyklen staumlrkere Verzahnung von Fachbereich und IT vorhandene Standards leichtere Realisierung von Architektur-prinzipien wie zB Wiederverwendung und lose Kopplung Die Migration existierender Architekturen in SOA kann und sollte evolutionaumlr erfolgen dh in einzelnen Schritten mit ge-schaumlftlich motivierter Priorisierung [GimnichWinter 2005 Gimnich 2006b] zB beginnend mit der Partneranbindung aufbauend auf Portalloumlsungen Migrationen erfolgen generell nach sorgfaumlltiger Analyse der Gegebenheiten [Sneed et al 2005] und einem realistischen Umstellungsplan Eine lsquoSOA Roadmaprsquo beruumlcksichtigt dabei bereits geplante und laufende Projekte und stellt die fruumlhzeitige Nutzung von SOA-Governance-Richtlinien-Prozessen sicher [Gimnich 2006a]

2 Schichtenmodell und Vorgehen Fuumlr die SOA-Realisierung hat sich ein Schichtenmodell be-waumlhrt dass eine Zentrierung auf (Business) Services aus Nut-zer- und Anbietersicht darstellt und dabei folgende Ebenen rea-lisiert (s auch Abb 1)

bull Nutzungsebene Personen Systeme (zB Portale)

bull Geschaumlftsprozess-Ebene

bull Service-Ebene (zentral)

bull Service-Komponenten-Ebene

bull Ebene der (existierenden) operationalen Systeme

Daruumlber hinaus gibt es Querschnittsfunktionen wie Governan-ce Metadaten-Management unternehmensweite Integration (Enterprise Service Bus ESB) ua Der Entwurf der SOA be-steht primaumlr in der Definition und Spezifikation der Elemente (Komponenten) auf diesen Ebenen und der Beziehungen der Elemente sowohl innerhalb einer Ebene als auch uumlbergreifend

Fuumlr das Vorgehen bei SOA-Analyse und -Design hat sich ein kombiniertes Verfahren (Top-down Bottom-up Outside-in) bewaumlhrt wie es zB in [Gimnich 2006b] an Fallstudien gezeigt wird Hier geht es darum genau die geschaumlftlich angemessenen Services und ihre Zusammen-haumlnge zu ermitteln zu spezifizieren und Realisierungs-entscheidungen zu treffen Eine lsquoInflationrsquo von Services ist zu vermeiden fuumlr jeden Servicekandidaten ist seine Exponierung (zum Kunden zu Partnern oder unterneh-mensintern) genau zu pruumlfen zu entscheiden und einzu-halten (einschlieszliglich QualitaumltLeistung und Wartung) Die laut Analysten maumlchtigste Methode zur Service-Modellierung ist SOMA eingefuumlhrt in [Arsanjani 2004] inzwischen publiziert und als Version 24 [SOMA 2006] allgemein verfuumlgbar

3 Komponentisierung Komponentisierung ist Teil der SOA-Entwurfsmethode und hilft die Komplexitaumlt der Erstellung einer angemes-senen geschaumlftsorientierten Zielarchitektur zu meistern Die auf den einzelnen Ebenen verwendeten Komponen-tenkonzepte und -modelle unterscheiden sich dabei meist erheblich [Gimnich 2007]

Daruumlber hinaus dient die Komponentisierung dazu auf jeder Ebene die Migration von ggf existierenden und verwendbaren Elementen in die SO-Zielarchitektur zu steuern und durchzufuumlhren

31 Komponentisierung auf Geschaumlftsprozessebene Hier werden ndash komplementaumlr zu den Geschaumlftsprozessen ndash geschaumlftliche Komponenten (Business Components) gebildet Diese stellen eigenstaumlndige nicht-uumlberlappende Gruppierungen von Geschaumlftsfunktionen dar bei Banken zB Kontenverwaltung oder AuditingCompliance Bei der Beschreibung von Geschaumlftskomponenten lassen sich Business Services auf hoher Abstraktion ermitteln und spaumlter ndash in der Service-Modellierung ndash aus Ausgangs-punkt nutzen Ein komplexer Geschaumlftsprozess wie zB Kreditantragsbearbeitung wird hier als lsquoKollaborationrsquo zwischen den relevanten Geschaumlftskomponenten be-schrieben und damit lsquoSOA-nahrsquo dokumentiert Fuumlr die Migration lassen sich hierbei im sog Business Operating Model (BOM) die existierenden IT-Assets (zB Anwendungen Standardpakete Unternehmensda-tenbanken) sowie die eventuell etablierte IT-Governance auf hoher Ebene den Geschaumlftskomponenten zuordnen

Abb 1 Komponentenbildung pro Ebene

32 Komponentisierung auf Service-Ebene Hier geht es um den Zusammenbau von Services zu komplexe-ren Strukturen (Composite Services) die eine groumlszligere Funkti-onalitaumlt realisieren und oft branchenspezifisch angelegt sind Fuumlr die Migration sind existierende Services und ggf Compo-site Services relevant die in die SOA uumlbernommen werden koumlnnen

33 Komponentisierung in der Service-Realisierung Auf dieser Ebene liegen die lsquoklassischenrsquo Komponentenmodel-le wie die von J2EE CORBA oder anderen Programmiermo-dellen vor Fuumlr die SOA-Realisierung ist insbesondere eine Aggregation von Service-Komponenten interessant wie sie zB durch das Enterprise Component Pattern erreicht werden kann [Arsanjani 2004] Solche lsquoUnternehmenskomponentenrsquo stellen dann meist die funktionale Grundlage fuumlr mehrere Ser-vices auf der Ebene daruumlber bereit Aus Migrationssicht sind alle Service-Komponenten wichtige Assets die als Kandidaten fuumlr die Implementierung im Servi-ce-Modell registriert werden sollten

34 Komponentisierung von operationalen

Systemen (Legacy)

Auf dieser Ebene liegen in der Regel die meisten Assets vor die fuumlr eine SOA-Migration in Betracht kommen Oft handelt es sich um sbquoklassischersquo Eigenentwicklung von Anwendungen zB in COBOL oder C++ oder kommerzielle Anwendungspa-kete (sbquoStandardsoftwarersquo) Auch wenn Komponenten und Be-schreibungen auf den Ebenen daruumlber oft fehlen Legacy-Sourcen oder fuumlr das Unternehmen parametrierte sbquoPackagesrsquo liegen meist vor Das Ziel der weiteren Verwendung in einer SOA ist nachvollziehbar aus Qualitaumlts- Stabilitaumlts- Auf-wands- und Kostengruumlnden

Methoden wie SOMA sehen die Einbindung existierender Systemen auf dieser Ebene in mehrfacher Hinsicht bull zur Vollstaumlndigkeit

des Service-Portfolios bereits (konventionell) rea-lisierte Business Services schlieszligen oft Luumlcken in der Service-Kandidaten-Liste

bull zum Treffen von Entscheidungen uuml-ber die Realisierung von Services zB Integration und ggf Transformation exi-

stierender Assets gegenuumlber Einkauf oder Neuimple-mentierung der Funktionalitaumlt

4 Bewertung und Ausblick

Der Nutzen der Komponentisierung wird anhand aktuel-ler SOA-Projekte diskutiert Abschlieszligend wird die Be-deutung der gerade in Version 1 verabschiedeten Stan-dardisierung einer Service Component Architecture [SCA 2007] eingeschaumltzt Literatur [Arsanjani 2004] A Arsanjani Service-Oriented Modeling and

Architecture httpwwwibmcomdeveloperworkswebserviceslibraryws-soa-design1 November 2004

[Gimnich 2006a] R Gimnich Quality Management Aspects in SOA Building and Operating SQM 2006 httpwwwsqs-conferencescomde2006programme_06htm May 2006

[Gimnich 2006b] R Gimnich SOA Migration ndash Approaches and Experience RePro 2006 GI Softwaretechnik-Trends Vol 27 No 1 2006 httppiinformatikuni-siegendestt27_1

[Gimnich 2007] R Gimnich Component Models in SOA Rea-lization SQM2007 httpwwwsqs-conferencescom April 2007

[GimnichWinter 2005] R Gimnich A Winter Workflows der Software-Migration WSR 2005 Softwaretechnik-Trends 252 May 2005 Presentation httpwwwuni-koblenzdesreConferencesWSRWsr2005Programmgimnichwinterpdf

[SCA 2007] Open SOA Service Component Architecture Specifications Final Version V10 March 21 2007 httpwwwosoaorgdisplayMainService+Component+Architecture+Specifications

[Sneed et al 2005] H Sneed M Hasitschka M-T Teichmann Software-Produktmanagement dpunkt Heidelberg 2005

[SOMA 2006] IBM RUP for Service-Oriented Modeling and Architecture V24 (Rational Method Composer plug-in) httpwwwibmcomdeveloperworksrationaldownloads06rmc_soma November 2006

Servicesatomic and composite

Operational Systems

Service Components

Consumers

Business ProcessComposition choreography business state machines

Service P

roviderS

ervice Consum

er

Integration (Enterprise S

ervice Bus)

QoS

Layer (Security M

anagement amp

Monitoring Infrastructure S

ervices)

Data A

rchitecture (meta-data) amp

Business Intelligence

Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication

Atomic Service Composite Service Registry

Business Componentscomplementing business

processes

Service Componentsfunctional building blocks eg as

J2EE components (EJBs) or Enterprise Components

Composite Servicesas collections of business

services usually industry-specific

Existing Systems Components

identified and potentially transformed legacy assets


Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication


Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes







Migration in eine Service-orientierte Architektur

von Harry M Sneed

ANECON GmbH Vienna harrysneedaneconcom

1 Zur Bereitstellung von Web-Services Eine Voraussetzung fuumlr die Einfuumlhrung eines Service orientierten Architektur (SOA) ist die Bereitstellung der erforderlichen Web-Services Denn im Gegensatz zu den Kindern werden sie nicht vom Storch gebracht Der Anwender muss sie besorgen Dies kann auf fuumlnferlei Weise geschehen Sie koumlnnen entweder gekauft gemietet geliehen gebaut oder aus vorhandenen Komponenten wieder gewonnen werden Um diese alternative Ansaumltze Web-Services bereitzustellen geht es in diesem Beitrag In dem ersten Abschnitt werden die fuumlnf Moumlglichkeiten fuumlr die Erlangung eines Webservices vorgestellt Sie sind wie folgt bull einen Service zu kaufen bull einen Service zu mieten bull einen Service zu leihen bull einen Service neu zu erstellen bull einen Service aus vorhanden Komponenten zu

gewinnen 11 Web-Services einkaufen Web-Services koumlnnen von einem Software-Hersteller eingekauft werden Inzwischen bieten die meisten ERP-Software-Hersteller bieten ihre Komponenten auch als Web-Services an und jeder IT-Anwender kann sie kaufen Dies gilt nicht nur fuumlr kommerzielle Software fuumlr den betrieblichen Einsatz sondern auch fuumlr Konstruktions- und Wissenschaftssoftware welche ebenso von der Stange gekauft werden kann Die Vorteile solcher fertigen Web-Services von der Stange sind bull sie sind sofort verfuumlgbar bull sie sind gut getestet und relativ verlaumlsslich bull sie werden mit Support angeboten [1] Die Nachteile eines Web-Services von der Stange sind bull Er ist in der Regel sehr teuer bull Er ist beschraumlnkt in seiner Funktionalitaumlt bull Er ist fuumlr den Benutzer nicht veraumlnderbar bull Er ist nicht selten zu groszlig und zu starr Der groumlszligte Nachteil ist die fehlende Flexibilitaumlt Die Verwendung von groszligen und starren Web-Services wie in etwa einem kompletten Abrechnungssystem ist wie das Bauen mit fertigen Betonwaumlnden Der Benutzer muss seine Geschaumlftsprozesse um die Web-Services herum

bauen Somit bestimmt der Web-Service den Prozess Man kauft also nicht nur die Software sondern auch den zugrunde liegenden Geschaumlftsprozess 12 Web-Services mieten Eine Alternative zum Kauf eines Web-Services ist es ihn zu mieten Viele Produzenten von Standardsoftware sind nun dabei ihre Services auf einer Vermietungsbasis anzubieten Anstelle die Software-Packete zu kaufen und sie innerhalb seiner Umgebung zu installieren hat der IT-Anwender nun die Option nur die Funktionalitaumlt die er benoumltigt zu verwenden und dies nur wann er sie benoumltigt also auf Anfrage ndash Software on Demand Er bezahlt dann nur fuumlr die tatsaumlchliche Nutzung Dieses Geschaumlftsmodell hat viele Vorteile gegenuumlber einem Kauf bull Zunaumlchst ist der Benutzer nicht gezwungen die

Software zu installieren und staumlndig zu aktualisieren

bull Zweitens arbeitet er stets mit der aktuellen Version

bull Drittens zahlt er nur fuumlr dass was er wirklich benutzt

Die Nachteile sind die gleiche wie beim Kauf plus einige mehr Wenn er sie kauft kann er sie anpassen Wenn er sie in welcher Weise auch immer mietet muss er sie benutzen wie sie sind Ist die Granularitaumlt der Software fein genug kann dieses Problem beherrschbar bleiben Er kann sie in seinen Prozess integrieren wie Ziegelsteine in eine Wand aber wenn sie groszlig wie vorgefertigte Bauplatten sind muss er seine Bauplaumlne anpassen um sie einbauen zu koumlnnen Andererseits ist er davon befreit staumlndig neue Versionen zu installieren und zu testen [2] 13 Web-Services ausleihen Web-Services aus der Open-Source-Gemeinde zu entnehmen ist wie sich einen Web-Service zu leihen Vertreter dieser Gemeinde lassen gerne andere ihre Arbeit verrichten um sie dann mit oder ohne eigene Aumlnderungen zu uumlbernehmen Auf der einen Seite wollen sie nicht fuumlr Software bezahlen und auf der anderen Seite wollen sie sie nicht entwickeln Open Source Web-Services werden als Allgemeinguumlter angesehen die jeder nach belieben verwenden kann

Der Nachteil hier ist dass der Anwender den fremden Code uumlbernehmen und pflegen muss Unzaumlhlige Studien haben bewiesen dass der groumlszligte Zeitfaktor im Bereich der Software-Maintenance ist die Software zu verstehen [3] Bei Open-Source Code kommt dieser Faktor voll zum tragen 14 Web-Services entwickeln Web-Services koumlnnen wie jedes andere Softwarepaket vom Anwender oder einem Vertragspartner entwickelt werden Der Unterschied zu konventioneller Software ist dass Web-Services wenn sie korrekt definiert wurden viel kleiner sind und leichter zu entwickeln sein sollten Der andere Unterschied ist der das Web-Services ein allgemeines Gut eines Unternehmens sein sollten also fuumlr alle Einheiten des Unternehmens verfuumlgbar sein sollten Dies ist ein ernster Bruch in der Tradition der Unternehmen bezuumlglich der Frage durch wen Software in dem Unternehmen bezahlt werden sollte In der Vergangenheit wurde sie IT-Abteilung als internes Software-Haus angesehen mit dem Auftrag fuumlr die verschiedenen Anwendungsbereiche als IT-Dienstleister zur Verfuumlgung zu stehen Benoumltigte die Marketing-Abteilung ein neues Customer-Relationship-Management-System beauftragte sie die IT-Abteilung eines zu entwickeln oder zu kaufen Benoumltigte die Logistikabteilung ein neues Auftragsbearbeitungssystem beauftragte sie die IT-Abteilung eines fuumlr sie zu entwickeln Es sind die Anwendungsbereiche die uumlber das Geld verfuumlgen und die werden es nur fuumlr etwas ausgeben wollen das einen direkten Nutzen fuumlr sie hat Im Fall von Web-Services ist nicht klar wem sie gehoumlren Jeder im Netzwerk der Organisation kann auf sie zugreifen Wer soll sie also bezahlen Fakt ist dass es ein groszliger Aufwand ist gute Web-Services zu planen zu entwickeln und zu testen Sie sollten stabiler und verlaumlsslicher sein als die Anwendungssysteme der Vergangenheit und sie sollten auszligerdem fuumlr die verschiedensten Zwecke und in verschiedenen Zusammenhaumlngen wieder verwendet werden Wie bei anderen Standardsysteme kosten auch Web-Services drei mal so viel als normale Single-User-Systeme Anwendungsbereiche sind allerdings abgeneigt gegenuumlber Projekten die nicht genau ihren Anforderungen gewidmet sind und nur einen langfristigen Nutzen versprechen Wenn sie ein Problem zu loumlsen haben moumlchten sie es gleich und direkt geloumlst bekommen dh die Loumlsung soll auf ihre Anforderungen erfuumlllen und sonst nichts Einen Web-Service zu entwickeln ist eine langfristige Investition [4] Es wuumlrde mindestens zwei Jahre dauern bevor genug Services von

ausreichender Qualitaumlt fuumlr die Anwender verfuumlgbar sind um ganze Prozesse daraus zu entwickeln Es ist fraglich ob die Anwender so lange warten wollen Die Vorteile von selbst entwickelten Web-Services werden sich erst nach Jahren zeigen In der Zwischenzeit muss die IT-Abteilung die laufenden Systeme warten Dies bedeutet eine Doppelbelastung fuumlr die Organisation Deswegen und auch wegen der hohen Folgekosten mag es keine attraktive Alternative sein Web-Services selbst zu entwickeln Die groumlszligte Barriere ist die benoumltigte Zeit die zweite die Frage der Finanzierung 15 Web-Services aus vorhandenen Systemen wiedergewinnen Die fuumlnfte und letzte Loumlsung ist Web-Services aus vorhanden Applikationen wiederzugewinnen Es mag wahr sein das die existierenden Software alt aus der Mode gekommen und schwierig zu warten ist aber sie funktioniert Und nicht nur dies sie ist auch an die lokale Organisation angepasst Sie passt zu den Daten und zur Umgebung der Organisation Warum sollte man sie also nicht wieder verwenden Das Ziel sollte nicht sein die existierenden Anwendungen als Ganze zu nutzen da sie vielleicht so nicht zu dem neuen Geschaumlftsprozess passen wuumlrden sondern gewisse Teile zu extrahieren Diese Teile koumlnnen Methoden Prozeduren Module oder Komponenten sein Das Wichtige ist nur das sie unabhaumlngig ausfuumlhrbar sind Dafuumlr muumlssen sie gekapselt werden Kapselungstechnologie ist der Schluumlssel fuumlr die Wiederverwendbarkeit von Software Es ist auch nicht so wichtig in welcher Sprache die existierende Software geschrieben ist so lange sie in der Server-Umgebung ausfuumlhrbar ist [5] Da Anfragen an Web Services umgeleitet werden koumlnnen ist es absolut legitim verschiedene Server fuumlr verschiedene Sprachtypen zu haben Es ist also durchaus moumlglich einen COBOL und PLI Service auf einem Server und einen C bzw C++ Service auf einem anderen Server zu haben Worauf es ankommt ist dass die Komponenten mit einer standardisierten WSDL Schnittstelle ausgestattet sind [6] Der Service selbst soll durch den jahrelangen produktiven Einsatz getestet sein Die geringen Kosten und die wenige Zeit in der Web-Services auf diese Art erstellt werden koumlnnen sind die groumlszligten Vorteile dieses Ansatzes Die groumlszligten Nachteile sind bull Die Software ist alt und schwer verstaumlndlich bull Die Konvertierung von Daten aus einem

externen in ein internes Format reduziert die Geschwindigkeit

bull Es koumlnnten irgendwann keine Programmierer mit Kenntnissen uumlber die Legacy-Systeme mehr verfuumlgbar sein

Ein zusaumltzliches Problem ist es den Datenstatus von einer Transaktion zur naumlchsten zu verwalten wenn die Software nicht urspruumlnglich darauf ausgelegt war ablaufsinvariant bzw reentrant zu sein Invarianz muss dann nachtraumlglich in die Software implementiert werden 2 Ansaumltze zur Wiedergewinnung von Web-Services Wer sich fuumlr das fuumlnfte Alternativ entscheidet steht vor der Frage wie man einen Web-Service aus existierender Software herausholen kann Die Antwort auf diese Frage heiszligt Web Service Mining Ein Groszligteil der benoumltigten Funktionalitaumlt einer Organisation wurde bereits auf die eine oder andere Weise implementiert Die Funktionalitaumlt liegt begraben in ihrer Legacy Systemen Web Service Mining dient dem Zweck sie ausfindig zu machen und wieder aufzubereiten [7] Um die bisherige Funktionalitaumlt fuumlr die Wiederverwendung mit Web-Services verfuumlgbar zu machen muss sie aus dem Kontext in dem sie implementiert wurde extrahiert und an die technischen Anforderungen einer service-orientierten Architektur angepasst werden Dies beinhaltet vier Schritte

bull Entdecken bull Bewerten bull Extrahieren bull Anpassen

21 Entdecken potentieller Web-Services Im Prinzip ist jede Funktion einer Legacy-Applikation ein potentieller Web-Service Man sollte dabei merken dass ein Groszligteil des Legacy-Codes aus technischen Funktionen besteht oder einer uumlberholten Art der Datenhaltung oder der Kommunikation dient Studien haben gezeigt dass dieser Code fast zwei Drittel des gesamten Codes ausmacht Dies laumlsst nur ein Drittel des Codes fuumlr die tatsaumlchliche Erreichung der Applikationsziele Dies ist der Code der fuumlr das Mining von Interesse ist Das Problem ist das dieser Code in hohem Grad vermischt ist mit dem technischen Code Innerhalb eines Code-Blocks etwa einer Methode einem Modul oder einer Prozedur koumlnnen sowohl Anweisungen fuumlr die Definition einer Datendarstellungsmaske sein als auch fuumlr die Berechnung der benoumltigten Werte Beim Durchsuchen des Codes muss das Analysewerkzeug die Anweisungen mit einem betriebswirtschaftlichen Wert entdecken [8] Andererseits sind nicht alle betrieblichen Funktionen korrekt Viele von ihnen werden uumlber die Jahre veraltet sein Das heiszligt dass der applikationsrelevante Code identifiziert werden muss er muss auch nach Guumlltigkeit gepruumlft werden

22 Bewertung potentieller Web-Services Ein weiteres Forschungsfeld ist die Bewertung der Code-Segmente die fuumlr potentielle Web-Services in Frage kommen Zunaumlchst muss der Verwalter des Codes entscheiden ob es sich uumlberhaupt lohnt Code-Fragmente aus dem System in dem sie sich befinden zu extrahieren Dies ist eine Frage der Wiederverwendbarkeit Es muumlssen Metriken entwickelt werden die Aussagen daruumlber treffen koumlnnen ob der Code wiederverwendbar ist oder nicht Der Autor hat sich um dieses Thema bereits gekuumlmmert und ein Paper dazu veroumlffentlicht [10] Die Schluumlsselmetrik ist die der Kapselungsfaumlhigkeit Ein Stuumlck Code ist kapselbar wenn es leicht aus seinem ihn umgebenden Code extrahiert werden kann In diesem Fall hat es wenige externe Funktionsaufrufe es erbt nichts und es teilt sich nur wenige Daten mit anderen Prozeduren Dies bedeutet dass man alle externen Funktionsaufrufe und alle Vererbungsbeziehungen zaumlhlen muss genauso wie alle nicht lokale Daten die auszligerhalb dieses Code-Blocks definiert werden Diese Zaumlhlung muss dann in Relation zu der Groumlszlige des Code-Blocks gemessen in Anweisungen gebracht werden Dies waumlre ein guter Ansatzpunkt aber es reicht nicht aus Es gibt noch die Fragen der Code-Qualitaumlt und des betrieblichen Wertes eines Code-Abschnitts zu klaumlren Es bleibt zu hinterfragen ob der Code qualitativ gut sowie wertvoll genug ist um in die neue Architektur uumlbernommen werden zu koumlnnen Der betriebliche Wert muss gemessen werden in dem gefragt wird wie wertvoll die von dem Code-Abschnitt produzierten Ergebnisse sind Es gab bisher nur wenig Forschung bezuumlglich dieser Frage Schlieszliglich muss berechnet werden was es kostet den Code zu extrahieren und dieses Ergebnis gegen den Wert der von ihm produzierten Ergebnisse gegenuumlbergestellt werden Dafuumlr werden Metriken bezuumlglich Wartbarkeit Testbarkeit Interoperatibilitaumlt und Wiederverwendbarkeit des Codes wie auch bezuumlglich des betriebswirtschaftlichen Wertes der jeweiligen Funktionalitaumlt benoumltigt 23 Extrahierung des Codes fuumlr den Web-Service Wurde ein Code-Fragment als potentieller Web-Service identifiziert ist der naumlchste Schritt es aus dem System zu extrahieren in dem es eingebettet ist Dies kann eine hochkomplexe Aufgabe werden aumlhnlich einer Organtransplantation besonders dann wenn der Code sich nicht als separate Einheit kompilieren laumlsst Prozedurale Module teilen sich globale Daten mit anderen Modulen im Hauptspeicher Sie koumlnnen auch andere Module aufrufen Alle diese Abhaumlngigkeiten muumlssen aufgeloumlst werden um den

Code aus seiner Umgebung extrahieren zu koumlnnen Objektorientierter Code ist generell leichter zu extrahieren als prozeduraler aber auch damit gibt es genug Probleme Eine spezielle Klasse kann Elemente houmlherstufiger Klassen erben die man nicht mit extrahieren moumlchte Auch kann eine Klasse die Methoden einer fremden Klasse aufrufen deren Ergebnisse wichtig fuumlr die weitere Verarbeitung sind Diese Abhaumlngigkeiten muumlssen entweder durch die Verflachung der Klassen ndash Class Flattening - oder durch Methodenauslagerung aufgeloumlst werden Wie auch immer keine dieser Loumlsungen ist einfach Ein schwieriges Problem bei der Extraktion von Code aus Legacy-Systemen ist die Isolierung von Features [11] Besonders in objektorientierten Systemen sind Features sprich Anwendungsfaumllle oft uumlber viele Klassen diverser Komponenten verteilt Eine Funktion ist eine Kette verteilter Methoden deren Aufruf durch ein Ereignis ausgeloumlst wird und ein vordefiniertes Ergebnis liefert Dieses kann die Antwort auf eine Abfrage oder das Ergebnis einer Berechnung sein wie in etwas ein Preis oder eine Bonitaumltsbewertung Um zu diesem Ergebnis zu gelangen muumlssen mehrere Methoden in verschiedenen Klassen in einer gegebenen Reihenfolge ausgefuumlhrt werden Diese Funktionstransplantation stellt die Reverse Engineering Forschungsgemeinde vor eine schwierige Aufgabe 24 Anpassung des Web-Service-Codes Das letzte Forschungsthema ist die Anpassung der extrahierten Code-Einheiten an die Anforderungen eines Web-Services Dies bedeutet dass dieser mit einer WSDL-Schnittstelle ausgestattet werden muss Die Eingabeparameter welche diese zuvor von einer Parameterliste einer Benutzerschnittstelle einer Eingabedatei oder einer anderen Form der Dateneingabe erhalten haben muumlssen nun als Argumente einer WSDL-Anfrage zugewiesen werden Dies bedeutet dass sie aus dem XML-Format der eingehenden SOAP-Nachricht konvertiert und in den internen Speicher des Web-Services geschrieben werden muumlssen Die Ausgabewerte die zuvor als Ausgabemasken Ruumlckgabewerte Ausgabedateien Berichte oder andere Formen der Datenausgabe ausgegeben wurden muumlssen nun einer WSDL-Antwort zugewiesen werden Dies impliziert dass sie aus dem internen Speicher des Web-Services in eine ausgehende SOAP-Nachricht im XML-Zeichenformat geschrieben werden muumlssen 3 Schlussfolgerung Dieser Beitrag hat verschiedene Strategien fuumlr die Gewinnung von Web-Services fuumlr eine service-orientierte Architektur herausgestellt Wie bereits darauf hingewiesen wurde koumlnnen sie gekauft gemietet geliehen entwickelt oder aus

vorhandenen Komponenten gewonnen werden Es gibt Vor- und Nachteile fuumlr jede dieser Methoden Die billigste und schnellste Loumlsung abgesehen vom Uumlbernehmen eines Web-Services aus der Open-Source-Gemeinde ist die Gewinnung aus existierenden Applikationen im Besitz des Anwenders Es existiert eine dringender Bedarf fuumlr Forschung im Bereich der Code-Wiedergewinnung Zunaumlchst sind Techniken fuumlr die Identifizierung von Code anhand der von ihm produzierten Ergebnisse noumltig Zweitens bedarf es Metriken fuumlr die Evaluierung der Wiederverwendbarkeit des identifizierten Codes Drittens muumlssen Werkzeuge entwickelte werden die in der Lage sind die funktional zusammenhaumlngenden Code-Abschnitte aus der Umgebung in der sie eingebettet sind zu extrahieren Letztlich werden Werkzeuge benoumltigt um den Code zu kapseln und an die Anforderungen eines Web-Services anzupassen Referenzen [01] Larson G ldquoComponent-based Enterprise Frameworksrdquo Comm Of ACM Vol 43 No 10 Oct 2000 p 25 [02] Pak-Lok PLau A ldquoThe Present B2C Implementation Frameworkrdquo Comm Of ACM Vol 49 No 2 Feb 2006 p 96 [03] von Mayrhauser AVans A ldquoIdentification of Dynamic Comprehension Processes in large scale Maintenancerdquo IEEE Trans on SE Vol 22 No 6 June 1996 p 424 [04] Bishop JHorspool N ldquoCross-Platform Development ndash Software that lastsrdquo IEEE Computer Oct 2006 p 26 [05] Aversano LCanfora GdeLucia A ldquoMigrating Legacy System to the Webrdquo in Proc of CSMR-2001 IEEE Computer Society Press Lisabon March 2001 p 148 [06] Sneed H ldquoWrapping Legacy COBOL Programs behind an XML Interfacerdquo Proc Of WCRE-2001 IEEE Computer Society Press Stuttgart Oct 2001 p 189 [07] Canfora GFasolino H Frattolillo G ldquoMigrating Interactive Legacy System to Web Servicesrdquo Proc of CSMR-2006 IEEE Computer Society Press Bari March 2006 p 23 [08] Sneed H rdquoIntegrating legacy Software into a Service oriented Architecturerdquo in Proc of CSMR-2006 IEEE Computer Society Press Bari March 2006 p 3 [09] Sneed H Erdoes K ldquoExtracting Business Rules from Source Coderdquo Proc of IWPC-96 IEEE Computer Society Press Berlin March 1996 p 240 [10] SneedH ldquoMeasuring Reusability of Legacy Softwarerdquo in Software Process Volume 4 Issue 1 March 1998 p 43 [11] Greevy ODucasse SGirba T ldquoAnalyzing Software Evolution through Feature Viewsrdquo Journal of Software Maintenance amp Evolution Vol 18 No 6 Dec 2006 p 425

Quelltextanalyse eines mittelgroszligen neuen Produktivsystems

Daniel Vinke Meik Teszligmer Thorsten SpittaUniversitaumlt Bielefeld

Fakultaumlt fuumlr Wirtschaftswissenschaftenpostdanielvinkede mtessmer|thspittawiwiuni-bielefeldde

AbstractEs wurde ein System von 200000 LOC auf OO-Maszlige hin analysiert und die Abhaumlngigkeiten der Maszlige statistisch analysiert Das System ist seit 2001 im Einsatz und wird auch zur Zeit noch (2007) evolutionaumlr weiter entwickelt Einige Befunde aus der neueren Literatur wurden bestauml-tigt einige praumlzisiert Wartungsintensive Klassen lassen sich zuverlaumlssig erkennen

1 EinfuumlhrungQuelltextanalysen sind nichts Neues (einen guten Uumlberblick gibt Zuse [91]) auch vor der Verbreitung objektorientierter Software Fuumlr objektorientierte Systeme braucht man spezifische Maszlige von denen die bdquoCK-Maszligeldquo von Chidamber und Kemerer [CK94] als allgemein akzeptiert gelten [SK03] Un-klar definiert ist das Maszlig LCOM [SK03 300] Es erwies sich bei einer Validation der CK-Maszlige als einziges als nicht signifikant [BBM96] An mittleren bis groszligen Systemen finden sich nur wenige Untersuchungen noch weniger an produkti-ven [Vin07 35] Neben einer umfangreichen Labor-untersuchung [DKST05] wurde nur eine Analyse der Browserfamilie Mozilla gefunden [GFS05] Bei-de Systeme sind in C++ geschrieben

2 UntersuchungsobjektDas von uns analysierte System BIS (Bielefelder In-formations-System) nennen wir mittelgroszlig 190000 LOC 1430 Java-Klassen 135 Packages Von den Anfaumlngen als Stundenplan-Verwaltungssystem fuumlr Studierende hat es sich inzwischen zum Raumpla-nungs- Veranstaltungsverwaltungs- bis zum Pruuml-fungsabwicklungssystem evolutionaumlr entwickelt Die Pruumlfungsabwicklung ist derzeit (Sommer 2007) noch recht rudimentaumlr ausgepraumlgt Groszlige Teile des Systems sind als Auskunftsystem im Internet sicht-bar httpeKVVuni-bielefelddeDa das System seit Ende 2003 unter Eclipse mit CVS weiterentwickelt und gepflegt wird sind wir im Projekt SQUARE (Software Quality and Refac-toring Environment) in der Lage die Systemzustaumln-

de seit Anfang 2004 in Form von Zeitreihen festzu-stellen um z B Aussagen uumlber Art und Verlauf der Evolution waumlhrend der Entwicklung zu machen Als erster Schritt war dazu eine Zeitpunkt-bezogene Analyse notwendig von der wir hier berichten

3 UntersuchungAnalysiert wurde der Stand des Systems vom Juni 2006 Wir wollten die CK-Maszlige erheben ihren Nut-zen mittels statistischer Analyse beurteilen und fuumlr das analysierte System kalibrieren Als Analysewerkzeug wurde Understand (for Java) verwendet Die Alternative Metrics (Sourceforge) schied aus da wir Quell- und keinen Bytecode ana-lysieren wollten Mit Understand hatten wir bereits Erfahrungen durch die Analyse eines deutlich groumlszlige-ren Systems (ca 1 Mio LOC) das in C++ geschrie-ben war [Teszlig04] Mittels Understand wurden alle CK-Maszlige ermittelt CBO Coupling between Objects LCOM Lack of Cohesion in Methods RFC Response for a Class DIT Depth of Inheritance Tree NOC Number of Children WMC Weighted Methods per Class NOM Number of Methods

Es zeigte sich dass die Daten fuumlr RFC nicht ver-wendbar waren weil das Maszlig von Understand falsch berechnet wird und dass LCOM nur bedingt verwendbar ist Es ist bereits in [CK 488] unpraumlzise definiert und wird von Understand als Prozentsatz ausgeben Dies waren jedoch keine Hindernisse fuumlr die Analyse weil wir ohnehin uumlber Regressionsana-lysen ermitteln wollten welche Maszlige fuumlr das Auf-finden wartungsintensiver Klassen benoumltigt werden Danach ist RFC entbehrlich weil es stark mit CBO und WMC korreliert istMit den ermittelten Maszligen (ohne RFC teilweise mit LCOM) wurde eine umfassende statistische Analyse mit dem System R durchgefuumlhrt und zwar univariat (Haumlufigkeiten Verteilungseigenschaften) bivariat (Korrelationsanalyse und Vergleich von jeweils

zwei Maszligen mit Toleranzgrenzen) und multivariat (Hauptkomponentenanalysen) Bild 1 zeigt ein Bei-spielplot von max(VG)1 gegen WMC Man sieht z B eine Klasse mit fast 200 Methoden links oben die aber nicht komplex ist Interessant in diesen Plots sind immer die Einzelpunkte links oben vor allem aber die rechts oben Dies sind die bdquoAusrei-szligerldquo die als wartungsintensiv interpretiert werden Wir zaumlhlen in Bild 1 davon acht

Bild 1 max(VG) korreliert mit WMC

Auszligerdem wurde Eclipse (mit 35 Mio LOC) analy-siert um die eigenen Kalibrierungen beurteilen zu koumlnnen Es enthaumllt 12000 Klassen davon einige mit mehr als 10000 LOC Wir haben eine Klasse mit max(VG) gt 1000 und drei mit VG gt 500 gefunden Strukturell sieht BIS in der Korrelationsanalyse zwi-schen WMC und CBO nicht schlechter aus als Eclipse

4 ErgebnisseFolgende Ergebnisse wurden ermittelt bzw Anga-ben aus der Literatur bestaumltigt LOC korreliert stark mit Komplexitaumlt Man findet wartungsintensive Klassen recht si-

cher mit mehreren Maszligen Diese sind mitein-ander korreliert

Diese Maszlige sind LOC max(VG) CBO und WMC (impliziert VG)

Das Interaktionsmaszlig DITCBO bringt wichtige Zusatzinformationen

1 Die Komplexitaumlt nach McCabe Die durchschnittliche Komplexitaumlt avg(VG) ist wenig aussagefaumlhig

Von den OO-Maszligen braucht man nur wenige es sind WMC und DITCBO

LCOM Nach der Interpretation durch Under-stand haben recht viele Klassen einen Kohaumlsi-onsmangel von uumlber 50 oft nahe 90

Im konkreten Fall des Systems BIS sind min-destens 70 (von rund 1400) Klassen wartungs-intensiv 5 halten wir fuumlr viel

5 AusblickEs besteht dringender Forschungsbedarf zur Kali-brierung der Maszlige denn unsere Vorschlaumlge bezie-hen sich nur auf einen Fall Klar ist dass in jedem Einzelfall kalibriert werden muss Es sollte aber To-leranzgrenzen nach einer Klassifikation geben (etwa groszlige kleine oder einfache komplexe Systeme)Die erwaumlhnten Laumlngsschnittuntersuchungen sind in Arbeit

Literatur[BBM96] Basili V R Briand L C Melo W L A

Validation of Object-Oriented Design Metrics as Quality Indicators IEEE Trans Software Eng 22 (10) 751-761 1994

[CK94] Chidamber S R Kemerer C F A Metrics Suite for Object Oriented Design IEEE Trans Software Eng 20 (6) 476ndash493 1994

[DKST05] Darcy D P Kemerer C F Slaughter S A Tomayko J E The Structural Complexity of Software An Experimental Test IEEE Trans Software Eng 31 (11) 982ndash995 2005

[GFS05] Gyimoacutethy T Ferenc R Siket I Empirical Validation of Object-Oriented Metrics on Open Source Software for Fault Prediction IEEE Trans Software Eng 31 (10) 897ndash910 2005

[Teszlig04] Teszligmer M Architekturermittlung aus Quell-code ndash Eine Fallstudie Diplomarbeit Universi-taumlt Bielefeld Technische Fak Jan 2004

[Vin07] Vinke D Quellanalyse eines mittelgroszligen Produktivsystems ndash Eine Fallstudie zur Quali-taumltssicherung Diplomarbeit Universitaumlt Biele-feld FakWirtschaftswissenschaften Maumlrz 2007

[Zus91] Zuse H Software Complexity Berlin et al de Gruyter 1991

JTransformer ndash Eine logikbasierte Infrastruktur zur Codeanalyse

Daniel Speicher Tobias Rho Guumlnter Kniesel Institut fuumlr Informatik III Universitaumlt Bonn Roumlmerstrasse 164 53117 Bonn

Email dsp rho gkiaiuni-bonnde

Kurzfassung Reengineering erfordert oft komplexe Analysen mit solider formaler Fundierung Je weiter das Abstrak-tionsniveau des Formalismus dabei von dem der Implementierung entfernt ist umso schwieriger ist die Implementierung und Wartung der Analyse JTransfomer bietet daher eine logikbasierte Infra-struktur zur Codeanalyse die eine angemessen di-rekte Umsetzung der formalen Grundlagen in aus-fuumlhrbaren Code erlaubt Dies demonstrieren wir am Beispiel der Vorbedingungen fuumlr generalisierende Refactorings

1 For Example Type Constraints Als Fallstudie betrachten wir das auf Typbeschraumln-kungen basierende Verfahren von Tip Kiezun und Baumlumer zur Entscheidung uumlber die Durchfuumlhrbarkeit generalisierender Refactorings [3]

Zur Illustration der Grundgedanken untersuchen wir im Beispiel in Abb 1 die Frage ob in der Me-thode m wirklich der konkrete Typ B verwendet werden muss oder ob auch der Obertyp A genuumlgen wuumlrde Der Aufruf der Methode p aus dem Typ A auf der Variablen x steht dem nicht im Wege Tat-saumlchlich erzwingt jedoch die Methode n indirekt die Verwendung des Typs B in Methode m da dort auf

dem Ergebnis von m eine Methode aus B aufgerufen wird Der Ansatz von [3] erlaubt es diesen Zusam-menhang formal abzuleiten

Abb 1 zeigt neben den unteren Codezeilen eine aus der jeweiligen Zeile abgeleitete Typbeschraumln-

kung ZB folgt aus der Zuweisung des Ruumlck-gabewertes von m an y (Zeile 16) dass der Ruumlck-gabewert von m ein Subtyp des Typs von y sein muss Aus den aufgefuumlhrten Ungleichungen ergibt sich die Ungleichungskette [x] le [Cm()] le [y] le B und damit die behauptete Notwendigkeit Die stati-schen Deklarationen des Typs von x oder y werden dabei nicht mit einbezogen weil diese ja gerade zur Disposition stehen

2 Logische Repraumlsentation und Analyse von Programmen

JTransformer [1] transformiert ein Java Programm in eine logische Faktenbasis die die Grundlage fuumlr Programmanalysen darstellt Wie in Abb 2 illus-triert wird dabei jeder Knoten des abstrakten Syn-taxbaumes eines Programms als ein logisches Fak-

tum darge-stellt 1 Das

Praumldikaten-symbol reprauml-sentiert den Typ des Kno-tens Der ers-te Parameter wird als eine

eindeutige Identitaumlt die-ses Knotens

verwendet Die anderen

Parameter sind entweder primitive Werte (Zahlen Namen) o-der Identitaumlten anderer Knoten die Referenzen auf diese Knoten darstellen2

Praumldikate koumlnnen auch ganz oder teilweise uumlber mitunter rekursive Ableitungsregeln definiert wer-den Somit ist der Uumlbergang von der Programmdar-stellung zu Analysen dieser Darstellung flieszligend

Der Begriff des sbquodeclaration elementrsquo bezeichnet in [3] die Deklaration des statischen Typs von Me-thoden Parametern Feldern und lokalen Variablen was sich in Prolog durch das folgende Praumldikat decl_element ausdruumlcken laumlsst3

1 Die Einruumlckung in Abb 2 hat keine Bedeutung sie verdeutlicht

lediglich die Schachtelung der Elemente Die gezeigte Faktendarstel-lung ist vereinfacht

2 So ist zum Beispiel das zweite Argument eines jeden Faktes eine Referenz auf den Elternknoten

3 Groszligschreibung in Regeln oder Fakten bezeichnet logische Vari-ablen Kleinschreibung Konstanten Die sbquoanonyme Variablersquo _ steht

1 package mini 2 3 class A Zuweisungen 4 void p() Methodenaufrufe und 5 Ruumlckgabeanweisungen 6 class B extends A stellen Bedingungen an 7 void q() die Typen [E] der betei- 8 ligten Ausdruumlcke E 9 10 class C 11 B m() 12 B x = new B() [new B()] le [x] 13 xp() [x] le A 14 return x [x] le [Cm()] 15 void n() 16 B y = m() [Cm()] le [y] 17 yq() [y] le B 18

Abb 1 Java Code mit Typbeschraumlnkungen

classDef(clsC pkgMini C) methodDef(mthM clsC m clsB) localDef(varX mthM clsB x newB) newClass(newB varX ctrB refB) ident(refB newB clsB) call(cllP mthM refX1 mthP) ident(refX1 cllP varX) return(retX mthM refX2) ident(refX2 retX varX) methodDef(mthN clsC n void) localDef(varY mthN clsB y cllM) call(cllM varY this mthM) call(cllQ mthN refY mthQ) ident(refY cllQ varY)

Abb 2 Fakten fuumlr C

decl_element(Elem Type) - methodDef(Elem _ _ Type) decl_element(Elem Type) - paramDef(Elem _ Type _ _) decl_element(Elem Type) - fieldDef(Elem _ Type _ _) decl_element(Elem Type) - localDef(Elem _ Type _ _)

Dies erlaubt erste Abfragen uumlber unser Beispiel - decl_element(mthM clsB) YES - decl_element(cllM clsB) NO - decl_element(Elem clsB) ctrB mthM varX varY

Die Abbildung eines Ausdrucks auf die Deklaration des davon referenzierten Elements wird durch das Praumldikat referenced_decl umgesetzt

referenced_decl(Ident RefElem) - ident(Ident _ RefElem) referenced_decl(Call CalledM) - call(Call _ _ CalledM) referenced_decl(Call CalledC) - newClass(Call_CalledC_)

3 Logikbasierte Umsetzung von sbquoType Constraintsrsquo

Im Beispiel muumlssen aufgrund der Verwendung der Methoden p und q die Variablen x und y mindestens den Typ A bzw B haben Die Zuweisungen und Er-gebnisruumlckgaben implizieren dann Typbeschraumln-kungen zwischen typdeklarierenden Elementen Daraus ergibt sich eine Ungleichungskette die zeigt dass auch x den Typ B haben muss Im Folgenden zitieren wir die entsprechenden formalen Definitio-nen und Implikationen aus [3] und geben dazu unse-re Implementierung an Der Typ eines Ausdrucks auf dem die Methode M aufgerufen wird muss ein Subtyp sein von Decl(RootDef(M)) dh des allgemeinsten Typs der eine Deklaration von M enthaumllt4

(Call) call Em() to a virtual method M rArr [E] le Decl(RootDef(M))

Gegeben eine Implementierung von RootDef ist das folgende Praumldikat eine direkte Umsetzung

constrained_by_type(Elem Type) - call(_ _ CalledOn CalledMethod) referenced_decl(CalledOn Elem) root_definition(CalledMethod RootMethod) methodDef(RootMethod Type _ _)

Zuweisungen implizieren eine Subtyprelation zwi-schen den Typen der Ausdruumlcke rechts und links

(Assign) E1 = E2 rArr [E2] le [E1] Auch diese Implikation laumlsst sich umsetzen

constrained_by(Lower Upper) - assign(_ _ LHS RHS) referenced_decl(LHS Upper) referenced_decl(RHS Lower) constrained_by(Lower Upper) - localDef(Upper _ _ _ InitExpression) referenced_decl(InitExpression Lower)

fuumlr beliebige Werte Jede Regel ist als Implikation von rechts nach links zu lesen So bedeutet zB die erste Regel bdquoWenn Elem eine Methodendefinition mit Ruumlckgabetyp Type ist dann ist Elem ein typdeklarierendes Element mit deklariertem Typ Typeldquo Mehrere Regeln fuumlr das gleiche Praumldikat sind disjunktiv verknuumlpft

4 Der Kuumlrze der Darstellung halber ignorieren wir im Folgenden multiple Subtypbeziehungen und verzichten auf die Angabe der Praumldikate root_definition und subtype

Der Typ des Ruumlckgabeausdrucks einer Methode muss ein Subtyp des deklarierten Ruumlckgabetyps sein

(Ret) return E in method M rArr [E] le [M] constrained_by(Lower Upper) - return(_ Upper Expression) referenced_decl(Expression Lower)

Die Menge der typdeklarierenden Elemente deren deklarierter Typ C sich nicht durch einen allgemei-neren Typ T ersetzen laumlsst umfasst alle Elemente die Subtypen einer Klasse Crsquo sein muumlssen die nicht Obertyp von T ist Hinzu kommen alle Elemente die Subtypen eines solchen nicht generalisierbaren Ele-ments sein muumlssen

(Gen) Bad(PC T) = E | E isin All(PC) and [E] le Crsquo isin TCfixed(P) and not T le Crsquo cup E | E isin All(PC) and [E] le [Ersquo] isin TCfixed(P) and Ersquo isin Bad(PC T)

Das Praumldikat not_generalizable setzt diese Defintion um Die unterstrichenen Ausdruumlcke entsprechen da-bei den jeweiligen Constraint-Praumldikaten

not_generalizable(Element GeneralizedType) - constrained_by_type(Element Type) not( subtype(GeneralizedType Type) ) not_generalizable(Element GeneralizedType) - constrained_by(Element Upper) not_generalizable(Upper GeneralizedType)

Fazit Dieser Beitrag gibt eine Idee davon dass die in JTransfomer realisierte logikbasierte Umgebung die Implementierung komplexer Programmanalysen vereinfacht und die Ruumlckverfolgbarkeit zur jeweili-gen theoretischen Grundlage foumlrdert Die Erweiter-barkeit gewinnt ebenso So ist es ein Leichtes auch die Hindernisse einer Typgeneralisierung zu finden

constrained_by(Lower Type Reason Rule) - Reason = Call Rule = lsquo(Call)rsquo call(Call _ CalledOn CalledMethod) hellip weiter wie vorhin hellip

Die Effizienz und Skalierbarkeit des Ansatzes wurde in [2] anhand von Design Pattern-Detection de-monstriert Das System unterstuumltzt auch Programm-transformationen und wurde erfolgreich eingesetzt fuumlr die Implementierung von Refactorings Aspekt-orientierung Designmetriken Pattern-Mining sowie Bad Smell- Clone- und Refactoring-Detection

Literatur [1] JTransformer-Project

httprootsiaiuni-bonnderesearchjtransformer [2] G Kniesel J Hannemann T Rho A Comparison of

Logic-Based Infrastructures for Concern Detection and Extraction LATE07 March 12-16 2007 Vancouver BC

[3] Frank Tip Adam Kiezun Dirk Baumlumer Refactoring for Generalization Using Type Constraints In Proceedings of the 18th OOPSLA pages 13ndash26 ACM Press 2003

SW-Archaologie mit AOP (Praxisbericht)

Author Oliver L Bohm

agentes AG Stuttgart

oliverboehmagentesde

April 21 2007

Abstract

Alte Software birgt oft viele Geheimnisse Wennman Gluck hat lasst sich zum Code der untersuchtund erweitert werden soll noch die Dokumentationdazu auftreiben Und wenn man sehr viel Gluckhat stimmt die Dokumentation sogar mit dem Codeuberein

Leider sieht die Realitat allzu oft anders aus dieDokumentation ist hoffnungslos veraltet die Ent-wickler von damals sind nicht mehr aufzutreibenund auch sonst gibt es niemanden den man fragenkonnte Das einzige worauf man sich verlassen kannist der Sourcecode Aber leider ist dieser oft un-verstandlich

Es gibt verschiedene Moglichkeiten dem Codeseine Geheimnisse zu entreiszligen Ein vielversprechen-der Ansatz ist dabei der Einsatz von Aspekte umunbekannte Codestellen zu erschlieszligen und das Pro-grammverhalten zu ergrunden

1 Die klassische Herangehensweise

Meist ist die Dokumentation oft die erste Anlauf-stelle um sich mit einer Alt-Anwendung vertraut zumachen Auch wenn sie oftmals von der Realitat ab-weicht gibt sie doch einen wertvollen Einblick undwichtige Informationen die den Einstieg in die The-matik erleichtern Vor allem Ubersichts-Dokumenteuber die Architektur Infrastruktur und Randbedin-gen sind hier sehr hilfreich

Um festzustellen inwieweit der Code tatsachlichmit der Dokumentation ubereinstimmt sind Testfalle(sofern vorhanden) von eminenter Bedeutung Siebilden den Ausgangspunkt um verschiedene Pro-grammteile zu erkunden und deren Verhalten zustudieren Die meisten Schwierigkeiten bestehenmeist darin die Testfalle zum Laufen zu bringen

Hat man die Tests am Laufen kann man sichan Refactoring-Maszlignahmen wagen mit dem Ziel dieBusinesslogik starker zum Vorschein zu bringen unddie Lesbarkeit und Wartbarkeit zu erhohen Vor allemJ2EE-Anwendungen sind oftmals over-designed waseine Einarbeitung meist erschwert

Mit den neuen Erkenntnisse sollte nochmal dieDokumentation begutachtet werden welche Doku-mente mussen uberarbeitet welche Dokumente

konnen ausgemistet oderund in Form von neuenTestfallen ausgedruckt werden

2 Unterstutzung durch AOP

Der groszligte Manko bei Altanwendungen (und nicht nurdort) sind die Testfalle Meistens fehlen sie oder sindgenauso veraltet wie die Dokumentation Ist die An-wendung noch in Betrieb kann man versuchen da-raus Testfalle fur die weitere Entwicklung abzuleitenUnd genau hier kann AOP helfen fehlende Log-Informationen zu erganzen oder die Kommunikationmit der Umgebung aufzuzeichen

21 Schnittstellen beobachten

Die interessanten Stellen sind vor allem dieSchnittstellen zur Auszligenwelt Bei J2EE-Applikationen sind dies meist andere Systemewie Legacy-Anwendungen oder Datenbanken dieuber das Netzwerk angebunden werden Hier reichtes oft aus die Anwendung ohne Netzwerkverbindungzu starten und zu beobachten wo uberall ExceptionsauftretenjavanetSocketException javanetConnectException Connection refused

at commysqljdbcStandardSocketFactoryconnect(StandardSocketFactoryjava156)

at commysqljdbcMysqlIOltinitgt(MysqlIOjava283)

at commysqljdbcConnectioncreateNewIO(Connectionjava2541)

at commysqljdbcConnectionltinitgt(Connectionjava1474)

at commysqljdbcNonRegisteringDriverconnect(NonRegisteringDriverjava264)

at javasqlDriverManagergetConnection(DriverManagerjava525)


at bankArchivinit(Archivjava25)

Aus dieser Exception kann man erkennen dassdie Anwendung auf eine MySQL-Datenbank zugreiftaber kein Connection-Objekt vom DriverManagerbekam Mit diesem Wissen kann man sich alleConnection-Aufrufe genauer unter die Lupe nehmenafter() returning(Object ret)

call( javasqlConnection()) logdebug(getAsString(thisJoinPoint) + = + ret)

Mit dieser Anweisung wird am Ende jedesConnection-Aufrufs der Aufruf selbst mitsamtseinen Parametern (z B SELECT-Statements) undRuckgabewert ausgegeben (uber die getAsString()-Methode hier nicht abgebildet) Ahnlich kann manbei Netz- bzw Socket-Verbindungen verfahren manerweitert die Stellen (im AOP-Jargon ldquoJoinpointsrdquogenannt) uber die Daten ausgetauscht werden

Handelt es sich um eine interne Bibliothek oderFramework das es zu betrachten gilt sind vor allem

die offentlichen Schnittstellen von Interesse Hierkann man mit Aspektorientierten Sprachmitteln alldie Methodenaufrufe ermitteln die tatsachlich vonauszligerhalb aufgerufen werden ndash denn oft sind nichtalle Methoden die als ldquopublicrdquo deklariert sind furden Aufruf von auszligen vorgesehenpublic pointcut executePublic()

(execution(public bank())

|| execution(public banknew()))ampamp within(EnvironmentAspect)

public pointcut executeFramework() execution( bank()) || execution(banknew())

public pointcut calledFromOutside()

executePublic() ampamp cflowbelow(executeFramework())

before() calledFromOutside() Signature sig = thisJoinPointgetSignature()String caller =

getCaller(ThreadcurrentThread()getStackTrace() sig)loginfo(caller + calls + sig)

Hier werden alle Methoden eines Bank-Frameworks(bank-Package) uberwacht Nur wenn der Aufrufnicht von innerhalb kam (cflowbelow) wird vorder Ausfuhrung der Methode oder Konstruktor derAufrufer anhand des Stacktraces ermittelt (MethodegetCaller() hier nicht aufgelistet)

jspindex_jsp_jspService(index_jspjava54) calls bankKonto(int)

jspindex_jsp_jspService(index_jspjava58) calls void bankKontoeinzahlen(double)

jspindex_jsp_jspService(index_jspjava60) calls double bankKontoabfragen()

Dies ist die Ausgabe die den Aufruf aus einerJSP zeigt Lasst man die Anwendung lang genuglaufen erhalt man so alle Methoden die von auszliger-halb aufgerufen werden

22 Daten aufnehmen

Mit Java ist es relativ einfach moglich Objekte abzus-peichern und wieder einzulesen Damit lasst sichein einfacher Objekt-Recorder bauen um damit dieSchnittstellen-Daten aufzunehmenafter() returning(Object ret) sqlCall()

objLoggerlog(thisJoinPoint)

objLoggerlog(ret)

Hinter thisJoinPoint verbirgt sich der Context derAufrufstelle die der AspectJ-Compiler (eine AO-Sprache die auf Java aufbaut s a [Boh05]) als Ob-jekt bereitstellt

23 Aufnahmedaten einspielen

Wenn man die notwendigen Schnittstellen-Datengesammelt hat kann man anhand dieser Daten einen(einfachen) Simulator bauen Man kennt die Punkteuber die diese Daten hereingekommen sind man mussjetzt lediglich an diesen Punkte die aufgezeichnetenDaten wieder einspielenObject around() sqlCall()

Object logged = logAnalyzergetReturnValue(thisJoinPoint)return logged

Hat man so die Anwendung von der Aussen-welt isoliert und durch Daten aus fruheren Laufensimuliert kann man das dynamische Verhalten der

Anwendung genauer untersuchen So kann man weit-ere Aspekte hinzufugen die automatisch Sequenz-Diagramme erzeugen oder wichtige Programmzweigevisualisieren

24 Code-Anderungen

Nach diesen Vorbereitungen kann mit den erstenCode-Anderungen (Refactorings[Fow01]) begonnenwerden Soll der Original-Code (noch) unverandertbleiben (was bei unbekannter Abdeckungen vorhan-denen Testfallen sinnvoll sein kann) liefert die As-pektorientierung die Moglichkeit den Code getrenntvom Original abzulegen Man kann sogar verschiedeneVarianten einer Komponente vorhalten und diesewahrend der Laufzeit austauschen Auf diese Weisekann man experimentell verschiedene Varianten undCode-Manipulationen ausprobieren um deren Verhal-ten auf die Gesamt-Anwendung studieren zu konnen

3 Fazit

Der Aufwand sich in unbekanntem Code einzuar-beiten wird haufig unterschatzt Langfristig ist esmeist wirtschaftlicher vorhandenen Code komplettneu zu entwickeln wenn die Dokumentation veraltetist der Code an vielen Stellen ausgewuchert ist undauch die Testfalle nicht vorhanden oder von zweifel-hafter Qualitat sind

Oftmals hat man aber keine andere Wahl als aufden bestehenden Code aufzusetzen weil er die einziggultige Quelle der Dokumentation darstellt Undhier bietet die Aspektorientierung eine Vielzahl vonMoglichkeiten um

bull zusatzliche Log-Moglichkeiten einzubauen

bull Schnittstellen zu uberwachen

bull Objekt-Recorder zu implementieren und im-plantieren

bull die aufgenommenen Objekte wieder einzuspielen

bull u v m

Daraus lassen sich weitere Testfalle schreibenund neue Erkenntnisse gewinnen um Refactoring-Maszlignahmen einzuleiten oder sich fur eine Neuen-twicklung zu entschlieszligen Allerdings entbindet auchAOP nicht von der Aufgabe bestehenden und neuenCode so zu gestalten und umzuformen dass kunftigeGenerationen damit glucklich werden

References

[Boh05] Oliver Bohm Aspekt-Orientierte Program-

mierung mit AspectJ 5 dpunktverlag 1 edi-tion 2005 ISBN-10 3-89864-330-15

[Fow01] Martin Fowler Refactoring Addison-Wesley7 edition 2001 ISBN 0-201-48567-2

JINSI Isolation fehlerrelevanter Interaktion in Produktivsystemen

Martin Burger mburgercsuni-sbdeUniversitat des Saarlandes Fachrichtung Informatik

Saarbrucken Deutschland

1 Einleitung

Die Fehlerbeseitigung in einem Softwaresystem be-ginnt zumeist mit der Reproduktion des Fehlers Beieinem Produktivsystem ist dies besonders schwierigda es von zahlreichen Diensten wie zB Datenbankenabhangt Daher kann das System nicht ohne weite-res unter Laborbedingungen gestartet und beobach-tet werden Wir schlagen als Hilfsmittel fur JAVA-Systeme JINSI vor JINSI fuhrt Teilkomponenten ei-nes Produktivsystemes unter Laborbedingungen ausDazu zeichnet es zunachst die Interaktion dieser Kom-ponente mit ihrer Umgebung im Produktivbetrieb aufund versorgt sie spater im Laborbetrieb mit dieser In-teraktion Dort kann die Komponente nicht nur nachBelieben ausgefuhrt werden sondern JINSI ermitteltauch den Bruchteil der Interaktion der tatsachlichfehlerrelevant ist Damit automatisiert JINSI zwei we-sentliche Aufgaben der Fehlersuche die Reproduktionund die Isolation eines Fehlers

Bisherige Arbeiten zeichnen ganze Programm-zustande auf um einen Lauf zu wiederholen und zuuntersuchen Hierbei fallen allerdings sehr groszlige Da-tenmengen an Eine weitere Moglichkeit um relevan-te Daten wie Parameter und Ruckgabewerte zu spei-chern besteht in der Serialisierung von Objekten Die-se ist allerdings bezuglich Speicher und Zeit sehr teu-er Die von JINSI aufgezeichnete Datenmenge ist imVergleich winzig da es die zu speichernden Daten aufein Minimum beschrankt (1) es werden nur die Ob-jekte gespeichert die Einfluss auf die Berechnung ha-ben und (2) JINSI benotigt nur Objekt-Ids Typenund skalare Werte fur die spatere Wiedergabe Da-durch werden benotigter Speicher und Zeit drastischreduziert was das Aufzeichnen in Produktivsystemenerlaubt

JINSI arbeitet erfolgreich auf groszligen Systemen wiedem ASPECTJ-Compiler Mit unseren Ansatz betragtder Faktor fur den zeitlichen Mehraufwand durch dasAufzeichnen nur 11 bis etwa 2 JINSI konnte in ers-ten Versuchen die Interaktion auf wenige fehlerrelvan-te Methodenaufrufe minimieren

2 JINSI

Mittels Instrumentierung zieht JINSI1 zunachst eineGrenze zwischen einer Komponente und ihrer Umge-

1Fur ldquoJINSI Isolates Noteworthy Software InteractionsrdquoldquoJinsirdquo ist auch Suaheli und bedeutet ldquoMethoderdquo

Komponente

ProtokollEreignisse

Software-SystemKomponente

Software-System

JINSI

1 ndash Produktiv

2 ndash Produktiv

ExterneDienste

ExterneDienste

Komponente

JINSI (Delta Debugging)

Interaktion

3 ndash Labor

Abbildung 1 Eine Komponente in einem Softwaresys-tem (1) wird mittels Instrumentierung abgegrenzt Danachkann JINSI die Interaktion im Produktiveinsatz abfangenund aufzeichnen (2) Im Labor kann der Fehler reprodu-ziert und isoliert werden (3)

bung (Abb 1) die Definition einer Komponente er-folgt durch Auswahl von Klassen oder Paketen JINSI

identifiziert die dortige Interaktion und instrumentiertden Bytecode so dass ein- und ausgehende Ereignis-se wie Methodenaufrufe Ruckgabewerte und Feldzu-griffe abgefangen werden Die Instrumentierung stelltauch sicher dass nur Ereignisse aufgezeichnet werdendie die Grenze passieren Die notwendige Instrumen-tierung kann vor Auslieferung oder auch zur Laufzeitim Produktivbetrieb geschehen und dauert auch beigroszligen Systemen nur wenige Sekunden So kann dieerneute Definition einer alternativen Grenze schnellerfolgen

Daten die wahrend der Ausfuhrung die Grenzepassieren konnen von skalaren Werten bis zu komple-xen Objektgraphen reichen Das Speichern von kom-pletten Objekten ist sehr aufwendig So ist Serialisie-rung hinsichtlich Zeit und Speicher kostspielig JINSI

speichert stattdessen fur Objekte die fur die Berech-nung relevant sind lediglich eine eindeutige Id undden Typ Da auch alle ausgehenden Ereignisse aufge-zeichnet werden sind genugend Informationen fur dasspatere Abspielen vorhanden Wird beispielsweise einausgehender Methodenaufruf abgefangen so wird derRuckgabewert aufgezeichnet Wahrend der Wiederga-be ist der reale Wert nicht vonnoten JINSI kann dann

den passenden Ruckgabewert liefern entweder einenskalaren Wert oder ein passendes Objekt2 Durch die-ses teilweise Aufzeichnen fallt der Faktor des zeitli-chen Overheads mit etwa 11 bis 2 klein aus und diein XML gespeicherten Ereginisse sind auch bei langenLaufen komprimiert maximal einige Megabyte groszlig

Vor dem Abspielen wird die Komponente erneutinstrumentiert so dass ausgehende Konstruktorauf-rufe und Feldzugriffe behandelt werden konnen Mit-tels der aufgezeichneten Interaktion kann dann derfehlerhafte Lauf auf der Komponente nach Beliebenwiederholt werden Diese Interaktion kann aber sehrviele irrelevant Ereignisse umfassen zB wenn es sichum einen lange laufenden Serverdienst handelt JINSI

nutzt Delta Debugging (Zeller 2005) um die Men-ge der Ereignisse durch systematisches Wiederholendes Laufes zu minimieren Dabei werden alle nicht re-levanten eingehenden Methodenaufrufe beseitigt Dadie Isolation ohne Umgebung also zB ohne Anfragenan eine Datenbank geschieht kann der Fehler inner-halb weniger Sekunden bis Minuten vollautomatischeingegrenzt werden

Nach der Reduzierung auf die relevanten Ereignissekann JINSI einen minimalen JUNIT Testfall erzeugender den Fehler in einer IDE wie ECLIPSE reproduziertDort konnen alle verfugbaren Werkzeuge genutzt wer-den um den Defekt zu beseitigen

3 Andere Arbeiten

JINSI ist der erste Ansatz der das Aufzeichnenund Abspielen von Komponenteninteraktion mit derIsolierung relevanter Methodenaufrufe kombiniertFruhere Arbeiten behandeln diese Ansatze getrenntLei and Andrews (2005) nutzen Delta Debugging umeine zufallige Sequenz von Methodenaufrufen zu mi-nimieren im Gegensatz zu zuvor unter realen Bedin-gungen aufgezeichneten Interaktionen Delta Debug-ging beschreibt allgemein die Isolierung fehlerrelevan-ter Umstande (Zeller 2005) Omniscient Debuggingzeichnet alle Zustande eines Laufes auf (Lewis 2003)JINSI reduziert den Lauf auf relevante Aufrufe diesekonnen mit ahnlichen Techniken untersucht werdenSCARPE (Orso and Kennedy 2005) ist ein Werkzeugfur das selektive Aufzeichnen und Abspielen von In-teraktion in JAVA-Programmen JINSI nutzt ahnlicheTechniken (Orso et al 2006)

4 Ergebnisse und Ausblick

JINSI implementiert eine kombinierte Losung fur zweinicht triviale Aufgaben Reproduzieren eines Fehlersund Beschranken auf die fehlerrelevante Komponen-teninteraktion Aus dieser Interaktion wird ein mi-nimaler JUNIT-Testfall erzeugt der den Fehler re-produziert Unser Ansatz kann fur komplexe Syste-

2JINSI verwendet hier sog Mockobjekte Diese implemen-tieren die Schnittstelle des echten Objektes ahmen das eigent-liche Verhalten aber nur nach das Verhalten kann von auszligenvorgegeben werden

me im Produktiveinsatz angewandt werden und er-laubt die Analyse eines realen Fehlers im Labor Ne-ben ASPECTJ haben wir JINSI bereits erfolgreich aufdem E-Mail-Programm COLUMBA angewandt

Durch die begrenzte Beobachtung einer Kom-ponente und die Aufzeichnung weniger Objekt-Informationen wird die Menge der anfallenden Da-ten gering gehalten Werden alle Interaktionen derzentralen ASPECTJ-Klasse BcelWorld beim Kompi-lieren des Timing Aspektes des mitgelieferten Bei-spieles ldquoTelecom Simulationrdquo3 aufgezeichnet so wer-den 5496 Ereignisse abgefangen Diese sind als gzip-komprimierte XML-Datei lediglich 68 Kilobyte groszlig

Die Instrumentierung der 3494 Klassen umfassen-den Datei aspectjtoolsjar dauert auf einem iMac mitIntel 20GHz Core Duo CPU nur 208s Das Kompilie-ren des Aspektes benotigt mit der originalen Biblio-thek 21s mit der instrumentierten 45s Hier betragtder Faktor des zeitlichen Overheads 21 In langer lau-fenden Programmen ist mit einem Faktor von 11 bis12 zu rechnen

Mittels der aufgezeichneten Ereignisse kann einFehler reproduziert werden JINSI hat in ersten Ver-suchen diese Interaktionen minimieren konnen Derdaraus resultierende JUNIT-Testfall umfasst nur eini-ge wenige Methodenaufrufe auf der fehlerhaften Kom-ponente

JINSI ist noch ein Prototyp und wird weiterent-wickelt Eine Fallstudie mit dem Benchmark iBugs4welcher 369 echte Fehler in ASPECTJ enthalt soll denNutzen belegen Neben der Minimierung ausgehenderInteraktion erscheint die von eingehender Interaktioninteressant um die Menge der relevanten Ereignisseweiter einzugrenzen Eine Integration in ECLIPSE alsPlug-In soll den Ansatz frei verfugbar machen

Literatur

Y Lei and J H Andrews Minimization of randomizedunit test cases In Proc 16th IEEE Intl Symp on Soft-ware Reliability Engineering 2005

B Lewis Debugging backwards in time In Proc 5thInt Workshop on Automated and Algorithmic Debug-ging 2003

A Orso and B Kennedy Selective Capture and Replayof Program Executions In Proc of the 3rd Intl ICSEWorkshop on Dynamic Analysis 2005

A Orso S Joshi M Burger and A Zeller Isolating rele-vant component interactions with jinsi In Proc of the4th Intl ICSE Workshop on Dynamic Analysis 2006

A Zeller Why Programs Fail A Guide to Systematic De-bugging Morgan Kaufmann 1st edition 2005

3httpwwweclipseorgaspectjdocreleased

progguideexamples-productionhtml Version 1534httpwwwstcsuni-sbdeibugs

Erzeugung dynamischer Objektprozessgraphen zur Laufzeit

Jochen QuanteArbeitsgruppe Softwaretechnik


quanteinformatikuni-bremende

1 Einfuhrung

Objektprozessgraphen beschreiben den Kontrollflusseines Programms aus Sicht eines einzelnen ObjektsSie enthalten Informationen daruber wie Objekte be-nutzt werden und wie diese Benutzungen in Bezie-hung zueinander stehen Damit konnen sie fur dasProgrammverstehen hilfreich sein (zB Protokoller-kennung Visualisierung) Allerdings ist die Extrak-tion solcher Graphen sehr aufwandig Wir stellen eineneue dynamische Extraktionstechnik vor die entspre-chende Graphen schon wahrend des Programmlaufsaufbaut und damit neue Anwendungen ermoglicht

2 Extraktion dynamischer Objektpro-zessgraphen

Ein Objektprozessgraph ist ein Teilgraph des in-terprozeduralen Kontrollflussgraphen der nur dieKnoten und Kanten enthalt die fur den Kontroll-fluss aus Sicht eines bestimmten Objekts relevantsind [2] Zur dynamischen Extraktion eines solchenGraphen wird zunachst das zu analysierende Pro-gramm so instrumentiert dass alle Kontrollfluss-und Objekt-relevanten Informationen erfasst wer-den Indem Instrumentierungspunkte auf Knoten undAusfuhrungsbeziehungen auf Kanten abgebildet wer-den kann daraus ein entsprechender ldquoRohgraphrdquo kon-struiert werden der durch Transformationen zum dy-namischen Objektprozessgraphen (DOPG) wird Dasgenaue Verfahren ist in [2] beschrieben Abb 1 zeigtein Beispiel fur die Konstruktion eines solchen Gra-phen wahrend der Transformation

Im bisherigen Ansatz (ldquoOfflinerdquo) werden die In-formationen aus der Instrumentierung in eine Dateigeschrieben und erst nach Programmende analysiertDer grobe Ablauf ist in Abb 2(a) skizziert Er bein-haltet einige aufwandige Schritte

bull Schreiben der Protokolldatei mit ca 1-6 Mio Er-eignissen pro Sekunde Dieser Schritt kann durchKompression und Pufferung beschleunigt werden

bull Herausfiltern der relevanten Daten fur einzel-ne Objekte Die ursprungliche Protokolldateienthalt die Daten fur alle gewahlten Objekte

bull Einlesen der gefilterten Daten zur Konstruktiondes Graphen

void main() int i = 0

S s1 = new S()

s2 = Sread()

reverse(s2 s1)

do s1pop()

i = i + 1

while (s1empty())

reverse(S from S to) while (fromempty())

topush(frompop())

(a) Quelltext

main

i=0

call

s1pop()

i = i+1

s1empty()

F

T

F

T

reverse

s1 = new S()

i=0

s2 = Sread()

call

i = i+1

F

T

fromempty()

frompop()

topush()

s1 = new S()

s1empty()

s1pop()

topush()

(b) DOPG fur s1

Abbildung 1 Quelltext und DOPG fur Anwendung ei-nes Stack-Objekts Die durchkreuzten Knoten werden imnachsten Schritt entfernt

Um die Konstruktion zu beschleunigen schlagenwir ein Verfahren vor das auf das Schreiben derProtokolldatei verzichtet und die Graphen aufbautwahrend das Programm noch lauft Dies wird im fol-genden genauer beschrieben

3 Extraktionsalgorithmus

Die Konstruktion des Graphen zur Laufzeit ist inAbb 2(b) skizziert und verlauft in folgenden Schritten(Details in [1])

bull Mitfuhrung eines Graphen der den aktuellenAufrufpfad beschreibt Dazu wird anhand derauftretenden Ereignisse ein Graph konstruiert(wie oben beschrieben) Wird eine Methode wie-der verlassen so wird der gesamte Methodenauf-ruf aus dem Graphen entfernt

bull Wenn eine zu beobachtende Klasse instanziiertwird so wird dieser Graph kopiert Die Kopiestellt den konkreten ldquoRohgraphrdquo fur dieses Ob-jekt dar

bull Fur alle weiteren Ereignisse werden sowohl zumAufrufpfad-Graph als auch zu allen Objekt-Graphen entsprechende Kanten und Knoten hin-zugefugt Dabei werden Objekt-spezifische Ope-

programrunning

tracetraceobject

graphraw

DOPG

programrunning

DOPGgraphraw

graphraw

graphraw

filter graph

construction transform

grapheventsa)

b)events graph

transformtrace

graph construction

with filter

Abbildung 2 Offline- (a) und Online-Verfahren (b) im Vergleich

rationen nur auf den zugehorigen Graphen ange-wendet Bei den Kopien werden Methodenaufru-fe nur dann entfernt wenn der jeweilige Aufrufnicht relevant war Relevant ist ein Aufruf genaudann wenn er den Aufruf einer Methode oder denZugriff auf ein Attribut des Objekts oder einenrelevanten Aufruf enthalt

Damit wird zu jeder Instanz einer zu beobachten-den Klasse ein eigener Graph mitgefuhrt Die Da-tenstrukturen werden so gewahlt dass ein effizien-tes Prufen und Hinzufugen von Methodenaufrufenmoglich ist Da Java-Programme analysiert werdensollen muss bei der Implementierung auch Multi-threading berucksichtigt werden Dies bedeutet dassder Graph moglicherweise an mehreren Stellen gleich-zeitig erweitert wird

4 Fallstudie

Wir vergleichen nun den Laufzeitoverhead der Online-und Offline-Extraktionstechniken anhand mehrererBeispiele Dazu werden drei Java-Anwendungen un-terschiedlicher Groszlige betrachtet ArgoUML J (einEditor) und JHotDraw Fur jede der Anwendungenwerden verschiedene Klassen herausgegriffen und furderen Instanzen DOPGs sowohl mit der Online- alsauch mit der Offline-Variante erzeugt Die benotigteCPU-Zeit wird gemessen Da es sich bei allen Anwen-dungen um interaktive Systeme handelt werden alleSzenarien mehrfach durchlaufen und Mittelwerte ge-bildet um Variationen in der Bedienung auszuglei-chen

Abb 3 zeigt die Ergebnisse dieser Studie Der durchdie Instrumentierung verursachte Laufzeitoverhead istsehr unterschiedlich Fur J liegt er zwischen Faktor 7und 22 wahrend er fur JHotDraw bei 2 bis 3 liegt Inden meisten Fallen ist die Online-Variante aber min-destens genauso performant wie die Offline-VarianteIn allen Fallen waren die Anwendungen ohne groszligereVerzogerungen weiterhin benutzbar

Fur das Szenario ldquoQuadrdquo brauchte die Online-Extraktion mehr Rechenzeit als fur die Offline-Variante Dies liegt darin begrundet dass in diesemFall zehn Instanzen parallel verfolgt wurden wahrendin den anderen Fallen nur fur jeweils eine Instanz einGraph erstellt werden musste Dies deutet darauf hindass die Online-Extraktion insbesondere in Fallen mitwenigen zu verfolgenden Objekten sinnvoll einsetzbarist

Tabelle6

Seite 28

Ed 0 Ed 1 Java 0 Java 1

0

5

10

15

20

25

30

J Editor

filter

instr

original

Zoom0 Zoom1 Quad 0 Quad 1

0

1

2

3

4

5

6

JHotDraw

filter

instr

original

CD 0 CD 1 SD 0 SD 1 Proj 0 Proj 1

0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Abbildung 3 Ergebnisse der Fallstudie Auf der Y-Achseist der Laufzeitoverhead (schwarz) als Faktor im Vergleichzur normalen Laufzeit angegeben Der linke Balken (0)steht jeweils fur die Offline-Extraktion der rechte Balken(1) fur die Online-Variante Fur die Offline-Extraktion istzusatzlich die Zeit fur das Filtern angegeben (grau)

5 Fazit

Die Fallstudie zeigt dass die Konstruktion von dy-namischen Objektprozessgraphen in der Praxis effizi-ent moglich ist In vielen Fallen insbesondere bei ei-ner geringen Anzahl betrachteter Objekte bremst dieOnline-Extraktion das beobachtete Programm weni-ger als das reine Schreiben der Protokolldatei Damitergeben sich ganz neue AnwendungsmoglichkeitenDie Graphen konnen zur Laufzeit visualisiert werdenund so einen Einblick geben wie sich bestimmte Be-nutzeraktionen in Bezug auf ein Objekt auswirken

Literatur

[1] Jochen Quante Online construction of dynamicobject process graphs In Proc of 11th CSMRpages 113ndash122 2007

[2] Jochen Quante and Rainer Koschke Dynamic ob-ject process graphs In Proc of 10th CSMR pages81ndash90 2006

Changes to Code Clones in Evolving Software

Jens KrinkeFernUniversitat in Hagen Germany

krinkeacmorg

1 IntroductionAlthough cut-copy-paste (-and-adapt) techniques are con-sidered bad practice every programmer is using them Be-cause such practices not only involve duplication but alsomodification they are called code cloning and the dupli-cated code is called code clone A clone group consistsof the code clones that are clones of each other Codecloning is easy and cheap during software developmentbut it makes software maintenance more complicated be-cause errors may have been duplicated together with thecloned code and modifications of the original code oftenmust also be applied to the cloned code

There has been little empirical work that checkswhether the above mentioned problems are relevant inpractice Kim et al [2] investigated the evolution of codeclones and provided a classification for evolving codeclones Their work already showed that during the evo-lution of the code clones common changes to the codeclones of a group are fewer than anticipated Geiger etal [1] studied the relation of code clone groups and changecouplings (files which are committed at the same time bythe same author and with the same modification descrip-tion) but could not find a (strong) relation Therefore thiswork will present a study that (in)validates the followinghypothesis

During the evolution of a system code clones ofa clone group are changed commonly

Of course a system may contain bugs like that a changehas been applied to some code clones but has been for-gotten for other code clones of the clone group For stablesystems it can be assumed that such bugs will be resolvedat a later time This results in a second hypothesis

During the evolution of a system if code clonesof a clone group are not changed commonly themissing changes will appear in a later version

This work will validate the two hypotheses by studying thechanges that are applied to code clones during 200 weeksof evolution of two open source software systems

2 Experiment SetupFor the study the version histories of two open source sys-tems have been retrieved The first system is jhotdrawIt is a drawing application and framework written in JavaIts goal is the demonstration of good use of design pat-terns Its version archive is available via CVS and for

the study the jhotdraw6 CVS-module has been usedThe second system is a subsystem of eclipse Its ver-sion archive is also available via CVS and for the studythe orgeclipsejdtcore CVS-module has beenused

For both systems the sources have been retrieved basedon their status on 200 different dates such that each ver-sion is exactly one week later or earlier than the next orprevious version For both systems only the Java sourcefiles have been analyzed Also the source files have beentransformed to eliminate spurious changes between ver-sions Comments have been removed from the sources andafterward the source files have been reformatted with thepretty printer Artistic Style The transformed sources aresaved to a repository

The changes between the versions of the system havebeen identified by the standard diff tool For each version vof the analyzed system the changes between version v andv + 1 (the version of the next week) have been identifedAlso the changes between a version in week v and andin five weeks later (v + 5) have been identified For eachof the 200 versions the clone groups have been identifiedby the use of the clone detection tool Simian from RedHillConsulting Pty Ltd

The analysis has been done on 195 version because theversions of the last five weeks were used only for the gen-eration of the changes between the versions For eachweek w 0 le w lt 195 the tool has generated the listof clone groups with common and non common changesbased on the clone groups of the analyzed system in weekw and the changes from week w to week w + 1 (and toweek w + 5)

3 ResultsThis section will present the results of the study as de-scribed in the previous section It will first describe theresults for eclipse and jhotdraw independently andwill then present common results together with the effectsof comment removal Also the part of the study that vali-dates the second hypothesis is presented

31 Results for eclipseMost of the times when changes occur to clone groupsonly one or two clone groups have non common changesIt is also rarely the case that during one week more thanthree clone groups are affected by any kind of change Ta-ble 1 shows the accumulated numbers for all 198 weeks

1

eclipse jhotdraw1 week 5 weeks 1 week 5 weeks

clone groups with non common changes 105 188 30 41clone groups with common changes 79 135 19 20

Table 1 Comparison for non common changes during one and five weeks

This reveals that in the orgeclipsejdtcore sys-tem clone groups have more often non common changesthan common changes This suggests that if a code cloneis changed it is more often adapted in the environment it isused in than it is modified in the same way like the othercode clones in its group

32 Results for jhotdrawThe development of jhotdraw was much less active andhappened in bursts For only 21 versions occur changes tothe clone groups half of them due to irrelevant changesThe three bursts occur in week 76 141 and 182 Theburst in week 76 shows an interesting behavior Although16 clone groups are affected by changes only two are af-fected by non common changes A manual inspection ofthe changes revealed that during that week a massive codecleanup has been applied to the source code with a lot ofsmall refactorings Again non common changes to morethan two clone groups are rare

The numbers in Table 1 are similar to the numbers fromeclipse Again clone groups have more often non com-mon changes than common changes This supports the as-sumption that if a code clone is changed it is more oftenadapted in the environment it is used in than it is modifiedin the same way like the other code clones in its group

33 Evolution of Changed Clone GroupsUp to now the presented results only gave evidence for thevalidation of the first hypothesis The second hypothesisldquoDuring the evolution of a system if code clones of a clonegroup are not changed commonly the missing changes willappear in a later versionrdquo has also been validated withinthis study If this hypothesis is true changes to a clonegroup that are not applied to all code clones of a groupwill appear in a later version The study only consideredthe changes to a system that appear within one week If thehypothesis is true there have to be more common changesif a longer time period is considered To validate this thestudy has been repeated with a time distance of five weeksinstead of one as it is assumed that missed changes to aclone will be detected and fixed within four weeks

The study generated the changes that appear within thenext five weeks for the state of the software system at195 weeks (0 to 194) Table 1 shows the numbers ofchanged clone groups within one week and the number ofchanged clone groups within five weeks However for thefive weeks comparison only the weeks were non commonchanges occurred have been used ie the weeks whereno (relevant) changes or common changes occurred withinone week were ignored for the five week comparison

The numbers show that during the five week periodmuch more changes occur than within only the first weekMoreover the non common changes increase much morethan the common changes This indicates that the secondhypothesis is not valid If it would be valid the commonchanges would increase much more However there areexceptions to this general observation as manual inspec-tion revealed For example in week 125 in eclipse sixclone groups are changed in a non common way within thefollowing week Within the next four weeks four of the ofthe six clone groups receive additional changes such thatthey are now changed in a common way during the fiveweek period In weeks 19 59 118 and 144 the changesare similar two (for week 144 three) clone groups thathave non common changes within one week have onlycommon changes within five weeks For jhotdrawmanual inspection did not reveal such behavior

These observations suggest that the second hypothesisoccurs in practice but not very often Moreover duringa longer period of observed time many more non com-mon changes to clone groups appear such that occurrencesof changes that change non common changes to commonchanges are hard to identify

4 ConclusionsThe study showed that the hypotheses are not valid gener-ally The study showed that clone groups more often havenon common changes than common changes invalidatingthe first hypothesis The study also showed that the secondhypothesis is only valid partially because the non com-mon changes appear much more often However a smallamount of such changes that turn non common changes toa clone group to common changes in a later version hasbeen observed

References[1] Reto Geiger Beat Fluri Harald C Gall and Martin

Pinzger Relation of code clones and change cou-plings In Proceedings of the 9th International Con-ference of Funtamental Approaches to Software Engi-neering (FASE) pages 411ndash425 March 2006

[2] M Kim V Sazawal and D Notkin An empiricalstudy of code clone genealogies In Proceedings ofthe 10th European software engineering conferenceheld jointly with 13th ACM SIGSOFT internationalsymposium on Foundations of software engineering(ESECFSE) pages 187ndash196 2005

How to Trace Model ElementsSven Wenzel

Software Engineering Group University of Siegenwenzelinformatikuni-siegende

Motivation In model-driven engineering models enjoythe same status as customary source code During thedevelopment process many different versions or vari-ants of models are created Thereby developers need totrace model elements between different versions to an-swer questions like Since when does element X exist inthis model or When did element Y disappear Regard-ing variants developers are often interested if certain ele-ments or groups of elements (eg containing a bug) alsoexist in other variants Questions from the analytical pointof view such as logical coupling require traceability ofmodel elements too

Traceability of elements becomes a challenge sincein daily practice models are often stored as textual fileseg XMI in versioning systems such as CVS or SVNHowever these systems are not aware of models ie syn-tax and semantics inside the textual files Subsequentlywe present an approach for fine-grained element tracingbased on difference computation We furthermore offer amodel-independent visualization of our trace information

Differencing Models The main task of tracing is tolocate the correspondence of an element in another modelThe comparison of two succeeding documents and the lo-cation of correspondences respectively is known as dif-ference computation and a daily task in software configu-ration management Modern difference tools are able tocompare models on an appropriate level of abstractionwhich is basically a graph with tree-like structure mod-els are composed of elements which in turn have sub ele-ments They are not exactly trees due to cross references

For our tracing approach we use a generic similarity-based algorithm called SiDiff which was part of our priorresearch [1] Instead of relying on persistent identifiersit computes similarities between model elements in abottom-uptop-down algorithm according to the tree-likestructure of the models If two elements reveal a uniquesimilarity and they are not similar to other elements aswell they are matched A threshold ensures a minimumsimilarity to avoid unsuitable matches Elements ofcycles are compared repeatedly as long as new matchescan be found Thereby SiDiff can compare even lesstree-like structures eg Petri nets whose elements arenot qualified by their compositional structure but by theirneighborhood to other elements In a pre-phase a hashvalue is calculated for each element and elements withidentical hash values are matched Thereby runtime ofpairwise comparison is reduced and precision is improvedsince identical elements provide trustworthy fix points forcomparison of neighbor elements

Computation of Trace Information The compari-son of two models provides information about correspon-dences ie the same element occuring in both models In

order to compute trace information about an element in amodel version this model version is compared with eachdirect successor either in the same branch or in parallelbranches The successors are compared with all their suc-cessors and so on

Starting from the basic model for each element thatoccurs also in the succeeding models a track is createdeg for element A in Fig 1 A track is a chain of modelelements representing the same element occuring in dif-ferent model revisions Due to model variants the trackmay split into branches forming the shape of a tree

The elements can either occur in the succeeding mod-els without any changes or they have been changed Un-changed elements are located immediately by the hashingfunctionality of the difference algorithm Elements thathave been changed from one revision to another are lo-cated by the similarity computation facilities Thereby thethreshold defined for each element type prevents from cor-respondences between elements with significant changes

Figure 1 Examples of tracks

If an element cannot be located in any subsequentrevision of a model the track of that element ends egtrack B ends in revision 13 Elements that do not havecorrespondences in an adjacent revision are compared tothe elements of the next following revision Thereby thetraceability of elements is enhanced without includingelements into a track that do not reliably correspond Inthis case a track may contain gaps eg track C Gapsmay also cover branching points of a model eg the onemarked with F concatenating the tracks of two branchesElements without any corresponding partner eg elementD do not become part of any track

Tracing of Elements In order to trace elements atdaily work the tracks computed above must be visual-ized in a meaningful way for developers Therefore wehave implemented our approach as Eclipse plug-in usingthe GEF framework A screenshot is shown in Fig 2

Tracks are visualized in an abstract representationindependent of any model type Rectangles representdifferent revisions of the given model inside a rectangle

Figure 2 Screenshot of the analysis tool

each model element is represented by a small coloredcircle The color provides information depending on thecurrent analysis task An outline view shows a list of allrevisions and their elements inside Both the graphicalrepresentation and the outline view allow developers toselect model elements Tool tips show further informationabout the elements Filters can reduce the set of displayedelements The panel on the lower side provides differentanalysis tasks to choose from The current implementa-tion supports four different analysis tasksGlobal Track Analysis The analysis of global tracksis the simpliest task It only uses the track informationcomputed as described above If a user selects a singlemodel element in any revision of the model historythe occurences in all other revisions are highlighteddespite the fact that the elements might have been slightlymodified One can immediately see (a) since when agiven element exists in the history (b) where an elementof a revision disappeared or (c) where it occurs in otherrevisions or variants Given the examplary screenshotabove a class named UseCase3 is selected it occurs andis marked yellow respectively in each revision exceptrevision 12Tracing a Bug A bug usually consists of more than justone model element We assume that a bug is only presentin another version (and should be fixed there) if the set ofelements involved in the bug occurs as a whole with onlysmall changes in the other version Therefore similaritiesof the element set in different versions as a whole are alsocomputed and must be above an additional threshold forthe other fragment to be considered as a repetition of thebug In bug tracing analysis the selected bug elementsare colored blue while the bug candidates in the otherrevisions are colored regarding their probability to be abug Unconcerned elements are greyed outFinding dependencies Dependency analysis formerlyknown as logical coupling provides information aboutsoftware elements bearing a relation to each otheralthough that relation is not obvious These relationsare based on the changes applied to the elements egwhenever element A has been changed element B waschanged too Due to our fine-grained tracing we are

able to provide this dependency information for eachelement within the model history Once an element hasbeen selected we are able to follow its track through thewhole history For each revision where the traced elementhas been changed we check other elements that are alsoaffected by modifications Those elements are coloredaccording to their degree of dependencyIdentifying Day Flies Day flies are elements thatoccur only in one revision of the model history They areusually a sign for models that are changed without takinga long view Technically they can be identified very easilyas they are not part of any track In our visualizationthose elements are shown by brown circles This providesa quick overview about model revisions containing dayflies The outline view depicts the elements themselves ifthe user want to examine them in detail

Evaluation We evaluated our approach and its visual-ization methodologies in an empirical case study involv-ing 30 developers The probands had to perform differentanalysis problems on given model histories first manu-ally with a modeling tool of their choice and afterwardswith help of our approach Both times they had to fill in aquestionaire asking for time exposure experiences etc

First analysis covered a history of models with 25 to30 classes unknown to the probands which is typical forreverse engineerrsquos work Although the models are rathersmall for daily practice the tool-assisted analysis pro-vided significant enhancements Summarized over thefour analysis scenarios time exposure was reduced bymore than 75 in 75 of the cases Beside time reduc-tion our approach computed all results correctly whilethe probands produced erroneous results during manualanalysis we estimate an error rate of 30 Furthermoreday flies were nearly impossible to be detected manually

Half of the probands also analyzed models designedby themselves during a software development course De-spite the fairly good knowledge of their history 86 ofthe probands preferred the tool-assisted analysis alreadymodels of 20 classes are too large to keep an overviewThe latter group of probands allowed verification of thetraces computed by our approach all information has beenjudged to be correct as expected since the correspondenceanalysis used for the trace computation has been tested in-tensively in the past

Summarized over all scenarios the probands preferredessentially the tool solution mainly explained by per-formance trustworthy of results and simplicity Thevisualization itself got good ratings for illustration andgraphical controls only the handling was not clearly ratedto be intuitive In general the benefit was considered veryhigh especially for bug tracing and dependency analysiswhich are hard to solve manually The identification ofday flies however was rated to be of limited usefullness

References

1 U Kelter J Wehren and J Niere A generic differencealgorithm for UML models In Proc of SE 2005 EssenGermany March 2005

XML schema refactorings for X-to-O mappings

mdash Extended abstract mdashlowast

Ralf Lammel Microsoft Corp Redmond USA

Extended abstract

Executive summary We deal with the overallproblem of mapping XML schemas to object modelswhere the resulting object models are meant for pro-grammatic schema-aware access to XML data Theprovision of such lsquoX-to-O mappingsrsquo involves variouschallenges one of them is variation in style of schemaorganization Without appropriate countermeasuressuch variation affects the resulting object models inundue manner We tackle this challenge by devisingtransformations for normalizing styles of schema or-ganization thereby improving the quality of X-to-Omapping results

An illustrative scenario Consider the followingXML tree of an order with two items someone is or-dering two copies of the XSD 11 standard as well asthree copies of the Cobol 2008 standardltOrder Id=rdquo4711rdquogt

ltItem Id=rdquoxsdminus11minusstandardrdquogtltPricegt4288ltPricegtltQuantitygt2ltQuantitygt

ltItemgtltItem Id=rdquocobolminus2008minusstandardrdquogt

ltPricegt3799ltPricegtltQuantitygt3ltQuantitygt

ltItemgtltOrdergt

A reasonable XML schema for orders may designate asingle element declaration for orders with a nested el-ement declaration for items an item comprises a priceand a quantity cf Fig 1 What sort of object modeldo we want for the given schema Let us assume thatwe readily committed to a straightforward mapping asfollows we map simple XML schema types to similarbuilt-in types of the OO language at hand we map re-peating elements such as Item to list collections we uselsquoclasses with plain fieldsrsquo for an OO representation ofXML trees Then there is still the question of whetheror not to preserve nesting Both mapping options areexplored in Fig 2 Both options have clearly theirpros and cons and hence it is useful to provide nor-malizations that can be requested for the automatedderivation of object models

Contributions of our work In addition to nestingof content models there are a few further style issues

lowastA full paper ldquoStyle normalization for canonical X-to-Omappingsrdquo appeared in the proceedings of ACM SIGPLAN2007 Workshop on Partial Evaluation and Program Manipula-tion (PEPM rsquo07)

ltminusminus A global element declaration minusminusgtltxselement name=rdquoOrderrdquogtltxscomplexTypegtltxssequencegtltminusminus A local element declaration minusminusgtltxselement maxOccurs=rdquounboundedrdquo name=rdquoItemrdquogtltxscomplexTypegtltxssequencegtltxselement name=rdquoPricerdquo type=rdquoxsdoublerdquogtltxselement name=rdquoQuantityrdquo type=rdquoxsintrdquogt

ltxssequencegtltxsattribute name=rdquoIdrdquo type=rdquoxsstringrdquo use=rdquorequiredrdquogt

ltxscomplexTypegtltxselementgt

ltxssequencegtltxsattribute name=rdquoIdrdquo type=rdquoxsintrdquo use=rdquorequiredrdquogt


Figure 1 The orders schema (in lsquoRussian Dollrsquo style)

Flat classes for orders and their itemspublic class Order

public int Id public ListltItemgt Item

public class Item

public string Id public double Price public int Quantity

Nested classes for orders and their itemspublic class Order

public int Id public ListltItemTypegt Itempublic class ItemType


Figure 2 Different object models for orders

that challenge X-to-O mappings in a similar man-ner As a remedy we devise a systematic software-transformation approach for style normalization Itturns out that some forms of style normalization (orconversion) cannot be accomplished by transforma-tions at the level of XML schemas alone instead someamount of work must be delegated to the back-endof the X-to-O mapping so that the outgoing objectmodels are transformed Our transformational setupleverages functional OO programming and abstractdata types for the lsquosubjects under transformationrsquo Inparticular we put to work C 30 and LINQ Thisform of a transformational setup should be of interestwell beyond the theme of X-to-O mappings

1

Reengineering of State Machines in Telecommunication Systems

Christof MoslerDepartment of Computer Science 3 RWTH Aachen University

Ahornstr 55 D-52074 Aachenchristofmoslerrwth-aachende

Abstract

In our reengineering project we regard architecturemodeling and reengineering techniques of telecommu-nication systems Our work concerns analysis and re-structuring of such systems including the re-designand re-implementation As telecommunication sys-tems are often planned and modeled using state ma-chines it seems reasonable to analyze the systems alsoon the more abstract representation level of state ma-chines This paper presents a reengineering approachin which we extract the state machines from PLEXsource code verify their consistency with the originalspecification documents and use the information forfurther reengineering steps

1 Introduction

In the E-CARES1 research project we study con-cepts languages methods and tools for understand-ing and restructuring of complex legacy systems fromthe telecommunications domain The project is acooperation between Ericsson Eurolab DeutschlandGmbH (EED) and Department of Computer Science3 RWTH Aachen University The current systemunder study is Ericssonrsquos AXE10 a mobile-serviceswitching center (MSC) comprising more than tenmillion lines of code written in PLEX (ProgrammingLanguage for EXchanges) [2] This language was de-veloped in about 1970 at Ericsson and is still in wideuse within the company PLEX systems are embeddedreal-time systems using the signaling paradigm thusthey pose additional requirements regarding fault tol-erance reliability availability and response time

According to the model introduced by Byrne [1]a reengineering process comprises three phases re-verse engineering modification and forward engineer-ing All of them are supported by our reengineeringtool environment (for details see [3]) In the reverseengineering phase we use different sources of infor-mation The most important and reliable one is thesource code of the PLEX system For representationof the legacy systems we follow a graph-based ap-proach ie all underlying structures are graphs andediting operations are specified by graph transforma-

1The acronym E-CARES stands for EricssonCommunication ARchitecture for Embedded Systems

Implementation

Design

Specification

Concept

Implementation

Design

Specification

Conceptre-think

re-specify

re-design

re-code

ForwardEngineering(Refinement)

ReverseEngineering(Abstraction)

Modification

Figure 1 Reengineering Model by Byrne [1]

tion rules We parse the source code and instantiatea graph describing the system structure comprisingits communication control flow and data flow Thisstructure graph consists of a main system node sub-system nodes block nodes and the nodes for differ-ent program parts of each block (eg subroutines sig-nal entry points data structures) The nodes are con-nected to each other by various kinds of edges (egcontains goto calls from source to target) On thisgraph the user can perform various types of analysesby using different visualization and query techniques

The tool supports also the modification phase byoffering some complex algorithms for suggesting howto improve the legacy software The user can inter-actively adapt the suggested transformations takingthe semantics of the software into account or editthe graph manually All modifications of the structuregraph can later be propagated from the design level tothe implementation level by using a TXL-based toolto generate the new source code

2 Extraction and Modificationof State Machines

When developing telecommunication systems engi-neers often think in terms of state machines and pro-tocols Indeed many parts of the AXE10 system wereoriginally specified with state machines We arguethat reengineering can only be successful if this rep-resentation level is also considered Up to now allmodification approaches in our project concerned thestructure graph corresponding to the design level ofthe model in figure 1 The extension presented in thispaper focuses on the specification level where parts

ENTER C7ABORTREQEXEC WITH MECAPPCASE MECAPPSTATE IS

WHEN ABORTPENDING DO GOTO ABORTPENDING340ABORTPENDING340) MECAPPSTATE = WAITRELEASE

Sour

ce C

ode

SignalEntryC7ABORTREQEXEC

LabelStatementABORTPENDING340

StatementSequenceABORTPENDING340_ss

SymbolVariableState

Goto Has Modifies

Stru

ctur

e G

raph

C7ABORTREQEXEC

Stat

e M

achi

ne

StateABORTPENDING

StateWAITRELEASE

Figure 2 Extraction of State Machines

of the PLEX system are additionally represented asstate machines According to the model we lift theabstraction level from design to specification level

Generally there is no explicit support for the im-plementation of state machines in PLEX They aresimulated by global enumeration variables whose pos-sible values represent the possible states of the PLEXprogram during execution Following the graph-basedapproach our reengineering tool instantiates the statemachines as independent graphs allowing to applydifferent analyses and graph transformations Thesestate machine graphs are derived from the structuregraph when certain patterns appear Usually thesepatterns comprise an assignment to the state variablewhich indicates a transition in the state machine

The example in figure 2 shows parts of the PLEXsource code the corresponding subgraph of the struc-ture graph and the extracted part of the state ma-chine graph The source code starts with an EN-TER statement waiting for an incoming signal namedC7ABORTREQEXEC In the next line a CASEstatement on the STATE value of the received recordMECAPP decides whether to jump to the statementsequence labeled ABORTPENDING340 Given thecurrent block state ABORTPENDING the new as-signment of the STATE variable indicates the newstate WAITRELEASE The structure graph createdfor this code comprises all the information requiredfor the state machine extraction It is one of the ma-jor patterns used in our extraction algorithm The ex-traction of the state machine starts at the signal entrypoints and looks for paths to statement sequences thatchange the state variable For each assignment to thestate variable there is a new transition created that islabeled with the signal name The name of the sourcestate is stored in the GOTO edge and the name of thetarget state is contained in the analyzed MODIFIESedge The resulting state machine graph is shown inthe upper part of the figure

Before continuing developing concepts and tool ex-tensions for state machine analysis we wanted to

guarantee the utility of the extracted information Weextracted the state machines of several PLEX blocksand by using a simple parser compared them automat-ically with the specification files we got from EricssonOur final results showed that the extracted state ma-chines contained all states and all relevant transitionsdescribed in the specification documents (eg for oneof the major system blocks comprising 17 states and53 transitions) All occasionally emerging problemsduring the analysis originated in outdated versions ofour PLEX files

After the extraction the additional informationvisible in the state machine graphs can be taken intoaccount when re-designing the structure graph Cur-rently our most important area of application forstate machine analysis is merging and splitting ofPLEX blocks Merging of small blocks into one big-ger block can reduce the number of exchanged sig-nals and thus improve the system performance Afterthe merging the new block usually implements severalstate machines which could also be merged in orderto reduce the state space Splitting a block into sev-eral independent blocks is usually done when the blockreaches a size which makes maintenance too painful Ifa block implements several state machines the split-ting of the structure graph should result in two blockseach containing one of the original state machines Ifthe block contains only one state machine a preced-ing splitting of this state machine and the adaptionof the structure graph (eg by providing a new statevariable and dividing the state space) are required be-fore splitting the structure graph

3 Outlook

The introduced extraction algorithm has been suc-cessfully implemented Also some basic re-design al-gorithms for the structure graph considering the statemachines have been developed Future work concernsthe study of simple operations directly for the statemachine graphs and the corresponding changes to bepropagated to the structure graph The goal is toprove generally that automatic source code generationafter restructuring of state machine graphs is possible

References

[1] Byrne Eric J A Conceptual Foundation ofSoftware Re-engineering In ICSM rsquo92 pages 226ndash235 IEEE Computer Society Press 1992

[2] Marburger Andre Reverse Engineering ofComplex Legacy Telecommunication SystemsShaker Verlag Aachen Germany 2004 ISBN 3-8322-4154-X

[3] Mosler Christof E-CARES Project Reengi-neering of Telecommunication Systems InLammel R J Saraiva and J Visser (edi-tors) GTTSErsquo05 number 4143 in LNCS pages437ndash448 Braga Portugal 2006 Springer

Benoumltigen wir einen bdquoCertified MaintainerldquoStefan Opferkuch

Abteilung Software Engineering Institut fuumlr SoftwaretechnologieUniversitaumlt Stuttgart

ZusammenfassungQualifizierungsnachweise (bdquoZertifikateldquo) haben in der Software-Branche eine lange Tradition Durch sie

sollen anerkannte und standardisierte Qualifizierungen in verschiedenen Bereichen des Software-Engineeringsgeschaffen werden Dieser Artikel untersucht die Vorteile einer solchen Qualifizierung fuumlr die Software-Wartungund umreiszligt welche Inhalte eine Qualifizierung umfassen muss

1 EinfuumlhrungIn der Software-Branche existieren schon seit vielenJahren Qualifizierungsnachweise in Form von Zerti-fikaten verschiedener Hard- und Software-HerstellerSo bieten SAP Microsoft IBM Sun Cisco Red Hatund viele andere Unternehmen die Moumlglichkeit ansich durch eine Schulung in speziellen Technologiender jeweiligen Unternehmen weiterzubilden und die-se Weiterbildung durch ein Zertifikat zu belegen

In den letzten Jahren werden auch inTechnologie-neutralen Bereichen des Software-Engineerings zunehmend Zertifizierungen angebo-ten Die wohl bekannteste ist der Certified Tester [1]Weitere aumlhnliche Zertifizierungen existieren oder ent-stehen fuumlr die Gebiete Software-Architektur Projekt-management und Requirements Engineering

Allen Zertifizierungsprogrammen ist dabei gleichdass fundierte Grundlagen zu einem Gebiet desSoftware-Engineerings kompakt gelehrt werden sol-len Dieses Prinzip ist auch fuumlr weitere Gebiete denk-bar Es stellt sich also die Frage Benoumltigen wir fuumlrdie Software-Wartung einen bdquoCertified Maintainerldquoalso eine nachweisbare Qualifizierung fuumlr die War-tung Welche Vorteile wuumlrden sich daraus ergebenund welche Inhalte sollten in einer solche Qualifizie-rung beruumlcksichtigt werden

2 Vorteile einer Qualifizierung fuumlrdie Wartung

Um die Vorteile einer Qualifizierung in der Software-Wartung zu untersuchen ist ein Modell der optima-len Qualifikationen eines Software-Warters hilfreichEin solches Modell ist in Abbildung 1 dargestellt DieBasis der Qualifikationen bilden die Grundlagen desSoftware-Engineerings Darauf aufbauend kennt derSoftware-Warter die Grundlagen der Wartung undverfuumlgt auf oberster Ebene uumlber Kenntnis des von ihmzu wartenden Objekts

Wenn man dieses Modell daraufhin untersuchtwie die einzelnen Qualifikationen typisch erwor-ben werden so zeigt sich dass die Grundlagendes Software-Engineerings durch eine Software-Engineering-Ausbildung erlernt werden Die Kennt-nis uumlber die konkret zu wartende Software erlangtder Software-Warter im Unternehmen entwederdurch Unternehmens-interne Schulungen oder durchbdquolearning by doingldquo Die Grundlagen der Software-Wartung kommen dabei haumlufig zu kurz In derSoftware-Engineering-Ausbildung wird die Software-

Wartung als Themengebiet stark vernachlaumlssigt undallenfalls oberflaumlchlich besprochen Beim Erlernender Kenntnis uumlber die zu wartende Software steht diekonkrete Wartungssituation im Vordergrund Der Fo-kus liegt also auf der speziellen Wartung nicht aufden Grundlagen

Eine separate systematische Qualifizierung inden Grundlagen der Software-Wartung wuumlrde jedocheine Reihe von Vorteilen mit sich bringen

bull In der Wartung qualifizierte Mitarbeiter koumlnnensich schneller die Kenntnisse und Handlungs-weisen fuumlr die Wartung einer konkreten Soft-ware aneignen

bull Das Grundlagenwissen der Wartung ist von derArbeit an einer konkreten Software unabhaumlngigund laumlsst sich von einer Software auf eine ande-re uumlbertragen

bull Es wird ein Nachweis uumlber die Qualifikation fuumlrdie Wartung geschaffen die von der Wartungeiner konkreten Software unabhaumlngig ist

bull Durch die einheitlichen Vorgaben fuumlr die Durch-fuumlhrung der Wartung wie sie in der Qualifizie-rung erlernt werden wird die Qualitaumlt der War-tung erhoumlht

bull Die Organisation der Ausbildung wird durch dieMoumlglichkeit von Wartungstrainings in denendie Grundlagen der Software-Wartung mehre-ren Personen gelehrt werden koumlnnen verein-facht

Die Einfuumlhrung einer nachweisbaren Qualifizie-rung fuumlr die Software-Wartung bildet also eine uumlber-aus sinnvolle Ergaumlnzung zu den Grundlagen desSoftware-Engineerings und der Kenntnis der zu war-tenden Software

Im Folgenden werden die Inhalte einer solchenQualifizierung untersucht

3 Inhalte der QualifizierungUm die Inhalte der Qualifizierung fuumlr die Software-Wartung festzulegen ist zu klaumlren welche einzelnenQualifikationen fuumlr die Wartung benoumltigt werden

Dazu stellen wir uns vor dass ein Unternehmeneinen Mitarbeiter fuumlr die Wartung einer Softwaresucht Uumlber welche Qualifikationen soll dieser verfuuml-gen

bull Um den Ablauf der Wartung zu verstehen soll-te der Mitarbeiter den Wartungsprozess kennen

Abbildung 1 Qualifikationen eines Software-Warters

Er sollte nachvollziehen koumlnnen welche Phasendie Software-Wartung umfasst und welche Ab-haumlngigkeiten zwischen den Phasen bestehen

bull Da Software-Wartung immer die Arbeit an einerbestehenden Software ist sollte der Mitarbeiterdie Verwaltung dieser Software beherrschen al-so den Umgang mit dem Configuration Manage-ment

bull Bei der Durchfuumlhrung der Wartung ist zunaumlchstdas Problemverstehen und die Formulierungder Benutzerwuumlnsche von zentraler BedeutungDer Mitarbeiter sollte sich also im Umgang mitWartungsanfragen und im Anforderungsmanage-ment auskennen

bull Nach dem Problemverstehen folgt das Pro-grammverstehen Der Mitarbeiter sollte also inProgrammanalyse und Software-Architektur ge-schult sein

bull Um Aumlnderungen durchfuumlhren zu koumlnnenbenoumltigt der Mitarbeiter Qualifikationen imSoftware-Entwurf in der Implementierung undder Dokumentation

bull Zur Pruumlfung der Aumlnderungen muss der Mitar-beiter uumlber Faumlhigkeiten im Software-Test spezi-ell im Regressionstest und im funktionalen Testhierbei insbesondere im Glass-Box-Test undin der Durchfuumlhrung von Software-Inspektionenverfuumlgen

bull Fuumlr die Auslieferung der Software sollte derMitarbeiter Kenntnisse im Release-Managementbesitzen

bull Schlieszliglich sollte sich der Mitarbeiter mit Werk-zeugen auskennen die die verschiedenen Taumltig-keiten der Software-Wartung unterstuumltzen

Aus dieser Auflistung lassen sich nun im Um-kehrschluss Themengebiete einer Qualifizierung fuumlrdie Software-Wartung ableiten

bull Wartungsprozesse

bull Configuration Management

bull Anforderungs- und Aumlnderungsmanagement

bull Software-Architektur und -Entwurf

bull Software-Test und -Inspektion

bull Release Management

bull Wartungswerkzeuge

4 Schlussfolgerung und AusblickDurch den Certified Maintainer koumlnnte eine stan-dardisierte und transparente Aus- und Weiterbildungfuumlr die Software-Wartung entstehen Es koumlnnte zwi-schen Grundlagenwissen fuumlr die Wartung allgemeinund Spezialwissen bezuumlglich der Wartung einer be-stimmten Software unterschieden werden Somit wauml-re z B denkbar dass alle neuen Mitarbeiter die inder Software-Wartung taumltig sein sollen eine Qualifi-zierung fuumlr die Wartung erwerben um sich anschlie-szligend in eine spezielle Wartungsumgebung einzuar-beiten

Erfahrenen Mitarbeitern boumlte sich durch den Qua-lifizierungsnachweis eine Moumlglichkeit ihre Qualifika-tion bezuumlglich der Software-Wartung gegenuumlber ih-rem aktuellen oder einem neuen Arbeitgeber zu be-legen

Bei der Planung der Qualifizierung fuumlr die War-tung gibt es einige Punkte zu beachten Vor allemist bei der Planung der Lehrinhalte auf die prakti-sche Relevanz und die Umsetzbarkeit des Lehrstoffszu achten Ein durchgaumlngiges Beispiel aus der Praxisals zentrales Element der Schulung waumlre eine Moumlg-lichkeit der Gestaltung um diesen Anforderungen ge-recht zu werden

Des Weiteren muumlssen die einzelnen inhaltlichenThemen fuumlr die Qualifizierung weiter ausgearbeitetund verfeinert werden Dabei stellt sich die Fragewelche gesicherten Erkenntnisse uumlber diese Themenvorliegen und wie die Erkenntnisse so aufbereitetwerden koumlnnen dass sie in der Qualifizierung ver-wendet werden koumlnnen

Abschlieszligend stellt sich die Frage nach dem di-daktischen Gesamtkonzept so dass die Inhalte opti-mal vermittelt werden koumlnnen

Literatur[1] SPILLNER ANDREAS und TILO LINZ Basiswissen

Softwaretest Aus- und Weiterbildung zum Cer-tified Tester Foundation Level nach ASQF- undISTQB-Standard dpunkt-Verlag 2 uumlberarb Auf-lage 2004

Three Static Architecture Compliance Checking Approaches ndash A Comparison1

1 This work was performed in the project ArQuE (Architecture-Centric Quality Engineering) which is partially funded by the German ministry of Education and Research (BMBF) under grant number 01IS F14

Jens Knodel

Fraunhofer Institute for Experimental Software Engineering (IESE) Fraunhofer-Platz 1 67663 Kaiserslautern Germany

knodeliesefraunhoferde

Abstract The software architecture is one of the most important

artifacts created in the lifecycle of a software system One instrument to determine how well an implementation conforms to the planned specification is architecture compliance checking This paper compares three static architecture compliance checking approaches namely Reflexion models relation conformance rules and component access rules

Keywords component access rules architecture compliance checking relation conformance rules Reflexion model SAVE software architecture

1 Introduction

The software architecture is one of the most crucial artifacts within the lifecycle of a software system Decisions made at the architectural level have a direct impact on the achievement of business goals functional and quality requirements However our experiences with industrial partners show that architectural descriptions are seldom maintained On the contrary architecture descriptions (if available at all) are often insufficient andor incomplete Late changes during implementation conflicting quality requirements only resolved while implementing the system and technical development constraints often results in the fact that the implemented architecture is not compliant to the intended architecture even for the first release of the software system During the evolution of a system such effects intensify and the planned and the implemented architecture diverge even more Thus there is a high demand for assurance of architectural compliance

2 Static Compliance Checking Approaches

The compliance of the architecture can be checked statically (ie without executing the code) and dynamically (at run-time) In this paper we compare the

three most popular approaches for static architecture compliance checking of a system bull Reflexion models Reflexion models [3] compare

two models of a software system against each other typically an architectural model (the planned or intended architecture on high-level of abstraction) and a source code model (the actual or implemented architecture on a low-level of abstraction) The comparison requires a mapping between the two models which is a human-based task

bull Relation Conformance Rules Relation conformance rules (see [4] [1]) enable specifying allowed or forbidden relations between two components The rules are specified by regular expression for the names of origin and the target of the components of the system Relation conformance rules can detect similar defects as reflexion models but the mapping is done automatically for each conformance check

bull Component Access Rules Component access rules enable specifying simple ports for components which other components are allowed to call These rules help to increase the information hiding of components on a level which might not be possible to achieve by the implementation language itself Once a routine is public it is accessible by the whole system not only selected subset of it Component Access Rules were inspired by ports in ADLs and exported packages in OSGi

Static architecture evaluation of either one of the three

approaches results in the assignment of a compliance types to each relation between two components The compliance type includes convergences (relations allowed or implemented as intended) divergences (relations not allowed or not implemented as intended) and absences (relations intended but not implemented) We implemented all three static architecture evaluation approaches as features of the Fraunhofer SAVE tool (Software Architecture Visualization and Evaluation) and they will be compared in the next section

3 Comparison

Table 1 shows the comparison results for the three architecture compliance checking approaches It assumes the general application case of the compliance checking approaches however there might be exceptions The table was derived based on our practical experiences gained in several industrial and academic case studies

4 Conclusion

Architecture compliance checking is a sound instrument to detect architectural violations (ie deviations between the intended architecture and the implemented architecture) This paper presents a short comparison of three static compliance checking approaches (Reflexion models relation conformance

rules and component access rules please refer to [2] for a detailed comparison) The comparison supports the architects in their decision making on which compliance checking approach to apply based on their goals and context

References

[1] Holt RC (2005) ldquoPermission Theory for Software Architecture Plus Phantom Architecturesrdquo School of Computer Science University of Waterloo September 2005

[2] Knodel J Popescu D ldquoA Comparison of Architecture Compliance Checking Approachesrdquo 6th IEEEIFIP Working Conference on Software Architecture Mumbai India 2007

[3] Murphy GC Notkin D amp Sullivan KJ (2001) ldquoSoftware Reflexion Models Bridging the Gap between Design and Implementationrdquo IEEE Trans Software Eng 27(4) 364-380

[4] van Ommering R Krikhaar R Feijs L (2001) ldquoLanguages for formalizing visualizing and verifying software architecturesrdquo Computer Languages Volume 27 (13) 3-18

Table 1 ndash Comparison of Static Architecture Compliance Checking Approaches

Dimension Reflexion Model Relation Conformance Rules Component Access Rules

Input source code architecture source code (architecture) source code (component spec) Stakeholders architect (developer) architect (developer) component engineer (developer) Manual Steps bull creating of the architectural

model bull mapping of architectural model

elements to code bull reviewing results

bull creating and formalizing of relation conformance rules

bull reviewing results

bull creating and formalizing of component access rules


Probability of False Positives

bull low bull high bull low

Defect Types bull unintended dependencies bull misusage of interfaces bull (misuse of patterns) bull violation of architectural styles

bull unintended dependencies bull misusage of interfaces bull (misuse of patterns) bull violation of architectural styles

bull unintended dependencies bull broken information hiding bull misusage of interfaces

Transferability bull version rework mapping bull variant partial refinement of

architectural model and mapping bull major restructuring rework bull different system not possible

bull version no consequences bull variant no consequences bull major restructuring review rules bull different system yes if naming

conventions are applied

bull version no consequences bull variant no consequences bull major restructuring review rules bull different system yes if

component is reused Ease of Application

bull intuitiveness high bull iterative refinements yes bull learning curve high

bull intuitiveness high bull iterative refinements limited bull learning curve medium

bull intuitiveness medium bull iterative refinements limited bull learning curve medium

Multiple View Support

bull yes each model mapping pair can capture a different view

bull it is possible to have mapping that crosscut the decomposition hierarchy

bull commonalities overlaps and variation can be achieved by comparing the mappings

bull yes each rule set can capture a different view

bull no hierarchy crosscutting possible since the rules depend on the hierarchy

bull no multiple views are not supported


Restructuring Scenarios

bull supported by modifications to model and mapping pairs

bull monitoring and tracking possible

bull no support for what-if analyses bull monitoring and tracking possible

bull no support for what-if analyses bull no support for monitoring and

tracking of restructurings Architectural Decision Support

bull limited bull limited bull limited

Referenzszenarien der Migration in Anwendungslandschaften

Johannes Willkomm Dr Markus Voszlig

sdampm Research sdampm AG software design amp management

Berliner Str 76 63065 Offenbach johanneswillkommsdmde markusvosssdmde

1 Einleitung

Die sdampm AG hat ihre Erfahrungen aus Dutzenden von Migrations-Projekten in ein Vorgehen zur Planung sol-cher Vorhaben gefasst In [1] haben wir daruumlber bereits berichtet Kern dieses Vorgehens ist eine systematische und auf klaren Konzepten beruhende Elimination von Freiheitsgraden zur schrittweisen Ableitung von Ziel-Architektur und Ziel-Migrationsszenario Der Gesamt-prozess ist in Abbildung 1 illustriert

Vorgehenssteuerung

- Definition der Ziele

- Identifikation der Stakeholder

- Definition der Kriterien

- Identifikation der Leitplanken

Ist-Analyse

und Bewertung

des Systems

Analyse der

Anforderungen- architektur- bzw

migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer

Shortlist moumlglicher

Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-

konformen Loumlsungs-

dimensionen

Ermittlung der

Ziel-Architektur

- Auswahl einer optimalen

Ziel-Architektur durch

kundenindividuelle

Gewichtung der

Kriterien zur Architektur

und deren Auswertung

Ermittlung des

Migrations-

szenarios- Auswahl einer optimalen

Folge von Migrationsschritten

durch kundenindividuelle

Gewichtung der Kriterien

zum Vorgehen

- Durchfuumlhrung der

Wirtschaftlichkeits-

betrachtung

Projektierung

LeitplankenArchitektur-

kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion

Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion

sdampm Vorgehen zur Migrationsplanung

Abbildung 1 Migrationsplanung

In [2] haben wir uumlber einige praxiserprobte Loumlsungsmus-ter aus den Bereichen Vorgehenssteuerung Ist-Analyse und Ermittlung der Ziel-Architektur berichtet In diesem Beitrag liegt der Schwerpunkt auf der Ermittlung des Migrations-Szenarios (Roadmap) unter Nutzung so ge-nannter Referenzszenarien 2 Langfristige Evolution der Anwendungslandschaft

Bei der Untersuchung von Migrationsszenarien ist es we-sentlich diese in den Gesamtkontext der langfristigen Evolution einer Anwendungslandschaft einzuordnen Dabei hat es sich als praktikabel erwiesen zwischen drei Auspraumlgungen der Anwendungslandschaft zu unter-scheiden Ist-Anwendungslandschaft Im Rahmen der Ist-

Analyse wird die Ist-Anwendungslandschaft erho-ben und beschrieben Sie ist uumlber Jahre und Jahr-

zehnte gewachsen meist ohne eine globale Planung Daher finden sich in jeder Ist-Anwendungs-landschaft Kompromisse und architektonische Irr-

tuumlmer Ideal-Anwendungslandschaft Die Ideal-

Anwendungslandschaft wird im Rahmen einer IT-Strategie konzipiert Sie stellt eine auf Agilitaumlt Ef-fektivitaumlt und Effizienz optimal ausgerichtete Struk-turierung der Komponenten einer Anwendungsland-schaft dar und dient so als bdquoLeuchtturmldquo fuumlr alle zu-

kuumlnftigen Umbaumaszlignahmen Sie wird im Folgen-den als gegeben vorausgesetzt

Soll-Anwendungslandschaft Im Rahmen der Ermitt-lung des Migrationsszenarios wird die Soll-Anwendungslandschaft erstellt Sie wird durch kon-kret geplante Projekte angestrebt

Die folgende Abbildung illustriert diesen Zusammen-hang

Maszlignahmen

Zeit

IDEAL(Vision nicht

direkt uumlber Projekte

angestrebt)

SOLL(konkret angestrebt)

Grad der Unterstuumltzung

des Geschaumlfts

IST

nicht erreichbarer

Bereich

unerwuumlnschter

Bereich

Einzelne Projekte als

Motor der Entwicklung

Das Ideal gibt die

Leitplanken vor fuumlr

bull Fachliche

Anwendungsarchitektur

bull TI-Architektur

(Technologie und

Infrastruktur)

Abbildung 2 Anwendungslandschafts-Vorhaben

Im Folgenden werden Hintergruumlnde zur Ermittlung von Soll-Anwendungslandschaft und Roadmap beschrieben 3 Ermittlung von Soll-Anwendungslandschaft und

Roadmap

Die Ermittlung von Soll-Anwendungslandschaft und Roadmap erfolgt in zwei Stufen In der ersten Stufe der Analyse werden die wesentlichen Einflussfaktoren ana-lysiert und gegeneinander abgewogen In der zweiten Stufe der Synthese werden die notwendigen Schritte definiert sowie sinnvolle Stufen zur Umgestaltung identi-fiziert Im Rahmen der Analyse wird eine Delta-Betrachtung zwischen Ist und Ideal durchgefuumlhrt Ziel der Analyse ist es einen Teilbereich der Anwendungslandschaft zu iden-tifizieren deren Umgestaltung zuerst anzugehen ist Teil-bereiche koumlnnen dabei beispielsweise eine oder mehrere Domaumlnen der Anwendungslandschaft sein Fuumlr die kon-krete Auswahl dieser Bereiche steht eine Kosten-Nutzen-Betrachtung unter Beruumlcksichtigung der Architekturkri-terien im Vordergrund Ergebnis der Analyse ist die Soll-Anwendungslandschaft die man als den Bebauungs-plan der Anwendungslandschaft mit einer Soll-Architektur der in den naumlchsten 3-5 Jahren umzugestal-tenden Flaumlchen verstehen kann Ziel der Synthese ist es den Prozess zur Umgestaltung der Ist-Anwendungslandschaft durch Schritte und Stufen hin zum Soll zu detaillieren Das Ergebnis der Synthese

ist eine Roadmap Hierbei werden zunaumlchst auf der Basis von Referenzszenarien die notwendigen Schritte dh die durchzufuumlhrenden Teilaufgaben identifiziert Die Schritte werden dabei unter Beruumlcksichtigung der Effizienz in eine Reihenfolge gebracht Danach gilt es sinnvolle Stu-fen zu finden Stufe bedeutet hierbei die Produktivset-zung einer vorgenommenen Aumlnderung der Anwendungs-landschaft Stufen fassen hierbei mehrere Schritte aus Kostengruumlnden zusammen oder koumlnnen einen Schritt aus Risikogruumlnden in mehrere Stufen unterteilen Die Fol-gende Grafik stellt diesen Sachverhalt dar

Soll-AL

Referenz-

szenarien

heute 3 JahreSchritt 1 Schritt 2 Schritt 3

Ist-AL

Kosten Risiken

heute 3 JahreStufe 1 Stufe 4Stufe 2 Stufe 3

Abbildung 3 Zweistufiger Prozesse ndash Schritte und Stufen

Die Referenzszenarien kondensieren die Erfahrungen von sdampm aus Anwendungslandschafts-Migrations-projekten Sie manifestieren sich in Form einer Reihe von aufeinander aufbauenden Fragen die in der sukzes-siven Beantwortung zur Roadmap fuumlhren Erster Schritt dabei ist die Frage nach der Notwendigkeit zur fruumlhen Migration von Bestandskomponenten (vgl auch [3]) Bestandskomponenten zuerst migrieren Die Er-

stellung der im Soll vorgesehenen Bestandskompo-nenten (vgl [4]) ist in vielen Faumlllen in einem ersten Schritt notwendig Damit wird eine nachhaltige Ba-sis gelegt um die im Soll vorgesehenen Funktions- und Prozesskomponenten solide zu implementieren Ob dieser erste Schritt am Anfang durchzufuumlhren ist haumlngt davon ab ob Erweiterungen und Neustruktu-rierungen an der Datenstruktur der Bestaumlnde not-wendig sind Das ist in der Regel der Fall Beispiel In einem Projekt fuumlr einen Baustoffhaumlndler war der Prozess zur Vergabe von Warenkrediten zu optimieren Die Partner-Struktur der betroffenen Systeme gestattete keine einheitliche Sicht auf den Geschaumlftspartner Aus diesem Grund wurde in ei-nem ersten Schritt eine zentrale Partnerverwaltung geschaffen Die Pflege von Partnerdaten fand nun ausschlieszliglich uumlber diese Bestandskomponente statt Diverse Altsysteme wurden mit diesen Partnerdaten versorgt Erst dann wurden naumlchste Schritte in der Optimierung der Kreditvergabe angegangen

Nach dem Schritt bdquoBestandskomponenten zuerstldquo er-folgt eine Identifizierung der Schritte auf Basis von fach-lichen Gesichtspunkten Bewaumlhrt haben sich hierbei fol-gende Alternativen Randfunktionen vor Kernfunktionen migrieren

In historisch gewachsenen Anwendungslandschaften sind Randfunktionen meist in groumlszligeren Anwen-dungssystemen versteckt oder durch individuelle

Komponenten abgedeckt Bewaumlhrt hat sich die Randfunktionen zunaumlchst durch standardisierte Louml-sungen herauszuloumlsen bevor die Kernfunktionen angegangen werden Beispiel Bei einem Pharmagroszlighaumlndler wurde nach der Einfuumlhrung zentraler Bestandskomponenten zu-naumlchst Randfunktionen wie Lageroptimierung und Reportingfunktionen durch Standardsoftware abge-loumlst bevor der eigentliche Kernprozess angegangen wurde

Entlang der Wertschoumlpfungskette migrieren Manchmal ist es sinnvoll die Funktionen entlang der Wertschoumlpfungskette sukzessive herauszuloumlsen Hierbei kann die Wertschoumlpfungskette von vorne oder von hinten bdquoaufgerolltldquo werden Beispiel In einem Bankenprojekt wurde nach Her-ausloumlsung der Komponenten zur Verwaltung von Bankleitzahlen (Bestandskomponenten zuerst) zu-naumlchst die Clearing-Annahme dann die Clearing-Verarbeitung und letztendlich die Versendung von Clearing-Informationen umgestaltet

Anhand der Prioritaumlten aus dem Geschaumlft

migrieren Bei nur geringer Verzahnung der abzu-loumlsenden Funktionalitaumlten kann auch eine sukzessive Herausloumlsung anhand der geschaumlftlichen Prioritaumlten erfolgen Beispiel In einem Projekt fuumlr eine Behoumlrde wurde nach Pruumlfung der Wohlstrukturiertheit der Bestands-komponenten Such- und Pflegefunktionen zu Perso-nendaten abhaumlngig von der Dringlichkeit ihrer Ablouml-sung sukzessive aus dem Altsystem herausgeloumlst

Wurden auf diese Weise die notwendigen Schritte und deren Reihenfolge identifiziert gilt es dann die Stufen zu finden Die Zusammenfassung von mehreren Schritten zu einer Stufe ist trivial Bei der Unterteilung eines Schrittes in mehrere Stufen spielt vor allem eine Strate-gie eine Rolle die immer wieder auftritt Mit fachlicher Partitionierung migrieren Hierbei

wird ein Schnitt durch die Datenbereiche gemacht und eine Stufe beispielsweise mandantenweise um-gesetzt Beispiel Ein Reiseanbieter fuumlhrte sein neues Regu-lierungssystem zur Risikominimierung gestuft nach Zielgebieten ein (Mallorca zuerst)

Literatur

[1] Voszlig M Synthese eines Vorgehens zur Migrati-

onsplanung Workshop Software-Reengineering (WSR 2006) GI Softwaretechnik-Trends Band 26 Heft 2 2006

[2] Boos J Voszlig M Willkomm J Zamperoni A Loumlsungsmuster in der Planung industrieller Migra-

tionsprojekte Workshop Reengineering-Prozesse (RePro 2006) GI Softwaretechnik-Trends Band 27 Heft 1 2007

[3] Schaumann P Altsysteme von auszligen nach innen abloumlsen IT Fokus 78 2004

[4] Humm B Hess A Voszlig M Regeln fuumlr service-orientierte Architekturen hoher Qualitaumlt Informa-tik-Spektrum 62006 Springer Verlag 2006

Konvertierung der Jobsteuerung am Beispiel einer BS2000-Migration

Uwe Erdmenger Denis Uhligpro et con Innovative Informatikanwendungen GmbH Annaberger Straszlige 240 09125 Chemnitz

UweErdmengerproetconde DenisUhligproetconde

Software-Migration beschraumlnkt sich nicht nur auf die Kon-vertierung von Programmen Bildschirmmasken und Da-teienDatenbanken Zu einem produktiven System gehoumlrenauch Skripten bzw Jobs zur Ablauforganisation und Pro-tokollierungDer vorliegende Beitrag beschreibt eine toolgestuumltzte Kon-vertierung der unter BS2000 eingesetzten Jobsteuerspra-che SDF (System-Dialog-Facility) nach Perl Es werdendaraus Schluszligfolgerungen zur toolgestuumltzten Konvertie-rung von Jobsteuersprachen allgemein gezogen

1 Eigenschaften der Quellsprachen

Sprachen zur Jobsteuerung unterscheiden sich in eini-gen wesentlichen Eigenschaften von Programmierspra-chen Die wichtigsten Unterschiede sollen in den folgen-den Punkten erlaumlutert werdenSyntaktische Komplexitaumlt Jobs werden meist interpretativabgearbeitet Dabei wird typischerweise eine befehlswei-se Abarbeitung durchgefuumlhrt Dadurch ist die syntaktischeKomplexitaumlt geringer als bei uumlblichen Programmierspra-chenAbhaumlngigkeit vom Betriebssystem In Jobs wird ungekap-selt auf Funktionen des Betriebssystems zugegriffen (keineBibliotheken wie bei Programmiersprachen uumlblich) EinBeispiel ist bei SDF die direkte Nutzung von Jobvariablenzur Inter-Prozess-KommunikationEinbettung externer Programme Da Jobs haumlufig zur Au-tomatisierung von Ablaumlufen eingesetzt werden besteht dieNotwendigkeit externe Programme in die Jobs einzubet-ten um sie zu steuern und um Ergebnisse zu kontrollierenEingebettet sein koumlnnen zB Systemprogramme bzw Uti-lities wie SORT oder EDT oder Aufrufe und Parametervon Programmen

2 Wahl der Zielsprache

Die genannten Eigenschaften beeinflussen die Auswahlder Zielsprache Dafuumlr sind folgende Kriterien wesentlichSprachumfang Die Zielsprache soll moumlglichst viele derim ersten Abschnitt genannten Eigenschaften unterstuumlt-zen Alle nicht unterstuumltzten Funktionalitaumlten muumlssen inder Zielsprache nachgebildet werden koumlnnenErweiterbarkeit Es muss moumlglich sein die Zielsprachedurch Bibliotheken zu erweitern Auf diese Weise ist eseinfach und effizient moumlglich fuumlr die konvertierten Jobs

Funktionen welche die Zielsprache nicht bietet verfuumlgbarzu machen Des Weiteren sollen Module fuumlr die zukuumlnftigeWeiterentwicklung zur Verfuumlgung stehen (z B Datenban-kanbindung)Portabilitaumlt Die Zielsprache soll auf mehreren Hardware-plattformen zur Verfuumlgung stehen um zukuumlnftige Migra-tionen zu erleichternFuumlr die Konvertierung von SDF fiel die Wahl auf Perlals Zielsprache Perl ist ebenso eine interpretative Spra-che welche die wesentlichen Eigenschaften von Jobsteu-ersprachen bietet (Variablensubstitution Einbettung ex-terner Programme ) Perl ist auf den verschiedenstenPlattformen verfuumlgbar Damit ist auch das Kriterium derPortabilitaumlt erfuumlllt Auch die Erweiterbarkeit ist gegebenPerl kann uumlber spezielle Schnittstellen auf Bibliothekenund eine Vielzahl von Modulen im Comprehensive PerlArchive Network (CPAN) zuruumlckgreifen Ebenso erfuumllltder Sprachumfang die geforderten Kriterien

3 Werkzeug

Fuumlr die Konvertierung entwickelte pro et con ein Werk-zeug SDF-to-Perl-Translator (S2P) S2P besteht aus dreiKomponenten Die erste Komponente Parse fuumlhrt eineSyntaxanalyse durch deren Ergebnis ein Syntaxbaum derSDF-Prozedur ist Dieser ist mittels verschachtelter Has-hes und Arrays implementiert Dieser Baum wird anschlie-szligend in ein Repository abgelegt um den Aufwand fuumlr zu-kuumlnftige Schritte zu minimierenDie zweite Komponente Analyse erlaubt Analysen uumlber dieSDF-Prozeduren Dabei kann die Analysebasis eine ein-zelne Prozedur (zB Analyse von Befehlen oder Parame-terlisten) oder auch das gesamte Repository sein DieseBatch-Analysen erstellen z B die Aufruf-Hierarchie oderfuumlhren eine Suche nach Clones also aumlhnlichen Prozedu-ren durch Die Ergebnisse der Analysen werden als csv-Dateien oder als HTML-Dokument angebotenDie dritte Komponente Convert realisiert die eigentlicheUumlbersetzung der SDF-Prozedur Bei der Konvertierung dersequentiell abgearbeiteten Befehle werden zwei Typen un-terschieden Befehle die ein Aumlquivalent in Perl besitzenwerden durch diese abgebildet So wird aus dem Sprung-befehl SKIP-COMMANDS ein goto in der generiertenPerl-Funktion Alle anderen Befehle ohne Perl-Aumlquivalenterfordern eine Nachbehandlung Bei der Konvertierungwird der Name in Kleinbuchstaben gewandelt und die Pa-rameteruumlbergabe wird in eine fuumlr Perl typische Notation

1

uumlberfuumlhrt Die Implementierung dieser Befehle erfolgt ineinem Laufzeitsystem Das folgende Beispiel zeigt einesolche KonvertierungOriginal ADD-FILE-LINK LINK-NAME=SORTOUT - FILE-NAME=ITSTDAT

generiertes Perladd_file_link (LINK_NAME =gt rsquoSORT_OUTrsquo

FILE_NAME =gt rsquoITSTDATrsquo)

Das Ergebnis der Komponente Convert ist eine zur SDF-Prozedur semantisch aumlquivalente Perl-Funktion die allekonvertierbaren SDF-Befehle beinhaltet Trotzdem bleibtimmer ein gewisser Teil Handarbeit Nicht konvertierba-re SDF-Kommandos werden als Perl-Kommentar in denZielcode uumlbernommen um diese manuelle Arbeit zu er-leichtern

4 Laufzeitsystem

Zur Ausfuumlhrung der konvertierten Skripten wird zusaumltzlichein Laufzeitsystem benoumltigt welches die von Perl nicht un-terstuumltzen Befehle und Funktionalitaumlten nachbildet BeimLaufzeitsystem der aus SDF generierten Perl-Prozedurenwurde ein zweischichtiger Aufbau gewaumlhlt (Vgl Abbil-dung) Die systemnahen Funktionalitaumlten sind in der Kom-ponente BS2SYS konzentriert BS2SYS ist eine in C im-plementierte Bibliothek die als Shared Object bereitge-stellt wird Eine Funktion aus dieser Bibliothek ist zB dieKonvertierung von Jobvariablen und Dateien

Betriebssystem (z BSolaris)

DateienDatenbankenProgrammeLesen

Schreiben

StartenKontrollieren

BS2SYS

jcl_ basepmSystem-

Programme

Jobs


LesenSchreibenLesen

Schreiben

Die uumlbrige Funktionaliaumlt des Laufzeitsystems wird im Mo-dul jcl_basepm in Perl realisiertDer Quellcode des Laufzeitsystems wurde in maschinellauswertbarer Form kommentiert Das Werkzeug PerlDoc2von pro et con erstellt daraus eine Nutzerdokumentation inHTML

5 Konvertierungsbeispiel

Das folgende Beispiel demonstriert einen Fall bei dem ei-ne SDF-Funktionalitaumlt in Perl nachgebildet wurdeSDF verfuumlgt uumlber eine spezielle Technik um auf Fehlerzu reagieren Schlaumlgt ein Kommando fehl wird ein so

genannter Spin-Off ausgeloumlst Dieser kann als eine Aus-nahme (Exception) betrachtet werden Das bedeutet eswerden nach einem Fehler alle Folgebefehle uumlbersprun-gen Gestoppt wird der Spin-Off erst wenn ein Befehlerreicht wird der als Aufsetzpunkt dienen kann (z BSET-JOB-STEP) Das nachfolgende Beispiel zeigt einensolchen Fall REMARK REMARK TEST AUF EXISTENZ DER DATEI ITSTDAT REMARK FILETEST SHOW-FILE-ATTRIBUTES FILE-NAME=ITSTDAT WRITE-TEXT rsquoFILE ITSTDAT IST VORHANDENrsquo SKIP-COMMANDS TO-LABEL=WEITER SET-JOB-STEP WRITE-TEXT rsquoFILE ITSTDAT IST NICHT VORHANDENrsquo WEITER

Der Befehl SHOW-FILE-ATTRIBUTES gibt die Eigen-schaften der im Parameter FILE-NAME angegebenen Da-tei aus Ist die Datei vorhanden und der Befehl damiterfolgreich wird die nachfolgende Textausgabe ausge-fuumlhrt und mittels SKIP-COMMANDS die Fehlerbehand-lung uumlbersprungen Ist die Datei allerdings nicht vorhan-den werden alle Befehle bis zu SET-JOB-STEP uumlber-sprungen Im Beispiel wird einfach eine Meldung ausge-geben und die Verarbeitung wird fortgesetztEine solche Technik existiert in Perl nicht und wurde des-halb wie folgt emuliert Im ersten Schritt werden alle Auf-setzpunkte im Job ermittelt und mit einer Sprungmarkeversehen sofern sie noch keine besitzen Zusaumltzlich mussnun an jeder Sprungmarke ein Befehl eingefuumlgt werdender im Laufzeitsystem den naumlchsten Aufsetzpunkt fuumlr denSpin-Off setzt Wird nun durch einen Befehl eine Ausnah-me ausgeloumlst ermittelt das Laufzeitsystem den naumlchstenAufsetzpunkt und springt zur entsprechenden Sprungmar-ke Der resultierende Perl-Text sieht dann wie folgt ausREMARK()REMARK(TEST AUF EXISTENZ DER DATEI ITSTDAT )REMARK()FILETEST

NEXT_STEP(rsquoSPIN_OFF_LAB_1rsquo)show_file_attributes(FILE_NAME=gtrsquoITSTDATrsquo)write_text(rsquoFILE ITSTDAT IST VORHANDENrsquo)goto WEITER

SPIN_OFF_LAB_1NEXT_STEP(rsquoSPIN_OFF_LAB_2rsquo)write_text(rsquoFILE ITSTDAT IST NICHT VORHANDENrsquo)

WEITERNEXT_STEP(rsquoSPIN_OFF_LAB_2rsquo)

Wie beschrieben wird mittels NEXT_STEP der naumlch-ste Aufsetzpunkt bekannt gemacht Tritt in der Perl-Variante in dem im Laufzeitsystem nachgebildeten Be-fehl show_file_attributes ein Fehler auf wirddas zuletzt registrierte Spin-Off-Label ermittelt (in diesemFall SPIN_OFF_LAB_1) und angesprungen Ist dieses er-reicht wird der naumlchste Aufsetztpunkt gesetzt und die Feh-lerbehandlung durchgefuumlhrt

6 Zusammenfassung

S2P wurde erfolgreich in einem BS2000-Migrations-projekt eingesetzt Unsere praktischen Erfahrungen besa-gen dass es moumlglich und sinnvoll ist nicht nur Program-me und Daten sondern auch die Jobs (teil-)automatischmit Toolunterstuumltzung zu migrieren

Reengineering von Software-Komponentenzur Vorhersage von Dienstgute-Eigenschaften

Klaus KrogmannLehrstuhl fur Software-Entwurf und -Qualitat

Institut fur Programmstrukturen und DatenorganisationUniversitat Karlsruhe (TH)

krogmannipdukade

1 Einleitung

Die Verwendung von Komponenten ist ein anerkann-tes Prinzip in der Software-Entwicklung Dabei wer-den Software-Komponenten zumeist als Black-Boxesaufgefasst [1] deren Interna vor einem Komponenten-Verwender verborgen sind Zahlreiche Architektur-Analyse-Verfahren insbesondere solche zur Vorhersa-ge von nicht-funktionalen Eigenschaften benotigen je-doch Informationen uber Interna (bspw die Anzahlabgearbeiteter Schleifen oder Aufrufe externer Dien-ste) die von den vielen Komponentenmodellen nichtangeboten werdenFur Forscher die aktuell mit der Analyse nicht-

funktionaler Eigenschaften von komponentenbasier-ten Software-Architekturen beschaftigt sind stelltsich die Frage wie sie an dieses Wissen uberKomponenten-Interna gelangen Dabei mussen exi-stierende Software-Komponenten analysiert werdenum die benotigten Informationen uber das Innere derKomponenten derart zu rekonstruieren dass sie furanschlieszligende Analyse-Verfahren nicht-funktionalerEigenschaften genutzt werden konnen BestehendeVerfahren konzentrieren sich auf die Erkennung vonKomponenten oder bspw das Reengineering von Se-quenzdiagrammen gegebener Komponenten fokussie-ren aber nicht auf die Informationen die von Vor-hersageverfahren fur nicht-funktionale Eigenschaftenbenotigt werden (vgl Abschnitt 2)Der Beitrag dieses Papiers ist eine genaue Be-

trachtung der Informationen die das Reengineeringvon Komponenten-Interna liefern muss um fur dieVorhersage der nicht-funktionalen Eigenschaft Perfor-manz (im Sinne von Antwortzeit) nutzbringend zusein Dazu wird das Palladio Komponentenmodell [2]vorgestellt das genau fur diese Informationen vorbe-reitet ist Schlieszliglich wird ein Reengineering-Ansatzvorgestellt der dazu geeignet ist die benotigten In-formationen zu gewinnen

2 Grundlagen

Um sinnvolle Analysen der nicht-funktionalen Ei-genschaften einer Komponente zu ermoglichen wer-den Informationen uber die Interna einer Kompo-nente benotigt In Abbildung 1 werden die Inter-na als Abhangigkeiten zwischen einer angebotenenund benotigten Schnittstelle einer Komponente darge-stellt So kann der Aufruf von angebotenen Diensten

Abbildung 1 Abhangigkeiten zwischen angebotenerund benotigter Schnittstelle

der Komponente (links) dazu fuhren dass auch Dien-ste auf der benotigten Schnittstelle der Komponen-te (rechts) aufgerufen werden Abhangig davon wieder benotigte Dienst von einer externen Komponen-te bereitgestellt wird (beispielsweise niedrige oder ho-he Ausfuhrungszeit) verandert sich auch die vom Be-nutzer wahrgenommene Antwortzeit der betrachtetenKomponente [3]Um diese grob skizzierten Abhangigkeiten in

ein Modell abzubilden das die Grundlage fur dieVorhersage nicht-funktionaler Eigenschaften einerKomponenten-Architektur ist wurde das PalladioKomponentenmodell (PCM) geschaffen Das PCM isteine domanenspezifische Sprache fur die Analyse-und Simulations-Methoden [4 2] existieren die zurVorhersage von Antwortzeiten Ressourcenauslastungusw dienen Zur Definition von Abhangigkeiten zwi-schen angebotenen und benotigten Diensten sind da-bei die sogenannten Dienst Effekt Spezifikationen(SEFF) essentiell SEFFs beschreiben das innere Ver-halten einer Komponente in Form von Kontroll- undDatenfluss Das Ziel eines SEFFs ist dabei eine Ab-straktion des inneren Verhaltens zu bietenIn SEFFs wird grundsatzlich zwischen komponen-

teninternem Verhalten und externen Dienstaufrufenunterschieden Daruber hinaus existieren Kontrollflus-skonstrukte fur Schleifen Verzweigungen Ressourcen-Aquisition und -Freigabe (insgesamt als rdquoAktio-nenldquo bezeichnet) Parametrisierung und parametri-sche Abhangigkeiten erlauben es Abhangigkeiten zwi-schen Eingabeparametern eines Dienstes und Schlei-fenausfuhrungen VerzweigungswahrscheinlichkeitenParametern von externen Dienstaufrufen usw zu de-finieren Die Erfassung von Ressourcennutzung (bspwCPU-Einheiten Festplattenzugriffe) ermoglicht eineAbbildung auf Hardware Verzweigungswahrschein-lichkeiten und Schleifenausfuhrungszahlen konnen

ComponentA

daruber hinaus auch stochastisch beschrieben wer-den ndash bspw wenn die Angabe einer parametrischenAbhangigkeit hochkomplex und berechnungsintensivwurdeBislang existieren keine automatisierten Reenginee-

ring Ansatze die alle benotigten Daten von SEFFsaus bestehenden Komponenten gewinnen ndash manuelleAnsatze scheiden aus Aufwandsgrunden aus

3 Reengineering Ansatz

Abbildung 2 Angestrebter Reengineering Prozess

Wie im vorangehenden Kapitel beschrieben wurdesind zahlreiche Daten fur ein Modell der Komponen-teninterna zur Vorhersage nicht-funktionaler Eigen-schaften zu erfassen Das Ziel eines solchen Modellsist es nicht existierenden Quellcode moglichst genauabzubilden sondern eine Abstraktion zu schaffen dienur noch Parameter und parametrischen Abhangig-keiten usw enthalt die fur die Vorhersageverfahrensignifikant sindZu diesem Zwecke wollen wir statische Analyse wie

sie von existierenden Werkzeugen unterstutzt wirdmit der Laufzeitanalyse in Form von Tracing kombi-nieren Die aus beiden Schritten resultierenden Datenwerden einem genetischen Algorithmus [5] zugefuhrtDie Aufgabe des genetischen Algorithmusrsquo ist das Auf-finden einer Abstraktion parametrischer Abhangigkei-ten Dabei werden insbesondere dienstgute-invarianteParameter herausgefiltert und funktionale Abhangig-keiten vereinfacht In Abbildung 2 wird der vorge-schlagene Reengineering Prozess skizziertDer Reengineering-Vorgang beginnt mit der Einga-

be von Quellcode das Ziel der Vorgangs ist eine Mo-dellinstanz eines SEFFs Die statische Analyse liefertden Kontrollfluszlig der SEFFs Zugleich wird eine furdas Tracing benotigte Instrumentierung auf Basis derstatischen Struktur vorgenommen Ziel ist es hierbeigezielt Laufzeitdaten zu erheben um die anfallendenDatenmengen zu reduzieren Daneben liefert die sta-tische Analyse Bausteine ndash den initialen Genom ndash furden genetischen Algorithmus Dies kann beispielsweiseeine lineare Funktion fur die Ausfuhrungsdauer einerfor-Schleife seinDie im Tracing-Schritt erhobenen und bereinigten

Daten werden als Zielfunktion des genetischen Algo-rithmusrsquo verwendet um den Genom zu verbessernDabei muss der Trade-Off zwischen einfacher Bere-

chenbarkeit der funktionalen Abhangigkeiten und diebereinstimmung mit den Tracing-Daten gelost wer-den

4 Fazit

Der angestrebte Mischung aus statischem und dyna-mischem Reengineering versucht die Vorteile beiderVarianten zu vereinen Die statische Analyse liefertwichtige Informationen fur die Kontrollflussstruktu-ren des SEFFs wohingegen die dynamische Analy-se (Tracing) typische Probleme wie die Bestimmungkomplexer Schleifenabbruchbedingungen vereinfachtDas Verhalten von Komponenten wird fur die dyna-

mische Analyse zur Laufzeit beobachtet Daher ist esnotwendig dass Testdaten in die beobachteten Kom-ponenten eingegeben werden Dabei werden die glei-chen Probleme wie beim Testen von Software auftre-ten es kann niemals der gesamte Eingaberaum in end-licher Zeit abgedeckt werden Entsprechend sind aus-sagekraftige Testdaten eine Grundvoraussetzung umsinnvolle Ergebnisse zu erlangenZukunftige Arbeiten werden sich mit der Imple-

mentierung und Evaluation der vorgestellten Verfah-rens-Idee beschaftigen

Literatur

[1] Szyperski C Gruntz D Murer S ComponentSoftware Beyond Object-Oriented Programming2 edn ACM Press and Addison-Wesley New YorkNY (2002)

[2] Becker S Koziolek H Reussner R Model-based performance prediction with the palladiocomponent model In Workshop on Software andPerformance (WOSP2007) ACM Sigsoft (2007)

[3] Reussner RH Schmidt HW Using Parame-terised Contracts to Predict Properties of Com-ponent Based Software Architectures In Crn-kovic I Larsson S Stafford J eds Work-shop On Component-Based Software Engineering(in association with 9th IEEE Conference andWorkshops on Engineering of Computer-Based Sy-stems) Lund Sweden 2002 (2002)

[4] Koziolek H Firus V Parametric PerformanceContracts Non-Markovian Loop Modelling and anExperimental Evaluation In Proceedings of FES-CA2006 Electronical Notes in Computer Science(ENTCS) (2006)

[5] Koza JR Genetic Programming ndash On the Pro-gramming of Computers by Means of Natural Se-lection third edn The MIT Press CambridgeMassachusetts (1993)

InputSource Code

Static Reconstruction(using existing

tools)Building Blocks

GeneticAlgorithm

OutputSEFF Instance

Tracing

Static AnalysesAnalyses of

Dynamics RuntimeMachine Learning

Statische Code-Analyse als effiziente Qualitaumltssicherungsmaszlignahme im Umfeld eingebetteter Systeme

Dr Daniel Simon (SQS AG) danielsimonsqsde Dr Frank Simon (SQS AG) franksimonsqsde

1 Einleitung

In diesem Papier werden Erfahrungen aus gemeinsa-men Projekten des Kunden und der SQS bei der Durch-fuumlhrung proaktiver Qualitaumltssicherungsmaszlignahmen im Umfeld von eingebetteten Telekommunikationssystemen erlaumlutert Dabei werden insbesondere die Vorteile von fruumlhzeitig ergreifbaren Qualitaumltssicherungsmaszlignahmen mit Hilfe statischer Code-Analysewerkzeuge sowie de-ren ungefaumlhre Quantifizierung erkennbar

2 Aufgabenstellung

An die Kommunikations- und Informationssysteme die der Kunde entwickelt werden besondere Anspruumlche in Hinsicht auf Zuverlaumlssigkeit und Verfuumlgbarkeit bei zugleich limitierten Hardware-Ressourcen gestellt Dabei reicht die Palette der Softwarearten von einfachen Hard-waretreibern fuumlr Standardbetriebssysteme bis hin zu komplexen Benutzerschnittstellen fuumlr Endanwender Durch den Einsatz von statischen Analysetechniken

soll bereits im Vorfeld der durchzufuumlhrenden dynami-schen Tests die Fehlerrate verringert werden um damit den Ablauf der Tests durch geringere Fehlerraten zu beschleunigen Die vor der Durchfuumlhrung der Qualitaumlts-sicherungsmaszlignahmen aufgestellte Hypothese lautet dass auch in der Praxis durch Qualitaumltsaudits mittels statischer Code-Analysen Laufzeitfehler vorab identifi-ziert und beseitigt werden koumlnnen die andernfalls nur durch Testen gefunden werden Damit sollten die Pro-jekte insgesamt von einem reduzierten Aufwand bei der Testdurchfuumlhrung profitieren und eine houmlhere Qualitaumlt der Gesamtsysteme fuumlr den Kunden erzielen

3 Statische Analysen im Vergleich zu dynamischen Tests

Dynamisches Testen im Umfeld des Kunden ist in fruuml-hen Phasen der Software-Entwicklung sehr aufwendig da beispielsweise Software von Kommunikationssyste-men im Verbund mit der noch in der Entwicklung befind-lichen Hardware arbeiten muss In spaumlteren Phasen muss die Software im Zusammenspiel mit vielen Um-systemen getestet werden die am Standort der Entwick-lung nicht oder noch nicht zur Verfuumlgung stehen Die statischen Code-Analysen bieten im Vergleich zu

dynamischen Tests ua die folgenden Vorteile

bull Abdeckung von zusaumltzlichen Qualitaumltsaspekten wie Wartbarkeit und Analysierbarkeit

bull Verwendbarkeit von technisch abhaumlngigen und fach-lich unabhaumlngigen Pruumlfregeln zur Kommunikation und Homogenisierung in Entwicklergruppen (zB gewuumlnschte Architekturen oder Designs)

bull Weitgehende Automatisierbarkeit der Pruumlfungen ohne signifikante Initialaufwaumlnde zu benoumltigen

bull Durchfuumlhrbarkeit fuumlr einzelne Software-Fragmente lange vor der Integration zu einem lauffaumlhigen Ge-samtsystem

bull Durchfuumlhrungszeitpunkt unabhaumlngig vom Stand des Projekts (fuumlr die Pruumlfung von Regeln idealerweise schon zu Beginn aus Werkzeugsicht spaumlter aber genauso moumlglich)

bull Durchfuumlhrung der statischen Analyse mit geringen Kenntnissen der Fachlichkeit moumlglich und daher mi-nimal-invasiv fuumlr den Projektverlauf

bull Vollstaumlndigkeit der Analyse aufgrund der statischen Gesamtbetrachtung des Systems (der Abdeckungs-grad dynamischen Tests in aller Regel lt80)

bull Einfache Vergleichbarkeit der Messergebnisse mit anderen Systemen Versionen durch Benchmarking

Als Verfeinerung der allgemeinen Zielsetzung der Qualitaumltssicherung erfolgte beim Kunden eine Fokussie-rung auf Indikatoren mit groszligem Einfluss auf die ISO9126-Qualitaumltseigenschaften [1] Effizienz Stabilitaumlt und Zuverlaumlssigkeit Auf den Aspekt der Wartbarkeit der Software wird daruumlber hinaus nur sekundaumlr Wert gelegt da der Kunde zum Teil erhebliche Wartungs- und Sup-portanforderungen seiner Kunden erfuumlllen muss Die aufgefuumlhrten Vorteile der statischen Analyse moti-

vieren deren zusaumltzlichen Einsatz koumlnnen die dynami-schen Tests aber keinesfalls vollstaumlndig ersetzen Der erwartete wirtschaftliche Vorteil der zusaumltzlichen stati-schen Analyse liegt neben der erreichbaren Ganzheit-lichkeit (zB Wartbarkeit) darin dass die Probanden der dynamischen Analyse eine deutlich bessere Eingangs-qualitaumlt haben und die dynamischen Tests nur noch solche Abweichungen finden fuumlr deren Identifikation dynamische Tests tatsaumlchlich notwendig sind Letztlich dient die statische Code-Analyse damit der Effizienzstei-gerung dynamischer Tests

4 Projektablauf

Initiiert wurde die Qualitaumltsoffensive seitens der Pro-jektleitung die als gesamtverantwortlich fuumlr die jeweils untersuchten Systeme zeichnet Insgesamt wurde die Software dreier verschiedener Anwendungen in unter-schiedlichen Technologien mit C- C++- und C-Anteilen untersucht Das erklaumlrte Ziel der Assessments ist die Identifikation von Risiken bzgl der ISO9126 (vgl oben) Da fuumlr die einzelnen Indikatoren eine Null-Fehlergrenze in der Praxis als nicht sinnvoll eingeschaumltzt wird wird zur Bewertung der Indikatoren das allgemeine Risiko mit Hilfe von Benchmarking gegen das SQS-Benchmark-Repository ermittelt das initiiert durch das Forschungs-projekt QBench mittlerweile Risikokennzahlen von knapp 200 Groszligprojekten aus der Industrie besitzt [6]

41 Quellcode-Uumlbernahme

Vor Ort wurde die Codeuumlbernahme und Erfassung der allgemeinen Projektparameter durchgefuumlhrt Dazu gehouml-ren unter anderem die verwendeten Programmierspra-chen die eingesetzten Frameworks und ganz wesentlich die Inventarisierung der Fremdanteile Zum Zeitpunkt des Kickoffs ist die Identifikation von generiertem Code von besonderer Bedeutung da zumindest einige der untersuchten Indikatoren fuumlr generierten Code anders gewichtet werden Die Beteiligung der Kunden-Entwickler ist fuumlr diesen Schritt unbedingt erforderlich

42 Vermessung

Die Code-Analyse und die vorlaumlufige Risikoidentifikati-on mit Hilfe des SQS-Benchmarking-Repository wurde im Anschluss ohne Mitwirkung des Kunden durch die SQS durchgefuumlhrt Aus zwei wesentlichen Gruumlnden kommt bei der Analyse ein ganzer Werkzeug-Zoo zum Einsatz dessen Resultate im Anschluss dem Kunde in kondensierter und konsolidierter Form uumlbergeben wer-den Im konkreten Fall sind dies CAST [2] Bauhaus [3]

Software Tomograph [4] Splint [5] sowie eine Reihe von Perl- Shell- und sonstigen Skripten

bull Einerseits sind die Analysatoren primaumlr technolo-giegetrieben und bieten etwa fuumlr bestimmte Sprachen besonders gute fuumlr andere dagegen keine Unterstuumltzung Daruumlber hinaus besitzen die Werkzeuge fuumlr unterschiedliche Techniken unter-schiedliche Detailtreue und Abstraktionsfaumlhigkeit Waumlhrend manche Werkzeuge in einer Technik den vollstaumlndigen Kontrollfluss analysieren abs-trahieren andere davon und stellen lediglich grouml-bere auf Modulebene verfuumlgbare Informationen dar

bull Zweitens sind die Ergebnisse solcher Werkzeuge immer noch nur durch Experten effektiv und effi-zient anwendbar und zwischen den Werkzeugen untereinander vollkommen inkompatibel Bereits an recht einfach anmutenden Metriken wie bdquoLines of Codeldquo die in allen Werkzeugen auch als sol-che bezeichnet werden scheitert ohne entspre-chende Kenntnisse die Vision konsistente und objektive Kennzahlen zu erheben

43 Ergebnisanpassung-anreicherung

Die Ergebnispraumlsentation vor Entwicklern und die An-reicherung in Form einer Risikobewertung der vermes-senen Indikatoren erfolgen nach der Konsolidierung der Analyseergebnisse Um zu einer Gesamtbewertung der Projekte zu gelangen wird auf der Grundlage bidirektio-naler Qualitaumltsmodelle [6] eine Aggregation der Bewer-tung der Einzelindikatoren durchgefuumlhrt Dabei kommt eine durch SQS vorgegebene Standardgewichtung der Indikatoren in Bezug auf die ISO-Eigenschaften zum Einsatz die gegebenenfalls projektspezifisch angepasst werden kann Damit sind quantitative Aussagen bzgl der Auspraumlgung eines Systems entlang der ISO9126 moumlglich Die Ableitung von konkreten Maszlignahmen in Bezug auf

die konkreten Befunde der Software bedarf daruumlber hinaus kundenspezifischer Diskussion So kann eine Liste hoch-priorisierter Risiken zB dadurch relativiert werden dass ein Groszligteil der Symptome in Systemtei-len liegen die kurzfristig durch andere Module ersetzt werden Eine weitere Dimension betrifft den Aufwand der mit der Behebung gefundener Risiken verbunden ist Hier existieren zwar Abschaumltzungen auf Basis langjaumlhri-ger Erfahrungen diese haumlngen aber in jedem Fall vom konkreten Kontext ab Werden diese drei Dimensionen Benchmark-Risiko Kunden-Risiko und Aufwand gleich-zeitig betrachtet ergibt sich in Folge ein Entscheidungs-raum der Grundlage einer abgestimmten Priorisierung ist Ziel ist die Identifikation der risikobehaftetsten und aufwandsminimalsten Maszlignahmen

5 Erfahrungen und Ergebnisse

Die Methoden und Konzepte der statischen Codeana-lyse lassen sich in der Praxis mit Aufwaumlnden zu einem beliebigen Zeitpunkt in die Projekte einbringen die im Vergleich zu den Aufwaumlnden des Blackboxtestens sehr gering sind (im vorliegenden Projekt knapp 10) Aller-dings gilt auch hier je fruumlher desto besser da bereits durch die Einfuumlhrung derartiger Qualitaumltssicherungs-maszlignahmen das Bewusstsein der einzelnen Entwickler geschaumlrft wird und die Entstehung von problematischem Code von vorneherein unterbleibt Die statische Codeanalyse steht fruumlhzeitig bereit nach

Schwaumlchen und Risiken im Quellcode der Applikationen

zu suchen - lange bevor der erste Blackboxtest durchge-fuumlhrt werden kann Da die Fehler sehr techniknah identi-fiziert werden ist das Loumlsungsvorgehen meist direkt ableitbar und zuumlgig umsetzbar Im konkreten Fall konn-ten durch die statische Analyse der Projekte aus dem Hause des Kunden Codestellen identifiziert werden die im Falle einer Ausfuumlhrung des Programms mit Sicherheit zu Fehlverhalten des System und schlieszliglich zum Ab-sturz der Software gefuumlhrt haumltten Da diese vor aufwen-digen dynamischen Tests identifiziert und behoben wer-den konnten waren die dynamischen Tests insgesamt weniger aufwendig Im vorliegenden Projekt dominierten von den Vorteilen

der statischen Analyse (vgl oben) vor allen Dingen folgende Punkte

bull Vollstaumlndigkeit Etwa 20 der identifizierten Feh-ler waumlren vermutlich kaum systematisch durch dynamische Tests identifiziert worden Hierzu zaumlhlen insbesondere die Bereiche Speicherver-waltung und Initialisierungsanomalien

bull Erhoumlhung der Eingangsqualitaumlt des dynamischen Tests fuumlr deren Aufwandsreduktion Auch wenn in der Praxis kein sauberer empirisch tauglicher Versuchsaufbau existierte so konnte im vorlie-genden Projekt zumindest im Vergleich zu aumlhnli-chen Systemen des gleichen Unternehmens eine Aufwandsreduktion des dynamischen Tests bis zum Erreichen von Test-Ende-Kriterien um ca 10-15 erreicht werden

bull Ganzheitlichkeit Auch wenn die Eigenschaft Wartbarkeit nicht im direkten Fokus der Analyse stand (vgl oben) so wurde sie dennoch optimiert da auch diese Abweichungen Teil des Maszlignah-menpaketes waren Quantifizierungen dieser Wartbarkeitseinsparung aus anderen Projekten belegen hier Werte zwischen 10 und 30 (vgl zB [7] [8] [9])

Der fruumlhe Zeitpunkt einer statischen Analyse hat den Vorteil das Thema Qualitaumlt fruumlhzeitig bis ins Manage-ment hinein zu kommunizieren Damit schafft sie durch-gehend und kontinuierlich (Automatisierbarkeit) Trans-parenz im Hinblick auf die Qualitaumlt der Software Auch die Moumlglichkeit damit Lieferantensteuerung zu einer aktiven und aufgrund der Objektivitaumlt partnerschaftlichen Taumltigkeit werden zu lassen wird beim Kunden als sehr positiv angesehen Somit wird ein nachhaltiger Beitrag zur Verbesserung der Produkte sowohl entwicklungsin-tern als auch extern fuumlr Kunden geleistet

6 Referenzen [1] ISOIEC 9126-12001 [2] CAST APM httpwwwcastsoftwarecom [3] Bauhaus Suite Axivion GmbH httpwwwaxivionde [4] Software Tomograph Software Tomographie GmbH

httpwwwsoftware-tomographyde [5] Splint httpwwwsplintorg [6] Simon F Seng O Mohaupt Th Code Quality Manage-

ment dpunkt-Verlag Mai 2006 [7] Studemund M Rioth C Simon F bdquoROI-Modell fuumlr das

Reengineering zur Optimierung technischer SW-Qualitaumltldquo Proceedings der WSR2005

[8] Richter U Simon F bdquoMit Code-Metriken Wartungskosten senken Controlling technischer Qualitaumltldquo Proceedings der Metrikon 2005

[9] Conte A Simon F bdquoPartnerschaftliche Lieferantensteue-rung mittels technischer Anforderungenldquo Proceedings der SQM2007

Predicting Effort to Fix Software Bugs

Cathrin WeiszligSaarland University

weissstcsuni-sbde

Rahul PremrajSaarland University

premrajcsuni-sbde

Thomas ZimmermannSaarland University

tzacmorg

Andreas ZellerSaarland University

zelleracmorg

Abstract

Predicting the time and effort for a software problem haslong been a difficult task We present an approach that pre-dicts the fixing effort for an issue Our technique leveragesexisting issue tracking systems given a new issue reportwe search for similar earlier reports and use their averagetime as a prediction Our approach thus allows for earlyeffort estimation helping in assigning issues and schedul-ing stable releases We evaluated our approach on theJBoss project data and found that we can estimate withinplusmn7 hours of the actual effort

1 IntroductionIn this paper we address the problem of estimating the

time it takes to fix an issue (an issue is either a bug featurerequest or task) from a novel perspective Our approach isbased on leveraging the experience from earlier issuesmdashormore prosaic to extract issue reports from bug databasesand to use their features to estimate fixing effort (in person-hours) for new similar problems These estimates are cen-tral to project managers because they allow to plan the costand time of future releases

Our approach is illustrated in Figure 1 As a new issuereport r is entered into the bug database (1) we search forthe existing issue reports which have a description that ismost similar to r (2) We then combine their reported effortas as estimate for our issue report r (3)

2 Data SetMost development teams organize their work around a

bug database Essentially a bug database acts as a big listof issuesmdashkeeping track of all the bugs feature requestsand tasks that have to be addressed during the project Bugdatabases scale up to a large number of developers usersmdashand issues An issue report provides fields for the descrip-tion (what causes the issue and how can one reproduce it)a title or summary (a one-line abstract of the description) aswell as a severity (how strongly is the user affected by theissue)

For our experiments we use the JBoss project data that

Most similar reportswith recorded effort

Bug database

New problem report Predicted effortas weighted average

(1) (3)

(2)

Figure 1 Predicting effort for an issue report

Table 1 Prerequisites for issues

Count

Issues reported until 2006-05-05 11185Issues withndash effort data (timespent sec is available) 786ndash valid effort data (timespent seclelifetime sec) 676ndash type in (rsquoBugrsquo rsquoFeature Requestrsquo rsquoTaskrsquo rsquoSub-taskrsquo) 666ndash status in (rsquoClosed rsquoResolvedrsquo) 601ndash resolution is rsquoDonersquo 575ndash priority is not rsquoTrivialrsquo 574Issues indexable by Lucene 567

uses the Jira issue tracking system to organize issue reportsJira is one of the few issue tracking systems that supports ef-fort data To collect issues from JBoss we developed a tool[3] that crawls through the web interface of a Jira databaseand stores them locally As inputs for our experiment weonly use the title and the description of issues since they arethe only two available fields at the time the issue is reportedIn Table 1 we list the prerequisites for issues to qualify forour study In total 567 issues met these conditions and fi-nally became the inputs to our statistical models

3 Predicting Effort for Issue ReportsTo estimate the effort for a new issue report we use the

nearest neighbor approach [2] to query the database of re-

solved issues for textually similar reports Analogous toFigure 1 a target issue (ie the one to be estimated) iscompared to previously solved issues to measure similar-ity Only the title (a one-line summary) and the descrip-tion both of them are known a priori are used to computesimilarity Then the k most similar issues (candidates) areselected to derive a estimate (by averaging effort) for the tar-get Since the input features are in the form of free text weused Lucene [1] (an open-source text similarity measuringtool) to measure similarity between issues

We also use another variant of kNN (α-kNN) to improveconfidence in delivered estimates Here only predictionsfor those issues are made for which similar issues existwithin a threshold level of similarity Prosaically all can-didates lying within this level of similarity are used for es-timation

To evaluate our results we used two measures of accu-racy First Average Absolute Residuals (AAR) where resid-uals are the differences between actual and predicted valuesSmaller AAR values indicate higher prediction quality andvice versa Second we used Pred(x) which measures thepercentage of predictions that lie within plusmnx of the actualvalue x taking values 25 and 50 (higher Pred(x) values in-dicate higher prediction quality)

4 ResultsFigure 2 shows the AAR Pred(25) and Pred(50) values

for when varying the k parameter from 1 to 10 The AARvalues improve with higher k values ie the average errordecreases Since the Pred(25) and Pred(50) values worsen(ie decrease) there is no optimal k in our case Overallthe accuracy for kNN is poor On average the predictionsare off by 20 hours only 30 of predictions lie within aplusmn50 range of the actual effort which we speculate to bean artefact of diversity in issue reports

The α-kNN approach does not suffer from diversity asmuch as kNN In Figure 3 we show the accuracy values forα-kNN when incrementing the α parameter from 0 to 1 by01 We used k = infin for this experiment to eliminate anyeffects from the restriction to k neighbors Note that Feed-back indicates the percentage of issues that can be predictedusing α-kNN The combination of k = infin and α = 0 usesall previous issues to predict effort for a new issue (naıveapproach without text similarity) It comes as no surprisethat accuracy is at its lowest being off by nearly 35 hourson average

However for higher α values the accuracy improves forα = 09 the average prediction is off by only 7 hours andalmost every second prediction lies within plusmn50 of the ac-tual effort value Keep in mind that higher α values increasethe accuracy at the cost of applicability for α = 09 ourapproach makes only predictions for 13 of all issues Ourfuture work will focus on increasing the Feedback values by

worse30h

25h

20h

15h

10h

5hbetter

0hk=1 k=3 k=5 k=7 k=9

kNN

JBOSS AAR 100better

80

60

40

20

0k=1 k=3 k=5 k=7 k=9

kNN

JBOSS Pred(25)JBOSS Pred(50)

Figure 2 Accuracy values for kNN

worse30h

25h

20h

15h

10h

5hbetter

0hα=1α=05α=0

αkNN with k=infinJBOSS AAR 100

better

80

60

40

20

0α=1α=05α=0

αkNN with k=infinJBOSS Pred(25)JBOSS Pred(50)

JBOSS Feedback

Figure 3 Accuracy for α-kNN with k=infin

using additional data such as discussions on issues

5 Conclusions and ConsequencesGiven a sufficient number of earlier issue reports our

automatic model makes predictions that are very close forissues As a consequence it is possible to estimate effortat the very moment a new bug is reported This should re-lieve managers who have a long queue of bug reports wait-ing to be estimated and generally allow for better allocationof resources as well for scheduling future stable releasesThe performance of our automated model is more surpris-ing if one considers that our effort predictor relies only ontwo data points the title and the description Howeversome fundamental questions remain to be investigated suchas what is it that makes software tedious to fix To learnmore about our work in mining software archives pleasevisit

httpwwwstcsuni-sbdesoftevo

References

[1] E Hatcher and O Gospodnetic Lucene in Action ManningPublications December 2004

[2] M Shepperd and C Schofield Estimating software projecteffort using analogies IEEE Transactions on Software Engi-neering 23(12)736ndash743 November 1997

[3] T Zimmermann and P Weigerber Preprocessing CVS datafor fine-grained analysis In Proceedings of the First Interna-tional Workshop on Mining Software Repositories pages 2ndash6May 2004

Tool-Demos

Bauhaus

AnbieterHersteller Universitaumlt BremenUniversitaumltStuttgartAxivion GmbH

Referent Jochen Quante Jan HarderKurzbeschreibung

Bauhaus bietet einen Werkzeugkasten zur Unter-stuumltzung von Software-Evolution mit Hilfe statis-cher und dynamischer Analysen Sowohl quell-codenahe als auch architekturrelevante Informa-tionen werden extrahiert abstrahiert und visual-isiert

weitere Informationenhttpwwwinformatikuni-bre -mendest httpwwwbauhaus-stuttgartde httpwwwaxivioncom

BS2 MigMan - Migration Manager fuumlr BS2000Architekturen

AnbieterHersteller pro et con Innovative Infor-matikanwendungen GmbH

Referent Denis UhligKurzbeschreibung

BS2 MigMan ist eine IDE welche eine automa-tische Migration von BS2000 Applikationen inUNIX-Umgebungen realisiert Das Tool ist eineEclipse-Anwendung mit folgenden Funktional-itaumlten

bull Anwendungsprogramme im BS2000 eige-nen COBOL-Dialekt werden in allgeme-inguumlltige COBOL-Dialekte fuumlr UNIX kon-vertiert

bull Ein in das Tool integrierter Sprachkon-vertierer uumlbersetzt die BS2000-eigene Sys-temprogrammiersprache SPL in C++

bull SDF-Prozeduren werden nach Perl kon-vertiert

Die komfortable graphische Oberflaumlche garantiertdie Kontrolle uumlber alle MigMan-Funktionen Dieintegrierte Versionsverwaltung basiert auf demOpen Source Produkt Subversion und realisiertdas Speichern verschiedener Projektzustaumlnde

weitere Informationenhttpwwwproetconde

SRA - Software Reengineering Architektur


Referent Uwe ErdmengerKurzbeschreibung

SRA ist ein Werkzeugkasten zur Entwick-lung von Migrations-Tools Alle Migrations-Werkzeuge der Firma pro et con entstandenunter Nutzung von SRA SRA selbst ist eben-falls eine Eigenentwicklung Daraus werdenpraumlsentiert

Parsergenerator BTRACCGeneriert aus einer formalen Beschrei-bung den Quellcode eines Parsers ImVergleich zu anderen Parsergeneratoren(zB yacc) entfallen durch das zugrun-deliegende Backtracking-Verfahren No-tationsbeschraumlnkungen der Eingabegram-matik und die Attributierung ist wesentlichkomfortabler Die Demonstration er-folgt anhand eines Praxisbeispiels (Gener-ierung eines SPL-Parsers)

Tree Handler zur formalen Notation von Syn-taxbaumlumenEingabe fuumlr das Werkzeug ist eine for-male Notation eines Syntaxbaumes TreeHandler generiert daraus den Code fuumlrdie Klassen des Syntaxbaumes Tree Han-dler wird eingesetzt bei der Entwicklungvon Sprachkonvertierern (Translatoren)

C-Gen zur Generierung von CC++-QuellcodeDer letzte Schritt bei einer toolgestuumltzenSprachkonvertierung besteht in derZielcode-Generierung C-Gen gener-iert automatisch aus der internen Repraumlsen-tation eines Programmes (Syntaxbaum)den strukturierten Zielcode Mittels einesConfig-Files wird auf das Zielcode-Layoutnutzerspezifisch Einfluszlig genommen ( zBBlockeinruumlckungen Zeilenumbruumlche For-matierungen)


Migrationsprojekte

Rainer Gimnich (IBM Frankfurt)Komponentisierung in der SOA-Migration

Harry M Sneed (ANECON Wien)Migration in eine Service-orientierte Architektur

Code-Analyse und Tool-Demos

Daniel Vinke Meik Tessmer Thorsten Spitta(Universitaumlt Bielefeld)Quelltextanalyse eines groszligen neuenProduktivsystems

Daniel Speicher Tobias Rho Guumlnter Kniesel(Universitaumlt Bonn)JTransformer - Eine logikbasierte Infrastruktur zurCodeanalyse

Dynamische Analyse

Oliver L Boumlhm (agentes)Software-Archaumlologie mit AOP

Martin Burger (Universitaumlt Saarbruumlcken)JINSI Isolation fehlerrelevanter Interaktion inProduktivsystemen

Jochen Quante (Universitaumlt Bremen)Online Construction of Dynamic Object ProcessGraphs

Software-Evolution und -Transformation

Jens Krinke (FernUniversitaumlt Hagen)Changes to Code Clones in Evolving Software

Sven Wenzel (Universitaumlt Siegen)How to trace model elements

Ralf Laumlmmel (Microsoft RedmondUSA)XML Schema Refactorings for X-to-O Mappings

Reengineering und Software-Wartung

Christof Mosler (RWTH Aachen)Reengineering of State Machines inTelecommunication Systems

Stefan Opferkuch (Universitaumlt Stuttgart)Benoumltigen wir einen ldquoCertified Maintainerldquo

Architektur-Analyse und -Migration

Jens Knodel (IESE Kaiserslautern)Three Static Architecture Compliance CheckingApproaches - A Comparison

Johannes Willkomm Markus Voszlig (sdampm Offenbach)Referenzszenarien der Migration inAnwendungslandschaften

Uwe Erdmenger Denis Uhlig (pro et con Chemnitz)Konvertierung der Jobsteuerung am Beispiel einerBS2000-Migration

Qualitaumltssicherung

Klaus Krogmann (Universitaumlt Karlsruhe)Reengineering von Software-Komponenten zurVorhersage von Dienstguumlte-Eigenschaften

Daniel Simon Frank Simon (SQS Koumlln)Statische Code-Analyse als effizienteQualitaumltssicherungsmaszlignahme im Umfeldeingebetteter Systeme

Cathrin Weiszlig Rahul PremraThomas Zimmermann Andreas Zeller (Universitaumlt

Saarbruumlcken)Predicting Effort to Fix Software Bugs






20 April 2007

1 Einfuhrung





2 Ausgangssituation














5 Ergebnisse




Literatur







































Gesamtsystem

System

Funktion

Produkt

Komponente

Modul

realisiert

realisiert

realisiert

1N

1N

1N 1N

1N

1N

Sub-system

Subkom-ponente



















Systems)




PCF

PEF

REP

DIA

CTR

EDT

SDI

CEI

CAD

EDID

ODACDACDACD DD

OPDED

OPD

OPD



























gimnichdeibmcom


















Systemen (Legacy)

















Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication


Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








von Harry M Sneed









































































































April 21 2007

Abstract







































22 Daten aufnehmen



objLoggerlog(ret)







24 Code-Anderungen


3 Fazit







bull u v m


References







1 Einleitung




2 JINSI



Komponente

ProtokollEreignisse


Software-System

JINSI

1 ndash Produktiv

2 ndash Produktiv

ExterneDienste

ExterneDienste

Komponente


Interaktion

3 ndash Labor










3 Andere Arbeiten










Literatur












1 Einfuhrung









S s1 = new S()

s2 = Sread()

reverse(s2 s1)

do s1pop()

i = i + 1

while (s1empty())


topush(frompop())

(a) Quelltext

main

i=0

call

s1pop()

i = i+1

s1empty()

F

T

F

T

reverse

s1 = new S()

i=0

s2 = Sread()

call

i = i+1

F

T

fromempty()

frompop()

topush()

s1 = new S()

s1empty()

s1pop()

topush()

(b) DOPG fur s1








programrunning

tracetraceobject

graphraw

DOPG

programrunning

DOPGgraphraw

graphraw

graphraw

filter graph


grapheventsa)

b)events graph

transformtrace

graph construction

with filter




4 Fallstudie




Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original


5 Fazit


Literatur





krinkeacmorg














1




































References





Extended abstract






ltItemgtltOrdergt












public class Item







1




Abstract


1 Introduction




Implementation

Design

Specification

Concept

Implementation

Design

Specification

Conceptre-think

re-specify

re-design

re-code



Modification








Sour

ce C

ode




SymbolVariableState

Goto Has Modifies

Stru

ctur

e G

raph

C7ABORTREQEXEC

Stat

e M

achi

ne

StateABORTPENDING

StateWAITRELEASE








3 Outlook


References




















































Jens Knodel






1 Introduction










3 Comparison


4 Conclusion



References















































1 Einleitung


Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion

Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion












Maszlignahmen

Zeit

IDEAL(Vision nicht


angestrebt)



des Geschaumlfts

IST

nicht erreichbarer

Bereich

unerwuumlnschter

Bereich



Das Ideal gibt die


bull Fachliche


bull TI-Architektur

(Technologie und

Infrastruktur)



Roadmap



Soll-AL

Referenz-

szenarien


Ist-AL

Kosten Risiken













Literatur
















3 Werkzeug


1





4 Laufzeitsystem




Schreiben


BS2SYS

jcl_ basepmSystem-

Programme

Jobs


LesenSchreibenLesen

Schreiben










6 Zusammenfassung





krogmannipdukade

1 Einleitung




2 Grundlagen






ComponentA










4 Fazit




Literatur






InputSource Code



GeneticAlgorithm

OutputSEFF Instance

Tracing





1 Einleitung


2 Aufgabenstellung
















4 Projektablauf




42 Vermessung

























weissstcsuni-sbde


premrajcsuni-sbde


tzacmorg


zelleracmorg

Abstract









Bug database


(1) (3)

(2)



Count












worse30h

25h

20h

15h

10h

5hbetter

0hk=1 k=3 k=5 k=7 k=9

kNN

JBOSS AAR 100better

80

60

40

20

0k=1 k=3 k=5 k=7 k=9

kNN



worse30h

25h

20h

15h

10h

5hbetter

0hα=1α=05α=0


better

80

60

40

20

0α=1α=05α=0


JBOSS Feedback






References




Tool-Demos

Bauhaus



























20 April 2007

1 Einfuhrung





2 Ausgangssituation














5 Ergebnisse




Literatur







































Gesamtsystem

System

Funktion

Produkt

Komponente

Modul

realisiert

realisiert

realisiert

1N

1N

1N 1N

1N

1N

Sub-system

Subkom-ponente



















Systems)




PCF

PEF

REP

DIA

CTR

EDT

SDI

CEI

CAD

EDID

ODACDACDACD DD

OPDED

OPD

OPD



























gimnichdeibmcom


















Systemen (Legacy)

















Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication


Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








von Harry M Sneed









































































































April 21 2007

Abstract







































22 Daten aufnehmen



objLoggerlog(ret)







24 Code-Anderungen


3 Fazit







bull u v m


References







1 Einleitung




2 JINSI



Komponente

ProtokollEreignisse


Software-System

JINSI

1 ndash Produktiv

2 ndash Produktiv

ExterneDienste

ExterneDienste

Komponente


Interaktion

3 ndash Labor










3 Andere Arbeiten










Literatur












1 Einfuhrung









S s1 = new S()

s2 = Sread()

reverse(s2 s1)

do s1pop()

i = i + 1

while (s1empty())


topush(frompop())

(a) Quelltext

main

i=0

call

s1pop()

i = i+1

s1empty()

F

T

F

T

reverse

s1 = new S()

i=0

s2 = Sread()

call

i = i+1

F

T

fromempty()

frompop()

topush()

s1 = new S()

s1empty()

s1pop()

topush()

(b) DOPG fur s1








programrunning

tracetraceobject

graphraw

DOPG

programrunning

DOPGgraphraw

graphraw

graphraw

filter graph


grapheventsa)

b)events graph

transformtrace

graph construction

with filter




4 Fallstudie




Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original


5 Fazit


Literatur





krinkeacmorg














1




































References





Extended abstract






ltItemgtltOrdergt












public class Item







1




Abstract


1 Introduction




Implementation

Design

Specification

Concept

Implementation

Design

Specification

Conceptre-think

re-specify

re-design

re-code



Modification








Sour

ce C

ode




SymbolVariableState

Goto Has Modifies

Stru

ctur

e G

raph

C7ABORTREQEXEC

Stat

e M

achi

ne

StateABORTPENDING

StateWAITRELEASE








3 Outlook


References




















































Jens Knodel






1 Introduction










3 Comparison


4 Conclusion



References















































1 Einleitung


Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion

Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion












Maszlignahmen

Zeit

IDEAL(Vision nicht


angestrebt)



des Geschaumlfts

IST

nicht erreichbarer

Bereich

unerwuumlnschter

Bereich



Das Ideal gibt die


bull Fachliche


bull TI-Architektur

(Technologie und

Infrastruktur)



Roadmap



Soll-AL

Referenz-

szenarien


Ist-AL

Kosten Risiken













Literatur
















3 Werkzeug


1





4 Laufzeitsystem




Schreiben


BS2SYS

jcl_ basepmSystem-

Programme

Jobs


LesenSchreibenLesen

Schreiben










6 Zusammenfassung





krogmannipdukade

1 Einleitung




2 Grundlagen






ComponentA










4 Fazit




Literatur






InputSource Code



GeneticAlgorithm

OutputSEFF Instance

Tracing





1 Einleitung


2 Aufgabenstellung
















4 Projektablauf




42 Vermessung

























weissstcsuni-sbde


premrajcsuni-sbde


tzacmorg


zelleracmorg

Abstract









Bug database


(1) (3)

(2)



Count












worse30h

25h

20h

15h

10h

5hbetter

0hk=1 k=3 k=5 k=7 k=9

kNN

JBOSS AAR 100better

80

60

40

20

0k=1 k=3 k=5 k=7 k=9

kNN



worse30h

25h

20h

15h

10h

5hbetter

0hα=1α=05α=0


better

80

60

40

20

0α=1α=05α=0


JBOSS Feedback






References




Tool-Demos

Bauhaus































5 Ergebnisse




Literatur







































Gesamtsystem

System

Funktion

Produkt

Komponente

Modul

realisiert

realisiert

realisiert

1N

1N

1N 1N

1N

1N

Sub-system

Subkom-ponente



















Systems)




PCF

PEF

REP

DIA

CTR

EDT

SDI

CEI

CAD

EDID

ODACDACDACD DD

OPDED

OPD

OPD



























gimnichdeibmcom


















Systemen (Legacy)

















Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication


Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








von Harry M Sneed









































































































April 21 2007

Abstract







































22 Daten aufnehmen



objLoggerlog(ret)







24 Code-Anderungen


3 Fazit







bull u v m


References







1 Einleitung




2 JINSI



Komponente

ProtokollEreignisse


Software-System

JINSI

1 ndash Produktiv

2 ndash Produktiv

ExterneDienste

ExterneDienste

Komponente


Interaktion

3 ndash Labor










3 Andere Arbeiten










Literatur












1 Einfuhrung









S s1 = new S()

s2 = Sread()

reverse(s2 s1)

do s1pop()

i = i + 1

while (s1empty())


topush(frompop())

(a) Quelltext

main

i=0

call

s1pop()

i = i+1

s1empty()

F

T

F

T

reverse

s1 = new S()

i=0

s2 = Sread()

call

i = i+1

F

T

fromempty()

frompop()

topush()

s1 = new S()

s1empty()

s1pop()

topush()

(b) DOPG fur s1








programrunning

tracetraceobject

graphraw

DOPG

programrunning

DOPGgraphraw

graphraw

graphraw

filter graph


grapheventsa)

b)events graph

transformtrace

graph construction

with filter




4 Fallstudie




Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original


5 Fazit


Literatur





krinkeacmorg














1




































References





Extended abstract






ltItemgtltOrdergt












public class Item







1




Abstract


1 Introduction




Implementation

Design

Specification

Concept

Implementation

Design

Specification

Conceptre-think

re-specify

re-design

re-code



Modification








Sour

ce C

ode




SymbolVariableState

Goto Has Modifies

Stru

ctur

e G

raph

C7ABORTREQEXEC

Stat

e M

achi

ne

StateABORTPENDING

StateWAITRELEASE








3 Outlook


References




















































Jens Knodel






1 Introduction










3 Comparison


4 Conclusion



References















































1 Einleitung


Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion

Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion












Maszlignahmen

Zeit

IDEAL(Vision nicht


angestrebt)



des Geschaumlfts

IST

nicht erreichbarer

Bereich

unerwuumlnschter

Bereich



Das Ideal gibt die


bull Fachliche


bull TI-Architektur

(Technologie und

Infrastruktur)



Roadmap



Soll-AL

Referenz-

szenarien


Ist-AL

Kosten Risiken













Literatur
















3 Werkzeug


1





4 Laufzeitsystem




Schreiben


BS2SYS

jcl_ basepmSystem-

Programme

Jobs


LesenSchreibenLesen

Schreiben










6 Zusammenfassung





krogmannipdukade

1 Einleitung




2 Grundlagen






ComponentA










4 Fazit




Literatur






InputSource Code



GeneticAlgorithm

OutputSEFF Instance

Tracing





1 Einleitung


2 Aufgabenstellung
















4 Projektablauf




42 Vermessung

























weissstcsuni-sbde


premrajcsuni-sbde


tzacmorg


zelleracmorg

Abstract









Bug database


(1) (3)

(2)



Count












worse30h

25h

20h

15h

10h

5hbetter

0hk=1 k=3 k=5 k=7 k=9

kNN

JBOSS AAR 100better

80

60

40

20

0k=1 k=3 k=5 k=7 k=9

kNN



worse30h

25h

20h

15h

10h

5hbetter

0hα=1α=05α=0


better

80

60

40

20

0α=1α=05α=0


JBOSS Feedback






References




Tool-Demos

Bauhaus























































Gesamtsystem

System

Funktion

Produkt

Komponente

Modul

realisiert

realisiert

realisiert

1N

1N

1N 1N

1N

1N

Sub-system

Subkom-ponente



















Systems)




PCF

PEF

REP

DIA

CTR

EDT

SDI

CEI

CAD

EDID

ODACDACDACD DD

OPDED

OPD

OPD



























gimnichdeibmcom


















Systemen (Legacy)

















Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication


Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








von Harry M Sneed









































































































April 21 2007

Abstract







































22 Daten aufnehmen



objLoggerlog(ret)







24 Code-Anderungen


3 Fazit







bull u v m


References







1 Einleitung




2 JINSI



Komponente

ProtokollEreignisse


Software-System

JINSI

1 ndash Produktiv

2 ndash Produktiv

ExterneDienste

ExterneDienste

Komponente


Interaktion

3 ndash Labor










3 Andere Arbeiten










Literatur












1 Einfuhrung









S s1 = new S()

s2 = Sread()

reverse(s2 s1)

do s1pop()

i = i + 1

while (s1empty())


topush(frompop())

(a) Quelltext

main

i=0

call

s1pop()

i = i+1

s1empty()

F

T

F

T

reverse

s1 = new S()

i=0

s2 = Sread()

call

i = i+1

F

T

fromempty()

frompop()

topush()

s1 = new S()

s1empty()

s1pop()

topush()

(b) DOPG fur s1








programrunning

tracetraceobject

graphraw

DOPG

programrunning

DOPGgraphraw

graphraw

graphraw

filter graph


grapheventsa)

b)events graph

transformtrace

graph construction

with filter




4 Fallstudie




Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original


5 Fazit


Literatur





krinkeacmorg














1




































References





Extended abstract






ltItemgtltOrdergt












public class Item







1




Abstract


1 Introduction




Implementation

Design

Specification

Concept

Implementation

Design

Specification

Conceptre-think

re-specify

re-design

re-code



Modification








Sour

ce C

ode




SymbolVariableState

Goto Has Modifies

Stru

ctur

e G

raph

C7ABORTREQEXEC

Stat

e M

achi

ne

StateABORTPENDING

StateWAITRELEASE








3 Outlook


References




















































Jens Knodel






1 Introduction










3 Comparison


4 Conclusion



References















































1 Einleitung


Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion

Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion












Maszlignahmen

Zeit

IDEAL(Vision nicht


angestrebt)



des Geschaumlfts

IST

nicht erreichbarer

Bereich

unerwuumlnschter

Bereich



Das Ideal gibt die


bull Fachliche


bull TI-Architektur

(Technologie und

Infrastruktur)



Roadmap



Soll-AL

Referenz-

szenarien


Ist-AL

Kosten Risiken













Literatur
















3 Werkzeug


1





4 Laufzeitsystem




Schreiben


BS2SYS

jcl_ basepmSystem-

Programme

Jobs


LesenSchreibenLesen

Schreiben










6 Zusammenfassung





krogmannipdukade

1 Einleitung




2 Grundlagen






ComponentA










4 Fazit




Literatur






InputSource Code



GeneticAlgorithm

OutputSEFF Instance

Tracing





1 Einleitung


2 Aufgabenstellung
















4 Projektablauf




42 Vermessung

























weissstcsuni-sbde


premrajcsuni-sbde


tzacmorg


zelleracmorg

Abstract









Bug database


(1) (3)

(2)



Count












worse30h

25h

20h

15h

10h

5hbetter

0hk=1 k=3 k=5 k=7 k=9

kNN

JBOSS AAR 100better

80

60

40

20

0k=1 k=3 k=5 k=7 k=9

kNN



worse30h

25h

20h

15h

10h

5hbetter

0hα=1α=05α=0


better

80

60

40

20

0α=1α=05α=0


JBOSS Feedback






References




Tool-Demos

Bauhaus






















PCF

PEF

REP

DIA

CTR

EDT

SDI

CEI

CAD

EDID

ODACDACDACD DD

OPDED

OPD

OPD



























gimnichdeibmcom


















Systemen (Legacy)

















Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication


Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








von Harry M Sneed









































































































April 21 2007

Abstract







































22 Daten aufnehmen



objLoggerlog(ret)







24 Code-Anderungen


3 Fazit







bull u v m


References







1 Einleitung




2 JINSI



Komponente

ProtokollEreignisse


Software-System

JINSI

1 ndash Produktiv

2 ndash Produktiv

ExterneDienste

ExterneDienste

Komponente


Interaktion

3 ndash Labor










3 Andere Arbeiten










Literatur












1 Einfuhrung









S s1 = new S()

s2 = Sread()

reverse(s2 s1)

do s1pop()

i = i + 1

while (s1empty())


topush(frompop())

(a) Quelltext

main

i=0

call

s1pop()

i = i+1

s1empty()

F

T

F

T

reverse

s1 = new S()

i=0

s2 = Sread()

call

i = i+1

F

T

fromempty()

frompop()

topush()

s1 = new S()

s1empty()

s1pop()

topush()

(b) DOPG fur s1








programrunning

tracetraceobject

graphraw

DOPG

programrunning

DOPGgraphraw

graphraw

graphraw

filter graph


grapheventsa)

b)events graph

transformtrace

graph construction

with filter




4 Fallstudie




Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original


5 Fazit


Literatur





krinkeacmorg














1




































References





Extended abstract






ltItemgtltOrdergt












public class Item







1




Abstract


1 Introduction




Implementation

Design

Specification

Concept

Implementation

Design

Specification

Conceptre-think

re-specify

re-design

re-code



Modification








Sour

ce C

ode




SymbolVariableState

Goto Has Modifies

Stru

ctur

e G

raph

C7ABORTREQEXEC

Stat

e M

achi

ne

StateABORTPENDING

StateWAITRELEASE








3 Outlook


References




















































Jens Knodel






1 Introduction










3 Comparison


4 Conclusion



References















































1 Einleitung


Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion

Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion












Maszlignahmen

Zeit

IDEAL(Vision nicht


angestrebt)



des Geschaumlfts

IST

nicht erreichbarer

Bereich

unerwuumlnschter

Bereich



Das Ideal gibt die


bull Fachliche


bull TI-Architektur

(Technologie und

Infrastruktur)



Roadmap



Soll-AL

Referenz-

szenarien


Ist-AL

Kosten Risiken













Literatur
















3 Werkzeug


1





4 Laufzeitsystem




Schreiben


BS2SYS

jcl_ basepmSystem-

Programme

Jobs


LesenSchreibenLesen

Schreiben










6 Zusammenfassung





krogmannipdukade

1 Einleitung




2 Grundlagen






ComponentA










4 Fazit




Literatur






InputSource Code



GeneticAlgorithm

OutputSEFF Instance

Tracing





1 Einleitung


2 Aufgabenstellung
















4 Projektablauf




42 Vermessung

























weissstcsuni-sbde


premrajcsuni-sbde


tzacmorg


zelleracmorg

Abstract









Bug database


(1) (3)

(2)



Count












worse30h

25h

20h

15h

10h

5hbetter

0hk=1 k=3 k=5 k=7 k=9

kNN

JBOSS AAR 100better

80

60

40

20

0k=1 k=3 k=5 k=7 k=9

kNN



worse30h

25h

20h

15h

10h

5hbetter

0hα=1α=05α=0


better

80

60

40

20

0α=1α=05α=0


JBOSS Feedback






References




Tool-Demos

Bauhaus

























gimnichdeibmcom


















Systemen (Legacy)

















Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication


Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








von Harry M Sneed









































































































April 21 2007

Abstract







































22 Daten aufnehmen



objLoggerlog(ret)







24 Code-Anderungen


3 Fazit







bull u v m


References







1 Einleitung




2 JINSI



Komponente

ProtokollEreignisse


Software-System

JINSI

1 ndash Produktiv

2 ndash Produktiv

ExterneDienste

ExterneDienste

Komponente


Interaktion

3 ndash Labor










3 Andere Arbeiten










Literatur












1 Einfuhrung









S s1 = new S()

s2 = Sread()

reverse(s2 s1)

do s1pop()

i = i + 1

while (s1empty())


topush(frompop())

(a) Quelltext

main

i=0

call

s1pop()

i = i+1

s1empty()

F

T

F

T

reverse

s1 = new S()

i=0

s2 = Sread()

call

i = i+1

F

T

fromempty()

frompop()

topush()

s1 = new S()

s1empty()

s1pop()

topush()

(b) DOPG fur s1








programrunning

tracetraceobject

graphraw

DOPG

programrunning

DOPGgraphraw

graphraw

graphraw

filter graph


grapheventsa)

b)events graph

transformtrace

graph construction

with filter




4 Fallstudie




Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original


5 Fazit


Literatur





krinkeacmorg














1




































References





Extended abstract






ltItemgtltOrdergt












public class Item







1




Abstract


1 Introduction




Implementation

Design

Specification

Concept

Implementation

Design

Specification

Conceptre-think

re-specify

re-design

re-code



Modification








Sour

ce C

ode




SymbolVariableState

Goto Has Modifies

Stru

ctur

e G

raph

C7ABORTREQEXEC

Stat

e M

achi

ne

StateABORTPENDING

StateWAITRELEASE








3 Outlook


References




















































Jens Knodel






1 Introduction










3 Comparison


4 Conclusion



References















































1 Einleitung


Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion

Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion












Maszlignahmen

Zeit

IDEAL(Vision nicht


angestrebt)



des Geschaumlfts

IST

nicht erreichbarer

Bereich

unerwuumlnschter

Bereich



Das Ideal gibt die


bull Fachliche


bull TI-Architektur

(Technologie und

Infrastruktur)



Roadmap



Soll-AL

Referenz-

szenarien


Ist-AL

Kosten Risiken













Literatur
















3 Werkzeug


1





4 Laufzeitsystem




Schreiben


BS2SYS

jcl_ basepmSystem-

Programme

Jobs


LesenSchreibenLesen

Schreiben










6 Zusammenfassung





krogmannipdukade

1 Einleitung




2 Grundlagen






ComponentA










4 Fazit




Literatur






InputSource Code



GeneticAlgorithm

OutputSEFF Instance

Tracing





1 Einleitung


2 Aufgabenstellung
















4 Projektablauf




42 Vermessung

























weissstcsuni-sbde


premrajcsuni-sbde


tzacmorg


zelleracmorg

Abstract









Bug database


(1) (3)

(2)



Count












worse30h

25h

20h

15h

10h

5hbetter

0hk=1 k=3 k=5 k=7 k=9

kNN

JBOSS AAR 100better

80

60

40

20

0k=1 k=3 k=5 k=7 k=9

kNN



worse30h

25h

20h

15h

10h

5hbetter

0hα=1α=05α=0


better

80

60

40

20

0α=1α=05α=0


JBOSS Feedback






References




Tool-Demos

Bauhaus


























Systemen (Legacy)

















Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication


Operational Systems

Service Components

Consumers


Service P

roviderS

ervice Consum

er


ervice Bus)

QoS

Layer (Security M

anagement amp


ervices)

Data A



Governance

Channel B2B

PackagedApplication

CustomApplication

OOApplication



processes








von Harry M Sneed









































































































April 21 2007

Abstract







































22 Daten aufnehmen



objLoggerlog(ret)







24 Code-Anderungen


3 Fazit







bull u v m


References







1 Einleitung




2 JINSI



Komponente

ProtokollEreignisse


Software-System

JINSI

1 ndash Produktiv

2 ndash Produktiv

ExterneDienste

ExterneDienste

Komponente


Interaktion

3 ndash Labor










3 Andere Arbeiten










Literatur












1 Einfuhrung









S s1 = new S()

s2 = Sread()

reverse(s2 s1)

do s1pop()

i = i + 1

while (s1empty())


topush(frompop())

(a) Quelltext

main

i=0

call

s1pop()

i = i+1

s1empty()

F

T

F

T

reverse

s1 = new S()

i=0

s2 = Sread()

call

i = i+1

F

T

fromempty()

frompop()

topush()

s1 = new S()

s1empty()

s1pop()

topush()

(b) DOPG fur s1








programrunning

tracetraceobject

graphraw

DOPG

programrunning

DOPGgraphraw

graphraw

graphraw

filter graph


grapheventsa)

b)events graph

transformtrace

graph construction

with filter




4 Fallstudie




Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original


5 Fazit


Literatur





krinkeacmorg














1




































References





Extended abstract






ltItemgtltOrdergt












public class Item







1




Abstract


1 Introduction




Implementation

Design

Specification

Concept

Implementation

Design

Specification

Conceptre-think

re-specify

re-design

re-code



Modification








Sour

ce C

ode




SymbolVariableState

Goto Has Modifies

Stru

ctur

e G

raph

C7ABORTREQEXEC

Stat

e M

achi

ne

StateABORTPENDING

StateWAITRELEASE








3 Outlook


References




















































Jens Knodel






1 Introduction










3 Comparison


4 Conclusion



References















































1 Einleitung


Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion

Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion












Maszlignahmen

Zeit

IDEAL(Vision nicht


angestrebt)



des Geschaumlfts

IST

nicht erreichbarer

Bereich

unerwuumlnschter

Bereich



Das Ideal gibt die


bull Fachliche


bull TI-Architektur

(Technologie und

Infrastruktur)



Roadmap



Soll-AL

Referenz-

szenarien


Ist-AL

Kosten Risiken













Literatur
















3 Werkzeug


1





4 Laufzeitsystem




Schreiben


BS2SYS

jcl_ basepmSystem-

Programme

Jobs


LesenSchreibenLesen

Schreiben










6 Zusammenfassung





krogmannipdukade

1 Einleitung




2 Grundlagen






ComponentA










4 Fazit




Literatur






InputSource Code



GeneticAlgorithm

OutputSEFF Instance

Tracing





1 Einleitung


2 Aufgabenstellung
















4 Projektablauf




42 Vermessung

























weissstcsuni-sbde


premrajcsuni-sbde


tzacmorg


zelleracmorg

Abstract









Bug database


(1) (3)

(2)



Count












worse30h

25h

20h

15h

10h

5hbetter

0hk=1 k=3 k=5 k=7 k=9

kNN

JBOSS AAR 100better

80

60

40

20

0k=1 k=3 k=5 k=7 k=9

kNN



worse30h

25h

20h

15h

10h

5hbetter

0hα=1α=05α=0


better

80

60

40

20

0α=1α=05α=0


JBOSS Feedback






References




Tool-Demos

Bauhaus























von Harry M Sneed









































































































April 21 2007

Abstract







































22 Daten aufnehmen



objLoggerlog(ret)







24 Code-Anderungen


3 Fazit







bull u v m


References







1 Einleitung




2 JINSI



Komponente

ProtokollEreignisse


Software-System

JINSI

1 ndash Produktiv

2 ndash Produktiv

ExterneDienste

ExterneDienste

Komponente


Interaktion

3 ndash Labor










3 Andere Arbeiten










Literatur












1 Einfuhrung









S s1 = new S()

s2 = Sread()

reverse(s2 s1)

do s1pop()

i = i + 1

while (s1empty())


topush(frompop())

(a) Quelltext

main

i=0

call

s1pop()

i = i+1

s1empty()

F

T

F

T

reverse

s1 = new S()

i=0

s2 = Sread()

call

i = i+1

F

T

fromempty()

frompop()

topush()

s1 = new S()

s1empty()

s1pop()

topush()

(b) DOPG fur s1








programrunning

tracetraceobject

graphraw

DOPG

programrunning

DOPGgraphraw

graphraw

graphraw

filter graph


grapheventsa)

b)events graph

transformtrace

graph construction

with filter




4 Fallstudie




Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original

Tabelle6

Seite 28


0

5

10

15

20

25

30

J Editor

filter

instr

original


0

1

2

3

4

5

6

JHotDraw

filter

instr

original


0

2

4

6

8

ArgoUML

filter

instr

original


5 Fazit


Literatur





krinkeacmorg














1




































References





Extended abstract






ltItemgtltOrdergt












public class Item







1




Abstract


1 Introduction




Implementation

Design

Specification

Concept

Implementation

Design

Specification

Conceptre-think

re-specify

re-design

re-code



Modification








Sour

ce C

ode




SymbolVariableState

Goto Has Modifies

Stru

ctur

e G

raph

C7ABORTREQEXEC

Stat

e M

achi

ne

StateABORTPENDING

StateWAITRELEASE








3 Outlook


References




















































Jens Knodel






1 Introduction










3 Comparison


4 Conclusion



References















































1 Einleitung


Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion

Vorgehenssteuerung





Ist-Analyse

und Bewertung

des Systems

Analyse der


migrationsrelevante

fachliche und

technische (Soll-)

Anforderungen

Vorauswahl

- Erstellung einer


Ziel-Architekturen

durch systematische

Eliminierung von

nicht Leitplanken-


dimensionen

Ermittlung der

Ziel-Architektur



kundenindividuelle

Gewichtung der



Ermittlung des

Migrations-





zum Vorgehen



betrachtung

Projektierung


kriterien

Prozess-

kriterien

hoher Grad an

Kundeninteraktion












Maszlignahmen

Zeit

IDEAL(Vision nicht


angestrebt)



des Geschaumlfts

IST

nicht erreichbarer

Bereich

unerwuumlnschter

Bereich



Das Ideal gibt die


bull Fachliche


bull TI-Architektur

(Technologie und

Infrastruktur)



Roadmap



Soll-AL

Referenz-

szenarien


Ist-AL

Kosten Risiken













Literatur
















3 Werkzeug


1





4 Laufzeitsystem




Schreiben


BS2SYS

jcl_ basepmSystem-

Programme

Jobs


LesenSchreibenLesen

Schreiben










6 Zusammenfassung





krogmannipdukade

1 Einleitung




2 Grundlagen






ComponentA










4 Fazit




Literatur






InputSource Code



GeneticAlgorithm

OutputSEFF Instance

Tracing





1 Einleitung


2 Aufgabenstellung
















4 Projektablauf




42 Vermessung

























weissstcsuni-sbde


premrajcsuni-sbde


tzacmorg


zelleracmorg

Abstract









Bug database


(1) (3)

(2)



Count












worse30h

25h

20h

15h

10h

5hbetter

0hk=1 k=3 k=5 k=7 k=9

kNN

JBOSS AAR 100better

80

60

40

20

0k=1 k=3 k=5 k=7 k=9

kNN



worse30h

25h

20h

15h

10h

5hbetter

0hα=1α=05α=0


better

80

60

40

20

0α=1α=05α=0


JBOSS Feedback






References




Tool-Demos

Bauhaus






















9. Workshop Software-Reengineering (WSR...

Documents

Transcript of 9. Workshop Software-Reengineering (WSR...