Software-Evolution. 27. Januar 2015

Transkript

1 Software-Evolution 27. Januar 2015

2 Überblick Warum ist Software-Evolution wichtig? Was ist Software-Evolution? Was sind die Prinzipien der Software-Evolution? Unterscheidet sich die Evolution von Open-Source- Software und Closed-Source-Software? Taentzer Einführung in die Softwaretechnik 390

3 Warum ist Software Evolution wichtig? Immer mehr Softwaresysteme existieren und müssen gewartet werden. Der Evolutionsanteil an der Softwareentwicklung wird immer höher. Faktor 2 bis 100 je nach Anwendung [Sommerville] : Wartungskosten mehr als 67% [Schach] Through 2008, at least 65 percent of custom-developed services for new SOA projects will be implemented via wrapping or reengineering of established applications. [Gartner] Software-Evolution ist häufig nicht genügend systematisch. Taentzer Einführung in die Softwaretechnik 391

4 Software-Betrieb, -Wartung und -Evolution Im laufenden Betrieb in ihrer Zielumgebung ist Software in der Regel Änderungen unterworfen. Die dafür notwendigen Tätigkeiten kann man - je nach Ursache und Zielsetzung - in Pflege- und Wartungstätigkeiten einteilen. Alle Änderungen an Softwaresystemen nach der ersten Auslieferung, die auch Architekturänderungen einschließen können, werden als Software-Evolution bezeichnet. Wartung (eines SW-Systems): Beseitigung von Fehlverhalten des Systems nach seiner Inbetriebnahme Pflege (eines SW-Systems): Anpassung des Systems an geänderte Bedingungen oder dessen Weiterentwicklung aufgrund neuer oder geänderter Anforderungen Betreuung (eines SW-Systems): Zusammenfassung der Pflege- und Wartungstätigkeiten. Taentzer Einführung in die Softwaretechnik 392

5 Software-Pflege und -Wartung Reparatur von SW-Fehlern: Diese ist i.a. umso teurer, je früher die Ursache im Entwicklungsprozess liegt. D.h. Codierungsfehler lassen sich relativ billig beheben, Fehler in den Anforderungen sind am teuersten. Anpassung an veränderte Betriebsbedingungen: Diese können sich z.b. durch neue Hardware, Betriebssysteme oder sonstige Basis-SW ergeben. Erweiterung oder Änderung der Funktionalität: Diese können sich z.b. aus organisatorischen oder geschäftlichen Änderungen ergeben. Voraussetzung für erfolgreiche Pflege und Wartung: Software von guter Qualität! Taentzer Einführung in die Softwaretechnik 393

6 Software altert Warum? Programs, like people, get old. We can t prevent aging, but we can understand its causes, take steps to limit its effects, temporarily reverse some of the damage it has caused, and prepare for the day when the software is no longer viable. [Parnas, 1994] zu wenig Anpassung an neue Anforderungen durch Anpassungen Einschränkungen im Design abnehmende Performanz abnehmende Zuverlässigkeit Nötige Aufräumarbeiten werden nicht durchgeführt. fehlende Dokumentation nachreichen Restrukturierung der Software Testsuite anpassen Taentzer Einführung in die Softwaretechnik 394

7 Woran erkennen wir Software-Alterung? [Demeyer, Ducasse, Nierstrasz] Veraltete oder fehlende Dokumentation Fehlende Tests Die ursprünglichen Entwickler sind gegangen. Das Wissen über das Innere der Software ist weg. Das Gesamtsystem wird nicht voll verstanden. Die Entwickler brauchen zu viel Zeit für einfache Änderungen. Kontinuierliches Fehlersuchen Lange Build-Zeiten Duplizierter Code und andere Code Smells Taentzer Einführung in die Softwaretechnik 395

8 Warum wollen wir ein Softwaresystem ändern? Neue Anforderungen Die Performanz verbessern First do it, then do it right, then do it fast. Das System auf eine neue Plattform portieren. Eine neue Technologie ausprobieren Dazu muss plattformspezifischer Code identifiziert werden. Extraktion des Designs Um eventuell Teile neu zu schreiben Abhängigkeit vom Menschen reduzieren Ein monolithisches System in individuelle Teile zerlegen Taentzer Einführung in die Softwaretechnik 396

