1.6 Wege aus der Softwarekrise

Transkript

1 1.6 Wege aus der Softwarekrise You lot start coding; I'll nip down the corridor and find out what they need. Softwareengineering bedeutet nicht nur Programmieren: Analyse & Design

2 1.6 Wege aus der Softwarekrise Warum Analyse / Design (A/D)? Wer kann Zeilen Code Zeile für Zeile schreiben? Große Systeme -> große Anzahl verschiedener Typen mit gegenseitigen Abhängigkeiten Programmierer, Auftraggeber und Nutzer sind verschiedene Personen

3 1.7 Beispiel: SAGE-Projekt ( ) Luftfahrtüberwachungssystem (US-Militär) 1.1 Mio Befehle 800 Programmierer Hilfskräfte (geplant 100 Programmierer) Vorgehensmodell aus Fertigungs- und Montageprozessen (Phasenmodell) (Engineering und Projektmanagement) Reduzierung des Kommunikationsaufwandes Einsatz von vielen, unerfahrenen Programmierern Projekt wurde mit 1 Jahr Verzögerung fertig

4 1.8 No silver bullet (Brooks '75,'95) Brooks (1986): There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity

5 1.8 No silver bullet (Brooks '75,'95) Komplexität: Große Anzahl von Zuständen, wenig wiederholte Elemente, Seiteneffekte. Konformität: Keine einfachen/einheitlichen Prinzipien (Interfaces) Veränderlichkeit: Großer Änderungsdruck von außen bei scheinbar leichter Veränderbarkeit. Unsichtbarkeit: Software ist abstrakt, schwierig visualisierbar.

6 1.8 Objektorierung als silver bullet? Objektorientierte Analyse/Design (OO A/D): Ganzheitliche Arbeitsgegenstände (Einheit von Daten und Operationen) Bessere Abstraktionsmöglishkeiten (ermöglicht Modellierung im Problembereich) Methodische Durchgängigkeit (gleiche Konzepte in allen Entwicklungsphasen) Evolutionäre Entwicklung (ermöglicht iteratives Vorgehen)

7 1.8 Objektorientierte Analyse und Design Ein kurzes Beispiel (Larman 2005): dice game : Software simuliert einen Spieler, es werden 2 Würfel geworfen, Gesamtpunktzahl 7 gewinnt, andere Zahl verliert. Use Cases Domänenmodell Interaktions- Diagramm Klassen- Diagramm

8 1.8 Objektorientierte Analyse und Design Use Cases Domänenmodell Interaktions- Diagramm Klassen- Diagramm Play a Dice Game: Spieler initiiert Würfeln. System präsentiert Ergebnis: Falls gemeinsame Augenzahl 7, Spieler gewinnt, sonst verliert der Spieler.

9 1.8 Objektorientierte Analyse und Design Use Cases Domänenmodell Interaktions- Diagramm Klassen- Diagramm name Player 1 Rolls 2 Die facevalue 1 Plays 1 DiceGame 1 Includes 2

10 1.8 Objektorientierte Analyse und Design Use Cases Domänenmodell Interaktions- Diagramm Klassen- Diagramm :DiceGame d1:die d2:die play() roll() fv1 = getfacevalue() roll() fv1 = getfacevalue()

11 1.8 Objektorientierte Analyse und Design Use Cases Domänenmodell Interaktions- Diagramm Klassen- Diagramm die1: Die die2: Die play() DiceGame 1 2 Die facevalue: int getfacevalue(): int roll()

12 1.8 Objektorierung als silver bullet? Warum hat sich OO-Technik nicht schon vor langem durchgesetzt? David Parnas [Brooks, 1995]: The answer is simple. It is because [O-O] has been tied to a variety of complex languages. Instead of teaching that O-O is a type of design, and giving them design principles, people have taught that O-O is the use of a particular tool. We can write good or bad programs with any tool.

13 1.9 Warum Projekte trotzdem scheitern... Ariane-5 (4. Juni 1996, selbstzerstört nach 40s)

14 1.9 Warum Projekte scheitern (Ariane 5)... Fehler in Steuerungssoftware (Prog. in Ada) declare vertical_veloc_sensor: float; horizontal_veloc_sensor: float; vertical_veloc_bias: integer; horizontal_veloc_bias: integer;... begin declare pragma suppress(numeric error, horizontal_veloc_bias); begin sensor_get(vertical_veloc_sensor); sensor_get(horizontal_veloc_sensor); vertical_veloc_bias := integer(vertical_veloc_sensor); horizontal_veloc_bias := integer(horizontal_veloc_sensor);... exception when numeric_error => calculate_vertical_veloc(); when others => use_irs1(); end; end irs2;

15 1.9 Warum Projekte scheitern (Ariane 5) Integer-Overflow nicht abgefangen. 2. Anforderungen verlangen, dass sich der Navigations-Rechner in diesem Fall abschaltet. 3. Ersatzrechner schaltet sich ebenfalls ab. 4. Diagnosedaten werden vom Hauptrechner als Flugbahndaten interpretiert. 5. Unsinnige Steuerbefehle riskieren ein Auseinanderbrechen der Rakete. 6. Selbstzerstörungsmechanismus wird ausgelöst.

16 1.9 Warum Projekte scheitern (Ariane 5)... Hintergrund: Steuerungssoftware identisch mit Ariane 4. Analyse für Ariane 4: Overflow physikalisch nicht möglich. Kein Exception-Handler wg. Rechenlast Software lief erfolgreich für Ariane 4. Ariane 5 erreicht Geschwindigkeit von 32768,0 internen Einheiten bei 3700m Höhe (5 mal höher als beim Vorgängermodell) Exceptions als zufällige Hardwarefehler behandelt Ausfall beider Systeme als unmöglich angesehen.

17 1.9 Warum Projekte scheitern (Ariane 5)... Warum wurde der Fehler nicht gefunden? Unit Testing... Keine Trajektoriendaten für Ariane 5 im Pflichenheft der Navigationskomponente. System-Tests... Volles integriertes Testen zu schwierig/zu teuer. Integrierte Test verwendeten nur Simulationen der Navigationskomponente. Code-Inspektion... Die Annahmen der Implementierung waren nicht dokumentiert.

18 1.9 Warum Projekte scheitern... System von Testen und Validieren schlägt fehl. Meistens sowohl Fehler der Entwicklung als auch des Managements. Zuverlässige Software beruht auf Kommunikation (Informationsaustausch) Management (Ressourcen und Risiko) Verifikation und Validierung Risikoidentifikation und -verfolgung In Frage stellen von Annahmen

19 1.10 Sichten auf Softwareentwicklung Programmierung Werkzeuge, Paradigmen, Stile Analyse/Entwurf Use Cases, Domänenmodelle, Klassenmodelle Projektentwicklung Ablaufplanung, Teamorganisation, Monitoring Produktentwicklung Spezifikation, Normen, Qualitätssicherung

20 1.11 Bücher C. Larman Applying UML and Patterns, E. Freeman Head First Design Patterns, F. P. Brooks The mythical man-month, 1975/95. H. Mayr Projekt Engineering, M. Fowler, K. Scott UML Distilled, E. Gamma Design Patterns, A. Cockburn Writing Effective Use Cases, R. Wirfs-Brock, A. McKean Object Design, I. Sommerville Software Engineering 2001.