| Podstawowa wiedza do stworzenia diagramu przypadków użycia. |
|---|
| Napisane przez Wed 08 Feb 2006 przez Artur (6091 cztane) |
|
Jako wstęp, potraktujmy tresć wcześniejszego artykułu "Krótko o diagramie przypadków użycia", którą również zamieszczam poniżej. \ Diagram przypadków użycia - z początkiem prac powinno się zobrazować oczekiwania użytkownika od tworzonego systemu. To on jest zleceniodawcą i on będzie rozliczał końcowy efekt prac. Język UML, przedstawia sposób, w zasadzie intuicyjny dla każdego. Obrazujemy na diagramie symbole, których interpretacja zawarta jest poniżej.  W tym artykule, w punktach przedstawię meritum wiedzy potrzebnej do stworzenia diagramu przypadków użycia: 1. Przypadek uzycia: - wskazuje tylko co system ma robić (a nie jak ma to robić), - określa o ile to możliwe, nie podzielne zachowanie systemu, - opisuje zbiór ciągów akcji wykonyawanych przez system, - posiada nazwę w formie krótkiego wyrażenia z czasownikiem w trybie rozkazującym na początku. 2. Wyróżnia się związki pomiędzy przypadkami użycia, które zasadniczo wpływają na idee tworzenia diagramów: - - include to zawieranie się jednego przypadku użycia w drugim, stosuje się w celu uniknięcia wielokrotnego opisywania tego samego ciągu zdarzeń, definiujemy w ten sposób wspólne zachowanie w jednym, odrębnym przypadku użycia. Grot przerywanej lini wskazuje na niezalezny przypadek. - extended obrazuje taką zależność pomiędzy przypadkami, gdzie jeden z nich jest postrzegany przez nas jako opcjonalne zachowanie systemu. Rozszerzenie scenariusza o taki przypadek, następuje w ściśle określonych miejscach. Grot strzałki jest skierowany na bazowy przypadek. 3. Ogólnie na diagramach przypadków użycia istnieje konwencja: - przypadki umiescza się w granicy systemu, a aktorów na zewnątrz ganicy, - aktorów inicjujących przypadek po lewej stronie granicy, a aktorów czerpiących korzyści po prawej stronie. |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.