Temat: BPMN 2.0 - jakie macie pierwsze odczucia?

Im dłużej korzystam z 2 tym bardziej się do niej przekonuję, ale nie wszystko mi się w niej podoba. Zachwycony jestem procesami zdarzeniowymi (przerywającymi i nie), sprzeciw budzą bramki inicjujące. A jakie są Wasze odczucia?

Temat: BPMN 2.0 - jakie macie pierwsze odczucia?

Piotr Tadeusz B.:
Im dłużej korzystam z 2 tym bardziej się do niej przekonuję, ale nie wszystko mi się w niej podoba. Zachwycony jestem procesami zdarzeniowymi (przerywającymi i nie), sprzeciw budzą

chodzi zapewne o Event Sub-Process, ale zaproponowana przez Ciebie nazwa bardzo mi sie nie podoba. lepszy sens oddawałaby nazwa: podproces (autonomiczny ?) obsługujący zdarzenie, ale ...
A może (pod)proces autonomiczny ?
Mechanizm ten bardzo mi przypomina zerżnięcie UML-owego mechanizmu regionu rozszerzającego, czy obsługe wyjątków. W sumie w UML te mechanizmy właśnie bardzo dobrze nadaja się do modelowania takich autonomicznych podprocesów obsługujących jakieś zdarzenia. Natomiast nie wiem jaki sens ma odseparowanie tych podprocesów od procesu macierzystego.
Czyli faktycznie można trochę więcej zamodelować tyle, że zastanawiam się też jak to przetransformować do BPEL-a, czy XPDL-a. Załozyć dla workflow, że graf nie będzie spójny ? Byłoby to bardzo niebezpieczne...

bramki inicjujące. A jakie są Wasze odczucia?

Co to są bramki inicjujące ? Czy chodzi Ci o to, że sterowanie dla danego swimlane'a (aktora) może być inicjowane przez innego aktora ?

Dla mnie ciekawym rozwiązaniem są elementy choreograficzne. Bardzo fajnie można uprościć wiele diagramów (można modelować bardziej kontekstowe modele), ale dużym problemem, moim zdaniem, okazuje się przechodzenie pomiędzy choreografią, a orkiestracją. O ile np. procesy mozna zwijać i rozwijać poprzez ukrywanie, bądź odkrywanie wewnętrznych elementów, to dla przejść choreografia-orkiestracja krawędzie z komunikatami mają zupełnie różne punkty zakotwiczenia ! A jeszcze jak to zapisać w BPEL, czy XPDL ???
Podobnie sprawa ma się z elementami konwersacyjnymi.

Najbardziej jednak podoba mi się zbliżenie notacji do istniejących rozwiązań w systemach BPM. Np. w Documentum mamy czynności manualne, systemowe, związane z wysłaniem mejla itp. i takie równiez widzę doszły rodzaje task-ów. Wydaje mi się, że tutaj mozna się pokusić o rozszerzenie typów zadań - np. odczyt daych, zapis danych itp.

Ciekawostką jest DataStore.

Temat: BPMN 2.0 - jakie macie pierwsze odczucia?

Piotr Tadeusz B.:
Im dłużej korzystam z 2 tym bardziej się do niej przekonuję, ale nie wszystko mi się w niej podoba. Zachwycony jestem procesami zdarzeniowymi (przerywającymi i nie), sprzeciw budzą bramki inicjujące. A jakie są Wasze odczucia?

Zaczyna implementować wymagania XPDL i chyba odchodzi się od BPEL.... co masz na myśli pisząc "bramka inicjująca"?

Temat: BPMN 2.0 - jakie macie pierwsze odczucia?

Bramka zdarzeniowa inicjująca - taki dziwny stwór.
Jako Bramka Równoległa oznacza, że jeśli dane zdarzenie ma miejsce to inicjowany jest proces a potem inicjowane są jego dalsze gałęzie podpięte pod zdarzenia. Jako bramka wyłączna oznacza, że musi zaistnieć jedno zdarzenie, żeby proces się zainicjował a pozostałe się nie wykonują.Piotr Tadeusz B. edytował(a) ten post dnia 13.04.11 o godzinie 22:36

Temat: BPMN 2.0 - jakie macie pierwsze odczucia?

Piotr Tadeusz B.:
Bramka zdarzeniowa inicjująca - taki dziwny stwór.
Jako Bramka Wyłączna oznacza, że jeśli dane zdarzenie ma miejsce to inicjowany jest proces a potem inicjowane są jego dalsze gałęzie podpięte pod zdarzenia. Jako bramka równoległa oznacza, że muszą zaistnieć wszystkie zdarzenia, żeby proces się zainicjował.

od strony logiki była już wcześniej chyba dopuszczalna konstrukcja polegająca na "zebraniu" na wejściu więcej niż jednego zdarzenia inicjującego dany proces ...?

