Softwaretechnik II, Sommersemester 2013pi.informatik.uni-siegen.de/Mitarbeiter/berlik/swt/swt3.pdf2...

1 / 43

Softwaretechnik IISommersemester 2014

Software-Qualitat

Stefan Berlik

Fachgruppe Praktische InformatikFakultat IV, Department Elektrotechnik und Informatik

Universitat Siegen

8. Mai 2014

Softwaretechnik II . Grundlagen des Softwaretestens III

2 / 43

Gliederung

1 Agile Software-EntwicklungMotivationUbersicht Softwareentwicklungs-MethodenAgile Softwareentwicklungs-Methoden

2 Testgetriebene Entwicklung

3 JUnit-Test

Stefan Berlik (Universitat Siegen)

. Agile Software-Entwicklung 3 / 43

Gliederung

3 JUnit-Test

. Agile Software-Entwicklung . Motivation 4 / 43

[nach: Total Quality Management, J. Oakland, 1989]

Generelle Risiken bei der Softwareentwicklung

Risiken

- Fehlerrate- Verstandnisprobleme- Personalwechsel- Anderungen von Anforderungen- Terminverzogerung- Unrentabilitat- Projektabbruche

Entwicklungsprozesse halten mit der Komplexitat der Softwarenicht Schritt

.’Softwarekrise‘

Risiken

Entwicklungsprozesse halten mit der Komplexitat der Softwarenicht Schritt

.’Softwarekrise‘

Risiken

Entwicklungsprozesse halten mit der Komplexitat der Softwarenicht Schritt.

’Softwarekrise‘

. Agile Software-Entwicklung . Ubersicht Softwareentwicklungs-Methoden 6 / 43

Klassifikation von SE-Methoden

’Code & fix‘,

’Hacking‘

Wenige Tests, Kommentare

Schnell unverstandlicherCode

’Code & fix‘,

’Hacking‘

Folge von Tatigkeiten mitphasenweisen Ergebnissen

Z.B. Wasserfallmodell, V-Modell,Spiralmodell, RUP

’Code & fix‘,

’Hacking‘

Folge von Tatigkeiten mitphasenweisen Ergebnissen

Z.B. Wasserfallmodell, V-Modell,Spiralmodell, RUP

Schnelle Ergebnisse fur denKunden

Intensive Zusammenarbeit mitdem Kunden

Z.B. Extreme Programming,Scrum

Ad-Hoc-Entwicklungsprozess

Nachdem die Anforderungen (mehr oder weniger) geklart sind, wirdsolange programmiert, getestet und korrigiert, bis die Software einenakzeptablen Stand erreicht hat.

Vorteile

- Kein’Overhead‘ fur Design, Dokumentation, Einhalten von Standards, . . .

- Keine Vorkenntnisse erforderlich

Nachteile

- Keine Moglichkeit, den aktuellen Projektstatus zu ermitteln- Kaum Moglichkeiten zur Projektsteuerung- Probleme bei Wartbarkeit und Erweiterbarkeit

Nur geeignet fur kleine Projekte mit kurzer Laufzeit,z.B. Wegwerfprototypen,

’Proof-of-Concept‘, Demos etc.

Vorteile

Nachteile

Vorteile

Nachteile

Wasserfallmodell [Winston Royce, 1970]

”I believe in this concept, butthe implementation describedabove is risky and invitesfailure. . . ”

”Attempt to do the job twice -the first result provides an earlysimulation of the finalproduct.”

Wasserfallmodell . Eigenschaften

Abfolge nicht uberlappender Phasen mit klar definierten Meilensteinen

Review nach Abschluss jeder einzelnen Phase zum Prufen, ob diePhasenziele erreicht wurden

Rucksprunge sind (ursprunglich) nicht vorgesehen

Geeignet fur Projekte mit stabilem Umfeld,z.B. Weiterentwicklungsprojekte oder Portierungen

. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 10 / 43

