Witam serdecznie!
Chciałbym stworzyć stronę http://z1.przeklej.pl/prze1410/ea9ccf9e00190e294d6d2797/przechwytywanie.png Mam diagram jak poniżej:
Nie wiem czy dobrze zaznaczyłem tych userów, chodziło mi że administrator ma takie same uprawnienia co junior admin plus jakieś jeszcze extra(aktualnie na diagramie nie dałem). Nie wiem czy ten system jako aktor jest dobrze, czy w ogóle coś tu jest dobrze, proszę o opinie, bo nie che robić pozostałe by pogłębiać błędy. Dodam że miałem na uczelni przedmiot, po którym powinienem co nieco wiedzieć, jednak jak to bywa teoria jest różna od praktyki. Czytam też książkę UML dla każdego, ale mam wrażenie że jest ona mocno nieaktualna, bo na zajęciach nieco inaczej mi to tłumaczono, szczególnie związki nieco się różnią. Zastanawiam się nad kupnem jakiejś książki, ponadto będę miał przedmiot jeszcze na uczelni związany nieco z UML-em. Na celowniku mam UML 2.0 w akcji i Modelowanie systemów informatycznych w języku UML 2.1 w praktyce. O pierwszej czytałem recenzje że przykład działania lotniska nie jest zbyt precyzyjny, o drugiej niewiele wiem, jeśli ktoś mógłby przy okazji polecić jakąś to byłbym wdzięczny. Szukam książki która będzie miała dużo przykładów.
- Napisałeś, że chcesz stworzyć stronę, która ma służyć do jakichś operacji na plikach. Nie masz ani jednego PU, który pokazywałby te operacje. Z Twojego diagramu wynika, że do systemu możesz się jedynie zalogować i wylogować.
- "chodziło mi że administrator ma takie same uprawnienia co junior admin plus jakieś jeszcze extra"
Zaznaczyłeś, że junior dziedziczy po Administratorze co oznacza, że junior ma wszystkie cechy administratora, ale ma coś jeszcze ekstra (w dużym skrócie). Jest to chyba odwrotność tego co chciałeś. W ogóle nie wiem czy bym na tym diagramie zawierał jakieś dziedziczenie. On ma pokazać interakcję użytkowników z systemem i można każdą rolę narysować jako oddzielnego ludzika nie zaznaczając żadnego dziedziczenia. - co do bazy danych. Jeśli jest to istniejący system, z którego danych skorzystasz (baza zewnętrzna) to powinna być tak zaznaczona. Jednak z tego, że połączyłeś tego aktora asocjacjami ze wszystkimi PU domyślam się, że to baza na potrzeby twojego sytemu, a zatem jest wewnątrz, a nie na zewnątrz i w ogóle bym jej nie zaznaczał tutaj.
- PU powinny być w formie rozkazu dla systemu (taka jest konwencja).
- Co do nauki. Polecam książkę Fowlera "UML w kropelce" jest bardzo konkretna (i ma tylko 170 stron).
Ad 1)Chce stworzyć stronkę, ale nie przedstawiałem jeszcze na diagramie wszystkiego, zrobiłem listę aktorów i przypadków użycia, następnie podzieliłem to na pakiety, zaprezentowany diagram to pakiet rejestracji.
Ad 2)Chodzi o to że administrator może to co junior admin i dodatkowo to czego junior admin nie może(ale namieszałem). Np. Junior admin a więc i administrator będzie mógł dodawać nowe pliki(będzie to na innym diagramie), ale tylko administrator będzie mógł aktywować konto nowo zarejestrowanej osoby. Jak rozumiem jeśli chce to zrobić w opisany sposób to strzałka powinna być w drugą stronę.
Ad 3)Odnośnie bazy to chodziło że przy rejestracji dane są wysyłane do bazy, podczas logowania sprawdzane są dane z tymi z bazy. Chodziło mi się że jest to aktor pomocniczy. Tu chyba będzie wewnętrzna baza w takim przypadku?
Ad 4)Tego nie rozumiem. Uczono mnie na uczelni i z książki, z internetu wyniosłem takie nazewnictwo PU. Napisz jakiś przykład dla zobrazowania jak powinno być poprawnie.
Ad 5)Już miałem kupić tą książkę i zrezygnowałem. To że ma tylko 170 stron to jak dla mnie wada, bo nie można wszystkiego opisać na tylu stronach, skoro w innych podobna treść zajmuje nawet 400 stron. Ale skoro polecasz to się jej przyjrzę, w innym miejscu również widziałem że ktoś ją polecał, więc zła chyba nie jest.
Dziękuję jeszcze raz za odpowiedź i jeszcze bardziej za kolejną :).
Ad 1.
Ok, ale zacznij od pokazania głównych funkcji systemu. To, że logowanie musi być jest w sumie oczywiste, dużo ważniejsze są podstawowe funkcje systemu.
Ad.2.
Dobrym testem na to, czy dziedziczenie jest poprawne zaznaczone jest odpowiedzenie sobie na pytanie czy A "jest" B. W twoim przypadku Czy JuniorAdmin jest Adminem (aby było poprawnie musi być w 100% adminem czyli mieć wszystkie jego cech+coś jeszcze). sprawdź sobie, w którą stronę to działa.
Tak w ogóle nie ma sensu na tym diagramie pokazywać aktora Admin, bo on nic nie robi (nie ma asocjacji z żadnym PU). Pokaż go tam, gdzie to coś wnosi.
Ad. 3.
Myślę, że w tym przypadku baza będzie częścią systemu, więc nie pokazujesz jej na diagramie PU
Ad.4.
Przykłady: Wydrukuj, Zaloguj, Sprawdź uprawnienia. Tak jakby aktor wydawał polecenie systemowi.
Ad.5.
To jest BARDZO dobra książka. Jakości nie mierzy się liczbą stron. Oryginalny tytuł do "UML destiled" i faktycznie autor przedestylował UML pod kątem najważniejszych rzeczy i sposobu ich używania. Oczywiście możesz potem zgłębiać temat i uczyć się dalej, aż skończysz po prostu na specyfikacji UML, która (licząc superstructure i infrastructure) ma jakieś 1000 stron ;) i jest dostępna tutaj.
Mała uwaga. Jeżeli aktor nazywa się "użytkownik" to jaki sens ma zamieszczanie przypadku użycia zaloguj? Skoro jest on już użytkownikiem? Jeżeli już, to powinien być aktor "niezalogowany użytkownik" i on ewentualnie miałby połączenie z przypadkami "zaloguj", "zarejestruj". Ale to tak na marginesie.
gkukawski napisał(a)
Dobrym testem na to, czy dziedziczenie jest poprawne zaznaczone jest odpowiedzenie sobie na pytanie czy A "jest" B. W twoim przypadku Czy JuniorAdmin jest Adminem (aby było poprawnie musi być w 100% adminem czyli mieć wszystkie jego cech+coś jeszcze). sprawdź sobie, w którą stronę to działa.
Tyle że Junior może mieć te same właściwości (pola / metody), ale z inną implementacją. To tak jak dyskusja, czy koło jest elipsą (podejście matematyczne) z równymi promieniami, czy elipsa jest kołem (podejście programistyczne) z drugim promieniem. Jednak use-case'y itp. to dopiero "projekt", więc logika tutaj powinna być zdroworozsądkowa, a nie implementacyjna, dlatego Junior jest Adminem, a nie Admin Juniorem. (na marginesie: OOP suxx ;))