Folien basieren auf folgendem Buch: Objektorientierte Analyse und Design Kernziele: Strukturen für erfolgreichen SW-Entwicklungsprozess kennen lernen Realisierung: Von der Anforderung zur Implementierung Grundkurs Software-Engineering mit UML Konzepte für die erfolgreiche Software- Entwicklung Bitte beachten Sie die Rechte des Verlages Vieweg+Teubner an der Buchinhalten und Bildern Diese Folien sind als Begleitfolien für das Buch konzipiert 1 2 Ablauf Verhaltenscodex 2h Vorlesung + 2h Praktikum = 5 CP Praktikum (2er Gruppen): 75% Anwesenheit = (Übungsblatt vorliegen + Lösungsversuche zum vorherigen Aufgabenblatt) 12-13 Übungsblätter mit jeweils 8 Punkten (Σ 100) Praktikum mit 75 oder mehr Punkten bestanden Vorlesung: mündliche Prüfung nach VL-Zeit Folienveranstaltungen sind schnell, bremsen Sie mit Fragen von Studierenden wird hoher Anteil an Eigenarbeit erwartet Melden Sie sich in Stud.IP an! Rechner sind zu Beginn der Veranstaltung aus Handys sind aus Wir sind pünktlich Es redet nur eine Person zur Zeit Sie haben die Folien zur Kommentierung in der Vorlesung vorliegen, ab Fr-Abend liegen Unterlagen im Netz (Ihre Aufgabe) http://www.edvsz.fh-osnabrueck.de/kleuker/index.html Probleme sofort melden Wer aussteigt teilt mit warum 3 4
Praktikum genauer Praktikumsaufgaben müssen jeweils als Ergebnisse im Praktikum der Folgewoche vorliegen; diese werden dort abgenommen Falls jemand nicht kommt, sind die Ergebnisse per E-Mail spätestens am Praktikumstag an den Praktikumsleiter zu schicken; werden in der Folgewoche abgenommen Aufgaben dürfen in Gruppen von maximal zwei Studierenden bearbeitet werden; jeder muss in der Lage sein, jedes Gruppenergebnis vorzustellen (gerade auch bei evtl. späteren Abnahmen) Treten ähnliche Ergebnisse bei mehr als einer Arbeitsgruppe auf, werden diese bei allen Arbeitsgruppen gestrichen Besorgen Sie sich ein Login für die Linux-Rechner des Labors Software-Technik: http://www.lbst.ecs.fh-osnabrueck.de/anmeldung Veranstaltung im Studienkontext + Sie können grundsätzlich imperativ Programmieren (C) + Sie haben Grundkenntnisse in der OO-Programmierung (C++, Java) + Sie arbeiten sich gerade in Datenbanken ein (Überschneidung bei Modellierung, Grundkenntnisse werden in der Mitte der Veranstaltung genutzt) = Sie können erfolgreich an dieser Veranstaltung teilnehmen + nächstes Semester: Veranstaltung Software-Engineering Projekt (Vorlesungsanteil zur Organisation von SW-Projekten in Unternehmen, großes Praktikumsprojekt, 10 CP) 5 6 weitere Literatur Werkzeuge Generell lesenswert: Mario Winter, Methodische objektorientierte Softwareentwicklung, dpunkt.verlag, Heidelberg Bernd Oestereich, Analyse und Design mit UML 2.1, 8. Auflage, Oldenbourg, München C. Rupp, S. Queins, B. Zengler, UML 2 glasklar, Hanser, München Wien Ian Sommerville, Software Engineering, 8. Auflage, Addison Wesley, Boston Spezialliteratur wird zum jeweiligen Kapitel genannt Benutzt wird Eclipse 3.4 mit einigen Erweiterungen und kleinen Macken SW von Web-Seite kopierbar Installation durch Auspacken; Plugins (Erweiterungen) sind bereits enthalten keine aktuelleren Versionen nutzen, da diese mit Plugins eventuell nicht zusammenpassen es gibt professionellere Werkzeuge, die aber nicht generell frei verfügbar sind (jedes Unternehmen kocht hier seinen eigenen Werkzeugbrei zusammen) 7 8
Inhaltsverzeichnis 1 Motivation von Software-Engineering 2 Prozessmodellierung 3 Vorgehensmodelle 4 Anforderungsanalyse 5 Grobdesign 6 Vom Klassendiagramm zum Programm 7 Konkretisierungen im Feindesign 8 Optimierung des Designmodells 9 Implementierungsaspekte 10 Oberflächengestaltung 11 Qualitätssicherung kurz, genauer nächstes Semester schon behandelt 12 Umfeld der Software-Entwicklung nächstes Semester 1. Motivation von Software- Engineering 9 10 Historie des SW-Engineering (1/4) Ende 60er Bedarf für Softwaretechnik neben der reinen Programmierung erstmals voll erkannt Vorher sind zahlreiche große Programmentwicklungen (möglich durch verbesserte Hardwareeigenschaften) gescheitert Arbeiten von Dijkstra 1968 (u.a. gegen Verwendung von GOTO) und Royce 1970 (Software-Lebenszyklus), Top-Down-Entwurf, graphische Veranschaulichungen (Nassi-Shneiderman Diagramme) Mitte 70er Top-Down-Entwurf für große Programme nicht ausreichend, zusätzlich Modularisierung erforderlich Entwicklung der Begriffe Abstrakter Datentyp, Datenkapselung und Information Hiding Historie des SW-Engineering (2/4) Ende 70er Bedarf für präzise Definition der Anforderungen an ein Softwaresystem, Entstehen von Vorgehensmodellen, z. B. Structured Analysis Design Technique (SADT) 80er Jahre Vom Compiler zur Entwicklungsumgebung (Editor, Compiler, Linker, symbolischer Debugger, Source Code Control Systems) Weiterentwicklung der Modularisierung und der Datenkapselung zur objektorientierten Programmierung 90er Jahre Objektorientierte Programmierung nimmt zu (wieder ausgehend von der Implementierung) Neue Programmiersprache Java (ab Mitte 80er C++) Anwendungs-Rahmenwerke (Application Frameworks) zur Vereinfachung von Design und vor allem Programmierung 11 12
Historie des SW-Engineering (3/4) 90er Jahre Geeignete Analyse- und Entwurfsmethoden entstehen (Coad/Yourdon, Rumbaugh, Booch, Jacobson und andere) 1995 Vereinigung mehrerer Ansätze zunächst als Unified Method (UM) von Booch und Rumbaugh, dann kommt Jacobson hinzu (Use Cases). 3 Amigos definieren die Unified Modeling Language (UML) als Quasi-Standard. 1997 UML in der Version 1.1 bei der OMG (Object Management Group) zur Standardisierung eingereicht und angenommen UML ist jedoch keine Entwicklungsmethode (Phasenmodell), nur eine Beschreibungssprache 1999 Entwicklungsmethode: Unified Process (UP) und Rational Unified Process (RUP) (erste Version) Historie des SW-Engineering (4/4) Heute Vorgehensweisen auf individuelle Projektanforderungen abgestimmt CASE-Methoden und Tools orientieren sich an der UML Aktueller Stand 2007: UML 2.1.1 Aufbauend auf Analyse und Design erzeugen Codegeneratoren Programmgerüste Haupttätigkeiten bei Softwareentwicklung sind Analyse und Design, vieles andere versucht man zu automatisieren (!?) 13 14 Warum scheitern SW-Projekte (kleine Auswahl) Die Software wurde wesentlich zu spät geliefert Die Software erfüllt nicht die Wünsche des Kunden Die Software läuft nicht auf den vereinbarten Rechnersystemen, sie ist zu langsam oder kommt mit dem Speicher nicht aus Die Software kann nicht erweitert werden oder mit anderer Software zusammenarbeiten Antworten des Software-Engineering 1967: Prägung des Begriffs Software-Krise Lösungsansätze: Programmiersprachen: kontinuierliche Einführung von Abstraktion (Datentypen, Funktionen, Modulen, Klassen, Bibliotheken, Frameworks) Dokumentation: Einheitliche Notationen für Entwicklungsergebnisse (UML) Entwicklungsprozesse: Aufgabenbeschreibungen, wann was wie gemacht wird Vorgehensmodelle: Entwicklung passt sich an Bedürfnisse des Kunden an 15 16
Definitionsversuch Software-Engineering Zusammenfassend kann man Software-Engineering als die Wissenschaft der systematischen Entwicklung von Software, beginnend bei den Anforderungen bis zur Abnahme des fertigen Produkts und der anschließenden Wartungsphase definieren. Es werden etablierte Lösungsansätze für Teilaufgaben vorgeschlagen, die häufig kombiniert mit neuen Technologien, vor Ihrer Umsetzung auf ihre Anwendbarkeit geprüft werden. Das zentrale Mittel zur Dokumentation von Software-Engineering- Ergebnissen sind UML-Diagramme. 17