Student uczy się UMLa - projekt

Witam,
od tego semestru na studiach przerabiam przedmiot - Inżynieria Oprogramowania i w ramach laboratorium musimy wykonać ćwiczenia związane z tworzeniem diagramów użycia, klas, aktywności itp.

Materiałów w sieci na temat UMLa jest dość sporo, jednak trudność pojawia się w momencie samodzielnego tworzenia diagramów dla danego projektu.

Dlatego postanowiłem tutaj zasięgnąć porady.

Jako przykład ćwiczebny otrzymałem projekt stworzenia aplikacji bazodanowej wspomagającej pracę wypożyczalni płyt DVD.

Zacząłem od krótkiej dokumentacji i wymagań klienta:

• Ułatwienie utrzymywania wszystkich danych o klientach
• Ułatwienie utrzymywania informacje o filmach dostępnych w wypożyczalni
• Ułatwienie procesu administrowania (wstawiania, edytowania, usuwania) informacjami o filmach, klientach
• System rejestracji dla nowych użytkowników wypożyczalni na stronie internetowej
• System zdalnej rezerwacji filmów z panelu użytkownika na stronie internetowej
• Umożliwienie zdalnego przeglądania zasobów wypożyczalni przez klientów za pomocą przeglądarki WWW
• Monitorowanie stanu wypożyczeń filmów przez klientów
• System przypomnień realizowany przy pomocy poczty email, który ma za zadanie przypominać klientom o terminie zaległych płatności
• System pomocy online
• Umożliwienie klientom zgłaszania nowych propozycji filmowych w celu uzupełnienia zasobów wypożyczalni

Następną czynnością było przygotowanie Diagramu Przypadków Użycia (zadania mamy przydzielane interacyjnie)

Oto moje wypociny:

PS. W książce Język UML 2.0 S.Wrycza,.. czytałem, że nazwy przypadków należy nazywać w trybie rozkazującym, ale w sieci znalazłem wiele przykładów gdzie ta zasada nie obowiązuje - więc jak z tym jest?)

Następnym zadaniem było przygotowanie Diagramu Obiektów, który ma przedstawiać cele tworzonej aplikacji oraz cele organizacji zamawiającej te aplikacje

(tutaj byłem trochę zmieszany bo z tego co zaobserwowałem to diagramy obiektów są omawiane dopiero po diagramach klas (a my tego punktu jeszcze w nie przerabialiśmy) oraz owe diagramy obiektów przedstawiają konkretny moment w działaniu aplikacji, a tutaj jakieś cele...)

Za dużo nie mogłem znaleźć wiadomości na wygląd takiego diagramu i wygląda on tak:

Czekam na porady/sugestie z Waszej strony odnośnie diagramów (co poprawić, co robi się inaczej, itp)

PS2. Wątek ten będę dalej kontynuował, rozszerzając go o następne polecenia które zostaną przede mną postawione.

Tymczasem pozdrawiam,
Michał

PS3. Nie wiem dlaczego fotki się nie wyświetlają, ale na podglądzie są widoczne..

1. Raczej przyjmuje się ze nazwy przypadków są w formie: "Zrób cośtam", np. "Rejestruj klienta"
2. Źle źle źle. Przeczytaj z łaski swojej Pierwszy diagram przypadków użycia i Prosty diagram przypadków użycia ...

• "Przeglądaj panel użytkownika" i "Logowanie" ma strzałke w złą stronę
• Nazwy są zbyt ogólne. Co to znaczy "zarządzaj filmami"?
• złe strzałki w extend (zarządzanie płatnościami to szczególny przypadek wyboru sposobu płatności?), (przypomnienie o opłacie to szczególny przypadek zapłaty opłaty karnej? o_O),
• co to niby jest "propozycja nowego filmu"?

Dzięki za odpowiedź i za wskazówki. Podesłane przez Ciebie linki sprawdzę na dniach (bo zwaliło mi się na głowę nagle inna sprawa).
Będę pisać w niedalekiej przyszłości.

Witam po przewie (dłuższej niż się spodziewałem..).

Dokonałem kilku zmian w Use-Case Diagram, starając się dostosować do wskazówek oraz nowych przemyśleń.

