Temat: BPMN 2.0 WorkFlow Patterns

Udostępniam wszystkim członkom grupy komplet wzorców procesowych w BPMN 2.0;


;
Proszę o komentarze.Ten post został edytowany przez Autora dnia 21.07.14 o godzinie 16:23

Temat: BPMN 2.0 WorkFlow Patterns

missing plugin...

Temat: BPMN 2.0 WorkFlow Patterns

(na Macu się nie odpala, po upgradzie javy itp. nie męczyłem tego, więc musiałem virtualnie to uruchomić z MSIE).

Jako, że pracujemy nad dostosowaniem do BPMN własnego narzędzia, to niestety nie jest to w pełni użyteczne (lub nie jestem w stanie tego dobrze zinterpretować). Po tych opisach i przykładach nie jestem w stanie jednoznacznie ustalić, jak ma się zachować interpreter. Ale przykłady graficzne dużo dają. Jest też to mądrze usystematyzowane, aczkolwiek nie wiem czy to jest skończona liczba możliwości konfiguracji wymagających definicji, czy tylko jest to jakiś fragment.

Tak się zastanawiam, czy nie najbardziej jednoznaczny obok symbolu graficznego byłby przykład kawałka kodu implementującego każdy z przypadków ( w javie lub php )?

Temat: BPMN 2.0 WorkFlow Patterns

Witam.
Celem WorkFlow Patterns jest pokazanie jak określone logiki realizacji procesu mogą być odzwierciedlone w danej notacji.
Oczywiście można wygenerować z tego kod XPDL ale już nie BPEL bo np. nie obsługuje wszystkich logik.

Temat: BPMN 2.0 WorkFlow Patterns

Arkadiusz Binder:
missing plugin...

Niestety nie mam dostępu do Mac'a. Dawniej, gdy próbowałem działało i na Mac'u. O ile wiem, nie działa tylko na Androidzie (ograniczenia licencyjne dla Googla).

Nie wymaga specjalnego plug-ina (tylko Javy). Może zainstalowany jest jakiś bloker skryptów?

Temat: BPMN 2.0 WorkFlow Patterns

Piotr Tadeusz B.:
Witam.
Celem WorkFlow Patterns jest pokazanie jak określone logiki realizacji procesu mogą być odzwierciedlone w danej notacji.
Oczywiście można wygenerować z tego kod XPDL ale już nie BPEL bo np. nie obsługuje wszystkich logik.

A czy można się spytać np. której logiki BPEL nie obsługuje ?
Wydawało mi się, żę BPMN daje się "przekonwertować" na BPEL ?

Jeszcze jedna ostatnio rzecz mnie ciekawiła. Dajmy na to prosto rozpisać na BPMN jak ma iść taśma z butelkami, ale teraz zastanawiałem się nad takim przypadkiem: jest sobie maszyna, która wycina trójkąty w deskach. Teraz możemy na BPMN pokazać prostą taśmę, gdzie w którymś momencie "robot" wycina jakiś zadany kształt (jako asocjację z komputera projektanta). Ale ja wiem, jaka jest struktura przekazywanych tych danych - wiem , że jest plik .DWG, który posiada współrzędne tych "cięć", wiem jak te informacje odebrać i jak przetworzyć do maszyny ( w pętli ). To teraz pytanie czy takie tematy też wspierają narzędzia BPMS/BPEL itp ? Bo jeżeli tak, to powinniśmy gdzieś znaleźć w sieci rozpisany w BPMN protokół TCP/IP , ARP, IMAP itp ... Jeżeliby to wpuścić w maszynkę BPEL, to czy mógłby powstać klient poczty oparty o BPEL/BPMS ? W rozwiązaniach np. BONETTI BPM Studio stosuje się tzw "connectory". A ja zakładałbym modelowanie w sposób taki, aby metody dojścia były zamodelowane w tym samym języku, co cała reszta. W teorii byśmy mieli pod kontrolą procesu nieodebrany pakiet TCP/IP ;-) ? Moje pytanie jest takie, czy znacie kogoś kto robi badania/działania w tym kierunku?

