Wstęp

Napisałem o orien­ta­cji na doku­men­ty w toku analiz:

Często jestem i ja pyta­ny o to ??Jak wyja­śnić zło­żo­ne roz­wią­za­nie tech­nicz­ne inte­re­sa­riu­szom nie­tech­nicz­nym?? Jak wie­lu mi podob­nych odpo­wia­dam: roz­ma­wiaj doku­men­ta­mi. Sponsor pro­jek­tu, przy­szli użyt­kow­ni­cy, postrze­ga­ją swo­ją pra­cę poprzez doku­men­ty: ich treść i układ. (Wymagania na for­mu­la­rze czy­li dia­gra­my struk­tur zło­żo­nych i XML)

Dzisiaj pój­dzie­my dalej, omó­wi­my to gdzie i jak zacho­wać tę infor­ma­cję. Posłużę się pro­stym przy­kła­dem przy­chod­ni wete­ry­na­ryj­nej. Artykuł będzie opi­sem meto­dy podej­ścia do ana­li­zy zorien­to­wa­nej na pro­ce­sy i dokumenty. 

Tekst ma dwie czę­ści: pierw­sza jest opi­sem dro­gi jaka pro­wa­dzi nas do zde­fi­nio­wa­nia tego jakie doku­men­ty, jaką mają (mieć) zawar­tość i struk­tu­rę. Praktycznie jest to opis ana­li­zy i pro­jek­to­wa­nia. Druga – krót­ka – to przy­kła­do­wa archi­tek­tu­ra logi­ki reali­za­cji apli­ka­cji, poka­zu­ją­ca miej­sce doku­men­to­wej bazy danych w archi­tek­tu­rze i pro­jek­cie, czy­li tak­że projektowanie. 

Celem tego wpi­su jest poka­za­nie czym może być ana­li­za oraz jej pro­dukt jakim jest Techniczny Projekt Oprogramowania.

Przychodnia weterynarzy – analiza

Mam nadzie­ję, że to jak dzia­ła przy­chod­nia wete­ry­na­ryj­na (Przychodnia), czy­tel­nik jest w sta­nie sobie wyobra­zić. Jeżeli nie, pole­cam lek­tu­rę regu­la­mi­nu jakiej­kol­wiek tego typu przy­chod­ni, np. ten Regulamin. Ale od razu zazna­czam, że w przy­pad­ku real­ne­go pro­jek­tu nale­ży od tego zacząć. Wywiady z pra­cow­ni­ka­mi nie mają więk­sze­go sen­su, czę­sto wpro­wa­dza­ją w błąd. Analizę nale­ży zacząć od ana­li­zy fak­tów czy­li od zebra­nia par­tii przy­kła­do­wych kart wizyt, regu­la­mi­nów i zarzą­dzeń, moż­li­we, że jest pra­wo regu­lu­ją­ce tego typu usłu­gi (a tu jest, parz USTAWA z dnia 18 grud­nia 2003 r. o zakła­dach lecz­ni­czych dla zwie­rząt) .

Model pro­ce­su opi­su­ją­ce­go pod­sta­wo­wą dzia­łal­ność przy­chod­ni wyglą­da tak:

Zgłoszenie się pacjen­ta powo­du­je wysta­wie­nie Karty Wizyty, któ­ra jako pla­no­wa­na wizy­ta w przy­szło­ści, sta­no­wi sobą rezer­wa­cję ter­mi­nu. Od tego momen­tu ​„zegar tyka”. 

Jeżeli w Przychodni poja­wi się Opiekun zwie­rzę­cia, reali­zo­wa­na jest stan­dar­do­wa pora­da wete­ry­na­ryj­na. Jeżeli ktoś zgło­si odwo­ła­nie wizy­ty zosta­nie ona odwo­ła­na (ale jako doku­ment Karta Wizyty pozo­sta­nie w sys­te­mie ze sta­tu­sem «odwo­ła­na»).

Zwracam uwa­gę, że zmia­na ter­mi­nu wizy­ty to odwo­ła­nie pla­no­wa­nej wizy­ty i nowa rezer­wa­cja (takie podej­ście zna­ko­mi­cie uprasz­cza cały sys­tem, a dodat­ko­wo zysku­je­my dane do ewen­tu­al­nych sta­ty­styk rze­tel­no­ści klientów). 

