Jaka jest różnica między schematem przypadków uwzględnienia i rozszerzenia w użyciu?

Jaka jest różnica między schematem przypadków użyciainclude i extendna nim ?

Rozszerzenie jest używane, gdy przypadek użycia dodaje kroki do innego pierwszego przypadku użycia.

Na przykład wyobraź sobie, że „Wypłata gotówki” jest przykładem użycia bankomatu. „Opłata za naliczenie” wydłużyłaby wypłatę gotówki i opisała warunkowy „punkt przedłużenia”, który jest tworzony, gdy użytkownik bankomatu nie bankuje w instytucji będącej właścicielem bankomatu. Zauważ, że podstawowy przypadek użycia „Wypłata gotówki” jest samodzielny, bez rozszerzenia.

Opcja Uwzględnij służy do wyodrębniania fragmentów przypadków użycia, które są duplikowane w wielu przypadkach użycia. Dołączony przypadek użycia nie może być samodzielny, a oryginalny przypadek użycia nie jest kompletny bez dołączonego. Powinno to być stosowane oszczędnie i tylko w przypadkach, gdy duplikacja jest znacząca i istnieje z założenia (a nie przypadkiem).

Na przykład przepływ zdarzeń, który występuje na początku każdego przypadku użycia bankomatu (kiedy użytkownik wkłada kartę bankomatową, wprowadza kod PIN i wyświetla menu główne) byłby dobrym kandydatem do włączenia.

Może to być kontrowersyjne, ale „obejmuje zawsze, a rozszerzenia czasami” jest bardzo powszechnym nieporozumieniem, które niemal przejęło teraz znaczenie de facto. Oto prawidłowe podejście (moim zdaniem i sprawdzone względem Jacobsona, Fowlera, Larmena i 10 innych referencji).

Relacje są zależnościami

Kluczem do włączenia i rozszerzenia relacji przypadków użycia jest uświadomienie sobie, że wspólna z resztą języka UML kropkowana strzałka między przypadkami użycia jest relacją zależności. Użyję terminów „podstawowy”, „włączony” i „rozszerzający” w odniesieniu do ról przypadków użycia.

zawierać

Podstawowy przypadek użycia zależy od dołączonych przypadków użycia; bez niego podstawowy przypadek użycia jest niekompletny, ponieważ dołączone przypadki użycia reprezentują podsekwencje interakcji, które mogą się zdarzyć zawsze LUB czasami. (Jest to sprzeczne z popularnym nieporozumieniem na ten temat, co sugeruje twój przypadek użycia zawsze dzieje się w głównym scenariuszu, a czasami dzieje się w alternatywnych przepływach, po prostu zależy od tego, co wybierzesz jako główny scenariusz; przypadki użycia można łatwo przekształcić, aby reprezentowały inny przepływ jako główny scenariusz i nie powinno to mieć znaczenia).

W najlepszej praktyce zależności jednokierunkowej podstawowy przypadek użycia wie o dołączonym przypadku użycia (i odnosi się do niego), ale dołączony przypadek użycia nie powinien „wiedzieć” o podstawowym przypadku użycia. Dlatego uwzględnione przypadki użycia mogą być: a) podstawowe przypadki użycia same w sobie i b) współdzielone przez wiele podstawowych przypadków użycia.

poszerzać

Rozszerzony przypadek użycia zależy od podstawowego przypadku użycia; dosłownie rozszerza zachowanie opisane w podstawowym przypadku użycia. Podstawowy przypadek użycia powinien być w pełni funkcjonalnym przypadkiem użytkowania sam w sobie (oczywiście „dołącza się”), bez dodatkowej funkcjonalności rozszerzonego przypadku użycia.

Rozszerzone przypadki użycia można wykorzystać w kilku sytuacjach:

1. Podstawowy przypadek użycia reprezentuje funkcjonalność „must have” projektu, natomiast rozszerzony przypadek użycia reprezentuje zachowanie opcjonalne (powinno / mogłoby / chce). W tym przypadku istotny jest termin opcjonalny - opcjonalny, czy budować / dostarczać, czy opcjonalny, czy czasem działa jako część podstawowej sekwencji przypadków użycia.
2. W fazie 1 możesz dostarczyć podstawowy przypadek użycia, który spełnia wymagania w tym punkcie, a faza 2 doda dodatkową funkcjonalność opisaną w rozszerzonym przypadku użycia. Może zawierać sekwencje, które są zawsze lub czasami wykonywane po dostarczeniu fazy 2 (znowu wbrew popularnemu nieporozumieniu).
3. Można go użyć do wyodrębnienia podsekwencji podstawowego przypadku użycia, szczególnie gdy reprezentują one „wyjątkowe” złożone zachowanie z własnymi alternatywnymi przepływami.

