Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

Witam,

Przeglądając trochę przykładów w sieci z diagramami przypadków użycia pojawiły się u mnie wątpliwości co do rozumienia relacji pomiędzy przypadkami. W związku z tym proszę Was gorąco o odpowiedź na kilka pytań.

1. Załóżmy, że system udostępnia możliwość przeglądania i drukowania dokumentów.
Poniżej są dwie propozycje i każda wydaje mi się dobra:



Na powyższym widać, że aby wydrukować należy wskazać odpowiedni dokument.




Na powyższym widać, że przeglądając dokumenty mamy możliwość wydruku.

Który z tych diagramów jest prawidłowy ?

2. Tutaj przykład znaleziony w sieci. System udostępnia funkcje przeglądania, wyszukiwania i drukowania obiektów.





Z powyższego diagramu wynika, że "Drukuj obiekty" zawsze zawiera "Wyszukaj obiekty" oraz "Przeglądaj obiekty" (który też zawiera "Wyszukaj obiekty". Czy takie podwójne zawieranie "Wyszukaj obiekty" przez "Drukuj obiekty" jest prawidłowe (bezpośrednio oraz pośrednio w "Przeglądaj obiekty")?

W opisie scenariuszy dla przypadku "Drukuj obiekty" jest:

- scenariusz główny który w pierwszy kroku zawiera "Użytkownik przegląda szczegóły wybranego dokumentu [PU Preglądaj obiekt]"

oraz

- scenariusz alternatywny który w pierwszym kroku zawiera "Użytkownik wyszukuje obiekty spełniające kryteria szukania [PU Wyszukaj obiekt]".

Skoro "Wyszukiwanie" jest tutaj w scenariuszu alternatywnym to znaczy że nie występuje zawsze. Czy w takim razie prawidłowe jest tutaj użycie zależności <include> pomiędzy "Drukuj" a "Wyszukaj" ?

3. Poniższy przykład pokazuje, że administrator systemu aukcyjnego ma możliwość zarządzania kontami, zarządzania aukcjami oraz zarządzania kategoriami towarów.




Jeśli zarządzanie serwisem obejmuje tylko takie funkcjonalności to czy nie powinna być tutaj relacja generalizacji/specjalizacji ? Bo jeśli "Zarządzanie kontami", "Zarządzanie aukcjami" oraz "Zarządzanie kategoriami" są opcjonalne to na czym może polegać "Zarządzanie serwisem" jeśli nie wystąpią pozostałe rozszerzenia ?

Poniżej ten sam przypadek z zastosowaniem generalizacji/specjalizacji:


Ten post został edytowany przez Autora dnia 02.10.13 o godzinie 08:10

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

1.Oba prawidłowe.
A. Tu przy wejściu do opcji Przeglądaj zawsze będzie możliwość drukowania. Bo Drukuj dokumenty są bazowym przypadkiem użycia i zawsze ściągają (bo zawierają) Przeglądaj dokumenty.
B.A tu bazowym przypadkiem użycia jest Przeglądaj dokumenty a więc dopiero po spełnieniu jakiegoś warunku (powinien być tu opisany) ściągane jest rozszerzenie Drukuj dokumenty.
2 i 3 Analiza wynika z
z wyjaśnień z .p.1 i zrozumienia co to jest generalizacja. Np. Zarządzaj kontami raz jest uszczegółowionym przypadkiem użycia Zarządzaj serwisem (Zarządzaj kontami zawiera funkcjonalność Zarządzaj serwisem), a wcześniej jego rozszerzeniem uruchamianym po spełnieniu jakiegoś warunku.

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

Oba są złe w kontekście tego co miały by pokazać:

PU połączony <<include>> nie może być kojarzony z aktorem (include to wyłączenie pewnej wspólnej części scenariusza i ma sens wyłącznie gdy dotyczy co najmniej dwóch innych PU).

Związek include to nie "flow" procesu! (aktor decyduje czy zainicjuje wydruk czy nie, a nie System) include nie oznacza "należy"

"Semantics
An include relationship between two use cases means that the behavior defined in the including use case is included in the
behavior of the base use case. The include relationship is intended to be used when there are common parts of the
behavior of two or more use cases. This common part is then extracted to a separate use case, to be included by all the
base use cases having this part in common. Since the primary use of the include relationship is for reuse of common parts,
what is left in a base use case is usually not complete in itself but dependent on the included parts to be meaningful. This
is reflected in the direction of the relationship, indicating that the base use case depends on the addition but not vice
versa."

Extend to obligatoryjna reakcja na spełnienie określonego warunku:

"If the condition of the extension is true at the time the first extension point is reached during the execution of the
extended use case, then all of the appropriate behavior fragments of the extending use case will also be executed. If the
condition is false, the extension does not occur. The individual fragments are executed as the corresponding extension
points of the extending use case are reached. Once a given fragment is completed, execution continues with the behavior
of the extended use case following the extension point. Note that even though there are multiple use cases involved, there
is just a single behavior execution."

Generalnie:

Diagram PU raczej obrazuje menu systemu, ale na pewno nie proces pracy z nim. o kolejności użycia opcji decyduje aktor a nie system. Jeżeli ma to być workflow to nie ten diagram do tego służy.

Stosowanie związków include i extend to relikt UML v.1.1, raczej odradzany bo "ujawnia" wewnętrzną architekturę a to nie jest rola diagramu PU - ten diagram to "czarna skrzynka".

Poważnym błędem większości diagramów przypadków użycia jest próba pokazana na nim "wszystkiego co wiemy".

Co do "diagramu znalezionego w sieci" jest najgorszy bo pokazuje kroki jednego scenariusza ("przeglądaj obiekty" to dla zwykłego usera bełkot a to dla niego jest ten diagram, po drugie samo przeglądanie do niczego nie służy więc nie może być samodzielnym przypadkiem użycia).

Sugeruje przestać używać tych związków, nauczyć się używania BPMN do modelowania procesów i procedur a diagramu klas i komponentów do modelowania architektury i będzie OK :)

