Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Cześć,
oto treść zadania:

Poniżej zostały zamieszczone dwa diagramy. Twoim zadaniem jest znalezienie różnic pomiędzy nimi, oczywiście w kontekście ich wykonania. A może tych różnic nie ma wcale...:)

Najlepsze odpowiedzi zostaną nagrodzone:)

Oto diagramy:

Diagram_1




Diagram_2




POWODZENIA!!!

Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Na diagramie 2 brak zdefiniowanej ścieżki domyślnej, mimo że specyfikacja zaleca taką akcję. Oznacza to, że druga bramka może się nie doczekać na token i proces "zawiesi się" ?

Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Panie Pawle, dziękuję za odpowiedź.

Być może OMG zaleca użycie oznaczenia default flow, ale z pewnością nie wymaga jego użycia na diagramie.
W obydwu przypadkach można zdefiniować wymuszaną przez silnik kolejność wykonywania poszczególnych tasków - to kwestia implementacji. W obydwu przypadkach również możemy nie wykonywać żadnej czynności i przejść do zakończenia.

Czekam na inne odpowiedzi.
Pozdrawiam.

Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Wydaje mi się, że problem jest zbyt ogólny, bo mamy diagram, a nie znamy modelu, więc nie wiadomo czy są ścieżki domyślne czy nie, jak są określone warunki zakończenia procesów, warunki na bramkach itd.

Czy odpowiedź na pytanie początkowe ma mieć formę dyskusji? :) np. załóżmy, że dla procesu ad-hoc czynności mogą być wykonywane równolegle (ordering=Parallel) i ustalimy jakiś warunek zakończenia, oraz to, że czynności mogą zostać przerwane (cancelRemaining) w przypadku osiągnięcia warunku zakończenia procesu.

Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Krzysztof P.:
Cześć,
oto treść zadania:

Poniżej zostały zamieszczone dwa diagramy. Twoim zadaniem jest znalezienie różnic pomiędzy nimi, oczywiście w kontekście ich wykonania. A może tych różnic nie ma wcale...:)

Najlepsze odpowiedzi zostaną nagrodzone:)

Oto diagramy:

Diagram_1



Diagram_2



POWODZENIA!!!

Są to dwa skrajnie różne modele:
1. są cztery aktywności, to które i w jakiej kolejności się wydarzą zależą od czynników zewnętrznych, leżących poza "modelem"
2. deterministyczna wersja pierwszego

Na poziomie modeli biznesowych kluczowe założenie to uznanie, że system składa się z także ludzi, którzy maja prawo podejmować własne (nie będące algorytmem) decyzje, to znaczy, że nie ma możliwości przewidywania tego co zajdzie. Sam BPMN (specyfikacja) jasno wskazuje na dwa aspekty (rodzaje modeli) modelowania procesów w BPMN: executable i nonexecutable. Pierwsze to deterministyczne dla aplikacji typu "workflow engine", drugie to modele biznesowe (niedeterministyczne) opisujące organizację jako system reguł biznesowych i samodzielnych (niezależnych) zachowań ludzi (ról w procesach).

Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Jarosław Ż.:

Krzysztof P.:
Cześć,
oto treść zadania:

Poniżej zostały zamieszczone dwa diagramy. Twoim zadaniem jest znalezienie różnic pomiędzy nimi, oczywiście w kontekście ich wykonania. A może tych różnic nie ma wcale...:)

Najlepsze odpowiedzi zostaną nagrodzone:)

Oto diagramy:

Diagram_1



Diagram_2



POWODZENIA!!!

Są to dwa skrajnie różne modele:
1. są cztery aktywności, to które i w jakiej kolejności się wydarzą zależą od czynników zewnętrznych, leżących poza "modelem"
2. deterministyczna wersja pierwszego

Panie Jarosławie,
na czym polega dokładnie ta skrajna różnica? Nie do końca zrozumiałem Pańską argumentację. W obydwu przypadkach to, czy i które czynności zostaną wykonane, zależy tylko i wyłącznie od użytkownika/operatora. Ilość [0,n] i kolejność jest dowolna w dwóch przypadkach. Czy nie mam racji? :)

Poza tym OMG twierdzi, że w podprocesie "ad-hoc-owym" możemy ustalić pewne reguły zachowania za pomocą atrybutów typu kolejność, wymagalność, "czy zadanie kończące" itd. W obydwu przypadkach da się zrobić to samo .

Czy istnieją jeszcze jakieś różnice? :)

Na poziomie modeli biznesowych kluczowe założenie to uznanie, że system składa się z także ludzi, którzy maja prawo podejmować własne (nie będące algorytmem) decyzje, to znaczy, że nie ma możliwości przewidywania tego co zajdzie. Sam BPMN (specyfikacja) jasno wskazuje na dwa aspekty (rodzaje modeli) modelowania procesów w BPMN: executable i nonexecutable. Pierwsze to deterministyczne dla aplikacji typu "workflow engine", drugie to modele biznesowe (niedeterministyczne) opisujące organizację jako system reguł biznesowych i samodzielnych (niezależnych) zachowań ludzi (ról w procesach).

Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Są to dwa skrajnie różne modele:
1. są cztery aktywności, to które i w jakiej kolejności się wydarzą zależą od czynników zewnętrznych, leżących poza "modelem"
2. deterministyczna wersja pierwszego

