Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
Cyfrowa Transformacja Organizacji: wiedza ogólna bezpłatnie na blogu, mój czas dedykowany dla Twojej Firmy tu:
Napisałem o orientacji na dokumenty w toku analiz:
Często jestem i ja pytany o to ??Jak wyjaśnić złożone rozwiązanie techniczne interesariuszom nietechnicznym?? Jak wielu mi podobnych odpowiadam: rozmawiaj dokumentami. Sponsor projektu, przyszli użytkownicy, postrzegają swoją pracę poprzez dokumenty: ich treść i układ. (Wymagania na formularze czyli diagramy struktur złożonych i XML)
Dzisiaj pójdziemy dalej, omówimy to gdzie i jak zachować tę informację. Posłużę się prostym przykładem przychodni weterynaryjnej. Artykuł będzie opisem metody podejścia do analizy zorientowanej na procesy i dokumenty.
Tekst ma dwie części: pierwsza jest opisem drogi jaka prowadzi nas do zdefiniowania tego jakie dokumenty, jaką mają (mieć) zawartość i strukturę. Praktycznie jest to opis analizy i projektowania. Druga – krótka – to przykładowa architektura logiki realizacji aplikacji, pokazująca miejsce dokumentowej bazy danych w architekturze i projekcie, czyli także projektowanie.
Celem tego wpisu jest pokazanie czym może być analiza oraz jej produkt jakim jest Techniczny Projekt Oprogramowania.
Przychodnia weterynarzy – analiza
Mam nadzieję, że to jak działa przychodnia weterynaryjna (Przychodnia), czytelnik jest w stanie sobie wyobrazić. Jeżeli nie, polecam lekturę regulaminu jakiejkolwiek tego typu przychodni, np. ten Regulamin. Ale od razu zaznaczam, że w przypadku realnego projektu należy od tego zacząć. Wywiady z pracownikami nie mają większego sensu, często wprowadzają w błąd. Analizę należy zacząć od analizy faktów czyli od zebrania partii przykładowych kart wizyt, regulaminów i zarządzeń, możliwe, że jest prawo regulujące tego typu usługi (a tu jest, parz USTAWA z dnia 18 grudnia 2003 r. o zakładach leczniczych dla zwierząt) .
Model procesu opisującego podstawową działalność przychodni wygląda tak:
Proces biznesowy obsługi klientów Przychodni (model analityczny, BPMN)
Zgłoszenie się pacjenta powoduje wystawienie Karty Wizyty, która jako planowana wizyta w przyszłości, stanowi sobą rezerwację terminu. Od tego momentu „zegar tyka”.
Jeżeli w Przychodni pojawi się Opiekun zwierzęcia, realizowana jest standardowa porada weterynaryjna. Jeżeli ktoś zgłosi odwołanie wizyty zostanie ona odwołana (ale jako dokument Karta Wizyty pozostanie w systemie ze statusem «odwołana»).
Zwracam uwagę, że zmiana terminu wizyty to odwołanie planowanej wizyty i nowa rezerwacja (takie podejście znakomicie upraszcza cały system, a dodatkowo zyskujemy dane do ewentualnych statystyk rzetelności klientów).
Zapewne większość biznesu (praca na user story, wywiady itp.) będzie oczekiwała możliwości edytowania Kart Wizyt i jest to własnie najgorsze rozwiązanie. To dlatego nie słucham pomysłów klientów na system, oczekuję wyłącznie opisu celu danej aktywności, a ta brzmi (powinna) raczej „chciał bym mieć możliwość przełożenia wizyty”, a nie „chce mieć możliwość edycji pola «termin wizyty» ”. Jeżeli termin wizyty nadejdzie a opiekun sie nie pojawi, wizyta zostanie oznaczona statusem «zignorowana».
Z uwagi na to, że nie umieszczamy na analitycznych modelach procesów biznesowych, opisów wypełniania formularzy czy detalicznych procedur, konieczny jest szablon dokumentu skojarzony z elementem Karta Wizyty (BPMN: DataObject). Jak już wspominałem w innym artykule, można do tego celu zastosować notację UML i diagram struktur złożonych (a dla użytkowników oprogramowania CASE jest to rekomendacja):
You need to pay to see more.
Podsumowanie
Dokumentowe bazy danych mają wiele zalet (np. wydajność) ale zaletą, która czyni jest na prawdę „hitem” jest możliwość całkowitej rezygnacji z modelu relacyjnego i języka SQL, co w efekcie daje ogromne uproszczenie implementacji. „Wyciągnięcie” z repozytorium nawet bardzo skomplikowanego strukturalnie dokumentu, realizujemy tu jednym bardzo prostym poleceniem. Identyczna operacja w modelu relacyjnym będzie wymagała nie raz monstrualnego, trudnego do testowania, zapytania SQL .
Bazy dokumentowe „nie boją się redundancji”, więc zmiany atrybutów nie przeniosą się na inne dokumenty. Architektura jak wyżej, jest całkowicie odporna na zmieniające się struktury kolejnych egzemplarzy dokumentów. Cała logika ich walidacji jest poza repozytorium. Repozytoria są w 100% hermetyzowane, żadne informacje nie są współdzielone między dokumentami (dlatego też ewentualna modyfikacja jednego dokumentu nigdy nie przeniesie sie na inne). . Posłużyłem się formatem XML jako przykładem, ale nie musi tak być, bardzo często wykorzystywany jest JSON, ale te detale to decyzja developera w toku implementacji. Model ten także doskonale wpisuje się w środowiska chmurowe takie jak AWS czy AZURE (można także wykorzystać repozytoria obiektowe).
Implementacja wyżej opisanej architektury jest bardzo łatwa w postaci mikroserwisów . Całość projektu spełnia zasady OCP (Open Close Principle, system jest otwarty na rozszerzenia i zamknięty na zmiany).
Kiedy bazy SQL? Hurtownie Danych, BigData i wiele podobnych wymagających przetwarzania danych a nie tylko archiwizowania. Wszędzie tam, gdzie taka potrzeba sie pojawia, efektywnym rozwiązaniem jest hurtownia danych i proces ETL pobierający dane z bazy dokumentowej, lub architektura oparta na wzorcach CQRS/Event Sourcing .
A to co tu opisano to standardowy proces analizy i projektowania MDA/MDE. Powstaje najpierw model CIM, potem PIM. A całość jako Opis Techniczny Oprogramowania jest chronionym know-how, jego implementacja jest dziełem zależnym. Wartości intelektualne zamawiającego są w 100% chronione, bo developer nie ma żadnych praw do implementacji jaką wykonał (ma prawa autorskie osobiste a nie majątkowe).
Pacheco, V. F. (2018). Microservice Patterns and Best Practices: Explore patterns like CQRS and event sourcing to create scalable, maintainable, and testable microservices. Packt Publishing Ltd.
Kitchenham, B. A., Dybå, T., & Jørgensen, M. (2004). Evidence-based Software Engineering. Th International Conference on Software Engineering, 9.
WÓJCIK, A. (2014). NIERELACYJNE BAZY DANYCH. Zeszyty Naukowe WSEI Seria: TRANSPORT I INFORMATYKA, 4(1).
Wei-Ping, Z., Ming-Xin, L. I., & Huan, C. (2011). Using MongoDB to implement textbook management system instead 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 – database comparison. 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 evaluation of a mongodb and hadoop platform for scientific data analysis. 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 mongodb to an sql db. Proceedings of the 51st ACM Southeast Conference, 1 – 6.
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based software engineering and systematic reviews. CRC Press.
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/10.1007/978 – 3‑319 – 74781-1_17
Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).
Czy w modelu maszyny UML opisujący status wizyty, dopisek [odwołana przez opiekuna] nie powinien być po prawej stronie diagramu przy statusie odwołana a nie przy zignorowana ? Wydaję sie ze wizyta zignorowana to wizyta przeterminowana bez próby kontaktu ze strony klienta czyli nie odwołana i nie zrealizowana.
Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione. Ewentualne użycie treści wymaga indywidualnej zgody autora.
Nie wykryto skryptu Javascript. Javascript wymagany do działania tej strony. Proszę włączyć go w ustawieniach przeglądarki i odświeżyć tę stronę.
Zarządzaj zgodami plików cookie
Aby zapewnić jak najlepsze wrażenia, korzystamy z technologii, takich jak pliki cookie, do przechowywania i/lub uzyskiwania dostępu do informacji o urządzeniu. Zgoda na te technologie pozwoli nam przetwarzać dane, takie jak zachowanie podczas przeglądania lub unikalne identyfikatory na tej stronie. Brak wyrażenia zgody lub wycofanie zgody może niekorzystnie wpłynąć na niektóre cechy i funkcje.
Funkcjonalne
Zawsze aktywne
Przechowywanie lub dostęp do danych technicznych jest ściśle konieczny do uzasadnionego celu umożliwienia korzystania z konkretnej usługi wyraźnie żądanej przez subskrybenta lub użytkownika, lub wyłącznie w celu przeprowadzenia transmisji komunikatu przez sieć łączności elektronicznej.
Preferencje
Przechowywanie lub dostęp techniczny jest niezbędny do uzasadnionego celu przechowywania preferencji, o które nie prosi subskrybent lub użytkownik.
Statystyka
Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do celów statystycznych.Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do anonimowych celów statystycznych. Bez wezwania do sądu, dobrowolnego podporządkowania się dostawcy usług internetowych lub dodatkowych zapisów od strony trzeciej, informacje przechowywane lub pobierane wyłącznie w tym celu zwykle nie mogą być wykorzystywane do identyfikacji użytkownika.
Marketing
Przechowywanie lub dostęp techniczny jest wymagany do tworzenia profili użytkowników w celu wysyłania reklam lub śledzenia użytkownika na stronie internetowej lub na kilku stronach internetowych w podobnych celach marketingowych.
obszerna prezentacja na temat baz dokumentowych: http://staff.uz.zgora.pl/agramack/files/BazyDanych/NoSQL/NoSQL.pdf
Czy w modelu maszyny UML opisujący status wizyty, dopisek [odwołana przez opiekuna] nie powinien być po prawej stronie diagramu przy statusie odwołana a nie przy zignorowana ? Wydaję sie ze wizyta zignorowana to wizyta przeterminowana bez próby kontaktu ze strony klienta czyli nie odwołana i nie zrealizowana.
Tak, faktycznie 🙂