Jednym ważnym aspektem, który należy wziąć pod uwagę, jest to, że rozszerzający się przypadek użycia może „wstawić” zachowanie w kilku miejscach przepływu podstawowego przypadku użycia, a nie tylko w jednym miejscu, jak w przypadku dołączonego przypadku użycia. Z tego powodu jest bardzo mało prawdopodobne, aby przedłużający się przypadek użycia był odpowiedni do rozszerzenia więcej niż jednego podstawowego przypadku użycia.

Jeśli chodzi o zależność, rozszerzający się przypadek użycia jest zależny od podstawowego przypadku użycia i ponownie jest zależnością jednokierunkową, tzn. Podstawowy przypadek użycia nie potrzebuje żadnego odniesienia do rozszerzającego się przypadku użycia w sekwencji. Nie oznacza to, że nie można zademonstrować punktów rozszerzenia ani dodać odwołania x do rozszerzonego przypadku użycia w innym miejscu szablonu, ale podstawowy przypadek użycia musi być w stanie działać bez rozszerzonego przypadku użycia.

PODSUMOWANIE

Mam nadzieję, że pokazałem, że powszechne błędne przekonanie o „włączeniach jest zawsze, przedłużeniach jest czasami” jest albo błędne, albo w najlepszym wypadku uproszczone. Ta wersja ma więcej sensu, jeśli weźmie się pod uwagę wszystkie problemy dotyczące kierunkowości strzałek, jakie przedstawia nieporozumienie - w prawidłowym modelu jest to tylko zależność i potencjalnie nie zmienia się, jeśli zmienimy treść przypadku użycia.

Często używam tego do zapamiętania dwóch:

Mój przypadek użycia: jadę do miasta.

obejmuje -> prowadzić samochód

wydłuża -> uzupełnia benzynę

Opcja „Uzupełnij benzynę” może nie być wymagana przez cały czas, ale opcjonalnie może być wymagana w zależności od ilości benzyny pozostałej w samochodzie. „Jedź samochodem” jest warunkiem wstępnym, dlatego też włączam.

Przypadki użycia służą do dokumentowania zachowania, np. Odpowiedzi na to pytanie.

Zachowanie rozszerza inne, jeśli jest ono dodatkiem do zachowania, ale niekoniecznie jest jego częścią, np. Poszukaj odpowiedzi.

Zauważ też, że badanie odpowiedzi nie ma większego sensu, jeśli nie próbujesz odpowiedzieć na pytanie.

Zachowanie jest uwzględnione w innym, jeśli jest częścią zachowania obejmującego, np. Logowanie do wymiany stosów.

Dla wyjaśnienia, ilustracja jest prawdziwa tylko wtedy, gdy chcesz odpowiedzieć tutaj w przepełnieniu stosu :).

Są to definicje techniczne z UML 2.5 strony 671-672.

Podkreśliłem, co uważam za ważne punkty.

Rozciąga się

Rozszerzenie jest relacją z rozszerzającego się UseCase (rozszerzenie) do rozszerzonego UseCase (ExtendedCase), który określa, jak i kiedy zachowanie zdefiniowane w rozszerzonym UseCase może zostać wstawione do zachowania zdefiniowanego w rozszerzonym UseCase. Rozszerzenie odbywa się w jednym lub kilku określonych punktach rozszerzenia zdefiniowanych w rozszerzonej UseCase.

Rozszerzenia należy używać, gdy istnieje pewne dodatkowe zachowanie, które należy dodać, być może warunkowo , do zachowania zdefiniowanego w jednej lub kilku przypadkach użycia.

Przedłużonym usecase zdefiniowano niezależnie wystającej usecase i ma znaczenie niezależnie wystającej usecase . Z drugiej strony rozszerzenie UseCase zazwyczaj określa zachowanie, które samo w sobie niekoniecznie musi mieć znaczenie . Zamiast tego rozszerzenie UseCase definiuje zestaw modułowych przyrostów zachowania, które zwiększają wykonanie rozszerzonej UseCase w określonych warunkach.

