Diagram Przypadków Użycia UML

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/

Mikroserwisy c.d.?

Dwa lata temu pisa­łem o mikroserwisach:

Obecnie mamy już dość dobrze wypra­co­wa­ne wzor­ce pro­jek­to­we ale nadal jest pro­blem ze zro­zu­mie­niem ?kie­dy i jak?. Ładnie to opi­sał swe­go cza­su E.Evans przy oka­zji wzor­ca DDD, Tu poprze­sta­nę jedy­nie na poję­ciu boun­ded con­text czy­li ?gra­ni­ca kon­tek­stu?. Granica ta ma podwój­ne zna­cze­nie: kon­tekst nada­je (zmie­nia) zna­cze­nia w mode­lu poję­cio­wym (bał­wan w kon­tek­ście zimy to co inne­go niż bał­wan w kon­tek­ście człon­ków zespo­łu pro­jek­to­we­go) oraz kon­tekst (bar­dzo czę­sto) wyzna­cza zakres pro­jek­tu (inne aspek­ty wzor­ca DDD tu pomi­nę). Pierwsza uwa­ga: kon­tekst dzie­dzi­no­wy (poję­cio­wy) jest waż­niej­szy (powi­nien być nad­rzęd­ny) wobec zakre­su pro­jek­tu, ten dru­gi jest usta­la­ny, dru­gi wyni­ka z sys­te­mu poję­cio­we­go (bał­wan z oka­zji zimy będzie trwal­szym poję­ciem w pro­jek­cie niż bał­wan z oka­zji człon­ków doraź­ne­go spo­tka­nia zespo­łu). (Źródło: Granice kon­tek­stu i mikro­ser­wi­sy)

Mikroserwisy to bar­dzo wygod­na archi­tek­tu­ra. Wymaga cał­ko­wi­tej rezy­gna­cji z jed­ne­go, rela­cyj­ne­go sys­te­mu danych dla dużej apli­ka­cji, dzię­ki cze­mu moż­li­we jest nie­za­leż­ne, ite­ra­cyj­no-przy­ro­sto­we (zwin­ne) imple­men­to­wa­nie kolej­nych usług.?(Woodie, 2018)? ?(Arsov, 2017)? Powyższy arty­kuł zawie­ra kil­ka przy­kła­dów (pole­cam lek­tu­rę cało­ści), któ­re poka­zu­ją przy­czy­ny pro­ble­mów z tra­dy­cyj­ny­mi cało­ścio­wo” zin­te­gro­wa­ny­mi sys­te­ma­mi (np. ERP).

Ogólna idea to budo­wa­nie apli­ka­cji tak, by każ­dy przy­pa­dek uży­cia sta­no­wił prak­tycz­nie odręb­ny mały kom­po­nent. W efek­cie mamy dużą swo­bo­dę zarzą­dza­nia kolej­no­ścią ich imple­men­ta­cji a lokal­ne mody­fi­ka­cje nie prze­no­szą się na resz­tę sys­te­mu. Ewentualne współ­dzie­lo­ne kom­po­nen­ty to wyłącz­nie ele­men­ty logi­ki biz­ne­so­wej, co nie ogra­ni­cza zbyt moc­no kolej­no­ści imple­men­to­wa­nych i wdra­ża­nych usług aplikacyjnych. 

Architektura ta jest zna­na od lat, dość pre­cy­zyj­nie opi­sał ją Fowler w 2014 roku (Microservices). 

Czym są mikro­usłu­gi? Zwrot w kie­run­ku opro­gra­mo­wa­nia opar­te­go o mikro­usłu­gi i kon­te­ne­ry to cicha rewo­lu­cja, któ­ra w ostat­nich mie­sią­cach doko­nu­je się na glo­bal­nym ryn­ku IT. Mikrousługi sta­no­wią alter­na­ty­wę dla mono­li­tycz­ne­go sty­lu two­rze­nia opro­gra­mo­wa­nia. Tworząc apli­ka­cje z wyko­rzy­sta­niem archi­tek­tu­ry mikro­usług i kon­te­ne­rów, pro­gra­mi­ści mogą odpo­wied­nio dobrać jej poszcze­gól­ne ele­men­ty, nie zaj­mu­jąc się cało­ścią apli­ka­cji, co ma miej­sce w przy­pad­ku podej­ścia mono­li­tycz­ne­go. Tym samym cykl pro­duk­cyj­ny ule­ga skró­ce­niu, a zwią­za­ne z nim kosz­ty obni­że­niu nawet o 60 proc. Zwiększa się tak­że ela­stycz­ność oraz szyb­kość wpro­wa­dza­nia inno­wa­cji? ? tłu­ma­czy Rafał Głąb, Business Technology Unit Director, odpo­wie­dzial­ny za roz­wój Onwelo Microservices Lab, naj­więk­sze­go w Polsce cen­trum kom­pe­ten­cyj­ne­go doty­czą­ce­go mikro­usług. (Źródło: Słyszałeś o mikro­usłu­gach? Twoje ulu­bio­ne apli­ka­cje dzia­ła­ją w opar­ciu o nie! – ERP​-view​.pl – ERP, CRM, MRP, Business Intelligence, MRP)