Temat: BPMN 2.0 WorkFlow Patterns

Arkadiusz Binder:

Piotr Tadeusz B.:
Witam.
Celem WorkFlow Patterns jest pokazanie jak określone logiki realizacji procesu mogą być odzwierciedlone w danej notacji.
Oczywiście można wygenerować z tego kod XPDL ale już nie BPEL bo np. nie obsługuje wszystkich logik.

A czy można się spytać np. której logiki BPEL nie obsługuje ?
Wydawało mi się, żę BPMN daje się "przekonwertować" na BPEL ?

Choćby Ad Hoc.

Z faktu, że BPMN daje się konwertować do BPEL nie wynika, że wszystkie konstrukcje BPMN są obsługiwane przez BPEL (BPMN " jest graficzną notacją służącą do opisywania procesów biznesowych" a BPEL to "język do definiowania procesów biznesowych opartych o usługi sieciowe" wg Wikipedii). Niektóre narzędzia (np. iGrafx) potrafią na etapie eksportu do BPEL pokazać nieobsługiwane konstrukcje (z sugestią ich zmiany) inne potrafią na modelowanie w BPMN nałożyć ograniczenia BPEL. (Można powiedzieć stosują zubożony BPMN).

Temat: BPMN 2.0 WorkFlow Patterns

Arkadiusz Binder:

Jeszcze jedna ostatnio rzecz mnie ciekawiła. Dajmy na to prosto rozpisać na BPMN jak ma iść taśma z butelkami, ale teraz zastanawiałem się nad takim przypadkiem: jest sobie maszyna, która wycina trójkąty w deskach. Teraz możemy na BPMN pokazać prostą taśmę, gdzie w którymś momencie "robot" wycina jakiś zadany kształt (jako asocjację z komputera projektanta). Ale ja wiem, jaka jest struktura przekazywanych tych danych - wiem , że jest plik .DWG, który posiada współrzędne tych "cięć", wiem jak te informacje odebrać i jak przetworzyć do maszyny ( w pętli ). To teraz pytanie czy takie tematy też wspierają narzędzia BPMS/BPEL itp ? Bo jeżeli tak, to powinniśmy gdzieś znaleźć w sieci rozpisany w BPMN protokół TCP/IP , ARP, IMAP itp ... Jeżeliby to wpuścić w maszynkę BPEL, to czy mógłby powstać klient poczty oparty o BPEL/BPMS ? W rozwiązaniach np. BONETTI BPM Studio stosuje się tzw "connectory". A ja zakładałbym modelowanie w sposób taki, aby metody dojścia były zamodelowane w tym samym języku, co cała reszta. W teorii byśmy mieli pod kontrolą procesu nieodebrany pakiet TCP/IP ;-) ? Moje pytanie jest takie, czy znacie kogoś kto robi badania/działania w tym kierunku?