http://oi50.tinypic.com/8z44r4.jpg

P.S. Widziałem, że w poprzednich postach, które mi podałeś do przejrzenia, zwracałeś uwagę na przypadki typu "zarządzanie filmami". Rozumiem, że powinno się to rozbić na przypadek "dodaj film", "usuń film", "modyfikuj film" ale niech tak na razie to pomińmy.

P.P.S. Propozycja nowego filmu to jest możliwość wykonania zgłoszenia przez klienta o uzupełnienie bazy filmów wypożyczalni w dany tytuł filmowy (jeśli aktualnie go brakuje w bazie).

Administrator jest bez sensu skoro nie robi nic więcej niż Pracownik.
Przypomnienie o opłacie karnej jest dziwne dla mnie. Dlaczego niby jest to szczególny przypadek wypożyczenia albo (i?) zwrotu filmu? Dla mnie te przypadki nie są za bardzo powiązane (no może tyle że jak ktoś ma dostać karę to wczesniej musiał wypożyczyć...).
Extendować "zwrot filmu" mogłoby na przykład "zwrot filmu za pomocą poczty".

Ja to rozumiem tak, że jeśli dana osoba chce wypożyczyć kolejny film a nie oddał jeszcze poprzedniego i przekroczył on termin zwrotu, to najpierw musi uiścić opłatę karną aby móc wypożyczyć kolejny film.

Natomiast przy zwrocie danego filmu, jeśli został przekroczony termin to należy uiścić opłatę karną.

Z tym administratorem to rzeczywiście "lekko" bezsensu.. Zastanawiam się, nad takim rozwiązaniem:

http://oi46.tinypic.com/2v0h5lh.jpg

Chodzi o to, że administrator może mieć dostęp do podglądu wszystkich dokonywanych płatności..

Umyka mi czemu uważasz "Zarządzanie płatnościami" za szczególny przypadek "Opłaty za wypożyczenie"...
Może to dlatego że nadajesz takie ogólne nazwy tym przypadkom? Myśl w kategorii konkretnej funkcjonalności z którą przypadek jest powiązany, to raz. Dwa, myśl o tym jak system faktycznie jest używany!
Czy zwrot filmu faktycznie wymaga interakcji uzytkownika z systemem? Czy moze jednak użytkownik przychodzi do wypożyczalny a to pracownik wklepuje informacje o zwrocie do systemu?

OK, jutro pomyślę coś dalej nad nazwami przypadków..

Jednak odnoszą się do twojego ostatniego zdania: "Czy zwrot filmu faktycznie wymaga interakcji uzytkownika z systemem? Czy moze jednak użytkownik przychodzi do wypożyczalny a to pracownik wklepuje informacje o zwrocie do systemu? "

To zakładałem, że to pracownik wklepuje informacje o zwrocie. Jednakże ja robią swój diagram sugerowałem się przykładami dostępnymi w sieci. I tak na przykład na ważniaku był przykład biblioteki:

http://wazniak.mimuw.edu.pl/images/a/a5/Io-5-wyk-Slajd13.PNG

na którym też zapewne zakładano, że zwrot dokonuje pracownik (bibliotekarz)..

P.S. Nazwy też nie są jakieś szczegółowe..

Jak dla mnie tamte nazwy są ok, każda z nich jasno odpisuje funkcjonalność. Ty byś wszystko zamknął tam w "Zarządzanie biblioteką" ;)
Jeśli chodzi o zwrot i użytkownika to musisz zrozumieć że nie ma tutaj rozwiązania dobrego albo złego. Wszystko zależy od tego jak sobie wyobrażasz ten system ;) Zadałem to pytanie właśnie po to żebyś się zastanowił nad tym. Jeśli tak chcesz zrobić faktycznie, że wystąpi tu jakaś interakcja użytkownika i systemu to ok, niech tak będzie. Zwracam tylko uwagę na to żebyś myślał kategoriami "jak system jest tu używany". Zwykle tak jest że system to nie człowiek-orkiestra i nie zajmuje się w firmie wszystkim :)

OK, diagram UC na razie zostawiam w spokoju (aż do weryfikacji przez "instancje wyższą")
Wygląda on tak:

*http:*oi45.tinypic.com/2laylqb.jpg//

Teraz przyszedł czas na diagram klas..
Tutaj dopiero jestem zmieszany :~ Mianowicie najpierw przeczytałem informacje dotyczące tworzenia tych diagramów. Potem obejrzałem kilka przykładów.. Teraz robię swój własny według projektu. Ogólnie odnoszę wrażenie, że te diagramy są jakieś "dziwne" i lepiej przemawiały do mnie diagramy ERD.

Diagram klas na razie wygląda tak:

*http:*oi46.tinypic.com/33mbi9u.jpg//

Starałem się to ująć w logiczną całość, ale nie wiem czy dobrze zostały zastosowane te asocjacje między klasami, oraz same zawartości tych klas..
(proszę o podpowiedzi, sugestie (podanie jak to Wy byście zrobili) | Wiem, że CD stosuje się jeszcze asocjacje częściowe, całkowite.. ale czy trzeba jest tutaj stosować?)

1. Kierwonik? :D
2. Ten diagram klas to jest masakra jakaś. Czy ty kiedykolwiek napisałeś jakiś obiektowy program? Bo odnosze wrażenie że w ogóle nie rozumiesz na czym to polega...

Co ma robić dodaj() w klasie Osoba? Nie widzę żeby ta klasa coś agregowała w sobie. Jeśli chodziło ci o dodanie nowej osoby to NIE JEST TO coś co wykonuje się na rzecz osoby! Musiałbyś mieć klasę ListaUżytkowników i tam mógłbyś mieć taką metodę.
rezerwujFilm() powinno być w klasie Członek a nie w rezerwacji, bo to Członek rezerwuje (tworząc tym samym obiekt Rezerwacja!). Poza tym pomiędzy członkiem a rezerwacjami powinna być agregacja albo nawet kompozycja (chyba to drugie raczej), bo rezerwacji może być więcej. Analogicznie ma sie sprawa w wypożyczeniem - metoda wypożyczFilm() powinna być w klasie Członek i powinna służyć do stworzenia obiektu Wypożyczenie. Znów powinna tu być kompozycja. Ten boolean przekroczony jest bez sensu, skoro masz dwie daty to wystarczy je odjąć od siebie, wiec ta flaga jest zbędna.
Klasa Film znów to samo -> dodawanie, usuwanie etc powinno być w klasie ListaFilmów która przechowuje wszystkie filmy.
Rozumiem że dokonajPłatności() to jest uregulujPłatność()?
Płatności nie powinny być powiązane z kierownikiem, bo przeciez kierowników moze być kilku... Powinna być znów osoba lista Płatności powiązana z Kierownikiem.

Na wstępie kieruje do Ciebie, że w ogóle się interesujesz moim wątkiem (mam nadzieje, że wytrzymasz ze mną do końca :) )

Odnośnie projektowania obiektowego to powiem szczerze, że moja praktyka jest mała w tym temacie, ale jakąś tam styczność miałem z obiektowością i od razu niektóre metody wydawały mi się bezsensu, ale dlaczego tak zrobiłem?

Jako, że czułem się mało doświadczony w tej materii postanowiłem zasugerować się przykładem:

*http:*img4.imageshack.us/img4/8525/class2q.jpg//

(i tutaj między innymi w klasie rezerwuj jest metoda rezerwuj() .. (i więcej tego typu "zagrań"..) )

Poza tym spoglądałem na przykład zaczerpnięty z książki Język UML 2.0:

*http:*oi48.tinypic.com/9sc8r8.jpg//

i tutaj mamy na przykład klasę licytacje a w niej utwórzLicytaje(). To jeżeli iść tym tropem co napisałeś, to metoda utwórzLicytacje() powinna być w klasie Sprzedający, który wystawia tą aukcje.

Czekam na rozjaśnienie tej kwestii (bo może znowu coś mieszam..)

P.S. W sygnaturce powineneś mieć jeszcze numer konta, aby móc dokonać małej wpłaty przynajmniej na piwo, bo za Twoją pomoc zwykłe "dziękuje" to trochę mało ;)

