Temat: Zagadka 2
Mam nadzieję, że tą "akademicką" dyskusją nie zanudzimy czytelników i że umożliwi Państwu zrozumienie istoty BPMN.
Stanisław Jerzy Niepostyn:
Piotr Tadeusz B.:
Witam
Chyba nie bardzo.
Czynność wysłania komunikatu jest wyraźnie sprecyzowanym obiektem w BPMN. Nie można wysłać komunikatu do dwu rożnych użytkowników. Byłoby to zdarzanie wielokrotne. Ale nie ma czynności "zdarzenia wielokrotnego". Dlatego moim zdaniem ten rysunek jest błędny.
Wydaje mi się, że znacznik wieloinstancyjności ma inne znaczenie. Powiązany jest z atrybutem mówiącym ile instancji musi się wykonać aby ukończyć współpracę lub choreografię (9.2.1 Participants, Sekcja Participant Multiplicity str. 117-118).
A mi się wydaje, iż rozważa Pan drogę tokenu, co miałoby wtedy uzasadnienie, ale rzecz w tym, że przepływem komunikatu token nie może być przesłany. Czyli zdarzenie wielokrotne nie gra przy tym jakiejkolwiek roli.
Zupełnie błędne założenie. Token nie jest przesyłany ale wyzwala bądź reaguje na stany w innym procesie. Ta zmiana stanów bądź reakcja na nie to zdarzenia w BPMN.
Wracając do "naszych baranów"
Tabela 9.5 ParticipantMultiplicity attributes specyfikacji określa:
Attribute Name
minimum: integer = 0
Description/Usage
The minimum attribute defines minimum number of Participants that
MUST be involved in the Collaboration. If a value is specified in the
maximum attribute, it MUST be greater or equal to this minimum value.
Attribute Name
maximum: integer [0..1] = 1
Description/Usage
The maximum attribute defines maximum number of Participants that MAY
be involved in the Collaboration. The value of maximum MUST be one or
greater, AND MUST be equal or greater than the minimum value.
Wskazuje to wyraźnie na możliwość zaangażowania we współprace lub choreografię więcej niż jednego uczestnika. I to pokazaniu tego faktu służy znacznik wieloinstancyjności.
Więc podobnie jak na rys. 9.8 strony przez Pana przywołanej (117) Supplier reprezentuje kilku Wysyłających, czy Odbierających. Zaś wartość atrybutu ParticipantMultiplicity (a w zasadzie atrybut maximum) odpowiada za pojawienie się, bądź nie tegoż znacznika.
Mam wrażenie, że Wytwórca mozę w ramach jednej współpracy komunikować się z wieloma dostawcami (i tak jest po pokazane na rysunku), natomiast nie wydaje mi się, aby mogło być wielu Wysyłających komunikujących się z jedną instancją operacji Emcs co Pan narysował.
Gdyby jednak (hipotetycznie) tak było to pojedyncza instancja musiała by być zainicjowana po pojawieniu się odpowiedniej ilości komunikatów (co pokazywane by było zdarzeniem wielokrotnym równoległym).
Jak sobie z tym radzi modeler to inna sprawa, którą standard BPMN 2.0 oddaje do dyspozycji producenta ;)
Tu modeler nie ma nic wspólnego. Tu chodzi o naturę komunikacji.
Ale czego tam jeszcze brakuje z punktu widzenia standardu BPMN 2.0 ???
???
Może jaśniej: czy komunikaty wysyłane z zadania 02 i 06 będą zawierały jakieś dane ?
Nie ma znaczenia. Znów przytoczę specyfikację:
(10.2.3.1 Types of Tasks, sekcja Send Task str. 159)
A Send Task is a simple Task that is designed to send a Message to an external Participant (relative to the Process). Once the Message has been sent, the Task is completed.
Komunikat jest pojęciem elementarnym. Nie ma "wielokomunikatów" więc nie można takiego samego komunikatu wysłać do różnych uczestników jako jednego zadania (co jest na rysunku).
Wbrew pozorom IE818 to dwa komunikaty różniące się kluczami korelacyjnymi.
To prawda, że w BPMN 2.0 poprzez wyeksponowanie "kluczy korelacyjnych" pomiędzy procesami odrobinę zagubiła się przejrzystość wykonywania komunikatów. Zadziałała zasada "skoro ja rozumiem to dla wszystkich powinno być zrozumiałe".
Linie komunikatu muszą być przyłączone do krawędzi uczestnika lub czynności (nie mogą wisieć w powietrzu)
Wystarczy przesunąć element Pool, by przekonać się, że linie komunikatu nie wiszą ;)
Próbowałem przesuwać, przesuwał mi się cały obrazek :-D
Inny element różniący się od iGrafx to Pool, ale w tym przypadku zgadza się dokładnie ze standardem BPMN 2.0, prawda ?
Nie zupełnie. Bo jak słusznie zauważył pan Adam:
"The label for the Pool MAY be placed in any location and direction within the Pool, but MUST be separated from the contents of the Pool by a single line"
A tu jest umieszczona poza obszarem uczestnika.
Tu raczej należałoby wskazać, że Pool musi być prostokątem i w sumie jest tym prostokątem, tyle, że trochę takim bardziej "intuicyjnym", gdyż taką właśnie grafikę udostępnia Topcased i muszę przyznać, że pierwszy raz tego typu uwagę usłyszałem ... ale etykieta jest wewnątrz partycji i jest oddzielona pojedynczą linią ;) Zaś biorąc pod uwagę rozdział 7.4 oraz 7.6 odnoszę wrażenie, że jest Pan, Panie Piotrze, bardziej wymagający, anizeli standard BPMN 2.0 ;) Wszak zasada "look-and-feel" nie została naruszona, prawda ?
Nie jestem bardziej wymagający. To nie jest artefakt ani rozszerzenie specyfikacji.
Uczestnik MUSI być prostokątem a nie prostokątem z "pipsztynkiem". I tu Topcased dał ... no nie rozpisujmy się czego. :-D
Jestem inżynierem i nauczono mnie trzymania się specyfikacji. Dlatego się czepiam. Inżynierowie mają często do czynienia z ludźmi "słabszymi intelektualnie", którzy jeśli sobie coś muszą dopowiedzieć to na ogół robią to źle. (Pamiętam dywagacje na tema zachowania się "czegośtam" a to po prostu był niedorysowany element. Za to moje stwierdzenie chciano mnie zlinczować i odsądzano od czci i wiary - bo przecież w tym niedorysowaniu musiało być jakieś znaczenie). Precyzyjne trzymanie się specyfikacji minimalizuje to ryzyko.
Na pocieszenie - we WSZYSTKICH implementacjach znajdowałem błędy. (Mogę ję pokazać nawet na edytorze wykorzystywanym do ilustrowania specyfikacji). :-(
Myślę, że przy BPMN nie wzorowano się na standardzie UML :-D.
BPMN powstał w zupełnie innej organizacji, która dopiero później przyłączyła się do OMG.
Wersje 1.x tak, natomiast wersja BPMN 2.0 jako żywo przypomina UML 2.0.
To efekt standaryzacji tworzenia dokumentacji w OMG. Wszystkie nowe specyfikacje tak wyglądają.
Nie chcę Pana obciążać wczytywaniem sie w standard UML 2.x, jednakże proponuję się przyjrzeć spisowi treści. W BPMN 2.0 i UML 2.x spis treści poukładano według modeli. Zachowano jedynie w BPMN poczętek wześniejszych wersji z wykazem większości symboli graficznych. W UML-u te wykazy umieszczono na końcu poszczególnych modeli. Natomiast w obu standardach w poszczególnych modelach bardziej szczegółowo opisane są wszystkie elementy poszczególnych modeli wraz z diagramami klas przedstawiającymi meta-modele.
Nota bene moje obserwacje wskazują, że ten standard OMG tworzenia dokumentacji wcale nie wpłynął na lepsze zrozumienie modelowania w BPMN. Moim zdaniem wiele rzeczy zaciemnił.
Ale z tego powodu się akurat nie martwię.
Bez dobrego szkolenia trudno zrozumieć a ja szkole :-D.
Czy we wcześniejszych wersjach BPMN była gdzieś mowa o diagramach klas prezentujących części metamodelu BPMN ?
Annex B w 1.2?
Choćby i z tego względu warto poznać standard UML :)
Co do analityków - zgadzam się :-) (tak samo jak programiści powinni znać podstawy BPMN)
Co do "biznesu" - czarno widzę.
Proszę wszystkich moich uwag nie traktować jako czepianie się ale jako temat do przemyśleń nad BPMN i przybliżanie jego zawiłości mniej zaawansowanym użytkownikom.
Bardzo fajnie, że wreszcie znalazłem osobę, z którą mogę pospierać się na temat BPMN 2.0 :)
Tylko spór (czyli sytuacja, gdy ludzie prezentują różne poglądy) prowadzi do poznania. :-)
пропозиції роботи