Zapewne więk­szość biz­ne­su (pra­ca na user sto­ry, wywia­dy itp.) będzie ocze­ki­wa­ła moż­li­wo­ści edy­to­wa­nia Kart Wizyt i jest to wła­snie naj­gor­sze roz­wią­za­nie. To dla­te­go nie słu­cham pomy­słów klien­tów na sys­tem, ocze­ku­ję wyłącz­nie opi­su celu danej aktyw­no­ści, a ta brzmi (powin­na) raczej ​„chciał bym mieć moż­li­wość prze­ło­że­nia wizy­ty”, a nie ​„chce mieć moż­li­wość edy­cji pola «ter­min wizy­ty» ”. Jeżeli ter­min wizy­ty nadej­dzie a opie­kun sie nie poja­wi, wizy­ta zosta­nie ozna­czo­na sta­tu­sem «zigno­ro­wa­na».

Z uwa­gi na to, że nie umiesz­cza­my na ana­li­tycz­nych mode­lach pro­ce­sów biz­ne­so­wych, opi­sów wypeł­nia­nia for­mu­la­rzy czy deta­licz­nych pro­ce­dur, koniecz­ny jest sza­blon doku­men­tu sko­ja­rzo­ny z ele­men­tem Karta Wizyty (BPMN: DataObject). Jak już wspo­mi­na­łem w innym arty­ku­le, moż­na do tego celu zasto­so­wać nota­cję UML i dia­gram struk­tur zło­żo­nych (a dla użyt­kow­ni­ków opro­gra­mo­wa­nia CASE jest to rekomendacja):

Taka for­ma doku­men­to­wa­nia ma dwie pod­sta­wo­we zale­ty: jest zro­zu­mia­ła dla zama­wia­ją­ce­go oraz sta­no­wi popraw­ny dia­gram klas, uży­tecz­ny na dal­szych eta­pach ana­li­zy i projektowania. 

Powyższy for­mu­larz jest tak­że naj­lep­szym miej­scem do poka­zy­wa­nia i reali­za­cji wyma­gań biz­ne­so­wych. Np. wyma­ga­nie ​„System powi­nien pozwa­lać na gene­ro­wa­nie sta­tyk rze­tel­no­ści klien­tów” skut­ku­je polem sta­tus oraz słow­ni­kiem (w dal­szej czę­ści) war­to­ści tego pola (będzie zawie­rał mię­dzy inny­mi war­tość «zigno­ro­wa­na»). Tu waż­na informacja: 

to ana­li­tyk pro­jek­tant, a nie deve­lo­per, ma zagwa­ran­to­wać (jeże­li pla­no­wa­ne jest opro­gra­mo­wa­nie dedy­ko­wa­ne) reali­za­cję wyma­gań funkcjonalnych!

Powyższy for­mu­larz Karta Wizyty na ​„tra­dy­cyj­nym” dia­gra­mie klas, wzbo­ga­co­nym o typy danych wyglą­da tak:

Tu jest miej­sce na defi­nio­wa­nie typów zawar­to­ści atry­bu­tów. Osobiście jestem gorą­cym zwo­len­ni­kiem sto­so­wa­nia atry­bu­tów «string» (tekst ASCII) i defi­nio­wa­nia struk­tur typów zło­żo­nych, co daje cał­ko­wi­tą nie­za­leż­ność od plat­for­my imple­men­ta­cji i jed­no­cze­śnie 100% pano­wa­nie nad logi­ką reali­zo­wa­ną w apli­ka­cji. Atrybut «sta­tus» opi­su­je­my mode­lem maszy­ny sta­no­wej UML:

Logikę biz­ne­so­wą defi­niu­je­my jako regu­ły biz­ne­so­we, np.:

zestaw danych «data wizy­ty», «slot cza­so­wy», «wete­ry­narz» i «gabi­net», musi być unikalny

(moż­na też taki zestaw nazwać i mode­lo­wać jako samo­dziel­ny typ struk­tu­ral­ny, co pew­nie było by bar­dziej ele­ganc­kie). Generalnie wszyst­kie nazwy doku­men­tów, atry­bu­tów i ich war­to­ści, powin­ny być zebra­ne w jed­no­li­tym słow­ni­ku pojęć. Bazując na tych (słow­ni­ko­wych) poję­ciach budu­je­my regu­ły biz­ne­so­we jak wyżej (patrz: SBVR). Dzięki temu cała logi­ka jest kom­plet­na, spój­na, nie­sprzecz­na. Słownik poję­cio­wy dobrze jest opra­co­wać (przy naj­mniej jego klu­czo­wą część) jako model, co pozwo­li testo­wać go na oko­licz­ność spój­no­ści i niesprzeczności:

Tu waż­na uwa­ga: to (powyż­szy dia­gram) nie jest żaden model dzie­dzi­ny sys­te­mu! To ​„name­spa­ce” (prze­strzeń poję­cio­wa) wyra­żo­na jako tak­so­no­mie pojęć. Służy ona to defi­nio­wa­nia nazw atry­bu­tów i ich war­to­ści na mode­lach struk­tur doku­men­tów. Np. «zwie­rze domo­we» to atry­but Karty Wizyty, a jego spe­cja­li­za­cje to mate­riał na słow­nik war­to­ści tego atry­bu­tu: tu poten­cjal­nie mamy dwa atry­bu­ty: «gatu­nek» i «waga» (patrz dia­gram Struktura Karty Wizyty i typów atry­bu­tów), spe­cja­li­za­cje tych pojęć to mate­riał na war­to­ści tych atry­bu­tów. Model poję­cio­wy to ele­ment mode­lu CIM. Jest to naj­waż­niej­szy etap pro­jek­tu. Z zasa­dy jest to pierw­szy etap, tu wspo­mi­nam o nim dopie­ro teraz, by poka­zać źró­dło nazw atry­bu­tów i ich war­to­ści .

Jak bez­piecz­nie reali­zo­wać zmia­nę ter­mi­nu lub anu­lo­wa­nie wizy­ty? Procedura anu­lo­wa­nia wizyty:

Nie chce­my np. przez tele­fon żądać danych oso­bo­wych, w samym gabi­ne­cie żądać dowo­dów toż­sa­mo­ści. Sprawdzonym roz­wią­za­niem jest sto­so­wa­nie dłu­gie­go loso­we­go uni­kal­ne­go nume­ru Karty Wizyty (atry­but «numer wizy­ty»). Dzięki temu sta­je się on nie­ja­ko hasłem/kodem, któ­re zna wyłącz­nie Przychodnia i Opiekun (dowia­du­je się o nim w momen­cie rezerwacji).

Zakres projektu i projekt

Przypadki uży­cia to usłu­gi apli­ka­cji, nie są to ani pro­ce­sy ani aktyw­no­ści! Dlatego tu dia­gram ten wyglą­da tak:

Jak widać, są tu trzy przy­pad­ki uży­cia, ten arty­kuł jest, z racji obję­to­ści, frag­men­tem więk­szej cało­ści. Generalnie przy­pad­ki uży­cia, jako usłu­gi apli­ka­cji, ofe­ru­ją wspar­cie dla akto­ra np. pra­cow­nik recep­cji (zna­ją­cy pro­ce­du­ry) korzy­sta z usłu­gi (opcja menu apli­ka­cji) Karty Wizyt. Wszystkie aktyw­no­ści w opi­sa­nym pro­ce­sie są reali­zo­wa­ne z uży­ciem tej samej usłu­gi aplikacji!

Przypadki uży­cia doku­men­tu­je­my z pomo­cą sce­na­riu­szy. Kolejna reko­men­da­cja: zamiast roz­bu­do­wa­nych sce­na­riu­szy z alter­na­tyw­ny­mi kro­ka­mi, znacz­nie lep­szym roz­wią­za­nie jest budo­wa­nie pro­stych sce­na­riu­szy alterntywnych:

zaś dru­gi scenariusz:

Dzięki temu sce­na­riu­sze są łatwe do zro­zu­mie­nia i imple­men­ta­cji, łatwe do zmian w przy­szło­ści (nie są od sie­bie zależ­ne). W sce­na­riu­szach nale­ży uży­wać nazw z dia­gra­mów (nazwy akto­rów, for­mu­la­rzy i ich atry­bu­tów) i słow­ni­ka (patrz tak­że Dokumentowanie Przypadków Użycia)

Ostatecznie archi­tek­tu­ra reali­za­cji tej usłu­gi, jako model dzie­dzi­ny (kom­po­nent Model we wzor­cu MVC) ma postać (wyko­rzy­sta­no wzo­rzec pro­jek­to­wy BCE, moż­na użyć tak­że DDD, ):

Jest to archi­tek­tu­ra reali­za­cji poje­dyn­czej usłu­gi apli­ka­cyj­nej (przy­pad­ku uży­cia). Była na tym blo­gu nie raz opi­sy­wa­na (np. https://it-consulting.pl//2019/10/22/generator-ofert-komentarze/).

I teraz naj­waż­niej­sze: repo­zy­to­rium Karty Wizyt to wła­śnie doku­men­to­wa baza danych. Cała Karta Wizyty jest war­to­ścią jed­ne­go atry­bu­tu «kar­ta wizy­ty» kla­sy «Karty Wizyt». Pozostałe atry­bu­ty tej kla­sy (tu jeden) słu­żą wyłącz­nie do obsłu­gi wyszu­ki­wa­nia doku­men­tów i jak naj­bar­dziej mogą to być (nie muszą) powtó­rzo­ne ele­men­ty tre­ści tego doku­men­tu ).

