W 2011 roku jeden z wpi­sów o łama­niu zasad koń­czy­łem słowami:

Łamanie zasad UML nie jest dobrym pomy­słem. Od lat spraw­dza mi się porze­ka­dło, że ?jeże­li cze­goś nie potra­fi­my nary­so­wać to zna­czy, że jesz­cze tego nie rozu­mie­my?. Maskowanie bra­ku wie­dzy o tym ?jak?, kolej­ny­mi nowy­mi sym­bo­la­mi to tyl­ko ?sprze­da­wa­nie? pro­ble­mu dalej, bo jaki pro­blem pro­jek­to­wy roz­wią­zu­je stwo­rze­nie akto­ra Czas?. Analityk to ktoś, kto ana­li­zu­je by ?zro­zu­mieć?? a nie zapi­su­je jak dyk­ta­fon sło­wa np. zama­wia­ją­ce­go.1

Dwa tygo­dnie temu pisałem:

…w ramach zająć jakie pro­wa­dzę na uczel­ni (stu­dia nie­sta­cjo­nar­ne) są wykła­dy i labo­ra­to­ria z obsza­ru ana­liz i mode­lo­wa­nia z uży­ciem sfor­ma­li­zo­wa­nych nota­cji (UML, BPMN, SBVR). To zna­czy, że mam co roku kon­takt co naj­mniej z kil­ku­dzie­się­cio­ma oso­ba­mi zaj­mu­ją­cy­mi się prak­tycz­nym sto­so­wa­niem tych nota­cji. W ogrom­nej więk­szo­ści przy­pad­ków dostrze­gam ten sam pro­blem: brak wie­dzy i zro­zu­mie­nia poję­cia abs­trak­cji i umie­jęt­no­ści mode­lo­wa­nia war­stwy abs­trak­cyj­nej ana­li­zo­wa­ne­go pod­mio­tu2.

Formalizm

Jak już wspo­mi­na­łem przy oka­zji pisa­nia o UML 2.5, for­ma­lizm jest pod­sta­wą dowo­du popraw­no­ści two­rzo­nych mode­li. Jest pod­sta­wą spój­no­ści i nie­sprzecz­no­ści całej kon­struk­cji, jaką jest model okre­ślo­nej rze­czy­wi­sto­ści w przy­pad­ku ana­li­zy, lub model przy­szłej imple­men­ta­cji w przy­pad­ku projektowania.

Każda sfor­ma­li­zo­wa­na nota­cja to zestaw ele­men­tów mają­cych okre­ślo­ne nazwy i zasa­dy łącze­nia (seman­ty­ka i syn­tak­ty­ka). Notacja to okre­ślo­ny meta­mo­del a kon­kret­ne dia­gra­my – mode­le, to instan­cje tego meta­mo­de­lu. Metamodel to nic inne­go jak teo­ria mówią­ca, że dany sys­tem pojęć w spo­sób zupeł­ny opi­su­je rze­czy­wi­stość z okre­ślo­nej per­spek­ty­wy (w okre­ślo­nym para­dyg­ma­cie), a to zna­czy, że dana kon­kret­na rze­czy­wi­stość da się wyra­zić w posta­ci mode­lu wyko­na­ne­go z uży­ciem tej nota­cji zgod­nie z zało­żo­nym paradygmatem.

Cztery pozio­my abs­trak­cji w MOF.

Powyższe opi­sa­no na stro­nie OMG3 w posta­ci spe­cy­fi­ka­cji MOF4 (patrz rozdz. 8. Language Formalism) sta­no­wią­cej fun­da­ment pozo­sta­łych nota­cji na OMG​.org.

Generalnie nota­cja to zbiór ele­men­tów struk­tu­ral­nych oraz prze­strzeń poję­cio­wa (poję­cia, ich defi­ni­cje i syn­tak­ty­ka), z któ­rej czer­pie­my nazwy dla ele­men­tów struktury.

Notacje kon­kret­ne (UML, BPMN, SysML, itp.) to tak zwa­ne pro­fi­le, czy­li dodat­ko­we sys­te­my poję­cio­we roz­sze­rza­ją­ce pro­fil stan­dar­do­wy MOF.

