Softwaretechnik WS2013

Projektaufgabe 3

Abgabe per Mail am 28.2. bis Mitternacht!
Beachtet bitte: wenn sich durch Aufgabe 3 Änderungen am Feinentwurf ergeben, dann passt bitte FMC-Diagramm und Klassendiagramm aus Aufgabe 2 an und gebt das mit ab. Passt der Feinentwurf nicht mehr zur Abgabe, könnte das zu Punktabzügen führen.

Falls ihr vorher eine Fragestunde wünscht, dann mailt mich an. Wenn sich genügend Interessenten finden, kann ich nochmal an die FH kommen.

Evaluation

Danke für eure Evaluation (Gruppe D und Gruppe E)


Projektaufgabe 2

Präsentation/Abnahme ist am Dienstag 28.1.2013 zu den üblichen Uhrzeiten, Abgabe per Mail bis MI 29.1. 23:59. An diesem Termin besteht keine Anwesenheitspflicht, d.h. Abgabe ohne Präsentation nur per Mail ist möglich.
Die JavaDoc-Warnungen sollen gemäß diesen Einstellungen konfiguriert sein und es darf in der Abgabe keine Warnungen geben:
JavaDoc

Hier ein kurzes Tutorial für das Erzeugen von JavaDoc-HTML-Dateien aus Eclipse heraus.

