Wasserfallmodel Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University.

Präsentation zum Thema: "Wasserfallmodel Fachgebiet Software Engineering Übersicht © 27.03.2017 Albert Zündorf, Kassel University."—  Präsentation transkript:

1 Wasserfallmodel Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

2 Machbarkeitsstudie Auswählen des Produktes
Voruntersuchung des Produkts Durchführbarkeitsuntersuchung Prüfen der ökonomischen Durchführbarkeit Ergebnis: „Stop or go“ Entscheidung Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

3 Anforderungsdefinition
Konzepterarbeitung mit Laien / Kunden Verständliche Szenarios Klärung der Funktionalität Nichtfunktionale Anforderungen Anforderungsdokumentation Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

4 Analyse Grob-Entwurf in der „Problem-Domain“
Erfassen der Domain (Business-Model) Konzeption neuer (komplexer) Funktionalität Konzeption von (Architektur) Umbauten Architekturkonzepte Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

5 Design Fein-Entwurf in der „Solution-Domain“
Arbeitsvorlage für den Entwickler Konzeption neuer (komplexer) Funktionalität Konzeption von (Architektur) Umbauten Architekturkonzepte Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

6 Implementierung hier wird „gehackt“
Entwickler orientieren sich am Design-Dokument Tests Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

7 Wartung Auslieferung Pflege vor Ort Bugfixing
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

8 Probleme mit dem Wasserfall
Alle Anforderungen zuerst ersten Phasen werden teuer Kunde bekommt nicht das, was er will Probleme werden spät entdeckt  Phasen werden Arbeitsschritte iterativer Durchlauf prototypisch usecase / scenario – driven Test-first Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

9 Kostenschätzung Resultat aus Gruppendiskussion Pi mal Daumen
Ergebnis: ca. ein Semester Modul und Phasen-basiert Schätzgrößen LOC, Seiten  Zeit Einzelschätzungen + Gesamtsumme Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

10 Abgaben Abgaben per CVS setzen der Tags gemäß Aufgabenstellung v3
vor der Deadline in eclipse: Rechtsklick  Team  Tag as Version Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

11 Organisatorische Hinweise
Im OKA anmelden - bis Anfang Dezember, Veranstaltung „Softwaretechnik“ Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

12 Testen - Motivation Testen ist Ausprobieren? GUI ‚durchklicken‘
System.out.println(…) Wer hat das kaputt gemacht? don't touch it if it works! Je nach „Qualität“ geht bis zu 50% der Arbeitszeit Debugging und Fehlersuche Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

13 Unit Tests Testen eine ‚Einheit‘: Klasse Modul Komponente
Werden programmiert Prüfen den Funktionsumfang Rufen nur die öffentliche Schnittstelle auf Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

14 Vorteile von Unit Testing
Tests sind: Reproduzierbar (von anderen) Automatisierbar und selbst auswertend Dokumentierend und Anwendungsbeispiel Tests decken Designfehler frühzeitig auf Der entstehende Code ist: Modular und einfach Änderungssicher Qualitativ hochwertiger => Weniger Fehler, Debugging und Fehlersuche Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

15 Testen Ziel: Fehler finden IST-SOLL Vergleich z.B. mit JUnit
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

16 Vorgehen beim Testen Test vor der Implementierung:
Funktionalität abprüfen Alle möglichen Fehlerfälle prüfen aber keine Trivialitäten So wenig wie möglich implementieren Genau soviel, dass der Test erfolgreich ist Umfang vom Testcode: 15-50% Anteil am Gesamtcode Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

17 Testgetriebene Entwicklung
Funktionale Anforderung Test anlegen Schnittstelle anlegen Test implementieren Funktion implementieren Eine Iteration Zeit Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

18 Tests für CoreWars Verwenden Junit 3.8 (siehe Beispiele)
möglichst früh Tests schreiben, (Test-first) vor oder während der Implementierung Hinterher macht das keinen Spaß! Achtung: gemeinsame Deadline für Tests und Implementierung! Szenarien-basiert: Test „spielt“ ein Szenario durch Prüfen der Ergebnisse Vorgehen siehe Vorlesung Programmiermethodik Debugger (Breakpoints, Variables View...) nutzen! Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

19 Tests für die 8 neuen Befehle
Siehe existierende Tests in CUTest.java Selbes Schema: Instruktion(en) erzeugen Queue mit Program Counter befüllen Aktuelle Instruktion ausführen Sind die richtigen Änderungen im Core? Stimmt der neue Program Counter? Testet die Funktion der Opcodes Mindestens eine Test-Methode pro Opcode Und auch die Fehlerfälle Division durch 0 ... Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

20 JUnit Framework (1) Freies Open Source Framework http://www.junit.org/
Verwendet: 3.8.1, aktuell: 4.4 Autoren: Kent Beck & Erich Gamma Grundeinstellung: Das Feature funktioniert erst … … wenn ein Test geschrieben wurde Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

21 JUnit Framework (2) Tests in separaten Test-Klassen, aber im gleichen Paket Test-Methoden Instanzieren von Objekten Prüfung des Objektzustandes vor und nach Methodenaufrufen Assertion-Methoden Prüfung von Fehlerbehandlung (Exceptions) Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

22 JUnit Framework (3) Basisklassen für Test-Klassen:
junit.framework.TestCase Stellt Assert-Methoden bereit TestRunner lassen Tests ablaufen: Eine Methode einer Test-Klasse Eine Test-Klasse komplett Mehrere Test-Klassen as TestSuite Grafisch oder Textmodus Oder direkt in Eclipse „Run As -> JUnit Test“ Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

23 Aufbau einer Test-Klasse
Tests werden thematisch in einer Klasse gesammelt: … extends TestCase … Jeder Test ist eine Methode: public void test<Name> throws Exception { … } Vor und nach jedem Test: public void setUp() { … } Objektstruktur aufbauen public void tearDown() { … } - aufräumen Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

24 Assertion-Methoden Ausdrücke, die wahr sein müssen, sonst Abbruch der aktuellen Test-Methode assertEquals(soll, ist) Object, primitive Typen assertTrue(boolean) assert[Not]Null(Object), assert[Not]Same(obj1, obj2) Bei Fehlschlag oder fail(): Wirft junit.framework.AssertionFailedError Alle Methoden auch mit ‚String message‘ Parameter Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

25 Testen - Vorgehen Erster Hinweis: Fehlermeldung! Stacktrace
Debugging - Einkreisen eines Fehlers Breakpoints an „spannenden“ Stellen setzen Variablenbelegung / Objekstruktur überprüfen Methode schrittweise ausführen in interessante Methoden reinsteppen Tip: Fehler gefunden => reproduzierenden Test schreiben Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University