Informatik für Ingenieure (InfIng)

Transkript

1 Informatik für Ingenieure (InfIng) SW-Engineering 1 Doz. Dipl.-Ing. H. Hiller WS 2012/13

2 Software und ihre Fehler 1965 Beginn der so genannten "Softwarekrise" Kosten für die Software übersteigen erstmals die Kosten für die Hardware Weitere Entwicklung führt zu den ersten großen gescheiterten Software-Projekten 1982 Absturz eines Prototypen des F117 Kampfjets SW-Fehler vertauscht Steuerung des Höhenruders mit der des Seitenruders 1995 Verzögerungen im bundesweiten Zugverkehr Umstellung des Hamburger Stellwerks auf ein elektronisches Stellwerksystem Zu kleiner Stapelspeicher: 3,5 statt 4 kb (500 Byte mehr aus "Sicherheitsgründen") 1996 Selbstzerstörung der Ariane-5-Rakete Programmcode für die Steuerung war von Ariane 4 übernommen worden Code funktionierte nur in einem von der Ariane 4 nicht überschreitbaren Bereich 2005 Verlust des NASA Mars Climate Orbiters Angesteuerte Umlaufbahn 170 km tiefer als geplant, Folge: Absturz oder Abprall 2 Gruppen am Projekt beteiligt: eine rechnete in Meter, die andere in Inch und Fuß FH D Seite 2 FB 5

3 Software und ihre Fehler 2007 Server-Ausfall der Telekom Fehlerhaftes Update (Software Aktualisierung) eines Düsseldorfer Servers FH D Seite 3 FB 5

4 Chaos-Report Überblick über Probleme bei der Software-Entwicklung Durchgeführt von der Standish Group 1. Chaos-Report 1994, erscheint etwa im 2-Jahres-Rhythmus, zuletzt 2008 Chaos-Report von 1994 Untersucht wurden 8380 Projekte in 365 amerikanischen Firmen Geschätzter Gesamtaufwand von $ 250 Milliarden, verteilt auf Projekte Ergebnis 31% der Projekte noch vor der Fertigstellung komplett abgebrochen Verlust: $ 80 Milliarden Indirekter Verlust aus dem Fehlen der Software nicht eingerechnet 53% der Projekte wurden mit erheblichen Mängeln fertig gestellt Lediglich 61% der ursprünglichen Anforderungen wurden erfüllt Verdoppelung der Projektdauer und der damit kalkulierten Kosten 16% der Projekte wurden ohne Mängel fertig gestellt Aktuelle Entwicklung Einerseits Zweifel am Report, andererseits für viele Projektmanager plausibel FH D Seite 4 FB 5

5 Chaos-Report Chaos-Report von 1994 bis 2004 FH D Seite 5 FB 5

6 Themen dieser Vorlesung Wir wollen folgender Frage nachgehen: "Wie kann Software besser, d.h. effektiver entwickelt werden?" Softwaretechnik FH D Seite 6 FB 5

7 Softwaretechnik Softwaretechnik ist Herstellung bzw. Entwicklung von Software Beginnt bei der Identifizierung des Bedarfs und reicht bis zur Inbetriebnahme und darüber hinaus (z.b. Wartung) Schrittweise Fertigstellung von Software Komplexe Software erfordert hohen Aufwand für Erstellung und Wartung Unterteilung des Entwicklungsprozesses in Phasen Phasen sind überschaubar, weil zeitlich und inhaltlich begrenzt Software wird somit Schritt für Schritt fertig gestellt Ingenieurmäßige Entwicklung Anwendung von Prinzipien, Methoden, Konzepten, Notationen und Werkzeugen Arbeitsteilige Vorgehensweise bei der Realisierung umfangreicher SW-Systeme Ziel der Softwaretechnik Erstellung qualitativ hochwertiger Programme Einhaltung eines vertretbaren Kosten- und Zeitrahmens FH D Seite 7 FB 5

