Temat: Poziomy zgodności modelerów z BPMN 2.0

> Piotr Tadeusz B.:
> 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.:
> > > 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
:O

> > > > 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.
To ma Pan wielki problem :(
Rozdział 7.4:
"BPMN elements (e.g. Flow objects) MAY have labels (e.g., its name and/or other attributes) placed inside the shape, or above or below the shape, in any direction or location, depending on the preference of the modeler or modeling tool vendor."
Z jednej strony Pool musi mieć etykietkę wewnątrz prostokąta (9.1), a z drugiej może mieć na zewnątrz (7.4) !!!
Zatem mój Pool jest prostokątem z zewnętrzną etykietką oddzieloną pojedynczą linia od zawartości Pool'a. Zatem zgodnie z 7.4 zgadza się i częściowo z 9.1. Natomiast 7.4 z 9.1 jest w pewnej części ze soba sprzeczne. Mam rację ?


> 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.
Przecyzyjne trzymanie się specyfikacji 1.x spowodowało, że dla specyfikacji BPMN 2.0 trzeba zmieniać wszystkie zdarzenia, które nie przerywały czynności, a rysowane w kółeczku rysowanym ciągła linią, na zdarzenia nieprzerywające rysowane w kółeczku rysowanym przerywającą linią.
Stąd zawsze powtarzam, że ścisłe trzymanie sie specyfikacji jakiejkolwiek notacji nie jest najważniejsze.
Najważniejsze jest, by osoby uczestniczące w projekcie potrafiły się ze sobą skutecznie porozumiewać wykorzystując dowolne notacje.
>
> Na pocieszenie - we WSZYSTKICH implementacjach znajdowałem
> błędy. (Mogę ję pokazać nawet na edytorze wykorzystywanym do
> ilustrowania specyfikacji). :-(
Myślę, że warto jednak zwrócić uwagę na poziomy zgodności BPMN 2.0 i dopiero po deklaracji producenta o zgodności jego modelera wypowiadać się, czy jest to błąd, czy tylko rozszerzenie ponad jego poziom zgodności z BPMN 2.0

Temat: Poziomy zgodności modelerów z BPMN 2.0

Stanisław Jerzy Niepostyn:

Piotr Tadeusz B.:
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.:
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

:O

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". (...)

Jestem inżynierem i nauczono mnie trzymania się specyfikacji.

To ma Pan wielki problem :(
Rozdział 7.4:
"BPMN elements (e.g. Flow objects) MAY have labels (e.g., its name and/or other attributes) placed inside the shape, or above or below the shape, in any direction or location, depending on the preference of the modeler or modeling tool vendor."
Z jednej strony Pool musi mieć etykietkę wewnątrz prostokąta (9.1), a z drugiej może mieć na zewnątrz (7.4) !!!
Zatem mój Pool jest prostokątem z zewnętrzną etykietką oddzieloną pojedynczą linia od zawartości Pool'a. Zatem zgodnie z 7.4 zgadza się i częściowo z 9.1. Natomiast 7.4 z 9.1 jest w pewnej części ze soba sprzeczne. Mam rację ?

Wydaje się, że 7.4 jest ogólną zasadą (MOGĄ), która jest jednoznacznie doprecyzowana dla Uczestników w pkt. 9.1 (MUSZĄ). Innymi słowy jest zasadą wyłączającą.

To tak jak z prędkością w mieście.
Dopuszczalna prędkość w mieście to 50 km/h za wyjątkiem godzin nocnych, gdy jest dopuszczalna prędkość 60 km/h.
Jednak gdy jest znak ograniczenie do 50 (w dzień teoretycznie zbędny) to bez względu na porę dnia MUSI być 50.

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. (...) Precyzyjne trzymanie się specyfikacji minimalizuje to ryzyko.

Przecyzyjne trzymanie się specyfikacji 1.x spowodowało, że dla specyfikacji BPMN 2.0 trzeba zmieniać wszystkie zdarzenia, które nie przerywały czynności, a rysowane w kółeczku rysowanym ciągła linią, na zdarzenia nieprzerywające rysowane w kółeczku rysowanym przerywającą linią.

W BPMN 1.x nie było zdarzeń nieprzerywających.

Stąd zawsze powtarzam, że ścisłe trzymanie sie specyfikacji jakiejkolwiek notacji nie jest najważniejsze.
Najważniejsze jest, by osoby uczestniczące w projekcie potrafiły się ze sobą skutecznie porozumiewać wykorzystując dowolne notacje.

Trudno mi się z tym zgodzić. To tak jakby ktoś powiedział trzymanie się gramatyki jest zbędne. Wystarczy, że się rozumiemy. No właśnie, czy zawsze wszyscy to samo rozumieją. I jak zrozumieją ci, którzy nie brali udziału w projekcie? I ja zrozumieją uczestnicy - ale za parę lat?

Na pocieszenie - we WSZYSTKICH implementacjach znajdowałem błędy. (Mogę ję pokazać nawet na edytorze wykorzystywanym do ilustrowania specyfikacji). :-(

Myślę, że warto jednak zwrócić uwagę na poziomy zgodności BPMN 2.0 i dopiero po deklaracji producenta o zgodności jego modelera wypowiadać się, czy jest to błąd, czy tylko rozszerzenie ponad jego poziom zgodności z BPMN 2.0

Staram się nie wypowiadać na temat zgodności modelerów a jedynie - modeli. Moja ręka nie jest zgodna z BPMN2.0 ale potrafię narysować zgodny model. :-)

Temat: Poziomy zgodności modelerów z BPMN 2.0

Piotr Tadeusz B.:

Stanisław Jerzy Niepostyn:

Piotr Tadeusz B.:
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.:
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

:O

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". (...)

Jestem inżynierem i nauczono mnie trzymania się specyfikacji.

To ma Pan wielki problem :(
Rozdział 7.4:
"BPMN elements (e.g. Flow objects) MAY have labels (e.g., its name and/or other attributes) placed inside the shape, or above or below the shape, in any direction or location, depending on the preference of the modeler or modeling tool vendor."
Z jednej strony Pool musi mieć etykietkę wewnątrz prostokąta (9.1), a z drugiej może mieć na zewnątrz (7.4) !!!
Zatem mój Pool jest prostokątem z zewnętrzną etykietką oddzieloną pojedynczą linia od zawartości Pool'a. Zatem zgodnie z 7.4 zgadza się i częściowo z 9.1. Natomiast 7.4 z 9.1 jest w pewnej części ze soba sprzeczne. Mam rację ?

Wydaje się, że 7.4 jest ogólną zasadą (MOGĄ), która jest jednoznacznie doprecyzowana dla Uczestników w pkt. 9.1 (MUSZĄ). Innymi słowy jest zasadą wyłączającą.

To tak jak z prędkością w mieście.
Dopuszczalna prędkość w mieście to 50 km/h za wyjątkiem godzin nocnych, gdy jest dopuszczalna prędkość 60 km/h.
Jednak gdy jest znak ograniczenie do 50 (w dzień teoretycznie zbędny) to bez względu na porę dnia MUSI być 50.

No dobra, dajmy na to Panie Piotrze, że dla specyfikacji BPMN 2.0 uwzględniamy również ustawę o ruchu drogowym ;)
W takim razie jak Pan wytłumaczy urywek znajdujący się parę wierszy za cytowanym przez Pana przepisem z użyciem frazy "MUSZĄ" ???
Oto ten urywek:
<<The use of text, color, size, and lines for a Pool MUST follow the rules defined in Section “Use of Text, Color, Size, and Lines in a Diagram” on page 41.>>
Jak więc jest z tymi prędkościami w mieście ? ;)
Poza tym wydaje mi się, że zdanie, na które Pan się powołuje <<BPMN elements (e.g. Flow objects) MAY have labels (e.g., its name and/or other attributes) placed inside the shape, or above or below the shape, in any direction or location, depending on the preference of the modeler or modeling tool vendor)>> odnosi się raczej do możliwości posiadania etykietki przez element BPMN, bądź jej nie posiadania, a nie do możliwości jej lokalizacji wewnątrz, czy na zewnątrz, nieprawdaż ? :)

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. (...) Precyzyjne trzymanie się specyfikacji minimalizuje to ryzyko.

