Diagram Przypadków Użycia

Wstęp

Jest to dia­gram, któ­ry na rów­ni z Diagramem Klas, budzi bar­dzo czę­sto ogrom­ne pro­ble­my inter­pre­ta­cyj­ne (patrz: Diagram klas…). Bardzo wie­lu auto­rów przy­pi­su­je temu dia­gra­mo­wi role, któ­rych on nie peł­ni, a nie raz pre­zen­to­wa­ne w sie­ci i lite­ra­tu­rze przy­kła­dy są nie­po­praw­ne. Znakomita więk­szość auto­rów tych dia­gra­mów uży­wa ich jako zbio­ru moż­li­wych klik­nięć” co jest cał­ko­wi­tym nie­zro­zu­mie­niem celu uży­cia i idei tego dia­gra­mu. Nawet jeże­li ktoś potrze­bu­je takiej mapy kli­ka­nia, to są do tego lep­szych narzę­dzia i meto­dy (przy­kład: Mapa ekra­nów apli­ka­cji – pod­sta­wa dobre­go UX/UI design). Tworzenie nie­zgod­nych z nota­cją dia­gra­mów przy­pad­ków uży­cia po pro­stu psu­je struk­tu­rę pro­jek­tu w narzę­dziach CASE, czy­niąc ją prak­tycz­nie bez­u­ży­tecz­ną w pro­jek­to­wa­nia archi­tek­tu­ry systemu. 

Najpierw opi­szę krót­ko dia­gram przy­pad­ków uży­cia posłu­gu­jąc sie cyta­ta­mi z ory­gi­nal­nej spe­cy­fi­ka­cji. Później opi­szę typo­we błędy. 

Czym jest Diagram Przypadków Użycia

Kluczowe są tu wyja­śnie­nia wstę­pu do roz­dzia­łu UseCases Specyfikacji UML :

18 UseCases
18.1 Use Cases
18.1.1 Summary
UseCases are a means to cap­tu­re the requ­ire­ments of sys­tems, i.e., what sys­tems are sup­po­sed to do. The key con­cepts spe­ci­fied in this clau­se are Actors, UseCases, and sub­jects. Each UseCase’s sub­ject repre­sents a sys­tem under con­si­de­ra­tion to which the UseCase applies. Users and any other sys­tems that may inte­ract with a sub­ject are repre­sen­ted as Actors.
[…]
18.1.3 Semantics
18.1.3.1 Use Cases and Actors
A UseCase may apply to any num­ber of sub­jects. When a UseCase applies to a sub­ject, it spe­ci­fies a set of beha­viors per­for­med by that sub­ject, which yields an obse­rva­ble result that is of value for Actors or other sta­ke­hol­ders of the sub­ject. A UseCase is a kind of BehavioredClassifier that repre­sents a dec­la­ra­tion of a set of offe­red Behaviors. Each UseCase spe­ci­fies some beha­vior that a sub­ject can per­form in col­la­bo­ra­tion with one or more Actors. UseCases defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal structure.

Powyższe wytłusz­cze­nia zebra­łem poni­żej, uwa­gi ozna­czo­ne „[…]” są moje:

  1. Przypadki uży­cia są spo­so­bem na uchwy­ce­nie [wska­za­nie] wyma­gań sta­wia­nych sys­te­mom, tzn. tego, co sys­te­my mają robić [powo­dy, dla któ­rych one powsta­ną, co będą reali­zo­wa­ły na rzecz i na żąda­nie Aktora].
  2. Każdy Przypadek Użycia repre­zen­tu­je okre­ślo­ny cel (powód), dla któ­re­go System jest projektowany. 
  3. Przypadek Użycia jest rodza­jem kla­sy­fi­ka­to­ra beha­wio­ral­ne­go, któ­ry repre­zen­tu­je dekla­ra­cję zbio­ru ofe­ro­wa­nych zacho­wań. [to zna­czy, że gru­pu­je okre­ślo­ny kon­tek­sto­wo powią­za­ny zbiór zacho­wań, są to alter­na­tyw­ne sce­na­riu­sze tego same­go przy­pad­ku użycia].
  4. Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia [mode­lo­wa­ne­go] sys­te­mu bez odwo­ły­wa­nia się do jego wewnętrz­nej struktury. (!)

Są to pryn­cy­pia budo­wy tych diagramów.

Związki między Przypadkami Użycia

Extend

Specyfikacja UML:

An Extend is a rela­tion­ship from an exten­ding UseCase (the exten­sion) to an exten­ded UseCase (the extendedCase) that spe­ci­fies how and when the beha­vior defi­ned in the exten­ding UseCase can be inser­ted into the beha­vior defi­ned in the exten­ded UseCase. The exten­sion takes pla­ce at one or more spe­ci­fic exten­sion points defi­ned in the exten­ded UseCase. Extend is inten­ded to be used when the­re is some addi­tio­nal beha­vior that sho­uld be added, possi­bly con­di­tio­nal­ly, to the beha­vior defi­ned in one or more UseCases.

Związku «extend» moż­na użyć do poka­za­nia, że pew­ne ele­men­ty zacho­wa­nia Systemu reali­zo­wa­ne są warun­ko­wo. Te dodat­ko­we zacho­wa­nia są jed­nak z zasa­dy czę­ścią bazo­we­go Przypadku Użycia.

Autorzy spe­cy­fi­ka­cji UML jasno piszą, że: Szczegółowy spo­sób okre­śla­nia poło­że­nia punk­tu roz­sze­rzeń jest celo­wo nie­okre­ślo­ny. Wynika to z fak­tu, że Przypadki uży­cia mogą być spe­cy­fi­ko­wa­ne w róż­nych for­ma­tach, takich jak język natu­ral­ny, tabe­le, drze­wa itp. […] Zazwyczaj, przy­pa­dek uży­cia z ExtensionPoints skła­da się z zesta­wu drob­no­ziar­ni­stych opi­sów frag­men­tów zacho­wa­nia (sce­na­riu­sze), któ­re są naj­czę­ściej wyko­ny­wa­ne w pew­nej sekwen­cji. Taka seg­men­to­wa struk­tu­ra tek­stu opi­su dane­go przy­pad­ku uży­cia pozwa­la na roz­sze­rze­nie pier­wot­ne­go opi­su zacho­wa­nia przez dołą­cza­nie dodat­ko­wych opi­sów, frag­men­tów zacho­wa­nia, w odpo­wied­nich punk­tach wsta­wia­ne pomię­dzy pier­wot­ne frag­men­ty (punk­ty roz­sze­rzeń). Tak więc, roz­sze­rze­nie UseCase skła­da się zwy­kle z jed­ne­go lub wię­cej opi­sów frag­men­tów zacho­wa­nia, któ­re mają być wsta­wio­ne w odpo­wied­nie miej­sca roz­sze­rza­ne­go przy­pad­ku uży­cia. Rozszerzenia są więc spe­cy­fi­ka­cją wszyst­kich róż­nych punk­tów roz­sze­rzeń w danym przy­pad­ku uży­cia, w któ­rych moż­na umie­ścić dodat­ko­we zachowania.”

