Einführung in die Softwaretechnologie

Transkript

1 R O O T S Einführung in die Softwaretechnologie Wintersemester 2012 Dr. Günter Kniesel Institut für Informatik III Römerstr. 164, D Bonn gk@cs.uni-bonn.de

2 Themenbereiche der Vorlesung Einführung Softwarequalitäten Komplexität und Änderung Engineering-Prinzipien Teamarbeit und Änderungen Configuration Management Rationale Management Project Management Issue Management Objektorientierte Modellierung OOP UML Design Patterns Refactoring SE Aktivitäten ( Workflows ) Anforderungserhebung Analyse Systemdesign Objektdesign Testen Softwareprozess Wasserfall-, V-Modell, Spiral-Modell Unified Process Agile SW-Entwicklung (XP, Scrum, Kanban, ) Dr. G. Kniesel Vorlesung Softwaretechnologie 1-2 R O O T S

3 Team Prof. Dr. Armin B. Cremers Dr. Günter Kniesel Dr. Tobias Rho Dr. Pascal Bihler Daniel Speicher Mark von Zeschau (né Schmatz) Holger Mügge Jan Nonnen Paul Heckmann Paul Imhoff

4 Fokus in Forschung und Lehre Agile Entwicklungsmethoden Software-Qualität Softwaretechnologie Software-Ergonomie Basistechnologien Mobile Anwendungen Dr. G. Kniesel Vorlesung Softwaretechnologie 1-4 R O O T S

5 Vorlesung Softwaretechnologie Wintersemester 2011/12 R O O T S Kapitel 0. Organisatorisches Stand: Studiengänge / Prüfungen Tutorien Infrastruktur

6 Literatur Basisliteratur Brügge, Dutoit: Object oriented Software Engineering Conquering Complex and Changing Systems, Prentice Hall, Zweite Auflage. bzw. Deutsche Ausgabe des Buches. Weitere Dr. G. Kniesel Vorlesung Softwaretechnologie 1-6 R O O T S

7 Tutorien Was Kleine Gruppen: 1 Betreuer, 3 Studenten, 45 Minuten Gemeinsame Abgabe via SVN Warum Praktische Anwendung des Vorlesungsstoffes Feedback zu Ihren Lösungen Voraussetzung für Prüfungsteilname Wann Ausgabe der Übungszettel: Montag vor Vorlesungsbeginn Abgabe der Lösungen: bis Sonntag 23: Dr. G. Kniesel Vorlesung Softwaretechnologie 1-7 R O O T S

8 Tutorien-Zeiten Keine vorgegebenen Tutorienzeiten! Die Zeiten werden auf Ihre Verfügbarkeit angepasst!! siehe nächste Folie (Online-Anmeldung) Dr. G. Kniesel Vorlesung Softwaretechnologie 1-8 R O O T S

9 Online-Anmeldung zu Tutorien 1. Anmeldung Sie geben Ihre belegten Zeiten ein Reihenfolge der Anmeldung ist unwichtig Sie haben Zeit bis morgen, Donnerstag, , Uhr 2. Zuteilungs-Benachrichtigung mit Infos über Gruppe und SVN-Kennung Morgen nachmittag / abend 3. Problemfälle besprechen In nächster Vorlesung Dr. G. Kniesel Vorlesung Softwaretechnologie 1-9 R O O T S

10 Übungsblatt 0 Aufgabe: Voraussetzungen zur Übungsteilnahme schaffen Anmeldung zur Tutoriumsgruppe Aktivierung des Altbau Windows Accounts Eclipse-Installation Aktivierung des SVN-Accounts SVN-Zugang testen (Gedicht) Abgabe im ersten Tutorium an Ihren Tutor Dr. G. Kniesel Vorlesung Softwaretechnologie 1-10 R O O T S

11 Prüfungen im Bachelor und nach neuer Informatik-DPO (2003) Modulprüfung Schriftliche Klausur Voraussetzung zur Prüfungsteilnahme Präsenz und Mitarbeit im jeweiligen Tutorium (max. 2 Fehltermine) 50 Prozent der Übungspunkte Zusätzliche Voraussetzung für Bachelor Studierende Vorlesung 015 Objektorientierte Programmierung bestanden! Nebenfächler Was immer Ihre Prüfungsordnung bestimmt Dr. G. Kniesel Vorlesung Softwaretechnologie 1-11 R O O T S

