Diagram wdrożenia

Diagram wdrożenia
Zaprojektowana przez nas aplikacja bazuje na architekturze client-server. W tej architekturze
w komunikacji aplikacji klienckiej z bazą danych pośredniczy serwer aplikacji, który udostępnia
metody biznesowe.
Użyty model pozwala na odizolowanie logiki aplikacji od aplikacji klienckiej. Logika aplikacji
może być umieszczona na serwerze aplikacji oraz w bazie danych. Dzięki temu aplikacja
stanie się bezpieczniejsza oraz wydajniejsza, podzielenie aplikacji na warstwy pozwala też na prostsze
utrzymanie kodu. W naszym przypadku serwer aplikacji został zaimplementowany w technologii
JavaEE 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. Przy tworzeniu naszej aplikacji wystarczył jednak MySQL.
Rys. 5.1 Diagram wdrożenia.
Diagram przypadków użycia
W naszej aplikacji występują 3 typy aktorów, są to:
•
•
•
Lekarze
Recepcjonistki
Klienci
Każdy z aktorów ma dostępne inne przypadki użycia w systemie, przy czym dla lekarzy
oraz recepcjonistek dostępna jest szersza wersja aplikacji, zaś dla klientów dostępna jest jedynie
wersja mobilna (znacznie uproszczona).
Przypadki użycia systemu można podzielić na 3 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 przychodni,
dlatego też te funkcjonalności znajdują się tylko w wersji aplikacji dla pracowników.
Funkcjonalność tego działu sprowadza się do listy leków w magazynie oraz możliwości
zamawiania/wydania ich.
Rys. 5.2 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. 5.3 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 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. 5.4 Diagram przypadków użycia dla rejestracji wizyt.
Diagram klas
Projektując oraz implementując naszą aplikację staraliśmy się bazować na popularnym wzorcu
projektowym MVP. 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.
Najważniejszym elementem wszystkich wymienionych 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.5 Diagram klas - model.
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.
Prezentowane funkcje operują na encjach biznesowych. Ważne jest jednak, że zwracają odpowiednio
uzupełnioną encję. Jeśli jest 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.
Diagram stanów
W naszym programie istnieją dwie encje biznesowe których stan naprawdę ma duże znaczenie. Są to:
•
•
recepty
wizyty.
Rys. 5.8 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
inforamcje są przychodni potrzebne do składania raportów.
Rys. 5.9 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.10 Diagram aktywności – wizyta.
Diagram sekwencji
Diagram przepływu danych