021
21.03.2005, 12:54 Uhr
ao
(Operator)
|
Dann würde ich spontan folgende UseCases vorschlagen:
Verwaltung der Medien
+ Neues Medium anlegen
+ Medium suchen (nach bestimmten Kriterien)
+ Medien-Info abfragen
+ Medien-Info ändern (falls sinnvoll)
+ Medium löschen
Jede Aktion erfordert bestimmte Benutzerrechte, und das Ändern oder Löschen von Mediendaten verlangt sinnvollerweise eine höhere Berechtigung als das Abfragen von Informationen.
Vermutlich ist es sinnvoll, eine Art "Session" einzuführen, die damit beginnt, dass sich ein Benutzer einloggt. Je nach dem, mit welchen Rechten sein Benutzerkonto ausgestattet ist, stehen ihm dann bestimmte Aktionen zur Verfügung oder auch nicht. Das fällt aber nach meinem Gefühl nicht unter "essential Use Cases", sondern ist Mittel zum Zweck. Für die UseCases reicht es, festzulegen, dass der Benutzer sich ausweisen muss und dass ein Kommando nicht aufgerufen werden kann bzw. fehlschlägt, wenn der Benutzer keine Berechtigung dafür hat.
Wenn es an dieser Stelle zu früh ist, von "Medien" zu sprechen, dann verwende einen abstrakteren Begriff, z.B. "Datensatz". Das glaub ich aber nicht, ein Begriff wie "Datensatz" gehört eher auf die Ebene der dahinterliegenden Datenbank.
Ein weiterer wichtiger UseCase ist möglicherweise die Erweiterbarkeit um andere Medientypen (E-Books, Folienpräsentationen, ...). Wenn das gefordert ist, darfst du nicht auf allen Ebenen fest einbacken, dass das Programm mit Filmen und Musik klarkommt und mit sonst nichts, sondern du musst es variabel halten. Das gilt insbesondere fürs Interface.
Benutzerverwaltung
+ Neuen Benutzer anlegen
+ Benutzer suchen
+ Benutzer-Daten abfragen
+ Benutzer-Daten ändern
+ Benutzer löschen
Alle Benutzerverwaltungs-Aktionen (ausgenommen Abfragen der eigenen Benutzerdaten) erfordern Administrator-Berechtigung.
Die Benutzung durch Menschen *und* durch andere Systeme ist ein wichtiger Essential Use Case. Er besagt nämlich, dass die Medienverwaltung ein vollständig GUI-loses API haben muss, d.h. eine Programmierschnittstelle, die ohne Mausklicks und Eingaben, nur über Funktionsaufrufe, bedienbar sein muss.
Auf diesem API können dann die Client-Programme aufsetzen, und für die humanoiden Mausschubser musst du ein (grafisches) Client-Programm schreiben. Zweckmäßigerweise benutzt das ebenfalls das API.
Das hört sich an, als ob die Sache dadurch irre kompliziert würde, aber eigentlich wird die Welt sogar schöner. Du kannst nämlich auf diesem API Skript-Programme laufen lassen, die dir während der Debug- und Testphase die endlose Klickerei auf dem GUI-Client ersparen. Und du kannst Stress-Tests bauen, die dir zeigen, ob dein Programm auch mit 50 Benutzeranfragen gleichzeitig klarkommt.
Für die Schnittstelle zur dahinterliegenden Datenbank ergeben sich die Usecases aus den oben genannten: Anlegen, Suchen, Abfragen, Ändern, Löschen von Datensätzen. Du könntest auch die Benutzerverwaltung an die DB delegieren.
Gruß, ao |
Schließlich sind wir hier rar 
