VISOKA ŠKOLA STRUKOVNIH STUDIJA ZA INFORMACIONE TEHNOLOGIJE

PROJEKTOVANJE INFORMACIONIH SISTEMA

Projekat:

Modelovanje informacionog sistema

Medicinska ordinacija online

Predmetni nastavnik: Student:

prof. dr Aleksandar Kostić Vladimir Bučić 500/17

Beograd
Februar, 2020
Cilj ovog rada je planiranje projekta softwerskog sistema pod nazivom ‘Medicinska ordinacija
online’ oslanjajući se na primenu sistemske strukturne analize. Pristupom sistemske strukturne
analize i korišćenjem UML dijagrama možemo pripremiti i opisati sve sastavne elemente koje ova
aplikacija treba da sadži. Ovakav pristup nam omogućava lako i jednostavno iscrtavanje celog
projekta, kako bi se mogla razumeti njegova funkcija kao sistema u celini i kako bi se kasnije
ubrzao sam proces izgradnje projekta prilikom projektovanja i pravljenja same aplikacije. Prvi
korak u planiranju projekta ‘Medicinska ordinacija online’ je opisivanje uloga i funkcija sistema,
ovo najbolje možemo prikazati kroz dijagram dekompozicije i dijagrame nultog, prvog i drugog
nivoa, na taj način možemo razumeti sve bitne elemente kao više povezanih uprošćenih stavki
koje zajedno čine ovaj sistem tako što između sebe ostvaruju interakciju.
Prikaz planiranja arhitekture projekta može se početi i od druge strane, počevši od dijagrama
korišćenja i aktivnosti, na taj način se polazi od sitnijih delova i na kraju se dobija jedna celina. Mi
smo izabrali pristup od spolja ka unutra, drugim rečima od završnog dela sistema koji izgleda
uprošćeno i kroz dalje njegovo prikazivanje poprima kompleksniji oblik sa prikazom njegovih
najsitnijih elemenata.
Sledeća slika prikazuje online kliniku kao jednu veliku celinu sistema koja je okružena svim
vrstama uloga korisnika koje će biti prisutne u sitemu ‘Medicinska ordinacija online’. (slika 1.1)

Slika br: 1.1 – Dijagram nultog nivoa

Napomenućemo da prikazani dijagram na slici (slika 1.1) nacrtali smo koristeći besplatan online
program za modelovanje UML dijagrama i mnogih drugih dijagrama, draw.io, i ostali dijagrami u
ovoj dokumentaciji biće iscrtani pomoću već pomenutog programa.

2
Na dijagramu nultog nivoa uočavamo da se sistem ‘Medicinska ordinacija online’ sastoji od četiri
vrste korisnika, a to su: Administrator, Lekar, Medicinsko osoblje ili sistemski korisnik, i na kraju
sam Pacijent zbog koga sam ovaj sistem i postoji. Svi ovi korisnici u određenim situacijama imaju
neku interakciju između sebe bilo neposredno ili posredno kroz neku njihovu akciju.

Opisaćemo neke od funkcija za svaku ulogu koju određeni korisnik poseduje za sam naziv svoje
uloge:
Sistemski Administrator:
Upravlja informacijama o klinici, menja/dodaje klinike
Upravlja rasporedom lekara, pravi izmene
Upravlja lekarima menja/dodaje/briše
Upravlja rasporedom zakazanih pregleda menja/dodaje/briše
Upravlja podacima pacijenata menja/dodaje/briše
Upravlja izveštajima
Upravlja korisničkim ulogama

Sistemski korisnik:
Upravlja rasporedom lekara, pravi izmene
Upravlja rasporedom zakazanih pregleda menja/dodaje/briše
Upravlja podacima pacijenata menja/dodaje/briše

Lekar:
Izvršava/overava preglede
Izdavanje terapija
Dodavanje izmena baze podataka lekova
Zadavanje dijagnoze