12 Prüfungen nach alter Informatik-DPO (1998) B-Prüfung in Kombination mit anderer 4-stündigen Veranstaltung aus dem B-Bereich Oft gewählt Fächerkombination SWT + IS Mögliche Prüfer: Prof. Dr. R. Manthey + Dr. Kniesel Prof. Dr. R. Manthey + Prof. Dr. A. B. Cremers Prof. Dr. A. B. Cremers (beides) Dr. G. Kniesel Vorlesung Softwaretechnologie 1-12 R O O T S

13 Kapitel 0: Vorlesungsüberblick Ausblick Unmittelbare Nachfolgeveranstaltungen Software Engineering Curriculum im Bachelor und Master R O O T S

14 Unmittelbare Anschluss-Veranstaltungen Projektgruppen Praktische Softwaretechnologie Sommersemester Mobile Applikationen Sommersemester + Wintersemester Teilnahme Bachelorstudiengang Diplomstudiengang Anmeldung Infos demnächst im SE-Wiki: Dr. G. Kniesel Vorlesung Softwaretechnologie 1-15 R O O T S

15 Sommersemester: Projektgruppe Angewandte Softwaretechnologie Praktische Anwendung der in der SWT-Vorlesung behandelten Technologien, Werkzeuge und Entwicklungsprozesse In kleinen Gruppen können eigene Projektideen begleitet bearbeitet werden!!! Vorbesprechung: voraussichtlich letzte Vorlesungswoche des Wintersemesters Voraussetzung: Gute Ergebnisse in der Vorlesung Softwaretechnologie Betreuer: Jan Nonnen Dr. G. Kniesel Vorlesung Softwaretechnologie 1-16 R O O T S

16 Sommer- und Wintersemester: PG Mobile and Social Applications Softwareentwicklung auf iphone-os und Android Mobile ortsbasierte Anwendung, verteilte Kollaboration, soziale Interaktion Vorbesprechung: voraussichtlich letzte Vorlesungswoche des Wintersemesters Voraussetzung: Gute Ergebnisse in der Vorlesung Softwaretechnologie Betreuer: Dr. G. Kniesel Vorlesung Softwaretechnologie 1-17 R O O T S

17 SE-Curriculum im Informatik-Bachelor- Studiengang (S) 6. Semester Bachelor-Arbeit & Bachelor-Seminar (wöchentliche Seminartreffen Evtl. Gruppenarbeit ) Modul BA-INF 061 (W) 5. Semester Projektgruppe 10 Mobile Applications Seminar (2) und Praktikum (3) 2+3 Modul BA-INF 051 (S) 4. Semester Projektgruppen 10 Angewandte SWT und / oder Mobile Applications Seminar (2) und Praktikum (3) 2+3 Modul BA-INF 051 (W) 3. Semester Vorlesung Softwaretechnologie (SWT) Modul BA-INF 033 (S) 2. Semester Vorlesung Objektorientierte Softwareentwicklung (OOSE) Modul BA-INF 024 (W) 1. Semester Vorlesung Algorithmisches Denken und imperative Prog Modul BA-INF Dr. G. Kniesel Vorlesung Softwaretechnologie 1-18 R O O T S

18 Winter Sommer Mögliche Gesamt-Studienverläufe Bachelor Master Computer Science 4+2 OOSE 2+3 PG Angew. SWT. Mobile Applications Bachelor-Arbeit & Bachelor-Seminar 2+2 AOSD 2+2 ALP 2+2 MDSE Master-Arbeit, -Seminar, -Kolloquium 4+2 ADIP 4+2 SWT 2 PG Mobile Applications 2+2 ATSC 2+2 UCSD 2 Seminar Agile 2 Seminar MDSE 4 Lab Agile 4 Lab MDSE Topic Lecture Seminar Lab MDSE = Model Driven Software Engineering ALP = Advanced Logic Programming 3207 Agile = Agile Software Development UCSD = User Centered Software Design 3217 ATSC = Advanced Topics in Software Construction Dr. G. Kniesel Vorlesung Softwaretechnologie 1-19 R O O T S

19 Vorlesung Softwaretechnologie Wintersemester 2011/12 R O O T S Kapitel 1 Software Engineering Eine Einführung Stand:

20 Ziele des Kapitels Erklärung der Bedeutung von Software Engineering Erläuterung der Hauptprobleme von SE Motivation der Verwendung objektorientierter Techniken Definition der grundlegenden Konzepte von SE Exkurse Software-Qualitäten Software Engineering Prinzipien Dr. G. Kniesel Vorlesung Softwaretechnologie 1-21 R O O T S

21 Bedeutung von Software Engineering Software ist allgegenwärtig Immer mehr Systeme werden durch Software kontrolliert Software ist ein wirtschaftlicher Schlüsselfaktor Die Volkswirtschaft aller Industrieländer ist von Software abhängig Die Ausgaben für Software haben einen beträchtlichen Anteil am Bruttosozialprodukt aller Industrieländer Software Engineering befasst sich mit Theorien Prozessen Methoden Werkzeugen zur professionellen Softwareentwicklung Dr. G. Kniesel Vorlesung Softwaretechnologie 1-22 R O O T S

22 Ziele: Software-Kosten und Softwarequalität Softwarekosten übersteigen oft Systemkosten Beispiel: PC Der Softwarewartung kostet mehr als die Entwicklung Bis zu 80% der Gesamtkosten Schlechte Software schadet mehr als sie nutzt Unzufriedene Benutzer Direkte Schäden Software Engineering befasst sich mit kosteneffektiver Software-Entwicklung qualitativ hochwertiger Software Dr. G. Kniesel Vorlesung Softwaretechnologie 1-23 R O O T S

23 Einige Beispiele: Qualität und Kosten Jahr Bug Im Jahre 1992 erhielt Mary eine Einladung einen Kindergarten zu besuchen im Alter von 104 Jahren! Fehlverhalten Automatisiertes Gepäcksystem am Flughafen von Denver beschädigte Koffer 3,2 Mio. $ über dem Budget, 16 Monate verspäteter Start mit zum größten Teil manuellem System Unnötig komplexe Lösung Das C-17 Transportflugzeug nutzt 19 Onboard-Computer, 80 Mikroprozessoren und 6 Programmiersprachen Es war 500 Mio $ über dem Budget Interface-Missbrauch Wissend, dass es ein System gab, das die Abfahrt des Zuges mit offenen Türen verhinderte, fixierte ein Zugführer den Startknopf mit Klebeband in Startstellung. Als er den Zug verließ um eine klemmende Tür zu schließen, fuhr der Zug ohne ihn los als die Tür nicht mehr klemmte. Er fand dies eine besonders clevere Art sicherzustellen, dass der Zug sofort losfuhr sobald die letzte Tür geschlossen war Dr. G. Kniesel Vorlesung Softwaretechnologie 1-24 R O O T S

24 Hauptherausforderungen von SE: Komplexität und Änderung Komplexität von Softwaresystemen Viele Funktionen Viele, möglicherweise kollidierende Ziele Viele Komponenten Komplexität der Zusammenstellung Viele Teilnehmer Komplexität der Kommunikation Keine Einzelperson kann ein ganzes System verstehen Dauernde Änderung von Softwaresystemen Software modelliert einen Ausschnitt der realen Welt Die reale Welt ändert sich (Gesetzgebung, Geschäftsabläufe,...) Der Ausschnitt ändert sich (mehr Funktionalität hinzufügen, Systeme integrieren,...) Die Implementierungstechnologie ändert sich (neue Sprachen, Komponenten,...) Das Team ändert sich (Personen gehen, neue kommen hinzu,...) Das Management wechselt (neue Geschäftsausrichtung,...) Alles kann sich jederzeit ändern! Dr. G. Kniesel Vorlesung Softwaretechnologie 1-25 R O O T S

25 Charakteristiken von anderen Ingenieurswissenschaften Domäne Klar definierte Probleme Ein Produkt muss gebaut werden Hohe Qualitätsanforderungen Methoden Systematische Verfahren und ihre disziplinierte Anwendung Standardschnittstellen, - komponenten und -prozesse Wissen um bereits verfügbare Teilkomponenten und gezielter Einsatz fertiger (Teil-) Lösungen Empirische Methoden zur Bewertung von Lösungen Dr. G. Kniesel Vorlesung Softwaretechnologie 1-26 R O O T S

