> Ein Einstieg zu UseCases findet sich hier im
> Portal unter
>
http://www.software-kompetenz.de/?6172
> (Dort unter Anwendungfälle).
> Ich würde die Use Cases sowohl grafisch als
> auch textuell beschreiben.
> Zu den Akteuren:
> Ich sehe bei der Bibliothek zwei Arten von
> Akteuren die beide Use Cases brauchen:
> - Der Bibliotheksbenutzer (Entwickler)
> - Der Programmnutzer (End-User)
>
> Ich denke aber auch, dass nicht der komplette
> Funktionsumfang durch Use Cases abgedeckt sein
> muss, da die Bibliothek ja stark
> algorithmisch geprägt ist, es geht eher darum,
> wie die Bibliothek
> genutzt werden kann von den beiden
> Akteurgruppen (z.B. gibt
> es eine Init Funktion, was passiert bei
> Problemen mit der Bibliothek
> etc)
> Grüße Isabel John
Danke erstmal fuer den Beitrag. Ich muss jedoch nochmal konkreter nachhaken, was die Ausarbeitung einzelner use cases angeht. Ein use case erfasst ja funktionale Anforderungen. Im Falle der Diagrammbibliothek kann ich mir folgende Funktionalitaet fuer den Bibliotheksbenutzer (Entwickler) vorstellen:
Hohe Abstraktionsniveau:
- 2-dimensionale, grafische Darstellung von Datenmengen
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
Kurzum: Der Bibliotheksbenutzer muss in der Lage sein, mit der zu entwickelnden Bibliothek ALLE Diagrammelemente spezifizieren zu koennen. Bilden die use cases diesen Sachverhalt ab? Mich erinnert das an eine funktionale Dekomposition a la top-down:
0. Dekomposition: Diagramm erstellen
1. Dekomposition: Achsen + Hilfslinien + Titel + Datenfolgen erstellen
2. Dekomposition: Min-, Max-Werte der Achsen bestimmen
...
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.
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?
Beste Gruesse,
Andre