Pacijent:
Zahteva pregled/rezervaciju istog
Izvršava plaćanje
Pregled izveštaja o svojoj terapiji i lekovima
Ovo su samo neke od bitnih funkcija korisnika koje pominjemo i prikazujemo u dijagramima.
Možemo napomenuti i to da ova aplikacija može imati i drugačije elemente zavisno od ugla sa
koga gleda osoba koja radi planiranje projekta, ali suština kod aplikacija kao što je ‘Medicinska
ordinacija online’ ili bilo koja druga aplikacija za zakzivanje pregled je ista.
Pacijent zahteva pregled, a sa druge strane medicinsko osoblje ili recepcija/u nekim slučajevima
call centar proverava trenutni raspored lekara i već postojećih zakazanih pregleda. Pored samog
zahteva za svoj pregled, pacijent je u mogućnosti da postavi određena pitanja u vezi klinike/lekara
ili svog budućeg/prošlog pregleda, i sa tim završi svoju interakciju bez da zakaže pregled. U istom
trenutku sistemski korisnik koji komunicira sa pacijentom je dužan da odgovori na njegova pitanja,
eventualno proveri informacije u bazi podataka pacijenata, izda račun korisniku za budući ili prošli
pregled. Ovim kratkim opisom već vidimo komunikaciju između ove dve uloge. Ovde smo
pomenuli i raspored lekara, sa kojim kasnija interakcija sa pacijentom sledi ako je pacijentu
zakazan pregled i pacijent je potvrdio svoj dolazak.

3
Lekar pre samo pregleda pacijenta traži od sistema/baze podatke o pacijentu, zatim pregleda
pacijenta, izdaje dijagnozu, daje terapiju, od pacijenta može zahtevati dodatne laboratorijske
analize i druge testove.
Pacijent ima mogućnost da izabere način plaćanja za svoj pregled koristeći sistem za online
plaćanje.
Na kraju imamo administratora celog ovog sistema, koji ima dozvolu da upravlja svim elementima
koji čine sistem, čak ima i mogućnost da kreira nove klinike, menja informacije o klinici, dodaje
nove lekare, menja njihove plate, pregleda transakcije u sistemu, kao i rasporede i zakazivanja.
Neke funkcije korisnika prikazane su strelicama koja vode ka njima samim, kao i sitemu online
klinike koji je u sredini, ovo je urađeno kako ne bi prikazivali zasebne linije koje imaju sličnu
funkciju.
Kada smo opisali bitne i veće celine samog sistema, sada možemo zaviriti u središnji deo ili centar
aplikacije koja će nam otkriti detaljniji prikaz pomenutih funkcija.

Slika br: 1.2 – Dijagram prvog nivoa

Rasčlanjivanje opisanih elemenata dobijamo dijagram prvog nivoa (slika 1.2). Ovde već možemo
videti koje sve baze podataka postoje u sistemu. Ovim bazama pristupaju korisnici direktno ili
preko određenih procesa.

