Software Factories WS 2018/19. Prof. Dr. Dirk Müller. 1 Einführung

Transkript

1 Software Factories 1 Einführung Prof. Dr. Dirk Müller

2 Überblick Master-Studiengang Angewandte Informatik Wintersemester 2018/19 2 SWS Vorlesung + 2 SWS Praktikum Prüfungsvorleistung: Belegarbeit Ausgabe im November Abgabe im Januar Prüfung: Klausur (90 min, mit Unterlagen) Kontakt: Prof. Dr. Dirk Müller Fakultät Informatik/Mathematik, Büro: Z 466 Sprechstunde: mittwochs Uhr bis Uhr Tel.: muellerd@ /17

3 Organisatorisches Vorlesung Modul I-755 Software Factories Gruppen: 18/046/ (alle) Fr Uhr Uhr 15 Sitzungen Praktikum zusammen mit Herrn J. Roeper Raum S 131 zuerst wöchentliches Aufgabenblatt später betreutes Arbeiten am Beleg Gruppen: 18/046/ (alle) Di 9.20 Uhr Uhr 3/17

4 Literatur T. Stahl, M. Völter, S. Efftinge, A. Haase: [StaV07] Modellgetriebene Softwareentwicklung Techniken, Engineering, Management, dpunkt.verlag, 2. Aufl E. Clayberg, D. Rubel: Eclipse Plug-ins, Addison-Wesley, 3. Aufl [ClR2009] C. Rupp, S. Queins, B. Zengler: UML 2 glasklar, Praxiswissen für die UML-Modellierung, Carl Hanser Verlag, 4. Aufl., 2012 [RupQ12] Ian Sommerville: Software Engineering 9, Addison-Wesley, 2010 auch: neue Auflage SE 10 von 2016 [Som10] W. Pree: Komponentenbasierte Softwareentwicklung mit Frameworks, dpunkt.verlag, 1997 [Pre1997] 4/17

5 Übersicht zur Vorlesung Grundlagen der Softwaretechnik Softwareentwicklungsprozesse Modellgetriebene Softwareentwicklung Werkzeugentwicklung mit Eclipse Plug-ins Rich Client Applications Werkzeuge zur Unterstützung der MDSD Eclipse EMF, GMF OpenArcitectureWare (oaw) mit Xtext, Xtend und Xpand Aspektorientierte Programmierung Software Factories Fallstudie einer MDSD-Infrastruktur unter Eclipse für Java-EE- Anwendungen 5/17

6 Software-Enthusiasmus in 1950ern Software mit riesigen Vorteilen gegenüber Hardware auf Universalrechnern für alle Zwecke einsetzbar ja, aber das zeigt die Verantwortung eines Informatikers einfach zu schreiben, zu testen und zu pflegen 2012 nur 39% aller Projekte erfolgreich einfach zu replizieren zu kopieren ja, aber zu portieren nein kein Verschleiß ja, aber relative Alterung Modellgetriebene SW-Entw. keine flüchtigen Fehler für einfache Programme ja, aber bei Multithreading auf Mehrkern-Prozessoren Heisenbugs durch z. B. Race Conditions sogar typisch 6/17

7 Software und Computer Software als eine spezielle Form von Daten immateriell, keine physikalischen Gesetze kein Verschleiß, aber relative Alterung keine SI-Einheit, aber Anzahl der Codezeilen (lines of code, LOC) oft genutzt: SW-Metriken fragwürdiges Leistungsmaß Produktivität in LOC/Monat (motiviert aufgeblähten Code) Wiss. Leistung in eingeworbener Drittmittelrate z. B. in /Jahr (Geld ist ein Mittel, nicht das Forschungsziel) Energieeffizienzklasse Pkws (Bezug des CO2-Ausstoßes auf Masse, nicht auf Nutzfläche oder -volumen, Masse ist Mittel und nicht Ziel) Freiheit: sehr flexibel Verantwortung: sehr komplex Computer nicht einfach neue Maschinen, sondern neue Qualität: digitale Revolution 7/17

8 Magisches Dreieck Gute Software soll schnell und zu geringen Kosten entwickelt werden. meistens Fokussierung auf 2 der Ziele nötig seit 1968 (NATO-Konferenz in Garmisch) ingenieurmäßiger Ansatz propagiert, da Größe und Komplexität mit unstrukturierten Methoden nicht mehr beherrschbar Qualität Zeit Kosten 8/17

9 Qualität von Software: ISO/IEC 9126 von 2001 Was? Wie? (nichtfunktionale Eigenschaften) Design for Change [1] 9/17