więcej znajdziesz tu:
http://it-consulting.pl/autoinstalator/wordpress/2011/...Ten post został edytowany przez Autora dnia 02.10.13 o godzinie 10:55

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

Tak potwierdzam wnioski pana Jarosława Żelińskiego (będę jeszcze analizował szczegółowo :)).
I wartość merytoryczną jego blogu (oczywiście na ile jestem w stanie ocenić po kilku latach czytania):
http://it-consulting.pl/autoinstalator/wordpress/

Za szybko chciałem pomóc, przepraszam. Co nie oznacza, że zrezygnuję. Jak można było sprawdzić w razie potrzeby pojawi się fachowa korekta. :)

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

przy okazji fajny tutorial, jeszcze ciepły :)
http://www.viswiser.com/tricks/how_to_elaborate_use_ca...

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

Też gdzieś czytałem że PU zawarty poprzez include nie powinien być połączony a aktorem ale w kilku materiałach oraz książkach do UML są przykłady gdzie właśnie takie PU jest połączone a aktorem.

Jeśli diagram PU ma pokazać menu systemu to jak pokazać że użytkownik może wyszukać, wydrukować i oglądać dany dokument (zakładam, że system oferuje właśnie takie funkcje) ? Będą trzy autonomiczne PU połączone z aktorem ?

Czy jeśli mamy PU zawarty w jakimś innym to czy kroki tego zawartego PU są wykonywane zawsze przed krokami PU bazowego ?

Jeśli chodzi o poniższy diagram:




to nie pokazuje on poszczególnych kroków scenariusza bo scenariusze dla tych PU opisane są następująco (podaje tylko scnariusze główne):

