# SWT Übung 9
## Aufgabe 1 - Anwendungsfalldiagramm

## Aufgabe 2 - Analysephase: Klassen- und Sequenzdiagramm

## Aufgabe 3 - Refactoring
*a) Was ist Refactoring?*
Refactoring ist eine systematische Umstrukturierung des Codes ohne das Verhalten nach außen zu ändern. Bei dieser Umstrukturierung gibt es klare Anweisungen und einen festgelegten Ablauf. Es geschieht in kleinen Schritten, nach denen jeweils ein Test erfolgt. Refactoring ist außerdem strikt von Funktionsänderungen abgekoppelt.

*b) Was ist der Zusammenhang von Refactoring und automatisierten Tests?*
Durch die Tests kann man erkennen, ob nur eine verhaltenserhaltende Strukturverbesserung stattgefunden hat, oder sich der Code in seinem Verhalten geändert hat. Bevor man Refactoring durchführt, ist es also sinnvoll, Tests zu schreiben. Diese müssen nach dem Refactoring immer noch funktionieren und signalisieren bei einem anderen Ergebnis/Fehlschlag, dass das Refactoring nicht ganz erfolgreich war.

*c) Warum sollte man Refactoring und Funktionserweiterung nicht mischen?*
Sobald man Funktionserweiterungen mit Refactoring mischt, können die Tests andere Ergebnisse liefern als zuvor. Man weiß nicht, ob das wegen eines Fehlers im Refactoring ist, oder weil die Tests nicht zum neuen Verhalten passen.

*d) Was ist der Nutzen von Refactoring?*
Probleme, die durch Refactoring behoben werden sind meist aufgrund von schwerer Wartbarkeit des Codes/Programms. Der Code enthält dann vermutlich Redundanzen, komplexe Fallunterscheidungen, ist unverständlich und um Erweiterungen zu implementieren sind Änderungen im bestehenden Codes erforderlich. Je mehr Code, umso unverständlicher ist er.
Refactoring...
- macht Software leichter wartbar und verständlicher
- hilft Bugs zu finden
- macht das Programmieren schneller

*e) Was ist ein „Code smell“?*
Ein Code Smell ist ein Problem im Code das auf die Notwendigkeit hinweist, ein bestimmtes Refactoring durchzuführen.

*f) Beschreiben Sie die Schritte des „Extract Method“ Refactorings (incl. der
Varianten)*
Vorbedingungen prüfen: der zu extrahierende Code enthält keine unvollständige Anweisungen oder Blöcke, return Anweisungen oder Zuweisungen an mehr als eine lokale Variable, die nach dem extrahierten Teilstück noch benutzt wird

**Fall 1: keine lokale Variable im extrahierten Block**
1. neue private Methode erzeugen
2. Variablen, die nur in der neuen Methode benutzt werden: Deklaration als lokale Variablen der neuen Methode
3. zu extrahierenden Code kopieren
4. neue Methode compilieren
5. zu extrahierenden Code durch Methodenaufruf ersetzen, Deklaration nicht mehr benötigter lokaler Variablen löschen
6. Kompilieren der Ursprungsmethode
7. Testen
8. Extrahierte Methode aufräumen (z.B. lokale Variablen sinnvoll umbenennen)

**Fall 2: lokale Variable, die gelesen wird**
1. neue private Methode erzeugen **(die Variable wird zum Parameter der extrahierten Methode)**
2. Variablen, die nur in der neuen Methode benutzt werden: Deklaration als lokale Variablen der neuen Methode
3. zu extrahierenden Code kopieren
4. neue Methode compilieren
5. zu extrahierenden Code durch Methodenaufruf ersetzen, Deklaration nicht mehr benötigter lokaler Variablen löschen
6. Kompilieren der Ursprungsmethode
7. Testen
8. Extrahierte Methode aufräumen (z.B. lokale Variablen sinnvoll umbenennen)

