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

377

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

sevugarajan
źródło
Nie zrobiłbym nic lepszego niż Scott Ambler, wyjaśniając, w jaki sposób można je wykorzystać do ponownego użycia w modelach przypadków użycia i jak się różnią. Zamiast więc sparafrazować go, sugerowałbym przeczytać Ponownie użyj w modelach przypadków użycia: „przedłużyć”, „zawierać” i Dziedziczenie .
Pascal Thivent
7
Rzeczywiście, to pytanie dotyczy programowania ...
Pascal Thivent
35
@closers: to jest poprawne pytanie.
Henk Holterman
82
W skrócie -> obejmują = Madatory, przedłużyć = Opcjonalnie
Thein
2
@Megamind 'przedłużyć = Opcjonalne' nie jest do końca prawdą ... Spójrz na ten przykładowy link
Shanaka Jayalath

Odpowiedzi:

262

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.

Doug Knesek
źródło
1
Include is used to extract use case fragments that are duplicated in multiple use cases, co wyodrębnia się w tych krokach puts in their ATM card, enters their PIN, and is shown the main menu:? Dzięki
Blaze Tama
2
Muszę się nie zgodzić na uwzględnienie kroków „logowanie”, które są dobrym kandydatem do włączenia . Kroki te tworzą własne przypadki użycia i powinny być powiązane z innymi przypadkami użycia według warunków wstępnych -> warunków wstępnych.
Bruno Brant,
22
@Bruno - Nikt nie zaloguje się do bankomatu i po prostu odejdzie szczęśliwy. Konkretne przypadki użycia muszą zapewnić aktorowi niezależną wartość, w przeciwnym razie są to tylko funkcje w rozkładzie funkcjonalnym.
Doug Knesek
@Blaze - Wszystkie części procesu logowania, w tym te kroki.
Doug Knesek
1
W jaki sposób Opłata Opłata może być UC? Jest to warunkowy przepływ w scenariuszu. To wcale nie jest wartość dodana. To kompletne przeciwieństwo.
qwerty_so,
113

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.

Julian C.
źródło
3
byłoby wspaniale, gdybyś mógł dodać odniesienia do tego roszczenia
mibollma,
1
Niestety, tworzenie diagramu UML w ten sposób, gdy oprogramowanie przechodzi iteracje, które dodają nowe funkcje, które zawsze były wymagane w stanie końcowym, byłyby niepotrzebnie mylące i złożone. Wolę podejście Douga Kneseka, o wiele prostsze do zrozumienia i pracy, nie powodując przy tym niepotrzebnego zamieszania ani złożoności.
BigMac66
1
Chociaż masz prawo zakwestionować „dołączenia są zawsze, a rozszerzenia są czasami”, ponieważ odnosi się to do przypadków użycia przypadku, twój wybór wykorzystania semantyki „rozszerzenia” do obsługi przyrostowego dostarczania może sprawić, że inni będą myśleć, że „rozszerzanie” jest O dostarczaniu przyrostowym.
Doug Knesek
81

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.

skipy
źródło
Ale „napełnij benzynę” w rzeczywistości oznacza „pójście do miasta”, a nie na odwrót, prawda?
Petr Hudeček
1
Myślę, że to zależy od punktu widzenia Petr. Imho „napełnij benzynę” może faktycznie przedłużyć jazdę samochodem.
Daniel Perník
2
Podróż do miasta i tankowanie benzyny brzmi jak dwie zupełnie niezwiązane ze sobą rzeczy, które mogą się zdarzyć przypadkiem.
OdraEncoded
1
@OdraEncoded jest poprawny. Uzupełnienie benzyny nie zależy od udania się do miasta.
nonybrighto
57

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

odpowiedz na pytanie dotyczące użycia pytania

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.

zbadaj odpowiedź

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

login do wymiany stosu to

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.

...

użytkownik1874524
źródło
23

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ę).

jimasp
źródło
23

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ę.

bohbian
źródło
świetny przykład!
Pavel Durov
15

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.

wprowadź opis zdjęcia tutaj

Etyka
źródło
Powinieneś przynajmniej podać istotę swojej odpowiedzi, a nie tylko dodać link do odpowiedzi. Ponadto wyjaśnienie, do którego się odwołujesz, nie jest ani dobre ani precyzyjne.
Geert Bellekens
Cześć @GeertBellekens, Dodałem trochę szczegółów, aby wyjaśnić różnicę między włączaniem i rozszerzaniem. IMHO sam diagram wyraźnie przekazuje różnicę i do tego właśnie służy diagram.
Etic
Cieszę się, że dodałeś wyjaśnienia, ale nadal uważam, że nie są one zbyt dobre ani precyzyjne. Ludzie (nawet, a zwłaszcza jeśli piszą dla msdn) powinni przestać wymyślać własne definicje czegoś, co jest już zdefiniowane w standardzie.
Geert Bellekens
15

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!

Alin Andrei
źródło
1
O rozszerza?
AlphaGoku
8

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 !!!

Vinay Narang
źródło
6

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.

Sylvain H.
źródło
5

„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.

sarbjit
źródło
może przypadek „dokonywania” płatności służyłby jako „obejmuje” przy zakupie laptopa? Mówię to, ponieważ miło jest mieć przykłady „razem” w tym samym scenariuszu. Ponadto, dokonanie płatności jest czymś, co byłoby wykorzystywane w wielu różnych scenariuszach, więc wydaje się, że może być odpowiednim kandydatem do <<include>>.
baxx 7.04.16
Loginwcale nie jest przypadkiem użycia. Jest to funkcja wykonywana w celu spełnienia warunku wstępnego.
qwerty_so
4

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.

LOURDHU KUMAR
źródło
4

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.

navya reddy maistry
źródło
3

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

Uczeń
źródło
Powinien raczej brzmieć „napełnij benzynę -> wydłuża”, ponieważ twój główny UC nie rozszerza „napełnić benzyną”. Tyle że jesteś firmą benzynową.
qwerty_so 24.04.17
3

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.

qwerty_so
źródło
3

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)

mrmashal
źródło
1
Rozszerzenie nie ma nic wspólnego z przypadkiem użycia, który jest po prostu zbyt skomplikowany. Takie podejście doprowadzi do zbudowania rozkładu funkcjonalnego, a nie rzeczywistego modelu przypadku użycia.
Doug Knesek
1
Myślę, że koncepcje inżynierii oprogramowania i ogólnie wszystko, co zbliża się do nauk humanistycznych, w dużej mierze opiera się na opiniach. Dołączyłem ref (patrz strona 248). Nie bądź dla tego zbyt trudny, stary :)
mrmashal 11.07.16
3

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 ...

wprowadź opis zdjęcia tutaj

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

wprowadź opis zdjęcia tutaj

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.

buydadip
źródło
Jaki powinien Amazon Primebyć przypadek użycia ? Nie zawiera nawet czasownika.
qwerty_so
0

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

Stephanie Famuyide
źródło
1
Witamy w Stack Overflow! Dziękujemy za opublikowanie odpowiedzi! Przeczytaj uważnie FAQ dotyczące autopromocji . Naprawdę niezła odpowiedź; ale pamiętaj o tym, co FAQ mówi o autopromocyjnych postach.
Andrew Barber
Schemat UC na dole linku to tylko anty-wzór. Ani konto, loginani createprzypadki nie są przypadkami użycia. Obie są funkcjami. Dlatego -1
qwerty_so