PU Przeglądaj:
1 Czytelnik wyszukuje obiekty spełniające jego kryteria.
2 Czytelnik wybiera obiekt, który chce przejrzeć.
3 System prezentuje szczegóły wybranego obiektu wraz z jego met danymi.
4 Czytelnik przegląda szczegółu obiektu.

PU Wyszukaj:
1. Czytelnik wybiera opcję wyszukania obiektów.
2. System prezentuje formularz wyszukiwania.
3. Czytelnik podaje kryteria wyszukiwania.
4. Czytelnik zatwierdza wprowadzone kryteria.
5. System wyszukuje obiekty spełniające podane kryteria.
6. System prezentuje wyszukane obiekty wraz z liczbą wszystkich znalezionych obiektów.

PU Drukuj:
1. Czytelnik przegląda szczegóły wybranego dokumentu
2. Czytelnik wybiera opcję wydruku.
3. System prezentuje opcje wydruku dotyczące wybranego obiektu.
4. Czytelnik wybiera odpowiednie opcje drukowania.
5. Czytelnik potwierdza drukowanie.
6. System drukuje wybrane metadane obiektu.
7. System drukuje treści dokumentów.

Na jednym z materiałów szkoleniowych znalazłem taką informacje o "include":

"Wykonanie przypadku włączanego jest obowiązkowe
po dojściu do punktu włączenia. Samo dojście może być natomiast warunkowe (należy wtedy
użyć ciągu alternatywnego)"

Czy to oznacza, że PU zawarty w innym PU może w ogóle nie być wykonywany ?

Chciałbym jeszcze zapytać o następującą rzecz.
Załóżmy że mamy relację include w której jest PU bazowy ze scenariuszem zawierającym kroki A1,A2,A3 oraz PU zawarty z krokami B1,B2,B3. Kiedy wykonywane są kroki B1,B2,B3 ? Przed czy po krokach A1,A2,A3 ?
Analogiczne pytanie dotyczy extend. Jeśli mamy PU bazowy z krokami A1,A2,A3 oraz PU rozszerzający z krokami B1,B2,B3 to czy te kroki są wykonywane po krokach A1,A2,A3 w przypadku spełnienia warunku rozszerzenia ?Ten post został edytowany przez Autora dnia 02.10.13 o godzinie 21:23

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

A czy "przeglądanie obiektów" nie powinno być pomijane podczas tworzenia diagramu PU ? Przeglądanie samo w sobie nie jest funkcją biznesową, projektować i tworzyć system po to, by móc "przeglądać" obiekty mija się z celem.

Oczywiście, dużo zależy od kontekstu, podam dwa przykład: śledzenie przesyłki kurierskiej w serwisie webowym.
Wtedy umieszczanie use case'a pt. "przeglądaj" ma sens, jednak przeglądanie obiektu samo w sobie IMHO nie...

pzdrTen post został edytowany przez Autora dnia 04.10.13 o godzinie 15:43

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

Krzysztof S.:
Też gdzieś czytałem że PU zawarty poprzez include nie powinien być połączony a aktorem ale w kilku materiałach oraz książkach do UML są przykłady gdzie właśnie takie PU jest połączone a aktorem.