4
Pacijent kaza pristupi online sistemu za zakazivanje, može da zatraži podatke o njegovom
lečenju/pregledima/analize, na taj način pacijent izvršava posredni pristup bazi podataka
pacijenata, preko sistemskog korisnika, koji može da mu dostavi te podatke na upit ili sama
aplikacija može to uraditi umesto njega. Ovaj deo je prikazan u dijagramu kao
„Zakazivanje/Informisanje Online“, ovde pacijent može zatražiti i pregled. Ovaj deo možemo
proširiti i posebnom celinom gde lekar pacijentu izdaje lekarsko uverenje ako je to on zatražio, ali
odlučili smo se da prikažemo celinu naplate lekarskog pregleda „Plaćanje Platni procesor Online“,
pošto traženje lekarskog uverenja je slično pregledu, pacijent mora biti pregledan, isto važi i za
kontrolni pregled, dok je plaćanje deo za sebe. Kada sistemski korisnik izda račun pacijentu, on
može izvršiti plaćanje na više različitih načina, online/karticom/wire transferom, zavisno koje
opcija platni procesor koji klinika koristi i isti podržava. Sve transakcije o uplatama skladište se u
bazu transakcija, ovo može biti lokalna baza ordinacije ili baza podataka na cloud-u, kojoj sa
druge strane administrator ima direktan pristup kako bih mogao da pregleda stanje kroz razne
transakcione izveštaje. Deo koji predstavlja zakazivanje pregleda, ima pristup bazama već
postojećih zakazanih pregleda i lekara, pošto sistemski korisnik pre upisa novog zahteva za
pregled, mora da pogleda postojeće stanje ili eventualno nešto izmeni ili oduzme ako je neki od
pacijenata otkazao pregled. U nekom sistemu ovaj deo bi mogao da se poveže i sa lekarom, gde
bi lekar dobio obaveštenje o angažovanju svog vremena za predstojeći pregled. Deo „Pregled
pacijenta/Određivanje terapije/dijagnoze“ je sam po sebi jasan, pacijent i lekar učestvuju u ovom
procesu tako što verbalno razmenjuju informacije, ili lekar pregleda karton pacijenta, pokušava
pregledom da utvrdi dijagnozu. Na samom kraju pregleda lekar izdaje terapiju/daje lekove ili
pacijentu daje uput na dodatna ispitivanja i analize. Ovde lekar pristupa bazi
dijagnoza/procedura/infekcija koja je u tom trenutku dostupna, a sa druge strane može i pretražiti
već postojeće izveštaje o dijagnostikovanom problemu ili bolesti, tako što pristupa bazi sa
izveštajima. Spisak lekova koje može prepisati pacijentu zajedno sa receptom, mora zabeležiti u
delu „Evidentiranje rezultata pregleda/testova“, zajedno sa ostalim rezultatima. Lekar u ovom
trenutku radi sa više baza, a to su baza pacijenata, baza lekova i baza recepata, pošto je vrlo
bitno imati uvid kom pacijentu koji recept je izdat i sa kojim medikamentima. Izveštajima pregleda
takođe može pristupiti medicinsko osoblje kako bi kasnije moglo pacijentu da obezbedi iste, ili
prilikom komunikacije pacijenta bude u toku radi narednih pregleda. Administrator je opet većinom
deo za sebe pošto je najnezavisnija uloga sistema samim tim što upravlja celim sistemom preko
„Upravljanje Online klinikama“, gde može menjati sve podatke o klinici,
pacijentima/lekarima/medicinskom osoblju, što znači da ima pristup svim bazama podataka koje
se tiču ovog dela. Sa druge strane Administrator ima pristup izveštajima transakcija koristeći bazu
platnog procesora u delu „Plaćanje Platni procesor Online“, i može izvršiti različite upite za
generisanje izveštaja.
Još detaljniji prikaz pojedinih funkcionalnosti možemo prikazati i raščlaniti u dijagramu drugog
nivoa.
Razdvojili smo deo „Zakazivanje/informisanje Online“ na više manjih elemenata koji čine tu celinu.
Pošto pacijent pristupa online sistemu pored direktne komunikacije sa medicinskim osobljem,
može da upravlja svojim korisničkim interfejsom gde može pretraživati i generisati izveštaje o
svojim dosadašnjim pregledima u izabranoj medicinskoj ordinaciji. Tu je takođe sam proces
zakazivanja/potvrde kao i komunikacija između medicinskog osoblja i pacijenta putem online
aplikacije. Komunikacija ovde postoji zato što pacijent može da se samo konsultuje sa
medicinskim osobljem, zatraži određene informacije koje ne moraju biti deo zahteva pregleda i
rezervacije, dok sa druge strane kada je u pitanju rezervacija pregleda, sistemski korisnik mora

5
prvo da proveri raspored lekara, kog dana radi koji lekar i u kojoj smeni, takođe mora da proveri i
bazu podataka sa već postojećim zakazanim pregledima, među kojima može da doda novi pristigli
zahtev za pregled, ukoliko pacijent potvrdi pregled (slika 1.3).

Slika br: 1.3 – Dijagram Drugog nivoa Zakazivanje

Naravno, nakon samog zakazivanja pregleda i potvrde, sledi pregled u kome učestvuju pacijent i
lekar koji je odabran da izvrši zdravstveni pregled pacijenta. Na samom početku lekar pristupa
bazi pacijenata kako bih saznao informacije o pacijentu ako je pacijent već posećivao ordinaciju
ili ako nije onda samo lične podatke o pacijentu koje je pacijent prosledio sistemskom korisniku.
Pacijent naravno saopštava lekaru svoje tegobe, a lekar vršri ispitivanje/pregled, nakon čega
može da zada dijagnozu, terapiju, spisak lekova, uputi pacijenta na dodatne analize preglede.
Dijagnoze kao i ostale atribute pregleda, lekar dobavlja iz baze podataka koja se takođe koristi
prilikom evidentiranja rezultata pregleda. Kada je pacijent poslat na dodatne testove i analize,
mora da da tražene uzorke koji se kasnije evidentiraju (slika 1.4).

6
 Slika br: 1.4 – Dijagram Drugog nivoa Pregled pacijenta/Određivanje terapije/dijagnoze