Nie wiem skąd wziąłeś ten przykładowy diagram, ale na moje oko to jest on raczej słaby. Poza tym te metody od biedy mogą być w tych miejscach, ale wtedy oznaczają trochę coś innego.
Jeśli masz metodę dodaj() w klasie Osoba to znaczy że kod będzie wyglądał tak:

Osoba zbyszek = new Osoba();
zbyszek.dodaj();

I ma to sens tylko i wyłącznie wtedy, jeśli Osoba ma powiązanie z listą osób i takie wywołanie dopisze zbyszka do tej listy. Tylko że to jest trochę złamanie zasady jednej odpowiedzialności, bo Osoba nie powinna sie tym zajmować.
utwórzLicytacje() co to innego, bo to może być taka metoda do tworzenia obiektu (zamiast konstruktora).
Metody klas to są operacje które obiekt danej klasy wykonuje i tak należy je traktować.

Pierwszy przykład diagramu był zaczerpnięty tutaj z forum więc nie koniecznie musi być dobry (bo osoba też pytała się o sugestie) ( link: Próba stworzenia diagramu klas)

Natomiast drugi diagram to skan z książki Język UML 2.0 S.Wrycza, B. Marcinkowski

Jutro przerobie poprzedni diagram i wrzuce do omówienia ;)

A więc zrobiłem kolejne podejście do diagramu klas (chciałem to zrobić z rana ale wypadło mi dzisiaj kilka kwestii i teraz z wieczora lekko podmęczony wrzucam posta)

Starałem się zastosować do Twoich wskazówek.

Ostatnio już pisałeś o moich mieszanych uczuciach odnoście tych diagramów. Już wiem dlaczego.. z jednej strony miałem dwa przykłady które zamieściłem wcześniej, z drugiej strony ten przykład:

http://wazniak.mimuw.edu.pl/images/6/6c/Io-5-wyk-Slajd14.PNG

(do którego wcześniej wrzuciłem diagram przypadków użycia)

Tutaj jak dobrze się przypatrzyć widać, że klasa Czytelnik ma w sobie metody rezerwuj() i wypożycz()..

Ok, ale rzućmy okiem na mój CD:

*http:*oi48.tinypic.com/27wynir.jpg//

Komentarz:
Zacznę od agregacji częściowej.. Zdecydowałem się na nią bo według definicji:

*Agregacja częściowa jest silniejszą formą asocjacji. W przypadku tej relacji równowaga między powiązanymi klasami jest zaburzona: istnieje właściciel i obiekt podrzędny, które są ze sobą powiązane czasem swojego życia. Właściciel jednak nie jest wyłącznym właścicielem obiektu podrzędnego, zwykle też nie tworzy i nie usuwa go. *