Panie Jarosławie,
na czym polega dokładnie ta skrajna różnica? Nie do końca zrozumiałem Pańską argumentację. W obydwu przypadkach to, czy i które czynności zostaną wykonane, zależy tylko i wyłącznie od użytkownika/operatora. Ilość [0,n] i kolejność jest dowolna w dwóch przypadkach. Czy nie mam racji? :)

procesy ad-hoc nie są deterministyczne, wersja z bramką OR jest deterministyczna (muszą zostać warunki na bramce OR), aktywności ad-hoc (ich wykonanie) mogą stanowić widzimisię człowieka a więc nie są przewidywalne...

Poza tym OMG twierdzi, że w podprocesie "ad-hoc-owym" możemy ustalić pewne reguły zachowania za pomocą atrybutów typu kolejność, wymagalność, "czy zadanie kończące" itd. W obydwu przypadkach da się zrobić to samo .

słowo klucz: "możemy" a nie "musimy", jeżeli ustalimy takie reguły dla procesów ad-hoc stają się konkretną logiką np. OR

Po drugie jest jeszcze kwestia "pętli wstecz", jest ona możliwa na poziomie procedury (kilkanaście razy łopatą "w pętli" by napełnić taczkę piaskiem) ale czas płynie w jedną stronę, i na poziomie "co i po co robimy" pętla wstecz nie ma sensu bo czas się nie cofa, co najwyżej można powtórzyć ten sam proces kolejny raz (decyduje o tym człowiek) a to nie jest pętla (kto ją kontroluje?)

Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Jarku pętla powrotna na diagramie to nie powrót w czasie (diagramy BPMN nie uwzględniają czynnika czasowego) a po prostu ponowne wykonanie danego zadania.

Panie Krzysztofie. Ad Hoc może mieć dodatkowe atrybuty CompletitionCondition, który oznacza, że jeśli któraś z czynności go ustawi to przerywane jest wykonywanie innych, które dzieją się równolegle, ponadto - AdHocOredering, który może wymusić sekwencyjność wykonywanych czynności (mogą w dowolnej kolejności ale nigdy współbieżnie). Bramka LUB nie przytrzyma żetonu ;-). Jarek ma rację, AdHoc wykorzystujemy do czynności "ręcznych". Do automatyzacji musimy go zamienić na jakąś logikę. Co wygrał Jarek :-D?

Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Piotr Tadeusz B.:
Jarku pętla powrotna na diagramie to nie powrót w czasie (diagramy BPMN nie uwzględniają czynnika czasowego) a po prostu ponowne wykonanie danego zadania.

To zależy od tego czy diagram to model procesy czy procedury. proces napełniania wiaderka łyżeczka to:
- puste wiaderko, aktywność napełniania, pełne wiaderko
- aktywność napełniania wiaderka ma procedurę: weź łyżeczkę piasku, wsyp do wiaderka, czy się przesypało? Nie wróc do początku, TAK - zakończ

oba to (mogą być) diagramy BPMN , pierwszy ma kontekt biznesowy (proces to chronologiczny łańcuch aktywości kończący się produktem), drugi procedura także modelowana z użyciem BPMN.

Panie Krzysztofie. Ad Hoc może mieć dodatkowe atrybuty CompletitionCondition, który oznacza, że jeśli któraś z czynności go ustawi to przerywane jest wykonywanie innych, które dzieją się równolegle, ponadto - AdHocOredering, który może wymusić sekwencyjność wykonywanych czynności (mogą w dowolnej kolejności ale nigdy współbieżnie). Bramka LUB nie przytrzyma żetonu ;-). Jarek ma rację, AdHoc wykorzystujemy do czynności "ręcznych". Do automatyzacji musimy go zamienić na jakąś logikę. Co wygrał Jarek :-D?

Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Piotr Tadeusz B.:
Jarku pętla powrotna na diagramie to nie powrót w czasie (diagramy BPMN nie uwzględniają czynnika czasowego) a po prostu ponowne wykonanie danego zadania.

Panie Krzysztofie. Ad Hoc może mieć dodatkowe atrybuty CompletitionCondition, który oznacza, że jeśli któraś z czynności go ustawi to przerywane jest wykonywanie innych, które dzieją się równolegle, ponadto - AdHocOredering, który może wymusić sekwencyjność wykonywanych czynności (mogą w dowolnej kolejności ale nigdy współbieżnie).

Też to doczytałem :)

Bramka LUB nie przytrzyma żetonu ;-).

Nikt od niej tego nie wymaga :)

Jarek ma rację, AdHoc wykorzystujemy do czynności "ręcznych". Do automatyzacji musimy go zamienić na jakąś logikę. Co wygrał Jarek :-D?

