| Tytuł artykułu: |
Podstawowa wiedza do stworzenia diagramu przypadków użycia. |
| Pierwszy wysłał: |
Wed 08 Feb 2006 |
| Opis: |
|
|
Treć artykułu:
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. |
|
|