//Agregacja całkowita (kompozycja) jest najsilniejszą relacją łączącą klasy. Reprezentuje relacje całość-część, w których części są tworzone i zarządzane przez obiekt reprezentujący całość. Ani całość, ani części nie mogą istnieć bez siebie, dlatego czasy ich istnienia są bardzo ściśle ze sobą związane i pokrywają się: w momencie usunięcie obiektu całości obiekty części są również usuwane
(tutaj jako przykład były klasy: książka i tom (tom nie może istniec bez książki a książka bez tomu)//

Natomiast w moim przypadku Członek może istnieć bez wypożyczenia.. (tak to widze..)

Dalszy komentarz..

Wiem, że nie jest on taki jak pisałeś, tzn. nie ma np. klas ListaUżytkowników, ListaFilmów czy ListaPłatności.. , gdyż znowu dopadły mnie wątpliwości i chciałbym to wyjaśnić.

Mianowicie poszukałem trochę w sieci przykładów diagramów klas i udało mi się znaleźć akurat pasujących do mojej tematyki.

I tak,

-na stronie : www.inzynieria.yoyo.pl są zaprezentowane wszystkie diagramy, a diagram klas jest przedstawiony w starym stylu (klasa film zawiera metody dodaj_film() itp)

-potem znalazłem taki diagram: [UML] Wypożyczalnia filmów DVD na stronie [UML] Wypożyczalnia filmów DVD

(diagram również nie zawiera klas "pośrednich" tworzących listy klientów, filmów...)

-natomiast jeszcze znalazłem taki diagram: http://oi49.tinypic.com/mutjya.jpg
i tutaj mamy zastosowane właśnie klasy typu: baza klientów, lista użytkowników..

I jak tu teraz być mądrym ?? :| (osoba posiadająca "wątpliwą" wiedzę (taka jak ja) jest normalnie skołowacona..)
Co doradzisz?

P.S. Z góry przepraszam za jakieś błędy składniowe, itp (bo padam już..)

Różnicy między agregacją a kompozycją nie rozumiesz :P
Agregacja oznacza zwykle ze "coś się zawiera w czymś", na przykład Użytkownik ma listę wypożyczeń, tak jak to zaznaczyłeś na diagramie. Ale kompozycja jest czymś trochę innym. W kompozycji jest tak że mamy obiekt nadrzędny i on zawiera w sobie inne obiekty, ale one są z nim nierozerwalnie związane. Mozemy mieć klasę samochód która składa się z silnika i kół, to jeśli ten silnik i koła są tworzone w trakcie tworzenia samochodu i nie mogą bez niego istnieć to mamy tu kompozycje. Te płatności od biedy pasuja ale...
Na moje oko na ten diagram klas trochę mieszasz z diagramem ERD. Technicznie rzecz biorąc takie rzeczy jak Wypożyczenie albo Płatność powinny leżeć w bazie danych, bo nie bardzo jest sens w czasie działania aplikacji mieć dziesiątki takich obiektów, ale może tak zostać.
Te "listy" nie muszą być osobnymi klasami. Tylko ze gdzieś taka lista i tak będzie musiała być stworzona. Ale oczywiście może być tak że w jakimś main() tego kodu będziesz miał np.

List<Uzytkownik> uzytkownicy = new LinkedList<Uzytkownik>();

i voila, mamy listę użytkowników bez konieczności definiowania takiej klasy.

Dwa ostatnie diagramy wyglądają ok. W tym przedostatnim nie ma klas odpowiedzialnych za agregowanie użytkowników etc, ale przynajmniej metody klas są zrobione poprawnie.

Polecam rzucić okiem na jakąś sensowną publikację dotyczącą OOA & OOD (nie, linki z google nie są dobre, wiele ksiażek też nie, bo często trafisz na takie bzdury jak te które wcześniej pokazałeś ;]).

OK.., dokonam jeszcze kilku zmian i wyślę belferowi do sprawdzenia (zobaczy jakie da wskazówki..).

Co do stwierdzenia - "Na moje oko na ten diagram klas trochę mieszasz z diagramem ERD." - to zapewne masz racje, gdyż d.ERD jakoś lepiej do mnie przemawiają (bardziej lubie bazodanowe podejście..| tam to wygląda trochę inaczej i biorąc stamtąd wzór i próbując to przerobić na klasy UML wychodzą takie kwiatki jak moje..).

Chciałbym się odnieść jeszcze do agregacji i kompozycji. Twój przykład z samochodem jest logiczny, ale chciałbym odnieść się do mojego diagramu..
Mamy sytuacje, że obiekt Członek wypożycza film, czyli niejako konkretna osoba tworzy wypożyczenie (obiekt) konkretnego filmu ; i patrząc na definicjie: "Ani całość, ani części nie mogą istnieć bez siebie, dlatego czasy ich istnienia są bardzo ściśle ze sobą związane i pokrywają się: w momencie usunięcie obiektu całości obiekty części są również usuwane." - jeśli usunięto by obiekt Członek to automatycznie usuwa się jego wypożyczenie (i to jest logiczne (raczej)).. i dlatego musi być zastosowana kompozycja?

P.S. W wolniejszej chwile będę musiał przejrzeć jakąś książke o OOAD (tylko teraz może nie być już czasu..)

Ale członek i wypożyczenie są dość luźno ze sobą powiązane mimo wszystko. Na przykład dlatego że ktoś może odnosić się do Wypożyczeń pomijając Użytkownika (np generując raport). Kompozycje widziałbym pomiędzy Wypożyczeniem i ListąWypożyczeń na przykład.

OK.
(w takim razie czekam i jak otrzymam jaką wiadomość zwrotną od belfra będę pisać :) )
pzdr..