Przecyzyjne trzymanie się specyfikacji 1.x spowodowało, że dla specyfikacji BPMN 2.0 trzeba zmieniać wszystkie zdarzenia, które nie przerywały czynności, a rysowane w kółeczku rysowanym ciągła linią, na zdarzenia nieprzerywające rysowane w kółeczku rysowanym przerywającą linią.

W BPMN 1.x nie było zdarzeń nieprzerywających.

Nie było, więc rysowano takie zdarzenia linią ciągła. Z chwilą ogłoszenia stadardu BPMN 2.0 zdarzenia te, które wcześniej miały znaczenie jako nieprzerywające, a mogły byc rysowane jeno ciągłą linią, muszą zostać jeszcze raz namalowane, ale z linią przerywaną.
Znaczy, że w standardzie BPMN 2.0 ikonki te trzeba gumeczką powycierać tak, by kółeczka były wygladające na rysowane linia przerywana, prawda ? ;)

Stąd zawsze powtarzam, że ścisłe trzymanie sie specyfikacji jakiejkolwiek notacji nie jest najważniejsze.
Najważniejsze jest, by osoby uczestniczące w projekcie potrafiły się ze sobą skutecznie porozumiewać wykorzystując dowolne notacje.

Trudno mi się z tym zgodzić. To tak jakby ktoś powiedział trzymanie się gramatyki jest zbędne. Wystarczy, że się rozumiemy. No właśnie, czy zawsze wszyscy to samo rozumieją. I jak zrozumieją ci, którzy nie brali udziału w projekcie? I ja zrozumieją uczestnicy - ale za parę lat?