Aplikacje budo­wa­ne w opar­ciu o tra­dy­cyj­ny mono­li­tycz­ny rela­cyj­ny model danych wyma­ga­ją zapro­jek­to­wa­nia cało­ścio­we­go mode­lu danych co jest dużym wyzwa­niem, obec­nie gra­ni­czą­cym z cudem (nie­daw­no o tym pisa­łem w Biznesowy model danych – nie chce­my).

Prawdopodobieństwo zmian pier­wot­nych (z dnia roz­po­czę­cia pro­jek­tu) wyma­gań na całość sys­te­mu”, dla pro­jek­tów trwa­ją­cych ponad rok, obec­nie gra­ni­czy z pew­no­ścią, dla­te­go po pro­stu nie sen­su tego robić.

Projekt może być reali­zo­wa­ny przy­ro­sto­wo tyl­ko pod warun­kiem, że pozwa­la na to archi­tek­tu­ra całe­go sys­te­mu, ta więc nie może mieć mono­li­tycz­nej pod­sta­wy jaką jest jeden rela­cyj­ny model danych. Implementacja (pro­ces) bazu­ją­ca na mikro­ser­wi­sach wyglą­da tak:

Takie podej­ście pozwa­la two­rzyć szyb­ciej przy mini­mal­nym ryzy­ku poja­wie­nia się potrze­by re-fak­to­rin­gu cało­ści a tak­że czy­ni apli­ka­cję łatwą do two­rze­nia w zespo­le i póź­niej­szej roz­bu­do­wy ?(Gage, 2018)?. Rosnąca popu­lar­ność tej archi­tek­tu­ry, tyl­ny­mi drzwia­mi powo­li rugu­je z ryn­ku mono­li­ty ERP, któ­re (nie­któ­re) pod­le­ga­ją re-fak­to­rin­go­wi (ich pro­du­cen­ci nie chwa­lą sie tym bo to powol­ny i bar­dzo kosz­tow­ny pro­ces). Te sys­te­my, któ­re nadal są opar­te na fun­da­men­cie jed­nej bazy danych z inte­gra­cją bazu­ją­ca na współ­dzie­le­niu danych, powo­li prze­gry­wa­ją kosz­ta­mi. Mit mono­li­tycz­ne­go zin­te­gro­wa­ne­go” sys­te­mu powo­li prze­sta­je dzia­łać na ryn­ku… powo­li… bo nadal jest żywy w ofer­tach.?(D., 2019)?

W nie­co innej for­mie, ale bar­dzo zbli­żo­nej mówi­my też o mikro apli­ka­cjach (micro­app). Pojęcie mikro­ser­wi­sów zosta­ło nie­co zawłasz­czo­ne przez dostaw­ców tech­no­lo­gii (VMWare, doke­ry, itp.), poję­ciem bliż­szym opi­sa­nej wyżej archi­tek­tu­ry jest poję­cie mikro­apli­ka­cji. Więcej o tym innym razem …

Bibliografia

  1. Arsov, K. (2017, March 17). What Are Microservices, Actually? Retrieved from DZone websi­te: https://​dzo​ne​.com/​a​r​t​i​c​l​e​s​/​w​h​a​t​-​a​r​e​-​m​i​c​r​o​s​e​r​v​i​c​e​s​-​a​c​t​u​a​lly
  2. D., A. (2019, April 18). Best Architecture for an MVP: Monolith, SOA, Microservices, or Serverless? Retrieved July 7, 2019, from RubbyGarage websi­te: https://​ruby​ga​ra​ge​.org/​b​l​o​g​/​m​o​n​o​l​i​t​h​-​s​o​a​-​m​i​c​r​o​s​e​r​v​i​c​e​s​-​s​e​r​v​e​r​l​ess
  3. Gage, J. (2018, April 23). Introduction to Microservices: What are Microservices? Use Cases and Examples. Retrieved September 5, 2019, from Algorithmia websi­te: https://​blog​.algo​ri​th​mia​.com/​i​n​t​r​o​d​u​c​t​i​o​n​-​t​o​-​m​i​c​r​o​s​e​r​v​i​c​es/
  4. Woodie, A. (2018, November 7). Modernizing IBM i Apps with Microservices. Retrieved from IT Jungle websi­te: https://​www​.itjun​gle​.com/​2​0​1​8​/​1​1​/​0​7​/​m​o​d​e​r​n​i​z​i​n​g​-​i​b​m​-​i​-​a​p​p​s​-​w​i​t​h​-​m​i​c​r​o​s​e​r​v​i​c​es/