niestety śmieci jest w sieci cała masa, w razie wątpliwości sugeruję oryginalne materiały na stronie OMG (http://www.uml.org)

Jeśli diagram PU ma pokazać menu systemu to jak pokazać że użytkownik może wyszukać, wydrukować i oglądać dany dokument (zakładam, że system oferuje właśnie takie funkcje) ? Będą trzy autonomiczne PU połączone z aktorem ?

to elementy scenariuszy a modelu PU

Czy jeśli mamy PU zawarty w jakimś innym to czy kroki tego zawartego PU są wykonywane zawsze przed krokami PU bazowego ?

traktuj <include> jak podprogram

Jeśli chodzi o poniższy diagram:




to nie pokazuje on poszczególnych kroków scenariusza bo scenariusze dla tych PU opisane są następująco (podaje tylko scnariusze główne):

czy którykolwiek z tych trzech PU ma sens sam bez pozostałych?

PU Przeglądaj:
1 Czytelnik wyszukuje obiekty spełniające jego kryteria.
2 Czytelnik wybiera obiekt, który chce przejrzeć.
3 System prezentuje szczegóły wybranego obiektu wraz z jego met danymi.
4 Czytelnik przegląda szczegółu obiektu.

"Przeglądaj" co? powyzej mamy wyszukiwanie, wybieranie, i co jak poogląda?

PU Wyszukaj:
1. Czytelnik wybiera opcję wyszukania obiektów.
2. System prezentuje formularz wyszukiwania.
3. Czytelnik podaje kryteria wyszukiwania.
4. Czytelnik zatwierdza wprowadzone kryteria.
5. System wyszukuje obiekty spełniające podane kryteria.
6. System prezentuje wyszukane obiekty wraz z liczbą wszystkich znalezionych obiektów.

prawodłowa wersja powyższego:
1. Aktor: wybór polecenia wyszukaj
2. System: wyświetla firmularz
3. Aktor: wypełnia formularz i klika OK
4. System: prezentuje wyniki wyszukiwania

i co dalej? Celem aktora było popatrzenie?

Na jednym z materiałów szkoleniowych znalazłem taką informacje o "include":

"Wykonanie przypadku włączanego jest obowiązkowe
po dojściu do punktu włączenia. Samo dojście może być natomiast warunkowe (należy wtedy
użyć ciągu alternatywnego)"

to jakaś herezja, ponownie odsyłam do http://uml.org

Czy to oznacza, że PU zawarty w innym PU może w ogóle nie być wykonywany ?

może, jeżeli jest elementem scenariusza alternatywnego, przypomnę że <include> to odpowiednik podprogramu

Chciałbym jeszcze zapytać o następującą rzecz.
Załóżmy że mamy relację include w której jest PU bazowy ze scenariuszem zawierającym kroki A1,A2,A3 oraz PU zawarty z krokami B1,B2,B3. Kiedy wykonywane są kroki B1,B2,B3 ? Przed czy po krokach A1,A2,A3 ?
Analogiczne pytanie dotyczy extend. Jeśli mamy PU bazowy z krokami A1,A2,A3 oraz PU rozszerzający z krokami B1,B2,B3 to czy te kroki są wykonywane po krokach A1,A2,A3 w przypadku spełnienia warunku rozszerzenia ?

zadam inne pytanie: co chcesz udokumentować tym diagramem?

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

Mam jeszcze pytanie dotyczące include i extend. Widziałem na kilku przykładach w książkach, że PU zawarty w innym występuje tylko na ścieżce alternatywnej, czyli może się on nie wykonać. Jeśli tak to moglibyśmy w tym przypadku połączyć te PU relacją extend. Znaczyłyby wtedy dokładnie to samo ?

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

Krzysztof S.:
Mam jeszcze pytanie dotyczące include i extend. Widziałem na kilku przykładach w książkach, że PU zawarty w innym występuje tylko na ścieżce alternatywnej, czyli może się on nie wykonać. Jeśli tak to moglibyśmy w tym przypadku połączyć te PU relacją extend. Znaczyłyby wtedy dokładnie to samo ?

Nie rozumiem pojęcia "ścieżki alternatywnej" PU w tym kontekście, stereotyp <<include>> jest dokładnie tym samym co "podprogram" w językach programowania.

to, że gdzieś w internecie ktoś coś narysował, nie znaczy, że należy to brać za dobra monetę.

generalnie stosowanie <include>> i <<exclude>> na dzisiaj jest delikatnie mówiąc "złą praktyką".

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

Krzysztof S.:
Jeśli tak to moglibyśmy w tym przypadku połączyć te PU relacją extend. Znaczyłyby wtedy dokładnie to samo ?

aktora można połączyć z PU "excludowanym" ale nie można z "includowanym"

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

A jak wygląda sytuacja z relacją generalizacji przypadków użycia.

Załżmy że mamy coś takiego:





1. Czy Aktor może wykonać sam przypadek A ?
2. Czy Aktor wykonując przypadek B lub C wykonuje zawsze przypadek A (jeśli tak to kiedy).
3. Czy przypadek A jest zawsze abstrakcyjny i Aktor wykonać może tylko B lub C ?

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

Krzysztof S.:
A jak wygląda sytuacja z relacją generalizacji przypadków użycia.

Załżmy że mamy coś takiego:





1. Czy Aktor może wykonać sam przypadek A ?
2. Czy Aktor wykonując przypadek B lub C wykonuje zawsze przypadek A (jeśli tak to kiedy).
3. Czy przypadek A jest zawsze abstrakcyjny i Aktor wykonać może tylko B lub C ?

kolejna niestety "herezja"

w UML pojęcie (używanie związku) dziedziczenia jest dostępne/możliwe dlatego, że od wersji 2.0 cały UML (wszystkie diagramy) są oparte na wspólnym "korzeniu" tej notacji którym jest model pojęciowy (wszystko w UML jest klasą) (UML dokument Infrastructure).

Jako "słownikowe" (pojęciowe) powiązanie może mieć sens to, że "wyszukiwanie książęk" i "wyszukiwanie autorów" dziedziczy po "wyszukiwaniu" ale z perspektywy projektowania przypadków użycia wiedząc, że są to usługi systemu nie ma to żadnego sensu. Podobnie nie ma sensu stosowanie dziedziczenia w modelowaniu dziedziny.

Co do pytań na początku: co do zasady superklasy z zasady są abstrakcyjne (tylko "liście" maja materializację). 9klasyczny antywzorzec OOAP to "wołanie przodka")Ten post został edytowany przez Autora dnia 17.10.13 o godzinie 12:01

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

