Methodische Softwareentwicklung - Software Engineering Kassel
Methodische Softwareentwicklung - Software Engineering Kassel
Methodische Softwareentwicklung - Software Engineering Kassel
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Albert Zündorf<br />
Albert Zündorf<br />
<strong>Methodische</strong> <strong><strong>Software</strong>entwicklung</strong><br />
(Programmiermethodik)<br />
Vorlesung im Wintersemester 2003/2004<br />
Prof. Albert Zündorf<br />
Fachgebiet für <strong>Software</strong> <strong>Engineering</strong><br />
Wilhelmshöher Allee 71-73<br />
34121 <strong>Kassel</strong><br />
(Raum 0630 im Neubau)<br />
Organisatorisches:<br />
Umfang: 4 SWS teils Vorlesungen teils Übungen<br />
Übungsbetreuung: Ira Diethelm, Carsten Reckord und Tutoren<br />
Ort und Zeit:<br />
Vorlesung: Dienstags 14:00 - 15:30 Raum 0446<br />
(Erste Vorlesung: 19.10.04)<br />
Übung: Donnerstags 11:00 - ... , Raum 0425 (CIP Pool unter der Mensa)<br />
(Erste Übung: Donnerstag, den 28.10.2003)<br />
Prüfung:<br />
• Projektarbeit (geeignet am Anfang der Ferien)<br />
• Wiederholung in der ersten Woche des Folgesemesters<br />
Folienskript:<br />
• http://www.uni-kassel.de/fb16/se/<br />
• meist am Wochende vorher.<br />
MSEInhalt.fm,1<br />
MSEInhalt.fm,2
Albert Zündorf<br />
Literatur:<br />
Grundlegend:<br />
• Helmut Balzert: Lehrbuch der <strong>Software</strong>-Technik (Bd.\ 1 und 2), Spektrum Akademischer<br />
Verlag 1996 (viele Details, sehr umfassend, eher ein Nachschlagewerk)<br />
Unified Modeling Language:<br />
• Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language - User<br />
Guide, Addison Wesley 1999 (die haben das erfunden)<br />
• Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language - Reference<br />
Manual, Addison Wesley 1999 (eher zum Nachschlagen)<br />
• Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified <strong>Software</strong> Development Process,<br />
Addison Wesley 1999 (relativ wichtiges Standardwerk)<br />
• Jochen Seemann, Jürgen Wolff von Gudenberg: <strong>Software</strong> Entwurf mit UML; Springer<br />
2000 (finde ich ziemlich gut)<br />
• Martin Hitz, Gerti Kappel: UML @ Work, dpunkt.verlag 1999 (ziemlich gut)<br />
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns, Addison Wesley<br />
1995 (wichtiger Trendsetter, siehe auch Vorlesung Design Pattern im Hauptstudium)<br />
• Albert Zündorf: Rigorous <strong>Software</strong> Development with UML, Draft, Fachgebietsseiten<br />
Albert Zündorf<br />
Hintergrund:<br />
MSEInhalt.fm,3<br />
• Frederick P.\ Brooks: The Mythical Man Month, Addison Wesley 1975 (ist nur kurz<br />
aber ziemlich witzig, unbedingt mal lesen)<br />
MSEInhalt.fm,4
Albert Zündorf<br />
Gliederung:<br />
1. Einführung<br />
2. Anforderungsdefinition<br />
3. Analyse<br />
4. Design<br />
5. Implementierung<br />
6. Zusammenfassung<br />
Albert Zündorf<br />
1. Einführung<br />
Was ist <strong>Software</strong> <strong>Engineering</strong>:<br />
D. Parnas (1987)<br />
<strong>Software</strong> engineering = multi-person construction of multi-version software<br />
MSEInhalt.fm,5<br />
Standard Glossary of <strong>Software</strong> <strong>Engineering</strong>, ANSI, IEEE (1990)<br />
The application of a sytematic, disciplined, quantifiable approach to the development,<br />
operation, and maintenance of software;<br />
that is, the application of engineering to software<br />
A. Zündorf (2003)<br />
Hacken ist, wenn der Mensch schwitzt, damit das Programm (effizient) läuft<br />
<strong>Software</strong>technik ist, wenn der Entwickler es leicht hat,<br />
der Rechner kann ruhig schwitzen.<br />
MSEInhalt.fm,6
Albert Zündorf University of <strong>Kassel</strong><br />
Motivation:<br />
• Bau einer Garage:<br />
- ein paar Handwerker<br />
- Steine, Balken, ...<br />
- Mischer, ...<br />
- auf geht’s<br />
• Bau eines Mehrfamilienhauses<br />
- viele Handwerker<br />
- Steine, Balken, ...<br />
- Verschalungen, Beton, ...<br />
- Kran, Mischer, ...<br />
- Architekt, Bauleiter, ...<br />
- Verträge, Baupläne, ...<br />
- Zeitpläne, ...<br />
• Programm bis 10.000 LOC:<br />
- ein paar Programmierer<br />
- Programmiersprache, ...<br />
- Rechner, Compiler, ...<br />
- auf geht’s<br />
• Programm um 500.000 LOC<br />
- viele Programmierer<br />
- Programmiersprache, ...<br />
- Objektorientierung, ...<br />
- Rechner, Compiler, ...<br />
- Architekt, Bauleiter, ...<br />
- Verträge, Baupläne, ...<br />
- Schnittstellenabsprachen, ...<br />
- Zeitpläne, ...<br />
Albert Zündorf University of <strong>Kassel</strong><br />
• Bau eines Wolkenkratzers<br />
- sehr viele Handwerker<br />
- Steine, Balken, ...<br />
- Verschalungen, Beton, ...<br />
- Stahlträger, ...<br />
- Kran, Mischer, ...<br />
- Architekt, Bauleiter, ...<br />
- Verträge, Baupläne, ...<br />
- Konstruktionsskizzen, Prinzipstudien, ...<br />
- Zeitpläne<br />
- Logistikstudien und -pläne<br />
- Unterkünfte, Großküche, Shuttle-Service,<br />
...<br />
• System um 2.500.000<br />
- sehr viele Programmierer<br />
- Programmiersprache, ...<br />
- Objektorientierung, ...<br />
- Modellierungssprachen (UML)<br />
MSEInhalt.fm,7<br />
- Rechner, Compiler, CASE Tools, ...<br />
- Architekt, Bauleiter, ...<br />
- Verträge, Baupläne, ...<br />
- Konstruktionsskizzen, Prinzipstudien, ...<br />
- Zeitpläne<br />
- Logistikstudien und -pläne<br />
- Internet, Groupware, ...<br />
MSEInhalt.fm,8
Albert Zündorf<br />
Probleme im Bereich <strong>Software</strong>:<br />
• Nach Laprie 1999:<br />
Albert Zündorf<br />
- 1/3 der Projekte wird zur Zufriedenheit der Kunden und des Anbieters durchgeführt<br />
- 1/3 der Projekte überzieht Zeit und Kosten, liefert nur Teilfunktionalität,<br />
Programme instabil<br />
- 1/3 der Projekte scheitert ganz.<br />
• Beispiele für prominente Probleme und Katastrophen:<br />
- Windows 9x<br />
- Ausfall Leitrechner Hamburger Bahnhof bei Neueröffnung (1995)<br />
- Explosion Ariane 5 Rakete (1996)<br />
- Airbus Absturz in Moskau<br />
- Ausfall des Londoner Ambulanz-Systems bei Einführung<br />
MSEInhalt.fm,9<br />
- wochenlange Schließung des Airports Chicago wegen neuem Flugkontrollsystem<br />
- Lieferverzögerungen bei Audi TT<br />
- ...<br />
- siehe auch http://catless.ncl.ac.uk/Risks<br />
MSEInhalt.fm,10
Albert Zündorf<br />
Hauptproblemquellen:<br />
• die schiere Größe der Systeme:<br />
- Handy circa 2 MLOC<br />
- SAP 1994 circa 7 MLOC, 100.000 Methoden, etwa 1000 <strong>Software</strong>entwickler<br />
- ...<br />
• viel zu viele Bugs:<br />
Albert Zündorf<br />
- 1977 circa 7 bis 20 Fehler pro 1000 LOC "gefunden"<br />
- 1994 circa 0,2 bis 0,5 Fehler pro 1000 LOC "gefunden"<br />
- voraussichtlich weiter alle 5 bis 10 Jahre 1/10 Fehlerrate<br />
aber aktuelle Fehlerrate entspricht wöchtlich<br />
- 6 ausfallende Herzschrittmacher<br />
- circa 120 Flugzeugabstürze<br />
- in kritischen Systemen sind Fehlerraten von 10 -9 vorgeschrieben<br />
MSEInhalt.fm,11<br />
• schlechter Ausbildungsstand<br />
- in den 60er und 70er Jahren "umgeschulte Buchhalter" als Cobol-Programmierer<br />
- Heute viele "Umsteiger", Autodidakten, Umschüler, ...<br />
- hohe Personalfluktation<br />
• mangelnde Vorstands- und Managementpräsenz<br />
- Vorstände und Manager unterschätzen <strong>Software</strong>probleme<br />
- zu gering angesetzte Resourcen führen zu Fehlern und Verzögerungen<br />
- "unzuverlässige Softis" kommen nicht in die Vorstände und ins Management<br />
• <strong>Software</strong> hat den "schwarzen Peter" bei Änderungen der Anforderungen<br />
- <strong>Software</strong> gilt als flexibel und leicht änderbar<br />
- <strong>Software</strong> muss oft Planungsfehler aus anderen Bereichen "last minute" ausbügeln<br />
• mangelhaftes Projektmanagement<br />
- keine ausreichende Aufwandsschätzung<br />
- keine ausreichende Personalplanung<br />
- miserable Teamkoordination<br />
- lächerliche Qualitätssicherung<br />
MSEInhalt.fm,12
Albert Zündorf<br />
Entstehung der <strong>Software</strong>technik<br />
• Ende der 60er Jahre<br />
- zentrale (Stickstoff gekühlte) Großrechner 3KB Hauptspeicher, 1 KHz CPU, Magnetbänder, ...<br />
- Assembler, Fortran, Cobol, C, ...<br />
- Programmgrößen bis 1000 LOC (Lines of Code) klappt<br />
• 1972 Konferenz in Garmischpartenkirchen ruft "<strong>Software</strong>krise" aus<br />
Lösungsidee: Ingenieurmäßige <strong><strong>Software</strong>entwicklung</strong> => <strong>Software</strong>technik<br />
• Um 2000:<br />
- Leistungsfähige PCs und Server, 1GB Hauptspeicher, 1 GHz CPU, 1 TB Platten, ...<br />
(Faktor 10 ^6 in 30 Jahren)<br />
- Eiffel, Java, ...<br />
- Programmgrößen bis 1 000 000 LOC (Lines of Code) klappt<br />
(Faktor 10 ^3 in 30 Jahren)<br />
• Voraussichtlich wird sich die zu beherrschende Problemgröße alle 3 Jahre verdoppeln<br />
Bemerkung: Die "Produktivität" der Entwickler ist nicht wesentlich gewachsen<br />
50 -100 LOC pro Tag (=> eine LOC kostet circa 10 Euro)<br />
Albert Zündorf<br />
MSEInhalt.fm,13<br />
<strong>Software</strong>qualität<br />
Ziel der <strong>Software</strong>technik ist eine Steigerung der <strong>Software</strong>qualität (und eine Senkung der Kosten)<br />
Das beinhaltet die Begriffe:<br />
• Funktionalität<br />
Funktionale Anforderungen werden erfüllt.<br />
• Zuverlässigkeit<br />
Das Programm läuft bei normaler Benutzung ohne Absturz.<br />
• Robustheit<br />
Das Programm fängt fehlerhafte Benutzung und andere Fehlersituationen gut ab.<br />
• Benutzbarkeit<br />
Auch von Studenten, Laien, Professoren und Vorständen bedienbar.<br />
Wichtige Dinge sind einfach auslösbar.<br />
MSEInhalt.fm,14
Albert Zündorf<br />
• Effizienz<br />
Gutes Verhältnis von Ergebnis und Aufwand an Rechenzeit und Speicherbedarf<br />
(verliert stark an Bedeutung)<br />
• Wartbarkeit<br />
auch später (nach Auslieferung) können neue Anforderungen leicht umgesetzt werden.<br />
• Wiederverwendbarkeit<br />
Einmal erstellte (und getestete) Bausteine können möglichst ohne Modifikationen in<br />
anderen Programmen verwendet werden<br />
(Heute Components, Product-Line-Architectures)<br />
• . . .<br />
Albert Zündorf<br />
Lösungsansätze der <strong>Software</strong>technik:<br />
• Bessere <strong>Software</strong> Ingenieure<br />
• Bessere Programmiersprachen<br />
• Objektorientierte Entwurfsmethoden<br />
• Bessere Werkzeuge<br />
• Formale Methoden<br />
• Wiederverwendung<br />
• Reengineering<br />
• Besseres Projektmanagement<br />
=> Prozess- / Vorgehensmodelle, Konfigurationsmanagement<br />
aber<br />
• "No silver bullet" F. Brooks, IEEE Computer 1987<br />
MSEInhalt.fm,15<br />
MSEInhalt.fm,16
Albert Zündorf<br />
Das Wasserfallmodell<br />
Albert Zündorf<br />
Anforderungsdefinition<br />
technisch, inhaltlicher Bereich => <strong>Methodische</strong> <strong><strong>Software</strong>entwicklung</strong><br />
Analyse<br />
Projektmanagement<br />
Design<br />
Implementierung<br />
<strong>Methodische</strong> <strong><strong>Software</strong>entwicklung</strong> (Programmiermethodik)<br />
1. Systematische Erfassung von Anforderungen<br />
2. <strong>Methodische</strong> Ableitung von objektorientierten Szenario-Beschreibungen<br />
plus Domänen-Modell / -Klassendiagramm<br />
3. <strong>Methodische</strong> Ableitung von automatischen Tests<br />
Qualitätssicherung<br />
4. <strong>Methodische</strong> Ableitung von Verhaltensspezifikationen / grafischen Programmen<br />
plus Design-Modell / -Klassendiagramm<br />
5. Automatische Code-Generierung<br />
6. Systematisches Testen<br />
Noch nicht erfasst:<br />
• Grafical User Interface<br />
• Wartung<br />
Test<br />
Wartung<br />
MSEInhalt.fm,17<br />
MSEInhalt.fm,18
Change language