Agiles Manifest als Wertesystem

[www.agilemanifesto.org]

Realisierung agiler SE-Prozesse

eXtreme Programming (XP)

- Beschreibt Techniken der agilen Softwareentwicklung

- Beschreibt einen Entwurfsprozess der die Techniken des XP nutzt

ErgoScrum ist eher auf der Managementebene angesiedelt, XP auf derEbene der Entwicklungspraktiken

VorteilhaftKombination von Scrum und XP

Realisierung agiler SE-Prozesse

eXtreme Programming (XP)

- Beschreibt Techniken der agilen Softwareentwicklung

- Beschreibt einen Entwurfsprozess der die Techniken des XP nutzt

ErgoScrum ist eher auf der Managementebene angesiedelt, XP auf derEbene der Entwicklungspraktiken

VorteilhaftKombination von Scrum und XP

Extreme Programming

1996 von Kent Beck vorgeschlagen als

”. . . eine leichte, effiziente, risikoarme, flexible, kalkulierbare, exakte

und vergnugliche Art und Weise der Softwareentwicklung.“

Warum’Extreme Programming‘?

”Extreme programming takes common principles and practices to

extreme levels“-

’Code reviews‘ sind gut. Standige

’code reviews‘,

’pair programming‘

- Testen ist gut. Standiges Testen

Programmierer: ModultestsKunden: Funktionstests

- Integrationstests sind wichtig. Mehrmals am Tag

’continuous integration‘

- Design ist wichtig. Standiges (re)design,

’refactoring‘

- Einfachheit ist gut. Alles so einfach wie moglich bzw. so komplex wie notig

- Architektur ist wichtig. Standige Architekturweiterentwicklung

- Kurze Iterationen sind gut. Extrem kurz:

’Minuten bis Stunden‘,

’planning game‘

extreme levels“-

’code reviews‘,

’refactoring‘

’planning game‘

extreme levels“-

’code reviews‘,

’refactoring‘

’planning game‘

extreme levels“-

’code reviews‘,

’refactoring‘

’planning game‘

extreme levels“-

’code reviews‘,

’refactoring‘

’planning game‘

extreme levels“-

’code reviews‘,

’refactoring‘

’planning game‘

extreme levels“-

’code reviews‘,

’refactoring‘

’planning game‘

extreme levels“-

’code reviews‘,

’refactoring‘

’planning game‘

Die vier Grundwerte des Extreme Programming:Kommunikation, Einfachheit, Feedback, Mut

Kommunikation

- Softwareentwicklung lebt vom effizienten Austausch von Informationen- Standige Kommunikation zwischen Kunden und Entwicklern, sowie unter

den Entwicklern selbst- Moglichst zeitnah und direkt- Von Angesicht zu Angesicht (synchron statt asynchron)

Einfachheit

- ”Do the simplest thing that could possibly work”- Einfachheit als die Kunst, Dinge nicht zu tun, die nicht unbedingt notig

sind- Fuhrt zu Losungen, die leicht verstandlich, schnell umsetzbar und leicht

adaptierbar - ergo agil - sind

Kommunikation

- Softwareentwicklung lebt vom effizienten Austausch von Informationen- Standige Kommunikation zwischen Kunden und Entwicklern, sowie unter

den Entwicklern selbst- Moglichst zeitnah und direkt- Von Angesicht zu Angesicht (synchron statt asynchron)

Einfachheit

- ”Do the simplest thing that could possibly work”- Einfachheit als die Kunst, Dinge nicht zu tun, die nicht unbedingt notig

sind- Fuhrt zu Losungen, die leicht verstandlich, schnell umsetzbar und leicht

adaptierbar - ergo agil - sind

Feedback

- Kontinuierliche Integration von Ruckmeldungen- Basierend auf

’User Stories‘ viele kleine Releases, laufende Integration,

kontinuierliches Testen

