......
> Niedriges Abstraktionsniveau:
> - Verschiedene Diagrammtypen spezifizieren
> (Punktwolken, Linien, Balken)
> - Titel fuer Diagramm spezifizieren
> - Hilfslinien spezifizieren
> - Achsen spezifizieren (Min-Werte, Max-Werte,
> Achsenbeschriftung, Unterteilungsintervall,
> Achsentyp (numerisch/zeitlich))
> - Legende spezifizieren
ja, ich denke das wäre der passende Level für textuelle Use Cases.
Die vollständigkeit können Sie jedoch mit den Use Cases
schecht überprüfen, ob ein Diagrammelement oder Diagrammtyp
vergessen wurde sieht man den Use Cases ja nicht an. Hier würde
ich zur Überprüfung der vollständigkeit dann eher eine vergleichbare
Bibliothek heranziehen.
> Die (Teil)aufgaben werden also immer weiter
> zergliedert bis ein Level zur Implementation
> gegeben ist. Mich verwirrt diese Sichtweise, da
> ich sie aus der SASD (Structured Analysis
> Structured Design) gewohnt bin, hier jedoch
> objektorientiert herangehen will.
Aus meiner Sicht kommen sie um die schrittweise Verfeinerung
auch bei einer OO-Analyse nicht herum, es ist aber nicht eine
verfeinerung der Algorithmen sondern eine Verfeinerung von Objekten, Interfaces, Methoden und Daten.
Use Case Diagramme dienen dabei zur Identifikation von High-Level Objekten und Interfaces, textuelle Use Cases zur prinzipiellen Klärung der Anforderungen , Verfeinerung der Objekte und Identifikation von ersten Methoden und Daten.
> Welchen Einfluss hat der zweite Akteur
> (Programmbenutzer), den Sie vorschlagen auf die
> Funktionalitaet der Diagrammbibliothek. Etwa
> derart: Wenn der Endbenutzer Liniendiagramme
> darstellen moechte, dann sollte die
> Diagrammbibliothek diese anbieten?
Ja, so in die Richtung, allerdings nicht auf die Funktionalität beschränkt (die nutzt ja schon der erste Akteur) sondern auf Qualitäten ausgeweitet. Ich würde dabei Zielorientiert vorgehen
(stichwort: Goal-Oriented Requirements Engineering).
Welche Ziele hat der Endnutzer?
- > Diagrammfunktionalitäten, ein stabil laufendes Programm, sinnvolle Fehlermeldungen, ein stabiles Gesamtsystem
daraus lassen sich Use Cases ableiten die die diese Ziele in bestimmten Situationen "abklopfen.
Beispiel: Use Case " Beim Erzeugen eines großen Diagrammsreicht der Speicher nicht"
Damit kann man sich aus Sicht des Endnutzers sinnvolles Verhalten und sinnvolle Fehlermeldungen vorstellen.
Vorteil hierbei: Die Qualitätssicht lässt sich normalerweise nicht an einzelnen Funktionen festmachen sondern zieht sich durch die ganze Bibliothek, mit Enduser Use Cases kann man dies beispielhaft
zeigen.
Grüße Isabel John