Ależ wystarczy wziąć pod uwagę język angielski ... :)
To samo zdanie, a jak różnorodnie można je odczytać, prawda ?
<<BPMN elements (e.g. Flow objects) MAY have labels (e.g., its name and/or other attributes) placed inside the shape, or above or below the shape, in any direction or location, depending on the preference of the modeler or modeling tool vendor)>>

Na pocieszenie - we WSZYSTKICH implementacjach znajdowałem błędy. (Mogę ję pokazać nawet na edytorze wykorzystywanym do ilustrowania specyfikacji). :-(

Myślę, że warto jednak zwrócić uwagę na poziomy zgodności BPMN 2.0 i dopiero po deklaracji producenta o zgodności jego modelera wypowiadać się, czy jest to błąd, czy tylko rozszerzenie ponad jego poziom zgodności z BPMN 2.0

Staram się nie wypowiadać na temat zgodności modelerów a jedynie - modeli. Moja ręka nie jest zgodna z BPMN2.0 ale potrafię narysować zgodny model. :-)

Na razie standard BPMN 2.0 mówi jedynie o zgodności modelerów. Brak informacji o zgodności modeli, aczkolwiek w niektórych miejscach można znaleźć podobne kawałeczki jak "possible values and any specific semantic are out of scope of this specification" ....Stanisław Jerzy Niepostyn edytował(a) ten post dnia 23.02.12 o godzinie 15:45

Temat: Poziomy zgodności modelerów z BPMN 2.0

Podzieliłem na kawałki, aby było strawne.

Stanisław Jerzy Niepostyn:

(...)
Lokalizacja napisów

"The use of text, color, size, and lines for a Pool MUST follow the rules defined in Section “Use of Text, Color, Size, and Lines in a Diagram” on page 41."
Jak więc jest z tymi prędkościami w mieście ? ;)

Ma się Pan stosować do prędkości dozwolonych w mieście, chyba, że znaki nakazują inaczej. Albo - mandat.

Poza tym wydaje mi się, że zdanie, na które Pan się powołuje "BPMN elements (e.g. Flow objects) MAY have labels (e.g., its name and/or other attributes)
placed inside the shape, or above or below the shape, in any direction or location, depending on the preference of the modeler or modeling tool vendor)" odnosi się raczej do możliwości posiadania etykietki przez element BPMN, bądź jej nie posiadania, a nie do możliwości jej lokalizacji wewnątrz, czy na zewnątrz, nieprawdaż ? :)