Prilikom evidentiranja podataka lekar se služi sa nekoliko baza podataka, pošto je potrebno
upisati i dobaviti različite informacije koje su značajne za sam pregled, a i same su proistekle od
njega. Vrlo je bitno da se prilikom evidentiranja lekova proverava informacija o dijagnozi jer na
osovnu nje se izdaju lekovi, čiji spisak ili terapiju lekova pacijent može da zatraži od medicinskog
osoblja pre ili posle plaćanja računa za izvršeni medicinski pregled ili laboratorijsku analizu.
Spisak lekova ide zajedno sa receptop koji je povezan sa pacijento pošto je za kliniku veoma
bitno čuvanje podataka o receptu, ko ga je izdao i kom pacijentu sledi recept. Upisuju se i rezultati
pregleda koje kasnije, pored spiska lekova, pacijent može da zatraži od sistemskog korsnika
(slika 1.5).

Slika br: 1.5 – Dijagram Drugog nivoa Evidentiranje rezultata pregleda/testova

Kada se sam pregled završi i svi rezultati upišu pacijentu se izdaje račun, sistemski korisnik radi
taj posao koristeći aplikaciju unutar klinike koja izračunava cenu njihovih usluga koje je pacijent
kao korisnik konzumirao. Pacijent ima mogućnost da izabere način plaćanja paypal/kartica/wire
transfer i izvrši plaćanje. Nakon unošenja podataka o plaćanju, platni procesor proverava
podatke/ispituje validnost kartice i stanje na računu, uplata se izvršava i upisuje u bazu sa
transakcijama, nad kojom administrator može izvršiti različite vidove pregleda i generisanja
izveštaja (slika 1.6).

7
 Slika br: 1.6 – Dijagram Drugog nivoa Plaćanje Platni procesor Online
Na samom kraju imamo dijagram koji je namenjen delu koji prikazuje funkcije administratora. Ovaj
dijagram je vrlo jednostavan i jasan, kao što smo prethodno pomenuli više puta, administrator ima
svaku dozvolu nad sistemom, na ovoj slici je to detaljno prikazano. (slika 1.7)

Slika br: 1.7 – Dijagram Drugog nivoa Upravljanje Online klinikama

Kada smo rasčlanili sve bitne delove na sitnije stavke i prikazali iz čega se sve sesatoje slike svih
pomenutih elemenata usko povezanih, dolazimo do jednog velikog stabla, a to je dijagram
dekompozicije (slika 1.8).

8
 Slika br: 1.8 – Dijagram Dekompozicije

Specifikacija zadaka za ovaj projekat takođe zahteva prikaz pet slučajeva korišćenja ili use case
dijagrama zajedno sa dijagramima aktivnosti za svaki od prikazanih dijagrama korišćenja. Na
pokečtku ćemo prikazati opšti dijagram korišćenja koji uključuje sve četiri vrste korisnika sa
njihovim funkcijama koje mogu da vrše u sistemu. Svim korisnicima je naravno zajedničko
prijavljivanje na sistem i promena lozinke u slučaju da je izgube, ovo je prikazano središnjem
delu, na sledećoj slici (slika 1.9). Pacijent ima mogućnost da koristi sistem kroz plaćanje,
zahtevanje pregleda, generisanje svojih rezultata pregleda. Administrator naravno ima
mogućnost da upravlja čitavim sistemom i to je na dijagramu prikazano tako što preuzima neke
funkcionalnosti koje su namenjene sistemskom korisniku. Sistemski korisnik upravlja pregledima,
rasporedima i zakazivanjima kao i formiranju računa i njegovom izdavanju, dok sa druge strane
lekar ili doktor zadaje dijagnozu nakon pregleda, upisuje u bazu rezultate i terapije sa lekovima,
to jest recepte.

9
 Slika br: 1.9 – Dijagram Korišćenja Opšti
Za prikazani slučaj korišćenja iznad (slika 1.9), prikazaćemo i odgovarajući dijagram aktivnosti.
Dijagram počinje prijavljivanjem korisnika na sistem, a zatim se proveravaju uloge ili dozvole
korisnika, zavisno od toga korisnik može da primenjuje i koristi odgovarajući korisnički interfejs
koji je namenjen njegovoj ulozi, naravno admin ima najpotpuniji korisniči interfejs kojim upravlja
svim delovima u aplikaciji. Pacijent nakon pregleda izvršava plaćanje, zatim pregleda svoje
rezultate kasnije u aplikaciji, lekar izdaje dijagnozu i evidentira preglede sa rezultatima, a
sistemski korisnik ili medicinsko osoblje, zakazuje pregled i izdaje račun, i na kraju što je
zajedničko za sve korisnike, mogu da se odjave sa sistema. (slika 1.10)