Werdyktu nie było, więc nie ma mowy jeszcze o nagrodach ;)
Użył Pan słowa sformułowania "czynności ręczne", a te raczej zawsze występują w automatyzowanym procesie, no chyba, że mówimy o całkowitym automacie - moim zdaniem niezmiernie rzadko się zdarzają...

Inną sprawą jest to, że atrybutów czynności ad-hocowych nie jesteśmy w stanie "łatwo" pokazać np. klientowi. A na tym kończy się ich praktyczne zastosowanie. Jak zauważył słusznie Pan Jarosław służą do zobrazowania procesu (nonexecutable BPMN), a nie do tworzenia oprogramowania (executable BPMN).

Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Krzysztof P.:

Piotr Tadeusz B.:
Jarku pętla powrotna na diagramie to nie powrót w czasie (diagramy BPMN nie uwzględniają czynnika czasowego) a po prostu ponowne wykonanie danego zadania.

Panie Krzysztofie. Ad Hoc może mieć dodatkowe atrybuty CompletitionCondition, który oznacza, że jeśli któraś z czynności go ustawi to przerywane jest wykonywanie innych, które dzieją się równolegle, ponadto - AdHocOredering, który może wymusić sekwencyjność wykonywanych czynności (mogą w dowolnej kolejności ale nigdy współbieżnie).

Też to doczytałem :)

Bramka LUB nie przytrzyma żetonu ;-).

Nikt od niej tego nie wymaga :)

Gdybyśmy chcieli za pomocą bramki zasymulować sekwencyjność wykonań musiałaby.

Jarek ma rację, AdHoc wykorzystujemy do czynności "ręcznych". Do automatyzacji musimy go zamienić na jakąś logikę. Co wygrał Jarek :-D?

Werdyktu nie było, więc nie ma mowy jeszcze o nagrodach ;)
Użył Pan słowa sformułowania "czynności ręczne", a te raczej zawsze występują w automatyzowanym procesie, no chyba, że mówimy o całkowitym automacie - moim zdaniem niezmiernie rzadko się zdarzają...

Czynności ręczne to najczęściej czynności inicjowane przez użytkownika, czynności wykonywane przez użytkownika ale zainicjowane przez system to czynności użytkownika user task. Ale tu silnik może uniemożliwić wybór dowolnej czynności do wykonania.

Inną sprawą jest to, że atrybutów czynności ad-hocowych nie jesteśmy w stanie "łatwo" pokazać np. klientowi.

Ja do tego wykorzystuje adnotacje.

A na tym kończy się ich praktyczne zastosowanie. Jak zauważył słusznie Pan Jarosław służą do zobrazowania procesu (nonexecutable BPMN), a nie do tworzenia oprogramowania (executable BPMN).

Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Użył Pan słowa sformułowania "czynności ręczne", a te raczej zawsze występują w automatyzowanym procesie, no chyba, że mówimy o całkowitym automacie - moim zdaniem niezmiernie rzadko się zdarzają...

nie mylmy modeli executable z non-executable
prawnik w ramach pewnej nadrzędnej aktywności "windykacja" może mieć kilka do wybory działań podejmowanych ad-hoc wedle uznania, nie ma sensu modelowanie wszelkich możliwych kombinacji bo musielibyśmy określić warunki na każdym "rombie" co może być niemożliwe (wedle uznania prawnika)

Poważanym błędem są próby pełnej algorytmizacji pracy firmy...

Inną sprawą jest to, że atrybutów czynności ad-hocowych nie jesteśmy w stanie "łatwo" pokazać np. klientowi. A na tym kończy się ich praktyczne zastosowanie. Jak zauważył słusznie Pan Jarosław służą do zobrazowania procesu (nonexecutable BPMN), a nie do tworzenia oprogramowania (executable BPMN).

atrybutów ad-hoc nie ma sensu tworzyć na poziomie non-executable

Jednak uwaga, pojęcie "czynność ręczna" nie oznacza "dowolna" ... ogólnie stosowanie "tasków" z symbolami w lewym górnym rogu na modelach non-executable nie bardzo ma sens

Temat: Zadanie do rozwiązania. Przewidziane NAGRODY!!!

Niestety tym razem nikt nie zdobył głównej nagrody - przechodzi ona do następnej edycji konkursu.

Dziękuję wszystkim za wartościową wymianę zdań.

Moja odpowiedź do konkursu:

W kontekście możliwej implementacji tych modeli nie ma żadnych różnic. Nie mają znaczenia nawet bramki, bo te również mogą być obsłużone jako rejestracja wyboru użytkownika. Efekt końcowy będzie taki, że możliwe będzie wykonanie dowolnych czynności dowolną ilość razy.

JEDYNA różnica między tymi modelami jest taka, że elementów AD-HOC nie wspiera żaden silnik BPM, więc o implementacji raczej nie powinniśmy tutaj mówić :)

Dziękuję i pozdrawiam!