Software-Technologie: Stand der Kunst und Herausforderungen O.Univ.-Prof. Dipl.-Ing. Dr. Wolfgang Pree Software & Systems Research Group Universität Salzburg cs.uni-salzburg.at Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
Kontext Das Phänomen Software Wie kann Software ingenieurmäßig entwickelt werden? Softwaretechnik Quo vadis? 2
Das Phänomen Software 3
Die Universalmaschine Computer macht Software allgegenwärtig Flugzeug-/Raketensteuerungen 4 ca. 70 Prozessoren im Auto
Qualität ist wesentlich schlechter als bei anderen Produkten Softwarefehler/-mängel mit drastischen Auswirkungen: Y2K, -Umstellung fehlerhafte Finanztransaktionen Abstürze (zb Ariane: $ 800 Mio.)... 5
Was ist besonders an Software? 6
Die Probleme bei der Herstellung von Software resultieren aus der Komplexität der zu realisierenden Produkte 7 Spezifikation der Anforderungen Beherrschung der Komplexität Wiederverwendung/PlugIns, Änderbarkeit und Erweiterbarkeit Automatisierung im Herstellungsprozeß Portabilität Psychologie (zb Piaget) Dokumentation Produktergonomie (Mensch-Computer- Schnittstelle) Projektorganisation u. -kontrolle Qualitätssicherung und -bewertung Personenunabhängigkeit Kostenabschätzung Prototyping Programmiermodelle Entwurfsmuster Frameworks
Beispiel: Problem der exakten Spezifikation 8
Eine exakte Spezifikation ist oft unpraktikabel geg.: n 3, L: N n N ges.: Ein Programm P, sodass inj a: N 3 N n, sodass 1 i 3 j ε N n \ U { a k } 1 k j L(a i ) L(a J ) 9
... im Vergleich zur nicht exakten verbalen Spezifikation Gegeben ist eine Liste mit mindestens drei positiven Zahlen. Gesucht ist ein Programm P, das die Indizes der drei größten Elemente der Liste liefert. 10
Meisterung der Komplexität 11
Bei klassischen Ingenieurdisziplinen gilt: Schlechte Qualität läßt sich kaum verbergen Tür zu einem Raum geht nicht gut auf unnötige Schnörksel fallen auf 5. Rad am Wagen Die Ressourcen sind beschränkt ingenieurmäßiges Herangehen bedeutet, unter den gegebenen Rahmenbedingungen zu optimieren 12
Bei Software hingegen ist schlechte Qualität nicht unmittelbar sichtbar schlechte Strukturierung Spaghetti -Programmcode: Radwechsel => Motor funktioniert nicht mehr replizierter Programmcode kaum Wiederverwendung das Rad wird immer neu erfunden 13
Ingenieurmäßiges Vorgehen scheint sich nicht auszuzahlen Hardware-Ressourcen werden nach Moore s Law potenter; der gedankenlose Umgang damit führt zu unnötiger Komplexität nicht mehr verstehbaren Artefakten OberonOS (ETH ZH) 30.000 Zeilen Programmcode 4,1 cm 27,5 m Windows XP: 20,000.000 (!!) Zeilen Programmcode 14
Wie kann Software ingenieurmäßig entwickelt werden? 15
von Einzelteilen zu Komponenten 50er Jahre Maschinen-/Assembler-Programme: auf bestimmten Prozessor zugeschnitten 60er/70er Jahre höhere Programmiersprachen (wie Pascal, C) Anweisungen können zu Funktionen/Prozeduren zusammengefasst werden Einzelteile, Schrauben, etc. 80er/90er Jahre Funktionen/Prozeduren werden zu Modulen zusammengefasst (Modula, Oberon, C++, Java, C#) Software-Komponenten 16
Beispiel: Komponente File-Handler einfache Schnittstelle File lesen File schreiben... 17 versteckte Implementierungsdetails: Zugriff auf Festplatte Aufsplitten des Inhalts eines Files etc.
Architektur-Patterns Software-Patterns 18
The Timeless Way of Building Christopher Alexander, Professor of Architecture, Univ. of California, Berkeley: 1979 erschienene Bücher: The Timeless Way of Building A Patttern Language (253 Patterns) Quality without a name 1991 von der Software-Community entdeckt 19
Beispiel: Windows Overlooking Life 20
Beispiele für Software Patterns 21
Wie können SW-PlugIn-Architekturen geschaffen werden? Beschrieben in Architektur-Handbüchern (1995): E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns: Elements of Reusable Software W. Pree: Design Patterns for Object-Oriented Software Development 22
Was sind PlugIn-Architekturen? Küchenmaschine: durch Einstecken einer Komponente wird das vorhandene PlugIn-System zum fertigen Mixer oder Fleischwolf neue Automodelle gleichen meist im Kern (Chassis, Getriebe, Motorpalette) den Vorgängermodellen 23
SW-Beispiele Einwegsoftware: Hotelreservierungssystem Autovermietungssystem Schiverleihsystem Motorradverleihsystem etc. PlugIn-Architektur: Reservierungssystem (Mietgegenstand) 24
Einwegsoftware Abhängigkeit zwischen den Komponenten ist im Programmquelltext: Hotelzimmer Kopplung mit einer anderen Komponente erfordert Änderungen: Auto 25
Pattern: PlugIn-Architekturen erfordern die Definition von Steckern Stecker Mietgegenstand Stecker-kompatible Komponenten 26
sogenannte dynamische Bindung von Aufrufen macht Änderungen im Source-Code obsolet m1() m1() m1() call m1 27
Stecker Mietgegenstand Definiert allgemeine, abstrakte Eigenschaften: istfrei(zeitraum) reserviere(zeitraum) berechnepreis(zeitraum) etc. 28
29
PlugIn-Architektur für Satellitensteuerungen in Kooperation mit der European Space Agency (ESA): 1998 2002 30
Automatische Generierung von Software aus Bauplänen (Modellen) 31
Compiler: DIE Erfolgsgeschichte der Softwaretechnik Programmtext (Pascal, C#, xuml) ausführbares (Maschinen-)Programm a+b als Maschinenprogramm: 010 100 "hole die Zahl vom Speicherplatz 100(a) in einen Puffer" 015 101 "addiere dazu den Inhalt von Speicherplatz 101(b)" 011 102 "speichere das Ergebnis in Zelle 102(a+b) für das Zeitverhalten von Embedded Systems noch ausständig für andere Anwendungsbereiche denkbar? 32
Beispiel: Helicopter Control System (I) Henzinger, Kirsch, Pree, Sanvido (UC Berkeley) Schaufelberger, Wirth (ETH Zürich) 33
Beispiel: Helicopter Control System (II) 34
Giotto als höhere Programmiersprache = Bauplan = Modell für Zeitaspekte Mode 1 Task S 400 Hz Task C 200 Hz Task A 1 khz Condition 1.2 Condition 2.1 Mode 2 Task S 400 Hz Task C 200 Hz Task A 1 khz Task A 1 khz Mode 3 Task S 400 Hz Task C 200 Hz Task A 2 khz Mode 4 Task C 100 Hz Task A 1 khz => spezif. HW-Plattform wird irrelevant 35
Generierung der Software + deren Verteilung auf Prozessoren erfolgt automatisch Sensor Driver Task d Actuator Task on CPU. Input ports loaded. Output ports read. Time t Time t Time t +d Time t +d 36
Softwaretechnik Quo vadis? 37
kostenintensive Wartung von Software, die 20-30 Jahre alt ist ingenieurmäßige Herangehensweise wird sich zumindest in Teilbereichen etablieren, zb bei sicherheitskritischen Systemen 38
simple, mechanische Weltsicht schwer skalierbar Vorbild biologische Systeme Internet wuchs um den Faktor 100 Mio. 39
Softwaretechnik Quo vadis? 40
The End Vielen Dank für Ihre Aufmerksamkeit! 41