**Fall 3: eine lokale Variable, die geschrieben wird**
1. neue private Methode erzeugen **(die Variable wird zum Parameter der extrahierten Methode und wird als Ergebnis zurückgegeben)**
2. Variablen, die nur in der neuen Methode benutzt werden: Deklaration als lokale Variablen der neuen Methode
3. zu extrahierenden Code kopieren
4. neue Methode compilieren
5. zu extrahierenden Code durch Methodenaufruf ersetzen, Deklaration nicht mehr benötigter lokaler Variablen löschen
6. Kompilieren der Ursprungsmethode
7. Testen
8. Extrahierte Methode aufräumen (z.B. lokale Variablen sinnvoll umbenennen)

**Fall 4: mehrere lokale Variablen, die geschrieben werden**
Methode ist nicht extrahierbar -> Vorbedingungen nicht eingehalten

**Zusammengefasst:**
1. Lokale Variablen des zu extrahierenden Codes in Ursprungsmethode suchen
- die in der neuen Methode gelesen werden: Parameter der neuen Methode
- die in der neuen Methode verändert und in der alten weiter benutzt werden: falls nur eine Variable, als Ergebnis der neuen Methode zurückgeben; sonst: Methode nicht extrahierbar!
2. Neue Methode erzeugen (immer private)
3. Variablen, die nur in der neuen Methode benutzt werden, Deklaration als lokale Variablen der neuen Methode
4. zu extrahierenden Code in die neue Methode kopieren (in der alten noch nicht löschen)
5. Kompilieren der extrahierten Methode
6. In Ursprungsmethode extrahierten Code ersetzen durch Aufruf der neuen Methode und Deklaration nicht mehr benötigter lokaler Variablen löschen
7. Kompilieren der Ursprungsmethode
8. Testen
9. Extrahierte Methode aufräumen (z.B. lokale Variablen sinnvoll umbenennen)

## Aufgabe 4 - Anforderungserhebung
*a) Welche Anforderungsarten gibt es? Erklären Sie ihre Bedeutung.*
1. Funktionale Anforderungen (Was)
- Beschreiben die Interaktionen zwischen dem System und seiner Umgebung unabhängig von der Implementierung
2. Nichtfunktionale Anforderungen (Wie)
- für den Nutzer sichtbare Aspekte des Systems, welche nicht direkt mit dem funktionalen Verhalten in Veziehung stehen
3. Nebenbedingungen ("Pseudo requirements")
- Alles, was die Umsetzung des Was und Wie einschränkt
- Bedingt durch den Kunden oder der Einsatzumgebung des Systems

*b) Geben Sie die Schritte der Anforderungserhebung wieder.*
1. Sammle Anforderungen ((nicht)funktionale Anforderungen und Nebenbedingungen)
2. Entwickle das funktionale Modell
- Use Cases zur Illustration der funktionalen Anforderungen
4. Entwickle das Objektmodell der Anwendungsdomäne (= was der Nutzer sieht)
- Klassendiagramme, die relevante Konzepte der Domäne beschreiben
5. Entwickle das dynamische Modell der Anwendungsdomäne
- Interaktionsdiagramm (Zusammenspiel von Objekten)
- Zustandsdiagramm (interne Abläufe von Objekten)
- Aktivitätsdiagramm (Geschäftsprozesse)

*c) Geben Sie die wichtigsten Konzepte der Anforderungserhebung wieder.*
Die Anfordderungserhebung gibt eine Definition des Systems in einer Form, die **Kunden und Entwickler** verstehen.
Der Nutzer hat Wissen über die Anwendunsdomäne und der Entwickler über die Implementierungsdomäne. Man muss nun die Lücke zwischen Nutzer und Entwickler überbrücken. Dies geschieht mit Ziele, Szenarien und Use Cases.
- Ziel: fasst eine Systemfunktion in einer verständlichen, überprüfbaren Weise zusammen
- Szenario:
- Beispiel der Nutzen des Systems in Form einer Reihe von Interaktionen zwischen externen Akteuren und dem System
- spezifiziert wie sich eine Voraussetzung auswirkt
- Use Case (UC):
- Abstraktion, welche eine Klasse von Szenarien beschreibt
- Use Case verbindet ein Ziel mit den zugehörigen Szenarien
- Name des Use Case ist seine Zielsetzung (aktives Verb steht am Anfang)