Effective software delivery. White paper. May 2009

Krzywe i koszty… architektury

Dwa tygo­dnie temu, na kon­fe­ren­cji o jako­ści sys­te­mów IT, pre­zen­to­wa­łem mię­dzy inny­mi dwa poniż­sze wykresy:

Koszty rozwoju


Pierwszy wykres jest bar­dzo popu­lar­ny w lite­ra­tu­rze przed­mio­tu, tu jeden z wie­lu przy­kła­dów. Powołam się na nie­go później.

Effective software delivery. White paper. May 2009

Drugi jest wyni­kiem moich stu­diów lite­ra­tu­ry , wła­snych badan i doświad­cze­nia i wła­śnie o nim nie­co wię­cej. Wyjaśnię jak powstał.

W zasa­dzie wystar­czy uznać, że jeże­li speł­nie­nie zasa­dy „[[open clo­sed prin­ci­ple in object orien­ted softwa­re]]” (archi­tek­tu­ra sys­te­mu jest otwar­ta na roz­sze­rze­nia i zamknię­ta na zmia­ny) jest moż­li­we, to kod tak zbu­do­wa­nej apli­ka­cji rośnie” linio­wo, a koszt roz­wo­ju podob­nie. Początkowy koszt, to koszt opra­co­wa­nia szkie­le­tu (zwa­ne­go [[core doma­in]]). To wła­śnie – w apli­ka­cjach kon­stru­owa­nych zgod­nie z [[zasa­da­mi SOLID]] – powo­du­je, że koszt począt­ko­wy jest rela­tyw­nie wyż­szy niż koszt archi­tek­tu­ry budo­wa­nej ad-hoc” (ozna­czo­nej ???).

Nie mam ambi­cji two­rze­nia przy­kła­du brzyd­kiej archi­tek­tu­ry”, chy­ba już nie umiem 😉 dla­te­go poni­żej tyl­ko struk­tu­ra apli­ka­cji (archi­tek­tu­ra kom­po­nen­tu Model/MVC) w obiek­to­wym para­dyg­ma­cie (apli­ka­cja to współ­pra­cu­ją­ce obiek­ty) zgod­na z SOLID:

Obiektowy model dziedziny Zasada SOLID
Przykład archi­tek­tu­ry na bazie wzor­ca BCE (BCCE)

Model ten powstał z uży­ciem blo­ków funk­cjo­nal­nych wzor­ca BCE (opi­sa­łem go tu: Wzorzec ana­li­tycz­ny Boundary Control Entity). Dla wyja­śnie­nia: powyż­szy dia­gram to w peł­ni popraw­ny Model dzie­dzi­ny wyko­na­ny z uży­ciem dia­gra­mu klas UML, kla­sy mają ste­reo­ty­py boun­da­ry, con­trol i enti­ty (powy­żej od lewej do pra­wej), ste­reo­ty­py te są repre­zen­to­wa­ne sym­bo­la­mi opi­sa­ny­mi (iko­na­mi) w BCE. Kilka cech tej architektury:

  1. każ­dy przy­pa­dek uży­cia ma dedy­ko­wa­ną kla­sę (ta połą­czo­na z akto­rem) odpo­wie­dzial­ną za jego inter­fejs i sce­na­riusz (ale nie logi­kę biznesową!),
  2. sce­na­riusz przy­pad­ku uży­cia to recep­ta” na to, kie­dy i cze­go wewnątrz apli­ka­cji nale­ży użyć do reali­za­cji celu użytkownika,
  3. to co potra­fi” apli­ka­cja to usłu­gi wewnętrz­ne (logi­ka biznesowa),
  4. to co apli­ka­cja musi wie­dzieć” zapa­mię­ta­ło się (jest prze­cho­wy­wa­ne) w repozytoriach,
  5. żad­ne infor­ma­cje nie są, logicz­nie ani w szcze­gól­no­ści fizycz­nie, współ­dzie­lo­ne: każ­de repo­zy­to­rium, powy­żej są trzy, jest w 100% her­me­ty­zo­wa­ne (imple­men­ta­cja repo­zy­to­riów to abso­lut­nie! nie jest jed­na współ­dzie­lo­na rela­cyj­na baza danych i mapo­wa­nie ORM!).

