W toku szko­leń, a tak­że audy­tów, powsta­ją nie raz spo­ry o inter­pre­ta­cje zna­cze­nia sym­bo­li nota­cji: ich seman­ty­ki i syn­tak­ty­ki (co ozna­cza­ją i jak je moż­na łączyć z inny­mi). Dzisiaj o dość czę­stym spo­rze czy­li bram­ki OR (inc­lu­si­ve) i XOR (exc­lu­si­ve) w nota­cji BPMN oraz o tym, że z 380 stron spe­cy­fi­ka­cji BPMN, w mode­lach ana­li­tycz­nych sto­su­je­my tyl­ko nie­ca­łe 40 stron roz­dzia­łu 7., pozo­sta­łe roz­dzia­ły słu­żą wyłącz­nie lep­sze­mu zro­zu­mie­niu teo­rii i mode­lom wyko­ny­wal­nym. Czyli dla­cze­go w ana­li­zach sto­su­je­my kil­ka, a nie kil­ka­dzie­siąt sym­bo­li nota­cji BPMN. 

Wprowadzenie

Specyfikacje nota­cji zarzą­dza­ne przez OMG (Object Management Group) ewo­lu­ują, są pisa­ne i roz­wi­ja­ne przez zespo­ły ludzi, i czę­sto odno­szą się wza­jem­nie do sie­bie (w szcze­gól­no­ści do MOF, obec­nie wer­sja 2.5.1. 2019 r.). Jeżeli dodać do tego fakt, że nota­cje te nie są aktu­ali­zo­wa­ne jed­no­cze­śnie, musi­my sie pogo­dzić z tym, że zawsze będą w pew­nym zakre­sie nie­spój­ne i mię­dzy sobą i wewnątrz. Widać to w szcze­gól­no­ści w UML po 2015 roku (poja­wie­nie sie wer­sji 2.5) i w BPMN po 2014 (poja­wie­nie się wer­sji 2.0.2). Te dwie zmia­ny są fun­da­men­tal­ne, bo są efek­tem har­mo­ni­za­cji obu tych nota­cji ze spe­cy­fi­ka­cją MDA (Model Driven Architecture), któ­ra zakła­da, że pro­ces wytwa­rza­nia opro­gra­mo­wa­nia to czte­ry klu­czo­we eta­py i zara­zem mode­le, powsta­ją­ce w kolej­no­ści: (1) Computation Independent Model (CIM), (2) Platform Independent Model (PIM), (3) Platform Specific Model (PSM) oraz (4) imple­men­ta­cja, czy­li wła­ści­we kodo­wa­nie. Są tą odpo­wied­nio: (1) model biz­ne­so­wy (pro­blem doma­in), (2) model roz­wią­za­nia (solu­tion doma­in), (3) model imple­men­ta­cji (softwa­re doma­in), (4) imple­men­ta­cja (imple­men­ta­tion domain).

Powyższy dia­gram poka­zu­je kolej­ność tych eta­pów i pro­duk­tów każ­de­go z nich (arte­fak­tów). Na sza­ro ozna­czo­no obsza­ry trans­for­ma­cji, pozo­sta­ją­ce nadal w sfe­rze aka­de­mic­kich roz­wa­żań o moż­li­wo­ści auto­ma­ty­za­cji tych ope­ra­cji. Powyższy pro­ces, wbrew zarzu­tom wie­lu auto­rów, nie jest tak zwa­nym wodo­spa­do­wym (water­fall) pro­ce­sem two­rze­nia opro­gra­mo­wa­nia, gdyż opi­su­je dowol­ny mały lub duży kom­po­nent sys­te­mu. Mogą to być np. mikro­ser­wi­sy, powsta­ją­ce w cyklu nawet tygo­dnio­wym. MDA sta­wia sobie za cel odsu­nię­cie w cza­sie naj­kosz­tow­niej­sze­go eta­pu jakim jest imple­men­ta­cja i testo­wa­nie. CIM i PIM robi sie na papie­rze” (czy­li szyb­ko i tanio, jak ktoś potra­fi), imple­men­ta­cja to już koniecz­ność uru­cho­mie­nia śro­do­wi­ska wyko­naw­cze­go i kil­ku dni pra­cy zespół pro­gra­mi­stów, w tym testy i popra­wia­nie błę­dów (któ­re są szyb­ko i tanio usu­wa­ne na eta­pie testo­wa­nia mode­li PIM).