8 Übersicht Grundmodell Versionsverwaltung UML FH D Seite 8 FB 5

9 Grundmodell Typische Prozesse im Rahmen der Softwaretechnik Planung Das Grundmodell umfasst 5 Phasen. Analyse Entwurf Es bildet die Basis der meisten in der Praxis angewandten Phasenmodelle. Implementierung Test Wir werden in dieser Vorlesung einige der wesentlichen Aspekte kennen lernen. FH D Seite 9 FB 5

10 Planungsphase Lastenheft Auch: Anforderungskatalog, Kundenspezifikation, Requirement Specification Gesamtheit aller Forderungen Erstellung durch den Auftraggeber Auftraggeber Externe Auftraggeber Firmen, Behörden, Institutionen, etc. Lastenheft kann Basis einer Ausschreibung sein Erstellung ggf. durch Dritte, z.b. Unternehmensberatung Interne Auftraggeber Inhalt Marketing, Produktmanagement Allgemeine Beschreibung, was und wofür etwas gemacht werden soll Formulierung so allgemein wie möglich und so einschränkend wie nötig Keine Einschränkung der Auftragnehmers in seiner Lösungskompetenz FH D Seite 10 FB 5

11 Planungsphase Beispiel Deutsche Bahn bietet Erstellung eines Lastenhefts als Dienstleistung an Quelle: FH D Seite 11 FB 5

12 Planungsphase Pflichtenheft Auch: Implementierungsspezifikation, Feature Specification Antwort des Auftragnehmers auf die Anforderungen des Lastenhefts Konkrete Beschreibung eines Lösungsvorschlags (ggf. mehrere) Bestätigung durch den Auftraggeber, Start der Entwicklungsarbeiten Auftragnehmer Externe Auftragnehmer Ingenieurbüro, Software-Firma Interne Auftragnehmer Inhalt Entwicklungsabteilung Pflichtenheft beschreibt, wie und womit etwas realisiert werden soll Kosten und Termine Ermittelt durch Aufwandsschätzung (äußerst schwierig und vielfach ungenau) Schätzverfahren: Analogie-Methode, Experten-Methode, Price-to-Win, etc. Grundlage für Angebot bzw. Entscheidung FH D Seite 12 FB 5

13 Planungsphase Zusammenhang von Lastenheft und Pflichtenheft Lastenheft Kunde Pflichtenheft Unternehmen Lastenheft - Anforderungen an die geplante Software - "was und wofür" Pflichtenheft - Konkrete Lösungsvorschläge - "wie und womit" Anforderungen 1 1..n Leistungen FH D Seite 13 FB 5

14 Analysephase Analyse Genaue Untersuchung des Problems Umsetzung der Benutzeranforderungen in Spezifikationen Ergebnis Detaillierte Spezifikation des Ziels Analysemodell als Abstraktion des realen Problems Schwierigkeit Abstraktion des realen Problems in einem komplexen Umfeld Beispiel: OOP Analyse Identifikation der benötigten Objekte (Attribute, Methoden, Vererbung etc.) Interaktionen zwischen den einzelnen Objekten Notation: UML (grafische Notation für objekt-orientierte Analyse und Design) FH D Seite 14 FB 5

15 Entwurfsphase Entwurf Erstellen einer softwaretechnischen Lösung aus den Anforderungen an ein Software-Produkt im Sinne einer Software-Architektur Software-Architektur Beschreibung der Gesamtstruktur des Systems Struktur ( Komponentisierung ) eines Software-Systems Kommunikation zwischen den Komponenten Abbildung auf Hardware- oder Software-Ressourcen Architektur gültig über den gesamten Lebenszyklus eines Software-Systems Design-Entscheidung Kritischster Punkte im Entwicklungsprozess einer Software Software-Architektur ist später nur mit hohem Aufwand änderbar Definiert über Softwarequalitätskriterien (nicht-funktionale Eigenschaften) U.a. Modifizierbarkeit, Wartbarkeit, Sicherheit oder Performance Unabhängig von der Implementierungssprache ( so der Anspruch) FH D Seite 15 FB 5