- Zu radikalen Anderungen (Refactoring)- Zu Anderungen bei Planung und Priorisierung- Zur Ehrlichkeit bei der Planung- Wird bestarkt durch automatisiertes Testen

Feedback

- Kontinuierliche Integration von Ruckmeldungen- Basierend auf

’User Stories‘ viele kleine Releases, laufende Integration,

kontinuierliches Testen

- Zu radikalen Anderungen (Refactoring)- Zu Anderungen bei Planung und Priorisierung- Zur Ehrlichkeit bei der Planung- Wird bestarkt durch automatisiertes Testen

Extreme Programming Praktiken

XP umfasst 12 Praktikendie sich gegenseitigunterstutzen bzw.verstarken

Gegliedert in 4 Gruppen

- Zeitnahes Feedback- Kontinuierlicher Prozess- Gemeinsames Verstandnis- Wohl der Programmierer

Planungsspiel

Programmie-ren in Paaren

TestgetriebeneEntwicklung

Kunde vor Ort

PermanenteIntegration

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Programmier-standards

XP Praktiken . Zeitnahes Feedback

Planungsspiel

- Zu Beginn jeder Iteration wird vonKunden, Projektmanager und Entwicklerngemeinsam die Releaseplanung per UserStories vorgenommen.

- Priorisierung der Stories erfolgtausschließlich durch den Kunden, dieAufwandsschatzungen nur durch dieEntwickler

Programmieren in Paaren

- Immer zwei Entwickler arbeiten zusammenan einem Arbeitsplatz (KontinuierlichesCodereview)

- Erhohte Qualitat durch regenInformationsfluss

- Die Paare wechseln nach jeder Story /nach Bedarf

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Planungsspiel

- Zu Beginn jeder Iteration wird vonKunden, Projektmanager und Entwicklerngemeinsam die Releaseplanung per UserStories vorgenommen.

- Priorisierung der Stories erfolgtausschließlich durch den Kunden, dieAufwandsschatzungen nur durch dieEntwickler

Programmieren in Paaren

- Immer zwei Entwickler arbeiten zusammenan einem Arbeitsplatz (KontinuierlichesCodereview)

- Erhohte Qualitat durch regenInformationsfluss

- Die Paare wechseln nach jeder Story /nach Bedarf

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Testgetriebene Entwicklung

-’Test-First‘-Ansatz: Entwickler schreibenautomatisiert ausfuhrbare Unit-Testsbevor die eigentliche Funktionalitatimplementiert wird

- Kunde fuhrt Akzeptanztests durch

Kunde vor Ort

- Der Kunde ist standig anwesend (furRuckfragen, Stories, Tests)

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Testgetriebene Entwicklung

-’Test-First‘-Ansatz: Entwickler schreibenautomatisiert ausfuhrbare Unit-Testsbevor die eigentliche Funktionalitatimplementiert wird

- Kunde fuhrt Akzeptanztests durch

Kunde vor Ort

- Der Kunde ist standig anwesend (furRuckfragen, Stories, Tests)

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

XP Praktiken . Kontinuierlicher Prozess

Permanente Integration

- Sobald ein Teil fertig implementiert ist,wird er in das Gesamtsystem integriert

- Vor und nach der Integration werden alleTests durchlaufen

Refaktorierung

- Standige Veranderung / Verbesserung desCodes

- Unit-Tests sorgen dafur, dass dergeanderte Code noch die gleicheFunktionalitat implementiert

Kurze Releasezyklen

- Kurze Iterationszeiten werden eingehalten(max. 4 Wochen)

- Releases werden dem Kunden zurKontrolle und fur Feedback ubergeben(Fruhes Feedback)

- Fruhes ROI

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Refaktorierung

Kurze Releasezyklen

- Fruhes ROI

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Refaktorierung

Kurze Releasezyklen

- Fruhes ROI

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

XP Praktiken . Gemeinsames Verstandnis

Programmierstandards

- Alle verpflichten sich, einen einheitlichenCodierungsstandard einzuhalten