Czy wspo­mnia­ne na począt­ku drob­ne nie­spój­no­ści nota­cji dys­kwa­li­fi­ku­ją te nota­cje (głów­nie BPMN i UML)? Absolutnie nie. Po pierw­sze są mar­gi­nal­ne i nie doty­czą klu­czo­wych cech nota­cji, po dru­gie nota­cje mają okre­ślo­ną hie­rar­chię jako meta-mode­le, opi­sa­ną w spe­cy­fi­ka­cji MOF, co pozwa­la samo­dziel­nie roz­strzy­gać takie pro­ble­my, co w tym arty­ku­le pokażę. 

Najnowsza wer­sja MOF zawie­ra krót­ki komen­tarz na temat licz­by warstw meta­mo­de­li (7.3 How Many Meta Layers?). Powszechnie cyto­wa­ny jest poniż­szy diagram:

(źr. Architecting Software Systems using Model Transformation and Architectural Frameworks, January 2007, Thesis for: PhD, Gilles Perrouin)

Jest to pokło­sie pierw­szej spe­cy­fi­ka­cji MOF z roku 2002 zawie­ra­ją­cej taki opis: 

(źr.: 1.4 April 2002 

Obecnie (Meta Object Facility, 2.5.1, 2016) czytamy: 

Jednym ze źró­deł nie­po­ro­zu­mień w pakie­cie stan­dar­dów OMG jest postrze­ga­na sztyw­ność czte­ro­war­stwo­wej archi­tek­tu­ry meta­mo­de­lu archi­tek­tu­ry meta­mo­de­lu”, o któ­rej mowa w róż­nych spe­cy­fi­ka­cjach OMG. Należy zauwa­żyć, że klu­czo­wy­mi poję­cia­mi mode­lo­wa­nia są kla­sy­fi­ka­tor i instan­cja lub kla­sa i obiekt oraz moż­li­wość nawi­ga­cji od instan­cji do jej meta-obiek­tu (jej kla­sy­fi­ka­to­ra). Ta pod­sta­wo­wa kon­cep­cja może być uży­ta do obsłu­gi dowol­nej licz­by warstw meta­mo­de­li (cza­sa­mi okre­śla­nych jako meta-poziomy).

Ostatnie zda­nie doty­czy war­stwy ozna­cza­ne M2 i doty­czy klas abs­trak­cyj­nych i pro­fi­li. To w tej war­stwie (M2) są defi­nio­wa­ne mię­dzy inny­mi pro­fi­le wzor­ców pro­jek­to­wych; np. blo­ki funk­cjo­nal­ne wzor­ców DDD (Domain Driven Design) czy BCE (Boundary, Control, Entity) i wie­lu frameworków.

Istnienie drob­nych nie­spój­no­ści (raczej są to nie­kon­se­kwen­cje) w nota­cjach (jak widać są aktu­ali­zo­wa­ne w róż­nym cza­sie) ozna­cza, że ich odręb­ne i dogma­tycz­ne inte­pre­to­wa­nie jest bar­dzo poważ­nym błę­dem. Z uwa­gi na spo­sób powsta­wa­nia, każ­da spe­cy­fi­ka­cja, pocho­dzą­ca z OMG, zawie­ra w począt­ko­wych roz­dzia­łach infor­ma­cje o zgod­no­ści z doku­men­ta­mi nad­rzęd­ny­mi, co pozwa­la, na dro­dze logi­ki i deduk­cji, roz­strzy­gać tego typu wąt­pli­wo­ści. W spe­cy­fi­ka­cji BPMN czytamy:

3. Normative References
3.1 General
The fol­lo­wing refe­ren­ced docu­ments are indi­spen­sa­ble for the appli­ca­tion of this docu­ment. For dated refe­ren­ces, only the edi­tion cited applies. For unda­ted refe­ren­ces, the latest edi­tion of the refe­ren­ced docu­ment (inc­lu­ding any amend­ments) applies.
(Następujące doku­men­ty powo­ła­ne są nie­zbęd­ne do sto­so­wa­nia niniej­sze­go doku­men­tu. W przy­pad­ku powo­łań dato­wa­nych obo­wią­zu­je tyl­ko wyda­nie cyto­wa­ne. W przy­pad­ku powo­łań nie­da­to­wa­nych obo­wią­zu­je ostat­nie wyda­nie doku­men­tu powo­ła­ne­go (łącz­nie z popraw­ka­mi)).
3.2 Normative
OMG UML
? OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 – OMG MOF
? Object Management Group – Meta Object Facility (MOF) Core Specification, V2.0
https://​www​.omg​.org/​s​p​e​c​/​M​O​F​/​2.0 RFC-2119
? Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF RFC 2119, March 1997
http://​www​.ietf​.org/​r​f​c​/​r​f​c​2​1​1​9​.​txt

(źr. BPMN Version 2.0.2).

Innymi sło­wy inter­pre­ta­cja seman­ty­ki i syn­tak­ty­ki spe­cy­fi­ka­cji BPMN, MUSI być reali­zo­wa­na na bazie aktu­al­nych spe­cy­fi­ka­cji MOF i UML. Specyfikacja nota­cji nie może być inte­pre­to­wa­na jako ode­rwa­ny od pozo­sta­łych, dogma­tycz­nie czy­ta­ny, tekst. 

Proces w BPMN

Modele pro­ce­sów biz­ne­so­wych w BPMN to tak na praw­dę two­rze­nie meta­mo­de­li okre­ślo­ne­go typu, nazwa­nych, sekwen­cji zda­rzeń (instan­cji pro­ce­su). Elementy na dia­gra­mach BPMN to z zasa­dy kla­sy a nie obiek­ty (spe­cy­fi­ka­cja BPMN zawie­ra wyłącz­nie dia­gra­my klas). Innymi sło­wy zada­nie Wystawienie fak­tu­ry” na dia­gra­mie BPMN, ozna­cza wszyst­kie przy­pad­ki wysta­wie­nia fak­tu­ry w mode­lo­wa­nej organizacji. 

Modele BPMN for­mal­nie umiesz­cza­my w war­stwie M2 struk­tu­ry MOF. Innymi sło­wy: np. jeden dia­gram BPMN, jako model prze­pły­wu fak­tur kosz­to­wych (war­stwa M2), repre­zen­tu­je (opi­su­je) wszyst­kie moż­li­we (dopusz­czal­ne) kon­kret­ne prze­pły­wy fak­tur. Hierarchię tę moż­na poka­zać tak:

Hierarchia mode­li BPMN na tle warstw MOF.

Innymi sło­wy dia­gra­my BPMN, jako mode­le pro­ce­sów biz­ne­so­wych, to kon­struk­cje budo­wa­ne w war­stwie M2 MOF. Są to meta-mode­le fak­tycz­nych wystą­pień (M1 to abs­trak­cja, jako dia­gram był­by to zapis ścież­ki prze­pły­wu kon­kret­ne­go doku­men­tu, świat real­ny, obser­wo­wa­ny, to nie­po­ka­za­na tu war­stwa M0).

Poniżej frag­ment spe­cy­fi­ka­cji, BPMN, dia­gram klas UML defi­niu­ją­cy klu­czo­we ele­men­ty seman­ty­ki pro­ce­su w nota­cji BPMN:

Semantyka klu­czo­wych ele­men­tów pro­ce­su biz­ne­so­we­go, nota­cja BPMN (dia­gram klas, pro­fil UML)

I czy­ta­my, że klu­czo­we ele­men­ty pro­ce­su to:

  1. Proces (jako dia­gram) jest kon­te­ne­rem na ele­men­ty z jakich się skła­da jego model,
  2. Te ele­men­ty to połą­czo­ne ze sobą węzły, któ­ry­mi są aktyw­no­ści, bram­ki i zdarzenia.

To naj­wyż­szy poziom abs­trak­cji w BPMN. W ory­gi­na­le (rozdz. 10) opi­sy­wa­ny jest słow­nie jako: 

Proces opi­su­je sekwen­cję lub prze­pływ dzia­łań w orga­ni­za­cji, któ­rych celem jest wyko­na­nie pra­cy [to bar­dzo waż­ne, bo cho­dzi o jej pro­dukt]. W BPMN pro­ces jest przed­sta­wio­ny jako graf ele­men­tów prze­pły­wu, któ­re są zbio­rem dzia­łań, zda­rzeń, bra­mek i prze­pły­wu ich sekwencji. 

Poprawny abs­trak­cyj­ny model pro­ce­su biz­ne­so­we­go, wyko­na­ny z uży­ciem mini­mal­ne­go, pod­sta­wo­we­go zesta­wu ele­men­tów nota­cji. Brak puli na dia­gra­mie ozna­cza, że kon­te­ne­rem (pulą) jest on sam (obra­mo­wa­nie).

Bramki w procesie

W spe­cy­fi­ka­cji czy­ta­my (10.6 Gateways): 

Bramki mogą defi­nio­wać wszyst­kie typy ste­ro­wa­nia prze­pły­wu sekwen­cji pro­ce­sów biz­ne­so­wych: Decyzje/rozgałęzienia (wyłącz­ne, włą­cza­ją­ce i zło­żo­ne), łącze­nie, roz­wi­dla­nie i złą­cze­nie. Tak więc, pod­czas gdy romb był uży­wa­ny tra­dy­cyj­nie dla decy­zji wyłącz­nych, BPMN roz­sze­rza zacho­wa­nie rom­bów, aby odzwier­cie­dlić każ­dy rodzaj Sterowania prze­pły­wem sekwen­cji. Każdy typ bram­ki będzie posia­dał wewnętrz­ny wskaź­nik lub mar­ker, aby poka­zać typ bram­ki, któ­ra jest używana.

Jednak w roz­dzia­le 7 (tabe­la 7.1.) pod­sta­wo­we sym­bo­le czytamy: 

Bramka jest uży­wa­na do kon­tro­li roz­wi­dleń i złą­czeń prze­pły­wów sekwen­cji w pro­ce­sie […]. W ten spo­sób okre­śla ona roz­ga­łę­zie­nia, roz­wi­dle­nia i złą­cze­nie ścieżek.

nie­co dalej, (tabe­la 7.2.) mamy także:

Przepływ warun­ko­wy: Przepływ sekwen­cji może posia­dać waru­nek (Wyrażenie), któ­ry jest ana­li­zo­wa­ny w cza­sie wyko­ny­wa­nia, aby okre­ślić, czy prze­pływ zosta­nie wyko­na­ny. […] Jeśli prze­pływ warun­ko­wy wycho­dzi bez­po­śred­nio z kra­wę­dzi aktyw­no­ści, wów­czas będzie posia­dał mini­romb na począt­ku łącz­ni­ka. Jeśli prze­pływ warun­ko­wy wycho­dzi z kra­wę­dzi Bramki, wów­czas linia nie będzie nie będzie posia­da­ła minirombu.

Poniżej dwie rów­no­waż­ne konstrukcje:

Alternatywna for­ma mode­lo­wa­nia kon­tro­lo­wa­ne­go prze­pły­wu procesu.

I tu zaczy­na się pro­blem dogma­ty­ków, gdyż z powyż­sze­go wca­le nie wyni­ka, czy bram­ka jest (powin­na być) bram­ką XOR (exc­lu­si­ve) czy OR (inc­lu­si­ve), bo warun­ki są na razie abs­trak­cyj­ne (np. są nazwa­mi para­me­trów). Patrząc dogma­tycz­nie na poniż­szy zapis spe­cy­fi­ka­cji w rozdz. 10.:

przy­kład po lewej na dia­gra­mie Alternatywna for­ma mode­lo­wa­nia kon­tro­lo­wa­ne­go prze­pły­wu pro­ce­su” jest nie­moż­li­wy do nary­so­wa­nia, bo to, czy warun­ki 1 i 2 się wza­jem­nie wyklu­cza­ją czy nie, może być skut­kiem kon­kret­ne­go zesta­wu danych na doku­men­tach. Innymi sło­wy, jeże­li for­ma po pra­wej jest popraw­na zawsze (wyj­ścia warun­ko­we), a po lewej mia­ła by wyma­gać wie­dzy o zależ­no­ści logicz­nej tych warun­ków, to albo lewa for­ma nie ma racji bytu na mode­lach ana­li­tycz­nych, albo przyj­mu­je­my kon­wen­cję, że na mode­lach ana­li­tycz­nych bram­ka danych ozna­cza dowol­ne roz­wi­dle­nie na pod­sta­wie danych i jest ryso­wa­na bez wewnętrz­ne­go ozna­cze­nia, i takie przy­kła­dy zawie­ra tak­że roz­dział 7. specyfikacji. 

Wyjaśnienie ist­nie­nia tego pro­ble­mu znaj­dzie­my w roz­dzia­le 2.2.1. Czytamy: 

Jako alter­na­ty­wę dla popraw­no­ści mode­lo­wa­nych pro­ce­sów, zde­fi­nio­wa­no trzy pod­kla­sy zgod­no­ści:
- Opisowa
- Analityczna
- Wykonywalna
Opisowa doty­czy widocz­nych ele­men­tów i atry­bu­tów uży­wa­nych w mode­lo­wa­niu wyso­ko­po­zio­mo­wym. Powinna być wygod­na dla ana­li­ty­ków, któ­rzy uży­wa­li narzę­dzi do two­rze­nia ogól­nych pro­stych dia­gra­mów prze­pły­wu BPA.
Analityczna zawie­ra te same ele­men­ty co Opisowa, plus pozo­sta­łe ele­men­ty nota­cji. Ta kla­sa mode­li jest opar­ta na doświad­cze­niach zebra­nych pod­czas szko­leń BPMN oraz ana­li­zach wzor­ców w Department of Defense Architecture Framework i pla­no­wa­nej stan­da­ry­za­cji dla tego fra­me­wor­ka.
Zarówno mode­le Opisowe jak i Analityczne kon­cen­tru­ją się na widocz­nych (ryso­wa­nych) ele­men­tach i mini­mal­nym pod­zbio­rze wspie­ra­ją­cych atrybutów/elementów.
Klasa Wykonywalnych mode­li sku­pia się na tym, co jest potrzeb­ne do two­rze­nia deta­licz­nych [imple­men­ta­cja pro­ce­sów w śro­do­wi­skach ser­we­rów BPMS] mode­li procesów.

Tak więc z uwa­gi na zapo­wiedź pla­no­wa­nej stan­da­ry­za­cji mode­li ana­li­tycz­nych, dzi­siaj musi­my sobie radzić sami, i pozo­sta­je przy­jąć kon­wen­cję: na mode­lach ana­li­tycz­nych abs­tra­hu­je­my od tego czy bram­ka danych jest bram­ką XOR czy OR, bo jest to na mode­lach ana­li­tycz­nych bar­dzo czę­sto po pro­stu nie­roz­strzy­gal­ne. Bez tego zało­że­nia bram­ki te w zasa­dzie nie powin­ny być uży­wa­ne na tych mode­lach, co poka­zu­je poniż­szy frag­ment pro­ce­su, a pyta­nie brzmi: jest to bram­ka XOR czy OR? W mode­lach ana­li­tycz­nych – to z zasa­dy mode­le CIM, nie­za­leż­ne od tech­no­lo­gii infor­ma­cyj­nej – bez­pod­staw­ne jest sto­so­wa­nie ikon w rogu sym­bo­li aktyw­no­ści (user, script, manu­al itp..), bo to znacz­ni­ki dla mode­li wyko­ny­wal­nych. Stosowanie ich na meda­lach ana­li­tycz­nych (Computation Independent) nie ma żad­ne­go uza­sad­nie­nia (wię­cej o mode­lach ana­li­tycz­nych z przy­kła­da­mi w arty­ku­le: Od zapy­ta­nia do reali­za­cji zamó­wie­nia czy­li jak to się robi z BPMN).

Można oczy­wi­ście roz­ry­so­wać wszyst­kie moż­li­we kom­bi­na­cje dla tych trzech para­me­trów, ale to dopro­wa­dzi do powsta­nia skom­pli­ko­wa­ne­go dia­gra­mu, wyma­ga­ją­ce­go czę­stej aktu­ali­za­cji (po każ­dej zmia­nie para­me­trów tych decy­zji), dia­gra­mu w wie­lu przy­pad­kach trud­ne­go do inter­pre­ta­cji przez laika (a to oni są czę­sto adre­sa­ta­mi tych dokumentów).

Co jest pod­sta­wą logicz­ną tej kon­wen­cji (jej zgod­no­ści z nota­cją)? W roz­dzia­le 10.6 Gateways, mamy model pojęciowy:

I mamy cie­ka­wost­kę: bram­ki Exclusive i Inclusive mają wspól­ne zasto­so­wa­nie: ste­ro­wa­nie prze­pły­wem, mogą, ale nie muszą mieć wewnętrz­ne­go ozna­cze­nia (conditionExpression 0..1), więc moż­na przy­jąć, że mamy bram­ki: ste­ru­ją­ce prze­pły­wem, roz­wi­dla­ją­ce, zda­rze­nio­we i zło­żo­ne. Przy obec­nym bra­ku uzgod­nie­nia deta­li dla mode­li ana­li­tycz­nych, pozo­sta­je przy­jąć, że pusty romb to bram­ka ste­ru­ją­ca danych, bez wzglę­du na to czy aktu­al­ny zestaw warun­ków two­rzy logi­kę OR czy XOR, bo jest to po pro­stu czę­sto nie­moż­li­we do stwier­dze­nia na tym eta­pie ana­li­zy i mode­lo­wa­nia. Pamiętajmy tak­że, że bram­ka (ona jest opcjo­nal­na, jak już wie­my) na dia­gra­mie BPMN to mani­fe­sta­cja decy­zji pod­ję­tych w poprze­dza­ją­cej ją aktyw­no­ści, a nie ich podej­mo­wa­nie. Z moich obser­wa­cji wyni­ka, że taka wła­śnie kon­wen­cja jest naj­pow­szech­niej sto­so­wa­na w lite­ra­tu­rze i jest zro­zu­mia­ła dla odbior­ców mode­li. Zaryzykuję tezę, że bar­dziej zro­zu­mia­ła niż bram­ki ozna­czo­ne dodat­ko­wo [X] lub [O] wewnątrz. Konwencja ta nie łamie zasad nota­cji (przy­po­mi­nam, że poję­cie toke­nu to cecha mode­li wykonywalnych).

Podsumowanie

Dogmatyzm w inte­pre­to­wa­niu spe­cy­fi­ka­cji nota­cji ma podob­ne skut­ki jak dogma­tyzm u praw­ni­ków: czę­sto jest szko­dli­wy. Czy to zna­czy, że moż­na łamać zasa­dy nota­cji? Absolutnie nie. To zna­czy, że podob­nie jak w teo­rii pra­wa nor­my praw­ne inte­pre­tu­je­my jako połą­czo­ne spój­ni­kiem i”, tak tu zapi­sy spe­cy­fi­ka­cji wszyst­kich nota­cji OMG inte­pre­tu­je­my łącz­nie i tak­że łączy­my wszyst­kie spój­ni­kiem i”. Innymi sło­wy MOF, UML, BPMN itp. to jed­na nota­cja podzie­lo­na na dzie­dzi­no­we obsza­ry. Praktycznie każ­da sfor­ma­li­zo­wa­na nota­cja w OMG (sys­tem nota­cyj­ny) to pro­fil nota­cji UML. Dlatego, każ­da nota­cja ma tu we wstę­pie przy­wo­ła­ną zgod­ność z MOF i UML. 

UWAGA! Materiały szko­le­nio­we i tre­ści egza­mi­nów cer­ty­fi­ka­cyj­nych nie sta­no­wią wie­dzy nad­rzęd­nej ani zastę­pu­ją­cej ory­gi­nal­ne spe­cy­fi­ka­cje nota­cji. Jeżeli jest jaka­kol­wiek nie­zgod­ność mię­dzy tre­ścią tych mate­ria­łów a tre­ścią aktu­al­nej spe­cy­fi­ka­cji danej nota­cji, sto­su­je­my tę dru­gą. Żadne z tych mate­ria­łów nie sta­no­wią pod­ręcz­ni­ka ana­li­zy czy mode­lo­wa­nia, a przy­kła­dy tam poda­wa­ne to wyłącz­nie przy­kła­dy popraw­nej kon­struk­cji dia­gra­mów, co nie jest toż­sa­me z dobrą, czy nawet zale­ca­na, prak­ty­ką modelowania. 

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

Dodaj komentarz

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