16 Entwurfsphase Strukturen und Abstraktionen Gliedern der Lösung in Komponenten und Interaktionen Gewinnen von Übersicht; Weglassen der Details Modularität Definierter und klar abgegrenzter Teil eines Systems In sich geschlossene Einheit, ohne Kenntnis des inneren Aufbau verwendbar Geheimnisprinzip Außerhalb der Komponente ist nur bekannt, was die Komponente leistet Nutzung von Vorhandenem Nicht neu entwickeln, sondern wiederverwenden oder ggf. beschaffen Standardsoftware, konfigurierbare Bausteine, etc. Qualität Software löst vorrangig das Problem des Auftraggebers (!!!) Kostengünstig, verständlich, robust und änderungsfreundlich FH D Seite 16 FB 5

17 Entwurfsphase Schichtenmodell Auch: Ebene, Tier (engl.) oder Layer (engl.) Komponenten werden auf Schichten verteilt Schichten sind semantisch zusammenhängend Kommunikation Innerhalb einer Schicht beliebig Außerhalb nur zwischen benachbarten Schichten Schicht 3 Schicht 2 Schicht 1 Client-Server-Architektur Muster für verteilte Systeme Verbindung nur zwischen Server und Client Prinzip: Client fordert Dienst des Servers an Client Server FH D Seite 17 FB 5

18 Entwurfsphase Architektur-Beispiel 1: OSI-Referenzmodell Designgrundlage von Kommunikationsprotokollen System A Transitsystem System B Application Application Presentation Presentation Session Session Transport Transport Network Network Network Network Data Link Data Link Data Link Data Link Physical Physical Physical Physical FH D Seite 18 FB 5

19 Entwurfsphase Architektur-Beispiel 2: Linux User Applications GNU C Library (glibc) User Space GNU / Linux System Call Interface Kernel User Space Architecture-Dependent Kernel Code Hardware Platform FH D Seite 19 FB 5

20 Entwurfsphase Architektur-Beispiel 3: Softphone About CounterPath CounterPath builds innovative SIPbased softphones, server applications and Fixed Mobile Convergence (FMC) solutions for service providers, enterprises, OEMs and end users. Quelle: FH D Seite 20 FB 5

21 Implementierungsphase Programmiersprache Funktional, prozedural oder objektorientiert Vorgabe durch den Auftraggeber, Legacy-System Human Factor Programmiersprachen-Kenntnisse Schulungsmaßnahmen Entwicklungsumgebung Compiler, Debugger, IDE,... Programmiertechnik Extreme Programming (XP) Agile Methode der SW-Entwicklung Frühzeitige Konzentration auf wesentliche Elemente der Softwareentwicklung Codieren, testen und kommunizieren statt dokumentieren Pair Programming Paarweises Programmieren, 4 Augen sehen mehr als 2 Zwei Mitarbeiter an einem Rechner (eine Tastatur, eine Maus und ein Monitor) Abwechselnd - einer tippt, der andere schaut über die Schulter FH D Seite 21 FB 5

22 Testphase Test-Strategie & Ziel Mit vertretbarem Aufwand möglichst viele Fehler in einem Programm finden Kosten Testkosten Fehlerfolgekosten Testumfang Ein Test liefert den Nachweis, dass bestimmte Funktionen funktionieren, aber nicht, dass keine Fehler vorhanden sind!!! FH D Seite 22 FB 5

