Mam pytanie - jak powinien wyglądać diagram use case dla forum jesli chce na nim pokazać, że gość może przeglądać forum, użytkownik ponadto zakładać tematy i dodawać posty do tematów, a moderator dodatkowo usuwać tematy i usuwać posty z tematów ?
Screen tego co mam:
http://img686.imageshack.us/img686/2475/beztytuubp.jpg
0
0
Odpowiedź podobna jak w przypadku http://4programmers.net/Forum/viewtopic.php?id=148459.
Można to oczywiście zrobić na kilka sposobów. Ten z dziedziczeniem też jest OK, ale nie jest to do końca potrzebne (radziłbym z praktycznego punktu widzenia omijać dziedziczenie aktorów). Jeśli chcesz pokazać prawa dostępu można to zrobić na kilka sposobów - opisowo w przypadku użycia (jego tekstowej reprezentacji), osobno w specyfikacji wymagań dla całego systemu, albo także poprzez przypadek użycia, ale najlepiej na osobnym diagramie - wtedy przypadki Dodaj ... i Usun wymagały by przypadku zaloguj... i ew. sprawdz uprawnienia (chociaż uważam, że nie zawsze jest to najlepszy pomysł bo może zaciemnić diagram)
Przykład (z ostatnim podejściem do praw):
Wygląda za prosto prawda? Ale mamy tyle fajnych relacji, które można użyć ;) Ogólnie im prościej się da wyrazić tym lepiej. Oczywiście skoro mamy "dynamiczne prawa", należałoby dodać także zarządzanie prawami.
Access control to jeden z wzorców przypadków użycia [1], w przyszłości postaram się je opisać na stronie http://www.se.cs.put.poznan.pl. W chwili obecnej jest już wprowadzenie do przypadków użycia http://www.se.cs.put.poznan.pl/knowledge-base/software-engineering-blog/introduction-to-use-cases oraz wprowadzenie do use case diagrams http://www.se.cs.put.poznan.pl/knowledge-base/software-engineering-blog/use-case-diagram
Literatura
- G. Övergaard and K. Palmkvist. Use cases: patterns and blueprints. Addison-Wesley, 2005.
0
Mirek PUT napisał(a)
radziłbym z praktycznego punktu widzenia omijać dziedziczenie aktorów
Dlaczego?
0
somekind napisał(a)
Dlaczego?
Dziedziczenie jest wtedy uzasadnione kiedy z punktu widzenia semantyki dany aktor jest pewnym specyficznym przypadkiem innego aktora. Czyli np. mamy Administratora i Administratora Użytkowników. Jeśli ten drugi jest specjalizacją pierwszego, czyli możemy powiedzieć, że Admin Użytk. jest także pełnoprawnym Adminem to jest OK, ale w pewnym momencie może się okazać, że jednak nie do końca się pokrywają te role (np. jest jakiś cel który ma Admin a nie ma go Admin Użyt.).
Wyobraź sobie na przykład forum. Możemy powiedzieć, że mamy Autora, Moderatora. Autor miałby PU "Dodaj wpis". Można sobie pomyśleć OK Moderator może także tworzyć wpisy, zatem... niech dziedziczy z Autora? Moderator nie jest specjalnym przypadkiem Autora. Napisanie posta nie jest jego celem! Oczywiście Kowalski, który wciela się najczęściej w rolę Moderatora, może także wcielić się w rolę Autora. Jeśli zapragnie dodać wpis występuje jako Autor (a może także w dwóch rolach -> Autora i Moderatora - jeśli sam sobie zatwierdzi wpis)
Takie błędy pojawiają sie najczęściej jak próbujemy oddać prawa dostępu do systemu a nie role za pomocą aktorów. Często w przypadku różnych portali obserwuję wprowadzanie aktorów Użytkownik anonimowy i Użytkownik zarejestrowany. W praktyce jak zrobimy dziedziczenie to potem często okazuje się, że użytkownik anonimowy ma zupełnie inne możliwości niż zarejestrowany, tzn. użytkownik zarejestrowany nie ma pewnych opcji (celów), które ma użytkownik niezarejestrowany (chociaż 99% się pokrywa).
Czyli relacja dziedziczenia "zadziała", chociaż będzie semantycznie niepoprawna, jeśli z punktu widzenia "praw w systemie", aktor będący specjalizacją będzie posiadał wszystkie "prawa" aktora generalizowanego (np. przykład Moderator -> Autor), wszystko się "wysypie" jak aktorzy co do których wprowadziliśmy relację współdzielą tylko część funkcji.
Nie wiem czy udało mi się wyjaśnić na czym polega problem, bo pewnie trzeba go wyczytać między wierszami albo zostać przez niego zaatakowanym w praktyce ;-)