Temat: Scenariusze w diagramach UML

Czy opisujecie swoje diagramy UML (do określenia zachowania systemu) za pomocą scenariuszy, czyli przebiegów głównych i alternatywnych, czy wyłącznie ograniczacie się ewentualnie do opisu słowno-muzycznego ?

Temat: Scenariusze w diagramach UML

Jeżeli chodzi o scenariusze przypadków użycia to:
- trywialnych (operujących na jednej klasie) nie opisują w ogóle poza wskazaniem co jest celem aktora
- nietrywialnych, bazujących na wzorcu nie opisuję, powołuje się na wzorzec, opisują cel aktora,
- jeśli nie powyższe dodaje diagram sekwencji dla Modelu Dziedziny z MVC, (V)idoku i (C)ontrolera nie pokazują lub pokazują tylko interfejs.

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. Uogólniając ja zakładam, że jest to stworzenie lub modyfikacja obiektu biznesowego reprezentowanego przez obiekt lub agregat (zgodnie z DDD). Przypadki generowania raportu nazywam na swój użytek "UC ułomny" bo jego celem jest wyłącznie użycie jednej metody jakiejś klasy sterującej (lub interfejsu do komponentu).

Temat: Scenariusze w diagramach UML

Stanisław Niepostyn:
Czy opisujecie swoje diagramy UML (do określenia zachowania systemu) za pomocą scenariuszy, czyli przebiegów głównych i alternatywnych

Diagramy UML służą do opisu systemu; w tym kontekście trochę bez sensu jest je opisywać (jakkolwiek).

Scenariusze działania (testowe) powinny znaleźć się w dokumentacji testów.

Temat: Scenariusze w diagramach UML

Jakub Wojt:
Diagramy UML służą do opisu systemu;

które co opisują? Bo nie jest to to oczywiste i warto diagram "opisać" (co przedstawia)

w tym kontekście trochę bez sensu jest je opisywać (jakkolwiek).

obawiam się, że np. diagram klas lub sekwencji bez opisu będzie trudny bo przedstawiać może taksonomie, klasy wykonawcze, obiekty biznesowe nie oprogramowanie, co tak sobie ktoś wymarzy, i może mieć to sens...

Scenariusze działania (testowe) powinny znaleźć się w dokumentacji testów.

czym są scenariusze działania? O jakim diagramie mowa?

Temat: Scenariusze w diagramach UML

Jakub Wojt:

Stanisław Niepostyn:
Czy opisujecie swoje diagramy UML (do określenia zachowania systemu) za pomocą scenariuszy, czyli przebiegów głównych i alternatywnych

Diagramy UML służą do opisu systemu; w tym kontekście trochę bez sensu jest je opisywać (jakkolwiek).

Bzdura. Diagramy UML są jednym z języków opisu systemu. Należy korzystać z innych metod w celu doprecyzowania modelu. Jedną z metod wskazywaną np przez IIBA jest właśnie opisywanie scenariuszy.

Scenariusze działania (testowe) powinny znaleźć się w dokumentacji testów.

Polecam poczytać o testowaniu w oparciu o przypadki użycia:)

Temat: Scenariusze w diagramach UML

A ty znowu Mateuszu z tymi "bzdurami" ;)
Wytłumacz po prostu człowiekowi, bo się zniechęci i więcej nie napisze.

Scenariusze w przypadkach użycia opisują jak dany przypadek użycia jest realizowany przez system. Oczywiście bardzo ułatwia to później opracowanie przypadków testowych i nawet się na nie przekłada.

Można opisać je słowno-muzycznie (ja wypunktowuję po prostu kolejne kroki) lub opisać w inny sposób, na przykład z użyciem diagramu aktywności lub diagramu sekwencji. W zależności od złożoności i potrzeb.

Temat: Scenariusze w diagramach UML

