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