Niedawno miałem problem z połączeniem aktora z przypadkiem dołączanym na szkoleniu - grupa mnie zakrzyczała mówiąc, że to nieważne lub tłumacząc na przykładach, że to jest możliwe. Odpuściłem, bo nie było czasu na sprawy niezwiązane bezpośrednio z tematem szkolenia. Jestem zdania, że lepiej nie używać tych powiązań bo niczego nie wyjaśniają klientowi, a projektanci tracą czas na uzasadnienie ich użycia.

Temat: Diagram przypadków użycia - problem ze zrozumieniem relacji

Jarosław Ż.:

Krzysztof S.:
Mam jeszcze pytanie dotyczące include i extend. Widziałem na kilku przykładach w książkach, że PU zawarty w innym występuje tylko na ścieżce alternatywnej, czyli może się on nie wykonać. Jeśli tak to moglibyśmy w tym przypadku połączyć te PU relacją extend. Znaczyłyby wtedy dokładnie to samo ?

Nie rozumiem pojęcia "ścieżki alternatywnej" PU w tym kontekście, stereotyp <<include>> jest dokładnie tym samym co "podprogram" w językach programowania.

to, że gdzieś w internecie ktoś coś narysował, nie znaczy, że należy to brać za dobra monetę.

generalnie stosowanie <include>> i <<exclude>> na dzisiaj jest delikatnie mówiąc "złą praktyką".

A tu w moim subiektywnym odczucie typowy antywzorzec jako "wiedza w sieci WWW":
http://www.wiedzanaplus.pl/index.php?option=com_conten...

przypadki użycia udają procesy, nie ma granicy systemu, diagram klas ... ok, ale w projekcie "diagram klas" to albo model pojęciowy albo model struktury kodu (tu chyba autor miał na myśli model dziedziny) a to co zawiera artykuł to jakieś kuriozum typu "anemiczny model dziedziny", zresztą tak nafaszerowany dziedziczeniem, że wyrazy współczucia do kodera i masakry na ORM.Ten post został edytowany przez Autora dnia 21.10.13 o godzinie 09:30