Hinweis: mit dem Tag {@link Klassenname#methode()} kann man einen Link auf eine Methode innerhalb des Fließtexts eines JavaDoc-Kommentars erzeugen.
Das Tag @see Klassenname#methode() (ohne geschweifte Klammern) darf nur alleine auf einer Zeile stehen und erzeugt eine "See also"-Angabe unterhalb des Kommentarblocks.
Zur Formatierung des generierten HTML sollte man schon im JavaDoc-Kommentar HTML-Elemente (z.B. "<br/>") verwenden!

Unit-Tests

Hier das JUnit-Beispiel aus dem heutigen Praktikum als gezipptes Eclipse-Projekt (Update 17.01: JavaDoc-Kommentare, Parameterchecks, allgemeine Konsistenzprüfungen Repräsentationsinvariante/Abstraktionsfunktion zugefügt, Update 22.01: es gibt jetzt zwei Varianten: "Vokabel" in strikter Version - Frage und Antwort dürfen nie null/leer sein, "Vokabel" in laxer Version - Frage und Antwort dürfen beide NULL sein, es wird nur im Konstruktor der Vokabelprüfung geprüft, dass keine Vokabel NULL-Werte enthält, Update 29.01.: kleine Anpassungen). Beachtet in diesem Beispiel auch, wie HTML-Elemente zur Formatierung der Texte verwendet werden.

Ein kurze JUnit-Einstieg ist hier (Codebeispiel bezieht sich auf eine frühere Praktikumsaufgabe)


Projektaufgabe 1

Bewertung
Hier gibt es die Bewertung von Abgabe 1. Nach Absprache mit Hr. Igler gibt es keine Nachbesserungsmöglichkeit.
Bitte prüft, dass ich keine falschen Matrikelnummern aufgeschrieben habe, mich bei Punkten nicht verzählt habe und auch sonst keine Fehler gemacht habe.

Präzisierung der Anforderungen:
Bei Assoziationen sollten Namen für beide Enden angebbar sein. Kardinalitäten sind nicht erforderlich.

Abzugeben sind:

Kommunikationsdiagramm

Update 14.1.2014: Hr. Igler hat mir dazu (und zum Status seiner Anfrage an die OMG) geschrieben:
ich habe leider noch keine Rückmeldung. Lassen Sie es uns vielleicht einfach so machen: In den alten UML-Versionen (<=1.4) waren "meine" Pfeilspitzen üblich. Ab 2.0 sind die "einfachen" Pfeilspitzen zumindest erlaubt. In der Klausur werden also beide Varianten erlaubt sein. Können Sie das bitte in Ihren Praktika so mitteilen?

In der Vorlesung hatten die Pfeile eine ausgefüllte Spitze (wie synchrone Nachrichten im Sequenzdiagramm), ich habe sie im Praktikum mit offener Spitze (wie asynchrone Nachrichten im Sequenzdiagramm) gezeigt.

Nach längerem Mailverkehr und Suche in der UML-Spezifikation (http://www.omg.org/spec/UML/2.4.1/) mit Hr. Igler komme ich zu dem Schluss, dass es im Prinzip egal ist, wie die Pfeilspitze aussieht.

Auf Seite 507 (PDF-Seite 523) steht dazu:
On Communication Diagrams, the Messages are decorated by a small arrow in the direction of the Message close to the Message name and sequence number along the line between the lifelines (See Table 14.4 and Figure 14.27).

Mein UML-Buch ("UML glasklar") und das Beispiel in der UML-Spezifikation (Seite 526 - PDF-Seite 542 - Bild 14.27) verwenden die offenen Pfeile.

Es gibt im Kommunikationsdiagramm also keine Unterscheidung zwischen synchron und asynchron, deshalb hat die Pfeilspitze hier eine andere Aussage als im Sequenzdiagramm, sie gibt nämlich nur die Richtung der Nachricht an und könnte mit allem dargestellt werden, was eine Richtung hat.


Aufgabe A.11

Im folgenden ein Versuch eines Sequenzdiagramms, das den allgemeinen Ablauf für die push-Methode darstellt.
Sequenzdiagramm push

Es besteht aus zwei Diagrammen (Logik aus der main-Methode sowie ein zweites, per "ref" eingebundenes Diagramm, das die allgemeine Logik für "push" enthält und mit dem Parameter "42" aus dem Hauptdiagramm heraus aufgerufen wird.
Der Aufruf der "main"-Methode erfolgt sowie der Übergang ins Detail-Sequenzdiagramm, dessen Startmethode "push" und die Exception-Rückgaben sind über "Gates" modelliert (hier in der Variante ohne Benennung).
Die Exceptions werden als Antwort-Nachrichten (Vorschlag Hr. Igler) modelliert.

Nach zu klären ist die Darstellung der static Klasse "UseStack" und die Darstellung der static "main"-Methoden.
Eventuell geht das über einen Stereotyp (letzter Post auf der Seite): http://stackoverflow.com/questions/9108660/how-to-present-static-class-or-function-call-in-sequence-diagram
Um darzustellen, dass es von "UseStack" keine Instanz gibt, könnte man wohl direkt die Klasse eintragen statt eines Objekts.
Alternativ: einfach die Klasse selbst eintragen statt eines Objekts. Dann sollten alle Methodenaufrufe, die auf diese Klasse gehen, static sein.

Erstellt wurde obiges Diagramm mittels "Quick Sequence Diagram Editor" http://sdedit.sourceforge.net, danach habe ich mit einem Malprogramm all die Dinge zugefügt, die das Tool nicht kann (Nachrichten über Gates, Exception-Antworten, "ref"-Einbindung, falscher Pfeil beim Erzeugen, Pfeilspitze bei Rückgaben)


Aufgabe A.9

Im Praktikum kam die Frage auf, wie man im Klassendiagramm den Fall darstellen könnte, dass eine Methode eine "throws"-Deklaration für eine Exception hat.
public int top() throws EmptyStackException
{
}
Das ist ganz einfach: "+top:int {raisedException:EmptyStackException}"
(siehe UML-2.4.1-Spezifikation unter http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF, Kapitel 7.3.37 "Operation")
Allerdings unterstützt nicht jedes UML-Tool dieses Feature.


Aufgabe A.5

Umsetzung einer Assoziation in Code:
Eine Assoziation kann mit Eigenschaften versehen werden, um sie detaillierter zu definieren (siehe http://baruzzo.wordpress.com/2008/11/26/on-cardinalities-in-uml-associations/ ):

Beispiel: 1..6 {bag} (which means “any number between 1 and 6, unordered, possibly with duplicates”)

Jede Assoziation, an der nichts anderes steht, hat die Eigenschaft "set" (unsortiert, keine Duplikate).
Die Java-Umsetzung müsste also über die Klasse "java.util.Set" erfolgen, da diese Duplikate verbietet.


Klassendiagramm: Interface, void, Datentyp einer Assoziation

Interface
Über den Classifier "<<interface>>" wird eine Interface deklariert:
Interface
In ArgoUML wird bei der Implementierungsbeziehung (Interface realization) zusätzlich der Stereotyp "<<realizes>>" eingetragen.

Hinweis: auch wenn "interface" in spitzen Klammern steht, handelt es sich hier ausnahmsweise nicht um einen Stereotype, sondern um einen "Classifier", also ein echtes UML-Modellelement: http://en.wikipedia.org/wiki/Stereotype_%28UML%29


Modellierung des Datentyps einer Assoziation
Um bei einer Assoziation den Datentyp zu deklarieren, kann man sich "Stereotypen" bedienen. Einen Stereotypen kann man sich als "ein Bezeichner, den man auf ein Modellelement anwendet" vorstellen. Es ist also nicht mehr als ein frei wählbarer Text, der zusätzliche Informationen zum Modell enthält. Ein Stereotyp kann auf jedes Element der UML angewendet werden. Er enthält eine Zusatzinformation, die sich aus der Verwendung gibt. Zum Beispiel könnte man Besonderheiten einer konkreten Programmiersprache darin modellieren. Diese Information ist für den Leser des Diagramms relevant, und eventuell steuern sie Tools, die z.B. Quellcode aus einem Klassendiagramm erzeugen.
Mehrere Stereotypen kann man zu einem "Profil" zusammenfassen. Profile sind eine leichtgewichtige Möglichkeit, UML zu erweitern. Ein solches Profil könnte z.B. alle für die Programmiersprache Java relevanten Stereotypen bündeln.

In unserem Beispiel könnte man damit modellieren, dass eine Assoziation den Datentyp java.util.Vector haben soll.
Verwendung von Stereotypen mit ArgoUML: argouml.html

void
Zum Thema "void über Stereotyp modellieren" und allgemein zu Stereotypen schrieb mir Hr. Igler 2012:
Im Prinzip: ja. Dafür braucht man aber keinen Stereotyp, weil es in UML schon ein Ausdrucksmittel für void gibt: "Typ weglassen". (Das ist aber leider nicht eindeutig, da man Typen ja auch einfach so weglassen kann.)

Etwas formaler betrachtet: Es gibt im wesentlichen drei Möglichkeiten, die Sprache UML zu erweitern:
1) Stereotypen: z.B. <<interface>>
2) Properties (sehen aus und wirken im Prinzip wie Einschränkungen: {...}): z.B. {abstract}
3) Meta-Modell verwenden

(1) und (2) setzen auf vorhandenen Modell-Elementen auf. Mit (3) kann man komplett neue Diagrammarten erfinden.

Zu (1) und (2): Es gibt vordefinierte Stereotypen und Properties, z.B.:
1) Stereotypen: z.B. <<interface>>
2) Properties: z.B. {abstract}

