fachgebiet software engineering Übersicht © 22.01.2014 albert zündorf, kassel university...

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

Wasserfallmodel


Machbarkeitsstudie

Auswählen des Produktes

Voruntersuchung des Produkts

Durchführbarkeitsuntersuchung

Prüfen der ökonomischen Durchführbarkeit

Ergebnis: „Stop or go“ Entscheidung


Anforderungsdefinition

Konzepterarbeitung mit Laien / Kunden

Verständliche Szenarios

Klärung der Funktionalität

Nichtfunktionale Anforderungen

Anforderungsdokumentation


Analyse

Grob-Entwurf

in der „Problem-Domain“

Erfassen der Domain (Business-Model)

Konzeption neuer (komplexer) Funktionalität

Konzeption von (Architektur) Umbauten

Architekturkonzepte


Design

Fein-Entwurf

in der „Solution-Domain“

Arbeitsvorlage für den Entwickler

Konzeption neuer (komplexer) Funktionalität

Konzeption von (Architektur) Umbauten

Architekturkonzepte


Implementierung

hier wird „gehackt“

Entwickler orientieren sich am Design-Dokument

Tests


Wartung

Auslieferung

Pflege vor Ort

Bugfixing


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


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


Abgaben

Abgaben per CVS

setzen der Tags gemäß Aufgabenstellung v3

vor der Deadline

in eclipse: Rechtsklick Team Tag as Version


Organisatorische Hinweise

Im OKA anmelden - bis Anfang Dezember, Veranstaltung „Softwaretechnik“


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


Unit Tests

Testen eine ‚Einheit‘: Klasse Modul Komponente

Werden programmiert

Prüfen den Funktionsumfang

Rufen nur die öffentliche Schnittstelle auf


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


Testen

Ziel: Fehler finden

IST-SOLL Vergleich

z.B. mit JUnit


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


Testgetriebene Entwicklung

Funktionale Anforderung

Test anlegen

Schnittstelle anlegen

Test implementieren

Funktion implementieren

Eine Iteration Zeit


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!


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 ...


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


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)


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“


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


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


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 © 22.01.2014 albert zündorf, kassel university...

Documents