Arkadiusz Pachucy 171049 Wrocław, dn. 30 listopada 2012 Paweł Kowalski 171143 Kamil Markuszewski 171016 Zaawansowane metody programowania Tytuł projektu: Informatyczny system obsługi przychodni Rok akad. 2012/2013, kierunek: INF PROWADZĄCY: Dr inż. Jacek Cichosz
Spis treści 1. Streszczenie...3 2. Wstępny opis słowny...4 3. Słownik pojęć z dziedziny problemu...10 4. Analiza wymagań użytkownika...13 5. Model systemu...21 Diagram wdrożenia...21 Diagram klas...23 Diagram stanów...27 Diagram aktywności...28 Diagram sekwencji...29 Diagram przepływu danych...31 6. Kwestie implementacyjne...32 7. Podsumowanie i dyskusja krytyczna...33 8. Wykaz materiałów źródłowych...34
1. Streszczenie Podczas wizyt w specjalistycznych przychodniach, można niejednokrotnie zauważyć problem niemożliwości dodzwonienia się do rejestracji, długiego czasu oczekiwania na termin wizyty, braku informacji ze strony lekarza odnośnie opóźnień w dotarciu do przychodni. Aby przeciwdziałać takim sytuacją, chcemy stworzyć aplikację, będącą Informatycznym systemem obsługi przychodni. Celem stworzenia tej aplikacji jest podniesienie jakości usług poprzez wprowadzenie informatyzacji w kontakcie z klientem. Co przełoży się na skrócenie czasu oczekiwania na termin wizyty, udostępni pacjentom większą swobodę w dobieraniu terminów wizyt lekarskich, zminimalizuje przepadanie terminów wizyt. W projekcie Informatyczny system obsługi przychodni będziemy zajmowali się przygotowaniem projektu informatycznego zajmującego się obsługą przychodni lekarskiej. Podczas tworzenia naszej aplikacji, będziemy wykorzystywać Scrum jako narzędzie do tworzenia naszej aplikacji oraz prezentacji etapów jej tworzenia. W jego skład wchodzą 3 aplikacje: aplikacja mobilna przygotowana pod platformę Android, dla pacjentów (klientów przychodni), jak i lekarzy (usługodawców) aplikacja typu stand-alone dla zarządzenia przychodnią obsługiwana przez personel prowadzący rejestrację pacjentów serwer pobierający dane z bazy danych i eksportujący odpowiednio przygotowane pakiety dla aplikacji mobilnej oraz stand-alone Pierwszą czynnością jaką wykonamy będą diagramy UML, w celu zaplanowania projektowania samej aplikacji. Wykonamy następujące diagramy (dla wybranych przypadków): przepływu danych klas i pakietów sekwencji aktywności stanów przypadków użycia
2. Wstępny opis słowny Sercem naszego projektu będzie serwer, który będzie komunikował się z bazą danych w celu pobierania potrzebnych informacji, a następnie opracowujący i wysyłający wynikowy plik XML/JSON do aplikacji lokalnej, bądź mobilnej. Jako klienta mobilnego rozumiemy zarówno pacjenta, jak i lekarza. W ramach projektu planujemy wykonać następujące funkcjonalności (funkcjonalności z oznaczeniem (o) na początku są zadaniami opcjonalnymi): Rejestracja klientów (pacjentów przychodni) System powiadomień i potwierdzania wizyt (Przed wizytą rozsyłane będą zawiadomienia dla pacjentów, na które będą musieli odpowiedzieć w celu potwierdzenia wizyty. W razie braku odpowiedzi, bądź odmowy wizyty, będą wysyłane zaproszenia do osób oczekujących w kolejce na wizytę) Priorytet wizyty do lekarza (Obecnie lekarze posiadają limity dzienne na ilość wizyt. Zakładamy przedzielenie 8 zwykłych wizyt i 2 o wysokim priorytecie na 10 wizyt dziennie u lekarza) System nadzorowania stanu posiadanych leków Zamawianie/wystawianie recept przez internet dla stałych pacjentów o znanej historii choroby (po wysłaniu żądania przez pacjenta, lekarz będzie mógł wystawić elektroniczny dokument receptę opatrzoną informacją, że recepta ta pochodzi z programu komputerowego i nie wymaga podpisu odręcznego) Odwoływanie wizyty przez lekarzy/zmiana terminu wizyty (o) Obsługa personelu pozamedycznego (personel sprzątający, konserwatorski itp.) Zamawianie sal specjalnych (sale nie należące do konkretnego lekarza, jak np. sale z tomografem, sale operacyjne, czy też sale konferencyjne)
Założenia projektowe: wykonywane diagramy UML muszą być spójne nie bierzemy pod uwagę kasy chorych w przypadku rejestracji mobilnej (kasa chorych będzie przypisywana pacjentowi w przychodni) pacjent nie może sam sobie przydzielić wyższego priorytetu wizyty jeśli pacjent posiada naszą aplikację na urządzeniu mobilnym, wtedy otrzymuje notyfikację na telefon, w przeciwnym wypadku odpowiedni komunikat zostanie wyświetlony w aplikacji stand-alone, a pacjent zostanie zapytany telefonicznie przez personel rejestracji sprawdzanie ważności skierowań lekarskich (skierowanie jest ważne przez rok, jeśli w przeciągu roku pacjent odwiedzał dwukrotnie lekarza specjalistę, to jego schorzenie jest traktowane, jako choroba przewlekła i okres jego skierowanie przedłuża się automatycznie generowanie recept, możliwe tylko w stand-alone (możliwość odbioru recepty bez wizyty lekarskiej, ale nie bez wizyty w przychodni) Głównym celem projektu jest przygotowanie systemu, który wspomoże działanie przychodzi, w szczególności w aspekcie obsługi rejestrowania pacjentów, komunikacji lekarz pacjent (informowanie o spóźnieniach, potwierdzanie wizyt pacjentów lub ich odwoływanie), prowadzenia bazy wizyt. Dzięki możliwości zdalnego rejestrowania pacjentów, taka aplikacja wpłynie na zwiększenie atrakcyjności używającej jej przychodni oraz efektywniejszą pracę przychodni. W ramach tego projektu przygotowaliśmy już bazę danych, jej schemat wygląda następująco (nie jest to jeszcze ostateczny schemat, ulegnie on za pewne pewnym modyfikacją podczas implementacji problemu):
Rys. 1 Schemat bazy danych
Rys. 2.1 prezentuje schemat bazy danych, wykorzystywanej przez wszystkie części Informatycznego systemu obsługi przychodni. Baza danych spełnia wymagania trzeciej postaci normalnej. Baza składa się z 17 tabel: a) Patients tablica poświęcona przechowywaniu danych pacjentów podstawowych danych (imię, nazwisko, płeć, data urodzenia, pesel, numer telefonu, email, ważności skierowania, odnośnik do adresu oraz kasy chorych), danych weryfikacyjnych (login i hasło). Znajduje się w relacji z 6 tabelami PatientCashbox, w relacji 1 do 1, PatientHealthCards, w relacji 1 do 1, PatientAdress w relacji 1 do 1, Prescriptions, w relacji 1 do n, PendingVisits, w relacji 1 do n oraz Visits, w relacji 1 do n. b) PatientAdress tabela przechowująca dane zamieszkania pacjenta, powstała w wyniku normalizacji bazy danych. Znajduje się w relacji 1 do 1 z tabelą Patients. c) PatientsCashbox tabela przechowująca listę kas chorych, dzięki niej możemy swobodnie odnosić się do konkretnych kas chorych, za pomocą numeru id, bez konieczności zaszywania w kodzie programu tabeli kas chorych w razie zmiany ilości kas chorych istnieje możliwość modyfikacji bazy danych, bez konieczności ingerencji w kod programu. Znajduje się w relacji 1 do 1 z tabelą Patients. d) PendingVisits tabela ta przechowuje dane o wizytach, na które zapisali się pacjenci, które nie zostały jeszcze potwierdzone w określonym czasie do wizyty. Zawiera dane odnośnie dnia i godziny wizyty, priorytetu pacjenta, oraz odnośniki do id_pacjenta, id_lekarza oraz id_pokoju. Tabela znajduje się w relacji z 3 tabelami Patients, w relacji n do 1, Doctors, w relacji n do 1, Rooms, w relacji n do 1. e) Visits tabela ta przechowuje dane o wizytach, które zostały już potwierdzone przez pacjentów. Zawiera takie same kolumny jak PendingVisits. Znajduje się w relacji z 4 tabelami - Patients, w relacji n do 1, Doctors, w relacji n do 1, Rooms, w relacji n do 1 oraz PatientHealthCards, w relacji 1 do 1.
f) Doctors tabela przechowująca informacje o lekarzach w placówce. Posiada podstawowe dane (imię, nazwisko, data urodzenia, numer telefonu, odnośnik do specjalizacji oraz numeru gabinetu), danych weryfikacyjnych (login i hasło). Znajduje się w relacji z 5 tabelami Rooms, w relacji 1 do 1, Visits, w relacji 1 do n, PendingVisits, w relacji 1 do n, Specializations, w relacji n do 1, Prescriptions, w relacji 1 do n. g) Rooms tabela przechowująca informacje o gabinetach numer pokoju, piętro na którym znajduje się pokój, informacja, czy jest to gabinet specjalny (gabinet specjalnego przeznaczenia sale operacyjne, sale konferencyjne, gabinety nie przypisane do konkretnego lekarza, do których trzeba zgłaszać chęć skorzystania). Znajduje się w relacji z 1 tabela Doctors, relacji 1 do 1. h) Specializations tabela stanowiąca listę specjalizacji. Znajduje się w relacji z 2 tabelami Doctors, w relacji 1 do n, Nurses, w relacji 1 do n. i) Nurses - tabela przechowująca informacje o pielęgniarkach w placówce. Posiada podstawowe dane (imię, nazwisko, data urodzenia, numer telefonu, odnośnik do specjalizacji). Znajduje się w relacji z 1 tabelą Specializations, w relacji n do 1. j) Prescriptions tabela zawierająca dane recept wypisywanych przez lekarzy, do odbioru ich bez wizyty u lekarza. Zawiera dane odnośnie daty, o której recepta może zostać wykorzystana oraz odnośniki do lekarza i pacjenta. Tabela znajduje się w relacji z 3 tabelami Doctors, w relacji n do 1, Patients, w relacji n do 1 oraz ReceptHaveDrugs, w relacji 1 do n. k) ReceptHaveDrugs tabela powstała w wyniku normalizacji. Zawiera klucze obce, do tabel recept i leków, odpowiada za rozwiązanie problemu relacji n do n. Tabela znajduje się w relacji z 2 tabelami - Prescriptions, w relacji n do 1 oraz Drugs, w relacji n do 1. l) Drugs tabela przechowująca informację, o lekach znajdujących się na receptach elektronicznych. Zawiera nazwę leku, oznaczenie refundacji dla danego pacjenta oraz ilość leków danego typu, dla danej recepty. Tabela znajduje się w relacji z 1 tabelą - ReceptHaveDrugs, w relacji 1 do n.
m) patienthealthcards tabela zawierająca dane medyczne pacjenta wagę, wzrost, odnośnik do ostatniej wizyty oraz odnośnik do samego pacjenta. Znajduje się w relacji z 2 tabelami Patients, w relacji 1 do 1 oraz Visits, w relacji 1 do 1. n) NonMedicStaff tabela przechowująca dane o pracownikach nie związanych z medycyną (personel pomocniczy, sprzątający, remontujący). Zawiera kolumny imię, nazwisko, data urodzenia oraz numer telefonu. o) Products tabela przechowująca dane o lekach i środkach potrzebnych do pracy przychodni. Zawiera informacje nazwę, posiadany stan danego produktu, limit dolny danego produktu, cenę, odnośnik do vatu oraz odnośnik do dostawcy. Tabela znajduje się w relacji z 2 tabelami VatTypes, w relacji n do 1, Providers, w relacji n do 1. p) VatTypes tabela listująca staki vat. W razie zmiany wysokości stawki vat, można w prosty sposób zmodyfikować procent w tej tabeli. Tabela znajduje się w relacji 1 do n z tabelą Products. q) Providers tabela przechowująca informacje o dostawcach produktów używanych w placówce. Zawiera dane nazwę dostawcy, ulice, numer budynku, nip, regon, krs. Znajduje się w relacji 1 do n z tabelą Products. Glosariusz: Aplikacja mobilna program przygotowany do pracy na urządzeniu typu smartphone oraz tablet Lista wizyt lista terminów zajętych do tej pory w systemie XML/JSON sposób komunikacji aplikacji z serwerem Baza danych obiekt, w którym przechowuje się informacje wykorzystywane przez aplikacje Zdalne rejestrowanie pacjentów wykonywanie dodawania pacjentów do listy wizyt
3. Słownik pojęć z dziedziny problemu Aplikacja mobilna program przygotowany pod system Android, pracujący po stronie klienckiej. Odpowiedzialny za obsługę systemu rejestracji pacjentów (dodawanie ich do bazy) oraz systemu rezerwacji wizyt. Aplikacja do komunikacji z systemem wymaga dostępu do internetu (WiFi/UMTS). Aplikacja stand-alone program multiplatformowy, w języku Java SE. Posiadający pełne możliwości zarządzania rejestracją pacjentów i pracowników, obsługujący system rezerwacji wizyt, nadzoru stanu zaopatrzenia, obsługi systemu recept. Rezerwacje zakładamy limit dzienny 8 zwykłych wizyt, 1 wizyty dla osoby o konieczności szybkiego spotkania z lekarzem oraz 1 wizytę rezerwową na nadzwyczajne sytuacje (jak wypadki). Pacjent po zapisaniu się na wizytę na 48 godzin przed wizytą otrzyma prośbę o potwierdzenie, jeśli nie odpowie w ciągu 16 godzin, jego wizyta przepada, a oferta skorzystania z tej wizyty przechodzi na pierwszą osobę w kolejce, otrzyma ona 16 godzin na zatwierdzenie wizyty, w razie niepowodzenia informacja o możliwości wizyty zostanie przesłana do kolejnej osoby. Stan leków każdy z leków podczas wydawania powinien być ujmowany w systemie, w sytuacji wystąpienia poziomu minimalnego określonego produktu, nastąpi poinformowanie o konieczności zamówienia danego leku. JSON (JavaScript Object Notation) lekki format wymiany danych komputerowych. Jest to format tekstowy będący podzbiorem Java Script. Spełnia on podobną funkcję, jak XML, z którym mieliśmy do tej pory więcej do czynienia. Z uwagi jednak, na mniejszy narzut danych, co przekłada się na odchudzenie i zwiększenie wydajności komunikacji, wybraliśmy JSON zamiast XML. Największym plusem XML jest jego czytelność dla człowieka, względem JSON, jednak z uwagi na przetwarzanie danych przez aplikacje, jest to funkcjonalność całkowicie zbędna. Nasza aplikacja wykorzystuje JSONA do przesyłania danych od serwisu bazy danych do aplikacji. Baza danych zbiór danych, przechowywanych w określony sposób, wg określonej struktury. Zwykle termin ten odnosi się do systemu zarządzania bazą danych (DBMS). W obrębie bazy danych można przechowywać różnego rodzaju dane (obecnie istnieją nawet możliwości przechowywania obrazów, filmów i dźwięków), my ograniczymy się do tradycyjnych danych tekstowych i liczbowych zapisanych w postaci cyfrowej. Jako serwer bazodanowy posłuży nam MySQL Server.
Serwer aplikacji w naszym przypadku program komputerowy, działający na maszynie zdalnej wyposażonej w Apache Tomcat, obsługujący żądania kierowane do aplikacji. Nasz serwer aplikacji będzie otrzymywał JSON'owe zgłoszenia, bądź żądania, które będzie przetwarzał i na ich podstawie generował JSON'ową odpowiedź, na podstawie danych z bazy danych. Odpowiada zarówno za weryfikację aplikacji klienckich, odczytywanie danych z bazy danych, jak i zapis i modyfikację do bazy danych. Aplikacja ta będzie sprawowała pełne zarządzanie bazą danych. Apache Tomcat jest to kontener aplikacji webowych. Odpowiada za udostępnienie serwera aplikacji, dla wszystkich użytkowników. Jest to obecnie najpopularniejszy darmowy kontener dla samodzielnych aplikacji (nie wymagających pełnego serwera aplikacji). Doskonale spełnia swoje zadanie w przypadku naszej aplikacji. Java EE (Java Enterprise Edition) jest serwerową platformą programistyczną języka Java. Program pisany w takim standardzie jest oparty o wielowarstwową architekturę komponentową. Komponenty te są osadzane na serwerze aplikacyjnym obsługującym Java Enterprise. Dzięki temu standardowi możliwa jest współpraca z różnymi platformami, architekturami, a nawet praca rozproszona. W oparciu o tą technologię powstał serwer aplikacji. Projekt zależny biblioteka dynamiczna dla Androida, pozwalająca na dodawanie nie natywnych widgetów Adt (Android Development Tools) wtyczka do środowiska Eclipse IDE, rozszerzająca możliwości o przystosowanie do pisania aplikacji na Androida. Wraz z bibliotekami, udostępnia szablony interfejsów aplikacji, eksport podpisów aplikacji.apk w celach dystrybucji, a także symulator telefonu z systemem Android. Serwlet klasa Javy działająca po stronie serwera WWW w modelu żądanie - odpowiedź SQL strukturalny język zapytań, służący do tworzenia, modyfikowania baz danych i pobierania z tych baz informacji. XML uniwersalny język formalny przeznaczony do prezentowania różnego rodzaju danych. MVP (Model Widok Prezenter) - wzorzec oprogramowania służący do budowania interfejsów użytkownik. Model ten jest podobno do MVC, jednak jego logika jest przesunięta w kierunku prezentera. UML język formalny służący do prezentowania modelowania różnych systemów.
RowEntity metodyka pobieranie jedynie interesujących nas danych, co wpływa na ograniczenie ruchu. Np. gdy pobieramy dane o wizycie i potrzebujemy tylko informację o godzinie, dacie i lekarzu odnoszącym się do wizyty, omijamy pobieranie danych o pacjencie. Scrum metodyka projektowa, zaliczana do metodyk zwinnych. Zakłada dzielenie całego procesu tworzenia oprogramowania na mniejsze etapy, nazywane sprintami.
4. Analiza wymagań użytkownika Scenariusze: Logowanie 1. Aplikacja stand-alone Uruchomienie aplikacji wprowadzenie loginu Naciśnięcie przycisku zaloguj Pojawienie się okienka informującego o błędzie Naciskamy przycisk ok Pojawi się okno konfiguracji Naciskamy przycisk anuluj Zamknięcie aplikacji 2. Aplikacja mobilna Uruchomienie aplikacji Naciśnięcie przycisku login wprowadzenie nazwiska Naciśnięcie przycisku login Usunięcie nazwiska wprowadzenie peselu Naciśnięcie przycisku Zaloguj Przejście do następnego widoku
Rejestracja 1. Aplikacja stand-alone Uruchamiamy aplikację wprowadzamy login i hasło Klikamy przycisk Zaloguj Otwiera się główne okno aplikacji Klikamy na menu wizyty i wybieramy opcję dodaj wpis wizyty Otwiera się zakładka prezentująca wizyty wybieramy pacjenta, lekarza, dzień, miesiąc, rok, godzinę i minuty wizyty klikamy przycisk Zapisz Pojawia się o okienko o pomyślnej rejestracji Klikamy OK, aby zamknąć okienko Zakładka zamyka się Powrót do okna głównego 2. Aplikacja mobilna Zalogowanie się przesunięcie palcem w prawo naciśnięcie na przycisk wizyty przejście do formularza rejestracji wizyt wypełnienie pola telefon wybranie płci wypełnienie pola email wprowadzenie nazwiska lekarza naciśnięcie na przycisk wyślij formularz otrzymanie informacji zwrotnej z terminem zaproponowanej wizyty powrót do menu głównego, dodanie wizyty do wizyt oczekujących
Przeglądanie wizyt 3. Aplikacja stand-alone Uruchamiamy aplikację wprowadzamy login i hasło Klikamy przycisk Zaloguj Otwiera się główne okno aplikacji Klikamy na menu wizyty i wybieramy opcję wyszukaj wizyty Otwiera się zakładka prezentująca wizyty Zamykamy zakładkę Powrót do głównego okna aplikacji 4. Aplikacja mobilna zalogowanie się przesunięcie palcem w prawo naciśnięcie przycisku moje wizyty przejście do listy moich wizyt
Zatwierdzenie wizyty 1. aplikacja stand-alone Uruchamiamy aplikację wprowadzamy login i hasło Klikamy przycisk Zaloguj Otwiera się główne okno aplikacji Klikamy na menu wizyty i wybieramy opcję Pokaż wszystkie oczekujące wizyty Otwiera się zakładka prezentująca oczekujące wizyty Klikamy opcję potwierdź obok danych interesującej nas wizyty Pojawia się okienko informujące o pomyślności potwierdzenia wizyty Klikamy OK, aby zamknąć okienko Zamykamy zakładkę Powrót do głównego okna aplikacji 2. aplikacja mobilna zalogowanie się przesunięcie palcem w prawo naciśnięcie na przycisku zatwierdź wizyty przejście do nowego widoku listy wizyt do zaakceptowania długi naciśnięcie na wizytę wyświetlenie potwierdzenia zaakceptowania wizyty powrót do poprzedniego widoku
Nadanie priorytetu wizyty aplikacja stand-alone Uruchamiamy aplikację wprowadzamy login i hasło Klikamy przycisk Zaloguj Otwiera się główne okno aplikacji Klikamy na menu wizyty i wybieramy opcję Pokaż wszystkie oczekujące wizyty Otwiera się zakładka prezentująca oczekujące wizyty Klikamy symbol aby wysunąć menu priorytetu wizyty oczekującej i klikamy interesującą nas opcję Zamykamy zakładkę Powrót do głównego okna aplikacji Generowanie recept aplikacja stand-alone Uruchamiamy aplikację wprowadzamy login i hasło Klikamy przycisk Zaloguj Otwiera się główne okno aplikacji Klikamy na menu Recepty i wybieramy opcję Przygotuj receptę Otwiera się zakładka tworzenia recepty wybieramy pacjenta Klikamy przycisk OK Otwiera się zakładka generowania recepty dla konkretnego pacjenta Klikamy przycisk +, a następnie wybieramy z listy leków przypisanych danemu pacjentowi lek, po czym w polu po prawej stronie dopisujemy liczbę leków danego typu wybieramy lekarza opiekującego się pacjentem Klikamy przycisk generuj receptę Pojawia się okienko wyboru folderu wybieramy folder i klikamy ok Powstaje plik pdf z receptą w wybranym folderze Zamknięcie zakładki i powrót do głównego okna aplikacji
W naszej aplikacji występują trzy typy aktorów, są to: Lekarze Recepcjonistki Klienci Każdy z aktorów ma dostępne inne przypadki użycia w systemie co świadczy o jego pozycji oraz pozwala nam na skuteczniejszą kontrolę systemu. Dla lekarzy oraz recepcjonistek dostępna jest szersza wersja aplikacji, zaś dla klientów dostępna jest jedynie wersja mobilna, która umożliwia tylko najprostsze akcje (znacznie uproszczona). Przypadki użycia systemu można podzielić na trzy duże grupy: Magazyn leków Wydawanie recept Rejestracja wizyt Magazyn leków to grupa przypadków użycia, która jest dostępna tylko dla pracowników (lekarzy oraz recepcjonistki) przychodni, dlatego też te funkcjonalności znajdują się tylko w wersji aplikacji dla pracowników. Funkcjonalność tego działu sprowadza się do stanu listy leków w magazynie oraz możliwości zamawiania oraz wydania ich. Rys. 4.1 Diagram przypadków użycia dla magazynu leków.
Przeglądanie recept jest grupą przypadków użycia dostępną również jedynie dla pracowników przychodni, dlatego też te funkcjonalności znajdują się tylko w wersji aplikacji dla pracowników. Grupa ta agreguje listę recept, wydanie recepty klientowi przez recepcjonistkę, oraz wypisanie recepty użytkownikowi przez lekarza. Rys. 4.2 Diagram przypadków użycia dla wydawania recept.
Najbardziej skomplikowaną częścią w naszym programie pod względem funkcjonalności jest system rejestracji wizyt. Występuje on w obu wersjach aplikacji klienckiej. W wersji dostępnej dla lekarza oraz recepcjonistki dostępna jest szersza funkcjonalność. Klient ma za zaś ograniczone możliwości. Funkcjonalności w ramach tej grupy to: - przeglądanie listy wizyt (dla konkretnego pacjenta, lekarza, lub wszystkich) - zatwierdzenie lub odwołanie istniejącej wizyty - rejestracja nowej wizyty Najciekawszym z tych przypadków użycia jest rejestracja wizyty, ponieważ przed dodaniem wizyty logika aplikacji musi sprawdzić wolne terminy, sale oraz lekarzy. Następnie użytkownikowi proponowany jest najbliższy termin, jednak z odpowiednim wyprzedzeniem czasowym. Rys. 4.3 Diagram przypadków użycia dla rejestracji wizyt.
5. Model systemu Diagram wdrożenia Zaprojektowana przez nas aplikacja bazuje na architekturze klient-serwer. We wspomnianej architekturze do komunikacji aplikacji klienckiej z bazą danych pośredniczy serwer aplikacji, który udostępnia metody odpowiadające za komunikacje oraz wymianę danych (metody biznesowe). Użyty model pozwala na odizolowanie logiki systemu od aplikacji klienckiej. Logika aplikacji może być umieszczona na serwerze aplikacji oraz w bazie danych. Dzięki temu aplikacja staje się bezpieczniejsza oraz wydajniejsza, podzielenie aplikacji na warstwy pozwala też na prostsze utrzymanie kodu. W naszym przypadku serwer aplikacji został zaimplementowany w technologii Java EE z wykorzystaniem kontenera serwletów Tomcat. W przypadku większego systemu po stronie bazy danych należałoby użyć również proceduralnego SQL, takiego jak PL/SQL lub T-SQL, co pozwoli na większą kontrolę danych, oraz znaczne zwiększenie wydajności wykonywanych zapytań. Przy stworzeniu wersji demonstracyjnej naszej aplikacji wystarczył jednak MySQL. Rys. 5.1 Diagram wdrożenia.
Rys. 5.2 Struktura projektu warstwy, MVP. Projektując oraz implementując naszą aplikację staraliśmy się bazować na popularnym wzorcu projektowym MVP. Wzorzec ten zakłada podział programu na warstwy: model, widok, prezenter. Z tego powodu serwer aplikacji i aplikacja kliencka przeznaczona dla pracowników były podzielone na warstwy. Aplikacja mobilna została wykonana w inny sposób ze względu na specyfikę systemu Android. Przykładem może być fakt, że za prezentację odpowiadają pliki XML
Diagram klas Najważniejszym elementem wszystkich wymienionych części aplikacji jest model biznesowy danych. Jest on wspólny dla wszystkich wersji, jednak wersja mobilna posiada zaimplementowaną jego okrojoną wersję, ponieważ nie używa wszystkich encji biznesowych projektu. Rys. 5.3 Diagram klas - model. Rys. 5.4 Diagram klas model relacje między encjami biznesowymi.
Kolejnym elementem wzorca projektowego jest prezenter. W naszym przypadku zawiera on serwisy biznesowe komunikujące się bazą danych lub serwerem aplikacji. Zadaniem serwisów jest również kontrola całej logiki biznesowej, spójności danych oraz bezpieczeństwa. Do obsługi funkcjonalności dla tych encji biznesowych zostały zaimplementowane interfejsy serwisów biznesowych. Encje zostały podzielone pomiędzy serwisy w taki sposób, żeby podział odpowiadał powiązaniom oraz podziałem funkcjonalności. Rys. 5.5 Diagram klas prezenter interfejs serwisów biznesowych. Powyższe funkcje operują na encjach biznesowych. Ważne jest jednak, że zwracają odpowiednio uzupełnioną encję. Jeśli zaistnieje potrzeba zwracana jest pełna encja biznesowa wraz z odpowiednimi powiązaniami. W przypadku pobierania wielu encji biznesowych postanowiliśmy zasugerować się użyciem tak zwanych RowEntity i nie doczytać pełnych danych. Na powyższym diagramie widać, że zaprojektowane interfejsy posiadają dla każdej ważnej encji funkcje: - GetAll Pobiera wszystkie encje biznesowe, nie uzupełnia wszystkimi danymi. Np. pobierając wszystkich lekarzy nie pobiera ich pokoi. - GetById Pobiera pełną encję biznesową o zadanym id. Uzupełnia wszystkie pod elementy. Np. Pobierając wizytę pobiera również pacjenta, lekarza, oraz pokój. Nie pobiera adresu pacjenta, ani jego kasy chorych. - GetEmpty Tworzy pustą encję biznesową. Metoda stworzona do inicjalizacji elementów po stworzeniu obiektu za pomocą konstruktora. - Update Dodaje/Edytuje element bazy danych. Użycie tej funkcji w aplikacji klienckiej wysyła zapytanie do serwera aplikacji. - Delete - Usuwa element z bazy danych. Użycie tej funkcji w aplikacji klienckiej wysyła zapytanie do serwera aplikacji.
Dalsza implementacja serwisów biznesowych jest już niezależna od stworzonych interfejsów i nie musi być tak silnie kontrolowana. Najważniejsze, by cała logika działania znajdowała się właśnie w serwisach. Na poniższym diagramie widać przykład dodatkowych metod jakie mogą być dodane do serwisu biznesowego. W tym przypadku są to metody do obsługi wizyt Rys. 5.6 Diagram klas prezenter przykładowe dodatkowe metody serwisów dla wizyt. Poniżej widać przykład dodatkowych metod klas dla recept. Prócz Pobrania recepty po identyfikatorze dodano jeszcze pobranie po identyfikatorze pacjenta. Dodana metoda ułatwi zaimplementowanie listy recept dla danego pacjenta przydatnej przy wydawaniu recept. Do serwisów DoctorsService oraz NursesService zostały dodane odpowiednie metody dodające recepty do bazy danych oraz zmieniające stan recepty na wydaną. Znajdują się one tam ponieważ są przypadkami użycia dla konkretnych aktorów. Rys. 5.7 Diagram klas prezenter przykładowe dodatkowe metody serwisów dla recept.
Rys. 5.8 Diagram klas podział aplikacji na warstwy. Na powyższym diagramie zaprezentowany został podział programu na warstwy. Widać oddzielone dwie komunikujące się ze sobą aplikacje. Obie aplikacje posiadają w warstwie modelu takie same encje biznesowe. W obu aplikacja warstwa modelu dziedziczy po tych samych interfejsach, których zadaniem jest wymiana danych między warstwami. Warstwa widoku czyli prezentacji danych użytkownikowi znajduje się tylko w aplikacji klienckiej. Serwer aplikacji zaś służy za warstwę dostępu do danych (Data Access Layer) oraz Serwis encji biznesowych.
Diagram stanów W naszym programie istnieją dwie encje biznesowe których stan naprawdę ma duże znaczenie. Są to: recepty wizyty. Rys. 5.9 Diagram stanów recepta. Stan recepty to wydana lub niewydana. Od tego stanu zależy czy receptę można wydać pacjentowi, czy może należy zablokować tę akcję. Wydane recepty zostają wciąż w bazie danych, ponieważ takie informacje są przychodni potrzebne do składania raportów. Rys. 5.10 Diagram stanów wizyta. Stan wizyty to wizyta zatwierdzona i niezatwierdzona. W przypadku niezatwierdzonej odpowiednio wcześniej wizyty należy zwolnić termin.
Diagram aktywności Najbardziej kłopotliwym dla nas samych w systemie okazała się rejestracja wizyty. Jako projektanci systemu powinniśmy wzajemnie rozumieć własne pomysły. Jednak okazało się, że taka funkcjonalność może zostać niejednoznacznie zrozumiała. Z pomocą przyszedł nam właśnie diagram oraz opis słowny, dopiero to pozwoliło na pełne zrozumienie problemu oraz naszego pomysłu na rozwiązanie go. Efektem końcowym rozważań został poniższy diagram prezentujący rejestrację wizyty. Ważnym punktem jest tutaj stan oczekiwanie na zatwierdzenie, którego długości nie ustaliliśmy i uważam, że powinna być konfigurowalna. Jak widać na diagramie, po rejestracji wizyty pacjent ma określoną długość czasu na zatwierdzenie jej. Wizyta zostaje odwołana jeśli pacjent wydał taką decyzję, lub jeżeli nie zatwierdził jej w wymaganym czasie. Dodatkowo możliwość odwołania wizyty ma lekarz i recepcjonistka. Jednak też musi zrobić to w określonym czasie. Rys. 5.11 Diagram aktywności wizyta.
Diagram sekwencji W naszym projekcie poszczególne serwisy muszą się ze sobą komunikować. Przykładową komunikację przedstawiono na diagramie poniżej. Głównym serwisem wykonującym zaprezentowaną operację rezerwację wizyty jest VisitsService. Komunikuj się on z PatientsService oraz DoctorsService w celu pobrania pacjenta i identyfikatora doktora. Pacjent przed pobraniem musi być zweryfikowany za pomocą numeru pesel. Rys. 5.12 Diagram sekwencji rezerwacja wizyty.
Rys. 5.14 Diagram sekwencji rezerwacja wizyty. Powyższy diagram prezentuje pobranie listy wizyt dla pojedynczego pacjenta. Widoczny jest tu podział programu na warstwy model-widok-prezenter oraz klient-serwer
Diagram przepływu danych Rys. 5.15 Diagram przepływu danych - Schemat przedstawia przepływ danych pomiędzy klientem/recepcjonistką, a systemem. Dla przykładu rejestracji wizyty użytkownika. Rys. 5.16 Diagram przepływu danych - Zamawianie leków oraz ich racjonowanie
6. Kwestie implementacyjne Pod uwagę braliśmy dwa (najoptymalniejsze do tego typu zadania) języki. Oba języki są językami wysokiego poziomu, z którymi mamy już duże doświadczenie, co pozwoli nam na skrócenie czasu implementacji. Te języki to C++ (dokładniej Qt) oraz Java. Pozwalają one na stworzenie MVP. Są to języki cross platformowe, które nie tylko możemy wykorzystać do implementacji aplikacji stand-alone, ale również i serwera. Oba doskonale nadają się do napisania aplikacji mobilnej. Zarówno w C++ jak i w Javie można pisać aplikacje na urządzenia mobilne z systemem Android, jednak lepsza znajomość języka Java oraz lepsza przenośność aplikacji przechyliła szalę na stronę Javy, dlatego też zrezygnowaliśmy z Qt. Do stworzenia modelu bazy danych wykorzystaliśmy MySQL Workbench, a jako serwer bazy danych użyliśmy MySQL Server. Środowiskiem aplikacji będzie Eclipse (dla platformy Android) oraz Eclipse EE dla pozostałej jej części. Ponadto zostaną wykorzystane następujące elementy: SDK dla Android OS, SVN dla Eclipsa, frameworki do mapowania obiektów (hybernate dla aplikacji na komputerze oraz orm-lite dla aplikacji mobilnej), do parsowania xml'i (simple-xml do parsowania xml'i otrzymanych z serwera) ponadto zostaną wykorzystane emulatory w celu przeprowadzenia symulacji działania aplikacji. Do komunikacji z bazą danych zostaną napisane odpowiednie serwisy, które zostaną zabezpieczone za pomocą SSL. Ponadto każdy użytkownik podczas logowania otrzyma indywidualny token, na czas trwania jego sesji. Aplikacja stand alone zostanie napisana natywnie w Javie. Ze względu na duża fragmentację w systemie Android, nie jest możliwe dokładne odwzorowanie graficzne naszej aplikacji mobilnej na każdej platformie Android, ze względu na różnice w SDK oraz rozdzielczość ekranu, widgety mogą się różnić. Większość elementów graficznych w Androidzie (layout) powstanie z wykorzystaniem xml'i. W ramach testów integralności systemów zostanie postawiony Jenkins, który pozwoli na testy jednostkowe dla naszego systemu. Testy będą składały się z testów jednostkowych oraz testów interfejsu Będziemy wykorzystywali framework Robotion, który pozwala nam na odwzorowanie gestów i ruchów użytkownika. Testy pozwolą nam na dostarczenie klientowi informacji dotyczących obecnego pokrycia kodu w zaistniałych problemach i błędach. Jenkins jest dobrym systemem do pilnowania buildów naszej aplikacji, ponadto pozwoli on dostarczać aktualne wersje naszych aplikacji w trybie release. Ponadto zostanie postawiony serwer apache tomcat do utrzymania komunikacji między aplikacją mobilną a bazą danych. Wszystkie środowiska Eclipse będą wykorzystywać tę samą wersję Javy.