Profil MOF jest bar­dzo ubo­gi, to w koń­cu fun­da­ment pozo­sta­łych nota­cji (nazy­wa­ny tak­że meta-meta­mo­del). Generalnie MOF ope­ru­je poję­ciem ele­men­tu struk­tu­ry, każ­dy ele­ment jest kla­sy­fi­ka­to­rem opi­sy­wa­nym z pomo­cą jego cech i ope­ra­cji. Instancjami klas są obiek­ty (lub instan­cje klas meta­mo­de­li). Elementy (instan­cje) są two­rzo­ne przez tak zwa­ne fabry­ki, są one tak­że ele­men­ta­mi j.w. Wszystkie ele­men­ty struk­tu­ry mode­li mają iden­ty­fi­ka­to­ry, są nimi uni­kal­ne nazwy. Źródłem nazw jest model poję­cio­wy zwa­ny prze­strze­nią poję­cio­wą (prze­strzeń nazw, name­spa­ce). Konkretne nota­cje i pro­fi­le mają swo­je dedy­ko­wa­ne dzie­dzi­no­we prze­strze­nie nazw. Specyfikacja każ­dej nota­cji opar­tej na MOF zawie­ra okre­ślo­ny zestaw pojęć, z któ­rych część ma postać gra­ficz­ną (nota­cja), część postać tak zwa­nych ste­reo­ty­pów a część postać nazw para­me­trów. Zestaw ten uzu­peł­nia­ją tak zwa­ne sło­wa klu­czo­we, mają­ce narzu­co­ne zna­cze­nie. Pojęcia te są zastrze­żo­ne, są inte­gral­ną czę­ścią nota­cji i co do zasa­dy nie wol­no ich re-defi­nio­wać. W UML opi­sa­no to tak5:

22 Standard Profile
22.1 Summary
The Standard Profile specifies a set of predefined standard stereotypes. A conforming tool shall support all of the stereotypes in the Standard Profile. […]
Annex C: Keywords
(normative)
UML keywords are reserved words that are an integral part of the UML notation and normally appear as text annotations attached to a UML graphic element or as part of a text line in a UML diagram. In UML, keywords are used for three different purposes:
1 To distinguish a particular UML concept (metaclass) from others sharing the same general graphical form. For instance, the ?interface? keyword in the header box of a classifier rectangle is used to distinguish an Interface from other kinds of Classifiers.
2 To distinguish a particular kind of relationship between UML concepts (meta-association) from other relationships sharing the same general graphical form. For example, dashed lines between elements are used for a number of different relationships, including Dependencies, relationships between UseCases and an extending UseCases, and so on.
3 To specify the value of some modifier attached to a UML concept (meta-attribute value). Thus, the keyword ?singleExecution? appearing within an Activity signifies that the ?isSingleExecution? attribute of that Activity is true.
Keywords are always enclosed in guillemets (?keyword?), which serve as visual cues to more readily distinguish when
a keyword is being used.

To wła­śnie sło­wa klu­czo­we (ich doda­wa­nie zgod­nie z zasa­da­mi two­rze­nie prze­strze­ni poję­cio­wych) są narzę­dziem roz­sze­rza­nia nota­cji, meto­dą jest sto­so­wa­nie ste­reo­ty­pów a całość nazy­wa się pro­fi­lo­wa­niem i pole­ga na two­rze­niu dodat­ko­wych typów dla już ist­nie­ją­cych pojęć. Nowym ste­reo­ty­pom moż­na nada­wać postać gra­ficz­ną (nota­cja) pod warun­kiem, że sym­bo­le te nie będą kształ­tem koli­do­wa­ły z już uży­wa­ny­mi (patrz: semiotyka).

Profilowanie

Profil to zestaw typów pojęć (ste­reo­ty­pów) i związ­ków mię­dzy (struk­tur) roz­sze­rza­ją­cych już dostęp­ne w danej nota­cji poję­cia i ele­men­ty, meto­dą budo­wa­nia ich dodat­ko­wych tak­so­no­mii (spe­cja­li­za­cje) a nie re-defi­nio­wa­nia ich!

Mechanizm roz­sze­rza­nia opi­sa­no wprost np. w nota­cji BPMN w rozdz 2.2.3 Visual Appearance6:

The following extensions to a BPMN Diagram are permitted:
? New markers or indicators MAY be added to the specified graphical elements. These markers or indicators could be used to highlight a specific attribute of a BPMN element or to represent a new subtype of the corresponding concept.
? A new shape representing a kind of Artifact MAY be added to a Diagram, but the new Artifact shape SHALL NOT conflict with the shape specified for any other BPMN element or marker.
? Graphical elements MAY be colored, and the coloring MAY have specified semantics that extend the information conveyed by the element as specified in this International Standard.
? The line style of a graphical element MAY be changed, but that change SHALL NOT conflict with any other line style REQUIRED by this International Standard.
? An extension SHALL NOT change the specified shape of a defined graphical element or marker (e.g., changing a square into a triangle, or changing rounded corners into squared corners, etc.).