Innymi sło­wy, for­mal­nie moż­na na Diagramie Przypadków Użycia poka­zać, to że sce­na­riusz przy­pad­ku uży­cia jest podzie­lo­ny na frag­men­ty, któ­re są wyko­ny­wa­ne warun­ko­wo. Jest to jed­nak mode­lo­wa­nie sce­na­riu­sza zawie­ra­ją­ce­go instruk­cje if … then”. Tu przy­po­mnę więc klu­czo­wą zasa­dę, zapi­sa­ną w spe­cy­fi­ka­cji UML: Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia [mode­lo­wa­ne­go] przed­mio­tu bez odwo­ły­wa­nia się do jego wewnętrz­nej struk­tu­ry”. Dlatego wie­lu auto­rów zwra­ca uwa­gę na pew­ne, takie jak ta, nie­kon­se­kwen­cje w specyfikacji. 

Include

Specyfikacja UML:

The Include rela­tion­ship is inten­ded to be used when the­re are com­mon parts of the beha­vior of two or more UseCases. This com­mon part is then extrac­ted to a sepa­ra­te UseCase, to be inc­lu­ded by all the base UseCases having this part in com­mon. As the pri­ma­ry use of the Include rela­tion­ship is for reu­se of com­mon parts, what is left in a base UseCase is usu­al­ly not com­ple­te in itself but depen­dent on the inc­lu­ded parts to be meaning­ful. This is reflec­ted in the direc­tion of the rela­tion­ship, indi­ca­ting that the base UseCase depends on the addi­tion but not vice versa.

Innymi sło­wy: jeże­li dwa Przypadki Użycia mają pew­ne wspól­ne frag­men­ty zacho­wa­nia, moż­na taki frag­ment wyjąć przed nawias”, ten frag­ment jest na dia­gra­mie repre­zen­to­wa­ny tak­że jako Przypadek Użycia, jed­nak jest to nie­sa­mo­dziel­ny frag­ment, sta­no­wią­cy część wspól­ną co naj­mniej dwóch PU bazo­wych i on sam z sie­bie nie repre­zen­tu­je samo­dziel­ne­go zacho­wa­nia. Ten wspól­ny, wyłą­czo­ny frag­ment, łączy­my z PU bazo­wy­mi związ­kiem «inc­lu­de».

Tak więc związ­ki «inc­lu­de» i «extend» owszem nadal są w spe­cy­fi­ka­cji UML, jed­nak Wynika to z fak­tu, że Przypadki uży­cia mogą być spe­cy­fi­ko­wa­ne w róż­nych for­ma­tach, takich jak język natu­ral­ny, tabe­le, drze­wa itp.” i ktoś może chcieć taki tek­sto­wy for­mat zobra­zo­wać na Diagramie. 

Konsekwencje

Diagram Przypadków uży­cia ma rodo­wód w meto­dy­ce struk­tu­ral­nej (sto­so­wa­nie instruk­cji go to” i sub­ro­uti­ne” w pro­gra­mo­wa­niu struk­tu­ral­nym). Związki «extend» i «inc­lu­de» mają wła­śnie taki rodo­wód i nadal są w nota­cji UML, gdyż Diagram Przypadków Użycia jest nadal popu­lar­nym narzę­dziem w meto­dach struk­tu­ral­nych. Jest też nie­kon­se­kwen­cją spe­cy­fi­ka­cji UML, co widać w jej tre­ści, gdzie na począt­ku roz­dzia­łu auto­rzy spe­cy­fi­ka­cji UML zwra­ca­ją jed­nak uwa­gę, że Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia przed­mio­tu bez odwo­ły­wa­nia się do jego wewnętrz­nej struk­tu­ry”. Więc sto­so­wa­nie powyż­szych związ­ków jest relik­tem metod struk­tu­ral­nych, i nie nale­ży ich sto­so­wać w pro­jek­tach zorien­to­wa­nych obiek­to­wo, tym bar­dziej, że jest to łama­nie pod­sta­wo­wej zasa­dy para­dyg­ma­tu obiek­to­we­go jaką jest hermetyzacja. 

Autorzy spe­cy­fi­ka­cji nota­cji UML, takim oto przy­kła­dem pod­su­mo­wu­ją roz­dział 18. Przypadki Użycia:

Jak widać celem pro­jek­to­wa­nia ban­ko­ma­tu są: Wypłata, Wpłata, Przelew, a tak­że: Rejestrowanie ban­ko­ma­tu (w sie­ci) i Udostępnianie listy trans­ak­cji. Detale tych dzia­łań i kolej­ność ich reali­za­cji nie są przed­mio­tem tego mode­lu, nie ma tu związ­ków «inc­lu­de» ani «extend», mimo, że np. trzy klu­czo­we ope­ra­cje wyma­ga­ją uży­cia kar­ty płat­ni­czej i kodu PIN (owszem, wspól­na część, ale są to jed­nak deta­le sce­na­riu­szy a nie osob­ne PU).