*d) Welche Arten von Szenarien gibt es? Nennen Sie die Begriffe und erläutern sie jeden kurz.*
- As-Is Szenarien
- Zur Beschreibung einer momentanen Situation
- Normalerweise während des Reengineering genutzt
- Der Benutzer beschreibt das System.
- Visionäre Szenarien
- Zur Beschreibung eines zukünftigen Systems
- Normalerweise genutzt beim Greenfield Engineering oder Reengineering
- Kann oft weder von Benutzer noch Entwickler alleine erstellt werden
- Evaluationsszenarien
- Benutzeraufgaben, anhand derer das System bewertet wird
- Training Szenarien
- Schritt–für–Schritt Anweisungen, um einen Neuling durch das System zu führen

## Aufgabe 5 - Anforderungsanalyse
Technische Spezifikation des Systems in einer für die Entwickler verständlichen, handhabbaren und realisierbaren Form
*a) Welchem Typen im Analyse-Modell entspricht ein Typ des Domain Object Models im Regelfall?*
Jeder Typ im Domain Object Model ist ein Entity-Kandidat im Analyse-Modell.

*b) Halten Sie BuchungsTabelle als Benennung für einen Boundary, der eine Tabelle mit allen Buchungen auf dem Bildschirm ausgibt für sinnvoll? Erklären Sie warum!*
Nein, da hier Implementierungsbegriffe verwendet werden. Sinnvoller wäre BuchungsBoundary.

*c) Was kapselt ein Controller?*
Ein Controller kapselt den Ereignisfluss eines Use-Case und ist die Vermittlungsstelle zwischen Entities und Boundaries.

*d) Welchen Sinn hat die Trennung aller Typen in die drei Analyse-Stereotypen?*
Die Trennung der drei Typen ermöglicht Stabilität und Flexibilität.
- Stabilität: Modelle sind weniger änderungsanfällig
- Grenzen eines systems (boundaries) und Geschäftsabläufe (controller) ändern sich häufig
- jede Änderung soll den Rest des Systems nicht beeinflussen
- Flexibilität: Modelle sind leicht kombinierbar
- verschiedene Geschäftsabläufe und Oberflächen sollen möglichst frei miteinander kombinierbar sein

*e) Welche Analyse-Typen dürfen voneinander abhängig sein?*
- Boundary zu Controller
- Boundary zu Boundary
- Controller zu Entity
- Controller zu Boundary
- Controller zu Controller
- Entity zu Entity

Vebotene Abhängigkeiten hingegen sind
- Boundary zu Entity
- Entity zu Boundary
- Entity zu Controller

*f) Entspricht das physische Gerät, welches vom Kunden verwendet wird, immer einem Boundary? Begründen Sie!*
Ein Boundary ist die Schnittstelle zum Akteur. Es beschreibt die Interaktionen zwischen dem System und den Akteuren.
Demnach sollte jeder Akteur mit nur einem Boundary verknüpft sein. Jedes Boundary sollte mit mindestens einem Akteur verknüpft sein. Es muss jedoch nicht unbedingt einem physischen Gerät entsprechen. Ein Popup-Fenster auf einem Bildschirm ist beispielsweise nicht physisch, aber eine Schnittstelle für die Kommunikation zwischen System und Akteur. Typische Boundaries sind in der Regel Dateneingabeformulare, Fenster, Fragen und Nachrichten an den Nutzer.