...

Obejmuje

Uwzględnij to DirectedRelationship między dwiema przypadkami użycia, co oznacza, że ​​zachowanie dołączonej UseCase (dodatek) jest wstawione w zachowanie włącznie UseCase (włącznieCase). Jest to także rodzaj NamedElement, dzięki czemu może mieć nazwę w kontekście własnego UseCase (włącznie z CaseCase). Dołączenie UseCase może zależeć od zmian spowodowanych wykonaniem dołączonej UseCase. Dołączona UseCase musi być dostępna, aby zachowanie w tym UseCase zostało całkowicie opisane.

Relacja Uwzględnij jest przeznaczona do użycia, gdy występują wspólne części zachowania dwóch lub więcej przypadków użycia. Ta wspólna część jest następnie wyodrębniana do osobnej skrzynki UseCase, która ma być dołączona do wszystkich podstawowych skrzynek UseCase mających wspólną część . Ponieważ głównym zastosowaniem relacji Uwzględnij jest ponowne użycie części wspólnych, to, co pozostało w podstawowej UseCase, zwykle nie jest kompletne samo w sobie, ale zależy od znaczeń zawartych w nim części. Jest to odzwierciedlone w kierunku relacji, wskazując, że podstawowa UseCase zależy od dodania, ale nie odwrotnie.

...

Myślę, że ważne jest, aby zrozumieć zamiar uwzględnienia i rozszerzenia:

„Relacja uwzględnienia służy do ponownego użycia zachowania modelowanego na podstawie innego przypadku użycia , natomiast relacja rozszerzenia służy do dodawania części do istniejących przypadków użycia, a także do modelowania opcjonalnych usług systemowych” (Overgaard i Palmkvist, Przypadki użycia: wzory i plany. Addison -Wesley, 2004).

To brzmi jak:

Uwzględnij = ponowne wykorzystanie funkcjonalności (tj. Dołączona funkcjonalność jest używana lub mogłaby być wykorzystana gdzie indziej w systemie). Uwzględnij oznacza zatem zależność od innego przypadku użycia.

Rozszerza = dodawanie (nieużywanie) funkcjonalności, a także dowolnych funkcji opcjonalnych . Rozszerza zatem może oznaczać jedną z dwóch rzeczy:
1. dodanie nowych funkcji / możliwości do przypadku użycia (opcjonalne lub nie)
2. dowolne opcjonalne przypadki użycia (istniejące lub nie).

Podsumowanie:
Dołącz = ponowne wykorzystanie funkcjonalności
Rozszerza = nowa i / lub opcjonalna funkcjonalność

Najczęściej znajdziesz drugie użycie (tj. Opcjonalną funkcjonalność) rozszerzeń, ponieważ jeśli funkcjonalność nie jest opcjonalna, to w większości przypadków jest wbudowana w sam przypadek użycia, a nie jest rozszerzeniem. Przynajmniej takie było moje doświadczenie. (Julian C podkreśla, że ​​czasami widzisz pierwsze użycie (tj. Dodanie nowych funkcji) rozszerzeń, gdy projekt wchodzi w drugą fazę).

Ułatwiać,

dla include

1. Gdy wykonywany jest podstawowy przypadek użycia, dołączony przypadek użycia jest wykonywany W KAŻDYM czasie .
2. Podstawowy przypadek użycia wymagał wypełnienia dołączonego przypadku użycia w celu uzupełnienia.

typowy przykład: między logowaniem a weryfikacją hasła

(logowanie) --- << obejmują >> --- > (zweryfikuj hasło)

Aby proces logowania się powiódł, „sprawdź hasło” również musi zakończyć się powodzeniem.

dla extend

1. Gdy wykonywany jest podstawowy przypadek użycia, rozszerzony przypadek użycia jest wykonywany TYLKO CZASAMI
2. Rozszerzony przypadek użycia nastąpi tylko wtedy, gdy zostaną spełnione określone kryteria.

typowy przykład: między logowaniem a wyświetlaniem komunikatu o błędzie (zdarzało się to tylko czasami)

(login) < --- << przedłużyć >> --- (pokaż komunikat o błędzie)