Widać (mam nadzie­ję na tym dość pro­stym sche­ma­cie), że każ­dy przy­pa­dek uży­cia to odręb­ny ser­wis”, prak­tycz­nie nie­za­leż­na usłu­ga (u Fowlera nazy­wa­ne mikro­ser­wi­sa­mi). Są od sie­bie cał­ko­wi­cie odse­pa­ro­wa­ne, co naj­wy­żej korzy­sta­ją z tych samych spe­cja­li­zo­wa­nych usług wewnętrz­nych (np. z gene­ra­to­ra pli­ków PDF będzie korzy­sta­ła każ­da usłu­ga ope­ru­ją­ca na doku­men­tach do dru­ku). Dodanie kolej­ne­go przy­pad­ku uży­cia w ogó­le nie wpły­wa na resz­tę apli­ka­cji (zale­ta her­me­ty­za­cji), ewen­tu­al­ne redun­dan­cje są raczej zba­wie­niem niż wadą, gdyż każ­da usłu­ga ma swój kon­tekst i wła­sny cykl życia, i jakie­kol­wiek współ­dzie­le­nie tre­ści (nie mylić z wyko­rzy­sta­niem tych samych) raczej zmu­si do (zgni­łe­go) kompromisu.

Współdzielenie danych naj­czę­ściej przy­no­si szko­dy, np. współ­dzie­le­nie listy pro­duk­tów pomię­dzy zamó­wie­niem i fak­tu­rą powo­du­je zależ­ność unie­moż­li­wia­ją­cą wysta­wie­nie fak­tu­ry na pro­duk­ty inne (w innej ilo­ści) niż na tym zamó­wie­nia (nie takie rzad­kie zja­wi­sko w dostęp­nych na ryn­ku sys­te­mach ERP). Utworzenie fak­tu­ry poprzez sko­pio­wa­nie (wyko­rzy­sta­nie) zawar­to­ści Zamówienia, pozwa­la na jej (fak­tu­ry) dowol­ną mody­fi­ka­cję bez potrze­by zmia­ny Zamówienia (żąda­nia powtór­ne­go jego przy­sła­nia lub o zgro­zo, wewnętrz­nej korek­ty!). Współdzielenie danych firm pomię­dzy np. fak­tu­ra­mi i reje­strem kon­tra­hen­tów, skut­ku­je pro­ble­mem gdy aktu­ali­za­cja adre­su kon­tra­hen­ta prze­no­si się na histo­rycz­ne fak­tu­ry. Owszem może nam się przy­tra­fić koszt nowej usłu­gi wewnętrz­nej, ale zro­bi­my to bez jakiej­kol­wiek inge­ren­cji w dotych­cza­so­wą logi­kę (i kod).

Aplikacje, któ­rych archi­tek­tu­ra wewnętrz­na bazu­je na współ­dzie­lo­nych danych, rela­cyj­nej jed­nej bazie danych (jeden spój­ny sys­tem tablic rela­cyj­nej bazy danych pod” apli­ka­cją), gęstej sie­ci wewnętrz­nych zależ­no­ści, wyma­ga­ją – dla doda­nia nowej usłu­gi lub zmia­ny ist­nie­ją­cej – pra­wie zawsze czę­ścio­we­go lub cał­ko­wi­te­go re-fak­to­rin­gu, a w skraj­nych przy­pad­kach nawet migra­cji danych do nowej ich struk­tu­ry. W efek­cie, to co użyt­kow­nik postrze­ga jako roz­sze­rze­nie, dla dewe­lo­pe­ra sta­no­wi pra­co­chłon­ny refak­to­ring, tym bar­dziej pra­co­chłon­ny im więk­sza ta apli­ka­cja. Z tego powo­du kosz­ty wpro­wa­dza­nia zmian do tak stwo­rzo­nej apli­ka­cji są tym więk­sze im więk­sza i zło­żo­na jest ta apli­ka­cja (czer­wo­na linia na wykre­sie kosz­tu roz­sze­rze­nia funkcjonalności).

Pisanie opro­gra­mo­wa­nia ad-hoc, bez prze­my­śla­nej logi­ki i archi­tek­tu­ry cało­ści, pro­wa­dzi do powsta­wa­nia tak zwa­ne­go „[[dłu­gu archi­tek­to­nicz­ne­go]]” (ana­lo­gicz­nie do [[dług tech­no­lo­gicz­ny]]). To dla­te­go bar­dzo czę­sto źle poj­mo­wa­ne agi­le” pozwa­la bar­dzo szyb­ko uzy­skać pierw­sze efek­ty, nie­ste­ty oku­pio­ne bar­dzo kosz­tow­nym póź­niej­szym utrzy­ma­niem i roz­wo­jem takiej apli­ka­cji. Chyba, że pro­dukt taki potrak­to­wa­ny zosta­nie jako efe­me­ry­da albo jako pro­to­typ odrzucany.