23 Testphase Manuelle Tests Black Box Test Funktionsorientiert Auswahl der Testfälle auf Basis der Spezifikation Testfälle unabhängig von der Programmstruktur und der Implementierung Ziel: Vollständige Abdeckung aller geforderten Eigenschaften White Box Test Strukturorientiert Auswahl der Testfälle auf Basis der Programmstruktur Möglichst vollständige Code-Abdeckung (Durchlauf aller Anweisungen) Automatisierte Tests Regressions Test Test nach Modifikation, z.b. Fehlerbehebung etc. Ziel: Überprüfung des fehlerfreien Erhalts der bisherigen Funktionalität Last-Test System wird an die Grenzen der Leistungsfähigkeit geführt (CPU, Speicher, etc.) Ziel: Überprüfen des Systemverhaltens unter Randbedingungen FH D Seite 23 FB 5

24 Testphase Modultest Test auf der Ebene der einzelnen Module der Software Testgegenstand ist die Funktionalität einzelner, abgrenzbarer Teile der Software Module, Programme oder Unterprogramme, Units oder Klassen Durchführung durch den Softwareentwickler selbst Nachweis der technischen Lauffähigkeit und korrekter fachlicher (Teil-) Ergebnisse Integrationstest Testet die Zusammenarbeit voneinander abhängigen Komponenten Testschwerpunkt liegt auf den Schnittstellen der beteiligten Komponenten Systemtest Test des Systems gegen die gesamten Anforderungen Funktionale und nicht funktionale Anforderungen Durchführung in einer Testumgebung mit Testdaten Testumgebung soll Produktivumgebung des Kunden simulieren FH D Seite 24 FB 5

26 Versionsverwaltung Branches Festlegung eines bestimmten Teilpfads einer Software-Version Erreichen eines Release-Zustands (z.b. durch Feature-Stop) Branches sind abgekoppelt von der laufenden Entwicklung Main Branch Nur wichtige Änderungen, zumeist Bugfixes, fließen in einen Branch I.d.R. solange verfügbar wie das Release beim Kunden im Einsatz ist Hauptpfad einer Software-Version Erweiterungen (Neu-Entwicklungen) und Fehlerbehebungen (Bugfixes) Release 2 Branch 2 Entwicklungsversion Main Branch Release 1 Branch 1 Release 1.1 Branch 3 FH D Seite 26 FB 5

27 Versionsverwaltung Repository (engl. für Lager/Depot) Speicherung von digitalen Objekten, z.b. Quellcode, Dokumentation Ablage mehrere unterschiedlicher Versionen (Releases) einer Software Verfügbarkeit vorangegangener Versionen Fehlerbehebung in einem ausgelieferten System (Kunden-Release) Alte Versionen müssen bei Bedarf wieder hergestellt werden Gemeinsames Arbeiten an Programm-Modulen Mehrere Mitarbeiter arbeiten an den gleichen Dateien (Quellcode-Files) Siehe hierzu die nächsten 3 Folien FH D Seite 27 FB 5

28 Gemeinsames Arbeiten an Programm-Modulen Sequentiell 1. Anke kopiert Datei aus Repository (check-out) Arbeitsbereich Anke Repository Arbeitsbereich Kai 2. Anke bearbeitet Datei in ihrem Arbeitsbereich 3. Anke überträgt geänderte Datei in Repository (check-in) A B C 1. check-out A B C V1 4. Kai kopiert die von Anke bearbeitete Datei aus Repository (check-out) 5. Kai bearbeitet Datei in seinem Arbeitsbereich A X C 2. Änderung 3. check-in A B X C V2 4. check-out A X C 6. Kai überträgt geänderte Datei in Repository (check-in) A X C Y V3 6. check-in 5. Änderung A X Y FH D Seite 28 FB 5

29 Gemeinsames Arbeiten an Programm-Modulen Parallel (1) 1. Anke kopiert Datei aus Repository (copy) Arbeitsbereich Anke Repository Arbeitsbereich Kai 2. Kai kopiert Datei aus Repository (copy) 3. Anke bearbeitet Datei in ihrem Arbeitsbereich A B C 1. copy A B C V1 2. copy A B C 4. Kai bearbeitet Datei in seinem Arbeitsbereich 5. Anke überträgt geänderte Datei in Repository (copy) 6. Kai überträgt geänderte Datei in Repository (copy) A X C 3. Änderung 5. copy A B X C V2 4. Änderung A B Y!!! FEHLER!!! In Schritt 6 überschreibt Kai die Änderungen von Anke! A X B C Y V3 6. copy FH D Seite 29 FB 5