„pokaż komunikat o błędzie” występuje tylko czasami, gdy proces logowania nie powiódł się.

Myślę, że wyjaśnione tutaj msdn są dość łatwe do zrozumienia.

Uwzględnij [5]

Dołączone przypadki użycia wywołują lub wywołują dołączone. Włączenie służy do pokazania, w jaki sposób przypadek użycia dzieli się na mniejsze etapy. Dołączony przypadek użycia znajduje się na końcu grotu strzałki.

Przedłuż [6]

Tymczasem rozszerzony przypadek użycia dodaje cele i kroki do rozszerzonego przypadku użycia. Rozszerzenia działają tylko pod pewnymi warunkami. Rozszerzony przypadek użycia znajduje się na końcu grotu strzałki.

Wyjaśnijmy to. Używamy za includekażdym razem, gdy chcemy wyrazić fakt, że istnienie jednego przypadku zależy od istnienia drugiego.

PRZYKŁADY:

Użytkownik może robić zakupy online tylko po zalogowaniu się na swoim koncie. Innymi słowy, nie może robić żadnych zakupów, dopóki nie zaloguje się na swoje konto.

Użytkownik nie może pobrać z witryny przed przesłaniem materiału. Nie mogę więc pobrać, jeśli nic nie zostało przesłane.

Rozumiesz?

Chodzi o uwarunkowane konsekwencje. Nie mogę tego zrobić, jeśli wcześniej tego nie zrobiłem .

Przynajmniej uważam, że to właściwy sposób, w jaki korzystamy Include. Myślę, że przykład z laptopem i gwarancją z powyższego jest najbardziej przekonujący!

za każdym razem, gdy istnieją przesłanki do użycia, wybierz opcję dołącz.

w przypadkach użycia z uwierzytelnieniem, w najgorszym przypadku lub opcjonalnych, przejdź do rozszerzenia.

przykład: w przypadku zastosowania w celu ubiegania się o przyjęcie, spotkanie, rezerwację biletu MUSISZ WYPEŁNIĆ formularz (formularz rejestracyjny lub formularz zwrotny) ... to tutaj dołącza się ...

przykład: w przypadku użycia weryfikującego login lub logowanie do konta, uwierzytelnienie jest koniecznością. pomyśl również o najgorszych scenariuszach. np. zwrot książki z karą grzywną .. NIE otrzymanie rezerwacji .. opłacenie rachunku PO NALEŻNEJ DATY .. to jest gdzie rozszerza się gra ...

nie nadużywaj włączania i rozszerzania diagramów.

UTRZYMUJ TO PROSTO GŁĘBOKIE !!!

Uważaj również na wersję UML: już dawno << używa >> i << zawiera >> zostały zastąpione << włącz >>, a << rozszerza >> przez << przedłużyć >> ORAZ uogólnienie .
Dla mnie jest to często mylący punkt: na przykład post i link Stephanie dotyczą starej wersji:

Płacąc za przedmiot, możesz wybrać płatność przy odbiorze, zapłacić za pomocą PayPal lub kartą. Są to wszystkie alternatywy dla przypadku użycia „zapłać za przedmiot”. Mogę wybrać dowolną z tych opcji w zależności od moich preferencji.

W rzeczywistości nie ma naprawdę alternatywy dla „zapłacić za przedmiot”! W dzisiejszych czasach UML „płatność przy odbiorze” jest rozszerzeniem, a „płatność za pomocą paypal” / „płatność kartą” to specjalizacje.

„Uwzględnij” służy do rozszerzenia podstawowego przypadku użycia i jest to warunek konieczny, tj. Dołączony przypadek użycia musi działać poprawnie, aby zakończyć podstawowe użycie.

np. rozważ przypadek usługi e-mail, tutaj „Login” to dołączony przypadek użycia, który należy uruchomić, aby wysłać wiadomość e-mail (podstawowy przypadek użycia)

Z drugiej strony „wykluczenie” jest opcjonalnym przypadkiem użycia, który rozszerza podstawowy przypadek użycia, podstawowy przypadek użycia może działać poprawnie nawet bez wywoływania / wywoływania rozszerzonego przypadku użycia.