Czyli: moż­na doda­wać pod­ty­py pojęć ist­nie­ją­cych, nale­ży zagwa­ran­to­wać semio­tycz­ną popraw­ność ich ewen­tu­al­nych repre­zen­ta­cji gra­ficz­nych: nie mogą one ani gra­ficz­nie ani poję­cio­wo koli­do­wać z dotych­cza­so­wy­mi ele­men­ta­mi. Robi się to z pomo­cą tak zwa­ne­go dia­gra­mu pro­fi­lu UML. W dobrych narzę­dziach CASE moż­na pro­fi­lo­wać, z uży­ciem dia­gra­mu pro­fi­lu i ste­reo­ty­pów, każ­dą nota­cję. Nie wol­no nicze­go re-definiować!

Te zasa­dy pozwa­la­ją na zacho­wa­nie jed­no­znacz­no­ści, wymie­nial­no­ści wyko­na­nych mode­li pomię­dzy róż­ny­mi narzę­dzia­mi CASE, jed­no­znacz­ność tre­ści w całym pro­ce­sie ana­li­zy i pro­jek­to­wa­nia. Umieszczenie na począt­ku doku­men­ta­cji (lub w załącz­ni­kach) wła­sne­go pro­fi­lu, jest ele­men­tem tej doku­men­ta­cji i wręcz obo­wiąz­kiem jej auto­ra. To zapew­nia zro­zu­mia­łość i jed­no­znacz­ność. Zwrócę uwa­gę, że nota­cja BPMN jest tak­że opar­ta na spe­cy­fi­ka­cji MOF i UML (pro­fil BPMN jest doku­men­to­wa­ny w UML) i moż­na ją roz­sze­rzać z uży­ciem stereotypów.

Zakończenie

W tym miej­scu nie­ste­ty muszę stwier­dzić, że wie­le osób nie prze­strze­ga tych zasad, co jest niczym innym jak nie­po­praw­nym sto­so­wa­niem tych nota­cji. Stosowanie wła­snych kon­wen­cji, nie­zgod­nych z meta­mo­de­lem, przede wszyst­kim pozba­wia nas moż­li­wo­ści kon­tro­li popraw­no­ści mode­li, a odbior­ców moż­li­wo­ści jed­no­znacz­nej interpretacji.

Rozczarowuje więc nie­co treść publikacji:

Restrykcyjne pil­no­wa­nie skład­ni jest dobre bo utrzy­mu­je model w stan­dar­dzie. Nie mniej jed­nak w wie­lu fir­mach meta­mo­del jest wypad­ko­wą nota­cji, przy­zwy­cza­jeń oraz zło­żo­no­ści danej orga­ni­za­cji. To spra­wia, że mode­le nie trzy­ma­ją się orto­dok­syj­nie stan­dar­du. To nie jest objaw bra­ku wie­dzy. To wynik świa­do­me­go dosto­so­wa­nia stan­dar­du do potrzeb fir­my.7

Z pierw­szym zda­niem cyta­tu wypa­da się zgo­dzić, ale tyl­ko z pierw­szym. Metamodel – popraw­nie wyko­na­ny – z zasa­dy nie może być nie­spój­ny i nie może być jaką­kol­wiek wypad­ko­wą czy kom­pro­mi­sem. Przyzwyczajenia do łama­nia zasad sto­so­wa­nia nota­cji w orga­ni­za­cji są tak samo szko­dli­we jak łama­nie zasad ruchu dro­go­we­go: ktoś taki sta­je się nie­prze­wi­dy­wal­ny. Czy to objaw bra­ku wie­dzy? Nie wiem, ale na pew­no objaw bra­ku odpo­wie­dzial­no­ści i bra­ku profesjonalizmu.

Dostosowanie nota­cji do potrzeb danej orga­ni­za­cji, czy wręcz dzie­dzi­ny, to czę­sta potrze­ba i dla­te­go pro­fi­lo­wa­nie jest inte­gral­ną czę­ścią każ­dej nota­cji. Łamanie zasad zawsze będzie tyl­ko łama­niem zasad, jeże­li robi to nie­pro­fe­sjo­nal­ny pra­cow­nik danej orga­ni­za­cji, moż­na mu to wyba­czyć, jed­nak nie powi­nien tego robić ktoś, kogo przed­mio­tem pra­cy jest pro­fe­sjo­nal­na usłu­ga. Owszem, klien­ci nie raz naci­ska­ją i wte­dy ana­li­tyk, dobry jak kie­row­ca, albo mimo to sto­su­je zasa­dy i wska­zu­je dla­cze­go, albo roz­sta­je się z pasażerem …