Gdybym dopro­wa­dził powyż­szy model do koń­ca (będzie to kolej­ny arty­kuł), był by to wła­śnie Model Dziedziny apli­ka­cji w rozu­mie­niu wzor­ca MVC. 

Podsumowanie

Dokumentowe bazy danych mają wie­le zalet (np. wydaj­ność) ale zale­tą, któ­ra czy­ni jest na praw­dę ​„hitem” jest moż­li­wość cał­ko­wi­tej rezy­gna­cji z mode­lu rela­cyj­ne­go i języ­ka SQL, co w efek­cie daje ogrom­ne uprosz­cze­nie imple­men­ta­cji. ​„Wyciągnięcie” z repo­zy­to­rium nawet bar­dzo skom­pli­ko­wa­ne­go struk­tu­ral­nie doku­men­tu, reali­zu­je­my tu jed­nym bar­dzo pro­stym pole­ce­niem. Identyczna ope­ra­cja w mode­lu rela­cyj­nym będzie wyma­ga­ła nie raz mon­stru­al­ne­go, trud­ne­go do testo­wa­nia, zapy­ta­nia SQL .

Bazy doku­men­to­we ​„nie boją się redun­dan­cji”, więc zmia­ny atry­bu­tów nie prze­nio­są się na inne doku­men­ty. Architektura jak wyżej, jest cał­ko­wi­cie odpor­na na zmie­nia­ją­ce się struk­tu­ry kolej­nych egzem­pla­rzy doku­men­tów. Cała logi­ka ich wali­da­cji jest poza repo­zy­to­rium. Repozytoria są w 100% her­me­ty­zo­wa­ne, żad­ne infor­ma­cje nie są współ­dzie­lo­ne mię­dzy doku­men­ta­mi (dla­te­go też ewen­tu­al­na mody­fi­ka­cja jed­ne­go doku­men­tu nigdy nie prze­nie­sie sie na inne). . Posłużyłem się for­ma­tem XML jako przy­kła­dem, ale nie musi tak być, bar­dzo czę­sto wyko­rzy­sty­wa­ny jest JSON, ale te deta­le to decy­zja deve­lo­pe­ra w toku imple­men­ta­cji. Model ten tak­że dosko­na­le wpi­su­je się w śro­do­wi­ska chmu­ro­we takie jak AWS czy AZURE (moż­na tak­że wyko­rzy­stać repo­zy­to­ria obiektowe).

Implementacja wyżej opi­sa­nej archi­tek­tu­ry jest bar­dzo łatwa w posta­ci mikro­ser­wi­sów . Całość pro­jek­tu speł­nia zasa­dy OCP (Open Close Principle, sys­tem jest otwar­ty na roz­sze­rze­nia i zamknię­ty na zmiany). 

Kiedy bazy SQL? Hurtownie Danych, BigData i wie­le podob­nych wyma­ga­ją­cych prze­twa­rza­nia danych a nie tyl­ko archi­wi­zo­wa­nia. Wszędzie tam, gdzie taka potrze­ba sie poja­wia, efek­tyw­nym roz­wią­za­niem jest hur­tow­nia danych i pro­ces ETL pobie­ra­ją­cy dane z bazy doku­men­to­wej, lub archi­tek­tu­ra opar­ta na wzor­cach CQRS/Event Sourcing .

A to co tu opi­sa­no to stan­dar­do­wy pro­ces ana­li­zy i pro­jek­to­wa­nia MDA/MDE. Powstaje naj­pierw model CIM, potem PIM. A całość jako Opis Techniczny Oprogramowania jest chro­nio­nym know-how, jego imple­men­ta­cja jest dzie­łem zależ­nym. Wartości inte­lek­tu­al­ne zama­wia­ją­ce­go są w 100% chro­nio­ne, bo deve­lo­per nie ma żad­nych praw do imple­men­ta­cji jaką wyko­nał (ma pra­wa autor­skie oso­bi­ste a nie mająt­ko­we).

Chcesz wie­dzieć dla­cze­go tak: zapo­znaj się z opi­sem: Analiza sys­te­mo­wa jako meto­da ana­li­zy i projektowania

Źródła