Niestety wie­le sys­te­mów ERP i i nie tyl­ko, powsta­ło w latach 90’tych, mają one nie­ste­ty scen­tra­li­zo­wa­ną archi­tek­tu­rę struk­tu­ral­ną (jed­na baza danych i nad nią” funk­cje prze­twa­rza­ją­ce te dane). Efekty tego widać przy wdro­że­niach, w któ­rych dopusz­czo­no tak zwa­ną kasto­mi­za­cje sys­te­mu, czy­li wła­śnie wpro­wa­dza­nie, nie raz bar­dzo wie­lu, zmian. To bar­dzo kosz­tow­ne pro­jek­ty o prak­tycz­nie nie­prze­wi­dy­wal­nym budże­cie. Niestety współ­dzie­le­nie danych wewnątrz takie­go sys­te­mu jest jego poważ­ną wadą a nie – jak to zachwa­la­ją ich dostaw­cy – zaletą…

Wzorzec CRUD dla przypadków użycia i mikroserwisy

Regularnie spo­ty­kam się z mon­stru­al­ny­mi spe­cy­fi­ka­cja­mi: naj­pierw wyma­gań” a potem przy­pad­ków uży­cia”: dzie­siąt­ki, set­ki (o ich ilo­ści napi­sa­łem tu). Na ich pod­sta­wie powsta­ją wyce­ny – nie mniej kosmicz­ne. Jednak jeże­li zesta­wić to z bada­nia­mi pro­jek­tów i oce­ną, że jed­ną z klu­czo­wych przy­czyn pora­żek jest nad­mier­na zło­żo­ność i nie­jed­no­znacz­ność spe­cy­fi­ka­cji wyma­gań, a potem same­go pro­jek­tu i jego zakre­su oraz utra­ta pano­wa­nia nad tym zakre­sem, to może war­to się nad tym pochylić?

Kluczem jest defi­ni­cja wyma­ga­nia i czę­sto są nimi wła­śnie przy­pad­ki uży­cia. Pojęcie przy­pad­ku uży­cia (UML) i usłu­gi (SoaML):

Przypadek uży­cia (UML, Superstructure v.2.4.1.): A use case is the spe­ci­fi­ca­tion of a set of actions per­for­med by a sys­tem, which yields an obse­rva­ble result that is, typi­cal­ly, of value for one or more actors or other sta­ke­hol­ders of the sys­tem.

Usługa (SoaML, v.1.0.1.): Service is defi­ned as the deli­ve­ry of value to ano­ther par­ty, ena­bled by one or more capa­bi­li­ties. Here, the access to the servi­ce is pro­vi­ded using a pre­scri­bed con­tract and is exer­ci­sed con­si­stent with con­stra­ints and poli­cies as spe­ci­fied by the servi­ce contract.

Tak więc przy­pa­dek uży­cia jako efekt daje okre­ślo­ny, war­to­ścio­wy rezul­tat. Warto teraz w tym miej­scu pod­kre­ślić, że SOA (patrz spe­cy­fi­ka­cja) zakła­da, że usłu­ga jako efekt (pro­dukt) daje Real World Effect defi­ned as servi­ce ope­ra­tion post con­di­tion” co jest o tyle istot­ne, że ana­lo­gicz­nie koń­czy się przy­pa­dek uży­cia (przy­po­mnę, że post con­di­tion” to sta­bil­ny stan sys­te­mu po wyko­na­niu operacji).

Popatrzmy teraz na poję­cie czyn­no­ści w BPMN:

Aktywność a czyn­ność: (BPMN, v.2.0) An Activity is work that is per­for­med within a Business Process. An Activity can be ato­mic or non-ato­mic (com­po­und). The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity, which allows the inc­lu­sion of re-usa­ble Tasks and Processes in the dia­gram. However, a Process is not a spe­ci­fic gra­phi­cal object. Instead, it is a set of gra­phi­cal objects. The fol­lo­wing sec­tions will focus on the gra­phi­cal objects Sub-Process and Task. […] A Task is an ato­mic Activity within a Process flow. A Task is used when the work in the Process can­not be bro­ken down to a finer level of detail.

