Temat: Scenariusze w diagramach UML

Jarek Żeliński:
P.S.
zbędne próby złośliwości pominąłem... szkoda mi oczy czytających

Opis rodzajów geometrii, opis zastosowania metody monte carlo, czy też próby powrotu do tematu scenariuszy UML to nie były próby złośliwości z mojej strony.
Jeśli tak to odczytałeś, to bardzo przepraszam.

Temat: Scenariusze w diagramach UML

Jarek Żeliński:

to się nazywa benedyktyńska, dobra, nikomu niepotrzebna praca ;), lubia ją ludzie rozliczani za czas a nie za dzieło.

Ja uważam, że jeśli wdrozono system i działa, to metoda, według której wykonano ten system musi być dobra, bo doprowadziła zespół do celu ...

powyższe przypomina mi: nie ważne czym, łopatą czy łyżeczką, kopano rów, ważne że w końcu wykopano... po drugie nie neguję nigdzie skuteczności tej metody a jedynie nakład pracy...

Podsumujmy więc prędziutko:
1. System można modelować rysując wyłącznie diagramy pomijając wagę opisu.
2. System można modelować bez rysowania diagramów, ale koniecznie ze scenariuszami
3. System można modelować rysując diagramy i wyszczególniać scenariusze

W mojej praktyce stosuję 3 sposób, który obejmuje zarówno 1 jak i 2 sposób.
Stosując zaś wyłącznie 1 sposób dodajemy bardzo dyżo pracy testerom.
Stosując zaś wyłącznie 2 sposób zwiększamy ryzyko budowy niekompletnego systemu.
Stosując zaś 3 sposób ajemy bardzo dobry materiał testerom, a jednocześnie zwiększamy pewność budowy spójnego i kompletnego systemu.

Temat: Scenariusze w diagramach UML

Stanisław Niepostyn:
Podsumujmy więc prędziutko:
1. System można modelować rysując wyłącznie diagramy pomijając wagę opisu.
2. System można modelować bez rysowania diagramów, ale koniecznie ze scenariuszami
3. System można modelować rysując diagramy i wyszczególniać scenariusze

W mojej praktyce stosuję 3 sposób, który obejmuje zarówno 1 jak i 2 sposób.
Stosując zaś wyłącznie 1 sposób dodajemy bardzo dyżo pracy testerom.
Stosując zaś wyłącznie 2 sposób zwiększamy ryzyko budowy niekompletnego systemu.
Stosując zaś 3 sposób ajemy bardzo dobry materiał testerom, a jednocześnie zwiększamy pewność budowy spójnego i kompletnego systemu.

chyba mamy nieporozumienie: co nazywamy scenariuszem?

Jeżeli scenariusz to opis jakiegoś wariantu jakiegoś przepływu to:
- model procesu (diagram, mapa procesu, ...) opisuje zjawisko, liczba możliwych przejść przez model (tu przez graf) może być większa niż jeden, będę to różne możliwe scenariusze obsługujące zdarzenie inicjujące proces (def.: proces to zmiana stanu wejścia w stan wyjścia, jednak może się dokonać na wiele sposobów)
- model sekwencji wymiany komunikatów pomiędzy obiektami realizującymi dany przypadek użycia to jeden scenariusz (przypadek użycia UtwórzFakturęVAT prowadzi do powstania konkretnego typu dokumentu, inny nie ma prawa powstać w poprawnie zaprojektowanym systemie) jest jeden, może on jednak mieć inny, nieoczekiwany koniec i to należy przewidzieć, przy czym przewidzieć należy fakt "możliwości przerwania" tego scenariusza a nie wszystkie możliwe warianty bo to, nawet jeśli możliwe, nie wnosi niczego do rozwiązania problemu o nazwie "system ma wspierać proces wystawiania faktur VAT".

Tak wiec model systemu to tylko diagramy, opis (komentarze itp.) oczywiście mogą go uzupełniać podnosząc zrozumiałość podobnie jak makieta samochodu to tylko deski zaś dołączona dokumentacja poprawia zrozumiałość i dodaje kontekst. Moim zdaniem opracowując system transportu miejskiego wymagam:
- modelu miasta
- modelu autobusu
- wskazanie jednej (kilku) testowych tras do przetestowania systemu

ćwiczenie, nawet na modelach, wszystkich możliwych kombinacji tych przejazdów podniesie pracochłonność a wartość wnoszona przez te ćwiczenia jest znacznie niższa niż ich koszt.

Tak wiec warto chyba zdefiniować sobie samemu pojęcie "scenariusz" by nie dochodziło do nieporozumień. Podobnie, co nazywamy przypadkiem użycia, bo po literaturze plączą się pojęcia przypadków użycia: biznesowy czy systemowy zapewne z wariantami, ja zaś osobiście jestem gorącym zwolennikiem brzytwy Ockhmama, i tezy mówiącej, że "przedmiotem wiedzy nie jest to, co jest indywidualne, lecz to, co jest ogólne."Jarek Żeliński edytował(a) ten post dnia 24.02.11 o godzinie 09:20

Temat: Scenariusze w diagramach UML

Hmm... może od początku:
Pisząc scenariusze mam na myśli realizację konkretnych UC.

miękka granica, bo co to jest dokumentacja funkcjonalna? Jeżeli napiszę, że "system ma pozwalać na tworzenie faktur VAT" to opis szczegółów wypełniania pól to już projekt czy wymagania? Bo dla użytkownika ważna jest w zasadzie faktura jako taka.

Dokumentacja funkcjonalna to wszystko to, co mówi "co" należy zrobić czyli definicja domeny.
Techniczna - wszystko to co mówi "jak" należy to zrobić czyli opis modelu domeny jako systemu informatycznego.

W skrócie - jedno różni się od drugiego jak książka (funkcjonalna) i jej przekład na inny język (techniczny).
Wszystko co jest w orginale ma się znaleźć w przkładzie ale nie na odwrót. Przekład nie powinien dodawać żadnej nowej treści niż ta z której "powstał".
W tym kontekście, odpowiedź na powyższe pytanie jest oczywista - taka informacja powinna się znaleźć w dokumentacji funkcjonalnej. Techniczna - przekształcenie modelu. Funkcjonalna - wyspecyfikowanie modelu.

Także w tym kontekście "dziwne" stają się opisy scenariuszy (przypadków użycia?) pod diagramami np. sekwencji.
To, że ktoś stworzył model domeny (dok. techniczna, diagramy) znaczy tylko tyle, że miał wcześniej tę domenę opisaną (funkcjonalna). Skoro miał opisaną domenę to po co powtarza opis pod jej technicznym modelem ? Do oddania relacji służą odnośniki, indeksy, spisy. Po co umieszczac ogólny opis pod częścią jego konkretyzacji ?
Uważam, że jeśli dokumentacja (jako całość) jest dobra to tego typu "zabiegi ułatwiające analizę" są zbędne. W drugą stronę - jeśli ktoś uznał, że taki opis jest potrzebny to znaczy to tylko tyle, że w dokumentacji panuje chaos i dodanie takiego opisu tylko ten chaos pogłębi... Ale doświadczą tego tylko osoby które będą musiały z nią pracować a nie te, które ją tworzyły (to tak tylko na marginiesie i właściwie do kogoś innego :) ).

Jeszcze inny przykład: kolejnośc tworzenia dokumentacji jest taka:
1.Opis klienta, na jego podstawie powstaje:
2.dokumentacja funkcjonalna, która z kolei służy do opracowania
3.dokumentacja techniczna, która umożliwia napisanie
4.program
Dlaczego „warto” w punkcie 3 powtarzać rzeczy z punktu 2 (przynajmniej teoretycznie) ?

Poza tym diagramy maja dokumentować a nie "powodować zrozumienie".

a jak udokumentować coś bez zrozumienia?

Hm.. bez zrozumienia się nie da. Ale wykorzystać dokumentację – to już tak; wiem bo sam tak robiłem wiele razy :)

P.S.
Można, wystarczy stenografować "user story"....

Na przykład :). Chociaż z takich user story ciężko „wyciągnąć” abstrakcję.

Pozdrawiam.Jakub Wojt edytował(a) ten post dnia 24.02.11 o godzinie 13:59

Temat: Scenariusze w diagramach UML

Jakub Wojt:
Hmm... może od początku:
Pisząc scenariusze mam na myśli realizację konkretnych UC.

miękka granica, bo co to jest dokumentacja funkcjonalna? Jeżeli napiszę, że "system ma pozwalać na tworzenie faktur VAT" to opis szczegółów wypełniania pól to już projekt czy wymagania? Bo dla użytkownika ważna jest w zasadzie faktura jako taka.

Dokumentacja funkcjonalna to wszystko to, co mówi "co" należy zrobić czyli definicja domeny.
Techniczna - wszystko to co mówi "jak" należy to zrobić czyli opis modelu domeny jako systemu informatycznego.

pominięto jak dla mnie jeden etap: opracowanie koncepcji rozwiązania co powinno poprzedzać implementację, koncepcja (w tym opis domeny) nie powinna "tykać" implementacji, więc:

1. wymaganie: system ma wspierać wystawianie faktur VAT
2. koncepcja: należy magazynować dane kontrahentów, dane produktów, mieć zapamiętane dane wystawcy faktur, użytkownik (aktor) inicjuje powstanie nowej faktury, tworzy ją korzystając z magazynowanych w systemie informacji, szczegóły jak powstaje taka faktura i z czego obrazuje diagram sekwencji.
3. implementacja: należy określić jak i zapisać powyższe w wybranym języku programowania.

Także w tym kontekście "dziwne" stają się opisy scenariuszy (przypadków użycia?) pod diagramami np. sekwencji.

opis, a konkretnie komentarz, można umieścić na diagramie lub pod nim, kwestia przyjętej metody...

To, że ktoś stworzył model domeny (dok. techniczna, diagramy) znaczy tylko tyle, że miał wcześniej tę domenę opisaną (funkcjonalna). Skoro miał opisaną domenę to po co powtarza opis pod jej technicznym modelem ?

model to decyzja projektowa (czyli jakiś wybór) czasami warto ją w dokumentacji uzasadnić... prawdą jest, ze dla wykonawcy same modele bez tych komentarzy są nie raz wystarczające

Jeszcze inny przykład: kolejnośc tworzenia dokumentacji jest taka:
1.Opis klienta, na jego podstawie powstaje:
2.dokumentacja funkcjonalna, która z kolei służy do opracowania
3.dokumentacja techniczna, która umożliwia napisanie
4.program
Dlaczego „warto” w punkcie 3 powtarzać rzeczy z punktu 2 (przynajmniej teoretycznie) ?

a moja wersja :):
1. model organizacji klienta
2. cel i zakres projektu
3. wykaz funkcjonalności -> przypadki użycia, model dziedziny
4. opracowanie (zaprojektowanie) koncepcji rozwiązania (modele sekwencje dla każdego UC)
5. wybór technologii i implementacja
każdy model powinien być przetestowany.

Poza tym diagramy maja dokumentować a nie "powodować zrozumienie".

obstawiam jednak na jedno i drugie... autor rozumie bo stworzył, powinien nie tylko przeczytać ale i zrozumieć programista bo implementacja to kolejne uszczegółowienie

a jak udokumentować coś bez zrozumienia?

Hm.. bez zrozumienia się nie da. Ale wykorzystać dokumentację – to już tak; wiem bo sam tak robiłem wiele razy :)

:)))

P.S.
Można, wystarczy stenografować "user story"....

Na przykład :). Chociaż z takich user story ciężko „wyciągnąć” abstrakcję.

są tacy, którzy stale próbują.... :)))

pozdrawiam :)

Temat: Scenariusze w diagramach UML

Pozwolę sobie wrócić do początku tej rozmowy.

Jarek Żeliński:
Jeżeli chodzi o scenariusze przypadków użycia to:
(...)
- nietrywialnych, bazujących na wzorcu nie opisuję, powołuje się na wzorzec, opisują cel aktora (...)

Można prosić o jakiś przykład takiego nietrywialnego, bazującego na wzorcu scenariusza przypadku użycia? Takie podejście wydaje mi się być pokładaniem sporego zaufania w osoby implementujące ten scenariusz...

Jarek Żeliński:
- jeśli nie powyższe dodaje diagram sekwencji dla Modelu Dziedziny z MVC, (V)idoku i (C)ontrolera nie pokazują lub pokazują tylko interfejs.

By zobrazować bardziej złożone przypadki użycia można też posłużyć się diagramem aktywności, w szczególności jeśli korzystamy z narzędzia wspierającego konwersję scenariusza do tegoż diagramu (np. Enterprise Architect - można sobie wygenerować diagram aktywności z ustrukturyzowanej specyfikacji scenariusza przypadku użycia)

Jarek Żeliński:
Przebiegi alternatywne pojawiają się rzadko, staram się by UC miał co najwyżej alternatywne zakończenie w postaci niepowodzenia, to wymaga ustalenia tego co jest przypadkiem użycia.

Zazdroszczę. Rzadkie pojawianie się przebiegów alternatywnych udaje mi się osiągnąć tylko w przypadku bardzo prostych i naprawdę krótkich PU, albo w przypadku upraszczania przez podział (na kilka mniejszych) bardziej złożonych PU, czego jednakże staram się unikać. Jeśli opisuję PU to staram się, by w scenariuszu było możliwie jak najwięcej przebiegów alternatywnych, choćby ze względu na uczynienie go "głupotoodpornym". Doświadczenie nauczyło mnie, że jeśli w ramach realizacji scenariusza podstawowego istnieje choćby niewielka możliwość, by obrać inną, nie opisaną jako alternatywa drogę, to prędzej czy później zostanie ona obrana (w najgorszym wypadku dopiero przez użytkownika końcowego) i najprawdopodobniej nie będzie zaimplementowana żadna jej obsługa :-)Jakub Płachecki edytował(a) ten post dnia 24.02.11 o godzinie 20:45

Temat: Scenariusze w diagramach UML

Jakub Płachecki:jednakże staram się unikać. Jeśli opisuję PU to staram się, by w scenariuszu było możliwie jak najwięcej przebiegów alternatywnych, choćby ze względu na uczynienie go "głupotoodpornym". Doświadczenie nauczyło mnie, że jeśli w ramach realizacji scenariusza podstawowego istnieje choćby niewielka możliwość, by obrać inną, nie opisaną jako alternatywa drogę, to prędzej czy później zostanie ona obrana (w najgorszym wypadku dopiero przez użytkownika końcowego) i najprawdopodobniej nie będzie zaimplementowana żadna jej obsługa :-)Jakub Płachecki edytował(a) ten post dnia 24.02.11 o godzinie 20:45

Jeśli przyjąć,że PU to ciąg interakcji z aktor-system realizujący konkretny pojedynczy cel, a Twoim podejściem jest stworzyć jak najwięcej przebiegów alternatywnych, to czy zarazem nie komplikujesz życia użytkownikom?
Z mojego doświadczenia im prostszy scenariusz tym lepiej,bo oznacza to, że tym prościej użytkownik może zrealizować swój cel.

Temat: Scenariusze w diagramach UML

Scenariusz podstawowy - jak najbardziej, im prostszy, tym lepszy. Co nie zmienia faktu, że przebiegi alternatywne powinny zostać opisane, jeśli w podstawowym istnieje jakaś "furtka".

Scenariusze alternatywne mają opisać drogę inną, niż podstawowy - nie wiem w jaki sposób miałyby one komplikować cokolwiek użytkownikom :-)

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
Scenariusz podstawowy - jak najbardziej, im prostszy, tym lepszy. Co nie zmienia faktu, że przebiegi alternatywne powinny zostać opisane, jeśli w podstawowym istnieje jakaś "furtka".

Scenariusze alternatywne mają opisać drogę inną, niż podstawowy - nie wiem w jaki sposób miałyby one komplikować cokolwiek użytkownikom :-)

Jest jedną ze skutecznych metryk jakościowych liczyć na ile sposobów można wykonać to samo. Im mniej - tym lepiej.
Zgodnie z tą koncepcją istnienie scenariusza alternatywnego jest w pewnym sensie porażką.

Temat: Scenariusze w diagramach UML

Oj oj, obawiam się, że scenariusz alternatywny nie służy "wykonaniu tego samego". Proponuję odświeżyć nieco UML ;-)

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
Pozwolę sobie wrócić do początku tej rozmowy.

Jarek Żeliński:
Jeżeli chodzi o scenariusze przypadków użycia to:
(...)
- nietrywialnych, bazujących na wzorcu nie opisuję, powołuje się na wzorzec, opisują cel aktora (...)

Można prosić o jakiś przykład takiego nietrywialnego, bazującego na wzorcu scenariusza przypadku użycia? Takie podejście wydaje mi się być pokładaniem sporego zaufania w osoby implementujące ten scenariusz...

np. jeżeli są to systemy obiegu dokumentów i przypadek użycia "obsługa zdarzenia/etapu pracy" wskazuje często na wzorzec "state machine" opisujący model sprawy, etapu i kontaktu.

Jarek Żeliński:
- jeśli nie powyższe dodaje diagram sekwencji dla Modelu Dziedziny z MVC, (V)idoku i (C)ontrolera nie pokazują lub pokazują tylko interfejs.

By zobrazować bardziej złożone przypadki użycia można też posłużyć się diagramem aktywności, w szczególności jeśli korzystamy z narzędzia wspierającego konwersję scenariusza do tegoż diagramu (np. Enterprise Architect - można sobie wygenerować diagram aktywności z ustrukturyzowanej specyfikacji scenariusza przypadku użycia)

VP także generuje, osobiście preferuję diagram sekwencji bo pokazuje jakie klasy biorą udział w scenariuszu i jakich metod używają....

Jarek Żeliński:
Przebiegi alternatywne pojawiają się rzadko, staram się by UC miał co najwyżej alternatywne zakończenie w postaci niepowodzenia, to wymaga ustalenia tego co jest przypadkiem użycia.

Zazdroszczę. Rzadkie pojawianie się przebiegów alternatywnych udaje mi się osiągnąć tylko w przypadku bardzo prostych i naprawdę krótkich PU, albo w przypadku upraszczania przez podział (na kilka mniejszych) bardziej złożonych PU, czego jednakże staram się unikać. Jeśli opisuję PU to staram się, by w scenariuszu było możliwie jak najwięcej przebiegów alternatywnych, choćby ze względu na uczynienie go "głupotoodpornym".

być może kwestia podejścia: raz - definicja UC, dwa pozostawiam użytkownikowi pewną swobodę w obsłudze wyjątków. Jestem typem, który nie algorytmizuje pracy ludzi.

Doświadczenie nauczyło mnie, że jeśli w ramach realizacji scenariusza podstawowego istnieje choćby niewielka możliwość, by obrać inną, nie opisaną jako alternatywa drogę, to prędzej czy później zostanie ona obrana (w najgorszym wypadku dopiero przez użytkownika końcowego) i najprawdopodobniej nie będzie zaimplementowana żadna jej obsługa :-)

Doświadczenie potwierdzam, ale ja stosuje metodę która nazwałem 404 :): projektuje "stan" w którym jak coś się wysypie to pojawia się ekran, gdzie użytkownik sam decyduje co zrobi, zawsze może zaniechać i zacząć jeszcze raz....

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
Scenariusz podstawowy - jak najbardziej, im prostszy, tym lepszy. Co nie zmienia faktu, że przebiegi alternatywne powinny zostać opisane, jeśli w podstawowym istnieje jakaś "furtka".

ja strosuję zasady, że "opisane" a nie "obsłużone"...Jarek Żeliński edytował(a) ten post dnia 24.02.11 o godzinie 21:47

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
Oj oj, obawiam się, że scenariusz alternatywny nie służy "wykonaniu tego samego". Proponuję odświeżyć nieco UML ;-)

UML to nie metoda projektowania a dokumentowania projektu...;) proponuje to odświeżyć..;)

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
Oj oj, obawiam się, że scenariusz alternatywny nie służy "wykonaniu tego samego". Proponuję odświeżyć nieco UML ;-)

scenariusz to w ogóle nie jest UML - od tego zacznijmy
jeżeli PU to interakcja aktor <-> system prowadząca do osiągnięcia konkretnego celu (przynosząca wartość dodaną w procesie)
jeżeli scenariusz jest jak najprostszy
jeżeli ponadto scenariusz alternatywny nie prowadzi do zrealizowania konkretnego celu
to wnioskować należy, że każdy przebieg alternatywny to sposób interakcji, który nie prowadzi do osiągnięcia wyznaczonego celu
zatem jest to ciąg interakcji zakończonych porażką, bo nie wnosi żadnej wartości dodanej w procesie
jeśli dodatkowo wziąć pod uwagę, że starasz się aby każdy PU miał jak najwięcej przebiegów alternatywnych jest samo-narzucającym się wnioskiem, że starasz się aby użytkownik wchodząc w interakcję z systemem aby osiągnąć konkretny cel jak najczęściej ponosił porażkę
czy to nie paradoks? dbasz aby projektowane przez CIebie systemy były jak najmniej użyteczne?

Temat: Scenariusze w diagramach UML

Jarek Żeliński:

Jakub Płachecki:
Oj oj, obawiam się, że scenariusz alternatywny nie służy "wykonaniu tego samego". Proponuję odświeżyć nieco UML ;-)

UML to nie metoda projektowania a dokumentowania projektu...;) proponuje to odświeżyć..;)

UML to nie metoda, tylko język. Taka pomyłka... wstyd :-) I może on służyć zarówno dokumentowaniu, jak i projektowaniu. Nie zmienia to w żaden sposób faktu, że scenariusz alternatywny nie służy wykonaniu tego samego, co scenariusz podstawowy przypadku użycia nawet mimo faktu, że specyfikacja superstruktury UML ich (scenariuszy) nie omawia. Informacje na ich temat można zaś znaleźć między innymi dzięki linkom z sekcji UML Tutorials strony uml.org - http://uml.org/#Links-Tutorials

Pozdrawiam :-)Jakub Płachecki edytował(a) ten post dnia 24.02.11 o godzinie 23:05

Temat: Scenariusze w diagramach UML

Jarek Żeliński:

Doświadczenie potwierdzam, ale ja stosuje metodę która nazwałem 404 :): projektuje "stan" w którym jak coś się wysypie to pojawia się ekran, gdzie użytkownik sam decyduje co zrobi, zawsze może zaniechać i zacząć jeszcze raz....

Ciekawe podejście, nie powiem. Weźmy np. taki hipotetyczny PU: Wypłać pieniądze z bankomatu.
Przebieg podstawowy:
1. Użytkownik wkłada kartę do bankomatu.
2. System sprawdza, czy karta nie została zastrzeżona.
3. System wyświetla komunikat z prośbą o podanie numeru PIN.
4. Użytkownik wprowadza numer PIN.
5. System weryfikuje wprowadzony numer PIN.
6. System wyświetla komunikat z prośbą o wybranie operacji.
(...)
Alternatywa 1 (karta zastrzeżona)
Od pkt 2 przebiegu podstawowego:
2.1. System wyświetla komunikat "Karta została zastrzeżona i nie zostanie zwrócona. Skontaktuj się z najbliższym oddziałem swojego banku".

A nie, przepraszam, 404 - zrób co chcesz :-)

Alternatywa 2 (nieprawidłowy PIN)
Od punktu 5 przebiegu podstawowego:
5.1. System wyświetla komunikat "nieprawidłowy PIN. wprowadź poprawny numer PIN (pozostało prób: 2).
5.2. Użytkownik wprowadza PIN.
(...)
5.X System wyświetla komunikat "Wprowadziłeś nieprawidłowy PIN 3 razy. Karta nie zostanie zwrócona. Skontaktuj się z najbliższym oddziałem swojego banku".

A nie, znów przepraszam, toż to 404 - zrób co chcesz...

Scenariusze alternatywne nie są potrzebne chyba tylko komuś, kto nie wie jak się opisuje przypadki użycia. Ewentualnie całkowicie rezygnuje z opisu słowno-muzycznego.Jakub Płachecki edytował(a) ten post dnia 24.02.11 o godzinie 22:30

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
By zobrazować bardziej złożone przypadki użycia można też posłużyć się diagramem aktywności, w szczególności jeśli korzystamy z narzędzia wspierającego konwersję scenariusza do tegoż diagramu (np. Enterprise Architect - można sobie wygenerować diagram aktywności z ustrukturyzowanej specyfikacji scenariusza przypadku użycia)

A w której wersji ? Jak w starej 6.5 to mi proszę szybciutko podaj przepis na wygenerowanie diagramu aktywności z ustrukturyzowanej specyfikacji scenariusza.

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
UML to nie metoda, tylko język. Taka pomyłka... wstyd :-) I może on służyć zarówno dokumentowaniu, jak i projektowaniu.

tylko dokumentowaniu.... projektuje autor projektu...

Temat: Scenariusze w diagramach UML

Wydaje mi się, że znów należałoby powtórzyć co to scenariusz, bo obserwując ostatnie wypowiedzi non-stop komuś myli się scenariusz z opisem scenariusza. Ale też i często zamiast opis scenariusza mówimy krótko scenariusz i ... tu chyba pies pogrzebany.

Uwzględniając wreszcie konkretne przykłady Jakuba twierdzę, że:
Scenariusz podstawowy to "Przebieg podstawowy"
Opis scenariusza podstawowego to wyszczególnienie kroków "Przebiegu podstawowego" (1,2,3,4,5,6).
Scenariusz alternatywny to "Alternatywa 1 (karta zastrzeżona)", bądź "Alternatywa 2 (nieprawidłowy PIN)"
Opis scenariusza alternatywnego to wyszczególnienie kroków tych przebiegów alternatywnych.
A tak na marginesie Jakub, to polecam Ci opisywanie scenariuszy alternatywnych jako A1, A2, A3 ...
Od razu widać, który to przebieg alternatywny. Ponadto bardzo ekonomicznie jest opisywanie przebiegi alternatywne w stosunku do głównego w następujący sposób:
A2. Alternatywa 2 (nieprawidłowy PIN)
A2.1. Kroki 1-5 przebiegu podstawowego
A2.2. System wyświetla komunikat "nieprawidłowy PIN. wprowadź poprawny numer PIN (pozostało prób: 2).
A2.3. Użytkownik wprowadza PIN.
(...)
A2.X System wyświetla komunikat "Wprowadziłeś nieprawidłowy PIN 3 razy. Karta nie zostanie zwrócona. Skontaktuj się z najbliższym oddziałem swojego banku".
A2.X+1. krok 6 przebiegu podstawowego
Możesz zmieniać podstawowy, a alternatywne w większości przypadków już nie musisz.
Ale to tylko moja sugestia ...

No, ale powróćmy do naszych baranów
Synonimem scenariusza jest przypadek użycia.
W UML przypadki użycia mogą po sobie dziedziczyć. I właśnie w ten sposób zaznacza się scenariusz podstawowy jako PU uogólniony oraz scenariusze alternatywne jako dziedziczące po scenariuszu podstawowym.
Aczkolwiek istnieje interpretacja, w której PU uogólniony przedstawia się jako scenariusz abstrakcyjny zawierający tylko te kroki, które są we wszystkich PU dziedziczących.

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
Ciekawe podejście, nie powiem. Weźmy np. taki hipotetyczny PU:

w przypadku karty i bankomatu mamy trzy PU w odpowiedzi na trzy zdarzenia:
1. zdarzenie: podano poprawny PIN do niezablokowanej karty
2. zdarzenie: podano zły PIN
3. zdarzenie: wykryto zablokowana kartę

kwestia definicji PU, podjęcie pieniędzy z bankomatu to proces mający także nieplanowany koniec, przypadek użycia to czynność aktora a tu jest ich kilka (trzy).

Scenariusze alternatywne nie są potrzebne chyba tylko komuś, kto nie wie jak się opisuje przypadki użycia. Ewentualnie całkowicie rezygnuje z opisu słowno-muzycznego.

ja całkowicie rezygnuje z opisu słowno-muzycznwego, a scenariusze alternatywne są potrzebne komuś kto nie radzi sobie z procesami...

czy "bitwa" na złośliwości to coś co lubisz?