Siehe Kapitel_5_[SE17-18]-System_Design(final UPDATE 4-12-17).pdf des Moduls SE1.

Strukturierung der Software als MVC-Musters (Kapitel 5, Folie 40).

Definieren sie dazu Java-Packages, um eine Software-Architektur ihrer Anwendung zu etablieren!
Definieren sie je ein Package für folgende Klassen in ihrem System:

• Model-Klassen
  • (zentrale Container-Klassen zur Verwaltung von Entities)
• Entity-Klassen
  • (langlebige Objekte; hier: die UserStory)
• View-Klassen
  • (Klassen für die Ein- und Ausgabe)
  • Soll ein Interface „OutputList“ enthalten, das als Vorgabe für diverse konkrete Klassen dienen soll, welche Ausgaben produzieren.
    • + display( list : List<UserStoryDTO> )
// bitte das DTO beachten!! Die zu übergebene Liste ist unsortiert!
  • View-Klassen dürfen demnach keine Entitys (also hier in dieser Aufgabe: Objekte vom Typ UserStory), sondern nur DTOs direkt sehen und verarbeiten.
    Die Ausgabe der UserStories(-DTOs) können sie auf die Darstellung des Titels, einer ID sowie auf den zugehörigen Priorisierungswert beschränken.
    Die Attributswerte eines DTOs werden aus einer Entity „entnommen“.
  • Implementieren sie eine exemplarische Ausgabe-Klasse (z.B. sortierte Ausgabe gemäß der UserStory 6; die Sortierung erfolgt dann somit innerhalb der Ausgabe-Klasse!).
• Controller-Klassen
  • (Klasse(n) zum Starten des Programms zur Entgegennahme von Befehlen (z.B. load, exit) aus der Console sowie zum Ausführen von Befehlen)
