Projekt aplikacji – przykład

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:

Proces biz­ne­so­wy obsłu­gi klien­tów Przychodni (model ana­li­tycz­ny, BPMN)

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

Struktura for­mu­la­rza Karta Wizyty (dia­gram struk­tur zło­żo­nych, UML)

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:

Struktura Karty Wizyty i typów atry­bu­tów (dia­gram klas, UML)

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:

Statusy Karty Wizyty (maszy­na sta­no­wa, 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:

Przestrzeń poję­cio­wa Przychodni (dia­gram fak­tów, SBVR, lub dia­gram klas UML)

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:

1. iden­ty­fi­ka­cja kar­ty wizy­ty (numer wizyty)
2. anu­lo­wa­nie wizy­ty (zmia­na statusu)
Procedura

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:

Zakres pro­jek­tu (dia­gram przy­pad­ków uży­cia, UML)

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:

1. Recepcja ini­cju­je Karty Wizyt
2. SYSTEM wyświe­tla for­mu­larz Karta Wizyty
3. Recepcja wpro­wa­dza dane do for­mu­la­rza Karta Wizyty i naci­ska Zapisz (regu­ła: Duplikowanie wizyt)
4. SYSTEM wyświe­tla Karta Wizyty i ewen­tu­al­ne komunikaty
Scenariusz: nowa wizyta

zaś dru­gi scenariusz:

1. Recepcja ini­cju­je Karty Wizyt
2. SYSTEM wyświe­tla for­mu­larz Karta Wizyty
3. Recepcja wpro­wa­dza dane do pola numer wizy­ty for­mu­la­rza Karta Wizyty i naci­ska Szukaj
4. SYSTEM wyświe­tla wypeł­nio­ny for­mu­larz Karta Wizyty lub komu­ni­ka o bra­ku karty
5. Recepcja zmie­nia sta­tus for­mu­la­rza Karta Wizyty i naci­ska Zapisz
6. SYSTEM wyświe­tla zacho­wa­ny for­mu­larz Karta Wizyty i ewen­tu­al­ne komunikaty
Scenariusz: odwo­ła­nie wizyty

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

Model archi­tek­tu­ry reali­za­cji usłu­gi apli­ka­cyj­nej (wzo­rzec BCE, dia­gram klas, UML)

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, 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).

Możesz nabyć ory­gi­nal­ny plik tego pro­jek­tu w Visual Paradigm.

Źródła

Papamarkos, G., Zamboulis, L., & Poulovassilis, A. (2015). Xml Databases. School of Computer Science and Information Systems, Birkbeck College, University of London. http://www.dcs.bbk.ac.uk/~sven/adm08/xmlDBs.pdf
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699
Pacheco, V. F. (2018). Microservice Patterns and Best Practices: Explore pat­terns like CQRS and event sour­cing to cre­ate sca­la­ble, main­ta­ina­ble, and testa­ble micro­se­rvi­ces. Packt Publishing Ltd.
Kitchenham, B. A., Dybå, T., & Jørgensen, M. (2004). Evidence-based Software Engineering. Th International Conference on Software Engineering, 9.
Truica, C.-O., Radulescu, F., Boicea, A., & Bucur, I. (2015). Performance eva­lu­ation for CRUD ope­ra­tions in asyn­chro­no­usly repli­ca­ted docu­ment orien­ted data­ba­se. 2015 20th International Conference on Control Systems and Computer Science, 191 – 196.
WÓJCIK, A. (2014). NIERELACYJNE BAZY DANYCH. Zeszyty Naukowe WSEI Seria: TRANSPORT I INFORMATYKA, 4(1).
van Sinderen, M., & Johnson, P. (Eds.). (2011). Enterprise Interoperability: Third International IFIP Working Conference, IWEI 2011, Stockholm, Sweden, March 23 – 24, 2011. Proceedings (Vol. 76). Springer Berlin Heidelberg. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 19680‑5
Wei-Ping, Z., Ming-Xin, L. I., & Huan, C. (2011). Using MongoDB to imple­ment text­bo­ok mana­ge­ment sys­tem inste­ad of MySQL. 2011 IEEE 3rd International Conference on Communication Software and Networks, 303 – 305.
Boicea, A., Radulescu, F., & Agapin, L. I. (2012). MongoDB vs Oracle – data­ba­se com­pa­ri­son. 2012 Third International Conference on Emerging Intelligent Data and Web Technologies, 330 – 335.
Dede, E., Govindaraju, M., Gunter, D., Canon, R. S., & Ramakrishnan, L. (2013). Performance eva­lu­ation of a mon­godb and hado­op plat­form for scien­ti­fic data ana­ly­sis. Proceedings of the 4th ACM Workshop on Scientific Cloud Computing, 13 – 20.
Banker, K. (2011). MongoDB in action. Manning Publications Co.
Parker, Z., Poe, S., & Vrbsky, S. V. (2013). Comparing nosql mon­godb to an sql db. Proceedings of the 51st ACM Southeast Conference, 1 – 6.
Usman, Z., Young, R. I. M., Chungoora, N., Palmer, C., Case, K., & Harding, J. (2011). A Manufacturing Core Concepts Ontology for Product Lifecycle Interoperability. In M. van Sinderen & P. Johnson (Eds.), Enterprise Interoperability (pp. 5 – 18). Springer. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 19680-5_3
Daniel, G., Gomez, A., & Cabot, J. (2019). UMLto[No]SQL: Mapping Conceptual Schemas to Heterogeneous Datastores. 2019 13th International Conference on Research Challenges in Information Science (RCIS), 1 – 13. https://​doi​.org/​1​0​.​1​1​0​9​/​R​C​I​S​.​2​0​1​9​.​8​8​7​7​094
Shimura, T., Yoshikawa, M., & Uemura, S. (1999). Storage and Retrieval of XML Documents Using Object-Relational Databases. In T. J. M. Bench-Capon, G. Soda, & A. M. Tjoa (Eds.), Database and Expert Systems Applications (Vol. 1677, pp. 206 – 217). Springer Berlin Heidelberg. https://​doi​.org/​1​0​.​1​0​0​7/3 – 540-48309 – 8_19
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.
Evans, E. (2014). Domain-dri­ven design: tac­kling com­ple­xi­ty in the heart of softwa­re. Addison-Wesley.
Rosenberg, D., Stephens, M., & Collins-Cope, M. (2005). Agile deve­lop­ment with ICONIX pro­cess: people, pro­cess, and prag­ma­tism. Apress.
Rademacher, F., Sachweh, S., & Zündorf, A. (2018). Towards a UML Profile for Domain-Driven Design of Microservice Architectures. In A. Cerone & M. Roveri (Eds.), Software Engineering and Formal Methods (Vol. 10729, pp. 230 – 245). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 74781-1_17

Inne artykuły na podobny temat

Komentarze

  1. Marek 28 lipca 2021 at 13:00

    Czy w mode­lu maszy­ny UML opi­su­ją­cy sta­tus wizy­ty, dopi­sek [odwo­ła­na przez opie­ku­na] nie powi­nien być po pra­wej stro­nie dia­gra­mu przy sta­tu­sie odwo­ła­na a nie przy zigno­ro­wa­na ? Wydaję sie ze wizy­ta zigno­ro­wa­na to wizy­ta prze­ter­mi­no­wa­na bez pró­by kon­tak­tu ze stro­ny klien­ta czy­li nie odwo­ła­na i nie zrealizowana.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

System komentarzy służy także do uzyskania konsultacji u autora tekstu, w przedmiocie treści artykułu.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.