Z punktu widzenia BPMN nie ma przeciwwskazań do zamodelowania takich struktur. Struktury danych opiszą co ma być przenoszone a mechanizm komunikatów, jak ma to być przenoszone (nawet obsłużą usterkę nieodebrany komunikat - pakiet TCP/IP (komunikat może mieć wbudowaną metodę implementacji).

Inną kwestią są narzędzia BPMN. One już nie zawsze pozwalają na precyzyjne opisanie i "niestety" nie wyklucza to ich zgodności ze specyfikacją (ona określa, że "mogą" a nie "muszą").

Tak, niektórzy producenci systemów BPMS pracują nad tym. Można się spotykać nawet z narzędziami uruchamiającymi procesy bezpośrednio z XPDL powstałego z BPMN (ale również tu widziałem jakieś "connectory").

Temat: BPMN 2.0 WorkFlow Patterns

W kwestii wzorców, a raczej stylu modelowania, ciekawy artykuł, mało "technokratyczny":
http://www.modernanalyst.com/Resources/Articles/tabid/...

Temat: BPMN 2.0 WorkFlow Patterns

Artykuł dobry aczkolwiek nie zgadzam się z tezą, że nie należy nazywać bramek.
Owszem, moim zdaniem, warto nazywać je kryterium wyboru (dotyczy to bramek decyzyjnych ALBO, LUB i Złożona) i rzadziej kryterium scalania (bramki scalające). Ma to znaczenie przy automatycznym tłumaczeniu modeli do procedur. Bramkę ALBO sterowaną zdarzeniami można nazywać "Oczekiwanie".

Dodatkowo jestem zwolennikiem nazywania zdarzeń stanami, jakie obrazują. Na przykładach z tego artykułu było to robione niekonsekwentnie. Rys. 1 z prawej - wzorowo. Rys. 2 - gorzej. (Przy okazji na tym rysunku jest błąd formalny. Nie można kończyć "Anuluj" bo nie jest to transakcja biznesowa :-(.)

Bardzo dobrze przedstawione są kryteria podziału na podprocesy.

Temat: BPMN 2.0 WorkFlow Patterns

Piotr Tadeusz B.:
Artykuł dobry aczkolwiek nie zgadzam się z tezą, że nie należy nazywać bramek.

Osobiście "testuje" to i jestem za tym by bramek nie nazywać, powody są dwa moim zdaniem:
- nazwane bramki są intepretowane przez "niewprawnych" czytelników jak czynności (nie walczymy z tym :)))
- zmusza to do zastanowienia się na sense ich używania

Testuje także "drugą wersje": to nadawanie bramkom nazw w postaci warunków jakie kontrolują... czyni to te bramki "reużywalnymi" (ale z głową :))), po drugie ma tę zaletę, że bramki maja swoje nazwy w repozytirum (i to jest główny powód dla którego to robię).

Dodatkowo jestem zwolennikiem nazywania zdarzeń stanami, jakie obrazują. Na przykładach z tego artykułu było to robione niekonsekwentnie. Rys. 1 z prawej - wzorowo. Rys. 2 - gorzej. (Przy okazji na tym rysunku jest błąd formalny. Nie można kończyć "Anuluj" bo nie jest to transakcja biznesowa :-(.)

Bardzo dobrze przedstawione są kryteria podziału na podprocesy.

poza małymi bolączkami ogólnie uważam, że artykuł jest jednak bardzo dobry :).

Z mojej strony uwaga: BPMN jest bardzo często używany na wyższym niż wykonywalny, poziomie abstrakcji. "Pętla wstecz" zawsze budziła moje wyobrażenie o "Maszynie czasu" w przeszłość. Fascynujące bywają opowieści co oznacza diagram, na którym z końca procesu opracowania oferty, po odrzuceniu jej treści przez szefa, leci strzałka na początek. Pytam wtedy: skoro praca nad oferta rozpoczęła się od pustej kartki, to jak to wygląda w drugiej iteracji skoro oferta istnieje? I "kto liczy te iteracji i co powoduje, że ta pętla nie jest nieskończona"...

Temat: BPMN 2.0 WorkFlow Patterns

Jarek Żeliński:

poza małymi bolączkami ogólnie uważam, że artykuł jest jednak bardzo dobry :).

Też się z tym zgadzam.

Z mojej strony uwaga: BPMN jest bardzo często używany na wyższym niż wykonywalny, poziomie abstrakcji. "Pętla wstecz" zawsze budziła moje wyobrażenie o "Maszynie czasu" w przeszłość. Fascynujące bywają opowieści co oznacza diagram, na którym z końca procesu opracowania oferty, po odrzuceniu jej treści przez szefa, leci strzałka na początek. Pytam wtedy: skoro praca nad oferta rozpoczęła się od pustej kartki, to jak to wygląda w drugiej iteracji skoro oferta istnieje? I "kto liczy te iteracji i co powoduje, że ta pętla nie jest nieskończona"...