9 Prinzipien der Software-Evolution [Lehmann] 1. Fortlaufende Änderungen: Wird ein System in realer Umgebung wirklich genutzt, so wird es notwendigerweise zum Gegenstand von Änderungen. 2. Wachsende Komplexität: Je länger ein System genutzt und fortlaufend geändert wird, desto komplexer wird seine Struktur. Vereinfachung erfordert zusätzlichen Aufwand. 3. Stabile Kenngrößen: Software-Evolution folgt festen Regeln. Kenngrößen wie SW-Umfangszuwachs, Zeit zwischen zwei Auslieferungen (Releases) oder Fehlerhäufigkeit sind (nahezu) invariant. 4. Organisatorische Stabilität: Große SW-Systeme entwickeln sich stabil - und relativ unabhängig von den dafür aufgewandten Kosten und Ressourcen. 5. Notwendige Vertrautheit: Im langfristigen Mittel ist der inkrementelle Zuwachs pro Version nahezu konstant. (Z.B. muss ein zu großer Evolutionsschritt durch mehrere kleinere wieder kompensiert werden.) Taentzer Einführung in die Softwaretechnik 397

10 Prinzipien der Software-Evolution 6. Kontinuierliche wachsende Software: Der funktionale Anteil eines Programms muss kontinuierlich wachsen, um den Anwender weiterhin zufrieden zu stellen. 7. Abnehmende Qualität: Programme scheinen eine abnehmende Qualität zu haben, es sei denn, sie werden systematisch gepflegt und an Änderungen in der Umgebung angepasst. 8. Feedback: Entwicklungsprozesse sind Feedback-Systeme und müssen als solche behandelt werden, um erfolgreich geändert oder verbessert zu werden. aus M.M.Lehmann: Laws of Software Evolution Revisited, 5th European Workshop on Software Process Technology, 1996 Taentzer Einführung in die Softwaretechnik 398

11 Taentzer Einführung in die Softwaretechnik 399

12 Einige Hypothesen zur Evolution von Open Source Software (OSS) [Xie,Chen,Neamtiu] Beispiel: Die Linux-Entwicklung startete Die Evolution bis 2003 zeigt, dass Linux mehr als linear wächst. Hypothesen: 1. OSS wächst schneller als Closed Source Software (CSS). 2. OSS-Projekte zeigen mehr Kreativität. (Z.B. Funktionalität pro Zeiteinheit) 3. OSS ist weniger komplex als CSS (Z.B. Komplexitätsmaße) 4. OSS-Projekte haben weniger Fehler und finden und fixen Fehler schneller (Z.B. modifizierte Funktionen pro Zeiteinheit) 5. OSS-Projekte haben eine bessere Modularisierung. (Z.B. Korrelation von hinzugefügten Funktionen zu geänderten.) Taentzer Einführung in die Softwaretechnik 400

13 Die Prinzipien von Lehmann in Open Source Software [Xie,Chen,Neamtiu] Taentzer Einführung in die Softwaretechnik 401

14 Forward-, Reverse- und Re-Engineering [Demeyer, Ducasse, Nierstrasz] Taentzer Einführung in die Softwaretechnik 402

15 Forward-, Reverse- und Re-Engineering Forward Engineering Die traditionelle Softwareentwicklung von den Anforderungen zur Implementierung. Reverse Engineering Die Analyse eines Softwaresystems mit dem Ziel, das System- Design zu erkennen. Reengineering Die Untersuchung und Veränderung eines bestehenden Softwaresystems, um es in eine neue Form zu bringen. Taentzer Einführung in die Softwaretechnik 403

16 Der Weg kann steinig sein Undurchschaubare, schlecht dokumentierte Systemstrukturen Kein modularer Systemaufbau, keine klare Trennung von Schichten Duplizierter Code, duplizierte Funktionalität Schlecht lesbarer Code: Programmierrichtlinien nicht beachtet Wenig Testfälle bzw. -suiten für die Module Unvollständige und unstrukturierte Projektdokumentation Keine Software zur Verwaltung und Verfolgung von Hinweisen auf Fehler verwendet (z.b. Bugzilla) Taentzer Einführung in die Softwaretechnik 404

17 Wie kann man trotzdem schnell einen Überblick bekommen? [Demeyer, Ducasse, Nierstrasz] Was nicht kaputt ist, wird nicht angefasst. Lies den gesamten Code in einer Stunde! Überflieg die Dokumentation! Wende das System an! Sprich mit den Entwicklern! Schau Dir die persistenten Daten an! Spekuliere über das Design! Überlege Dir ein Designmodell! Erkenne Muster im Code! Annotiere den Code! Schreib schwierige Codestellen so um, dass Du sie verstehst (Refactoring)! Taentzer Einführung in die Softwaretechnik 405