Slika br: 1.10 – Dijagram Aktivnosti Opšti

10
Sledeći dijagram slučaja korišćenja koji ćemo prikazati je deo koji predstavlja zakazivanje samog
pregleda. Pacijent šalje upit ili zahtev za pregled, pre toga može da izabere kliniku ili da se
informiše o lekarima koji rade u toj klinici, kada sistemski korisnik pogleda i eventualno izmeni
rasporede lekara i pregleda, javlja sistemskom korisniku za pregled i traži potvrdu da korisnik
potvrdi dolazak na pregled. (slika 1.11)

Slika br: 1.11 – Dijagram Korišćenja Zakazivanje pregleda

Dijagram aktivnosti počinje isto kao prethodni prikazani dijagram aktivnosti (slika 1.10), a to je
prijavljivanje korisnika na sistem. Proverava se uloga, pacijent ima mogućnost da izabere kliniku,
pregleda lekare i pošalje zahtev za pregled, kada sistemski korisnik napravi rezervaciju za budući
pregled, traži se potvrda od pacijenta. Naravno oba korisnika se na kraju odjavljuju sa sistema
ako nemaju drugog posla na sistemu (slika 1.12).

Slika br: 1.12 – Dijagram Aktivnosti Zakazivanje pregleda

11
Posle zakazivanja pregleda, naravno sledi i sam pregled, ovde učestvuju dve vrste korisnika,
lekar i naravno pacijent koji prvo zahteva pregled. Lekar izvršava pregled i evidentira rezultate
pregleda i izdaje recept sa lekovima koji se u bazu podataka upisuje zajedno sa podacima
pacijenta. Ovde je samo prikazan element gde korisnik pacijent, ima opciju plaćanja, koju smo
prethodno spomenuli i kod zakazivanja pregleda (slika 1.13).

Slika br: 1.13 – Dijagram Korišćenja Pregled

Dijagram aktivnosti za pregled pacijenta nije mnogo komplikovan. Sa jedne strane prijavljeni
korisnik koji je lekar, ima odgovarajući korisnički interfejs sa svim potrebnim elementima za
dobavljanje liste mogućih dijagnoza, sličnih slučajeva, kao i lekova, i naravno može da upiše
rezultate trenutnog pregleda, pacijent nakon pregleda samo izvrši plaćanje koje se takođe
evidentira u bazu (slika 1.14).

Slika br: 1.14 – Dijagram Aktivnosti Pregled

12
U sledećem dijagramu na slici (slika 1.15), predstavićemo ulogu korisnika prilikom plaćanje, a
detaljniji pregled biće prikazan na dijagramu aktivnosti (slika 1.16). Dijagram korišćenja je
jednostavan, nakon izdavanja računa pacijent ima mogućnost da izabere plaćanje, i plati račun,
pri čemu se njegov račun proverava da li je validan i da li ima dovoljan izvnos novca na njemu
kako bi se platio pregled.

Slika br: 1.15 – Dijagram Korišćenja Plaćanje

U dijagramu aktivnosti, pacijent može da izabere način plaćanja, na početku smo to pomenuli,
aplikacija može da podržava više načina plaćanja, karticom, wire, paypal itd. Kada izabere način
plaćanja, korisnik unosi svoje podatke koje odgovaraju tom načinu plaćanja, u slučaju da nešto
od podataka nije u redu ili da nema dovoljno novčanih sredstava na računu, korisniku će ponovo
biti prikazan deo za biranje načina plaćanja u kome može da pokuša sa nekim drugim načinom
plaćanja, a zatim plati račun i tako završi svoju aktivnost. Sistemski korisnik naravno samo izdaje
račun (slika 1.16).

Slika br: 1.16 – Dijagram Aktivnosti Plaćanje

13
Poslednji slučaj korišćenja ostavili smo za administratorovo upravljanje sistemom. Ovde vidimo
veliki broj elemenata aplikacije kojima administrator može da upravlja i da ih kontroliše. Od
pregleda plaćanjima pa do upravljanju informacija o platama lekara, kao i dodavanje ordinacija i
izmena postojećih. Administrator naravno može da dodaje nove korisnike, koji mogu biti
lekari/pacijenti/sistemski korisnici (slika 1.17).