10 Qualität von Software: ISO/IEC 250mn von 2011 Software product Quality Requirements and Evaluation (SQuaRE) zwei neue Hauptkriterien, somit jetzt insgesamt acht Sicherheit (Security) Kompatibilität: Koexistenz und Interoperabilität Funktionalität heißt jetzt funktionale Angemessenheit Effizienz heißt jetzt Leistungseffizienz Änderbarkeit mit Modularität und Wiederverwendbarkeit Zuverlässigkeit mit Verfügbarkeit 10/17

11 Definitionen Ziel: kostengünstige Entwicklung von SW hoher Qualität David Parnas [1]: Design for Change multi-person construction of multi-version programs Helmut Balzert: Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen. Zielorientiert bedeutet die Berücksichtigung z. B. von Kosten, Zeit, Qualität. [Bal09], S. 17 IEEE [2]: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. 11/17

12 Begriffe Software-Engineering (engl.), F. L. Bauer, 1968 Softwaretechnik, auch: Softwaretechnologie, Abk.: SWT, SE Software, John W. Tukey, 1958 Programm + Dokumentation + Konfigurationsdaten + Modelle Gegensatz: Hardware, Zwischenstufe Firmware spezielle Form von Daten, die zusammen mit Hardware und Anwendungsdaten einen Computer ausmachen Engineering, ca planvolles, gezieltes Vorgehen zum Entwurf, Bau, zur Erhaltung und Verbesserung von Maschinen, Geräten, Systemen, Strukturen und Prozessen Gegensatz: Kunst und Wissenschaft military engineering vs. civil engineering Metapher liefert Bezeichnung, aber Analogien begrenzt 12/17

13 Kritik am Begriff Donald Knuth: Kunst und Wissenschaft, aber keine Ingenieurwissenschaft Edsger W. Dijkstra: Engineering ist der falsche Begriff, Ziel ist widersprüchlich in sich, How to program if you cannot. nur sehr selten als anerkannter Berufsabschluss Revolutionen statt Evolution legen nahe, dass es sich (noch?) nicht um eine Ingenieurwissenschaft handelt Strukturierte Programmierung seit ca Objekt-orientierte Programmierung seit ca Generische Programmierung seit ca Modellgetriebene Programmierung seit ca Aspektorientierte Programmierung seit ca /17

14 Software-Lebenszyklus (1/2) meist Unterschätzung der Lebensdauer von SW-Systemen Design for Change z. B. Space Shuttle der NASA Betrieb ist normalerweise die längste und teuerste Phase Größenordnung Jahrzehnte ist typisch Wartung und Evolution Software-Alterung [3] kein Verschleiß wie bei materiellen Dingen Umgebung ändert sich (Anforderungen und Hardware sowie andere Software) => relative Alterung Anpassungen verschlechtern Struktur, was zu noch mehr Alterung führt (Gegenmaßnahme: Refactoring) Hardware Alterung Anforderungen SW-Umgebung Änderungen 14/17

15 Software-Lebenszyklus (2/2) Funktionale Angemessenheit Benutzbarkeit Leistungseffizienz Zuverlässigkeit Abschaltung bzw. Ablösung Betrieb Start der Entwicklung Spezifikation Änderbarkeit Installation Entwurf Kompatibilität Übertragbarkeit Änderbarkeit Implementierung Funktionale Angemessenheit Benutzbarkeit Sicherheit Quelle: [Bal11], S. 1 f. 15/17

16 Zusammenfassung Softwaretechnik als Reaktion auf Softwarekrise seit 1968 Umfang und Komplexität wachsen exponentiell Heterogenität Auslieferungsdruck (Produktzyklen immer kürzer) Vertrauen Erstellung von Programmen mit mehreren Versionen durch mehrere Personen Qualität von Software: Funktionale Angemessenheit und nichtfunktionale Eigenschaften mit wichtigster darunter Änderbarkeit: Design for Change Magisches Dreieck aus Qualität, Zeit und Kosten meist Fokussierung auf zwei der drei Ziele nötig SW-Lebenszyklus mit 5 Phasen: Spezifikation, Entwurf, Implementierung, Installation und Betrieb 16/17

17 Literatur [1] Parnas, David Lorge: Software engineering or methods for the multiperson construction of multi-version programs, Programming Methodology, Springer Berlin Heidelberg, 1975, S [2] Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.) SWEBOK: Guide to the Software Engineering Body of Knowledge. Piscataway, NJ, USA: IEEE [3] Parnas, D. L.: Software Aging. In: Int'l Conf. on Software Engineering. IEEE Computer Society Press, Sorrento, Italy 1994, S /17