2008. Springer.
- Intro
- Horseshoe process model for reengineering (legacy software --> high level architectural model --> improved, restructured model --> new software system Dirk W. Hoffmann. Software-Qualität.
- Different evolutions: requirements, architecture, data, runtim, to SOA (service oriented architecture), language (programming, modelling, formal specification etc.)
- Identifying and removing Software Clones. Rainer Koschke. Uni Bremen. Verschiedene Clones: Identisch / Syntaktisch Isomorph / nur ähnlich. Entsprechend verschiedene Detection Methoden. Visualisierungen
- Analysing Software Repositories to Understand Software Evolumtion. Marco D' Ambros, Lugano etc.. Versioning Sysktem, defect Tracking system, eMail Logs usw. Durchforsten um Evolution zu analysieren, z.B,. Developer Effort, social networks, change impact & propagation, trend and hotspot analysis, fault and defect prediction. Daten zuerst extrahieren und dann analysieren, z.B. Grafisch darstellen: Z.B. Fractal Figures für wieviele Developer arbeiten wieviel mit. Evolution Radars für change propagation
- Predicting Bugs from History. Thomas Zimmermann, Calgary etc.. Bug Wahrscheinlichkeit kann aus importierten/benutzen Modulen gut vorausgesagt werden
- ObjectOriented Reengineering. Reengineering Patterns
- Aehnlichkeiten mit Patterns: Keep it simple, Pattern System oder Language (besser organisiertes System), Human in the Loop
- Unterschiede: Process Oriented, Intermediate Solutions, Bad Examples, Polititcs
- Migration of Legacy Information Systems:
- 1. Dimensionen: DB, Strategien
- physisch (jedes alte Konstrukt in neues System übersetzen),
- Conceptual: Konzept ist extrahiert, verbessert und neu implementiert
- plus DatenKonversion
- 2. Dimension Program
- Wrapper
- Statement Rewriting (z.B. alte nach neue DML Statements)
- Logic Rewriting (mit manueller Unterstützung neu schreiben)
- 1. Dimensionen: DB, Strategien
- Architectural Transformations: From Legacy to Three-Tier and Services. Legacy enthält eine Mischung der Kategorien Presentation, Business Logik und DB-Acces, wo das nicht automatisch erkannt den Code mit der Kategorie Annotieren und dann transformieren
- On the interplay Between Software Testing and Evolution and its Effect on Program Comprehension. Leon Moonen, etc.. XP basiert wesentlich auf UnitTests und UnitTests fungieren auch als Dokumentation und für Program Comprehension. Listet verschiedene test smells und Lösungen um daraus bessere Tests zu machen. Z.B. Mystery Guest: Abhängigkeit von externen Resourcen: diese selbst generieren. Usw.. Tests selbst können Refactor'd werden oder man kann Tests Smells benutzen um nötige Code Refactoring zu entdecken
- Evolution Issues in Aspect Oriented Programming Kim Mens und Tom Tourwe. Aspect exploration (crossCuttingConcerns entdecken), Aspect extraction und Aspect evolution
- aspect Languages z.B. AspectJ: poinCut ist Menge von joinPoints in die wird der Code der advices einGewoben. PatternLanguage um pointCuts zu definieren
- Software Architectur Evolution. Olivier Barais etc.. beweisbare Ueberprüfung bzw. Transformation von architekturellen Eigenschaften, z.B. Communication Integrity (Kommunikation/Calls etc nur über in der Architektur erlaubte Verbindungen). Architektur eignet sich für aspektorientierte Ansätze (mit verschiedenen Views, die verschiedene Aspekte beleuchten). Viele Tools wie, Wright, Fractal/FScript, ArchJava usw. Stellt TranSAT vor, mit dem architect. Evolution unterstützt wird.
- Empirical Studies of Open Sopurce Evolution. Juan Fernandez-Ramilt etc. Open Source bringen ein Fülle von Daten über grossen Softwareprojekte. Die Evolution scheint Unterschiede zu propriety Software Entwicklung aufzuweisen, z.B. wechseln Stagnations, Regressions und Wachstumsphasen häufiger. Wachstum kann sehr schnell sein