Kollektives Eigentum

- Jeder hat das Recht, an jeder Stelle imCode Veranderungen vorzunehmen

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Programmierstandards

- Alle verpflichten sich, einen einheitlichenCodierungsstandard einzuhalten

Kollektives Eigentum

- Jeder hat das Recht, an jeder Stelle imCode Veranderungen vorzunehmen

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Einfaches Design

- Design und Code werden so einfach wiemoglich gehalten

- Code wird regelmaßig kontrolliert unduberflussiger Code sofort entfernt

- Es wird nur implementiert, was direktAuswirkung auf die Implementierung deraktuell bearbeiteten User Story hat

System Metapher

- Wenige einfache Metaphern zurBeschreibung des zu entwickelndenSystems, so dass allen sein Kern klar ist

- Metapher dient als Ersatz fur dieArchitektur

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Einfaches Design

- Design und Code werden so einfach wiemoglich gehalten

- Code wird regelmaßig kontrolliert unduberflussiger Code sofort entfernt

- Es wird nur implementiert, was direktAuswirkung auf die Implementierung deraktuell bearbeiteten User Story hat

System Metapher

- Wenige einfache Metaphern zurBeschreibung des zu entwickelndenSystems, so dass allen sein Kern klar ist

- Metapher dient als Ersatz fur dieArchitektur

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

XP Praktiken . Wohl der Programmierer

Nachhaltiges Tempo

-’Marathon statt Sprint‘

- Zu hohe Arbeitsbelastung fuhrt zurVerringerung derEntwicklergeschwindigkeit

- Bei XP-Projekten kann nicht (bzw. kaum)mit Uberstunden gearbeitet werden

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Scrum . Uberblick

Scrum ist ein agiler Prozess, der es erlaubt auf die Auslieferung derwichtigsten Geschaftsanforderungen innerhalb kurzester Zeit zufokussieren.

Scrum gestattet es schnell und in regelmaßigen Abschnitten (Sprints)tatsachlich lauffahige Software zu inspizieren.

Das Business setzt die Prioritaten.Selbstorganisierende Entwicklungsteams legen das beste Vorgehen zurAuslieferung der hochstprioren Features fest.

Alle zwei bis vier Wochen kann jeder lauffahige Software sehen undentscheiden, diese so auszuliefern oder in einem weiteren Abschnitt zuerganzen.

Scrum . Funktionsweise

Scrum . Sprints

Scrum-Projekte schreiten in Serien von Sprints voran

Analog zu den Iterationen des Extreme Programming

Die typische Sprintdauer betragt 2-4 Wochen (nicht langer als einKalendermonat)

Eine konstante Dauer fuhrt zu einem besseren Rhythmus

Das Produkt wird wahrend des Sprints entworfen, kodiert und getestet

Sequentielle vs. uberlappende Entwicklung

Anstatt alles im Ganzenhintereinander...

...tun Scrum-Teams ein bisschenvon allem die ganze Zeit uber

Scrum . Konzepte

. Testgetriebene Entwicklung 28 / 43

Gliederung

3 JUnit-Test

Traditionelles Unit-Testen vs. Testgetriebene Entwicklung

[Quelle: Roy Osherove: The Art of Unit Testing.]

Traditionelles Unit-Testen vs. Testgetriebene Entwicklung

[Quelle: Roy Osherove: The Art of Unit Testing.]

Test Driven Development . Test First Design

Refactor

Schreiben einer Testmethode: Fail (keine Funktionvorhanden)

Schreiben einer Funktion mit minimaler, bewusstfalscher Implementierung: Fail (Testen des Tests)

Schreiben einer Funktion mit minimaler (ggf.sinnloser) Implementierung: Pass

Schreiben der benotigten Implementierung

Refactor

Testcode wird vor dem eigentlichen Code geschriebenFrage: Wie wird die Funktionalitat genutzt? Nicht: Wie ist sieimplementiert?