26 Software Engineering ist anders Andere Ingenieursbereiche Herstellung bestimmt die Endkosten Änderungen sind weniger häufig 2000 Jahre von der Euklidischen zur nicht- Euklidischen Geometrie Änderungen sind möglich, aber sehr teuer Redesign wird gründlich durchdacht Auswirkungen werden genau analysiert Software Engineering Herstellung ist eine einfache Duplizierung Änderungen geschehen dauernd Manchmal innerhalb von Stunden (Kunde hat seine Meinung geändert) Änderungen sind einfach Kein durchdachtes Redesign Auswirkungen werden nicht ausreichend bedacht Andauernde Änderungswünsche zusammen mit der Leichtigkeit, Änderungen durchzuführen, führen zu ungenügend überdachten, adhoc Lösungen Dr. G. Kniesel Vorlesung Softwaretechnologie 1-27 R O O T S

27 Vorlesung Softwaretechnologie Wintersemester 2011/12 R O O T S Was ist Software-Engineering?

28 Was ist Software Engineering Modellierung Modellierung ist das wichtigste Mittel um mit Komplexität umzugehen Problemlösung Suche nach akzeptablen Lösungen erfordert experimentellen Vergleich von Modellen Wissensakquisition Modellierung erfordert das Sammeln von Daten, deren Organisation und Formalisierung Rationale Management Dokumentation der Überlegungen / Gründe für Entscheidungen erleichtert Verständnis der Auswirkungen von späteren Änderungen Dr. G. Kniesel Vorlesung Softwaretechnologie 1-30 R O O T S

29 Modellierung (1) Software Engineering... hilft die Welt zu verstehen Modelle nicht mehr existenter Systeme: Modell der Dinosaurier, basierend auf Knochen, Zähnen und den Regeln der Anatomie Modelle von Systemen die angeblich existieren: Modell von Materie und Energie basierend auf Experimenten mit Teilchenbeschleunigern Modelle realer Systeme: Software basierend auf Betrachtung der Anwendungsdomäne und Benutzer Participatory design (Beteiligungsorientiertes Design) als Weg, die relevanten Aspekte der Anwendungsdomäne zu verstehen... möglichst einfache aber ausreichend genaue Darstellung des Systems wichtigstes Mittel mit Komplexität umzugehen Abstraktion hilft den Blick auf die relevanten Aspekte zu richten... ist ein Hauptgrund für Änderungen Je abstrakter desto mehr implizite Annahmen liegen dem System zugrunde. Je mehr Annahmen desto mehr Potential für Änderungen Dr. G. Kniesel Vorlesung Softwaretechnologie 1-31 R O O T S

30 Was wir modellieren Modellierung der Anwendungsdomäne Problemorientierte Sicht Modellierung des Systems Lösungsorientierte Sicht Vergleich verschiedener Lösungen verlangt die Modellierung verschiedener alternativer Systeme Objektorientierte Modellierung Problem domain object model Objekte Beziehungen Solution domain object model Objekte Beziehungen Interaktionen Vorteile der OO Modellierung Erstellung der beiden Modelle mit gleichen Mitteln möglich Modell der Lösung ist eine Erweiterung des Problem- Modells Nachvollziehbarkeit ( Traceability ) Dr. G. Kniesel Vorlesung Softwaretechnologie 1-32 R O O T S

31 Modellierung in dieser Vorlesung Objektorientierte Konzepte Technische Grundlagen Die Unified Modelling Language (UML) Standardisierte graphische Notation für OO Modelle Objektorientierte Modellierung Anwendungs-Prinzipien Entwurfsmuster (Design Patterns) Typische gute Entwurfs-Lösungen Refactoring Verletzung von Designprinzipien erkennen ( Bad smells ) Entsprechende verhaltenserhaltende Restrukturierung ( Refactoring ) Dr. G. Kniesel Vorlesung Softwaretechnologie 1-33 R O O T S

32 Problemlösung Software Engineering Begrenzte Ressourcen und unvollständiges Wissen erfordern... den Vergleich verschiedener Lösungen/Modelle... empirische Bestimmung von Alternativen Techniken um Angemessenheit von Modellen zu bewerten Benutzerzentrierter Entwurf (Participatory Design) Den Benutzer permanent in das Projekt einbinden und die Entwicklung leiten lassen Analyse-Überprüfung (Analysis Review) Vergleiche Modell des Anwendungsbereichs mit Realität aus Sicht des Benutzers Entwurfs-Überprüfung (Design Review) Vergleich des Lösungsmodells (solution domain model) mit Projektzielen Implementierungs-Überprüfung (Code Review) und Testen System wird auf Basis des Lösungsmodells (solution domain model) validiert Projektmanagement Vergleiche Prozessmodell (Zeitplan, Budget,...) mit der Realität des Projektes Dr. G. Kniesel Vorlesung Softwaretechnologie 1-34 R O O T S