Tu akurat przydaje się świadomość danych w procesie. Praktycznie każda czynność w BPMN to zmiana danych w procesie (bez roztrząsania czy są to dane wirtualne czy fizyczne). Więc jeśli "wracasz na początek" to dane powiązane z żetonem mają już jakąś strukturę i ew. status.

Temat: BPMN 2.0 WorkFlow Patterns

Piotr Tadeusz B.:

Jarek Żeliński:

poza małymi bolączkami ogólnie uważam, że artykuł jest jednak bardzo dobry :).

Też się z tym zgadzam.

Z mojej strony uwaga: BPMN jest bardzo często używany na wyższym niż wykonywalny, poziomie abstrakcji. "Pętla wstecz" zawsze budziła moje wyobrażenie o "Maszynie czasu" w przeszłość. Fascynujące bywają opowieści co oznacza diagram, na którym z końca procesu opracowania oferty, po odrzuceniu jej treści przez szefa, leci strzałka na początek. Pytam wtedy: skoro praca nad oferta rozpoczęła się od pustej kartki, to jak to wygląda w drugiej iteracji skoro oferta istnieje? I "kto liczy te iteracji i co powoduje, że ta pętla nie jest nieskończona"...

Tu akurat przydaje się świadomość danych w procesie. Praktycznie każda czynność w BPMN to zmiana danych w procesie (bez roztrząsania czy są to dane wirtualne czy fizyczne). Więc jeśli "wracasz na początek" to dane powiązane z żetonem mają już jakąś strukturę i ew. status.

Moim zdaniem "ratunkiem" nie raz faktycznie jest status, ale pozostaje problem "pętli nieskończonej"... czyli pytanie: co powoduje, że proces dobiega do końca w 100%, jak to się dzieje w symulacjach?Jarek Żeliński edytował(a) ten post dnia 03.01.13 o godzinie 22:21

Temat: BPMN 2.0 WorkFlow Patterns

Jarek Żeliński:

Piotr Tadeusz B.:

Jarek Żeliński:

poza małymi bolączkami ogólnie uważam, że artykuł jest jednak bardzo dobry :).

Też się z tym zgadzam.

Z mojej strony uwaga: BPMN jest bardzo często używany na wyższym niż wykonywalny, poziomie abstrakcji. "Pętla wstecz" zawsze budziła moje wyobrażenie o "Maszynie czasu" w przeszłość. Fascynujące bywają opowieści co oznacza diagram, na którym z końca procesu opracowania oferty, po odrzuceniu jej treści przez szefa, leci strzałka na początek. Pytam wtedy: skoro praca nad oferta rozpoczęła się od pustej kartki, to jak to wygląda w drugiej iteracji skoro oferta istnieje? I "kto liczy te iteracji i co powoduje, że ta pętla nie jest nieskończona"...

Tu akurat przydaje się świadomość danych w procesie. Praktycznie każda czynność w BPMN to zmiana danych w procesie (bez roztrząsania czy są to dane wirtualne czy fizyczne). Więc jeśli "wracasz na początek" to dane powiązane z żetonem mają już jakąś strukturę i ew. status.

Moim zdaniem "ratunkiem" nie raz faktycznie jest status, ale pozostaje problem "pętli nieskończonej"... czyli pytanie: co powoduje, że proces dobiega do końca w 100%, jak to się dzieje w symulacjach?

Dane weryfikowane w bramce (lub w czynności realizowanej w pętli) decydują o opuszczeniu pętli. W "głupich" narzędziach symulacyjnych jest to określane % w mądrych tworzony jest warunek i weryfikowane jest spełnienie warunku. Ale do tego potrzebne są dane.

Temat: BPMN 2.0 WorkFlow Patterns

Piotr Tadeusz B.:

Moim zdaniem "ratunkiem" nie raz faktycznie jest status, ale pozostaje problem "pętli nieskończonej"... czyli pytanie: co powoduje, że proces dobiega do końca w 100%, jak to się dzieje w symulacjach?

Dane weryfikowane w bramce (lub w czynności realizowanej w pętli) decydują o opuszczeniu pętli.

o ile (teraz nie mam przed sobą) pamiętam semantykę BPMN, bramka jest jedynie manifestacją logiki wykonanej w poprzedzającej ją czynności, każda bramkę można zamienić na serię wyjść warunkowych (wyjątkiem jest bramka zdarzeniowa, tu logikę XOR określa kolejność zdarzeń). Więc chyba nie istnieje pojęcie "dane wejściowe w bramce" ....

W "głupich" narzędziach symulacyjnych jest to określane % w mądrych tworzony jest warunek i weryfikowane jest spełnienie warunku. Ale do tego potrzebne są dane.

jaki warunek? mam pętlę "Opracowanie Oferty" gdzie odrzucenie treści przez szefa cofa Ofertę do kroku Opracowanie Oferty, gdzie i jakie warunki powinny być by nie była to pętla nieskończna? Rozumiem, że symulator może dostać regułę "do korekty wraca 15% Ofert" ale to nie zabezpiecza nas przed ryzykiem nieskonczoności trwania tej pętli, to tylko statystyka.

Temat: BPMN 2.0 WorkFlow Patterns

Jarek Żeliński:

Piotr Tadeusz B.:

Moim zdaniem "ratunkiem" nie raz faktycznie jest status, ale pozostaje problem "pętli nieskończonej"... czyli pytanie: co powoduje, że proces dobiega do końca w 100%, jak to się dzieje w symulacjach?

Dane weryfikowane w bramce (lub w czynności realizowanej w pętli) decydują o opuszczeniu pętli.

o ile (teraz nie mam przed sobą) pamiętam semantykę BPMN, bramka jest jedynie manifestacją logiki wykonanej w poprzedzającej ją czynności, każda bramkę można zamienić na serię wyjść warunkowych (wyjątkiem jest bramka zdarzeniowa, tu logikę XOR określa kolejność zdarzeń). Więc chyba nie istnieje pojęcie "dane wejściowe w bramce" ....

Pełna nazwa np. bramki XOR (zwykłej) to Bramka ALBO sterowana danymi. W specyfikacji jest opisane:

"A Decision can be thought of as a question that is asked at a particular point in the Process. The question has a defined
set of alternative answers. Each answer is associated with a condition Expression that is associated with a Gateway’s
outgoing Sequence Flows."

Jedynie dane mogą być weryfikowane więc dane są elementem wyrażenia. Mogą odnosić się do procesu lub instancji procesu. Nie są manifestacją a reakcją na określoną strukturę danych. (Konkretnie na spełnienie określonego warunku / wyrażenia w przypadku XOR sprawdzanego w określonej kolejności.)

W "głupich" narzędziach symulacyjnych jest to określane % w mądrych tworzony jest warunek i weryfikowane jest spełnienie warunku. Ale do tego potrzebne są dane.

jaki warunek? mam pętlę "Opracowanie Oferty" gdzie odrzucenie treści przez szefa cofa Ofertę do kroku Opracowanie Oferty, gdzie i jakie warunki powinny być by nie była to pętla nieskończna? Rozumiem, że symulator może dostać regułę "do korekty wraca 15% Ofert" ale to nie zabezpiecza nas przed ryzykiem nieskonczoności trwania tej pętli, to tylko statystyka.

Nie zupełnie. Jeśli opracowanie oferty jest czynnością w pętli (Sequential Loop Task) to badany jest warunek wyjścia (badane jest, czy wartość wyrażenia jest prawdą). Jeśli pętla realizowana jest bramką to weryfikowane jest wyrażenie czy dla pierwszej ze ścieżek warunek ten jest prawdą (np. status zmiennej StatusOferty jest ustawiony na Tak). Jeśli nie to badany jest warunek dla następnej ścieżki. Jak widzisz nie ma tu nic z "przypadku". Zmiana statusu (zmiana wartości zmiennej czyli danej) jest możliwa jedynie w czynności.

Temat: BPMN 2.0 WorkFlow Patterns

Piotr Tadeusz B.:
Jedynie dane mogą być weryfikowane więc dane są elementem wyrażenia. Mogą odnosić się do procesu lub instancji procesu. Nie są manifestacją a reakcją na określoną strukturę danych. (Konkretnie na spełnienie określonego warunku / wyrażenia w przypadku XOR sprawdzanego w określonej kolejności.)

Bramka każda OR i XOR (w zasadzie bramka AND oznacza 'dla każdego...") może być zamieniona na szereg wyjść warunkowych... czyli "praca" jest wykonana w "czynności", kontrola warunku(ów) to ostatni krok procedury danej czynności. Romb (diament ;) to "zobrazowanie" logiki tych warunków.

W "głupich" narzędziach symulacyjnych jest to określane % w mądrych tworzony jest warunek i weryfikowane jest spełnienie warunku. Ale do tego potrzebne są dane.

jaki warunek? mam pętlę "Opracowanie Oferty" gdzie odrzucenie treści przez szefa cofa Ofertę do kroku Opracowanie Oferty, gdzie i jakie warunki powinny być by nie była to pętla nieskończna? Rozumiem, że symulator może dostać regułę "do korekty wraca 15% Ofert" ale to nie zabezpiecza nas przed ryzykiem nieskonczoności trwania tej pętli, to tylko statystyka.

Nie zupełnie. Jeśli opracowanie oferty jest czynnością w pętli (Sequential Loop Task) to badany jest warunek wyjścia (badane jest, czy wartość wyrażenia jest prawdą).

ale wtedy ta pętla to "jedna czynność" na diagramie...

Jeśli pętla realizowana jest bramką to weryfikowane jest wyrażenie czy dla pierwszej ze ścieżek warunek ten jest prawdą (np. status zmiennej StatusOferty jest ustawiony na Tak). Jeśli nie to badany jest warunek dla następnej ścieżki. Jak widzisz nie ma tu nic z "przypadku". Zmiana statusu (zmiana wartości zmiennej czyli danej) jest możliwa jedynie w czynności.

owszem, bo "czynność to praca" (a nie bramka). Pytanie pozostaje: ile razy może wykonać sie ta pętla. Czynności Loop, kręci się i jest to kompetencja "wykonawcy" (nie modelujemy licznika tej petli) co najwyżej umieszczamy zdarzenie przerywające np. "po upływie dwóch dni" ale to nie licznik tylko przerwanie.

Temat: BPMN 2.0 WorkFlow Patterns

Jarek Żeliński:

Piotr Tadeusz B.:
Jedynie dane mogą być weryfikowane więc dane są elementem wyrażenia. Mogą odnosić się do procesu lub instancji procesu. Nie są manifestacją a reakcją na określoną strukturę danych. (Konkretnie na spełnienie określonego warunku / wyrażenia w przypadku XOR sprawdzanego w określonej kolejności.)

Bramka każda OR i XOR (w zasadzie bramka AND oznacza 'dla każdego...") może być zamieniona na szereg wyjść warunkowych... czyli "praca" jest wykonana w "czynności", kontrola warunku(ów) to ostatni krok procedury danej czynności. Romb (diament ;) to "zobrazowanie" logiki tych warunków.

"Praca" wykonywana jest jedynie w czynnościach. Bramka OR lub XOR jest reakcją na strukturyzowane dane zgodnie z podanymi warunkami wyjścia. Jeszcze raz zacytuję:
" A Decision can be thought of as a question that is asked at a particular point in the Process. The question has a defined set of alternative answers. Each answer is associated with a condition Expression that is associated with a Gateway’s outgoing Sequence Flows."

Innymi czynność (nie koniecznie poprzedzająca bramkę, ba niekoniecznie nawet w tym procesie w którm jest bramka - patrz przenoszenie danych komunikatem) ustawia dane a bramka realizuje wyjścia zgodnie z tymi danymi. (Z wyjątkiem bramek sterowanych zdarzeniami).

W "głupich" narzędziach symulacyjnych jest to określane % w mądrych tworzony jest warunek i weryfikowane jest spełnienie warunku. Ale do tego potrzebne są dane.

jaki warunek? mam pętlę "Opracowanie Oferty" gdzie odrzucenie treści przez szefa cofa Ofertę do kroku Opracowanie Oferty, gdzie i jakie warunki powinny być by nie była to pętla nieskończna? Rozumiem, że symulator może dostać regułę "do korekty wraca 15% Ofert" ale to nie zabezpiecza nas przed ryzykiem nieskonczoności trwania tej pętli, to tylko statystyka.

Nie zupełnie. Jeśli opracowanie oferty jest czynnością w pętli (Sequential Loop Task) to badany jest warunek wyjścia (badane jest, czy wartość wyrażenia jest prawdą).

ale wtedy ta pętla to "jedna czynność" na diagramie...

Dokładnie tak.

Jeśli pętla realizowana jest bramką to weryfikowane jest wyrażenie czy dla pierwszej ze ścieżek warunek ten jest prawdą (np. status zmiennej StatusOferty jest ustawiony na Tak). Jeśli nie to badany jest warunek dla następnej ścieżki. Jak widzisz nie ma tu nic z "przypadku". Zmiana statusu (zmiana wartości zmiennej czyli danej) jest możliwa jedynie w czynności.

owszem, bo "czynność to praca" (a nie bramka). Pytanie pozostaje: ile razy może wykonać sie ta pętla. Czynności Loop, kręci się i jest to kompetencja "wykonawcy" (nie modelujemy licznika tej petli) co najwyżej umieszczamy zdarzenie przerywające np. "po upływie dwóch dni" ale to nie licznik tylko przerwanie.

Pętla wykona się tyle razy ile razy potrzebne jest wykonanie danej czynności aby dane uzyskały odpowiednią wartość powodującą, że warunek wyjścia stanie się prawdą. Badane jest to parametrem "loopCondition" kiedy on stanie się prawdą wychodzimy z pętli. Nie wymaga to zdarzenia przerywającego. Kompetencja nie jest faktem. Kompetencja mówi jak można zmienić dane a wartość danych - jak zostały zmienione (lub nie).

Inne jest znaczenie zdarzenia przerywającego a inne "loopCondition" choć efekt jest podobny. Ale ta różnica to temat na oddzielną dyskusję :-) (jeśli chcemy mówić o precyzyjnym wyrażaniu sposobu realizacji procesu).

Temat: BPMN 2.0 WorkFlow Patterns

Piotr Tadeusz B.:
Each answer is associated with a condition Expression that is associated with a Gateway’s outgoing Sequence Flows."

w moich oczach "kluczem" jest słowo "Expression "...

Pętla wykona się tyle razy ile razy potrzebne jest wykonanie danej czynności aby dane uzyskały odpowiednią wartość powodującą, że warunek wyjścia stanie się prawdą.

dokładnie tak

Badane jest to parametrem "loopCondition" kiedy on stanie się prawdą wychodzimy z pętli. Nie wymaga to zdarzenia przerywającego.

Inne jest znaczenie zdarzenia przerywającego a inne "loopCondition" choć efekt jest podobny. Ale ta różnica to temat na oddzielną dyskusję :-) (jeśli chcemy mówić o precyzyjnym wyrażaniu sposobu realizacji procesu).

jeżeli np. jednym z warunków będzie "waga worka z piaskiem przekroczyła 10kg" to cykliczne (w pętli) dosypywanie ziarenka po ziarenku w końcu spowoduje spełnienie warunku i "wyjście" z czynności, zdarzenie przerywające może brzmieć "jeżeli upłynie tydzień od rozpoczęcia napełniania" spowoduje przerwanie...

Myślę, że mówimy o tym samym...:)

Temat: BPMN 2.0 WorkFlow Patterns

Jarek Żeliński:

Myślę, że mówimy o tym samym...:)

I mam nadzieję, że pomogło to innym lepiej zrozumieć BPMN :-D