Temat: BPMN 2.0 - jakie macie pierwsze odczucia?

Stanisław Jerzy Niepostyn:

Piotr Tadeusz B.:
Im dłużej korzystam z 2 tym bardziej się do niej przekonuję, ale nie wszystko mi się w niej podoba. Zachwycony jestem procesami zdarzeniowymi (przerywającymi i nie), sprzeciw budzą

chodzi zapewne o Event Sub-Process, ale zaproponowana przez Ciebie nazwa bardzo mi sie nie podoba. lepszy sens oddawałaby nazwa: podproces (autonomiczny ?) obsługujący zdarzenie, ale ...
A może (pod)proces autonomiczny ?

W mojej propozycji nazwy był skrót myślowy. Moim zdaniem powinno być Podproces inicjowany zdarzeniem, ale Autonomiczny podproces obsługujący zdarzenie też brzmi dobrze i oddaje ducha.

Mechanizm ten bardzo mi przypomina zerżnięcie UML-owego mechanizmu regionu rozszerzającego, czy obsługe wyjątków. W sumie w UML te mechanizmy właśnie bardzo dobrze nadaja się do modelowania takich autonomicznych podprocesów obsługujących jakieś zdarzenia. Natomiast nie wiem jaki sens ma odseparowanie tych podprocesów od procesu macierzystego.

Tu się kłania filozofia BPMNu jako narzędzia modelowania procesów.
Odseparowane bo dzieją się "obok" normalnego procesu i służą obsłużeniu pewnego stanu, który się pojawił.

Czyli faktycznie można trochę więcej zamodelować tyle, że zastanawiam się też jak to przetransformować do BPEL-a,

Może w BPELu też pojawią się takie konstrukcje?

czy XPDL-a.

Też pewnie będzie, ale OMG daje też alternatywę - plik XML - BPMN-XML2

Załozyć dla workflow, że graf nie będzie spójny ? Byłoby to bardzo niebezpieczne...

bramki inicjujące. A jakie są Wasze odczucia?

Co to są bramki inicjujące ? Czy chodzi Ci o to, że sterowanie dla danego swimlane'a (aktora) może być inicjowane przez innego aktora ?

To było już przy zwykłym zdarzeniu odebrania komunikatu.

Dla mnie ciekawym rozwiązaniem są elementy choreograficzne. Bardzo fajnie można uprościć wiele diagramów (można modelować bardziej kontekstowe modele), ale dużym problemem, moim zdaniem, okazuje się przechodzenie pomiędzy choreografią, a orkiestracją. O ile np. procesy mozna zwijać i rozwijać poprzez ukrywanie, bądź odkrywanie wewnętrznych elementów, to dla przejść choreografia-orkiestracja krawędzie z komunikatami mają zupełnie różne punkty zakotwiczenia ! A jeszcze jak to zapisać w BPEL, czy XPDL ???
Podobnie sprawa ma się z elementami konwersacyjnymi.

Najbardziej jednak podoba mi się zbliżenie notacji do istniejących rozwiązań w systemach BPM. Np. w Documentum mamy czynności manualne, systemowe, związane z wysłaniem mejla itp. i takie równiez widzę doszły rodzaje task-ów. Wydaje mi się, że tutaj mozna się pokusić o rozszerzenie typów zadań - np. odczyt daych, zapis danych itp.

Brak tego bo w BPMN odczyt / zapis danych nie występuje bez mechanizmu dlatego pokazuje się go albo komunikatem, skryptem, usługą, regułą biznesową, bądź informacyjnie artefaktami (przepraszam w nowej specyfikacje te artefakty nazywają się "danymi" a nie artefaktami)

Ciekawostką jest DataStore.

Temat: BPMN 2.0 - jakie macie pierwsze odczucia?

Jarek Żeliński:

Piotr Tadeusz B.: skorygował

Bramka zdarzeniowa inicjująca - taki dziwny stwór.
Jako Bramka Równoległa oznacza, że jeśli dane zdarzenie ma miejsce to inicjowany jest proces a potem inicjowane są jego dalsze gałęzie podpięte pod zdarzenia. Jako bramka wyłączna oznacza, że musi zaistnieć jedno zdarzenie, żeby proces się zainicjował a pozostałe się nie wykonują.

od strony logiki była już wcześniej chyba dopuszczalna konstrukcja polegająca na "zebraniu" na wejściu więcej niż jednego zdarzenia inicjującego dany proces ...?

Tak inicjujące zdarzenie równoległe.
Różnica polega na tym, że w bramce inicjującej jeden wystarczy doi zainicjowania w w zdarzeniu wymagane wszystkie.

Bramka wyłączna wyklucza zainicjowanie procesu przez przez "spóźnialskich". (Przy niezależnych każde by inicjowało nową instancję.

Przepraszam za miszmasz z moim pierwszym opisem. Powyższy (skorygowany) jest prawidłowy.