Niestety wie­le audy­tów, jakie wyko­nu­ję, poka­zu­je, że łama­nie zasad nie jest takie rzad­kie, i prę­dzej czy póź­niej stwa­rza poważ­ne kło­po­ty, bo nawet jeże­li autor dia­gra­mu przy­mknie na coś oczy, to na pew­no nie zro­bi tego żaden kom­pi­la­tor, ani bie­gły w sądzie, gdy­by doszło do spo­ru o jakość doku­men­tów i jej wpływ na krach projektu.

Dlatego nie nale­ży wyłą­czać pil­no­wa­nia skład­ni… Jeżeli narzę­dzie ma wady w tym obsza­rze, nale­ży zmie­nić narzę­dzie… lub same­mu wejść w rolę kon­tro­le­ra składni.

__________________
1.
Czas nie jest akto­rem sys­te­mu. IT​-Consulting​.pl. https://it-consulting.pl//2011/11/27/czas-nie-jest-aktorem-dla-systemu/. Published November 27, 2011. Accessed July 2, 2018.
2.
Żeliński J. BPMN… IT​-Consulting​.pl. https://it-consulting.pl//2018/06/18/mit-o-notacji-bpmn/. Published June 2, 2018. Accessed July 2, 2018.
3.
OMG​.org. OMG. https://​www​.omg​.org/. Published July 2, 2018. Accessed July 2, 2018.
4.
MOF. OMG. https://​www​.omg​.org/​s​p​e​c​/​MOF. Published November 1, 2016. Accessed July 2, 2018.
5.
OMG? Unified Modeling Language? (OMG UML?) Version 2.5.1.
6.
Business Process Model and Notation (BPMN) Version 2.0.2.
7.
Jak wyłą­czyć zasa­dy pil­no­wa­nia skład­ni połą­czeń w Enterprise Architect 14? Michał Wolski. . Published June 25, 2018. Accessed July 2, 2018.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 2 komentarzy

  1. Michał Wolski

    Jarku świet­ny tekst. Podpisuję się pod nim obie­ma ręka­mi. Mój wpis na blo­gu był bar­dzo tech­nicz­ny i odno­sił się do ułom­no­ści ostat­nie­go wyda­nia Enterprise Architect, gdzie zaszy­to nie­kom­plet­ny metamodel.
    Wskazywałem tyl­ko dro­gę wyj­ścia z trud­nej sytu­acji, gdy po aktu­ali­za­cji nie moż­na było zro­bić cze­goś co jest w stan­dar­dzie. Najbardziej bola­ło mnie to w ArchiMate, co też opisałem ?. 

    Wracając do Twojej wypo­wie­dzi. Tak samo jak Ty uwa­żam, że każ­de odej­ście od stan­dar­du gene­ru­je pro­ble­my porów­ny­wal­ne z łama­niem zasad ruchu dro­go­we­go. Wiem też, że cza­sem tak samo, jak prze­wo­żąc ładun­ki ponadnor­ma­tyw­ne (domy, ele­men­ty wia­tra­ków, czoł­gi itp.) łamie się, w usta­lo­ny spo­sób, zasa­dy ruchu dro­go­we­go. Podobnie w fir­mach sto­su­je się róż­ne roz­wią­za­nia roz­sze­rza­ją­ce nota­cję. Popieram te dzia­ła­nia, któ­re są wyko­na­ne w usta­lo­ny, nie­przy­pad­ko­wy i nie­cha­otycz­ny sposób. 

    W moim prze­ko­na­niu zapro­po­no­wa­ne przez Ciebie pro­fi­lo­wa­nie to naj­lep­sza dro­ga. Spisanie zasad mode­lo­wa­nia w danej orga­ni­za­cji, w rozu­mie­niu cze­go i jak uży­wa­my też jest pomoc­ne , choć cza­sem tro­chę roz­sze­rza” stan­dard. Takie wła­śnie postę­po­wa­nie rozu­miem jako świa­do­me dosto­so­wa­nia (roz­sze­rza­nie) stan­dar­du do potrzeb fir­my. Pozdrawiam ser­decz­nie Ciebie i Twoich Czytelników :-). Michał.

    1. Jaroslaw Zelinski

      Cytowanie Twojego tek­stu było przy­kła­dem tego, ze klien­ci naci­ska­ją, co potwier­dzasz ;), myślę, że co do zasad obaj się zga­dza­my :). Pozdrawiam 🙂

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.