Slika br: 1.17 – Dijagram Korišćenja Upravljanje sistemom

Dijagram aktivnosti koji odgovara administratorovim upravljanjem sistemom prikazan je na
sledećoj slici (slika 1.18). Administrator ima poseban deo gde može da upravlja plaćanjima, to
jest da pregleda transakcije, ovo je namerno ovako izdvojeno, pošto plaćanje nekad može biti i
zasebna aplikacija koja administratoru nudi mogućnost generisanja izveštaja transakcija ili da se
podaci transakcija čuvaju i u bazi same aplikacije. Dodavanjem nove ordinacije, može da doda i
nove radnike za tu ordinaciju, tu spadaju doktori/sistemski korisnici, to je deo u kome može da
upravlja korisnicima za izabranu kliniku. Administrator u svom moćnom korisničkom sistemu ima
mogućnost upravljanja pacijentima, pri čemu može da pregleda/menja podatke, mada prema
novom zakonu o zaštiti elektronskih podataka pacijenata koji su evidentirani u nekom softweru
ova mogućnost ne mora biti dostupna administratoru, već samo zaposlenima u klinici i
pacijentima.

14
 Slika br: 1.18 – Dijagram Aktivnosti Upravljanje sistemom

Sad kada vidimo sve delove funkcija projekta koji predstavljaju interakciju između korisnika i
njihovih uloga, možemo zamisliti koji nam sve objekti ili klase trebaju za izradnju jedne ovakve
aplikacije, to možemo prikazati u dijagramu klasa (slika 1.19). Pošto je ovo veći projekat i ima
više sastavnih elemenata koji se oslanjaju jedan na drugi, sam prikaz dijagrama klase izgledaće
kompleksno, pošto je na njemu potrebno prikazati i relacije, to jest povezanosti između klasa. Za
definisanje osobina klasa i njenih delova, ili njihovih imena, koristićemo nazive na engleskom
jeziku, zato što ovaj deo projekta treba biti razumljiv svim članovima razvojnog tima koji rade na
izradi ovog softwera, i često u timu mogu da budu ljudi koji govore različite jezike.

15
 Slika br: 1.19 – Dijagram Klasa

Tema ovog rada je takođe prikazivanje i opis jednog primera dijagrama sekvenci ili interakcije. Za
naš primer opisaćemo i pokazati prijavljivanje koisnika na sistem, u ovom slučaju administratora.
Dijagram sekvenci pocinje tako što se administrator prijavljuje na sistem koristeći login stranicu ili
stranicu za prijavljivanje. Ovde postoje dva slučaja, korisnik možda unese netačne podatke i u
tom slučaju može da traži resetovanje lozinke, tj da je zaboravio lozinku, ili je uneo ispravne
podatke. Kada korisnik traži povratak lozinke šalje mu se email za zahtev resetovanje lozinke i
postavlja mu se sigurnosno pitanje, ako odgovori ispravno onda menja lozinku i ulazi u sistem. U
drugom slučaju uneo je ispravne podatke koji se kasnije validiraju, sistem proverava da li korisnik
sa tim korisničkim imenom postoji u bazi i da li uneta lozinka odgovara hašovanoj lozinci i
password salt-u u bazi, ako je sve uredu sesija se pravi i beleži vreme ulaza u bazu, a korisniku

16
se pravi token i dozvoljava pristup sadržaju aplikacije. Korisnik kad završi sa poslom može da se
odjavi, time se sesija gasi i dijagram sekvenci se završava. (slika 1.20)

Slika br: 1.20 – Dijagram interakcije/sekvenci – prijavljivanje na sistem

Na sledećoj slici biće prikazan dijagram komponenti (slika 1.21). Ovaj diagram služi da bi opiao
servisno orijentisanu strukturu aplikacije „Medicinska ordinacija online“, drugim rečima, opisuje
povezivanje fizičkih komponenti u sistemu, zahtevanih interfejsova, portova i veza izmedju
sledećih komponenti: Klinika ili ordinacija, Pacijent, Doktor, Sistemski korisnik, Zakazivanje i
Raspored. Osobine ovog komponentnog dijagrama su: Prikazivanje modela komponenti za
aplikaciju „Medicinska ordinacija online“, modelovanje šeme baze podataka, medelovanje
izvršnih tela sistema, modelovanje izvornog koda sistema.

17
 Slika br: 1.21 – Dijagram Komponenti