Traktując więc PU zgod­nie z jego pod­sta­wo­wą, przy­to­czo­ną powy­żej defi­ni­cją, jako: okre­ślo­ny cel (powód), dla któ­re­go System jest pro­jek­to­wa­ny”, uzna­je­my, że celem apli­ka­cji biz­ne­so­wej jest np. Rejestrowanie Zamówień czy Fakturowanie, a nie to, że Drukujemy doku­ment”, szu­ka­my fak­tu­ry” czy wpro­wa­dza­my NIP kon­tra­hen­ta”. Pokazanie dru­ko­wa­nia jako wyłą­czo­nej czę­ści wspól­nej, lub roz­sze­rze­nia, PU Faktura i Zamówienie (sto­su­jąc zwią­zek «inc­lu­de» lub «extend»), czy też wydzie­la­nie na dia­gra­mie PU Wybór klien­ta z listy kon­tra­hen­tów”, to pro­jek­to­wa­nie archi­tek­tu­ry i dro­ga do klę­ski tego dia­gra­mu. To, że kom­po­nent reali­zu­ją­cy dru­ko­wa­nie będzie osob­nym ele­men­tem archi­tek­tu­ry tego sys­te­mu zapew­ne jest praw­dą, ale Diagram PU, jak już wie­my, to nie jest model archi­tek­tu­ry sys­te­mu. Nie jest to tak­że spe­cy­fi­ka­cja pro­ce­su biznesowego.

Obiektowo-zorientowane modelowanie systemu

W arty­ku­le Use Case 2.0 opi­sy­wa­łem kon­cep­cję obiek­to­we­go podej­ścia w pro­jek­to­wa­niu zorien­to­wa­nym na Przypadki Użycia, opra­co­wa­ną przez jed­ne­go z współ­twór­ców UML: Ivara Jacobsona . W arty­ku­le Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych opi­sa­łem pro­jek­to­wa­nie opro­gra­mo­wa­nia opar­te na obiek­to­wym para­dyg­ma­cie i wzor­cach pro­jek­to­wych takich jak mikro­ser­wi­sy. Cytowałem mię­dzy inny­mi ten diagram:

Po pra­wej stro­nie powyż­sze­go widzi­my archi­tek­tu­rę zorien­to­wa­ną na mikro­ser­wi­sy. Jest to typo­we i zna­ne od lat kom­po­nen­to­we podej­ście z her­me­ty­za­cją kom­po­nen­tów, reali­zu­ją­cych usłu­gi apli­ka­cji . Bloki [MS] (micro­se­rvi­ces) to nic inne­go jak kom­po­nen­ty reali­zu­ją­ce Przypadki Użycia tego sys­te­mu. Każdy PU ma wła­sną imple­men­ta­cję (i bazę danych, dane [DB] tak­że nie są współ­dzie­lo­ne mię­dzy przy­pad­ka­mi uży­cia). Komponent [UI] to zagre­go­wa­ne na jed­nym ekra­nie wywo­ła­nia usług, czy­li głów­ne menu sys­te­mu. Tak więc Diagram Przypadków Użycia, to model tego głów­ne­go menu sys­te­mu, a nie model imple­men­ta­cji usług (nie archi­tek­tu­ra kodu i nie pro­ces biznesowy).

Podsumowanie

Na poniż­szym dia­gra­mie po lewej stro­nie, poka­za­no for­mal­nie popraw­ny dia­gram przy­pad­ków uży­cia. Z per­spek­ty­wy pro­jek­to­wa­nia zorien­to­wa­ne­go na kom­po­nen­ty, oraz zacho­wa­nia zasa­dy mówią­cej, że ten dia­gram nie słu­ży do mode­lo­wa­nia wewnętrz­nej archi­tek­tu­ry sys­te­mu, popraw­na pro­jek­to­wo jest wer­sja poka­za­na po pra­wej stronie:

Warto też wie­dzieć, że w kon­se­kwen­cji powyż­sze­go, łącze­nie Aktora z wydzie­lo­ny­mi, nie­sa­mo­dziel­ny­mi, opi­sa­mi zacho­wań repre­zen­to­wa­ny­mi przez przy­pad­ki uży­cia 4 i 5, jest pozba­wio­ne logi­ki (podob­nie jak tyl­ko jeden PU połą­czo­ny związ­kiem «inc­lu­de»).

Więc jak i gdzie poka­zać owe sce­na­riu­sze PU? Osobno na dia­gra­mach aktyw­no­ści (role kom­po­nen­tów) lub na dia­gra­mach sekwen­cji (wywo­ły­wa­ne ope­ra­cje inter­fej­sów). (Patrz arty­kuł: Diagram aktyw­no­ści – kie­dy).

Powyższa for­ma (dia­gram po pra­wej stro­nie) ma tak­że prak­tycz­ną zale­tę: Zamawiający zro­zu­mie ten dia­gram. Diagram o po lewej, jest już prak­tycz­ną utra­tą komu­ni­ka­cji z Zamawiającym, bo mało któ­ry z nich stu­diu­je spe­cy­fi­ka­cję UML. Specyfikacja po lewej pro­wa­dzi tak­że do ogrom­ne­go zawy­ża­nia osza­co­wa­nia wycen, gdyż mia­ry opar­te na tak zwa­nych punk­tach funk­cyj­nych, trak­tu­ją każ­dy PU jako samo­dziel­ną, kom­plet­ną jed­ną jed­nost­kę kosztową. 

A co może­my zna­leźć w sie­ci? Poniżej kil­ka przy­kła­dów wraz ze źró­dła­mi, ich oce­nę pozo­sta­wię czytelnikom. 

przykład 1

Major elements of business use case UML diagram.

(w nota­cji UML nie ma i nigdy nie było poję­cia biz­ne­so­wy przy­pa­dek uży­cia”, to poję­cie jest relik­tem meto­dy RUP, Rational Unified Process, z cza­sów gdy nie było nota­cji BPMN i BMM).

przykład 2

Major elements of UML use case diagram.

przykład 3

przykład 4