np. rozważ „Zakup laptopa” jako podstawowy przypadek użycia i „Dodatkowa gwarancja” jako przedłużający się przypadek użytkowania, tutaj możesz uruchomić podstawowy przypadek użytkowania „Zakup laptopa” nawet bez ponoszenia dodatkowej gwarancji.

Jest to świetny zasób z doskonałym wyjaśnieniem: co to jest przypadek użycia w przypadku? Co to jest Extend w przypadku użycia?

Rozszerzenie przypadku użycia zazwyczaj określa zachowanie opcjonalne. Jest niezależny od rozszerzonego przypadku użycia

Uwzględnij używane do wyodrębnienia wspólnych części zachowań dwóch lub więcej przypadków użycia

Elementy diagramu

• Aktorzy: określani również jako Role. Nazwę i stereotyp aktora można zmienić w zakładce Właściwości.

• Dziedziczenie: udoskonalenie relacji między aktorami. Ta relacja może nosić nazwę i stereotyp.

• Przypadki użycia: mogą mieć punkty rozszerzeń.

• Punkty rozszerzenia: określa lokalizację, w której można dodać rozszerzenie.

• Powiązania: między rolami a przypadkami użycia. Przydatne jest nadawanie stowarzyszeniom wymawiających nazwiska.

• Zależności: Między przypadkami użycia. Zależności często mają stereotyp, aby lepiej zdefiniować rolę zależności. Aby wybrać stereotyp, wybierz zależność na diagramie lub w panelu Nawigacja, a następnie zmień stereotyp na karcie Właściwości. Istnieją dwa specjalne rodzaje zależności: <<extend>>i <<include>>dla których Poseidon oferuje własne przyciski (patrz poniżej).

• Rozszerz relację: Jednokierunkowa relacja między dwoma przypadkami użycia. Rozszerzona relacja między przypadkiem użycia B a przypadkiem użycia A oznacza, że ​​zachowanie B można zawrzeć w A.

• Uwzględnij relację: jednokierunkowa relacja między dwoma przypadkami użycia. Taki związek między przypadkami użycia A i B oznacza, że ​​zachowanie B jest zawsze zawarte w A.

• Granica systemu: Granica systemu nie jest w rzeczywistości zaimplementowana jako element modelu w Poseidon dla UML. Możesz po prostu narysować prostokąt, wysłać go w tło i użyć jako obramowania systemu, umieszczając wszystkie odpowiednie przypadki użycia wewnątrz prostokąta.

Zarówno <include>i <extend>są zależne od klasy bazowej, ale<extend> jest opcjonalny czyli to wywodzi się z klasy bazowej, ale w punkcie użytkownikom wyświetlanie może być używany lub nie mogą być wykorzystywane.

<include> jest włączony do klasy podstawowej, tzn. jest obowiązkowy w użyciu <include> w twoim przypadku użycia, w przeciwnym razie uznano by go za niekompletny.

na przykład:

W konstrukcji bankomatów (według punktu widzenia użytkownika):

1: Wypłata, wpłata gotówki i sprawdzenie konta są objęte, <extend>ponieważ od użytkownika zależy, czy dokonać wypłaty, wpłaty czy czeku. Są to opcjonalne czynności wykonywane przez użytkownika.

2: „Wprowadź kod PIN, umieszczenie karty, usunięcie karty” są to rzeczy, które wchodzą, <include>ponieważ użytkownik musi i powinien umieścić kartę i wprowadzić prawidłowy kod PIN do weryfikacji.

Nie polecam używania tego do zapamiętania dwóch:

Mój przypadek użycia: jadę do miasta.

obejmuje -> prowadzić samochód

wydłuża -> uzupełnia benzynę

Wolę, żebyś użył: Mój przypadek użycia: Idę do miasta.

rozszerza -> prowadzenie samochodu

obejmuje -> napełnij benzynę

Nauczono mnie, że przedłużenie relacji kontynuuje zachowanie klasy podstawowej. Muszą tam być funkcje klasy podstawowej. Z drugiej strony relacja dołączania przypomina funkcje, które można wywołać. Maj jest pogrubiony.

Można to zobaczyć po ponownym wykorzystaniu modelu agilemeling w modelach przypadków użycia

Różnica między obiema została wyjaśniona tutaj. Ale nie wyjaśniono, że <<include>>i<<extend>> po prostu nie powinno się z niego w ogóle korzystać.