Za prikaz fizičih uređaja i prikaz mreže sitema i međusobne komunikacije izmedju fizičkih uređaja
koristimo dijagram razmeštaja (slika 1.22). U ovom dijagramu imamo nekoliko celina: deo gde su
obični korisnici ili pacijenti, sistemski korisnici i lekari, server i admin kao telo koje ima direktan
ipristup serveru i bazi podataka. Pacijenti pristupaju određenoj klinici, njenoj web aplikaciji
koristeći računare ili telefone, a sistemski korisnici iz klinike koristeći svoje računare pristupaju
bazi i serveru koji se nalazi na udaljenom računaru koji drži server sa bazom podataka.
Administrator sa druge strane može da pristupi direktno fiziči serveru ili remote sa udaljene
lokacije.

18
 Slika br: 1.22 – Dijagram Razmeštaja

Za dijagram stanja prikazaćemo tok jednog zahveta za pregled od strane pacijenta. Pre samog
zakazivanja pregleda, pacijent mora prvo da se informiše o lekarima/pregledu i slobodnom
rasporedu lekar i već postojećih rezervisanih termina, sistemski korisnik proverava rasporede i u
komunikaciji sa pacijentom dogovaraju termin, koji korisnik treba da potvrdi putem telefona ili
koristeći aplikaciju. Kada je to urađeno sistemski korisnik upisuje rezervaciju i lekar dobija
obaveštenje o zakazanom pregledu kod njega. Pacijent dolazi na pregled ili ne, ako pregled bude
izvršen, lekar upisuje rezultate pregleda i pacijent izvršava plaćanje (slika 1.23).

Slika br: 1.23 – Dijagram Stanja

19
Prikaz i uređenje strukture pojedinih celina i elemenata u aplikaciji prikazaćemo koristeći dijagram
paketa, koji tome služi (slika 1.24). Dijagram paketa može da pokaže strukturu kao i
zavisnost/oslanjanje modula, pokazivaćuji različite aspekta sistema u više slojeva. Strukturu naše
aplikacije podelili smo na pet veća dela koji se svi oslanjaju na nekakav Gui koji koriste u
prikazivanju i korišćenju svojih funkcija. Pacijent može da koristi online sistem za zakazivanje
pregleda koji je predstavljen kao korisniči interfejs sa input poljima i tabelama sa rasporedom
lekara i slobodnih termina, naravno u korisničkom interfejsu prikazuju se podaci/informacije koje
su izčitane iz baze podataka koja je posebna celina, u kojoj se takođe mogu upisati informacije o
plaćanju koje pacijent može da izvrši. Plaćanje je ovde prikazano kao poseban sloj kome može
pristupiti pacijent kao korisnik koji mož da konzumira usluge plaćanja na platnom procesoru, koji
takođe ima neki korisnički interfejs gde pacijent može izabrati ponuđene opcije plaćanja i td. U
zadnjem delu imamo i sam pregled pacijenta koji može da sledi nakon zakazivanja pregleda, gde
vidimo lekara i pregled koji sam lekar upisuje u bazu koristeći korisnički interfejs tome namenjen.

Slika br: 1.24 – Dijagram Paketa

Na sledećoj slici (slika 1.25) prikazaćemo IDEF1X dijagram koji u suštini izgleda kao dijagram
klase, sadrži sve objekte ili možemo reći bazne tabele koje će biti potrebne za izgradnju aplikacije
„Medicinska ordinacija online“. Na dijagramu IDEF1x prikazujemo glavne i strane ključeve tabela
kao i povezivanje tabla direktno ili preko poveznih tabela, kao što je to na primer „ClinicMembers“
tabela, ovde koristimo poveznu tabelu zato što jedna klinika može sadržati više različitih korisnika
kao njenih radnika, dok jedan korisnik može raditi za više klinika, ali u nekom drugom sistemu
ovo možemo i ograničiti da jedan korisnik može raditi samo u jednoj ordinaciji, znači ovo je stvar
dogovora ili zahteva. Slična tabela je i „UserRoles“, jedan korisnik može imati više različitih uloga.
Ostale tabele su same po sebi jasne, u glavnim tabelama gde jedan isti rekord može da se pojavi

20
samo jednom on je logično primarni ključ u svojoj tabeli, dobar primer je tabela „Clinic“, zato što
na jednoj lokaciji može da se nalazi samo jedna ordinacija ili centar, a ne više njih.

Slika br: 1.25 – Dijagram IDEF1X

21