tytuł projektu: „informatyczny system obsługi...
TRANSCRIPT
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ści1. Streszczenie.............................................................................................32. Wstępny opis słowny..............................................................................43. Słownik pojęć z dziedziny problemu..................................................104. Analiza wymagań użytkownika...........................................................135. Model systemu......................................................................................21
Diagram wdrożenia .........................................................................................................21Diagram klas....................................................................................................................23Diagram stanów...............................................................................................................27Diagram aktywności........................................................................................................28Diagram sekwencji..........................................................................................................29Diagram przepływu danych.............................................................................................31
6. Kwestie implementacyjne....................................................................327. Podsumowanie i dyskusja krytyczna..................................................338. 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. 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 stwo-rzeniu obiektu za pomocą konstruktora.
• - Update – Dodaje/Edytuje element bazy danych. Użycie tej funkcji w aplikacji klienckiej wysyła za-pytanie 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ściNajbardziej 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 sekwencjiW 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.
7. Podsumowanie i dyskusja krytyczna
Wykorzystanie CI (integralności systemu) pozwoli nam na utrzymanie wysokiej jakości
kodu. Korzystanie z bibliotek *.jar oraz projektów zależnych w Androidzie pozwoli nam na
skrócenie czasu implementacji oraz odciążenie developerów od elementów mniej ważnych.
Wykorzystanie ostatnio wprowadzonej przez Google biblioteki support-lib.jar pozwoli na
zmniejszenie problemu fragmentacji w systemach Android, przez co aplikacje będą wyglądały
podobnie do siebie. Jednak wykorzystanie tylu bibliotek zależnych oraz tylu projektów zależnych,
niesie ze sobą ryzyko częstej potrzeby aktualizacji projektu, gdyż wspomniane biblioteki/projekty
mogą przestać być wspierane.
Zaletą wykorzystania wspomnianych elementów, jest stworzenie aplikacji niższym
kosztem . Wykorzystanie języka Java pozwoli na szybszą implementację, jednak aplikacje serwera
oraz aplikacje stand-alone nie będą tak szybkie jak w przypadku napisania jej w C++. Istnieje też
możliwość tego, iż nasze aplikacje będą zajmować dużą przestrzeń na dysku, ale dla obecnych
komputerów rozmiar aplikacji, czy też rozmiar bazy danych nie powinien stanowić problemu.
Dzięki zastosowaniu SSH do komunikacji przesyłane informacje są bezpieczniejsze.
Aplikację kliencką przychodnia może umieścić w Google Markecie (Google Play), żeby
każdy zwykły użytkownik, mógł pobrać - co wpłynie pozytywnie na zwiększenie zainteresowanie
przychodnia.
Istnieje ryzyko przeciążenia komunikacji między użytkownikami a elementem końcowym,
co może skutkować zawieszeniem się serwera aplikacji. Aby zmniejszyć ryzyko, zamierzamy
postawić zapasowy serwer, który zapewni Load-Balancing.
8. Wykaz materiałów źródłowych
„The Busy Coder's Guide to Android” Mark L. Murphy (Android development)
http://www.scrum.org/ (SCRUM information)
http://tomcat.apache.org/index.html (Tomcat)
http://developer.android.com/sdk/index.html (page for android developers)
http://www.hibernate.org/ (to communication with data base)
www.object-arts.com/downloads/papers/TwistingTheTriad.PDF (MVP)
http://simple.sourceforge.net/ (for xml)
http://ormlite.com/ orm lite for android
http://docs.oracle.com/javase/tutorial/ (java tutorial)
http://code.google.com/p/robotium/ (robotium for android testing)
https://wiki.jenkins-ci.org/dashboard.action (for CI – continous integration our application)
http://docs.oracle.com/javaee/ (Java EE)