• Utility-Klassen
  • (Util-Klasse zur Auslagerung der Berechnung der Priorisierung sowie zur Überprüfung der Fibonacci-Zahlen (siehe nächste User Story)
• Exception-Klassen
  • .......
• Command-Klassen
  • Enthält für diese Aufgabe noch keine Klassen, dient aber später dazu, den Controller gemäß MVC mit ausführbaren Befehlen genauer zu implementieren.
• DTO-Klassen
  • (Klasse UserStoryDTO)

• Anwendung der Prio-Formel nach Gloger
• Absteigende Sortierung: Höchste Werte zuerst
• Der Prio-Wert soll in der UserStory-Entity abgespeichert werden

Liefern sie eine prototypische Implementierung der oben beschrieben funktionalen und technischen Anforderungen.
Laden sie den Source Code der Implementierung „gezipt“ auf LEA hoch (Assignment: Mid-Term)

Abspeichern der Daten auf die Festplatte
(Utils-Methoden zum Speichern/Laden)

• Zum Speichern von Daten muss die Klasse ObjectOutputStream aus dem
Package java.io verwendet werden
• Zum Laden von Daten muss die Klasse Klasse ObjectInputStream aus dem
Package java.io verwendet werden

Modellieren sie das resultierende Klassendiagramm unter Verwendung der notwendigen Muster anhand eines UML-Klassendiagramms.
Upload als PDF ebenfalls auf LEA!

Als Anwender möchte ich eine bereits eingegebene User Story analysieren können, um ihre Qualität festzustellen, und um somit auch die Qualität aller User Stories langfristig zu optimieren und sicherzustellen.

Details:
Die Ausführung der Analyse-Funktion soll mit Hilfe des Befehls analyze mit der Angabe einer bekannten ID einer User Story erfolgen.

Eine Ausgabe soll dann die bewertete Qualität der User Story in Prozent (%) ausdrücken.
Beispiel (Die Zahl 1 entspricht der ID einer gegebenen User Story):

> analyze 1
Die User Story mit der ID 1 hat folgende Qualität:
100% (sehr gut)

Alle Befehle sollen über eine Kommandozeile („Shell“) eingegeben werden können.
Die Klasse "Container.java" ist zu verwenden.

Struktur der Eingabe:

befehl [parameter]

Befehle:

• enter
  • (Eingabe einer User Story, nur Ablage in den RAM-Speicher)
• store
  • (Abspeichern von User Story auf einen Datenträger)
• load
  • (Laden von User Stories von einem Datenträger)
• dump
  • (sortierte Ausgabe der User Stories inklusive aller eingegeben Werte und Angaben)
• help
  • (ausgabe der Liste an Befehlen samt Beschreibung)

Hinweise:

• Die Entwicklung einer graphischen Benutzeroberfläche ist nicht erwünscht.
• Bei eingabe eines ungültigen Befehls wird eine entsprechende Hinweismeldung ausgegeben und anschließend der "help"-Befehl ausgeführt.

Als Anwender möchte ich den zuletzt eingegebenen Befehl rückgängig machen, damit ich falsch eingegebene Eingaben löschen kann.
Damit soll allgemein die Usability (Bedienbarkeit) des Tools verbessert werden.

Details:
Das Rückgängigmachen von Befehlen soll durch den Befehl undo erfolgen.
In dieser Version des Prio-Tools soll das Eintragen von User Stories sowie von Akteuren rückgängig gemacht werden.

Zusammenhängendes Beispiel:

> addElement – actor Student
Der Akteur Student wurde im System registriert!

> actors
Student
Professor

> undo

> actors
Professor

> undo
nothing to undo!

Als Entwickler möchte ich die User Stories ausgegeben bekommen, die nicht abgeschlossen sind, damit ich eine klare Vorstellung habe, welche Stories generell noch umzusetzen sind.

Beachte die technischen Anforderungen im Wiki!

Eingabedialog für Entwickler für die notwendigen Daten einer User Story

Notwendige Daten der US Entity:

• Beschreibung: String
• Details: String
• Akzeptanzkriterien: String
• Epic: String
• Mehrwert: int (Wertbereich: 1-5)
• Strafe: int (Wertbereich: 1-5)
• Risiko: int (Wertbereich: 1-5)
• Aufwand: int
• Prio: double (als Getter)

Errechnung der Priorität (Auslagern in statische Methode der Klasse Utils):
Prio = (Mehrwert + Strafe)/(Aufwand + Risiko)

Sent from my Nexus 6 using FastHub

Neue Algorithmen zur Überprüfung der Qualität und somit zur Aufdeckung von Defiziten einer User Story sollen flexibel in das System integriert werden können.

Der Vorgang einer Überprüfung der Qualität einer User Story soll mit einem UML Sequenzdiagramm anhand eines konkreten Szenarios modelliert werden.
Upload als PDF ebenfalls auf LEA!

Modellieren sie das resultierende Klassendiagramm unter Verwendung der notwendigen
Muster anhand eines UML-Klassendiagramms.
Upload als PDF ebenfalls auf LEA!

Der Vorgang einer Überprüfung der Qualität einer User Story soll mit einem UML
Sequenzdiagramm anhand eines konkreten Szenarios modelliert werden.
Upload als
PDF ebenfalls auf LEA!

Laden sie das resultierende bzw. aktualisierte UML Paketdiagramm auf LEA hoch (vgl.
auch Aufgabe 8-2).
PDF ebenfalls auf LEA!

Einen schriftlich beschriebenen Akzeptanztest (vgl. Kapitel 3, Abschnitt 3.3), der von
„ihrem“ Kunden eigenständig ausgeführt werden kann.
Upload ebenfalls auf LEA!

Erstellung von JUnit-Tests für jeden Use-Case.

Sent from my Nexus 6 using FastHub

Mit dem Parameter – details lassen sich die identifizierten Defizite bei der Analyse einer User Story ausgeben.

Beispiel Nr. 1:
> analyze 2 – details
Die User Story mit der ID 2 hat folgende Qualität:
70% (befriedigend)

Details:
Kein schriftlicher Mehrwert zu erkennen (- 30%)

Beispiel Nr. 2:
> analyze 1 – details
Die User Story mit der ID 1 hat folgende Qualität:
100% (sehr gut)

Details:
Alles ok

Modellieren sie die Software-Architektur anhand eines UML-basierten Paketdiagramms.
Orientieren sie sich dabei an die Darstellung aus dem Kapitel_5_[SE17-18]-System_Design(final UPDATE 4-12-17).pdf, Folie 44.
Modellieren sie auch die Abhängigkeiten zwischen ihren Paketen.
Fügen sie ihre Pakete auch in eine Schicht-Architektur ein gemäß folgender Schicht-Aufteilung:

• UI-Layer
• AL-Layer
• IN-Schicht (Infrastruktur).

Das „Command“-Package sollten sie in dieser Aufgabe noch nicht berücksichtigen.

Erstellen Sie einen schriftlich beschriebenen Akzeptanztest (vgl. Kapitel_3_[SE17-18]_ Anforderungen_(final KOMPLETT).pdf, Abschnitt 3.3), der von „ihrem“ Kunden eigenständig ausgeführt werden kann.
Upload ebenfalls auf LEA!

Als Entwickler möchte ich angeben, dass eine User Story abgeschlossen wurde, um somit ein einfaches Tracking meiner Stories durchzuführen.

Erweiterung mit einem privaten boolean samt Kapselung.

Erstellung der Klasse "Container.java"
Diese kapselt List<UserStory> und erlaubt den Zugriff über Methoden.
GET US, ADD US, REMOVE US, GET ALL

Folgende funktionale Anforderungen (FA) soll diese Klasse unterstützen:

FA1:
Es soll möglich sein, Objekte vom Typ UserStory in einem instanziierten Objekt der Klasse Container zur Laufzeit abzuspeichern.
Eine Kontrolle, ob ein übergebenes UserStory-Objekt mit einer ID bereits in dem Container-Objekt enthalten ist, sollte ebenfalls in der Container -Klasse implementiert werden.
Falls ein UserStory-Objekt mit einer bereits vorhandenen ID übergeben wird, so soll eine geprüfte Exception vom Typ ContainerException ausgeworfen werden.
Der StackTrace dieser Exception sollte folgendes exakt ausgeben:

„Das UserStory-Objekt mit der ID [hier die ID des Objekts] ist bereits vorhanden!“

FA2:
Es soll möglich sein, Objekte vom Typ UserStory in einem instanziierten Objekt der Klasse Container zur Laufzeit zu löschen.
Dazu muss die eindeutige ID des Objekts vom Typ UserStory dem Container-Objekt übergeben werden.
Falls zu der übergebenen ID kein UserStory-Objekt gespeichert ist, sollte über eine Exception eine entsprechende Fehlermeldung ausgegeben werden.

FA3:
Es soll mit einer Methode dump möglich sein, die IDs der aktuell abgespeicherten Objekte vom Typ UserStory auszugeben (z.B. auf der Console).
Für die Ausgabe der ID eines einzelnen UserStory-Objekts soll innerhalb der Methode dump die Methode toString() des jeweiligen UserStory-Objekts verwendet werden.

FA4:
Es soll möglich sein, die Anzahl der aktuell abgespeicherten Objekte vom Typ Member in einem Container-Objekt zu ermitteln und an ein aufrufendes Objekt als Rückgabeparameter zu übergeben.

Change requests (CR):

CR1:
Es soll zur Laufzeit zugesichert werden, dass von der Klasse Container nur ein einziges Mal ein Objekt erzeugt werden kann und somit nur ein Objekt davon im Speicher existiert.
(Singleton-Pattern)

CR2:
Die Abspeicherung eines Objekts in einem Container-Objekt soll weiterhin über eine zentrale Methode erfolgen.
Die Klasse Container soll nun so erweitert werden, dass je nach selektiertem List-Type die Abspeicherung intern in dem Container–Objekt über eine ArrayList oder eine LinkedList erfolgen soll. Der List-Type soll von außen über eine Methode changeListType( Modus modus ) gesetzt werden können.
Die verschiedenen List-Types sollen als Konstanten in einem paketsichtbaren enum type Modus definiert werden, die dann z.B. innerhalb der Test-Klasse wie folgt verwendet werden können, um einen List-Type zu ändern (bzw. initial zu setzen):

Container con = ...
con.changeListType( Modus.LIST_TYPE_ARRAY );

Das Umsetzen eines List-Types auf ArrayList bzw. LinkedList kann die Löschung einer bestehenden Liste implizieren.
Ein Umkopieren ist nicht notwendig.

Sent from my Nexus 6 using FastHub

Die aktuell registrierten Akteure können mit dem Befehl actors ausgeben werden.
Beispiel:

> actors
Student
Professor

Der Befehl analyze kann auch mit Parameter verwendet werden. Der Parameter – all dient dazu, die durchschnittliche Qualität aller User Stories zu bewerten.
Beispiel:

> analyze – all
Ihre 13 User Stories haben durchschnittlich folgende Qualität:
87,5% (gut)

Die genaue bzw. vollständige prozentuale Verteilung zur Bewertung der Qualität sollten sie im Rahmen ihrer Metrik selber definieren.

Beachte die technischen Anforderungen im Wiki!

Liste alle Userstories mit eingegebenen Daten

Als Anwender des Prio-Tools möchte ich, dass eine Überprüfung des Aufwands gemäß der Fibonacci-Zahlen durchgeführt wird, damit ich stets eine korrekte Aufwandsabschätzung abgebe.

Details: Anstelle von 21 soll eine 20 ausgegeben werden. Die maximale Zahl ist 50.
Für die Überprüfung soll eine pragmatische Lösung dienen.

Tipp:
Die Fibonacci-Zahlen bis 100
1,2,3,5,8,13,20,35,50,100

Beispiel Nr. 3: Mit dem Parameter – hints können zusätzliche Hinweise (engl.: hints) zur Optimierung ausgegebenen werden:

> analyze 3 – details – hints
Die User Story mit der ID 3 hat folgende Qualität:
50% (ausreichend)

Details:
Kein schriftlicher Mehrwert zu erkennen (- 30%)
Akteur („Student“) ist nicht bekannt (- 20%)

Hints:
Fügen sie einen schriftlichen Mehrwert hinzu!
Registrieren sie einen neuen Akteur!

Weitere Defizite, die zu einer prozentualen Herabstufung der Qualität einer User Story
führen, können sie gerne selber definieren und als Algorithmus implementieren.
Rücksprache dazu bitte mit dem Projektleiter.

Falls ein Akteur in einer User Story nicht bekannt ist, so kann er in ihrem System hinzugefügt werden.

Als Anwender möchte ich Bezeichnungen für Akteure in das Prio-Tool registrieren, um die Qualitätsanalyse bei einer User Story zu optimieren.

Detail: Zur Eintragung von Bezeichnungen für Akteure soll der Befehl addElement dienen. Ein Akteur kann mit dem zusätzlichen Parameter – actor registriert werden.

Zusammenhängendes Beispiel (in Zusammenhang mit dem obigen Beispiel):

> analyze 3 – details – hints
Die User Story mit der ID 3 hat folgende Qualität:
50% (ausreichend)

Details:
Kein schriftlicher Mehrwert zu erkennen (- 30%)
Akteur („Student“) ist nicht bekannt (- 20%)

Hints:
Fügen sie einen schriftlichen Mehrwert hinzu!
Registrieren sie einen neuen Akteur!

> addElement – actor Student
Der Akteur Student wurde im System registriert!

> analyze 3 – details
Die User Story mit der ID 3 hat folgende Qualität:
30% (befriedigend)

Details:
Kein schriftlicher Mehrwert zu erkennen (- 30%)