Jeśli czytasz Bittner / Spence, wiesz, że przypadki użycia dotyczą syntezy, a nie analizy. Ponowne użycie przypadków użycia jest nonsensem. Wyraźnie pokazuje, że niewłaściwie obciąłeś domenę. Wartość dodana musi być unikalna per se. Jedyne ponowne wykorzystanie wartości dodanej, które znam, to franczyza. Więc jeśli prowadzisz burgery, to miło. Ale wszędzie indziej Twoim zadaniem jako BA jest próba znalezienia USP. I to musi być przedstawione w dobrych przypadkach użycia.

Ilekroć widzę ludzi korzystających z jednej z tych relacji, to właśnie wtedy próbują dokonać funkcjonalnego rozkładu. I to po prostu źle.

Mówiąc prościej: jeśli możesz bez wahania odpowiedzieć swojemu szefowi: „Zrobiłem ...”, to „...” jest twoim przykładem użycia, ponieważ masz na to pieniądze. (To również wyjaśni, że „logowanie” wcale nie jest przypadkiem użycia.)

W tym względzie znalezienie samodzielnych przypadków użycia, które są włączone lub rozszerzają inne przypadki użycia, jest bardzo mało prawdopodobne. W końcu możesz użyć, <<extend>>aby pokazać opcjonalność swojego systemu, tj. Niektóre schematy licencyjne, które pozwalają uwzględnić przypadki użycia niektórych licencji lub je pominąć. Ale poza tym - po prostu ich unikaj.

Rozciąga się jest używana, gdy zrozumiesz, że Twój przypadek użycia jest zbyt złożony. Tak więc wyodrębniasz skomplikowane kroki we własnych przypadkach użycia „rozszerzenia”.

Obejmuje to, gdy widzisz wspólne zachowanie w dwóch przypadkach użycia. Tak więc wyodrębniasz typowe zachowanie w osobnym „abstrakcyjnym” przypadku użycia.

(zob. Jeffrey L. Whitten, Lonnie D. Bentley, Analiza systemów i metody projektowania, McGraw-Hill / Irwin, 2007)

The Zawierać związek pozwala przypadek użycia obejmuje etapy innym przypadku użycia.

Załóżmy na przykład, że masz konto Amazon i chcesz sprawdzić zamówienie, no cóż, nie można sprawdzić zamówienia bez uprzedniego zalogowania się na swoje konto. Tak więc przepływ wydarzeń chciałby, aby ...

Rozszerzyć związek jest stosowany, aby dodać dodatkowy krok do przepływu w przypadku użycia, który jest zwykle opcjonalny krok ...

Wyobraź sobie, że wciąż rozmawiamy o twoim koncie Amazon. Załóżmy, że przypadek podstawowy to Zamówienie, a przypadek użycia rozszerzenia to Amazon Prime . Użytkownik może regularnie zamawiać produkt lub może wybrać Amazon Prime, co zapewni, że jego zamówienie dotrze szybciej i będzie droższe.

Pamiętaj jednak, że użytkownik nie musi wybierać Amazon Prime, jest to tylko opcja, może zignorować ten przypadek użycia.

Lubię myśleć, że „obejmuje” jako niezbędny warunek wstępny / towarzyszący podstawowy przypadek użycia. Oznacza to, że podstawowego przypadku użycia nie można uznać za kompletny bez uwzględnionego przypadku użycia. Podam przykład witryny e-commerce, która sprzedaje przedmioty klientom. Nie ma możliwości zapłaty za przedmiot bez uprzedniego wybrania go i umieszczenia w koszyku. Oznacza to, że przypadek użycia „Zapłać za przedmiot” obejmuje „wybierz przedmiot”.

Istnieją różne zastosowania rozszerzeń, ale lubię myśleć o tym jako o alternatywie, która może być używana lub nie. Na przykład - wciąż na stronie e-commerce. Płacąc za przedmiot, możesz wybrać płatność przy odbiorze, zapłacić za pomocą PayPal lub kartą. Są to wszystkie alternatywy dla przypadku użycia „zapłać za przedmiot”. Mogę wybrać dowolną z tych opcji w zależności od moich preferencji.

Aby uzyskać większą przejrzystość i zasady dotyczące przypadków użycia, przeczytaj mój artykuł tutaj:

http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics