Jak wyłączyć zasady pilnowania składni… Nie wyłączać!

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.

Język czy notacja czyli co?

Od cza­su do cza­su jestem pyta­ny czy UML, BPMN, itp.. to nota­cje czy języ­ki, a pada­ją nawet pyta­nia czy to meto­dy. Otóż meto­dy na pew­no nie… (np. mamy dwie meto­dy mode­lo­wa­nia pro­ce­sów biz­ne­so­wych: z uży­ciem nota­cji BPMN i nota­cji eEPC). A pozo­sta­łe dwa?

Nie jest to pro­ste. Dzisiaj pój­dę może nie­co na skró­ty dla­te­go wni­kli­wym pole­cam lek­tu­rę przede wszyst­kim na temat semio­ty­ki, logi­ki i rachun­ku zdań.

Język i znaczenie

Na począ­tek kil­ka defi­ni­cji ogól­nych (wszyst­kie sł. j. pol­skie­go PWN):

język
5. ?utrwa­lo­ny spo­łecz­nie zespół zna­ków doty­czą­cych jakichś dzia­łań czło­wie­ka lub wyra­ża­ją­cych jego emo­cje oraz każ­dy układ ele­men­tów rze­czy­wi­sto­ści, któ­re­mu czło­wiek nadał jakąś treść?

Język jest więc okre­ślo­nym zespo­łem norm, są nimi jed­nak nie tyl­ko zna­ki ale tak­że to, co zna­czą i jaką treść nio­są. Wyrażanie emo­cji czy myśli w ogó­le, rzad­ko jest moż­li­we z uży­ciem tyl­ko jed­ne­go zna­ku. Dlatego w toku ich wyra­ża­nia ope­ru­je­my raczej zdaniami:

zda­nie
1. ?myśl wyra­żo­na słowami?
4. log. ?sen­sow­ne wyra­że­nie oznaj­mia­ją­ce pod­le­ga­ją­ce falsyfikacji?

Tu zaczy­na­my powo­li iść w porząd­ko­wa­nie tego o czym piszę. Każde zda­nie (w logi­ce) może być praw­dzi­we lub nie (tau­to­lo­gia jest zda­niem zawsze praw­dzi­wym, czy­li jest zna­ny fakt je fal­sy­fi­ku­ją­cy ale wie­my, że nigdy taki nie wystą­pi). Jeżeli więc, że treść naj­czę­ściej wyra­ża­my sło­wa­mi (a raczej rzad­ko nie jed­nym sło­wem) to zna­czy, że nale­ży umieć odczy­tać zna­cze­nie zło­że­nia wie­lu słów w jed­nym zda­niu. Jak wie­my o zro­zu­mia­ło­ści (zro­zu­mia­łość ozna­cza, że zda­nie ma dla czy­ta­ją­ce­go okre­ślo­ne zna­cze­nie) decy­du­je układ słów w zda­niu, zna­ki inter­punk­cyj­ne itp.

przecinek

Nawet prze­ci­nek ma zna­cze­nie (jest on ele­men­tem języ­ka) w zda­niu złożonym.

Jednoznaczność (zro­zu­mia­łość, zna­cze­nie) zdań jest tak­że efek­tem kontekstu:

kon­tekst
1. ?frag­ment tek­stu potrzeb­ny do dokład­ne­go rozu­mie­nia danych wyra­zów lub wyrażeń?
3. ?zespół jed­no­stek języ­ko­wych, któ­re sta­no­wią oto­cze­nie danej jednostki?
4. ?zespół odnie­sień nie­zbęd­nych do zro­zu­mie­nia utwo­ru lite­rac­kie­go, dzie­ła nauko­we­go itp.?

zakaz dobijania dziobem niejednoznacznoscJeżeli napi­szę Te dwie kro­wy są paskud­ne” to nadal nie ma pew­no­ści o czym mowa. Bez wie­dzy o tym, czy to roz­mo­wa dwóch rol­ni­ków o inwen­ta­rzu, czy też dwóch kole­ża­nek o dwóch innych, nie wie­my. Słowo palant” tak­że ma wię­cej niż jed­no zna­cze­nie i bez kon­tek­stu jego uży­cia nie wie­my o jakie zna­cze­nie cho­dzi (kole­ga czy mało już popu­lar­na gra) :). Bardzo czę­sto to wła­śnie kon­tekst nada­je znaczenie.

Jak widać zro­zu­mie­nie prze­ka­zu nie musi być pro­ste, a komu­ni­ka­cja pro­sta i łatwa (każ­dy kto się choć raz pokłó­cił z powo­du nie­po­ro­zu­mień o tym wie). Kontekstem zaj­mu­je się:

prag­ma­ty­ka
1. ?dział języ­ko­znaw­stwa, któ­re­go przed­mio­tem są spo­łecz­ne i sytu­acyj­ne warun­ki funk­cjo­no­wa­nia języ­ka oraz cele, jakie mówią­cy chce osią­gnąć przez uży­cie okre­ślo­nych wyra­zów i wyrażeń?

Należy pamię­tać, że zna­cze­nie mają nie tyl­ko poje­dyn­cze sło­wa (zna­ki) ale tak­że ich zło­że­nia („pro­ces biz­ne­so­wy” to jed­no poję­cie ale dwa sło­wa). Innymi sło­wy kon­kret­ne poję­cie może być zapi­sa­ne z uży­ciem jed­ne­go lub wię­cej znaków.

sło­wo
1. ?znak języ­ko­wy mają­cy jakieś znaczenie?

Dlatego zło­że­nie kil­ku zna­ków (słów) tak­że jest zna­kiem (defi­ni­cja sło­wa i słowo/pojęcie przez nią defi­nio­wa­ne, nio­są toż­sa­me zna­cze­nie). Słowo (rozu­mia­ne jako zapis: zło­że­nie liter) moż­na zastą­pić sym­bo­lem gra­ficz­nym (iko­na). O tym traktuje

semio­ty­ka
1. ?ogól­na teo­ria zna­ku w pro­ce­sie poro­zu­mie­wa­nia się ludzi?

w tym:

seman­ty­ka
1. ?dział języ­ko­znaw­stwa, któ­re­go przed­mio­tem jest ana­li­za zna­czeń wyrazów?
2. ?dział semio­ty­ki zaj­mu­ją­cy się bada­niem związ­ków, jakie zacho­dzą mię­dzy wyra­że­nia­mi języ­ka a przed­mio­ta­mi, do któ­rych się one odnoszą?

syn­tak­ty­ka
2. ?dział semio­ty­ki bada­ją­cy wza­jem­ne sto­sun­ki i wła­ści­wo­ści budo­wy wyra­żeń języ­ka w pro­ce­sie poro­zu­mie­wa­nia się ludzi?

Zapisując coś: treść, w celu prze­ka­za­nia jej dru­giej oso­bie komu­ni­ku­je­my się:

komu­ni­ka­cja
2. ?prze­pływ infor­ma­cji mię­dzy urzą­dze­nia­mi, np. tele­fo­na­mi lub komputerami?
3. ?prze­ka­zy­wa­nie i odbie­ra­nie infor­ma­cji w bez­po­śred­nim kon­tak­cie z dru­gą osobą?

treść
1. ?to, co jest zawar­te w czy­jejś wypo­wie­dzi; też: to, co prze­ka­zu­je odbior­cy dzie­ło sztu­ki, w prze­ciw­sta­wie­niu do formy?
2. ?to, co sta­no­wi isto­tę, sens czegoś?

Do komu­ni­ka­cji uży­wa­my znaków:

znak
1. ?kształt, któ­re­mu przy­pi­su­je się okre­ślo­ne znaczenie?
2. ?dźwięk, spoj­rze­nie, gest itp. słu­żą­cy do prze­ka­za­nia informacji?

Znak zna­czy, czy­li ma okre­ślo­ne znacz­nie (pamię­ta­my o kon­tek­ście). Znakiem może być wie­le rze­czy (tak­że gest). Znak ma (nie­sie) zna­cze­nie, znak lub ich zło­że­nie tak­że, prze­ka­zu­je okre­ślo­ną treść:

zna­cze­nie
1. ?myśl zawar­ta w czy­jejś wypo­wie­dzi, w czy­imś zacho­wa­niu itp.?
3. ?treść, któ­rej zna­kiem jest wyraz lub wyrażenie?

zna­czyć
1. ?być zna­kiem czegoś?
3. ?umiesz­czać na czymś lub na kimś znak?
4. ?zosta­wiać na czymś znak, ślad?

Na koniec zosta­wi­łem, spor­ne słowo:

nota­cja ?ozna­cze­nie cze­goś umow­ny­mi zna­ka­mi; też: zbiór takich znaków?

Notacja to zbiór zna­ków. Przypomnę też, że język to mie­dzy inny­mi okre­ślo­ny zbiór zna­ków wraz z opi­sem ich zna­czeń (seman­ty­ka) oraz tym, jakie mają zna­cze­nia ich okre­ślo­ne zło­że­nia (syn­tak­ty­ka). Wiemy już, że zna­cze­nie (treść) mają nie tyl­ko poje­dyn­cze sło­wa (to rzad­ko) ale ich kon­kret­ne zło­że­nia (zda­nia). Przekazanie kon­kret­nych, jed­no­znacz­nych tre­ści, poza rzad­ki­mi wyjąt­ka­mi, wyma­ga więc zbu­do­wa­nia kon­kret­nych zdań czy­li zło­żeń słów (zna­ków)”. Innymi sło­wy, nikt chy­ba nie powie, że książ­ka jaką jest słow­nik języ­ka pol­skie­go, wraz z zasa­da­mi gra­ma­ty­ki, to jest język pol­ski”. Język to jed­nak coś wię­cej”. Słowo język jest dość nie­pre­cy­zyj­ne i ozna­cza wręcz pewien zespół norm i spo­so­bów poro­zu­mie­wa­nia się (w tym idio­my, zespo­ły słów mają­ca inne zna­cze­nie niż każ­de z nich z osob­na). Poprawne (sku­tecz­ne) posłu­gi­wa­nie się danym języ­kiem ozna­cza, że adre­sat zro­zu­miał” treść nadaw­cy (mówią­ce­go).

Porządkujemy to wszystko

Zrobiło się cięż­ko :). Poniżej model poję­cio­wy: dia­gram w nota­cji SBVR poka­zu­ją­cy poję­cia i związ­ki mię­dzy nimi. Jednym z klu­czo­wych narzę­dzi w ana­li­zie jest wła­snie ana­li­za poję­cio­wa i budo­wa­nie słow­ni­ka pojęć dla okre­ślo­nej dzie­dzi­ny (tu wię­cej o tym czy jest dia­gram fak­tów opi­sa­ny w nota­cji SBVR).

jezyk-i-notacja-model-pojeciowy

Powyższy model obra­zu­je związ­ki pomię­dzy opi­sa­ny­mi wyżej poję­cia­mi, pre­cy­zu­je tak­że ich zna­cze­nia. Model poję­cio­wy dla danej dzie­dzi­ny (tu mowa o języ­kach i nota­cjach) powi­nien się cecho­wać mię­dzy inny­mi tym, że zna­cze­nia poszcze­gól­nych pojęć powin­ny być roz­łącz­ne, czy­li speł­niać ary­sto­te­le­sow­ską zasa­dę wyłą­czo­ne­go środ­ka” w logi­ce, brzmią­cą: jeże­li coś jest czymś, to nie jest niczym innym”. Dla zacho­wa­nia jed­no­znacz­no­ści zdań, defi­ni­cje pojęć muszą się więc wza­jem­nie wyklu­czać, tak zbu­do­wa­ny słow­nik nazy­wa­my prze­strze­nią nazw” (ang. namespace).

UML i BPMN to język czy notacja?

Skrót UML zawie­ra w sobie sło­wo lan­gu­age” (ang. język). Historycznie tłu­ma­czyć to moż­na tym, że obec­ne 14 typów dia­gra­mów to kon­kret­ne kon­tek­sty oraz narzu­co­ne kon­struk­cje, któ­re moż­na nazwać zda­nia­mi” (widać to szcze­gól­nie w przy­pad­ku dia­gra­mów Przypadków uży­cia czy Rozlokowania). Jednak obec­na spe­cy­fi­ka­cja UML 2.5 porząd­ku­je i to, sło­wo lan­gu­age” w zasa­dzie nie jest w niej sto­so­wa­ne wobec tego co nazwa­no tam mia­nem UML (W zasa­dzie dzi­siaj mogła by nosić nazwę Object-orien­ted Modeling and Notation 🙂 ).

Tak więc język czy nota­cja? To zale­ży od tego czy dana spe­cy­fi­ka­cja” opi­su­je wyłącz­nie sym­bo­le czy też ich okre­ślo­ne, i zale­ca­ne w okre­ślo­nych sytu­acjach, kon­struk­cje oraz ich zna­cze­nie. OMG (chy­ba) sta­ra się to ostat­nio jasno sygna­li­zo­wać: UML to jesz­cze lan­gu­age” ale BPMN to już nota­tion”. Specyfikacja UML zawie­ra okre­ślo­ne, seman­tycz­ne (nazwa­ne) kon­struk­cje, mają­ce okre­ślo­ne zna­cze­nia, zwią­za­ne z kon­kret­ny­mi dia­gra­ma­mi (nazwa dia­gra­mu nada­je kon­tekst uży­tym na nich sym­bo­lom, jest to potrzeb­ne bo pamię­taj­my, że w UML wszyst­ko jest kla­są”). W BPMN nie ma cze­goś takie­go (nawet poję­cie pro­ces biz­ne­so­wy” nie jest czę­ścią BPMN, jest ono zde­fi­nio­wa­ne dopie­ro w Dodatku A jako obja­śnie­nie i dodat­ko­wy kon­tekst, w nota­cji zaś BPMN nie ma sym­bo­lu pro­ces biz­ne­so­wy” 🙂 ). To czy dana spe­cy­fi­ka­cja to tyko opis nota­cji czy tak­że języ­ka, zale­ży więc od kon­kret­ne­go przypadku.

usuwanie dwuznaczosci i niejasnosciNiewątpliwie UML, BPMN, CMMN, SBVR, BMM itp., to wszyst­ko są nota­cje, bo są to spe­cy­fi­ka­cje sym­bo­li, ich zna­czeń oraz okre­ślo­na syn­tak­ty­ka. Natomiast o tym co i jak wyra­ża­ją (i czy w ogó­le ;)) two­rzo­ne z ich pomo­cą dia­gra­my, to już inna kwe­stia… To leży w gestii twór­cy dia­gra­mów. A testem jest mie­dzy inny­mi sku­tecz­ność komu­ni­ka­cji: porów­na­nie tego jaką kon­kret­ną treść chciał prze­ka­zać twór­ca dane­go dia­gra­mu i jaką treść ode­brał czy­ta­ją­cy… Analityk zaczy­na od ana­li­zy poję­cio­wej by unik­nąć nie­jed­no­znacz­no­ści w samym prze­ka­zie. Potem dopie­ro doku­men­tu­je, z uży­ciem mode­li two­rzo­nych z pomo­cą nota­cji, to co zastał oraz pro­jek­tu­je to, co chciał­by by, by powsta­ło spo­sób roz­wią­za­nie pro­ble­mu (tu pole­cam lek­tu­rę arty­ku­łu gdzie pisa­łem o tym, że wyma­ga­nia to pro­jekt).

Niewątpliwie więc wszyst­kie języ­ki pro­gra­mo­wa­nia” są języ­ka­mi: mają skład­nię i każ­de zda­nie coś wyra­ża (rozu­mie to i kole­ga pro­gra­mi­sta i kom­pi­la­tor). Wiele nota­cji jed­nak języ­kiem nie jest. O języ­ku moż­na mówić tyl­ko wte­dy, gdy jest samo­wy­star­czal­ny do wyra­ża­nia okre­ślo­nych myśli i tre­ści, do komu­ni­ko­wa­nia ich. Nie może­my tego raczej powie­dzieć o nota­cjach. Diagramy i mode­le wyko­na­ne z pomo­cą w. nota­cji wyma­ga­ją sto­so­wa­nia np. języ­ka” pol­skie­go, do nada­wa­nia nazw sym­bo­lom i dia­gra­mom, bez cze­go dia­gra­my te były by nie­zro­zu­mia­łe. Uważam więc, że uży­wa­nie wobec nota­cji obli­ga­to­ryj­nie nazwy język, jest poważ­nym nad­uży­ciem… Niektóre nota­cje mają swo­ją wer­sję wyko­ny­wal­ną (tu nawią­zu­je do tego że języ­ki pro­gra­mo­wa­nia są” języ­ka­mi”) o czym nie­daw­no pisa­łem (Analityczne i wyko­ny­wal­ne mode­le) jed­nak pamię­tać, nale­ży nota­cja jako taka nie jest języ­kiem pro­gra­mo­wa­nia”, jest tu raczej for­mą budo­wa­nia mecha­ni­zmu (mode­lo­wa­nie), któ­ry dopie­ro po doda­niu wie­lu para­me­trów (czy­li wpro­wa­dze­niu wie­lu słów” z poza nota­cji) pozwa­la taki model uru­cho­mić”.

klient, CRM, wróg, sprzedaż, wróg

Słownik pojęć biznesowych czyli po co nam przestrzeń nazw

Niedawno jeden z arty­ku­łów zakoń­czy­łem akapitem:

Pierwszy etap ana­li­zy biz­ne­so­wej to mię­dzy inny­mi opra­co­wa­nie biz­ne­so­we­go słow­ni­ka pojęć (model poję­cio­wy)… (Słownik pojęć biz­ne­so­wych: naj­bar­dziej pod­sta­wo­we wyma­ga­nie).

Nie każ­da jed­nak ana­li­za to ana­li­za, któ­rej celem jest opi­sa­nie wyma­gań i pro­jek­to­wa­nie opro­gra­mo­wa­nia. Jednak każ­da ana­li­za pro­ble­mu, pro­wa­dzo­na jako ana­li­za sys­te­mo­wa, ma usta­lo­ne eta­py postępowania:

  1. for­mu­ło­wa­nie problemu,
  2. opra­co­wa­nie mode­lu ana­li­zo­wa­ne­go zja­wi­ska (w tym dowód jego poprawności!),
  3. wykry­cie i testo­wa­nie wariantów,
  4. ana­li­za wyni­ków i rekomendacje,
  5. pro­jek­to­wa­nie rozwiązania.

Powyższe to, opar­te na kla­sycz­nej ana­li­zie sys­te­mo­wej, postę­po­wa­nie. Dzisiaj sku­pię się głów­nie na punk­cie opra­co­wa­nie mode­lu” gdyż bazą do jego two­rze­nia jest wła­śnie słow­nik pojęć. 

Jak nie raz tu pisa­łem, mode­le two­rzo­ne są z uży­ciem nota­cji. Notacja to sys­tem poję­cio­wy, pew­na prze­strzeń nazw (ang. name­spa­ce). Notacje mogą być gra­ficz­ne, wte­dy każ­de poję­cie ma przy­po­rząd­ko­wa­ny okre­ślo­ny uni­kal­ny sym­bol, two­rzo­ne z nich kon­struk­cje to dia­gra­my, będą­ce odpo­wied­ni­kiem zdań (popraw­ny dia­gram coś mówi”). Tak więc tyle krót­kie­go wprowadzenia.

Gdzie te słowniki?

Pierwszym eta­pem ana­li­zy sys­te­mo­wej jest zde­fi­nio­wa­nie pro­ble­mu, ten jest zwią­za­ny zawsze z okre­ślo­nym przed­mio­tem. Przedmiot ana­li­zo­wa­ny – sys­tem – musi mieć ści­śle okre­ślo­ne gra­ni­ce oraz jed­no­znacz­ny opis będą­cy mode­lem tego sys­te­mu. Aby taki opis mógł powstać, jak się zapew­ne już domy­śla­my, musi­my dys­po­no­wać zbio­rem jed­no­znacz­nych pojęć go opi­su­ją­cych – musi­my mieć ade­kwat­ną do pro­ble­mu i jego dzie­dzi­ny prze­strzeń nazw. Model sys­te­mu to jed­no­znacz­na defi­ni­cja tego czym jest i jak się zacho­wu­je (jak reagu­je na bodź­ce). Opis taki wyko­na­ny języ­kiem natu­ral­nym, nie nada­je się do ana­li­zy, język natu­ral­ny nie jest for­mal­ną prze­strze­nią nazw, i z regu­ły nie pozwa­la na jed­no­znacz­ne opi­sa­nie cze­goś (w złym mode­lu poję­cio­wym zna­cze­nia pojęć nie pokry­wa­ją całej prze­strze­ni, nakła­da­ją się).

przestrzen nazw

Tak więc do opra­co­wa­nia mode­lu wyma­ga­na jest nota­cja. Skąd ja wziąć? Jak ją wybrać? Jak widać, nota­cja musi być dosto­so­wa­na do dzie­dzi­ny pro­ble­mu. Notacje stan­dar­do­we, z regu­ły, są dość ogól­ne gdyż muszą zacho­wy­wać pew­ną uni­wer­sal­ność. Notacje stan­dar­do­we są dzie­dzi­no­we i tu dzie­dzi­ną tą jest okre­ślo­ny para­dyg­mat. Najbardziej zna­ny­mi nota­cja­mi sto­so­wa­ny­mi w ana­li­zie sys­te­mo­wej z obsza­ru zarzą­dza­nia i sys­te­mów infor­ma­cyj­nych są UML i BPMN. UML repre­zen­tu­je para­dyg­mat obiek­to­wy mówią­cy, że świat skła­da się ze współ­pra­cu­ją­cych obiek­tów mają­cych okre­ślo­ne cechy i moż­li­wo­ści (umie­jęt­no­ści). BPMN repre­zen­tu­je para­dyg­mat pro­ce­so­wy mówią­cy, że świat to zacho­dzą­ce w cza­sie pro­ce­sy two­rze­nia lub prze­kształ­ca­nia rze­czy­wi­sto­ści (nale­ży jed­nak dodać, że UML to tak­że dia­gra­my dyna­mi­ki sys­te­mu, mają­ce zwią­zek z para­dyg­ma­tem pro­ce­so­wym, nie nale­ży jed­nak mylić tego z poję­ciem pro­ces biznesowy”).

Poza tymi dwo­ma nota­cja­mi (moim zda­niem głów­ny­mi) mamy wie­le innych, spe­cy­ficz­nych dla okre­ślo­nych dzie­dzin i para­dyg­ma­tów, sys­te­mów poję­cio­wych (np. BMM czy SBVR).

Tak więc każ­da ana­li­za, powin­na być poprze­dzo­na wybo­rem nota­cji, któ­re zosta­ną w niej uży­te. Na pew­nym okre­ślo­nym pozio­mie abs­trak­cji wystar­czą poję­cia dostęp­ne w nota­cjach stan­dar­do­wych. Nie raz może się jed­nak zda­rzyć, że ana­li­za pro­ble­mu doty­ka szcze­gó­łów, któ­rych roz­róż­nia­nie nie jest moż­li­we z pomo­cą stan­dar­do­wej nota­cji. Każdy kon­kret­ny pro­blem ma swo­je kon­kret­ne śro­do­wi­sko dzie­dzi­no­we, może się zda­rzyć, że bar­dziej szcze­gó­ło­we niż uni­wer­sal­ne nota­cje. Wtedy nale­ży roz­sze­rzyć zasto­so­wa­ną nota­cję (prze­strzeń poję­cio­wą). Rozszerzanie to jed­nak wyma­ga prze­strze­ga­nia pew­nej zasa­dy: roz­sze­rze­nie to może pole­gać wyłącz­nie na zastę­po­wa­niu sta­rych” pojęć zesta­wem ich spe­cja­li­za­cji („sta­re” poję­cie sta­je się abs­trak­cją) oraz zestaw takich spe­cja­li­za­cji tak­że musi sta­no­wić lokal­ną prze­strzeń nazw. Taka dodat­ko­wa prze­strzeń nazw nazy­wa się pro­fi­lem nota­cji. Tworzenie pro­fi­li jest dość trud­nym zaję­ciem z uwa­gi na wymóg zacho­wa­nia opi­sa­nych for­ma­li­zmów prze­strze­ni poję­cio­wych (pro­fil tak­że musi mieć okre­ślo­na seman­ty­kę i syn­tak­ty­kę, któ­ra to nie może koli­do­wać z tą w nota­cji bazowej).

I tu docho­dzi­my do sed­na: aby stwo­rzyć pro­fil nota­cji – co cza­sa­mi bywa nie­zbęd­ne dla jako­ści ana­li­zy – nale­ży naj­pierw zbu­do­wać słow­nik pojęć z dzie­dzi­ny ana­li­zo­wa­ne­go pro­ble­mu, spraw­dzić czy zasto­so­wa­na nota­cja pozwa­la na roz­wią­za­nie posta­wio­ne­go pro­ble­mu z uży­ciem stan­dar­do­wej wer­sji nota­cji. Bez takie­go słow­ni­ka ana­li­za może być nie­wy­ko­ny­wal­na, albo jej jakość będzie bar­dzo niska – czy­taj: uży­cie jej wyni­ków będzie bar­dzo ryzykowne.

Takie pro­fi­le ma np. nota­cja BPMN w celu prze­cho­dze­nia z mode­li abs­trak­cyj­nych na wyko­ny­wal­ne, stan­dar­do­wo ope­ru­je się np. jed­nym poję­ciem czyn­ność, jeże­li potrzeb­ne jest ich roz­róż­nia­nie, prze­cho­dzi­my na sto­so­wa­nie sym­bo­li ozna­czo­nych jako czyn­ność ode­bra­nia komu­ni­ka­tu, czyn­ność wysła­nia komu­ni­ka­tu, czyn­ność manu­al­na, itp.. Dla nota­cji UML powsta­ło wie­le pro­fi­li np. dla kon­kret­nych języ­ków pro­gra­mo­wa­nia i ich środowisk.

Semiotics and the Philosophy of Language Umberto Eco

Semiotyka – czyli dlaczego sama notacja to za mało

Tym razem krót­ki wpis po pew­nym spo­tka­niu pro­jek­to­wym, dla two­rzą­cych i czy­ta­ją­cych diagramy:

Semiotyka, ogól­na teo­ria zna­ku zwią­za­na z logi­ką i lin­gwi­sty­ką. Jej współ­cze­sna postać pocho­dzi od Ch. Morrisa, któ­ry uznał, że semio­ty­ka powin­na sta­no­wić pod­sta­wę badań nad związ­ka­mi mię­dzy wszel­ki­mi dzia­ła­nia­mi ludz­ki­mi i ich odzwier­cie­dle­niem w sys­te­mie zna­ków. Semiotyka dzie­li się na:

1) seman­ty­kę (w węż­szym sen­sie), czy­li naukę o zna­cze­nio­wej stro­nie języ­ka, o tym, jakie rela­cje zacho­dzą mię­dzy zna­ka­mi i ich zna­cze­niem (sen­sem).

2) syn­tak­ty­kę roz­pa­tru­ją­cą związ­ki zacho­dzą­ce mię­dzy zna­ka­mi i mię­dzy sys­te­ma­mi znaków.

3) prag­ma­ty­kę bada­ją­cą warun­ki uży­cia okre­ślo­nych znaków.

(za Semiotyka – WIEM, dar­mo­wa encyklopedia).

Wobec tego w nawią­za­niu do powyższego:

  1. uży­cie for­mal­nej nota­cji i powo­ła­nie się na nią (nazwa stan­dar­du) w dia­gra­mie (opi­sie dia­gra­mu) ozna­cza 100% zgo­dę na for­mal­ne defi­ni­cje uży­wa­nych sym­bo­li i uzna­wa­nie ich,
  2. uży­cie for­mal­nej nota­cji i powo­ła­nie się na nią (nazwa stan­dar­du) w dia­gra­mie (opi­sie dia­gra­mu) ozna­cza sto­so­wa­nie for­mal­nych ogra­ni­czeń wyni­ka­ją­cych ze skoń­czo­nej licz­by dopusz­czal­nych (zde­fi­nio­wa­nych dla nota­cji) rela­cji pomię­dzy zna­cze­nia­mi (sym­bo­la­mi),
  3. i naj­waż­niej­sze: bez poda­nia warun­ków, celu i kon­tek­stu two­rzo­nych mode­li są one nie­zro­zu­mia­łe i (lub) niejednoznaczne!

Dlatego popraw­nie wyko­na­na doku­men­ta­cja np. pro­ce­sów biz­ne­so­wych z uży­ciem nota­cji np. BPMN, powin­na mieć na począt­ku”, mię­dzy inny­mi, kon­kret­ną defi­ni­cję pro­ce­su biz­ne­so­we­go sta­no­wią­ca kon­tekst dla sym­bo­lu czyn­ność” oraz dia­gra­mu będą­ce­go mode­lem pro­ce­su (BPMN nie ma sym­bo­lu o nazwie pro­ces”).

W przy­pad­ku UML dla każ­de­go dia­gra­mu nale­ży podać jego kon­tekst. Notacja UML jest nad­mia­ro­wa (nie trze­ba, a nawet nie nale­ży uży­wać wszyst­kich dopusz­czal­nych sym­bo­li). W szcze­gól­no­ści dia­gra­my klas i przy­pad­ków uży­cia mogą mieć wie­le kon­tek­stów, bez któ­rych mogą być wręcz nie­czy­tel­ne (np. dia­gram klas może być sys­te­mem pojęć – tak­so­no­mia – a może być struk­tu­rą kodu pro­gra­mu jako model dzie­dzi­ny systemu).

Wnikliwym pole­cam książ­kę Umberto Eco: teo­ria semio­ty­ki. Ostrzegam, że książ­ka nie ma nic wspól­ne­go z infor­ma­ty­ką za to jest w 100% o informacji. 🙂

Krótki wpis o śladowaniu

Często jestem pyta­ny: a co to jest to śla­do­wa­nie”? Artykuł adre­su­je nie tyl­ko ana­li­ty­kom, ale tak­że oso­bom zle­ca­ją­cym wyko­na­nie ana­li­zy, pro­jek­tu i ich doku­men­ta­cji. W arty­ku­le poda­je przy­kła­dy bazu­ją­ce na obiek­to­wych meto­dach i wzor­cach ana­li­tycz­nych jed­nak nie jest to wie­dza wyma­ga­na do jego zrozumienia.

Po kolei…

Jedną z cech doku­men­ta­cji wyso­kiej jako­ści, jest wywo­dze­nie (kon­stru­owa­nie) każ­de­go wyma­ga­nia i pozo­sta­łych ele­men­tów mode­li od ogó­łu do szcze­gó­łu (meto­da ana­li­zy top-down) i wery­fi­ko­wa­nie ich w dru­gą stro­nę (meto­da ana­li­zy bot­tom-up). Nazywane jest to coraz czę­ściej jako tak zwa­ne śla­do­wa­nie (zależ­ność «tra­ce» na mode­lach popu­la­ry­zo­wa­na przez orga­ni­za­cję IIBA). Śladowanie pozwa­la przede wszystkim:

  1. uza­sad­nić każ­de wymaganie,
  2. uza­sad­nić każ­dy ele­ment pro­jek­tu implementacji,
  3. zwe­ry­fi­ko­wać kom­plet­ność i spój­ność całej dokumentacji,
  4. zapo­biec nie kon­tro­lo­wa­ne­mu roz­ro­sto­wi zakre­su projektu,
  5. umoż­li­wia oce­nę ren­tow­no­ści pro­jek­tu per każ­de wyma­ga­nie niezależnie.

Cóż to jest śladowanie? 

Przede wszyst­kim potrzeb­ny jest szczyt”, korzeń drze­wa śla­do­wa­nia. Powinien nim być cel biz­ne­so­wy pro­jek­tu, jak nie trud­no się domy­śleć, dla jed­ne­go pro­jek­tu powi­nien być zde­fi­nio­wa­ny jeden cel głów­ny, on wyzna­cza kie­ru­nek. Możliwe są cele skła­do­we, pod­rzęd­ne, ale jeden głów­ny jest wymagany.

Jednym z pod­sta­wo­wych ele­men­tów stra­te­gii osią­ga­nia celów biz­ne­so­wych jest ulep­sza­nie pro­ce­sów biz­ne­so­wych w orga­ni­za­cji. w tym celu wyko­nu­je się audyt orga­ni­za­cji, któ­re­go pro­duk­tem jest jej peł­ny model, ten zawie­ra mię­dzy inny­mi, jako skła­do­we, mode­le pro­ce­sów biznesowych.

Każdy pro­ces biz­ne­so­wy to jed­na lub sze­reg powią­za­nych czyn­no­ści. Wymagania są koja­rzo­ne (wywo­dzo­ne) z tych czyn­no­ści, któ­re pla­nu­je­my uspraw­nić np. z pomo­cą narzę­dzia jakim jest pla­no­wa­ne nowe lub roz­bu­do­wy­wa­ne oprogramowanie.

W przy­pad­ku opro­gra­mo­wa­nia dedy­ko­wa­ne­go, to jest two­rzo­ne­go na zamó­wie­nie, tymi wyma­ga­nia­mi są ocze­ki­wa­ne usłu­gi, tak zwa­ne przy­pad­ki uży­cia, opro­gra­mo­wa­nia (sys­te­mu). Są one wywo­dzo­ne z tych czyn­no­ści, któ­re nowe opro­gra­mo­wa­nie ma wspie­rać. Tak się okre­śla zakres pro­jek­tu, któ­ry jak widać, też wywo­dzo­ny jest z mode­lu (pro­ce­sów).

Kolejny pro­jek­to­wa­ny ele­ment to model dzie­dzi­ny sys­te­mu. Zawiera on obiek­ty biz­ne­so­we oraz ele­men­ty odpo­wie­dzial­ne za reali­za­cje każ­dej usłu­gi nowe­go opro­gra­mo­wa­nia. Są to kla­sy (i obiek­ty) w mode­lu dzie­dzi­ny. Każdy przy­pa­dek uży­cia jest wywo­dzo­ny z czyn­no­ści w pro­ce­sie, kla­sy ste­ru­ją­ce są wywo­dzo­ne z przy­pad­ków uży­cia, kla­sy repre­zen­tu­ją­ce obiek­ty prze­twa­rza­ne, są wywo­dzo­ne z doku­men­tów i zdarzeń.

Dalej z przy­pad­ków uży­cia wywo­dzo­ne są dia­gra­my sekwen­cji mode­lu­ją­ce sce­na­riu­sze zacho­wa­nia sys­te­mu w reak­cji na dzia­ła­nia użyt­kow­ni­ka (tak zwa­ne­go akto­ra). Klasy na mode­lach sekwen­cji są wywo­dzo­ne z mode­lu dziedziny.

Jeżeli model pro­ce­sów biz­ne­so­wych zawie­ra defi­ni­cje reguł biz­ne­so­wych, wywo­dzo­ne są z nich kla­sy lub ich ope­ra­cje, odpo­wie­dzial­ne za prze­strze­ga­nie” tych reguł.

Śladowanie w opi­sa­nej powy­żej kon­wen­cji ma nastę­pu­ją­ca postać:

Jak widać nad­zo­ro­wa­nych jest (śla­do­wa­nie) wie­le logicz­nych sko­ja­rzeń. Tego rodza­ju dia­gra­mów w pro­jek­cie jest nie mało, nie raz kil­ka­dzie­siąt i wię­cej, logicz­nych połą­czeń (czer­wo­ne linie prze­ry­wa­ne obra­zu­ją­ce śla­do­wa­nie) są więc set­ki. Jak nie­trud­no się domy­śleć, ręcz­ne” śle­dze­nie tych powią­zań jest prak­tycz­nie nie moż­li­we. (podob­nie zresz­tą jak ręcz­ne opra­co­wy­wa­nie zło­żo­nych rapor­tów finan­so­wych z tysię­cy danych).

Bez spe­cjal­ne­go narzę­dzia utrzy­ma­nie wyso­kiej jako­ści pro­jek­tu jest prak­tycz­nie nie moż­li­we przy zacho­wa­niu roz­sąd­ne­go nakła­du pra­cy. Narzędzia te to pakie­ty opro­gra­mo­wa­nia wspo­ma­ga­ją­ce pro­jek­to­wa­nie CASE (ang. com­pu­ter aided sys­tems engi­ne­ering lub com­pu­ter aided softwa­re engi­ne­ering, oso­bi­ście pre­fe­ru­je to pierw­sze roz­wi­nię­cie tego skrótu).

Jak zapew­ne czy­tel­ni­cy już zauważyli,…

…mode­le bez sys­te­mu śla­do­wa­nia są prak­tycz­nie nie­we­ry­fi­ko­wal­ne, ich jako­ści nie da się oce­nić a ich sto­so­wa­nie jest wyso­ce ryzy­kow­ne o ile w ogó­le sensowne.

Po co to wszystko? 

Jak wspo­mnia­no na począt­ku, do zapa­no­wa­nia na zło­żo­no­ścią pro­jek­tu i jego ren­tow­no­ścią. Kolejny powód to moż­li­wość wery­fi­ka­cji kom­plet­no­ści wyma­gań. Odkrywanie wyma­gań dopie­ro w trak­cie reali­za­cji pro­jek­tu (wery­fi­ka­cja wyma­gań dopie­ro z pomo­cą kolej­nych jego pro­to­ty­pów) to powszech­nie zna­ny zabój­ca projektów”.

Dobrze opra­co­wa­ny, kom­plet­ny model orga­ni­za­cji, jego wyko­na­nie poprze­dza opi­sa­ny powy­żej model, łączy w sobie:

  1. model moty­wa­cji biz­ne­so­wej,
  2. model struk­tu­ry organizacyjnej,
  3. model pro­ce­sów biz­ne­so­wych (wymie­nio­ny już powyżej),
  4. model reguł biz­ne­so­wych.

Elementy każ­de­go z tych mode­li są ze sobą powią­za­ne: role w pro­ce­sach są wywo­dzo­ne ze sta­no­wisk w mode­lu orga­ni­za­cyj­nym, ana­li­zo­wa­ne pro­ce­sy są wywo­dzo­ne ze stra­te­gii w mode­lu moty­wa­cji, regu­ły biz­ne­so­we są koja­rzo­ne z czyn­no­ścia­mi w pro­ce­sach i wywo­dzo­ne z aktów praw­nych i wewnętrz­nych zarządzeń.

Mając tak opra­co­wa­ny kom­plet­ny model orga­ni­za­cji, zawie­ra­ją­cy śla­do­wa­nie, i odpo­wied­nie opro­gra­mo­wa­nie CASE moż­na prze­pro­wa­dzić ana­li­zę oddzia­ły­wa­nia, np. spraw­dzić na jakie oso­by w orga­ni­za­cji prze­nie­sie się zmia­na wybra­nych reguł biz­ne­so­wych. Mając model sys­te­mu infor­ma­tycz­ne­go sko­ja­rzo­ny z pro­ce­sa­mi, moż­na spraw­dzić wpływ awa­rii poszcze­gól­nych pod­sys­te­mów na pro­ce­sy biz­ne­so­we i ich skut­ki dla fir­my. Takich ana­liz moż­na wyko­nać wie­le, nie było by to moż­li­we bez tak skon­stru­owa­ne­go modelu.

Dlatego, pod­sta­wo­wą war­to­ścią popraw­nie wyko­na­nych mode­li orga­ni­za­cji i uży­cia wła­ści­wych narzę­dzi, jest nie tyl­ko opra­co­wa­nie wyma­gań np. na opro­gra­mo­wa­nie. Możliwe jest testo­wa­nie reak­cji ele­men­tów struk­tu­ry orga­ni­za­cji na zda­rze­nia np. awa­rie. Możliwe jest opra­co­wa­nie pro­jek­tów inte­gra­cji, wymia­ny opro­gra­mo­wa­nia. Możliwe jest spraw­dze­nie na co ma wpływ np. nie­ocze­ki­wa­na nie­obec­ność pra­cow­ni­ka. To tyl­ko wybra­ne przy­kła­dy, jed­nak moż­li­we jest to wyłącz­nie pod warun­kiem posia­da­nia popraw­nie wyko­na­ne­go modelu.

Wartość doda­na takiej ana­li­zy może być bar­dzo duża. Jeżeli podej­mu­je się decy­zje o inwe­sty­cjach rzę­du setek tysię­cy a nie raz dzie­sią­tek milio­nów zło­tych to wspar­cie tych decy­zji ana­li­za­mi, któ­rych war­tość jest o rząd albo dwa rzę­dy mniej­sza ma głę­bo­ki sens…

Co jest wadą większości analiz biznesowych?

To, że są one tak na praw­dę tyl­ko upo­rząd­ko­wa­nym zapi­sem wywia­dów z klien­tem a nie fak­tycz­ną ana­li­zą orga­ni­za­cji i jej potrzeb (bo nie koniecz­nie jej pra­cow­ni­ków!) i celów biz­ne­so­wych. Jakie są tre­ści tek­sto­we­go lub tabe­la­rycz­ne­go zapi­su wywia­dów? NIEJEDNOZNACZNE! Jakie są nie­sfor­ma­li­zo­wa­ne, swo­bod­nie two­rzo­ne dia­gra­my pro­ce­sów? NIEJEDNOZNACZNE! Jakie są słow­ne opi­sy struk­tu­ry opro­gra­mo­wa­nia jakie ma powstać? NIEJEDNOZNACZNE!

Co zro­bić? Używać już na eta­pie ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia sfor­ma­li­zo­wa­nych narzę­dzi takich jak stan­dar­do­we nota­cje i meto­dy­ki, wte­dy opi­sy będą JEDNOZNACZNE. Czy to trud­ne? Tak, w koń­cu te 70% pora­żek to nie przy­pa­dek? ( czy­taj cały arty­kuł: Analityk biz­ne­so­wy czy­li wyple­nić dwu­znacz­ność z doku­men­tów ana­li­tycz­nych!).

Dlaczego tak jest? Bo opro­gra­mo­wa­nie jest two­rzo­ne z pomo­cą języ­ków pro­gra­mo­wa­nia a te SĄ sfor­ma­li­zo­wa­ne. Nie da się skom­pi­lo­wać do posta­ci sys­te­mu ERP luź­nej pro­zy”. Napisałem to w Listopadzie 2011, dzi­siaj ciąg dal­szy. Na począ­tek dodam jesz­cze moją kon­klu­zję z pew­nej konferencji:

Tak więc język for­mal­ny, uży­ta nota­cja, czy­ni pro­jekt war­to­ścio­wym [jed­no­znacz­nym]. Bez tego raczej nie zna­czy on po pro­tu nic. (Modelowanie pro­ce­sów biz­ne­so­wych – dla­cze­go mają sens tyl­ko meto­dy for­mal­ne i uzna­ne nota­cje).

Jak to mówią: moc­ne sło­wa, ale nie zapo­mi­naj­my, że mało któ­ry pro­jekt biz­ne­so­wy IT koń­czy się w ter­mi­nie i zamy­ka w zało­żo­nym budże­cie. Zastanówcie jak były doku­men­to­wa­ne Wasze nie­uda­ne” projekty…

O notacjach

Króciutko, żeby się nie powta­rzać. Notacja to pewien język wyra­zu, prze­strzeń nazw zawie­ra­ją­ca skoń­czo­ną licz­bę pojęć o ści­śle zde­fi­nio­wa­nych zna­cze­niach. Notacji mamy na ryn­ku wie­le. Czy to jakiś pro­blem? W pew­nym sen­sie tak, bo po pierw­sze języ­ki te nie­co nakła­da­ją się na sie­bie (nakła­da­ją się na sie­bie prze­strze­nie nazw) ale nie dają się na sie­bie w spo­sób jed­no­znacz­ny tłu­ma­czyć. Języki te nie zastę­pu­ją się wza­jem­nie. Są w uży­ciu” nota­cje (sys­te­my two­rze­nia dia­gra­mów) nie­sfor­ma­li­zo­wa­ne, trud­no je w ogó­le nazy­wać nota­cją. To po pro­tu biblio­te­ki sym­bo­li do two­rze­nia sche­ma­tów blo­ko­wych a te nie koniecz­nie są mode­la­mi”. Przykładem może być bar­dzo popu­lar­ny MS Visio z wie­lo­ma biblio­te­ka­mi sym­bo­li. Niestety tak powsta­ją­ce dia­gra­my są zapew­ne ilu­stra­cją dla tek­stu ale nie są żad­nym modelem.

Opisze tu wybra­ne nota­cje, te któ­rych uży­wam i uzna­je za pewien stan­dard de’fac­to. Nie będzie to żad­ne szko­le­nie z nota­cji”, bo nie jest to ani miej­sce ani dobry spo­sób na szko­le­nia (na te ser­decz­nie zapra­szam zain­te­re­so­wa­nych na sale wykła­do­wą :)). Powiemy sobie o [[ArchiMate]], [[BMM]], [[BPMN]], [[UML]].

Co, kiedy i do czego

To co tu teraz napi­szę nie jest żad­nym dogma­tem. To efekt doświad­czeń, prac badaw­czych i pew­nych przemyśleń.

Każda orga­ni­za­cja to bar­dzo zło­żo­ny orga­nizm. Stopień zło­żo­no­ści jest duży jeże­li wziąć pod uwa­gę fakt, że nie­jed­na zatrud­nia dzie­siąt­ki pra­cow­ni­ków, two­rzy tysią­ce doku­men­tów, obsłu­gu­je set­ki spraw i uży­wa dzie­sią­tek narzę­dzi (w tym opro­gra­mo­wa­nie) wspo­ma­ga­ją­cych tę pra­cę . Czy to w ogó­le da się jakoś opi­sać? Owszem. Jak?

Organizacje się nie tyle opi­su­je” co raczej mode­lu­je. Ich model to uprosz­cze­nie, pozwa­la­ją­ce zro­zu­mieć spo­sób jej dzia­ła­nia. Problem jed­nak w tym, że orga­ni­za­cja to wie­le róż­nych aspek­tów jej dzia­ła­nia. Dla każ­de­go z nich powstał inny język opi­su, powo­dem jest (tak sądzę), po pierw­sze róż­ny odbior­ca na każ­dym pozio­mie szcze­gó­ło­wo­ści, a po dru­gie róż­ne para­dyg­ma­ty (pro­ce­so­wy, obiek­to­wy czy sys­tem ana­liz wpły­wu). Kto inny czy­ta opis stra­te­gii biz­ne­so­wej a kto inny opis tech­nicz­ny sys­te­mu ERP, jed­nak oba te aspek­ty są jakoś powią­za­ne (powin­ny być ;)) i to tak­że powin­no dać się opi­sać. Z tego powo­du pierw­szym podzia­łem mode­li są: mode­le logicz­ne (abs­trak­cja) i wyko­naw­cze (spe­cy­fi­ka­cja). Na to nakła­da się sfe­ra biz­ne­so­wa (zarzą­dza­nie) oraz tech­nicz­na (zaso­by w tym narzędzia).

Nie znaj­dzie­cie tu pań­stwo defi­ni­cji tych nota­cji, odsy­łam na stro­ny orga­ni­za­cji stan­da­ry­zu­ją­cych ([[Object Management Group]] oraz [[The Open Group]]). Pokaże do cze­go dosze­dłem na bazie dzie­sią­tek pro­jek­tów małych i dużych, dla real­nych przed­się­biorstw i fik­cyj­nych badaw­czych. Posłużę się kla­sycz­nym chy­ba już mode­lem ana­li­zy zstę­pu­ją­cej, w posta­ci pira­mi­dy obra­zu­ją­ce trzy pozio­my abs­trak­cji opi­su orga­ni­za­cji (im niżej tym wię­cej szcze­gó­łów zawie­ra dokumentacja):

Na naj­wyż­szym pozio­mie abs­trak­cji mamy stra­te­gię, tu poja­wia się tak zwa­ny model moty­wa­cji i ana­li­za wpły­wu. Obecnie uży­wam na tym pozio­mie nota­cji (języ­ka mode­lo­wa­nia) [[Business Motivation Model]]. Zawiera takie poję­cia jak cel biz­ne­so­wy, środ­ki osią­ga­nia celu ale tak­że bar­dzo waż­ne na tym eta­pie takie ele­men­ty jak czyn­ni­ki wpły­wu, ana­liz a SWOT, ryzy­ka czy stra­te­gie i taktyki.

Na tym pozio­mie od tego roku moż­na sto­so­wać nota­cję [[ArchiMate]], jed­nak w moim prze­ko­na­niu jest ona w tym obsza­rze zbyt sil­nie ukie­run­ko­wa­na na meto­dy­kę i struk­tu­ry opi­su [[TOGAF]], jest w moich oczach w tej sfe­rze uboż­sza, bra­ku­je jej wie­lu pojęć obsłu­gi­wa­nych” przez BMM.

Jeżeli nie widzę nic złe­go w sto­so­wa­niu kil­ku nota­cji w jed­nym pro­jek­cie (jest to w zasa­dzie koniecz­ność), to z zasa­dy uży­wam wyłącz­nie jed­nej nota­cji na jed­nym pozio­mie abs­trak­cji (war­stwie jak wyżej). Używanie na jed­nym pozio­mie np. dwóch róż­nych nota­cji pro­wa­dzi co naj­mniej do bra­ku spój­no­ści mode­li gdyż poję­cia róż­nych nota­cji róż­nią się swo­im zasię­giem (poszcze­gól­ne poję­cia mają nie­co inne znaczenia).

Na pozio­mie pro­ce­sów biz­ne­so­wych, sto­su­ję zamien­nie BPMN albo ArchiMate. Z każ­dym kolej­nym pro­jek­tem skła­niam się jed­nak do uży­wa­nia na tym pozio­mie ArchiMate. Powodem jest to, że BPMN ofe­ru­je wyłącz­nie czy­ste poję­cia z defi­ni­cji pro­ce­su (czyn­ność, dane, zda­rze­nie, rola, pula, bram­ki). Na tym pozio­mie jed­nak nie raz nale­ży wyra­zić roz­dziel­nie takie poję­cia jak rola i aktor (np. klient i kon­tra­hent mogą peł­nić rolę zama­wia­ją­ce­go w pro­ce­sie) albo odręb­ne poję­cia takie jak funk­cje biz­ne­so­we (aktor wraz z zaso­ba­mi jakich uży­wa peł­ni funk­cję admi­ni­stra­cji wewnętrz­nej) albo usłu­gi powią­za­ne z pro­ce­sa­mi (pro­ces sprze­da­ży powią­za­ny z usłu­gą obsłu­gi klien­ta). Przykłady moż­na mnożyć.

Realizacja pro­ce­sów to suche” łań­cu­chy czyn­no­ści i twar­da logi­ka ich sce­na­riu­szy. Tu dosko­na­le spraw­dza się BPMN i pier­wot­ny cel powsta­nia tej nota­cji: mode­lo­wa­nie skryp­tów BPEL ([[Business Process Execution Language]], a obec­nie głów­nie [[XPDL]]). W tej war­stwie BPMN nie ma kon­ku­ren­cji, jest w 100% zgod­ny z XPDL (język opi­su pro­ce­sów zale­ca­ny przez [[Workflow Management Coalition, WfMC]]). Podejmowane są pró­by sto­so­wa­nia UML (Diagram czyn­no­ści) ale nie wró­żę tej meto­dzie suk­ce­su i nie pole­cam jej (powo­dy na koń­cu tekstu).

Tu dodat­ko­wa mała uwa­ga. Nawet na pozio­mie wyko­naw­czym pro­ce­su rzad­ko poja­wia się potrze­ba, mode­lo­wa­nia expli­ci­te” każ­dej czyn­no­ści, z dokład­no­ścią nie­mal­że algo­ryt­micz­ną. W więk­szo­ści wypad­ków zupeł­nie wystar­czy model celo­wo­ści dzia­łań” i ich sce­na­riu­sze, algo­rytm postę­po­wa­nia potrzeb­ny jest tyl­ko maszy­nie. Na stro­nach BPM Research dostęp­ne są wyni­ki badań poka­zu­ją­ce to zja­wi­sko: The ave­ra­ge sub­set of BPMN used in the­se models con­si­sted of just 9 dif­fe­rent sym­bols. That means that the ave­ra­ge BPMN model uses less than 20% of the ava­ila­ble voca­bu­la­ry. (Najczęściej uży­wa­ny w mode­lach zestaw pojęć BPMN to 9 sym­bo­li. Oznacza to, że w mode­lach BPMN uży­wa­nych jest nie­ca­łe 20% zde­fi­nio­wa­nych w tej nota­cji pojęć). Polecam dostęp­ny na tych stro­nach wykres.

Można się spo­tkać z poję­ciem trzech pozio­mów mode­lo­wa­nia pro­ce­sów (Bruce Silver blog): war­stwa opi­so­wa, war­stwa mode­li ana­li­tycz­nych, war­stwa mode­li wyko­naw­czych. w zasa­dzie nie odbie­ga to od powyż­sze­go mode­lu jed­nak autor pro­po­nu­je tu w war­stwie pierw­szej (opis) two­rze­nie ogól­nych mode­li z zanie­dba­niem reguł nota­cji. Tu jed­nak nie­ste­ty nara­ża­my się na nie­jed­no­znacz­no­ści. Ja widać nie ja jeden dostrze­gam potrze­bę podzia­łu na pozio­my abs­trak­cji w mode­lo­wa­niu i ana­li­zie. Propozycja Bruce’a Silvera jest jak naj­bar­dziej war­ta naśla­do­wa­nia, z tym jed­nak, że lep­szym pomy­słem jest, moim zda­niem, wybra­nie nota­cji dosto­so­wa­nej do pozio­mu abs­trak­cji, dla­te­go na pozio­mi opi­so­wym (ja jed­nak wole nazwę model biz­ne­so­wy lub łań­cuch war­to­ści, to nada­je kon­kret­ny sens temu mode­lo­wi) sto­su­ję oraz czę­ściej ArchiMate by nie musieć łamać zasad sys­te­mu poję­cio­we­go danej nota­cji (jak sam Bruce Silver przy­znał, wyma­ga to wyłą­cze­nia kon­tro­li popraw­no­ści modelu).

Warstwa archi­tek­tu­ry sys­te­mów IT. Tu w zasa­dzie rów­no­praw­nie moż­na uży­wać ArchiMate i UML (głów­nie dia­gram kom­po­nen­tów i dia­gram wdro­że­nia). Jednak koja­rząc logi­kę biz­ne­so­wą (poziom pro­ce­sów biz­ne­so­wych) z archi­tek­tu­rą apli­ka­cji (sys­tem IT), nale­ży zasto­so­wać jed­ną nota­cję dla obu warstw by zacho­wać spój­ność poję­cio­wą mode­lu, a to daje nam wła­śnie ArchiMate (to są już pro­jek­ty doty­ka­ją­ce” archi­tek­tu­ry korporacyjnej).

Najniżej mamy war­stwę spe­cy­fi­ka­cji sys­te­mu IT, jego struk­tu­rę (albo jak to woli model reali­za­cji sys­te­mu IT). Na tym pozio­mie w uży­ciu nota­cja UML, któ­ra do tego powsta­ła. Jeżeli uznać fakt, że meto­dy struk­tu­ral­ne ode­szły do lamu­sa (nota­cje DFD) a mode­le rela­cyj­nych baz danych są na zbyt niskim, inży­nier­skim pozio­mie (nota­cja ERD), to UML jako język obiek­to­wy, nie ma w tym obsza­rze kon­ku­ren­ta. Poniżej typo­wy zakres (pakie­ty, w nich są loko­wa­ne arte­fak­ty” pro­duk­tu ana­li­zy) moich projektów:

Powyższy dia­gram obra­zu­je struk­tu­rę mode­li (pod spodem odpo­wia­da­ją­ce mu drze­wo kata­lo­gów, dia­gram powyż­szy do dia­gram pakie­tów UML).

Powyższy dia­gram to tak­że podział z per­spek­ty­wy adre­sa­ta doku­men­ta­cji: dla tak zwa­ne­go biz­ne­su adre­so­wa­ne są trzy war­stwy licząc od góry. Dla wyko­naw­ców sys­te­mów ostat­nia: wykonawcza.

Na zakończenie kilka słów o UML

Notacja ta powsta­ła jako uni­wer­sal­na ([[Unified Modeling Language]], Uniwersalny Język Modelowania) jed­nak tu chy­ba auto­rzy tej nota­cji dotknę­li pro­ble­mu coś co jest do wszyst­kie­go jest do nicze­go”. Mimo tego, że z pomo­cą sys­te­mu tak zwa­nych pro­fi­li w UML moż­li­we jest wyra­że­nie w tej nota­cji pojęć każ­dej z pozo­sta­łych wymie­nio­nych, nie jest to dobry pomysł. Mam nadzie­ję, że nie zacho­ru­je na to” [[The Open Group i ArchiMate]] (poja­wi­ła się wspo­mnia­na ArchiMate 2.0).

Dlaczego UML nie powi­nien być uży­wa­ny do wszyst­kie­go? Notacja ta jest ska­żo­na” tak zwa­nym obiek­to­wym para­dyg­ma­tem, bar­dzo trud­nym do przy­swo­je­nia dla osób nie oby­tych z meto­da­mi obiek­to­wy­mi w inży­nie­rii opro­gra­mo­wa­nia. Po dru­gie sys­tem gra­ficz­ny w UML nie uła­twia odbio­ru, per­cep­cji mode­li gdyż więk­szość pojęć jest obra­zo­wa­na pro­sto­ką­tem z róż­ny­mi ety­kie­ta­mi. Zjawisko to (zro­zu­mia­łość gra­ficz­nych sys­te­mów komu­ni­ko­wa­ni tre­ści) opi­su­je nauka jaką jest [[Semiotyka]]. Nie jest to miej­sce na jej opis, jed­nak wyka­zu­je ona, że sto­so­wa­nie np. UML do komu­ni­ko­wa­nia cze­go­kol­wiek ludziom z tak zwa­ne­go biz­ne­su”, nie mają­cym nic wspól­ne­go z obiek­to­wym para­dyg­ma­tem, nie jest dobrym pomy­słem, a doku­men­ty opi­su­ją­ce orga­ni­za­cję w koń­cu mają im służyć.

Semiotyka uczy nas”, że każ­de poję­cie (kon­cept) dla moż­li­wie naj­lep­szej zro­zu­mia­ło­ści dla odbior­cy, powi­nien być repre­zen­to­wa­ny innym zna­kiem (kształ­tem), naj­le­piej koja­rzą­cym się z repre­zen­to­wa­nym zna­cze­niem (co zna­czy ten znak).

Innym razem na kil­ku przy­kła­dach, poka­żę mode­le w ArchiMate…