Pool MUSI mieć etykietę, a specyfikacja w pkt. 9.1 dokładnie określa, gdzie ma być ta etykieta.
Inne elementy MOGĄ mieć etykietki (zgodnie z pkt. 7.4)
Przypadki szczególne ograniczają zasady ogóle a nie na odwrót.Piotr Tadeusz B. edytował(a) ten post dnia 23.02.12 o godzinie 22:49

Temat: Poziomy zgodności modelerów z BPMN 2.0

Stanisław Jerzy Niepostyn:

Zdazrenia nieprzerywające w BPMN 1.x

W BPMN 1.x nie było zdarzeń nieprzerywających.

Nie było, więc rysowano takie zdarzenia linią ciągła. Z chwilą ogłoszenia stadardu BPMN 2.0 zdarzenia te, które wcześniej miały znaczenie jako nieprzerywające, a mogły byc rysowane jeno ciągłą linią, muszą zostać jeszcze raz namalowane, ale z linią przerywaną.
Znaczy, że w standardzie BPMN 2.0 ikonki te trzeba gumeczką powycierać tak, by kółeczka były wygladające na rysowane linia przerywana, prawda ? ;)

Zapis przykładowy ze specyfikacji 1.x (tu 1.2)\
Tabela 9.8
"Message (...) If used for exception
handling, it will change the Normal Flow into an Exception Flow."
Jest ewidentnie i ZAWSZE przerywające.
Pozostałe zdarzenia - tak samo.

Jeśli ktoś stosuje nie przerywające zdarzenia w BPMN 1.x to robi błąd.

Temat: Poziomy zgodności modelerów z BPMN 2.0

Stanisław Jerzy Niepostyn:

Lingwistyka

Stąd zawsze powtarzam, że ścisłe trzymanie sie specyfikacji jakiejkolwiek notacji nie jest najważniejsze.
Najważniejsze jest, by osoby uczestniczące w projekcie potrafiły się ze sobą skutecznie porozumiewać wykorzystując dowolne notacje.

Trudno mi się z tym zgodzić. To tak jakby ktoś powiedział trzymanie się gramatyki jest zbędne. Wystarczy, że się rozumiemy. No właśnie, czy zawsze wszyscy to samo rozumieją. I jak zrozumieją ci, którzy nie brali udziału w projekcie? I ja zrozumieją uczestnicy - ale za parę lat?

Ależ wystarczy wziąć pod uwagę język angielski ... :)
To samo zdanie, a jak różnorodnie można je odczytać, prawda ?
"BPMN elements (e.g. Flow objects) MAY have labels (e.g., its name and/or other attributes) placed inside the shape, or above or below the shape, in any direction or location, depending on the preference of the modeler or modeling tool vendor)"

Dla mnie to zdanie jest jednoznaczne.

Ale czy można je tłumaczyć do różnych warrtości logicznych zostawmy lingwistom.
I niech oni określą, czy gramatyka jest już zbędna.Piotr Tadeusz B. edytował(a) ten post dnia 23.02.12 o godzinie 22:58

Temat: Poziomy zgodności modelerów z BPMN 2.0

Stanisław Jerzy Niepostyn:

Zgodność

Na razie standard BPMN 2.0 mówi jedynie o zgodności modelerów. Brak informacji o zgodności modeli, aczkolwiek w niektórych miejscach można znaleźć podobne kawałeczki jak "possible values and any specific semantic are out of scope of this specification" ....

Wydawało mi się, że cała specyfikacja określa co jest dozwolone w BPMN a co nie - a więc określa, jaki model jest zgodny z notacją.
I przeciwieństwie do narzędzi - tu nie ma "poziomów zgodności".
Albo model jest zgodny, albo nie.

Ale możliwe, że się mylę.

Temat: Poziomy zgodności modelerów z BPMN 2.0

Dodam od siebie, że z uwagi na "miękkość" języka specyfikacja BPMN (nie ona jednak) zawiera meta modele sformalizowane diagramem klas (UML) i tu nie ma "niejednoznaczności" interpretacji...