18 Konkrete Refactoring-Methoden Einfachste Refactorings: Rename Class/Field/Method/ Vereinfachte Methoden: Change Method Signature Extract Local Variable/Constant Convert Local Variable to Field Extract Method Introduce Parameter Introduce Parameter Object Änderungen an der Vererbungshierarchie: Pull up Field / Method Push Down Field /Method Extract Superclass / Subclass Replace Inheritance With Delegation Weitere Strukturänderungen: Extract Class Move Field to Associated Class Encapsulate Field Taentzer Einführung in die Softwaretechnik 406

19 Was sind Design Patterns? Muster, die sich im Softwareentwurf bewährt haben Gute Design Patterns entstammen direkt der Praxis. Antwort auf wiederkehrende Probleme im SW-Entwurf Kein fertiges Stück Code, das direkt in eigenen Code gesetzt werden kann Eher eine Art Schablone für die Lösung eines Problems Kritik: Design Patterns müssen immer wieder neu implementiert werden. Literatur: E.Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software(ISBN ), Taentzer Einführung in die Softwaretechnik 407

20 Sinn und Zweck von Design Patterns Zwecke: Stärkere Modularisierung von Software Integration von unabhängig entwickelten Komponenten Variantenmanagement: Gemeinsamkeiten von Objekten herauskehren, sodass verschiedene Objekte gleich behandelt werden können Arten: Erzeugungsmuster: Factory, Singleton, etc. Strukturmuster: Adapter, Decorator, Fassade, Composite, Proxy, etc. Verhaltensmuster: Observer, Visitor, Iterator, Strategy, etc. Taentzer Einführung in die Softwaretechnik 408

21 Beispiel: Strukturierung von graphischen Elementen In Android gibt es Views und ViewGroups. Views und ViewGroups sollen möglichst gleich implementiert werden. Verschiedene Varianten von Views (TextView, EditText, Button, etc.) sollen integriert werden können. Taentzer Einführung in die Softwaretechnik 409

22 Anwendung des Composite Pattern Einzelne Instanzen und Gruppen von Instanzen können gleich behandelt werden. Pattern: Beispiel: Component View Atomic Composite TextView ImageView ViewGroup EditText Button Taentzer Einführung in die Softwaretechnik 410

23 Software-Reengineering Verbreitetes Problem in der Software-Praxis: bestehende, oft schon langlebige Systeme, welche die o.g. Kriterien nicht oder nur teilweise erfüllen, aber trotzdem dringend (weiter) gebraucht werden. Bezeichnung für solche Systeme: Legacy Systems" (dt. etwa: Altsysteme). Mögliche Strategien zum Umgang mit Altsystemen: (1) Mit minimalem Aufwand weiterwursteln. (2) Das Altsystem einpacken und nicht weiterentwickeln. (3) System durchgängig analysieren, dokumentieren, (teilweise) sanieren oder reimplementieren. (4) System neu konzipieren und ablösen. nicht einfach warum? Taentzer Einführung in die Softwaretechnik 411

24 Zusammenfassung Softwareentwicklung ist vielfach langfristig angelegt. Software-Evolution umfasst die Wartung und Pflege von Softwaresystemen sowie ihre Erweiterung bzgl. neuer Anforderungen. Software altert. Lehmann hat eine Reihe von Gesetzen aufgestellt, die die Prinzipien der Software-Evolution beschreiben. Obwohl diese Gesetze ursprünglich für Closed-Source-Projekte aufgestellt worden sind, wollen wir sie anhand von Open-Source- Projekten studieren. Beispiele für Best Practices im Reverse- und Re-Engineering Taentzer Einführung in die Softwaretechnik 412

25 Literatur Object-Oriented Reengineering Patterns, Serge Demeyer, Stephane Ducasse, Oscar Nierstrasz, 2008, A. Deshpande, D. Riehle: The Total Growth of Open Source, in: Open Source Development, Communities and Quality, Springer LNCS, 2008 M.M. Lehman, L.A. Belady, Program Evolution: Processes of Software Change. Academic Press, London, ftp://ftp.umh.ac.be/pub/ftp_infofs/1985/programevolution.pdf D. L. Parnas: Software Aging, Int. Conf. on Software Engineering, IEEE, 1994 Ian Sommerville: Software Engineering, Addison-Wesley, 9. Auflage, 2013 S. Schach: Object Oriented Software Engineering, 1. Auflage, 2007 I. Neamtiu, G. Xie, J. Chen: Towards a Better Understanding of Software Evolution: An Empirical Study on Open Source Software, in: Journal of Software: Evolution and Process, 2013 Taentzer Einführung in die Softwaretechnik 413