UML Diagram przypadków użycia ograniczenia dla aktorów

Możecie mi wyjaśnić jak na diagramie przypadków użycia zobrazować cos takiego:
Mam dwóch aktorów GOŚĆ i UŻYTKOWNK ZAREJESTROWANY każdy z nich ma opcję wyszukiwania tematu/książki, ale tylko użytkownik zarejestrowany ma możliwość pobrania pliku DOWNLOAD, więc jak na takim diagramie zaznaczyć to, aby ody dwaj aktorzy mieli funkcję wyszukiwania byli połączeni do funkcji systemu, ale tylko zarejestrowani mieli pełne prawa?

Jakoś się to zaznaczało, ale nie wiem jak. Czy po prostu do rozszerzenia <<extends>> dopisać TYLKO ZAREJESTROWANI?

W ogóle projekty UML muszą odzwierciedlać w pełni rzeczywisty system, czy projekt a implementacja to też duze rozbierzności? Nie jest to projekt komercyjny.

Odpowiedź trochę po czasie ale może pomoże innym osobom szukającym odpowiedzi na podobne pytania.

Po pierwsze groty zakończeń relacji <<extend>> na Twoim diagramie są błędne (masz strzałki od dziedziczenia). Druga sprawa to jeśli dwóch aktorów połączysz z tym samym przypadkiem użycia nie oznacza to, że każdy z osobna może chcieć osiągnąć dany cel, tylko że obaj współpracują w ramach tego przypadku, aby ten cel osiągnąć. Przykład - Wyszukaj temat - połączenie z Gościem i Użytkownikiem zarejestrowanym oznaczałoby, że proces wyszukiwania obejmuje obu aktorów np. Gość podaje kryteria wyszukiwania, Użyt. zar. potwierdza itd.

Teraz propozycje rozwiązania:

1. Pamiętaj, że aktor to rola w systemie i jedna osoba może pełnić różne role w różnych przypadkach użycia. Dlatego Kowalski mógłby raz być Gościem raz Użyt. Zar. Osobna sprawa to czy nazwy aktorów są odpowiednie? Na Twoim diagramie starasz się wyrazić prawa dostępu, nie jest to dobry pomysł. Gdybyś wprowadził aktorów typu Czytelnik i np. Odbiorca plików (trochę głupia nazwa ale nie wiem dokładnie co to za system)?

2. Możesz także wykorzystać dziedziczenie aktorów: twierdząc, że Użytkownik zarejestrowany jest rozszerzeniem Gościa. Jest to dobre rozwiązanie jak długo Gość nie ma żadnego przypadku użycia, który jest dostępny tylko dla niego a nie jest dla Użytkownika Zarejestrowanego. Z dziedziczeniem trzeba się zawsze zastanowić czy ma semantyczny sens.

Jeśli ktoś chciałby dowiedzieć się więcej o diagramach zapraszam na stronę http://www.se.cs.put.poznan.pl/knowledge-base/software-engineering-blog/use-case-diagram umieściłem krótki artykuł o use case diagrams, co prawda po angielsku, ale w najbliższym czasie pojawi się najprawdopodobniej na stronie obszerne opracowanie na temat jak przygotować specyfikację wymagań (w języku polskim)