Tu zaczy­na się prag­ma­ty­ka biz­ne­so­wa, czy­li defi­ni­cja poję­cia pro­ces biz­ne­so­wy, któ­ra zakła­da, że pro­ces biz­ne­so­wy (tak­że ele­men­tar­ny, ato­mo­wy) to czyn­ność lub łań­cuch logicz­nie powią­za­nych czyn­no­ści (aktyw­ność), two­rzy pro­dukt mają­cy war­tość dla odbior­cy tego pro­duk­tu (pro­dukt musi się nada­wać do biz­ne­so­we­go wyko­rzy­sta­nia). Ta defi­ni­cja jest nie­mal­że kopia defi­ni­cji przy­pad­ku uży­cia. Procesem biz­ne­so­wym jest KAŻDA aktyw­ność wraz z jej samo­dziel­nie przy­dat­nym biz­ne­so­wo pro­duk­tem (para aktyw­ność i jej pro­dukt, dla­te­go w BPMN nie ma jed­nej iko­ny na pro­ces biz­ne­so­wy”). Jak widać, te trzy poję­cia: przy­pa­dek uży­cia apli­ka­cji, usłu­ga apli­ka­cji oraz ele­men­tar­ny pro­ces biz­ne­so­wy (pod­kre­ślam, że pro­jek­ty IT dla biz­ne­su mają biz­ne­so­wy kon­tekst co nada­je ści­ślej­sze zna­cze­nia tym trzem poję­ciom), mają nie­mal­że toż­sa­me defi­ni­cje (zresz­tą OMG dąży w tym wła­śnie kie­run­ku). Popatrzmy tu:

The majo­ri­ty of today­’s SOA design tech­ni­qu­es 1,2,3 are cen­te­red aro­und defi­ni­tion of servi­ces. They use 1se­rvi­ce-orien­ted decom­po­si­tion, based on the busi­ness pro­ces­ses, enter­pri­se business/functional model, requ­ired long term archi­tec­tu­ral goals and reu­se of the exi­sting enter­pri­se func­tio­na­li­ty. (Incorporating Enterprise Data into SOA).

Kluczem jest suge­stia (uzna­nie), że ele­men­tar­nym poję­ciem do dekom­po­zy­cji funk­cjo­nal­nej jest poję­cie ele­men­tar­nej (ato­mo­wej) usłu­gi (i nie jest nią jed­na linia pro­gra­mu!) będą­cej tak­że ele­men­tar­nym pro­ce­sem biz­ne­so­wym. Popatrzmy na dia­gram obra­zu­ją­cy archi­tek­tu­rę SOA (pocho­dzą­cy z tego same­go artykułu):

SOA implemetation

Mamy tu, mię­dzy inny­mi, trzy waż­ne war­stwy (tu dru­gą, trze­cią i czwar­tą od góry), są to odpo­wied­nio: pro­ce­sy biz­ne­so­we, usłu­gi apli­ka­cyj­ne (ta war­stwa to abs­trak­cja) oraz apli­ka­cje świad­czą­ce te usłu­gi. Mamy więc mapo­wa­nie ele­men­tar­nych ato­mo­wych pro­ce­sów (poje­dyn­czych czyn­no­ści) na ele­men­tar­ne usłu­gi apli­ka­cyj­ne. Usługi te, to nic inne­go jak przy­pad­ki uży­cia apli­ka­cji, czy­li każ­dą apli­ka­cję (jej uży­tecz­ność) moż­na opi­sać z pomo­cą jej przy­pad­ków uży­cia”, a te jak już wie­my, w UML słu­żą – jak widać słusz­nie – do spe­cy­fi­ko­wa­nia wyma­gań funk­cjo­nal­nych. Tu uwa­ga, nie nale­ży tego mylić ze spo­ty­ka­ny­mi w lite­ra­tu­rze biz­ne­so­wy­mi przy­pad­ka­mi uży­cia” (nie ma taki w UML).

Konwencja biz­ne­so­wych przy­pad­ków uży­cia to relikt meto­dy RUP z lat 90’tych, kie­dy to nie było np. nota­cji BPMN, i tak zwa­ny biz­ne­so­wy dia­gram przy­pad­ków uży­cia” opi­sy­wał fir­mę, jej usłu­gi i klien­tów (akto­rów), a nie apli­ka­cję (do dzi­siaj jest to przy­czy­ną wie­lu nie­po­ro­zu­mień i powsta­wa­nia niskiej jako­ści nie­jed­no­znacz­nych dokumentacji). 

Tak więc, jak widać, moż­na uznać (przy­jąć), że przy­pa­dek uży­cia to usłu­ga apli­ka­cji, a ich gra­da­cję okre­śla pro­dukt jako uży­tecz­ność efek­tu. Co cie­ka­we, nie­któ­re narzę­dzia CASE wspie­ra­ją (uła­twia­ją) two­rze­nie (mapo­wa­nie) czyn­no­ści (ele­men­tar­nych pro­ce­sów biz­ne­so­wych) w pro­ce­sach (nota­cja BPMN) na przy­pad­ki uży­cia (nota­cja UML).