pojęcie poziomu zgodności jest dla mnie kuriozalne: albo coś jest z godne z czymś w 100% albo nie jest, w przeciwnym wypadku skazujemy się na dywagacje w rodzaju "tjaktoj sie zespiuł" znanego kabaretu Tey (Laskowik, Smoleń, Shubert) i gadanie w czy traktor bez koła jest dobry czy nie bo w końcu "trzy koła są dobre...".

Temat: Poziomy zgodności modelerów z BPMN 2.0

Piotr Tadeusz B.:

Stanisław Jerzy Niepostyn:

Zgodność

Na razie standard BPMN 2.0 mówi jedynie o zgodności modelerów. Brak informacji o zgodności modeli, aczkolwiek w niektórych miejscach można znaleźć podobne kawałeczki jak "possible values and any specific semantic are out of scope of this specification" ....

Wydawało mi się, że cała specyfikacja określa co jest dozwolone w BPMN a co nie - a więc określa, jaki model jest zgodny z notacją.
I przeciwieństwie do narzędzi - tu nie ma "poziomów zgodności".
Albo model jest zgodny, albo nie.

Ale możliwe, że się mylę.

Ano ... :)
Mówi się i opisuje się, że model jest "well-formed".
To znaczy, że zgodny jest z regułami składni danej notacji (np. graficznej), czy dowolnego innego języka formalnego.
Czasem też mówi się o stopniu odwzorowania przez dany model matematyczny innego modelu, czy rzeczywistości (części).
Bo jak model może być zgodny np. z rzeczywistością ??? ;)

Temat: Poziomy zgodności modelerów z BPMN 2.0

Bo jak model może być zgodny np. z rzeczywistością ??? ;)

Definicja modelu: uproszczenie rzeczywistości w określonym kontekście. Model więc nigdy nie jest zgodny (w 100%) z rzeczywistością... i nie musi, bo nie taki jest cel jego tworzenia... dlatego powstały tak zwane perspektywy lub pragmatyki.

Temat: Poziomy zgodności modelerów z BPMN 2.0

Piotr Tadeusz B.:
Podzieliłem na kawałki, aby było strawne.

Stanisław Jerzy Niepostyn:

(...)
Lokalizacja napisów

"The use of text, color, size, and lines for a Pool MUST follow the rules defined in Section “Use of Text, Color, Size, and Lines in a Diagram” on page 41."
Jak więc jest z tymi prędkościami w mieście ? ;)

Ma się Pan stosować do prędkości dozwolonych w mieście, chyba, że znaki nakazują inaczej. Albo - mandat.

Tak, ale jest to dokładnie opisane w Ustawie o ruchu drogowym.
Natomiast gdzie w specyfikacji BPMN 2.0 są opisane przez Pana zasady "stosowania prędkości" ?
Bo jeśli brak, to zazwyczaj mówi się o braku spójnosci specyfikacji ...

Poza tym wydaje mi się, że zdanie, na które Pan się powołuje "BPMN elements (e.g. Flow objects) MAY have labels (e.g., its name and/or other attributes)
placed inside the shape, or above or below the shape, in any direction or location, depending on the preference of the modeler or modeling tool vendor)" odnosi się raczej do możliwości posiadania etykietki przez element BPMN, bądź jej nie posiadania, a nie do możliwości jej lokalizacji wewnątrz, czy na zewnątrz, nieprawdaż ? :)

Pool MUSI mieć etykietę, a specyfikacja w pkt. 9.1 dokładnie określa, gdzie ma być ta etykieta.
Inne elementy MOGĄ mieć etykietki (zgodnie z pkt. 7.4)
Przypadki szczególne ograniczają zasady ogóle a nie na odwrót.

