[UML] prosty use case diagram do oceny

Cześć witam,

moglibyście rzucić okiem na diagram przypadków użycia? Nie mam żadnego doświadczenia w uml i czuję, że coś tu jest źle.

Diagram przedstawia panel administracyjny dla właścicieli domków letniskowych.
Jest osobny serwis, w którym prezentowane są domki letniskowe w górach. Użytkownicy mają możliwość przeglądania informacji o tych domkach (zdjęcia, opisy) i rezerwować domek online. Natomiast wspomniany panel jest dla właścicieli domków, którzy mogą obsługiwać rezerwacje składane w serwisie i edytować informacje o swoich obiektach.

Największe wątpliwości mam co do <<include>> i <<extend>>. Z tego co rozumiem <<extend>> używamy gdy jakaś opcja jest ROZSZERZANA przez inną (np. przy 'Odmów rezerwacji' właściciel ma możliwość 'Podaj powód', ale nie musi), a <<include>> opcje, które ZAWSZE są używane (np. opcja 'Edytuj zdjęcia' składa się na opcje 'Zmień zdjęcie główne' <- tu szczególnie mam wątpliwości).

http://img13.imageshack.us/img13/4876/37863539.jpg

Z góry dzięki za szybką pomoc w zrozumieniu tego
Tym bardziej, że do dzisiaj wieczór powinienem oddać ten diagram

Pozdrawiam!

No wlasnie zle masz te include porobione, poniewaz obsluz rezerwacje dolacza dwie przeciwne sobie akcje, a co za tym idzie jest nie jasnosc, zamiast tego ja dalbym extend. Brak tez jest podstawowej akcji dokonaj rejestracji. Dla mnie w ogóle te akcje obsluz rezerwacje powinny wychodzic od systemu. Wlasciciel daje dokonaj rezerwacji, a reszta chyba sie system zajmuje nie ?
To podaj login i haslo tez jest zbedne na takim diagramie, wystarczy samo zaloguj sie, bez zbednych szczegolow, a jak nie wystarczy to daj komentarz i po sprawie.

Co do aktorow, to jesli gosc nie zalogowany ma stac sie wlascicielem to pokaz, ze wlasciciel dziedziczy pewne cechy po gosciu.

Dzięki.

Jeszcze jedno mam pytanie - 'Edytuj obiekt' rozgałęzia się na kilka opcji, m.in. 'Edytuj zdjęcia', 'Edytuj opis'. Właściciel po zalogowaniu do panelu MOŻE obiekt edytować, ale nie musi. Może edytować tylko zdjęcia, tylko opis, zdjęcia i opis, albo nic.
Czy w takim przypadku powinienem zmienić <<include>> na <<extend>> ?

Czy raczej powinienem operacje typu 'Edytuj zdjęcia' bądź 'Edytuj opis' traktować jako składowe operacje 'Edytuj obiekt' i zostawić <<include>> ?

Podsumowując, czy <<include>> odnosi się do użytkownika (MUSI coś zrobić) czy do architektury (operacja edytowania obiektu musi zawierać operację edytowania opisu)?
Z góry wielkie dzięki.

Co do pierwszego pytania to jesli ma byc tak to zmien na extend.
Zle robisz, ze zastanawiasz sie nad tym diagramem w kontekscie klas, ktore maja byc. Diagram przypadkow uzycia ma pokazywac co system oferuje, a nie w jaki sposob oferuje te rzeczy.
Dla mnie w takim prostym diagramie nie powinno byc tylu opcji edycji tylko na przyklad jedna opcja edytuj profil opisana w dokumentacji dokladniej, ale moze ktos ma inne zdanie i sie wypowie.

Masz rację, za dużo szczegółów nawaliłem. Miejscami to był bardziej diagram klas, a przecież przypadki użycia mają służyć przede wszystkim dogadaniu się z klientem na temat funkcjonalności.

Przy okazji, znalazłem rozwiązanie moich wątpliwości w necie. W przypadku, gdy dana operacja jest tylko uszczegółowieniem poprzedniej, nie musimy dawać include ani extend. Wystarczy zwykła strzałka.

Gdyby ktoś był zainteresowany to całość wygląda tak: http://img718.imageshack.us/img718/9569/70362842.jpg