Grzegorz Kukawski:
Scenariusze w przypadkach użycia opisują jak dany przypadek użycia jest realizowany przez system. Oczywiście bardzo ułatwia to później opracowanie przypadków testowych i nawet się na nie przekłada.

Osobiście nie wierze w to, że testowanie pojedynczego przypadku użycia czyni taki test skutecznym, rzecz w tym że testowane pojedyncze (na sztuki) przypadki nie wykażą błędu ale ich specyficzna kolejność owszem, dlatego osobiście zalecam testowanie całych procesów biznesowych.

w kwestii scenariuszy, może warto zapytać autora co rozumie pod tym pojęcie bo chyba straciłem wiarą, że wiem o jaki scenariusz zapytano...

Temat: Scenariusze w diagramach UML

Jarek Żeliński:

Osobiście nie wierze w to, że testowanie pojedynczego przypadku użycia czyni taki test skutecznym, rzecz w tym że testowane pojedyncze (na sztuki) przypadki nie wykażą błędu ale ich specyficzna kolejność owszem, dlatego osobiście zalecam testowanie całych procesów biznesowych.

Z ciekawości zapytam. Nie zalecasz tego jak w procesie biznesowym są złożone operacje logistyczne. Np. przetransportowanie tira koszulek z napisem "dobry analityk systemowy" z chin do polski?
Oczywiście wiem o co Ci chodzi i traktuj tę uwagę w formie żartu.

w kwestii scenariuszy, może warto zapytać autora co rozumie pod tym pojęcie bo chyba straciłem wiarą, że wiem o jaki scenariusz zapytano...

To fakt

Temat: Scenariusze w diagramach UML

W architekturze oprogramowania pojęcie "scenariusze" (scenarios) powstało w na przełomie lat osiemdziesiatych/dziewięćdziesiątych jako bardzo dobry sposób modelowania systemów informatycznych.
Scenariusz opisuje interakcję pomiędzy aktorem a systemem informatycznym.
Szybko też przechrzczono scenariusze na przypadki użycia.
Np. na początku opracowywania swojej koncepcji Philippe Kruchten nazwał nadrzedną perspektywę architektury oprogramowania perspektywą scenariuszy (Scenarios View). Dopiero parę lat później jego model 4+1, który jest podstawą RUP, "zaczął" się składać m.in. z perspektywy "przypadków użycia" czyli "Use Case View".
Ponieważ scenariusz opisuje interakcję pomiedzy aktorem a systemme informatycznym, więc jest to zbiór tzw. "przebiegów" (sekwencji, kroków), z których jeden z przebiegów jest wyróżniony jako główny, a pozostałe przebiegi nazywa się alternatywnymi.
Mam nadzieję, że wyjaśniłem termin scenariusz.
W przypadku wątpliwości mogę rozwinąć temat ;)

Temat: Scenariusze w diagramach UML

Grzegorz Kukawski:

Jarek Żeliński:

Osobiście nie wierze w to, że testowanie pojedynczego przypadku użycia czyni taki test skutecznym, rzecz w tym że testowane pojedyncze (na sztuki) przypadki nie wykażą błędu ale ich specyficzna kolejność owszem, dlatego osobiście zalecam testowanie całych procesów biznesowych.

Z ciekawości zapytam. Nie zalecasz tego jak w procesie biznesowym są złożone operacje logistyczne. Np. przetransportowanie tira koszulek z napisem "dobry analityk systemowy" z chin do polski?
Oczywiście wiem o co Ci chodzi i traktuj tę uwagę w formie żartu.

:)
Wychodzę z założenia, że:
- testy klas i testy pojedynczych UC to roboczy obowiązek programisty
- skuteczne testy całości to tylko testy kontekstowe :)

Temat: Scenariusze w diagramach UML

Jarek Żeliński:

Jakub Wojt:
Diagramy UML służą do opisu systemu;

które co opisują? Bo nie jest to to oczywiste i warto diagram "opisać" (co przedstawia)

1. Jeśli opis odnosi się do działania - Wtedy taki opis powinien się znaleźć w dokumentacji funkcjonalnej a nie technicznej. Diagram mam być obrazem opisanej funkcjonalności a nie na odwrót.

2. Jeśli opis odnosi się do "struktury" - ciężko to komentować; jeśli diagram wyraża wszystko precyzyjniej od słów to po co używać słów. Ogólniej - diagram w sposób idealny przedstawia fragment systemu do przedstawienia którego został stworzony.

3. Jeśli chodzi "o zrozumienie". Uważam, że ta kwestia jest zbyt "ogólna" żeby odnieść się do niej w sensowny sposób. Poza tym diagramy maja dokumentować a nie "powodować zrozumienie".Jakub Wojt edytował(a) ten post dnia 21.02.11 o godzinie 22:07

Temat: Scenariusze w diagramach UML

Scenariusz to szerokie pojęcie, tak szerokie jak szeroka będzie tu definicja przypadku użycia, może nim być w niektórych metodykach zbudowanie budżetu firmy a w innych wprowadzenie danych budżetowych jednej komórki org. dlatego warto zapytać, poza panem Kruchtenem powstało bardzo dużo innych książek o przypadkach użycia, np. bardzo popularny (znacznie bardziej od Kruchtena) Cocbourn (Jak pisać efektywne przypadki użycia, akurat tej teorii nie lubię) albo nieco mniej popularny Geri Shneider (Stosowanie przypadków użycia, tego Pana dla odmiany lubię :).

jeżeli uznamy, że przypadek użycia zaczyna się stabilnymi warunkami początkowymi, kończy warunkami końcowymi i stanowi pojedynczą operacje na obiekcie lub ich kolekcji, to scenariuszem jest np. sekwencja opisująca realizacje takiego przypadku użycia i dodatkowy opis (nie licząc tytułu) staje się zbędny, kontekstem jest model procesu biznesowego, w którym dany przypadek użycia występuje ....

Temat: Scenariusze w diagramach UML

Jakub Wojt:
1. Jeśli opis odnosi się do działania - Wtedy taki opis powinien się znaleźć w dokumentacji funkcjonalnej a nie technicznej. Diagram mam być obrazem opisanej funkcjonalności a nie na odwrót.

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.

2. Jeśli opis odnosi się do "struktury" - ciężko to komentować; jeśli diagram wyraża wszystko precyzyjniej od słów to po co używać słów. Ogólniej - diagram w sposób idealny przedstawia fragment systemu do przedstawienia którego został stworzony.

O jakiej/czego strukturze mowa? Scenariusz może w postaci diagramu sekwencji opisywać dokładnie jakie klasy i jak wywoływane zrealizują tworzenie tej faktury, to już projektowanie (co najmniej koncepcji rozwiązania)

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

a jak udokumentować coś bez zrozumienia?
P.S.
Można, wystarczy stenografować "user story"....Jarek Żeliński edytował(a) ten post dnia 21.02.11 o godzinie 22:17

Temat: Scenariusze w diagramach UML

Jarek Żeliński:
jeżeli uznamy, że przypadek użycia zaczyna się stabilnymi warunkami początkowymi, kończy warunkami końcowymi i stanowi pojedynczą operacje na obiekcie lub ich kolekcji, to scenariuszem

Standard UML, rozdział Use Cases, wyraźnie precyzuje, że jest to interakcja pomiędzy aktorem a systemem. Niniejszy wątek dotyczy scenariuszy w diagramach UML. Toteż nie miałem na myśli jakichkolwiek szerszych pojęć scenariuszy. Jeżeli ktoś zrozumiał nie tak, jak było to moją intencją, to chciałbym przeprosić za moje niezbyt precyzyjne, jak widać, określenia. Wróćmy więc z tych szerokich pojęć do UML.
Natomiast interesujące jest definiowanie przypadku użycia jako pojedynczej operacji na obiekcie. I jest to dosć częstą praktyką, aczkolwiek niezupełnie poprawną. Jeżeli jednak udaje się za pomocą tej interpretacji wdrożyć działający system, to poprawność traci co nieco na znaczeniu.
Inna sprawa, że interpretowanie interakcji pomiędzy komponentami (obiektami) systemu jako przypadku użycia wprowadza bardzo duże kłopoty przy testowaniu całego systemu.
Mocny przykład miałem niedawno jeszcze w pracy nad systemem celnym. Chłopcy stwierdzili, że cały system warto podzielić na poszczególne jego moduły, a interakcje pomiędzy modułami (czyli obsługę komunikatów - np. o eksporcie koszulek z napisem "dobry analityk systemowy" z Chin na teren UE) nazwali przypadkami użycia. Oczywiście cały proces biznesowy obsługujący tego tira to zestaw wielu komunikatów wymienianych pomiędzy systemami poszczególnych Izb Celnych, ale chłopaki rozdrobnili to jeszcze na moduły.
Jakież ich było zdziwienie, gdy nie potrafili sensownie ułożyć scenariuszy testowych. W tych scenariuszach pełno było oczywiście przypadków testowych utworzonych na podstawie ich "stosownych" przypadków użycia. I w trakcie testowania trudno było zweryfikować działanie systemu, gdyż ich przypadki testowe opisywały jedynie stan wewnętrzny systemu, czyli stan poszczególnych obiektów systemu. Więc po każdym niemalże dotknięciu się klawiatury na danym ekranie należało wchodzić w przeróżne miejsca systemu na innym równobieżnym ekranie (procesie), bądź wychodzić z naszego ekranu i wchodzić w inne zakątki systemu, a potem wracać do pierwotnego, by zweryfikować, czy wciśnięcie danego klawisza było prawidłowe, czy nie. Znaczy się makabra.
Z drugiej strony nie dziwię się temu podejściu, gdyż było to jak gdyby powieleniem błędnej interpretacji przypadku użycia zastosowanego w dokumentacji Komisji Europejskiej dotyczącej systemu celnego. Tam przypadkiem użycia została nazwana wybrana sekwencja obsługi jednego, bądź kilku komunikatów z informacjami o deklaracjach celnych. No ale aktorami nie były części systemu ...

Temat: Scenariusze w diagramach UML

Nic z tego nie zrozumiałem więc przytoczę źródło czyli twórców UML'a bo, jako oryginał, są moim zdaniem jednak lepsi od interpretatorów ich myśli:

"Przypadek użycia to opis zbioru ciągów akcji (i ich wariantów) wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi wyniku." (źr. G.Booch, J.Rumbaugh, I.Jacobson, UML przewodnik użytkownika).

Prosta i piękna w swej prostocie definicja i po co kombinować?

Po drugie: jak rozumiemy scenariusz? Mając plan warszawy (jej model w postaci diagramu jakim jest plan) mamy zamodelowany układ ulic: JEDEN. Scenariuszy pokonania odcinka od dworca centralnego do kolumny zygmunta może być wręcz nieskończenie wiele, ale model miasta pozostaje jeden i dlatego warto się skupić na tym modelu a nie na wykonaniu listy wszystkich scenariuszy..

jednak prawdę jest, że podejście zależy od stosowanej metodyki o tu chyba warto dać sobie spokój z przekonywaniem się, jak każdy pokaże swój sposób to i tak jest dużo... jedni lubię Kruchtena, inni Cocbourna jeszcze inni I.Grahama czy po protu E.Yourdona.

Po prostu uważam, że skuteczniej jest zamodelować raz porządnie miasto niż wysilać się na osobne odrębne modelowanie każdej trasy taksówkarza jaką w danych warunkach podejmie... na planie miasta przeprowadzę kilka testów poprawności i OK, wszystkich możliwych tras i tak jest niemalże nieskończenie wiele... to podejście nazywa się DDD.Jarek Żeliński edytował(a) ten post dnia 22.02.11 o godzinie 00:26

Temat: Scenariusze w diagramach UML

Jarek Żeliński:
Nic z tego nie zrozumiałem więc przytoczę źródło czyli

Szkoda .... a ja się tak namęczyłem by opisać przykład z prawdziwego projektu wzięty, mając nadzieję, że będę lepiej zrozumiany .... :(

twórców UML'a bo, jako oryginał, są moim zdaniem jednak lepsi od interpretatorów ich myśli:

"Przypadek użycia to opis zbioru ciągów akcji (i ich wariantów) wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi wyniku." (źr. G.Booch, J.Rumbaugh, I.Jacobson, UML przewodnik użytkownika).

Prosta i piękna w swej prostocie definicja i po co kombinować?

Cieszę się, że zawróciłeś z szerokich wód nieokreśloności UC ... :)
A OMG kombinuje, bo mamy już rok 2011, a książeczka, którą przytaczasz to juz zabytek, a ludzie z OMG tez by chcieli jakoś zaznaczyć swój wkład w rozwój UML. Patrz co wykombinowali w 2009 roku:
"Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors. Use cases define the offered behavior of the subject without reference to its internal structure."

Po drugie: jak rozumiemy scenariusz? Mając plan warszawy (jej model w postaci diagramu jakim jest plan) mamy zamodelowany układ ulic: JEDEN. Scenariuszy pokonania odcinka od dworca centralnego do kolumny zygmunta może być wręcz nieskończenie wiele, ale model miasta pozostaje jeden i dlatego warto się skupić na tym modelu a nie na wykonaniu listy wszystkich scenariuszy..

Przykład planu miasta jest takim małym przegięciem, prawda ?
W przypadku dużych modeli inżynieria oprogramowania radzi dekomponować cały ten model na odpowiednie fragmenty. I od razu będzie Ci o wiele łatwiej analizować część systemu ... :)

Po prostu uważam, że skuteczniej jest zamodelować raz porządnie miasto niż wysilać się na osobne odrębne modelowanie każdej trasy taksówkarza jaką w danych warunkach podejmie... na planie miasta przeprowadzę kilka testów poprawności i OK, wszystkich możliwych tras i tak jest niemalże

Można od razu modelować i nie przejmować się scenariuszami ...
Ale też można pisać tylko same scenariusze i w ogóle ich nie przedstawiać graficznie w formie modelu. I tak też widziałem. W uzasadnieniu podawano, że w sumie te scenariusze są na tyle proste, że szkoda tracić czas na rysowanie diagramu ....

nieskończenie wiele... to podejście nazywa się DDD.

Graf skierowany raczej nie może być nieskończony. Wydaje mi się, że nieskończenie wiele może być natomiast przypadków testowych. A to wynika z możliwości wprowadzania nieskończonej ilości wartości danych. No, ale tu wchodzimy w informatykę teoretyczną, a mało osób ją lubi ....Stanisław Niepostyn edytował(a) ten post dnia 22.02.11 o godzinie 01:16

Temat: Scenariusze w diagramach UML

Grzegorz Kukawski:
A ty znowu Mateuszu z tymi "bzdurami" ;)
Wytłumacz po prostu człowiekowi, bo się zniechęci i więcej nie napisze.

Ja mogę nie pisać bzdura jak ktoś pisze - moim zdaniem, ja używam do, z mojego doświadczenia lepiej jest, korzystniejsze rozwiązanie to, u nas sprawdza się.
Ale jak arbitralnie ocenia co do czego służy i co powinno a co nie powinno gdzie się znajdować, a do tego mianuje się projektantem to w moim odczuciu, ktoś kto czyta to forum, żeby się czegoś nauczyć może uznać, że jest tak jak ten człowiek pisze. A wtedy ignorancja się szerzy, efektem czego trudniej jest mi kiedyś z kimś pracować.
A że jestem konformistą to dla własnej wygody koryguję takie sytuacje:P

Temat: Scenariusze w diagramach UML

Stanisław Niepostyn:
A OMG kombinuje, bo mamy już rok 2011, a książeczka, którą przytaczasz to juz zabytek, a ludzie z OMG tez by chcieli jakoś zaznaczyć swój wkład w rozwój UML.

jeszcze większym zabytkiem jest geometria Euklidesa... wiek "wiedzy" nijak nie przekłada się na jej wartość,

Patrz co wykombinowali w 2009 roku:
"Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors. Use cases define the offered behavior of the subject without reference to its internal structure."

ostatnia sentencja oznaczy tylko "hermetyzację" i nic więcej... nie jest taka zła i nie kłóci się poprzednią

Przykład planu miasta jest takim małym przegięciem, prawda ?

nie

W przypadku dużych modeli inżynieria oprogramowania radzi dekomponować cały ten model na odpowiednie fragmenty. I od razu będzie Ci o wiele łatwiej analizować część systemu ... :)

Zaś inżynieria projektowanie polega na umiejętnym użyciu uogólnień i abstrakcji. Miasto to tysiące budynków, w razie potrzeby sięgniemy po plany każdego z nich, to osobne dokumenty powiązane, niezależnie od tego zależnie od potrzeby, posługujemy się planem o dobranej skali. Ten przykład jest w moich oczach bardzo dobry.

Ale też można pisać tylko same scenariusze i w ogóle ich nie przedstawiać graficznie w formie modelu.

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

nieskończenie wiele... to podejście nazywa się DDD.

Graf skierowany raczej nie może być nieskończony.

ale może mieć tak wielką liczbę przejść, że ich detaliczny opis traci sens, wiadomo, że liczba możliwych dróg od Kolumny Zygmunta do Dworca Centralnego jest skończona, co nie zmienia faktu, że ich liczba nie daje szansy analizy jednemu człowiekowi w rozsądnym czasie... po to powstała metoda monte carlo i tak tez się testuje gotowe systemy (można testować), wybiera się tak zwane "reprezentacyjne procesy biznesowe" do testowania poprawności działania oprogramowania np. ERP.

Temat: Scenariusze w diagramach UML

Jarek Żeliński:

Stanisław Niepostyn:
A OMG kombinuje, bo mamy już rok 2011, a książeczka, którą przytaczasz to juz zabytek, a ludzie z OMG tez by chcieli jakoś zaznaczyć swój wkład w rozwój UML.

jeszcze większym zabytkiem jest geometria Euklidesa... wiek "wiedzy" nijak nie przekłada się na jej wartość,

Hmm..,
gdyby nie geometria Riemanna nie byłoby teorii względności,
gdyby nie geometria algebraiczna, nie byłoby krzywych eliptycznych w kryptografii...
gdyby .....

Patrz co wykombinowali w 2009 roku:
"Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors. Use cases define the offered behavior of the subject without reference to its internal structure."

ostatnia sentencja oznaczy tylko "hermetyzację" i nic więcej... nie jest taka zła i nie kłóci się poprzednią

To nie wiem czemu podniosłeś larum ???
Widzę, że powtarzasz za mną moje określenia i definicje, a wrażenie można odnieść, że głosisz niemalże nieznane nikomu idee.
Bardzo ciekawa technika konwersacji ;)
Warsztat dziennikarski widzę, że masz opanowany ;)

Przykład planu miasta jest takim małym przegięciem, prawda ?

nie

Przyznaj się więc komu malowałeś plan Warszawy w Visual Paradigm, czy w innym narządku ;)))
Ja bym raczej użył do tego jakiegos narzędzia do obsługi map, ale ... masz bardzo ciekawe zlecenia ;))))

W przypadku dużych modeli inżynieria oprogramowania radzi dekomponować cały ten model na odpowiednie fragmenty. I od razu będzie Ci o wiele łatwiej analizować część systemu ... :)

Zaś inżynieria projektowanie polega na umiejętnym użyciu

szukam i szukam "inżynierii projektowania" i ni ma ... :(
Czy mam rozumieć, ze rezygnujemy juz z Informatyki i zaczynamy schodzić na bezdroża sci-fi, tudziez mistyki ?

uogólnień i abstrakcji. Miasto to tysiące budynków, w razie potrzeby sięgniemy po plany każdego z nich, to osobne dokumenty powiązane, niezależnie od tego zależnie od potrzeby, posługujemy się planem o dobranej skali. Ten przykład jest w moich oczach bardzo dobry.

Nie słyszałem, by ktos wykorzystywał UML do modelowania planu miasta ;)))
Ach ten rozwój nauki i techniki ... Cięzko nadążyć za śledzeniem zmian ...;)))

Ale też można pisać tylko same scenariusze i w ogóle ich nie przedstawiać graficznie w formie modelu.

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

nieskończenie wiele... to podejście nazywa się DDD.

Graf skierowany raczej nie może być nieskończony.

ale może mieć tak wielką liczbę przejść, że ich detaliczny

w grafie planarnym, bo o takim mowa, do wyznaczenia jego krawędzi stosujemy wzór Eulera ...

opis traci sens, wiadomo, że liczba możliwych dróg od Kolumny Zygmunta do Dworca Centralnego jest skończona, co nie zmienia faktu, że ich liczba nie daje szansy analizy jednemu człowiekowi w rozsądnym czasie... po to powstała metoda monte carlo i tak

Przy wyznaczaniu dróg w grafie planarnym bezsensowne jest używanie metody monte carlo ....
Ja zastosowałem w sumie tylko dwa algorytmy BFS i DFS ... Wprowadzenie metody monte carlo zmieniłoby tylko wyłacznie kolejność przebiegów alternatywnych, ale za to zmniejszyło by wydatnie szybkość działania algorytmu ...

tez się testuje gotowe systemy (można testować), wybiera się tak zwane "reprezentacyjne procesy biznesowe" do testowania poprawności działania oprogramowania np. ERP.

Fajnie dowiedzieć się wielu dziwnych rzeczy, ale wydawało mi się, że tematem są scenariusze w diagramach UML ... Zmieniamy wątek ?

Temat: Scenariusze w diagramach UML

Stanisław Niepostyn:

jeszcze większym zabytkiem jest geometria Euklidesa... wiek "wiedzy" nijak nie przekłada się na jej wartość,

Hmm..,
gdyby nie geometria Riemanna nie byłoby teorii względności,
gdyby nie geometria algebraiczna, nie byłoby krzywych eliptycznych w kryptografii...
gdyby .....

wierze, że wiesz czym się różnię i że wiesz dlaczego na papierze stosujemy wyłącznie geometrię Euklidesa, choć sam fakt że je tu w tym kontekście przytoczyłeś zachwiał tę moja wiarę

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... jeśli nadal nie rozumiesz idei stosowania metody monte carlo (skuteczniejszej i łatwiejszej to implementacji niż rzeczone wzory na które się powołujesz) odsyłam do wujka googla.

tez się testuje gotowe systemy (można testować), wybiera się tak zwane "reprezentacyjne procesy biznesowe" do testowania poprawności działania oprogramowania np. ERP.

Fajnie dowiedzieć się wielu dziwnych rzeczy, ale wydawało mi się, że tematem są scenariusze w diagramach UML ... Zmieniamy wątek ?

nie, proces testowy jest w końcu także scenariuszem testu :), można go udokumentowac w UML (i BPMN), prozy nie polecam

P.S.
zbędne próby złośliwości pominąłem... szkoda mi oczy czytających