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/

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”

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.

Practical Event-Driven Microservices Architecture

Practical Event-Driven Microservices Architecture Building Sustainable and Highly Scalable Event-Driven Microservices

Hugo Rocha ma pra­wie dzie­się­cio­let­nie doświad­cze­nie w pra­cy z wyso­ce roz­pro­szo­ny­mi, ste­ro­wa­ny­mi zda­rze­nia­mi archi­tek­tu­ra­mi mikro­ser­wi­sów. Obecnie jest sze­fem inży­nie­rii w wio­dą­cej glo­bal­nej plat­for­mie ecom­mer­ce dla pro­duk­tów luk­su­so­wych (Farfetch), świad­czą­cej usłu­gi dla milio­nów aktyw­nych użyt­kow­ni­ków, wspie­ra­nej przez archi­tek­tu­rę ste­ro­wa­ną zda­rze­nia­mi z set­ka­mi mikro­ser­wi­sów prze­twa­rza­ją­cych set­ki zmian na sekun­dę. Wcześniej pra­co­wał dla kil­ku refe­ren­cyj­nych firm tele­ko­mu­ni­ka­cyj­nych, któ­re prze­cho­dzi­ły od apli­ka­cji mono­li­tycz­nych do archi­tek­tur zorien­to­wa­nych na mikro­ser­wi­sy. Hugo kie­ro­wał kil­ko­ma zespo­ła­mi, któ­re każ­de­go dnia bez­po­śred­nio sty­ka­ją się z ogra­ni­cze­nia­mi archi­tek­tur ste­ro­wa­nych zda­rze­nia­mi. Zaprojektował roz­wią­za­nia dla kry­tycz­nych ele­men­tów wyso­ce roz­pro­szo­nej plat­for­my bac­kof­fi­ce, obsłu­gu­ją­cej set­ki zmian na sekun­dę, współ­bież­nie, ska­lo­wal­nie i z wyso­ką wydajnością.

Ten opi­so­wy prze­wod­nik prze­pro­wa­dzi Cię przez eta­py prze­no­sze­nia plat­for­my z milio­na­mi użyt­kow­ni­ków z archi­tek­tu­ry mono­li­tu do archi­tek­tu­ry ste­ro­wa­nej zda­rze­nia­mi z wyko­rzy­sta­niem mikro­ser­wi­sów. Poznasz wyzwa­nia i zło­żo­no­ści, któ­re poja­wia­ją się w śro­do­wi­skach o dużej prze­pu­sto­wo­ści, zawie­ra­ją­cych czę­sto set­ki mikro­ser­wi­sów. Książka ta zosta­ła zapro­jek­to­wa­na jako naj­lep­sze źró­dło wie­dzy o tym, jak sto­so­wać archi­tek­tu­rę ste­ro­wa­ną zda­rze­nia­mi w rze­czy­wi­stych sce­na­riu­szach i ofe­ru­je set­ki wzor­ców do poko­na­nia powszech­nych i nie tak powszech­nych wyzwań.

Source: Practical Event-Driven Microservices Architecture | SpringerLink

Diagram: Jeden model dwa konteksty Diagram przedstawia obiekty biznesowe - dokumenty () pochodzące z dwóch różnych kontaktów. Na schemacie mamy trzy klasyfikatory reprezentujące dokumenty i ich struktury. W celu usunięcia kolizji pojęć opisanej przez Fowlera (FOWLER 2014) obiekty funkcjonujące w dwóch różnych kontaktach zostały rozdzielone na dwie kontekstowe przestrzenie pojęciowe: Sprzedaż oraz Serwis. W kontekście Sprzedaż pojęcia Klient i Produkt zostały użyte do nazwania obiektów biznesowych będących przedmiotami mającymi tożsamość. W kontekście Serwis pojęcia te (klient i produkt) ca jedynie cechami (atrybutami) obiektu biznesowego Uszkodzenie, słowa te (pojęcia) stanowią jedynie nazwy atrybutów a konkretne nazwy klienta i produktu stanowią wartość tych atrybutów i jako obiekty nie mają tu tożsamości (value UML i value object w DDD). Tak więc problem kolizji nazewnictwa została rozwiązany, warto tu zwrócić, że zbudowanie jednej spójnej relacyjnej bazy danych dla wszystkich pojęć obu tych dziedzin jest niemożliwe bez dodatkowych zabiegów z nazewnictwem.

Modelowanie architektury HLD i LLD usług aplikacji – modelowanie podsystemów

Wstęp

Tym razem krót­ki arty­kuł na temat pew­nej cie­ka­wej kon­struk­cji. Została ona opi­sa­na przez Rebekę Wirfs-Brock w 1999 roku . Pomysł nie zdo­był sobie wte­dy raczej zbyt dużej popu­lar­no­ści, jed­nak obec­nie, w dobie wzor­ców opar­tych o mikro­ser­wi­sy i mikro apli­ka­cje, ma szan­sę wró­cić do łask. Ja sto­su­ję go już od pew­ne­go cza­su. Skróty HLD i LLD to odpo­wied­nio: High-Level Design (pro­jekt wyso­kie­go pozio­mu) i Low-Level Design (pro­jekt niskie­go pozio­mu). Są to pozio­my abs­trak­cji w mode­lu PIM. 

Czytaj dalej… Modelowanie archi­tek­tu­ry HLD i LLD usług apli­ka­cji – mode­lo­wa­nie pod­sys­te­mów”