Wydaje mi się, że jest Pan w błędzie, gdyż:
1) taka zasada powinna być wpisana do specyfikacji (podobnie jak dla ruchu drogowego), ale na razie jej nie zauważyłem.
2) fragment metamodelu BPMN wyraźnie stanowi, iż figurka BPMN może posiadać kilka etykietek, co oznacza, że może nie posiadać żadnej - Figure B.12
3) element Pool może posiadać etykietkę, ale nie musi. Wynika to z reguły w 9.2, iż co najwyżej jeden Pool może nie posiadać granic. Jeśli nie musi być oznaczony prostokątem, to w takim przypadku taki Pool nie posiada siłą rzeczy etykietki, prawda ?
4) Cytowany przez Pana podpunkt z rozdziału 9.2 jest semantycznie zgodny z 7.4, a umieszczenie go tylko dla elementu Pool, bo inne elementy mają odwołanie tylko do 7.4 (Pool równiez ma), spowodowane zostało chęcią umieszczenia zasady, że etykietka elementu Pool ma być oddzielona pojedynczą linią od zawartości elementu Pool tylko wtedy, gdy Pool nie oznacza tzw. "black box". Co ciekawe w wersji 1.2 nie ma tej regułyStanisław Jerzy Niepostyn edytował(a) ten post dnia 25.02.12 o godzinie 20:32

Temat: Poziomy zgodności modelerów z BPMN 2.0

Piotr Tadeusz B.:

Stanisław Jerzy Niepostyn:

Lingwistyka

Stąd zawsze powtarzam, że ścisłe trzymanie sie specyfikacji jakiejkolwiek notacji nie jest najważniejsze.
Najważniejsze jest, by osoby uczestniczące w projekcie potrafiły się ze sobą skutecznie porozumiewać wykorzystując dowolne notacje.

Trudno mi się z tym zgodzić. To tak jakby ktoś powiedział trzymanie się gramatyki jest zbędne. Wystarczy, że się rozumiemy. No właśnie, czy zawsze wszyscy to samo rozumieją. I jak zrozumieją ci, którzy nie brali udziału w projekcie? I ja zrozumieją uczestnicy - ale za parę lat?

Ależ wystarczy wziąć pod uwagę język angielski ... :)
To samo zdanie, a jak różnorodnie można je odczytać, prawda ?
"BPMN elements (e.g. Flow objects) MAY have labels (e.g., its name and/or other attributes) placed inside the shape, or above or below the shape, in any direction or location, depending on the preference of the modeler or modeling tool vendor)"

Dla mnie to zdanie jest jednoznaczne.

Ale czy można je tłumaczyć do różnych warrtości logicznych zostawmy lingwistom.
I niech oni określą, czy gramatyka jest już zbędna.

Na ten fragment specyfikacji powołuje się również część standardu opisującego np. element SubProcess, po czym wręcz jawnie na stronie 174 zdanie opisuje "unlabeled expanded Sub-Process". Zatem zdaje się, że standard BPMN 2.0 interpretuje to zdanie podobnie jak ja.
Czyli wygląda nmi na to, że się powtórzę, Panie Piotrze, że jest Pan bardziej wymagający, aniżeli standard BPMN 2.0 ;)

Temat: Poziomy zgodności modelerów z BPMN 2.0

Piotr Tadeusz B.:

Stanisław Jerzy Niepostyn:

Zdazrenia nieprzerywające w BPMN 1.x

W BPMN 1.x nie było zdarzeń nieprzerywających.

Nie było, więc rysowano takie zdarzenia linią ciągła. Z chwilą ogłoszenia stadardu BPMN 2.0 zdarzenia te, które wcześniej miały znaczenie jako nieprzerywające, a mogły byc rysowane jeno ciągłą linią, muszą zostać jeszcze raz namalowane, ale z linią przerywaną.
Znaczy, że w standardzie BPMN 2.0 ikonki te trzeba gumeczką powycierać tak, by kółeczka były wygladające na rysowane linia przerywana, prawda ? ;)

Zapis przykładowy ze specyfikacji 1.x (tu 1.2)\
Tabela 9.8
"Message (...) If used for exception
handling, it will change the Normal Flow into an Exception Flow."
Jest ewidentnie i ZAWSZE przerywające.
Pozostałe zdarzenia - tak samo.

Jeśli ktoś stosuje nie przerywające zdarzenia w BPMN 1.x to robi błąd.

Jak Pan myśli Panie Piotrze dlaczego wprowadzono zdarzenia nieprzerywające ?
Komuś się tak uwidziło, czy dlatego, że spora część użytkowników notorycznie "robiła błędy" według Pana ? ;)
W 1.2 dopuszczono 3 sposoby zrównoleglania przepływów.
Widać nie były wystarczające, więc w 2.0 dorzucono więcej.