30 Gemeinsames Arbeiten an Programm-Modulen Parallel (2) oder: Wie es besser funktioniert! 1. Anke kopiert Datei aus Repository (copy) Arbeitsbereich Anke Repository Arbeitsbereich Kai 2. Kai kopiert Datei aus Repository (copy) 3. Anke bearbeitet Datei in ihrem Arbeitsbereich 4. Kai bearbeitet Datei in seinem Arbeitsbereich 5. Anke überträgt nur geänderte Zeilen in Repository (merge) 6. Kai überträgt nur geänderte Zeilen in Repository (merge) A B C A X C 3. Änderung 1. copy 5. merge X A B C A B X C V1 V2 2. copy 4. Änderung A B C A B Y!!! OK!!! Nur Änderungen werden übertragen! A X C Y V3 6. merge Y FH D Seite 30 FB 5

32 UML UML - Unified Modeling Language Sprache zur Beschreibung & Modellierung von Softwaresystemen Werkzeug u.a. für Systemanalyse und Systemdesign Seit 1995, Version 2.0 ist aktuell, de facto Standard Grundgedanke Einheitliche Notation für alle Softwaresysteme (!!!) UML entstand aus mehreren bestehenden Notationen Eigenschaften Grafische, objektorientierte Modellierungssprache Unabhängig von Entwicklungsprozessen und methoden Kommunikationsmittel zwischen Entwickler und Benutzer Tool-Unterstützung StarUML, ArgoUML oder Eclipse UML2 Tools (alle Open Source) FH D Seite 32 FB 5

33 UML Diagramme Verschiedene Diagrammtypen Strukturdiagramme und Verhaltensdiagramme Darstellung verschiedener Sichtweisen Gegenseitige Ergänzung Hervorhebung verschiedener Systemaspekte Vergleich: Bauplan für ein Haus Verschiedene Ansichten Grundriss und Aussenansichten Werkpläne für verschiedene Handwerker Mit Hilfe von UML können große Teile der Analyse und des Designs von Software in standardisierter Form beschrieben werden. FH D Seite 33 FB 5

34 UML Diagramme Diagrammtypen UML 2 kennt insgesamt 14 Diagramme Strukturdiagramme (7) : Beschreiben die statischen Aspekte von Objekten Verhaltensdiagramme (7) : Beschreiben die Dynamik zwischen den Objekten Strukturdiagramme Klassendiagramm Kompositionsdiagramm Komponentendiagramm Verteilungsdiagramm Objektdiagramm Paketdiagramm Profildiagramm Verhaltensdiagramme Anwendungsfalldiagramm Aktivitätsdiagramm Sequenzdiagramm Kommunikationsdiagramm Interaktionsübersichtsdiagramm Zeitverlaufsdiagramm Zustandsdiagramm FH D Seite 34 FB 5

35 Anwendungsfalldiagramm Anwendungsfalldiagramm Zusammenwirken von Akteuren mit einem System Verbale Beschreibung der abgebildeten Tätigkeiten Elemente Akteur Benutzer-Rolle bei Interaktion mit dem System Symbolisiert durch ein Strichmännchen System Software mit der geforderten Funktionalität Symbolisiert durch ein Rechteck Use Case Anwendungsfall eines Systems nach außen hin Symbolisiert durch eine Ellipse Assoziation Verbindungslinie zwischen Akteur und Use Case Symbolisiert durch eine einfache Linie System Use Case FH D Seite 35 FB 5

36 Anwendungsfalldiagramm Beispiel: Bank Kunde soll Konto eröffnen können und Geld überweisen Bank Betrag überweisen Kunde Konto eröffnen Berater FH D Seite 36 FB 5