(źr.: Podstawy mode­lo­wa­nia w języ­ku UML, dr hab. Bożena Woźna-Szcześniak, prof. UJD, Uniwersytet Humanistyczno-Przyrodniczy im. Jana Długosza w Częstochowie, http://​www​.wozna​.org/​s​t​u​d​e​n​t​s​/​2​018 – 2019/uml/UML03.pdf)

Dla porów­na­nia do pobra­nia: Biblioteka

przykład 5

przykład 6

(źr.: Projektowanie Systemów Komputerowych, Laboratoria/Projekty, Krzysztof Regulski, AGH, WIMiIP, DIAGRAM PRZYPADKÓW UŻYCIA – USE CASE MODEL, https://home.agh.edu.pl/~regulski/psk/cw/01_UseCase.pdf)

___

Na koniec pole­cam też arty­kuł: Ile przy­pad­ków uży­cia?

Źródła

D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
architektura kontrukcja

Projektowanie i dokumentowanie architektury oprogramowania – trzy książki

Architektura

Projekty infor­ma­tycz­ne się roz­ra­sta­ją, cała bran­ża ewo­lu­uje. Ostatnie 20 lat doświad­czeń poka­za­ło, że owszem sztu­ką jest stwo­rzyć i wdro­żyć opro­gra­mo­wa­nie, ale jesz­cze więk­szą sztu­ką jest je kon­ser­wo­wać, zmie­niać i roz­wi­jać. Wiele firm bory­ka się z powta­rza­ny­mi dłu­go­trwa­ły­mi i kosz­tow­ny­mi ana­li­za­mi przed­wdro­że­nio­wy­mi” poprze­dza­ją­cy­mi każ­dy kolej­ny pro­jekt wdra­ża­nia zmian. To sku­tek bra­ku aktu­al­nej doku­men­ta­cji posia­da­ne­go sys­te­mu. To jak pla­no­wa­nie nowej budo­wy w mie­ście nie mając aktu­al­nych pla­nów urba­ni­stycz­nych tego mia­sta: każ­dy nowy pro­jekt to ponow­ne doku­men­to­wa­nie sta­nu obec­ne­go, tyl­ko dla­te­go, że ktoś nie udo­ku­men­to­wał zmian wpro­wa­dzo­nych ostat­nim razem (być może poprzed­nio udo­ku­men­to­wał jakiś stan zasta­ny, jed­nak nie aktu­ali­zo­wał tej doku­men­ta­cji). Podobno deve­lo­per pamię­ta co mają jego klien­ci, jed­nak zmia­na deve­lo­pe­ra sta­je się wte­dy trud­na, a nie raz nie­moż­li­wa z powo­du złej umo­wy (pra­wo autor­skie) i bra­ku doku­men­ta­cji (wie­dza w gło­wach pro­gra­mi­stów, wdro­że­niow­ców, bywa, że nigdzie), to efekt zna­ny jako ven­dor lock-in.

Rozwiązaniem jest doku­men­ta­cja sys­te­mu. Co jest głów­nym wyzwa­niem w two­rze­niu doku­men­ta­cji sys­te­mu? Ustalenie kom­pro­mi­su mię­dzy szcze­gó­ło­wo­ścią doku­men­ta­cji a cza­sem i kosz­tem jej opra­co­wa­nia a potem aktu­ali­za­cji. Tym kom­pro­mi­sem jest archi­tek­tu­ra: struk­tu­ra opi­su­ją­ca co i do cze­go słu­ży: ele­men­ty sys­te­mu i ich wza­jem­ne powią­za­nia, ale bez anga­żo­wa­nia się w doku­men­to­wa­nie deta­li tych ele­men­tów (her­me­ty­za­cja). To dla­te­go bar­dzo przy­dat­ne jest kom­po­nen­to­we podej­ście do pro­jek­to­wa­nia i obiek­to­wy para­dyg­mat two­rze­nia opro­gra­mo­wa­nia.

Dzisiaj kil­ka słów o trzech książ­kach, każ­da z nich była na tym blo­gu krót­ko recen­zo­wa­na, razem sta­no­wią moim zda­niem pod­sta­wo­wy zestaw pro­jek­tan­ta. Pod poję­ciem pro­jek­to­wa­nia rozu­mie­my two­rze­nie pro­jek­tu sys­te­mu czy­li doku­men­to­wa­nie tego jakim ma być, lub jakim jest i co w nim zmienimy.

Dokumentowanie architektury

Ta książ­ka to rodzaj pod­su­mo­wa­nia. We wstę­pie czytamy:

Architektura opro­gra­mo­wa­nia – kon­cep­cyj­ny klej, któ­ry spa­ja każ­dą fazę pro­jek­tu, dla jego wie­lu inte­re­sa­riu­szy – jest powszech­nie uzna­wa­na za kry­tycz­ny ele­ment współ­cze­sne­go roz­wo­ju opro­gra­mo­wa­nia. Praktycy coraz czę­ściej prze­ko­nu­ją się, że poświę­ca­nie szcze­gól­nej uwa­gi archi­tek­tu­rze sys­te­mu opro­gra­mo­wa­nia przy­no­si wymier­ne korzy­ści. Bez archi­tek­tu­ry, któ­ra jest odpo­wied­nia dla roz­wią­zy­wa­ne­go pro­ble­mu, pro­jekt będzie się poty­kał, a naj­praw­do­po­dob­niej zakoń­czy się nie­po­wo­dze­niem. Ale nawet przy dosko­na­łej archi­tek­tu­rze, jeśli nie jest ona dobrze rozu­mia­na i prze­ka­zy­wa­na, pro­jekt ma małe szan­se powodzenia. 

Książka Documenting Software Architectures, dostar­cza naj­bar­dziej kom­plet­nych i aktu­al­nych wska­zó­wek, nie­za­leż­nie od języ­ka czy nota­cji, jak ująć archi­tek­tu­rę w powszech­nie zro­zu­mia­łej for­mie. Bazując na swo­im boga­tym doświad­cze­niu, auto­rzy naj­pierw poma­ga­ją zde­cy­do­wać, jakie infor­ma­cje nale­ży udo­ku­men­to­wać, a następ­nie, za pomo­cą wska­zó­wek i przy­kła­dów (w róż­nych nota­cjach, w tym UML), poka­zu­ją, jak wyra­zić archi­tek­tu­rę, aby inni mogli na jej pod­sta­wie z powo­dze­niem budo­wać, uży­wać i utrzy­my­wać sys­tem. Książka zawie­ra zasa­dy two­rze­nia solid­nej doku­men­ta­cji, cele i stra­te­gie doku­men­ta­cji, wido­ki i sty­le archi­tek­to­nicz­ne, doku­men­ta­cję inter­fej­sów opro­gra­mo­wa­nia i zacho­wa­nia opro­gra­mo­wa­nia oraz sza­blo­ny do zbie­ra­nia i orga­ni­zo­wa­nia infor­ma­cji w celu stwo­rze­nia spój­ne­go pakietu. 

Zdaniem auto­rów klu­czem są poję­cia: ele­ment sys­te­mu, jego cechy i związ­ki mię­dzy tymi ele­men­ta­mi. Zwracają uwa­gę na to, że zwią­zek mię­dzy ele­men­ta­mi to ich wza­jem­ne wywo­ły­wa­nie się (współ­pra­ca to nie rela­cje a uży­cie). Mając model poja­wia się dru­ga waż­na rzecz: adre­sa­ci infor­ma­cji czy­li per­spek­ty­wy opi­su sys­te­mu. Dlatego kolej­na istot­na rzecz to treść i for­ma pre­zen­to­wa­nia kontekstu. 

Kolejna książ­ka to Architektura Oprogramowania w Praktyce . Ze wstęu: Wielokrotnie nagra­dza­na i cie­szą­ca się dużym zain­te­re­so­wa­niem Architektura opro­gra­mo­wa­nia w prak­ty­ce, wyda­nie trze­cie, zosta­ła zna­czą­co zmie­nio­ne, aby odzwier­cie­dlić naj­now­sze osią­gnię­cia w tej dzie­dzi­nie. W książ­ce po raz kolej­ny przed­sta­wio­no kon­cep­cje i naj­lep­sze prak­ty­ki archi­tek­tu­ry opro­gra­mo­wa­nia – struk­tu­rę sys­te­mu opro­gra­mo­wa­nia oraz spo­sób, w jaki jego ele­men­ty mają ze sobą współdziałać. 

W tym wyda­niu auto­rzy sku­pi­li się na kon­cep­cji roz­wo­ju archi­tek­tu­ry. Każdy cykl roz­wo­ju poka­zu­je, w jaki spo­sób archi­tek­tu­ra wpły­wa na okre­ślo­ny kon­tekst, w któ­rym odgry­wa klu­czo­wą rolę, oraz jak jest kształ­to­wa­na przez ten kon­tekst. Konteksty te obej­mu­ją śro­do­wi­sko tech­nicz­ne, cykl życia pro­jek­tu, pro­fil biz­ne­so­wy orga­ni­za­cji oraz prak­ty­ki zawo­do­we archi­tek­ta. Autorzy znacz­nie roz­sze­rzy­li tak­że omó­wie­nie atry­bu­tów jako­ści, któ­re pozo­sta­ją cen­tral­nym ele­men­tem ich filo­zo­fii archi­tek­tu­ry – każ­de­mu z atry­bu­tów poświę­ci­li cały roz­dział – oraz roz­sze­rzy­li omó­wie­nie wzor­ców architektonicznych.” 

Autorzy cie­ka­wie pre­zen­tu­ją to jak i po co powsta­je doku­men­ta­cja: pro­ce­so­wo. Streszczają (pre­zen­tu­ją) treść książ­ki w posta­ci kil­ku pro­stych mode­li procesów:

Ta for­ma bar­dzo mi się spodo­ba­ła: poka­zu­je bodź­ce, model (arti­fact) logi­ki i efekt uzy­ska­ny. Generalnie auto­rzy w swo­jej książ­ce pre­zen­tu­ją prak­tycz­ne aspek­ty doku­men­to­wa­nia opro­gra­mo­wa­nia i sto­so­wa­nia tej doku­men­ta­cji. Pamiętajmy tak­że, że doku­men­ta­cja opro­gra­mo­wa­nia to przede wszyst­kim jego modele. 

Na koniec zosta­wi­łem książ­kę naj­star­szą: Large-Scale Software Architecture .

Jak piszą auto­rzy, celem pro­jek­to­wa­nia (doku­men­to­wa­nia) archi­tek­tu­ry dużych apli­ka­cji jest uchwy­ce­nie i opi­sa­nie prak­tycz­nych metod jego zobra­zo­wa­nia (udo­ku­men­to­wa­nia), mają­cych na celu zwięk­szyć efek­tyw­ność komu­ni­ka­cji zespo­łów pro­gra­mi­stów i ich zro­zu­mie­nia kon­tek­stu systemu.

W tej książ­ce auto­rzy poka­zu­ją, jak wyko­rzy­stać archi­tek­tu­rę opro­gra­mo­wa­nia już jako narzę­dzie na eta­pie zarzą­dza­nia roz­wo­jem apli­ka­cji, nie tyl­ko jako powy­ko­naw­czą doku­men­ta­cję po pod­ję­ciu wszyst­kich decy­zji pro­jek­to­wych. Prezentują w swo­jej książce:

  • Zwięzły opis wyko­rzy­sta­nia języ­ka UML w archi­tek­tu­rze dużych aplikacji, 
  • Architekturę opro­gra­mo­wa­nia i zasa­dy jej projektowania,
  • Zwracają uwa­gę na jej nie­za­leż­ność od tech­no­lo­gii i dostawców.
Struktura projektu UML

Tę książ­kę moż­na pod­su­mo­wać tak: każ­da archi­tek­tu­rę nale­ży doku­men­to­wać od ogó­łu do szcze­gó­łu, każ­dy model powi­nien być pro­sty i zwię­zły ale mode­li tych może być wie­le, każ­dy sys­tem to jego klu­czo­wa rola, jego wewnętrz­na struk­tu­ra i zacho­wa­nia jego skła­do­wych ele­men­tów oraz jego poję­cio­wy dzie­dzi­no­wy ogól­ny opis. 

Podsumowanie

Powyższe opi­sy to klu­czo­we cechy każ­dej z tych trzech pozy­cji. Moją inten­cją było pole­ce­nie tych trzech pozy­cji jako zesta­wu pre­zen­tu­ją­ce­go dość kom­plet­ną wie­dzę na temat sta­nu wie­dzy na temat pro­jek­to­wa­nia opro­gra­mo­wa­nia sku­pia­ją­ce­go się na jego archi­tek­tu­rze. Jako efekt uzy­sku­je­my doku­men­ta­cję rela­tyw­nie szczu­płą obję­to­ścio­wo, więc będzie czy­ta­na. Stosowanie stan­dar­du nota­cyj­ne­go, jakim jest UML, uzy­sku­je­my sze­ro­ki zasięg odbior­ców i uni­wer­sal­ność. Zwracają na to uwa­gę auto­rzy wszyst­kich tych trzech pozycji. 

Ostatnia pozy­cja to kla­sy­ka kom­po­nen­to­we­go podej­ścia do pro­jek­to­wa­nia. Pierwsze dwie powsta­ły kil­ka lat po fascy­na­cji auto­rów zwin­nym podej­ściem (agi­le). Podobnie jak Scott Ambler , odkry­li że zbyt­nie przy­kła­da­nie wagi do dzia­ła­ją­ce­go opro­gra­mo­wa­nia” na nie­ko­rzyść jego doku­men­ta­cji, powo­du­je szko­dy na kolej­nych eta­pach cyklu życia pro­duk­tu jakim jest aplikacja. 

Żadne opro­gra­mo­wa­nie nie powsta­je tyl­ko na jeden dzień, będzie komuś słu­ży­ło mie­sią­ca­mi, lata­mi, a świat nie stoi w miej­scu. sta­wia­nie tezy, że celem two­rze­nia opro­gra­mo­wa­nia jego powsta­nie jest szko­dli­we. Kluczem jest cykl życia opro­gra­mo­wa­nia, a jego doku­men­ta­cja to jedy­na for­ma komu­ni­ko­wa­nia się zmie­nia­ją­cych się osób, lata­mi zaan­ga­żo­wa­nych w utrzy­ma­nie i roz­wój aplikacji. 

Te trzy książ­ki to moim zda­niem mały zbiór rze­tel­nej wie­dzy, któ­ry powi­nien pomóc każ­de­mu począt­ku­ją­ce­mu i zagu­bio­ne­mu junio­ro­wi ana­li­zy biz­ne­so­wej” w nauce two­rze­nia wyso­kiej jako­ści doku­men­ta­cji. To tak­że wie­dza przy­dat­na dla doświad­czo­nych ana­li­ty­ków i pro­jek­tan­tów: zawsze war­to wie­dzieć jak robią to inni, mają­cy ogrom­ny doro­bek. Dokumentacja sys­te­mu to jedy­ne trwa­łe źró­dło wie­dzy o nim, jed­nak zła i nie­ak­tu­al­na doku­men­ta­cja jest gor­sza od jej braku… 

Źródła

Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Merson, P., Nord, R., & Stafford, J. (2015). Documenting Software Architecture (Second, Vol. 1 – 1). Pearson Education, Inc.
Bass, L., Clements, P., & Kazman, R. (2013). Software archi­tec­tu­re in prac­ti­ce (3rd ed). Addison-Wesley.
Ambler, S. W. (2002). Agile mode­ling. John Wiley & Sons.
Ambler, S. W. (2004). The object pri­mer. Agile Model-Driven Development with UML 2.0 (Third Edition). Cambridge University Press.
Garland, J., & Anthony, R. (2003). Large-sca­le softwa­re archi­tec­tu­re: a prac­ti­cal guide using UML. J. Wiley.

Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy

Artykuł ma dwie czę­ści. Pierwsza część jest adre­so­wa­na do kadr zarząd­czych, cały arty­kuł (obie czę­ści) do osób zaj­mu­ją­cych się pro­jek­to­wa­niem roz­wią­zań. (22.04.2022 dopi­sa­łem Dodatek).

Wstęp

Mamy ogól­no­świa­to­wą sieć Internet, apli­ka­cje lokal­ne i w chmu­rze, apli­ka­cje naszych kon­tra­hen­tów i apli­ka­cje cen­tral­nych urzę­dów. Wszystkie one współ­pra­cu­ją i wymie­nia­ją dane, czy­li są zin­te­gro­wa­ne. Dlatego inte­gra­cja sta­ła się jed­nym z obli­ga­to­ryj­nych wyma­gań każ­de­go sys­te­mu informatycznego. 

Pogodzenie się z tym, że świat już nigdy nie będzie tak pro­sty jak 40 lat temu jest nie­unik­nio­ne. Podobnie jak pogo­dze­nie się z tym, że cza­sy jed­nej cen­tral­nej apli­ka­cji też ode­szły do lamu­sa. Praktyka zaś poka­zu­je, że idea zbu­do­wa­nia wszyst­kich funk­cjo­nal­no­ści jako zin­te­gro­wa­nej apli­ka­cji na jed­nej współ­dzie­lo­nej bazie danych jest utopią. 

Czytaj dalej… Integracja sys­te­mów ERP jako źró­dło prze­wa­gi ryn­ko­wej. Projektowanie REST API i sce­na­riu­szy”

Prawo autorskie – czy jest skuteczne?

Wstęp

Prawo autor­skie sta­no­wi natu­ral­ny przed­miot zain­te­re­so­wa­nia każ­de­go, kogo efek­ty pra­cy są tym pra­wem chro­nio­ne. Czasami pra­wo to sta­je się przed­mio­tem badań, jak w moim przy­pad­ku, bo nie tyl­ko to co two­rzę, pod­le­ga ochro­nie praw­no­au­tor­skiej, ale też sta­no­wi to war­tość nie­ma­te­rial­ną dla bene­fi­cjen­tów mojej pra­cy: pod­mio­tów będą­cych przed­mio­tem moich audy­tów i ana­liz, prze­ka­zy­wa­ną im war­to­ścią tego co pro­jek­tu­ję: pro­jek­tów rozwiązań. 

Moje bada­nia nie doty­czą jed­nak aktu­al­ne­go sta­nu praw­ne­go, doty­czą mecha­ni­zmu powsta­wa­nia i praw­nej ochro­ny war­to­ści intelektualnych. 

Prawo autor­skie budzi wie­le emo­cji i kon­tro­wer­sji z wie­lu powo­dów. Jednym z nich jest to, że czę­sto sta­wia­ny jest mu zarzut, że jest nie­sku­tecz­ne w pew­nych obszarach:

Dla filo­zo­fa pra­wa wyjąt­ko­wo inte­re­su­ją­cym przed­mio­tem badań są pra­wa autor­skie. Wynika to z fak­tu, iż odkąd poja­wił się Internet, dotych­cza­so­we w peł­ni satys­fak­cjo­nu­ją­ce ure­gu­lo­wa­nia sta­ły się nieskuteczne. 

Autorka powyż­sze­go napi­sa­ła cie­ka­wy esej, do któ­re­go posta­ram się odnieść na grun­cie sys­te­mów infor­ma­cyj­nych i tech­no­lo­gii z nimi zwią­za­nych (wspo­mi­na­ny przez autor­kę Internet tak­że). Jest to pró­ba wyja­śnie­nia kry­ty­ko­wa­ne­go zja­wi­ska jakim jest łatwość kopio­wa­nia, oraz teza i jej obro­na, że nie pra­wo autor­skie jest tu źró­dłem pro­ble­mu a życze­nio­we podej­ście wie­lu posia­da­czy praw mająt­ko­wych, do jego sto­so­wa­nia. W 2012 roku pisa­łem, że nie moż­na się obra­żać” na postęp:

Prostą, nadal funk­cjo­nu­ją­cą, barie­rą blo­ku­ją­cą powie­la­nie (two­rze­nie replik, repro­duk­cji ory­gi­na­łów np. rzeźb) dzieł mate­rial­nych jest wyma­ga­na umie­jęt­ność porów­ny­wal­na do tej, jaką cechu­je się autor ory­gi­na­łu. W przy­pad­ku dzieł nie­ma­te­rial­nych ta barie­ra nie ist­nie­je, bo do sko­pio­wa­nia naj­lep­sze­go nawet utwo­ru lite­rac­kie­go czy muzycz­ne­go wystar­czy np. kom­pu­ter, nie są potrzeb­ne żad­ne, poza obsłu­gą kom­pu­te­ra, umiejętności.

(źr.: Prawo autor­skie i war­to­ści nie­ma­te­rial­ne – ana­li­za sys­te­mo­wa)

Powyższy arty­kuł z 2012 roku, pole­cam jako lek­tu­rę początkową. 

Czytaj dalej… Prawo autor­skie – czy jest sku­tecz­ne?”

Analiza efektywności i kosztów czyli symulacja procesu

Wstęp

Produktem mode­lo­wa­nia pro­ce­sów biz­ne­so­wych są jakieś dia­gra­my, i z tym jeste­śmy oswo­je­ni. Od cza­su do cza­su moż­na usły­szeć o symu­la­cjach pro­ce­sów, lecz to już jed­nak znacz­nie rza­dziej. O symu­la­cjach pro­ce­sów pisze się mniej: Google Scholar (lite­ra­tu­ra nauko­wa) poka­zu­je ok. 5 mln publi­ka­cji na temat mode­lo­wa­nia pro­ce­sów biz­ne­so­wych, na temat ich symu­la­cji 2 mln mniej. Ale już Google („cały Internet”) odpo­wied­nio: 2,3 mld. i 282 mln. Jak widać w powszech­nym obie­gu symu­la­cje, jako temat, to trzy rzę­dy (tysiąc­krot­nie) mniej­sza ilość tek­stów! (wyszu­ki­wa­ne były hasła ang. «busi­ness pro­cess mode­ling» oraz «busi­ness pro­cess simu­la­tion»). Zastanówmy się dla­cze­go i co moż­na osią­gnąć symulacją.

Czytaj dalej… Analiza efek­tyw­no­ści i kosz­tów czy­li symu­la­cja pro­ce­su”

Business Knowledge Blueprints

Ronald G. Ross 

Ronald G. Ross jest auto­rem lub współ­au­to­rem wie­lu opra­co­wań na temat mode­li poję­cio­wych i zarzą­dza­nia wie­dzą . Jest tak­że współ­za­ło­ży­cie­lem Business Rule Solution LLC, oraz współ­twór­cą spe­cy­fi­ka­cji i nota­cji SBVR .

Książka

Najnowsze z powyż­szych opra­co­wań to rodzaj pod­su­mo­wa­nia pew­nej czę­ści dorob­ku autora.

Modele poję­cio­we są czę­sto mylo­ne z pro­jek­to­wa­niem rela­cyj­ne­go mode­lu danych, a bywa gorzej, gdy są utoż­sa­mia­ne z mode­lem dzie­dzi­ny sys­te­mu” w pro­jek­tach doty­czą­cych two­rze­nia apli­ka­cji okre­śla­nych jako„obiektowe”.

Książka trak­tu­je o mode­lach poję­cio­wych, i autor defi­niu­je je jako: 

model poję­cio­wy: upo­rząd­ko­wa­ny zbiór pojęć i związ­ków mię­dzy nimi

Podstawowym związ­kiem mię­dzy poję­cia­mi (nazwa­mi) jest fakt (pre­dy­kat: zwią­zek zda­nio­twór­czy) łączą­cy poję­cia w popraw­ne i praw­dzi­we zdania. 

Przykład: poję­cia «pies» oraz «listo­nosz» to nazwy słow­ni­ko­we. Połączone fak­tem (pre­dy­ka­tem) two­rzą zda­nie, np.: „ «Pies» szcze­ka na «listo­no­sza» ” (z uwzględ­nie­niem pol­skiej flek­sji, «szcze­ka (na)» to fakt – pre­dy­kat). Jest to zda­nie popraw­ne a tak­że zda­nie praw­dzi­we: jest praw­dą, że pies szcze­ka na listo­no­sza” (to rela­cja), albo: jest moż­li­we, że pies szcze­ka na listo­no­sza” (jest praw­dą to, że to może się to wyda­rzyć). Ważna rzecz: poję­cia to nie sło­wa, to to co opi­su­ją defi­ni­cje tych pojęć (patrz: trój­kąt semio­tycz­nysemio­ty­ka).

Budowanie takich zdań to kon­tro­la (testo­wa­nie) popraw­no­ści mode­lu poję­cio­we­go, test spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści mode­lu poję­cio­we­go. Poprawny model poję­cio­wy (name­spa­ce) to pod­sta­wo­wy waru­nek np. póź­niej­szej spój­no­ści całe­go sys­te­mu zarzą­dza­nia infor­ma­cją (tak­że dany­mi), doku­men­ta­mi (gro­ma­dzą dane), meta­da­ny­mi (opi­su­ją dane). 

Podtytuł książ­ki to: About Vocabulary & Concept Models (O słow­nic­twie i mode­lach poję­cio­wych). Warto wie­dzieć, że zna­ko­mi­ta więk­szość nie­uda­nych pro­jek­tów i wdro­żeń opro­gra­mo­wa­nia to sku­tek błę­dów w mode­lach poję­cio­wych (nazew­nic­two).

Nazewnictwo to nie tyl­ko nazwy doku­men­tów, tabel i pól (ety­kiet danych), to tak­że same dane czy­li nazwy sta­no­wią­ce war­to­ści pól for­mu­la­rzy: nazwy miast, nazwi­ska, nazwy przed­mio­tów, pro­duk­tów, itp. Dawno temu już skoń­czy­ły się cza­sy, gdy kom­pu­te­ry tyl­ko liczy­ły” (to wte­dy powsta­ła idea rela­cyj­ne­go mode­lu danych). Obecnie kom­pu­te­ry prze­twa­rza­ją dane nie będą­ce licz­ba­mi, dane niestrukturalne. 

Zarządzanie wie­dzą to nie są obliczenia.

Autor pisze: akt two­rze­nia danych (zapi­sy­wa­nie infor­ma­cji) to akt komu­ni­ka­cji: to prze­kaz (wia­do­mość) dla przy­szłych czy­tel­ni­ków, odbior­ców tych danych. Dlatego komu­ni­kat (treść), musi (powi­nen) być zro­zu­mia­ły i jed­no­znacz­ny. Jedynym spo­so­bem zagwa­ran­to­wa­nia tego jest popraw­ność uży­te­go zaso­bu pojęć (słow­nic­twa). To wła­śnie jest miej­sce na ana­li­zy i pro­jek­to­wa­nie: naj­pierw mode­li poję­cio­wych a potem mode­li i struk­tur danych. 

Pewną wadą moim zda­niem jest wpro­wa­dze­nie przez auto­ra nowej sym­bo­li­ki dla gene­ra­li­za­cji (budo­wa­nie tak­so­no­mii) w posta­ci pogru­bio­nej linii”. Jednak każ­dy kto zna UML i pozna SBVR, moim zda­niem, bez pro­ble­mu sobie z tym pora­dzi (Visual Paradigm tak wła­śnie zro­bił: gene­ra­li­za­cje na mode­lach fak­tów obra­zo­wa­ne są jako strzał­ki z zamknię­tym gro­tem, zna­ne z UML, podej­ście to opi­su­je Dodatek C do spe­cy­fi­ka­cji SBVR). 

Modele pojęciowe

Modele poję­cio­we są bar­dzo czę­sto mylo­ne z mode­lem pro­ce­sów. Jest to kon­se­kwen­cja sto­so­wa­nia związ­ków skie­ro­wa­nych (aso­cja­cje skie­ro­wa­ne w UML, mode­le poję­cio­we są wyra­ża­ne jako kon­tek­sto­we dia­gra­my klas). Zdanie pies szcze­ka na listo­no­sza” to nie pro­cess (biz­ne­so­wy), to zda­nie spraw­dza­ją­ce popraw­ność uży­tych nazw (pies, listo­nosz) i rozu­mie­nia tych pojęć (komu­ni­kat) oraz praw­dzi­wość zda­nia jako takie­go. Przykład: 

Diagram fak­tów nota­cji SBVR, przy­kład wery­fi­ka­cji pojęć pies i listo­nosz oraz zda­nia pies szcze­ka na listo­no­sza”. (dia­gra­my opra­co­wa­ne z uży­ciem Visual Paradigm).

Powyższy dia­gram zawie­ra dwa poję­cia słow­ni­ko­we: pies, listo­nosz (for­mal­nie powin­ny być tak­że w słow­ni­ku i mieć swo­je jed­no­znacz­ne defi­ni­cje). Górna część dia­gra­mu to gra­ficz­na for­ma, omó­wio­ne­go wyżej, zda­nia pies szcze­ka na listo­no­sza”. Typowe zda­nia to co naj­mniej dwie nazwy połą­czo­ne pre­dy­ka­tem (fak­tem: szcze­ka­nie to fakt). Dolna część dia­gra­mu to zda­nie zbu­do­wa­ne z jed­nej nazwy i pre­dy­ka­tu: Pies szcze­ka”. To tak­że jest popraw­ne zda­nie. Metoda i sys­tem nota­cyj­ny, two­rze­nia mode­li poję­cio­wych (opar­ta na logi­ce pre­dy­ka­tów) zosta­ła opi­sa­na i opu­bli­ko­wa­na jako stan­dard SBVR (patrz tak­że OWL: Web Ontology Language) .

Autor w książ­ce dokład­nie opi­su­je róż­ni­cę mię­dzy mode­lem poję­cio­wym a mode­lem danych: model poję­cio­wy i model danych do róż­ne modele!

Model danych i model poję­cio­wy to nie to samo!

Autor poka­zu­je tak­że zasto­so­wa­nie dia­gra­mów fak­tów do mode­lo­wa­nia ontologii.

Na zakończenie

Słownik jest bar­dzo waż­ny bo sta­no­wi fun­da­ment logi­ki biz­ne­so­wej wyra­żo­nej w posta­ci reguł biz­ne­so­wych (busi­ness rules, patrz arty­kuł z 2015 roku: Reguły biz­ne­so­we, decy­zje i poję­cia). Autor dokład­nie opi­su­je meto­dy two­rze­nia słow­ni­ków i dia­gra­mów fak­tów, w dodat­kach jest omó­wio­ny przy­kład kom­plet­ne­go mode­lu wraz ze słow­ni­kiem. Tu, jako uzu­peł­nie­nie, pole­cam książ­kę prof. Hołówki o logi­ce i two­rze­niu defi­ni­cji pojęć .

Gorąco zachę­cam do lek­tu­ry tej książ­ki, moim zda­niem jest to typo­wa pozy­cja must have” dla każ­de­go ana­li­ty­ka i pro­jek­tan­ta sys­te­mów infor­ma­cyj­nych. Więcej na ten temat napi­sa­łem w 2016 roku w arty­ku­le: Model poję­cio­wy, model danych, model dzie­dzi­ny sys­te­mu.

Literatura

OMG​.org. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). 334. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/
Ronald G. Ross. (2020). Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business (2nd Edition). Business Ruless Solution LLC.
OMG​.org. (2014, September). Ontology Definition Metamodel (ODM).
Al-Fedaghi, S. (2020). Conceptual Modeling of Time for Computational Ontologies. 14.
Hołówka, T. (2012). Kultura logicz­na w przy­kła­dach (Wydawnictwo Naukowe PWN, Ed.). Wydawnictwo Naukowe PWN.
Ross, R. G. (2013). Business rule con­cepts: get­ting to the point of know­led­ge (4th Ed). Business Rule Solutions.
Ross, R. G., & Lam, G. S. W. (2011). Building busi­ness solu­tions: busi­ness ana­ly­sis with busi­ness rules. Business Rule Solutions.