Temat: Diagram przypadków użycia - kto wykonuje przypadek...

Drodzy Grupowicze :)

Nie jestem pewna czy istnieją reguły określające kto wykonuje przypadek rozszerzający na diagramie przypadków użycia? Czy aby to doprecyzować potrzebny jest opis tego przypadku z wymienieniem aktorów?

Dla lepszego zobrazowania dołączam ilustrację: http://www.imgshare.pl/view.php?id=LLH3

W pokazanym przypadku jak określić kto może wykonywać zmianę hasła? Teraz nie jest to dla mnie jednoznaczne czy Użytkownik i Administrator czy może któregoś możemy wykluczyć.

Jak pokazać, że tylko Użytkownik zmienia hasło i tylko Administrator zmienia grupy? Do każdego przypadku pociągnąć powiązania? Nie wpłynie to negatywnie na czytelność przy wielu przypadkach rozszerzających?

Jak Wy sobie z tym radzicie?

Pozdrawiam:)Hanna Wesołowska edytował(a) ten post dnia 29.08.12 o godzinie 15:19

Temat: Diagram przypadków użycia - kto wykonuje przypadek...

Obrazek nie działa:)
Ja łączę Aktorów z wszystkimi PU, z których korzystają. Warto zauważyć, że diagram PU to nie macierz uprawnień.Mateusz Kurleto edytował(a) ten post dnia 02.09.12 o godzinie 15:10

Temat: Diagram przypadków użycia - kto wykonuje przypadek...

Obrazek nie działa:)

Kiedy działał - wszyscy mogli wszystko :)

Ja łączę Aktorów z wszystkimi PU, z których korzystają. Warto zauważyć, że diagram PU to nie macierz uprawnień.

Dlaczego na podstawie diagramów UC nie można stworzyć macierzy uprawnień ?
Prawdę mówiąc, wydawało mi się, że na podstawie UC można stworzyć tylko to.

Temat: Diagram przypadków użycia - kto wykonuje przypadek...

(diagram się nie ładuje)

Przypadki użycia to pokazanie z czego (jakiej usługi systemu) korzysta użytkownik a nie do czego ma prawa. Od uprawnień są "inne mechanizmy".

Prosty przykład: każdy pracownik ma dostęp do usługi "archiwum dokumentów"
- aktor: każdy
- Przypadek Użycia: dodaj/edytuj dokument w repozytorium

A gdzie uprawnienia? Nie tu! Dostęp do konkretnych dokumentów zależy od reguł biznesowych, np. do dokumentów sprawy maje dostęp wyłącznie osoby w nią zaangażowane.

Niem mam pojęcia skąd pomysł by diagram UC traktować jako macierz uprawnień i do czego? Dobrze zaprojektowany system zarządza uprawnieniami do informacji (danych) a nie do narzędzi (opcji).

Include i Extend powstały głównie do "uzewnętrznienia" alternatywnych scenariuszy, ale to tylko jedna z konwencji, np. jeżeli zastosujemy praktykę SRP (Single responsibility principle) współdzielenie jakiegokolwiek kawałka scenariusza "zaczyna" wskazywać na błędy w projektowaniu...