33 Problemlösung in dieser Vorlesung Participatory design Den Benutzer permanent in das Projekt einbinden und die Entwicklung leiten lassen Extreme Programming: Benutzer / Kunde als Teil des Teams Analysis-, Design-, Code-Review Extreme Programming: permanenter Review-Prozess durch Pair Programming Projektmanagement Vergleiche Prozessmodell (Zeitplan, Budget,...) mit der Realität des Projektes Dr. G. Kniesel Vorlesung Softwaretechnologie 1-35 R O O T S

34 Wissensakquisition Software Engineering Wissensakquisition ist nicht linear Das Hinzukommen einer neuen Information kann alles vorher erworbene Wissen unbrauchbar machen Hohes Fehlerrisiko Risk-based development (Risikoorientierte Softwareentwicklung)... zielt darauf ab, mit hohem Risiko behaftete Komponenten und Aktivitäten zu erkennen.... plant sie frühzeitig im Projekt ein Issue-based development (Problemorientierte Softwareentwicklung)... erkennt an, dass jede Aktivität jede andere beeinflusst Analyse Systemdesign, Objektdesign Implementierung, Testen Auslieferung... ersetzt lineare durch parallele Ausführung von Aktivitäten... erleichtert es, auf Änderungen zu reagieren... ist leider schwieriger zu koordinieren

35 Wissensaquisition in dieser Vorlesung Prozessmodelle Risk-based development Issue-based development Extreme Programming und Agile Prozesse Verbindung beider Ansätze Es geht um den Umgang mit Änderungen! Das neue Wissen von heute kann die gute Entscheidung von gestern hinfällig werden lassen. die gestern verworfene Alternative neu ins Spiel bringen Dr. G. Kniesel Vorlesung Softwaretechnologie 1-37 R O O T S

36 Rationale Management Rationale (engl.) = Begründung, Erklärung, Motivation Rationale Management = Erfassung von Problemen Lösungsalternativen Argumenten für und Wider der Alternativen getroffene Entscheidung Begründung für die Entscheidung Dr. G. Kniesel Vorlesung Softwaretechnologie 1-38 R O O T S

37 Rationale Management : Sinn und Zweck Software Engineering Statische Problem- und Lösungs-Domänen Mathematikbücher sind voller Beweise. Nie aber ist festgehalten, warum ein Beweis gerade so und nicht anders geführt wurde. Das ist nicht weiter schlimm, da sich die zugrundeliegenden Modelle sehr selten ändern 2000 Jahre von euklidischer zu nicht-euklidischer Geometrie 1500 Jahre von geozentrischem zu heliozentrischem Weltmodell Dynamische Problem- und Lösungs-Domänen Rationale Management Dokumentation der Gründe für Architektur und Entwurfsentscheidungen wichtig Sie ermöglicht die Auswirkung späterer Änderungen dieser Entscheidungen nachzuvollziehen Sie reduziert den Änderungsaufwand und die Gefahr von Fehlentscheidungen Dr. G. Kniesel Vorlesung Softwaretechnologie 1-39 R O O T S

38 Rationale Management: Problem Software Engineering Dokumentation von Alternativen Aktuelles Lösungsmodell beinhaltet nur die gewählte Alternative Betrachtet wurden aber evtl. N andere Möglichkeiten Rationale Management muss also N andere Alternativen mit erfassen Dokumentation der Gründe gegen jede verworfene Alternative Wichtigste Entscheidungshilfe bei Änderung: Ist etwa eine der vorherigen Annahmen ungültig geworden und somit auch die Schlussfolgerung die damals gezogen wurde? Dokumentation der getroffenen Entscheidung Zusammen mit benutzten Bewertungskriterien Dokumentation impliziter Entscheidungen Entscheidung aus Erfahrung oder Intuition, ohne explizit Alternativen zu betrachten Nachträgliches Explizitmachen sehr aufwendig Rationale Management erfordert enormen Zusatzaufwand Dr. G. Kniesel Vorlesung Softwaretechnologie 1-40 R O O T S