Taksonomia wyma­gań, w tym biz­ne­so­we i przy­pad­ki uży­cia oraz usłu­gi apli­ka­cyj­ne (Produkty w pro­ce­sie ana­li­zy wyma­gań):

Wymagania

Warto tu teraz zwró­cić uwa­gę, że wyma­ga­nia funk­cjo­nal­ne i poza-funk­cjo­nal­ne, jako­ścio­we i dzie­dzi­no­we oraz usłu­gi sys­te­mu to ele­men­ty abstrakcyjne.

Tak na praw­dę rze­czy­wi­ste są jedy­nie wyma­ga­nia biz­ne­so­we jako ocze­ki­wa­nia zama­wia­ją­ce­go wyra­żo­ne w jego języ­ku, oraz przy­pad­ki uży­cia i model dzie­dzi­ny, bo opi­su­ją rze­czy­wi­sty byt jakim jest (przy­szły) pro­dukt (apli­ka­cja).

CRUD, czym jest?

CRUD to skrót od ang. Create, Retrieve, Update, Delete (Utwórz, Przywołaj, Zaktualizuj, Usuń). Są to czte­ry pod­sta­wo­we ope­ra­cje na tak zwa­nych kar­to­te­kach, obiek­tach słu­żą­cych do zapa­mię­ty­wa­nia infor­ma­cji czy­li poje­dyn­czych encji” (nie mylić z encja­mi w bazach rela­cyj­nych) lub ich agre­ga­tach. Obiektami odpo­wie­dzial­nym za ich prze­cho­wy­wa­nie są repo­zy­to­ria (Repository). Kluczowe czte­ry ope­ra­cje udo­stęp­nia­ne przez repo­zy­to­rium to wła­śnie CRUD. Pytanie brzmi: czym jest kar­to­te­ka? Jest zbio­rem kart (doku­men­tów) o jed­na­ko­wej (lub podob­nej) struk­tu­rze. Tak więc usłu­gą jest zarzą­dza­nie kar­ta­mi”, czy też odręb­ny­mi usłu­ga­mi są two­rze­nie kar­ty, czy­ta­nie, uzu­peł­nie­nie, usu­nię­cie? Popatrzmy na to z per­spek­ty­wy usłu­gi dla użyt­kow­ni­ka: ma sens posia­da­nie wygod­nej szu­fla­dy z kar­ta­mi w biblio­te­ce ale czy ma sens samo­dziel­na, wyję­ta z kon­tek­stu usłu­ga two­rze­nie nowych kart”? Można pole­mi­zo­wać, ale jeże­li chcieć utrzy­mać spój­ność poję­cio­wą i moż­li­wość kon­tro­li spój­no­ści i kom­plet­no­ści pro­jek­tu i jego zakre­su, lepiej uznać, że usłu­gą apli­ka­cyj­ną jest zarzą­dza­nie kar­ta­mi”. Po pierw­sze taka usłu­ga jest samo­wy­star­czal­na, zaś samo two­rze­nie kar­ty bez moż­li­wo­ści jej przy­wo­ła­nia nie ma sen­su, więc te czte­ry pro­ste czyn­no­ści są nie­ja­ko nie­ro­ze­rwal­nie zwią­za­ne, sta­no­wiąc jed­ną usłu­gę. Po dru­gie two­rze­nie nowe­go zapi­su, mody­fi­ko­wa­nie czy usu­wa­nie, to kon­tekst użyt­kow­ni­ka, w zasa­dzie każ­dą z czte­rech ope­ra­cji CRUD moż­na spro­wa­dzić do scenariusza:

  1. pokaż kar­tę (pusta to two­rze­nie nowe­go zapisu)
  2. zrób z tym coś (wpisz nowe, zmień, usuń) i potwierdź (zacho­waj skutek)

Dlatego są pod­sta­wy by uznać, że zarzą­dza­nie kar­ta­mi kata­lo­go­wy­mi” to jed­nak jeden przy­pa­dek uży­cia, a poszcze­gól­ne ope­ra­cje, to kon­tek­sto­we warian­ty sce­na­riu­sza wyni­ka­ją­ce z pro­ce­su czy­li chwi­lo­we­go celu użyt­kow­ni­ka (akto­ra). To podob­nie jak mło­tek (usłu­ga dostęp­na ze skrzyn­ki narzę­dzio­wej), to czło­wiek uży­wa młot­ka w kon­tek­ście wbi­ja­nie gwoź­dzia, zbi­ja­nia szy­by, roz­bi­ja­nia kamie­ni. Młotek w rękach czło­wie­ka po pro­stu słu­ży do ude­rza­nia, więc przy­pad­kiem uży­cia jest ude­rza­nie a nie czyn­ność w pro­ce­sie zbi­ja­nia budy dla psa jaką jest wbi­ja­nie gwoź­dzi w deski. Podejście takie wca­le nie jest nowe, w cie­ka­wy spo­sób opi­sał to autor tego artykułu:

If you have ever been wri­ting use cases for a data-orien­ted sys­tem (i.e. CMS), you have pro­ba­bly noti­ced that the­re is a pro­blem with the lar­ge num­ber of use cases like Add an artic­le”, Remove an artic­le” etc. If you have all CRUD ope­ra­tions ava­ila­ble for all objects in the sys­tem, you can finish with up to 4 x num­ber-of-objects of use cases. You can redu­ce this num­ber by intro­du­cing the CRUD pat­tern, which I would like to pre­sent you in this blog entry. (CRUD Pattern in Use Cases ? PUT Software Engineering Team).

Można takie podej­ście (wyni­ka­ją­ce nie­ja­ko wprost z defi­ni­cji przy­to­czo­nych pojęć), jak widać, nazwać wzor­cem pro­jek­to­wym :). Bardzo ład­nie prze­kła­da się to na archi­tek­tu­rę (model opar­ty o wzo­rzec BCE), ope­ru­ją­cą poję­cia­mi boun­da­ry (gra­ni­ca), con­troll ( ste­ro­wa­nie) i enti­ty (nośnik informacji):

Wzorzec BCE

Na powyż­szym dia­gra­mie mamy dwa przy­pad­ki uży­cia: gór­ny to typo­wy CRUD, dol­ny do usłu­ga, np. obli­cze­nio­wa. Przypadek pierw­szy (gór­ny) dodat­ko­wo korzy­sta z logi­ki Samodzielna logi­ka” tego dru­gie­go PU (inte­gra­cja dwóch aplikacji/komponentów).

Poniżej dwa cie­ka­we arty­ku­ły, roz­wi­ja­ją­ce powyż­sze. Pierwszy to tak zwa­ne mikro ser­wi­sy, wzo­rzec trak­tu­ją­cy każ­dą usłu­gę apli­ka­cyj­ną 9a tym samym przy­pa­dek uży­cia) jako odręb­ną apli­ka­cję, dru­gi poka­zu­je jak pro­jek­to­wać inter­fej­sy w takich przypadkach.

Microservices” – yet ano­ther new term on the crow­ded stre­ets of softwa­re archi­tec­tu­re. Although our natu­ral inc­li­na­tion is to pass such things by with a con­temp­tu­ous glan­ce, this bit of ter­mi­no­lo­gy descri­bes a sty­le of softwa­re sys­tems that we are fin­ding more and more appe­aling. We’ve seen many pro­jects use this sty­le in the last few years, and results so far have been posi­ti­ve, so much so that for many of our col­le­agu­es this is beco­ming the default sty­le for buil­ding enter­pri­se appli­ca­tions. Sadly, howe­ver, the­re­’s not much infor­ma­tion that outli­nes what the micro­se­rvi­ce sty­le is and how to do it. (Microservices).

Tell-Don’t-Ask is a prin­ci­ple that helps people remem­ber that object-orien­ta­tion is abo­ut bun­dling data with the func­tions that ope­ra­te on that data. It reminds us that rather than asking an object for data and acting on that data, we sho­uld inste­ad tell an object what to do. This enco­ura­ges to move beha­vior into an object to go with the data. (TellDontAsk).

Na zakończenie

Analizy biz­ne­so­we wyma­ga­ją ode­rwa­nia się od tech­no­kra­cji, nie ma cze­goś takie­go jak dzie­siąt­ki przy­pad­ków uży­cia dla jed­nej fak­tu­ry, nie ma sys­te­mo­wych przy­pad­ków uży­cia (nawet w spe­cy­fi­ka­cji UML ich nie znaj­dzie­cie), są kom­plet­ne (dają­ce jako efekt przy­dat­ne pro­duk­ty) usłu­gi apli­ka­cyj­ne i korzy­sta­ją­cy z tych usług akto­rzy, w tym inne apli­ka­cje lub kom­po­nen­ty. Dokumentacje zawie­ra­ją­ce set­ki przy­pad­ków uży­cia to nie­po­ro­zu­mie­nie, tech­no­kra­tycz­ni zabój­cy pro­jek­tów. Warto się zasta­no­wić zanim powie­rzy­cie ana­li­zę i pro­jekt logi­ki sys­te­mu tech­no­kra­tycz­ne­mu deve­lo­pe­ro­wi… Zapraszam do lek­tu­ry kolej­ne­go arty­ku­łu o zarzą­dza­niu szcze­gó­ło­wo­ścią ana­li­zy..