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