Arbeiten in kleinen SchrittenEin Test + zugehoriger Code, ein Test + zugehoriger Code, . . .”You ain’t gonna need it” (Code erst schreiben, wenn er gebrauchtwird)

Code ist testbarAnders als bei ”feature first” ist Code von Anfang an testbar und mussnicht nachtraglich an Tests angepasst werden.

. TDD is specification not validation

. JUnit-Test 32 / 43

Gliederung

3 JUnit-Test

Definition

”A unit test is a piece of a code (usually a method) that invokes anotherpiece of code and checks the correctness of some assumptions afterward.If the assumptions turn out to be wrong, the unit test has failed. A ’unit’is a method or function.” [Roy Osherove: The Art of Unit Testing.]

Das typische Vorgehen

Business Logic

Datahelper

Database

Classundertest

Helperclass

Data access

Business Logic

Datahelper

Database

Classundertest

Helperclass

Data access

Fehler?

Business Logic

Datahelper

Database

Classundertest

Helperclass

Data access

Fehler?

Business Logic

Datahelper

Database

Classundertest

Helperclass

Data access

Fehler?

. Integrationstest

Was ist ein guter Unit TestAutomatisierbar und jederzeit wiederholbar- Anderungen im Code sind normal und erwunscht (Refactoring).

Anderungen absichern.

Einfach zu implementieren- Tests schreiben bedeutet zusatzlichen Aufwand/Kosten.

Jeder sollte den Test ausfuhren konnen- Anderungen in ’fremden’ Codeteilen mussen abgesichert sein (Collective

Ownership).

Ausfuhrung erfolgt auf Knopfdruck, keine Konfiguration- Tests sollen in verschiedenen Umgebungen laufen ohne angepasst werden

zu mussen.

Lauft schnell- Tests sollen moglichst oft ausgefuhrt werden konnen.

. Ein guter Test?

Was ist ein guter Unit TestAutomatisierbar und jederzeit wiederholbar- Anderungen im Code sind normal und erwunscht (Refactoring).

Anderungen absichern.

Einfach zu implementieren- Tests schreiben bedeutet zusatzlichen Aufwand/Kosten.

Jeder sollte den Test ausfuhren konnen- Anderungen in ’fremden’ Codeteilen mussen abgesichert sein (Collective

Ownership).

Ausfuhrung erfolgt auf Knopfdruck, keine Konfiguration- Tests sollen in verschiedenen Umgebungen laufen ohne angepasst werden

zu mussen.

Lauft schnell- Tests sollen moglichst oft ausgefuhrt werden konnen.

. Ein guter Test?Stefan Berlik (Universitat Siegen)

Was ist ein guter Unit-Test?

A unit test is an automated piece of code that invokes the method orclass being tested and then checks some assumptions about the logicalbehavior of that method or class. A unit test is almost always writtenusing a unit-testing framework. It can be written easily and runs quickly.It’s fully automated, trustworthy, readable and maintainable.” [Roy Osherove: The

Art of Unit Testing.]

Was muss getestet werden?

Jede offentliche Methode der Klassen des Business Layers, dieeine Logik enthalt.

- Logik: Alle Stellen, an denen etwas ’passiert’: if, for, switch,Berechnungen, exceptions, . . .

- Offentlich: Getestet werden nur die Schnittstellen, nicht dieImplementierung (Design by Contract)

- Business Layer: GUI und Data Layer sind nur mit erheblichem Aufwandautomatisiert testbar. Abhangigkeiten zum Business Layer mussen in UnitTests mittels Mocks & Stubs aufgebrochen werden

*Unit - Unit-Test Frameworks

Schreiben, Ausfuhren und Uberwachen von Unit Tests wird nur durchden Einsatz von Frameworks mit vertretbarem Aufwand realisierbar.

Unit Test Frameworks sind fur viele Sprachen verfugbar

- JUnit (Java)- NUnit (.NET)- CppUnit (C++)- SUnit (Smalltalk)- DUnit (Delphi)- MLUnit (Matlab)- . . .

