Upload
annaliesa-heigl
View
121
Download
3
Embed Size (px)
Citation preview
Patrick Plieth, [email protected] 1
Seminar „Software aus Komponenten“
Software comprehension Patrick Plieth
Freie Universität Berlin, Institut für Informatikhttp://www.inf.fu-berlin.de/inst/ag-se/
• Motivation
• Kognitives Modell
• Verstehensmodelle
• Experimentelle Ergebnisse
• Fazit
Patrick Plieth, [email protected] 2
Motivation
• 75.000 Anwendungen laufen auf Großcomputern, davon sind mehr als 80% in Cobol programmiert. Mehr als drei Viertel davon sind unstrukturiert, monolithisch und vor 1980 entstanden.
• Deutsche Cobol-Programme sind zu 77% unstrukturiert, zu 80% monolithisch und enthalten zu 93% überflüssige, redundante Daten.
• Ein Wartungsprogrammierer benötigt 47% seiner Zeit für die Programmanalyse, 15% für die Programmierung, 28% für den Test und 9% für die Dokumentation.
• Bei der US Air Force kostet die Änderung einer einzelnen Quellcodezeile zwischen 2.500 und 3.000 Dollar (1990).
• Softwareverständnis zentrale Aufgabe bei Wartung, Weiterentwicklung und
Wiederverwendung
Patrick Plieth, [email protected] 3
Motivation (2)
• Probleme: Software-Altlasten ungenügend fachkundiges Personal Wartungskosten mangelnde oder fehlende Dokumentationen
• Ziele: Schaffung besserer Software durch bessere
• Werkzeuge• Richtlinien• Dokumentationen
• Notwendigkeit: Erkenntnisse über Codeverstehensprozess
Patrick Plieth, [email protected] 4
Elemente des kognitiven Modells
• „Programmverständnis ist ein Prozess, der bestehendes Wissen verwendet, um neues Wissen zu erlangen, das schließlich zum Ziel einer Codeverständnisaufgabe führt.“
• Wissen allgemeines spezifisches Verstehensprozess:
• Abgleich von allg. Wissen mit spez. Wissen• Menge der Übereinstimmungen ist mentales Modell
• Mentales Modell gegenwärtige interne Repräsentation besteht aus
• statischen Elementen• dynamischen Elementen
Patrick Plieth, [email protected] 5
mentales Modell
• statische Elemente (Entitäten) Textstrukturen Chunks Pläne Hypothesen Beacons Stilregeln
• dynamische Elemente (Verhaltensweisen) Strategien Aktionen Episoden Prozesse
Patrick Plieth, [email protected] 6
Letovsky-Modell
Patrick Plieth, [email protected] 7
Shneiderman-Modell
Patrick Plieth, [email protected] 8
Brooks-Modell
Patrick Plieth, [email protected] 9
Top-Down-Modell (Soloway und Ehrlich)
Patrick Plieth, [email protected] 10
Bottom-Up-Modell (Pennington)
Patrick Plieth, [email protected] 11
Integrated Metamodel
Patrick Plieth, [email protected] 12
Experimentelle Ergebnisse
• Stilregeln Layout mnemonische Namensvergabe Verwendung üblicher
• Daten- und Kontrollstrukturen• Algorithmen• Muster
Konsistenz Kommentare!! und Dokumentationen GOTO ist tabu!
Patrick Plieth, [email protected] 13
Experimentelle Ergebnisse
• Werkzeuge IDEs
• „syntaxhighlighting“• „pretty prints“• ausblenden einzelner Programmteile• browsing im Programmcode• strukturelle Programmdarstellungen
Analyse• aufspüren von Duplikaten• lokalisieren von „totem“ Code• erkennen kritischer Funktionsaufrufe oder Laufzeitbedingungen• Regenerierung und Visualisierung des Entwurfs
Patrick Plieth, [email protected] 14
Experimentelle Ergebnisse
• Experten erkennen mehr Probleme finden mehr Lösungen kennen spezialisierte (effizientere) Problemlösungen besitzen ausgeprägteres Bewusstsein über Neben-
bedingungen, Konsequenzen und Zusammenhänge greifen auf früher konstruierte Lösungen ähnlicher
Probleme zurück sind konsequenter im Umgang mit fraglichen Hypothesen
und „aufgeschobener“ Arbeitsschritte beschaffen sich groben Gesamtüberblick bevor Problem
weiter zerlegt wird
Patrick Plieth, [email protected] 15
Verständisprobleme
• Dokumentation entspricht nicht der aktuellen Implementierung
• Muster Umsetzung unterliegt keinem explizitem Standard
• Diskrepanz zwischen Bezeichnung und Funktionalität
Patrick Plieth, [email protected] 16
Fazit
• bisherige Erfahrungen: noch nicht vielfältig genug beziehen sich auf statische Eigenschaften weitere Untersuchungen nötig
• Was hilft? Einhalten von Konventionen Verwenden von Werkzeugen ausreichend dokumentieren Erfahrung!
Patrick Plieth, [email protected] 17
Quellen
• Advances in Computers, M. Yovitz, M. Zelkowitz, 1995, Vol.40, p. 1-38: A. v. Mayrhauser, A. M. Vans, Program Understanding: Models and Experiments
• IEEE Transactions on Software Engineering, 1999, Vol.25, No.4: A. v. Mayrhauser, S. Lang, A Coding Scheme to Support Systematic Analysis of Software Comprehension
• VSEK/025/D, 2004, M. Bennicke, H. Rust, Programmverstehen und statische Analysetechniken im Kontext des Reverse Engineering und der Qualitätssicherung
• Spektrum Akademischer Verlag, Heidelberg, Berlin, 1998, Prof. Dr.-Ing. habil. H. Balzert, Lehrbuch der Software-Technik, Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung
Patrick Plieth, [email protected] 18
Danke!