37 Klassendiagramm Klassendiagramm Beschreibt den logischen Aufbau des Systems Sichtweise ist statischer Natur Klassen Symbolisiert durch ein Rechteck Unterteilung in drei Bereiche Oben : Name Mitte : Eigenschaften Unten : Methoden Sichtbarkeit Minuszeichen "-" : privates Klassenmerkmal Pluszeichen "+" : öffentliches Klassenmerkmal Definition von Eigenschaften Name u. Datentyp getrennt durch Doppelpunkt Definition von Methoden Name u. Datentyp des Rückgabewertes Getrennt durch einen Doppelpunkt Kunde - Name : String - KtoNr : int - nameaendern - KtoNrAendern Girokonto - Kontostand - Zinssatz + auszahlen() + einzahlen() FH D Seite 37 FB 5

38 Klassendiagramm Assoziation Semantische Beziehung zwischen zwei oder mehreren Objekten Lieferant Kunde Symbolisiert durch eine Verbindungslinie Ohne Pfeil: ungerichtete Assoziation Beziehung ist in beiden Richtungen navigierbar Mit Pfeil: gerichtete Assoziation Firma schickt Werbung Person Pfeilrichtung gibt Zugriffsrichtung an Bsp: Firma schickt Werbung an Person Kardinalitäten Aussage über die Anzahl der Objekte eines Typs, die in Beziehung stehen können Symbolisiert durch Auflistung der Anzahl, z.b. Tochter 1..n 1 Vater 1 : genau ein Objekt 0..* : null bis beliebig viele Objekte 2..n : mindestens zwei, maximal n Objekte Bsp.: Ein Kunde kann 1 bis n Konten haben Tochter 1 1..n Unsinn Vater FH D Seite 38 FB 5

39 Klassendiagramm Aggregation Aggregation ist Sonderform der Assoziation Beschreibung der Zusammensetzung eines Objekts (Aggregats) aus mehreren Einzelteilen Symbolisiert durch eine offene Raute Bsp.: Kapitän gehört zu einer Crew, kann aber auch ohne Crew existieren Komposition Komposition ist verstärkte Form der Aggregation Einzelteile sind existenzabhängig und können ohne das Aggregat nicht existieren Symbolisiert durch eine gefüllte Raute Bsp.: Ein Haus besteht aus mehreren Zimmern, ein Zimmer ohne Haus kann nicht existieren Vererbung Hierarchische Strukturierung von Klassen Ganzes Crew Ganzes Haus Fähre Teil Kapitän Teil Zimmer Boot FH D Seite 39 FB 5

40 Klassendiagramm Beispiel: Bank Kunde hat verschiedene Konten bei einer Bank Bank verwendet Konto 1 1..n Konto hat Bank Giro-Konto Spar-Konto Kunde Buchungsposten nur existent, wenn es ein Girokonto gibt. besteht aus 1 0..* Buchungsposten FH D Seite 40 FB 5

41 Sequenzdiagramm Sequenzdiagramm Zeitlicher Verlauf des Nachrichtenaustauschs zwischen Objekten :Objekt A :Objekt B Lebenslinie Zeitabschnitt, in dem das Objekt existiert. Aktivierung Bereich, in dem eine Methode des Objekts aktiv ist, bzw. ausgeführt wird. Nachricht 1 Antwort 1 Nachricht 2 Antwort 2 Objekt, Name des Objekts, dargestellt durch einen Unterstrich. Nachrichten Methodenaufruf und Rücksprung. FH D Seite 41 FB 5

42 Sequenzdiagramm Beispiel: Bank Kunde eröffnet ein Konto bei der Bank und "testet" den Geldautomaten ;-) :Kunde :Berater : Geldautomat eröffnekonto() zeigeausweis() return() unterschreiben() return() return() auszahlen() new() return() :Konto return() FH D Seite 42 FB 5

43 Softwaretechnik pragmatisch "gedacht" FH D Seite 43 FB 5