Aufbau von *Unit Testprojekten

Objekt Ebene Verantwortlich

Testprojekt Anwendung Framework. Test Suite Klasse Framework. Testfall Klasse Framework

. SetUp Methode Entwickler

. Testmethode Methode Entwickler

. TearDown Methode Entwickler

Testphasen eines einzelnen Unit Tests

1 SetupInitialisierung des Testobjekts in den Testzustand(SetUp + Testmethode)

2 ExerciseAusfuhren der zu testenden Funktionalitat(Testmethode)

3 VerifyUberprufen ob der Zustand dem erwarteten entspricht(Testmethode)

4 TeardownAufraumen(TearDown Methode)

Neuerungen bei JUnit 4

Normale Klassendefinition ohne TestCase-Ableitung

Testmethoden brauchen kein Prafix test mehr

Testmethoden werden mit @Test Annotation gekennzeichnet (dafurnotwendig: import org.junit.Test)

Weiterhin werden, wie bei JUnit 3, Assert-Methoden furVergleichszwecke benutzt. Diese sind jetzt allerdings statischeMethoden der Klasse Assert und lassen sich so sehr einfach nutzen,wenn man eine entsprechende Import-Anweisung benutzt.

So sieht das aus...

import s t a t i c org . j u n i t . A s s e r t . a s s e r t E q u a l s ;

import org . j u n i t . A f t e r ;import org . j u n i t . A f t e r C l a s s ;import org . j u n i t . B e f o r e ;import org . j u n i t . B e f o r e C l a s s ;import org . j u n i t . I g n o r e ;import org . j u n i t . Test ;

p u b l i c c l a s s C a l c u l a t o r U t i l T e s t {p r i v a t e s t a t i c Long n1 = n u l l ;p r i v a t e s t a t i c Long n2 = new Long ( 1 ) ;p r i v a t e s t a t i c Long n3 = new Long ( 2 ) ;

@ B e f o r e C l a s sp u b l i c s t a t i c v o i d s e t U p B e f o r e C l a s s ( ) throws E x c e p t i o n { . . . }

@ A f t e r C l a s sp u b l i c s t a t i c v o i d t e a r D o w n A f t e r C l a s s ( ) throws E x c e p t i o n { . . . }

@Beforep u b l i c v o i d setUp ( ) throws E x c e p t i o n { . . . }

@Afte rp u b l i c v o i d tearDown ( ) throws E x c e p t i o n { . . . }

So sieht das aus... (2)@Testp u b l i c v o i d t e s t S u b t r a c t Z e r o ( ) {

a s s e r t E q u a l s ( new Long ( 0 ) , C a l c u l a t o r U t i l . s u b t r a c t ( n3 , n3 ) ) ;}

@Test ( t i m e o u t = 1)p u b l i c v o i d t e s t S u b t r a c t T i m e o u t ( ) {

t r y {Thread . s l e e p (10000) ;

} catch ( I n t e r r u p t e d E x c e p t i o n e ) {// TODOe . p r i n t S t a c k T r a c e ( ) ;

}a s s e r t E q u a l s ( new Long ( 1 ) , C a l c u l a t o r U t i l . s u b t r a c t ( n3 , n2 ) ) ;

@Test@ Ig n or ep u b l i c v o i d t e s t S u b t r a c t I g n o r e ( ) {

@Test ( e x p e c t e d = N u l l P o i n t e r E x c e p t i o n . c l a s s )p u b l i c v o i d t e s t S u b t r a c t E x c e p t i o n ( ) {

Softwaretechnik II, Sommersemester 2013pi.informatik.uni-siegen.de/Mitarbeiter/berlik/swt/swt3.pdf2...

Documents

Transcript of Softwaretechnik II, Sommersemester 2013pi.informatik.uni-siegen.de/Mitarbeiter/berlik/swt/swt3.pdf2...