Im Prinzip unterscheidet sich die Bedeutung des Einsatzes von Stereotypen von der von Properties. Für unsere Zwecke ist das aber egal, da es für uns vor allem auf eines ankommt: Durch die Angabe von <<vector>> (vorangestellt) oder {vector} (nachgestellt) können wir verbindliche Zusatzangaben für die Implementierung vorsehen. Es muss nur sichergestellt sein, dass selbsterfundene Stereotypen und Properties vor der ersten Verwendung eingeführt und erläutert werden. (Es gibt auch dafür ein eigenes Diagramm, das Profildiagramm. Wir machen es uns aber einfach -- das ist zulässig -- und erklären die Bedeutung in natürlicher Sprache.) Bei ArgoUML gibt es den Datentyp "void", wenn man das Profil "Java" aktiviert.


Aufgabe A.1

Hier ein Link zu einer detaillierten Ariane5-Analyse:
http://userpages.uni-koblenz.de/~beckert/Lehre/Seminar-Softwarefehler/Ausarbeitungen/weyand.pdf

Und zu Therac-25:
http://www5.in.tum.de/lehre/seminare/semsoft/unterlagen_02/therac/website/index.html
Sowie ein nicht ganz so tiefgehender Wikipedia-Artikel:
http://de.wikipedia.org/wiki/Therac-25

Und zum Abschluss ein Artikel über statistische Erhebungen zur Anzahl von Bugs in einer Software: http://swreflections.blogspot.de/2011/08/bugs-and-numbers-how-many-bugs-do-you.html
Am relevantesten ist dieser Abschnitt:
If 85% of bugs are hopefully found and fixed before the code is released, this leaves 0.75 bugs per Function Point (für den Autor bedeutet das ca. 50 Zeilen) unfound (and obviously unfixed) in the code when it gets to production. Which means that for a small application of 1,000 Function Points (50,000 or so lines of Java code), you could expect around 750 defects at release.

Stand 04.03.2014
Historie:
27.10.2013: Erstellt
04.11.2013: Klassendiagramm-Details (Interface, void, Assoziation-Datentyp, raisedException)
12.11.2013: Kommunikations- und Sequenzdiagramm
13.11.2013: Sequenzdiagramm-Feinschliff
04.12.2013: Hinweise zur Projektaufgabe 1
26.12.2013: Bewertung Projektaufgabe 1
14.01.2014: Evaluation, Hinweis "Kommunikationsdiagramm"
17.01.2014: JavaDoc-Einstellungen, JUnit-Beispiel um Kommentare und Repräsentationsinvariante/Abstraktionsfunktion erweitert
22.01.2014: JUnit-Beispiel erweitert, Link zur "JavaDoc erstellen"-Seite
29.01.2014: Hinweise zu Abgabe 3, JUnit-Beispiel angepaßt
06.02.2014: Bewertung Abgabe 2, große Tabelle
01.03.2014: Bewertung Abgabe 3
04.03.2014: Summe für die Gruppe, die keine Abgabe 3 gemacht hatte, aber trotzdem bestanden hatte