Witam

również jestem na etapie tworzenia diagramu Use Case mam pewien problem z zrozumieniem związku zawierania include, (Stanowi wydzieloną część bazowego przypadku użycia, która jest obowiązkowo wywoływana w procesie realizacji bazowego przypadku użycia) czyli mam rozumiec jezeli jest przypadek uzycia dostepny po logowaniu np.wynajmij samochod to od tego przypadku ma isc strzalka na logowanie ? i we wszystkich przypadkach jezeli jest wymuszone logowanie tak ma byc ? a jezeli jest przypadek rejestracji to logowanie musi zawierac(include) rejestracje ?

moj diagram

http://img441.imageshack.us/img441/1441/usecasediagram1.jpg

Pozdrawiam

1. Nie do końca
2. Nie
3. Diagram to masakra. Przypadki użycia muszą być z czymś powiązane, zwykle z aktorem ew innym przypadkiem. Nie możesz mieć przypadków zawieszonych w próżni. Include rozumiesz źle. Extend rozumiesz źle.

Include znaczy "zawsze musi się wykonać przed tym przypadkiem". Logowanie nie do końca pasuje, bo jak sie zalogujesz to potem wykonujesz inne przypadki bez konieczności logowania się. Gdzie pasuje include? Jeśli na przykład jak robisz przelew w banku i dostajesz hasło jednorazowe smsem. To jest coś co wykonuje się zawsze (zależy od banku, ale chodzi o przykład). U ciebie na przykład zanim się ktoś zaloguje to musi się za każdym razem rejestrować...
Extend znaczy "ten przypadek jest szczególnym przypadkiem tamtego". U ciebie te extendowane przypadki są zbyt ogólne i nic nie mówiące. Co to za przypadek "zarządzanie testami"? Jak sobie wyobrażasz scenariusz takiego przypadku?

Przypadki użycia powinny określać pewną czynność. Nie jest przypadkiem "Test online".

Koledzy tu na pewno dali wiele uwag bardzo przydatnych, mi natomiast rzuciło się w oczy jedno:

*Ułatwienie utrzymywania wszystkich danych o klientach *

Te dwa słowa są nie na miejscu. Ułatwieniem mogłoby być przeniesienie schowka na dyski z danymi bliżej biurka sekretarki.

Podstawowe zdanie przy zbieraniu wymagań:
The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Niestety tym razem to chyba zleceniodawca (wykładowca?) się tu nie popisał.

Jeżeli zawsze ma się wykonać to w takim razie nie może tam występować ani logowanie ani rejestracja i oto mi właśnie chodziło natomiast przypadek typu zarządzaj testami oznacza użycia kontrolki w menu która przeładuje zawartość strony i wyświetli dostępne opcje związane z testami, są to przypadki użycia rozszerzające przypadek zarządzaj testami, żeby wybrać jakąś opcje musi wejść w to menu.

Logowanie ! To najbardziej powszechny błąd. Jest tak powszechny, że nawet niektórzy wykładowcy uważają, że zamieszczenie logowania jest wskazane...... Celem systemu nie jest logowanie samo w sobie. To tylko wypełnienie wymagania niefunkcjonalnego odnośnie bezpieczeństwa systemu.

Słowo o wymaganiach nie-funkcjonalnych. Nie umieszcza się ich na tym diagramie. Aby specyfikacja była kompletna trzeba je dostarczyć w osobnym opisie, na przykład tekstowym typu: system ma być bezpieczny co będzie zrealizowane koniecznością logowania się.

napisał kapustka w podobnym temacie

czyli NIE uwzględniać logowania, czy uwzględnić i dodać komentarz że jest jednorazowo ?

Znaczy "nie pisać o logowaniu" ;]
Te przypadki z extend nadal są po prostu źle. Nie mozesz mieć przypadku "Zarządzanie czymśtam" bo jest zbyt ogólny i kropka. Nie możesz też mieć "Kliknięcie w menu zarządzanie" bo nie jest to ani sensowny przypadek uzycia systemu, ani zwykle nie jest znany interfejs aplikacji w chwili pisania Use Case ;]
Gdzie extend pasuje? Na przykład do takich przypadków:

• Dodaj użytkownika
• Dodaj administratora (co wymaga podania dodatkowych informacji na przykład)
  Albo w takim przypadku:
• Dodaj test
• Dodaj specjalny test
  U ciebie masz kwiatki w stylu "wydruk" jako szczególny przypadek "tworzenia testu" co jest bez sensu.

Diagram wersja druga

http://img215.imageshack.us/img215/1441/usecasediagram1.jpg

I w tym momencie Czy generowanie zapytań do bazy tj. Przegląd moich użytkowników, Przegląd statystyk, jest funkcjonalnością systemu ?

Jednolite nazewnictwo, błagam ;] Raz masz formę osobową, raz bezosobową...
Przypadki użycia dla Admina są zbyt ogólne.
Generowanie zapytań do bazy nie jest przypadkiem użycia systemu, ale przeglądanie statystyk czy raportów jak najbardziej jest. Nie mieszaj 2 poziomów abstrakcji! W czasie tworzenia Use Case NIE WIADOMO w jakim języku to będzie napisane, jak będzie wyglądal interfejs, jaka (i czy w ogóle!) będzie baza danych etc. To jest diagram prezentujący WYMAGANIA dotyczące systemu, nic więcej.

Najpierw dziękuje za opinie

Następnie wypisanie każdej funkcji i opcji tej funkcji kończy się tym że nie mogę tego wszystkiego pomieścic łatwiej było by to pogrupować w bardziej ogólniejszej formie np. zarządzaj użytkownikami i (jeżeli można) związki asocjacji z przypadkami użycia dodaj, usuń, edytuj czy tego typu kwiatuszki :) wchodzą w gre ?

Sugerując sie twoimi radami wersja 3

Administracja została usunięta całkowicie bo nie będzie oddzielnego konta użytkownika administrator oraz interfejsu do zarządzania

1. Nie bardzo, ale za to możesz po prostu zrobić kilka diagramów. Tak się często robi bo jak system jest trochę bardziej skomplikowany to nie pomieścisz wszystkiego na jednym czytelnym diagramie. Możesz więc zrobić diagram "przypadki użycia związane z ..."
2. "usuwa/edytuje" zamieniłbym na 2 przypadki powiązane przez extend. Przypadek główny to "edytuje cośtam" a jego extenduje przypadek "usuwa cośtam".
   Czy "generowanie podglądu" to jest faktycznie przypadek użycia systemu? To jest jedna z jego głównych funkcjonalności?
   "Przegląda wyniki" się powtarza...
   Czy Dydaktyk nie może "dodać grupy" nie dodając klasy? Bo teraz tak to wygląda.
   Tak samo z tym "edytowaniem" i "przeglądaniem". Zresztą jak dla mnie "edytowanie" nie jest szczególnym przypadkiem "przeglądania". Prędzej bym powiedział ze edytowanie wymaga (include) przeglądania.

Poza tym popełniasz jeden z podstawowych błędów: to mają być przypadki UŻYCIA SYSTEMU. Czy system faktycznie jest jakoś używany przy "pobieraniu udostępnionych materiałów"?

Drogi shalom mam nadzieje że tworzyłeś już setki takich diagramów i wiesz co mówisz :)

Tak grupa nie może istnieć sama w sobie musi należeć do klasy

Klasa musi zawierać minimum jedną grupę np. group_all

Przeglądanie wyników nie powtarza się bo Tester przegląda wynik który jest obliczany przez system i prezentowany jemu

Natomiast Dydaktyk i Tester mają dostęp do przeglądania poprzednich wyników , poprzednich testów

wersja final:
http://img717.imageshack.us/img717/1441/usecasediagram1.jpg

Stworzyłem również diagram aktywności opisujący proces tworzenia testu

http://img856.imageshack.us/img856/6161/activitydiagram1.jpg

Powstanie również osobny diagram dla rozwiązania testu przez użytkownika o roli tester

Nie rozumiesz. Teraz jest tak że NIE DA się dodać grupy nie dodając nowej klasy - nie da sie dodać grupy do juz istniejącej klasy, bo "dodawanie grupy" nie jest powiązane z żadnym aktorem.