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

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