Proszę o skomentowanie tego diagramu i sprawdzeniu czy ma sens :)
Diagram dotyczy biblioteki. Jak widać Czytelnik ma możliwość przeglądania książek, wypożyczenia, oddania oraz zarządzania swoimi danymi (dołączenie do czytelników jeśli jeszcze nim nie jest, edycje danych lub skreślenie siebie z listy czytelników), za pośrednictwem bibliotekarza. Głównie zastanawiam się władnie nad „Zarządzaniem czytelnikami”. Czy jest to prawidłowo rozwiazane?
Wygląda to dobrze tylko groty strzałek masz źle. Np. Oddanie książki -> include -> Autoryzacja, znowu extend strzałki odwrotnie mają być. I to Ponaglenie i kara jakoś tak mi nie pasuje w miejscu gdzie je wrzuciłeś :/
Jednak każdy projekt można zrobić na różne sposoby...
Aj faktycznie. Prawie wszystkie strzałki odwrotnie, niby oczywiste a taki błąd hehe. Dzięki ;)
Co do ponagleń i kar. Jest to opcja wypożyczenia, czyli jeśli zjawi się czytelnik, który nie oddał książek w terminie po wklepaniu jego danych system poinformuje o tym bibliotekarza i nastąpi ten przypadek użycia. Bibliotekarz poinformuje czytelnika, że nie oddał książki i ewentualnie również nałoży mu kare.
i jeszcze jedna wazna sprawa: jesli to ma byc UseCaseDiagram, to, uwaga, KAZDY przypadek uzycia ma styk tylko z JEDNYM aktorem. Aktor na UCD jest strona aktywna, tym ktory inicjuje i dokonuje wyborow. Nawet na prosta logike, kierowca w samochodzie jest tylko jeden :) jesli z danym UC polaczysz dwohc aktorow, to to by oznaczalo, ze ALBO ten ALBO z tej uslugi moze skorzystac. na przyklad:
"Oddanie ksiazki"
masz powiazane z Czytelnik i Bibliotekarz
a teraz na chlodny rozum: KTO wbija do systemu ze ksiazka zostala oddana? Bibliotekarz. Czytelnik jedynie podaje mu ksiazke i dowod osobisty, a to jest akcja poza systemem. System widzi jedynie Bibliotekarza
"Zarzadzanie czytelnikami"
powiazane z Czytelnik i Bibliotekarz
przypadki-dzieci: dodaj, usun, edytuj
edytowac - jasne ze moze swoje dane, ale czy Czytelnik naprawde moze dodawac i usuwac czytelnikow? e-e..
"Przegladanie ksiazek"
tutaj, rzeczywiscie, Czytelnik moze sobie online'owo obejrzec jakie sa ksiazki. Bibliotekarz - nie.ok, dopuszczalne
..ale moznaby sie zastanowic, czy rzeczywiscie Bibliotekarz jako Bibliotekarz nie moze przegladac? mi sie wydaje ze jak Czytelnik chce wypozyczyc cos, to pierwsze co Bibl. robi to .. przejrzenie listy ksiazek i sprawdzenie czy jest wolna! IMHO, tutaj wlasnie jest UC ktory ma powiazania i z Czytelnikiem i z Bibliotekarzem -- bo obaj moga przejrzec liste ksiazek. Ale, z racji ze Bibliotekarz moze na tej "liscie" zrobic wiecej rzeczy, to przypadek "Wypozycz" powinien byc <extends> do przegladania i byc powiazany z Bibliotekarzem.. nie musze chyba tego rysowac?:)
etc.
pamietaj ze UC to nie jest diagram 'dokladny', on pokazuje jakie system daje mozliwosci i kto na nich 'operuje', nie ma on pokazac ze Czytelnik wszedl do budynku, przywital woźną i dopiero wtedy mogł pojść do katalogu i wtedy z karta katalogowa do bibliotekarza, a bibliotekarz ja bierze, sprawdza, wbija do systemu i idzie po ksiazke. UC wypozyczenie brzmi: bibliotekarz odhacza ksiazke jako wypozyczona przez danego Czytelnika. Koniec UC. System komputerowy wiecej nie robi.
Hmmmm w jednej z książek jest napisane: „Aktor inicjuje przypadek i aktor (byś może ten sam, ale niekoniecznie) otrzymuje jakąś wartość przez ten przypadek utworzoną.
Więc tak to ma wyglądać? Celowo rozdzieliłem wyszukiwanie przez czytelnika pracownika biblioteki, ponieważ będę korzystać z różnych interfejsów.
</image>
Jeśli "biblioteka" (nazwa zakresu) oznacza system informatyczny, to quetzalcoatl ma całkowitą rację - na pierwszym diagramie Czytelnik zbyt wiele może ... z jednym wyjątkiem. "Przeglądanie książek" jest świetnym przykładem przypadku użycia, z którego korzystać mogą dwaj aktorzy: Czytelnik i Bibliotekarz. W tej sytuacji proponuję powiedzieć "Bibliotekarz może korzystać ze wszystkich przypadków użycia Czytelnika". Na diagramie wyraża się to dziedziczeniem od Czytelnika do Bibliotekarza.
Czy na diagramie można UC łączyć z więcej niż jednym aktorem ? Ja na to pozwalam, bo jest to (gdy nie można zastosować dziedziczenia) najłatwiejszy sposób na zilustrowanie takich sytuacji jak powyższe "Przeglądanie książek". Przyznaję jednak, że najważniejsze narzędzie UC, czyli tekstowe UC (scenariusze przypadków użycia) w formacie Alistara Cockburna dopuszczają tylko jednego aktora głównego. Cockburn wspomina, że czasami prowadzi to głupich sytuacji, gdzie tworzy się aktora na potrzeby jednego przypadku użycia - "twórca faktur tworzy fakturę" ale jednocześnie wyraźnie zaznacza, że wybór aktora głównego wbrew pozorom nie ma dużego znaczenia dla analizy "Gdy jeden z bystrych studentów zapytał - jak wiele złego stanie się gdy [...] źle ustalimy aktora głównego - odpowiedziałem - Niewiele".
Wiem, że to irytująca odpowiedź ale zalecam ogromną elastyczność w temacie aktora głównego. Jeśli UC będzie miał dwóch aktorów, to nie sądzę aby ktokolwiek nie potrafił tego poprawnie odczytać a jeśli UC będzie miał pominiętego jednego z aktorów, to i tak zbudujemy w pełni funkcjonalny system.
Hmm na pierwszym diagramie rozumiałem to tak, że czytelnik tylko inicjuje przypadek użycia a bibliotekarz „korzysta” z systemu i dlatego aktorów było dwóch bo oboje są uczestnikami UC. Należy, wiec tylko w scenariuszy zapisać, że warunkiem będzie np: dla UC wypożycz książkę - przyjście czytelnika w celu wypożyczenia książki?
Tak juz dobrze? Czy może jeszcze coś dodać? Jeśli bibliotekarz dziedziczy po czytelniku (nie wiem czy dobrze rozumiem, czy strzałkę mam dobrze), ma wszystkie "możliwosci" czytelnika to powiązanie z UC szukania książki nie musi być?
o przegladaniu napisalem dokladnie to samo :) i zgadzam sie, mozna laczyc z wieloma! tez to pisalem
co do:
Jeśli UC będzie miał dwóch aktorów, to nie sądzę aby ktokolwiek nie potrafił tego poprawnie odczytać a jeśli UC będzie miał pominiętego jednego z aktorów, to i tak zbudujemy w pełni funkcjonalny system
to mozna to zle przeczytac bardzo prosto: jesli bedzie UC "XXXXX" polaczone z bibliotekarzem i czytelnikiem, to "typowy ogladacz diagramow" uzna, ze to pokazuje ze czytelnik robi a bibliotekarz bierze w tym udzial.. lub vice versa. co jest bzdura.. taki zapis obrazuje ze czytelnik albo bibliotekarz robia XXXXX.
w kwestii "tworca faktury" - moze i to wyglada glupio, ale jesli rozumiec Aktora troszke inaczej - nabiera sensu. Aktora mozna rozumiec abstrakcyjnie, jako "uprawnienie", albo klasa uprawnien do operacji. I warto pamietac, ze aktorzy moga po sobie dziedziczyc!! to oszdzedza bardzo wielu strzalek na UC.
Np. na aktorzy tego forum jest pieciu: {anonim --> pisaczpostow <-- uzytkownik <-- moderator <--- administrator}
strzalki oznaczaja kierunek dziedziczenia
przykladowe przypadki:
pisaczpostow --> przegladanie, wyszukiwanie, pisanie postow, zakladanie watkow
anonim --> logowanie sie
uzytkownik --> wylogowanie sie, zmiana swoich ustawien, edycja swoich postow, edycja cudzych watkow
moderator --> edycja cudzych postow, edycja cudzych watkow, ukrywanie/odkrywanie postow, przenoszenie watkow (..)
administrator --> (..)
spojrzcie jaka oszczednosc.. nie trzeba od usera, modera i admina robic miliona strzaleki do piszposty,wyloguj,szukaj,przegladaj :)
dzieki 'dziedziczeniu', anonim i uzytkownik moga to pisac posty i tworzyc watki, cool.
ale po co pisacz postow?
czemu uzytkownik nie dziedziczy po anonimie?
-- bo wtedy uzytkownik dostalby powiazanie z "zaloguj", UCkiem typowym dla anonima.. user moglby sie ponownie zalogowac, a to bezsensu lekko
well.. i to chyba wszystko. reszta to juz tylko logika:)