UNIVERZITET ZA POSLOVNI INŽENJERING I MENADŽMENT BANJA LUKA

Diplomski studijski program Računarske nauke

Diplomski rad
PROJEKTOVANJE INFORMACIONOG SISTEMA ZASNOVANOG NA
OBJEKTIMA I DIZAJNU POMOĆU UML-A KROZ PRIMJER

Mentor: prof. dr Dušan Malbaški

BANJA LUKA, JANUAR 2015. STEFAN MIŠANOVIĆ

“Pod moralnom i krivičnom odgovornošću izjavljujem da sam ja autor ovog rada te
sam upoznat da sam, ukoliko se utvrdi da je rad plagijat, odgovoran za štetu
pričinjenu Univerzitetu za poslovni inženjering i menadžment, kao i autoru
originalnog rada.”
 SAŽETAK

Diplomski rad se bavi analizom postojećeg informacionog sistema „eDnevnik“, koji

sam dizajnirano i implementirao u Srednjoškolski centar „Ljubiša Mladenović“ u Banjoj
Luci 2013. godine. Srednjoškolski centar „Ljubiša Mladenović“ je radi poboljšanja
kvaliteta obrazovanja, precizne evidencije, brzog i lakog pristupa informacijama kako
roditeljima, tako i profesorima uveo elektronski dnevnik. Sistem „eDnevnik“ takođe
pomaže rukovodstvu škole da uradi efikasnu analizu, te na osnovu dobijenih zaključaka
poboljšava i unapređuje proces edukacije. Analiza sistema je vršena pomoću UML
dijagrama, a korišćeni alati su Microsoft Visio i IBM Rational Rose XDE. Na osnovu ove
analize se olakšavaju svi budući koraci u nadograđivanju i održavanju sistema.
Ključne riječi: projektovanje, sistem, objekti, dizajn, UML.

SUMMARY

A bachelor's thesis is about analysis existing information system eDnevnik, which I

made for high school “Ljubiša Mladenović“ in Banja Luka in 2013. Because of quality of
education, accurate records, fast and easy access to informations both parents and teachers,
high school “Ljubiša Mladenović“ installed eDnevnk. The eDnevnik system also helps the
school management to do effective analysis and on the basis of the obtained improves and
enhances the education process. Diagrams used for the system analysis are made in UML.
Softwares used are Microsoft Visio and IBM Rational Rose XDE. On the basis of this
analysis all future steps are facilitated in upgrading and maintaining the system.
Key words: developing, system, objects, design, UML.
SADRŽAJ

1 UVOD U UML ............................................................................................................... 1

1.1 Modelovanje sistema ............................................................................................... 2
1.2 Komponente UML-a ................................................................................................ 4
1.2.1 Dijagram klasa ................................................................................................. 4
1.2.2 Fizički dijagrami (dijagram komponenti i dijagram razvoja) .......................... 6
1.2.3 Dijagram objekata .......................................................................................... 10
1.2.4 Dijagram aktivnosti ........................................................................................ 11
1.2.5 Dijagram stanja .............................................................................................. 13
1.2.6 Dijagram slučaja upotrebe (Use case diagram) ............................................ 15
1.2.7 Dijagrami interakcija ..................................................................................... 19
1.2.8 Dijagram saradnje .......................................................................................... 19
1.2.9 Sekvencijalni dijagram ................................................................................... 20
2 ANALIZA INFORMACIONOG SISTEMA ............................................................... 23
2.1 Identifikacija posla ................................................................................................. 23
2.2 Analiza i specifikacija korisničkih zahtjeva .......................................................... 24
2.3 Analiza domena ..................................................................................................... 38
2.3.1 Analiza intervjua poslovnog procesa ............................................................. 38
2.3.2 Razvijanje dijagrama klasa ............................................................................ 38
2.4 Analiza i razvoj sistema ......................................................................................... 42
2.5 Analiza slučajeva upotrebe .................................................................................... 43
2.6 Komponente sistema .............................................................................................. 44
3 DIZAJN SISTEMA, IZGLED I ZAŠTITA .................................................................. 45
3.1 GUI Dizajn ............................................................................................................. 45
3.2 Zaštita ..................................................................................................................... 52
4 ZAKLJUČAK ............................................................................................................... 54
LITERATURA .....................................................................................................................55
SADRŽAJ SLIKA
Slika 1.1 Model vodopada ............................................................................................... 3
Slika 1.2 Primjer klase ..................................................................................................... 4
Slika 1.3 Primjer asocijativnosti ...................................................................................... 5
Slika 1.4 Primjer generalizacije ....................................................................................... 6
Slika 1.5 Primjer čvorova i konekcije u dijagramu razvoja ............................................ 7
Slika 1.6 Dijagram razvoja sa tri računara, štampačem, aplikacionim serverom, internet
priključkom i bazom podataka ........................................................................................ 8
Slika 1.7 Prikaz grafičke komponente na dijagramu ....................................................... 8
Slika 1.8 Primjer dijagrama komponenti ......................................................................... 9
Slika 1.9 Kombinovani dijagram razvoja i dijagram komponenti ................................ 10
Slika 1.10 Primjer dijagrama objekata .......................................................................... 11
Slika 1.11 Dijagram aktivnosti ...................................................................................... 12
Slika 1.12 Primjer dijagrama aktivnosti ........................................................................ 13
Slika 1.13 Grafički prikaz dijagrama stanja objekta...................................................... 14
Slika 1.14 Primjer procedure upisa studenta na fakultet korišćenjem dijagrama stanja 15
Slika 1.15 Glavne komponente dijagrama slučaja upotrebe ......................................... 16
Slika 1.16 Primjer dijagrama slučaja upotrebe .............................................................. 17
Slika 1.17 Log aktivnosti slučaja upotrebe.................................................................... 18
Slika 1.18 Primjer extend veze ...................................................................................... 19
Slika 1.19 Osnovni elementi dijagrama saradnje .......................................................... 20
Slika 1.20 Dijagram saradnje na primjeru narudžbe ..................................................... 20
Slika 1.21 Primjer sekvencijalnog dijagrama ................................................................ 22
Slika 1.22 Objekti za vrijeme izvršenja sekvence ......................................................... 23
Slika 2.1 Dijagram slučaja upotrebe za profesora ......................................................... 25
Slika 2.2 Dijagram slučaja upotrebe za razrednike ....................................................... 26
Slika 2.3 Dijagram slučaja upotrebe za vannastavno osoblje........................................ 27
Slika 2.4 Dijagram slučaja upotrebe za roditelje ........................................................... 28
Slika 2.5 Dijagram slučaja upotrebe za sistem administratora ...................................... 29
Slika 2.6 Način interakcije između administratora i baze podataka .............................. 30
Slika 2.7 Dijagram stanja za unos novog odjeljenja...................................................... 32
Slika 2.8 Dijagram aktivnosti za modifikovanje ocjene ................................................ 33
Slika 2.9 Dijagram komponenti veb aplikacije ............................................................. 34
Slika 2.10 Dijagram komponenti desktop aplikacije ..................................................... 37
Slika 2.11 Aapstraktni prikaz klasa i njihovih relacija .................................................. 40
Slika 2.12 ER model baze sa atributima entiteta ........................................................... 41
Slika 2.13 Dijagram razmještanja.................................................................................. 43
Slika 3.1 Početna strana za prijavu ................................................................................ 46
Slika 3.2 Prikaz menija .................................................................................................. 46
Slika 3.3 Izgled interfejsa za upis ocjene ...................................................................... 47
Slika 3.4 Izgled interfejsa za izostanke ......................................................................... 48
Slika 3.5 Prikaz izvještaja.............................................................................................. 49
Slika 3.6 Prijava na veb aplikaciju ................................................................................ 50
Slika 3.7 Prikaz informacija za učenika na veb aplikaciji ............................................. 51
Slika 3.8 Izgled aplikacije zaštite .................................................................................. 52
 1 UVOD U UML

Kako se informacione tehnologije rapidno razvijaju, isto tako računarski sistemi iz

dana u dan postaju sve složeniji. Ta složenost se odlikuje kako kroz hardver tako i kroz
softver, umrežavanje velikih razdaljina, povezanost i komuniciranje sa bazama koje
pohranjuju velike količine podataka. Ako želite da razvijete sistem koji može da izlazi na
kraj sa ovim, morate da imate efikasan način kako da se suočite sa kompleksnošću izrade.
Jedno od rješenja problema jeste da se taj proces izrade sistema napravi razumljiv
svima koji učestvuju u kreiranju jednog sistema (klijenti, analitičari, programeri i ostali koji
učestvuju u izradi). UML (engl. Unified Modeling Language) predstavlja objedinjeni jezik
za modelovanje i standardni je jezik za vizuelno prikazivanje objektnog modela u polju
softverskog inženjerstva. UML model predstavlja apstraktni model sistema koji se pravi
pomoću grafičkih simbola. UML su napravili Grady Booch, Ivar Jacobson and James
Rumbaugh sredinom devedesetih i prvi put je 1996. godine firma Rational Software
predstavila UML.

Jedinstvenost UML modelovanja se ogleda u:

- Može se koristiti za modelovanje u različitim vrstama analize ili dizajna bez

pravljenja objektno orijentisane aplikacije,
- Kombinovanje najboljih koncepata ranije korišćenih metoda;
1. Entity Relationship modeling – model objekti-veze,
2. Modelovanje objekata,
3. Modelovanje komponenti,
4. Poslovno modelovanje.
- Isti koncepti i oznake modu da se koriste u bilo kojoj fazi razvoja sistema,
- Pruža mogućnost da se jednim jezikom modeluje poslovni sistem, aplikacija, baza
podataka i arhitektura sistema,
- Omogućava povezivanje razvojnih timova;
1. Korištenje UML-a omogućava zajednički jezik za sve učesnike u razvoju
sistema objedinjujući ljude u jedan razvojni tim,
2. UML kao jezik za čitav životni ciklus razvojnog procesa omogućava da svi
timovi rade na isti način, ali da svoj sopstveni dio rade prema potrebama.

UML omogućava:

1
 - Vizualizaciju – vizuelni odnosno grafički jezik,
- Specifikaciju – formiraju se precizni, nedvosmisleni i potpuni modeli,
- Konstrukciju – nije vizuelni programski jezik ali njegovi modeli mogu se
neposredno povezati sa raznim programskim jezicima. Moguće preslikavanje iz
UML-a u druge programske jezike poput C# ili Jave,
- Dokumentovanje sistema – mogu se dokumentovati zahtjevi, arhitektura, izvorni
kod itd.

1.1 Modelovanje sistema

Razvoj informacionih sistema je složen i dugotrajan proces koji podrazumijeva niz

faza i aktivnosti, od planiranja razvoja do zastarijevanja sistema. Taj proces razvoja sistema
uključuje mnogo ljudi. Prvi u nizu je klijent, osoba ili firma za koga se sistem pravi.
Analitičar je taj koji će proučiti zahtjeve korisnika i analizirati postojeće stanje, u cilju
predlaganja i definisanja poslovnih zahtjeva koje treba da podrži novo rješenje. Projektant
je taj koji u fazi projektovanja sistema definiše dizajn baze podataka, arhitekturu
softverskog sistema, procedure koje će se koristiti prilikom eksploatacije sistema i
korisnički interfejs. Programer je taj koji piše programski kod prema projektnoj
specifikaciji i vrši testiranje modula. Pored njih postoji još mnoštvo ljudi uključenih u
izradu sistema. To je neophodno jer su današnji sistemi veoma složeni i danas jedna osoba
ne može da zna sve činjenice i zahtjeve, da razumije problem, predstavi rješenje, projektuje
model rješenja, napiše programski kod, testira ga i da bude siguran da programsko rješenje
zadovoljava potrebe klijenta.

2
 Slika 1.1 Model vodopada

Ovaj prethodni način modelovanja sistema, poznat kao model vodopada, određuje da
svaka faza izrade prethode jedna drugu tj. tek kad je jedna faza gotova druga može otpočeti.
Kada analitičar preda analizu projektantu, koji proslijeđuje projektni model programeru
koji piše kod programa itd. šanse da više učesnika iz različitih faza izrade rade zajedno su
veoma male.
UML danas nudi mogućnost da se analitičari i projektanti mogu stalno vraćati i
poboljšavati svoju fazu kako bi programeri imali što bolju osnovu modula za
programiranje, isto tako programeri mogu da podijele svoja zapažanja sa analitičarima i
projektantima kako bi se napravio još bolji dizajn sistema. Takva saradnja među
učesnicima različitih faza izrade sistema omogućava da sistem bude kvalitetniji u svakom
pogledu.

3
 1.2 Komponente UML-a

Unutar UML postoji više različitih grafičkih elementa kombinovanih u dijagrame.

Dijagrami služe kako bi se neki sistem predstavio iz različitih aspekata. Model predstavlja
više takvih aspekata (skup aspekata). Model sistema je taj koji predstavlja kako sistem treba
da radi.

1.2.1 Dijagram klasa

Dijagrami klasa se koriste kako bi opisali tipove objekata unutar sistema i veze istih.
Dijagrami klasa koriste elemente:

- Klase,
- Pakete,
- Objekte.

Dijagrami klasa opisuju tri različita aspekta pri projektovanju sistema a to su aspekt
sistema, aspekt specifikacije i aspekt implementacije.
Klasa se sastoji od tri elementa: imena klase, atributa i operacije. Primjer klase je prikazan
na slici 1.2.

Slika 1.2 Primjer klase

Dijagrami klasa mogu prikazivati veze kao što su asocijativnost, naslijeđivanje i druge.
Slika 1.3 prikazuje primjer asocijativnosti.

4
 Slika 1.3 Primjer asocijativnosti

Veza asocijativnost se najviše koristi kod ovakvih dijagrama. Ova veza prikazuje
relaciju između instanci klasa, npr. klasa Narudžba je asocirana klasom Kupac. Složenost
asocijacije označava broj objekata koji učestvuju u relaciji. Na primjer neka narudžba može
biti asocirana sa jednim kupcem, a kupac može biti asociran sa većim brojem narudžbi.
Pored asocijacija, veza koja se takođe široko koristi je generalizacija. Generalizacija se
uglavnom koristi kada su dvije ili više klasa slične sa nekim različitostima. Primjer
generalizacije je prikazan na slici 1.4.

5
 Slika 1.4 Primjer generalizacije

Na ovom primjeru generalizacije personalni kupac i korporativni kupac klase imaju

neke zajedničke sličnosti poput imena i adrese, a sama klasa Kupac generalnija je od klasa
personalni kupac i korporativni kupac.
Prije samog početka crtanja dijagrama klasa je neophodno sagledati sva tri različita
aspekta sistema koje će predstaviti dijagram:

- konceptualnu perspektivu,
- specifikaciju,
- implementaciju.

Potrebno se fokusirati na jednu perspektivu i vidjeti kako rade sve zajedno. Kada se klase
projektuju takođe se moraju razmotriti artibuti i relacije koje će ta klasa sadržavati.

1.2.2 Fizički dijagrami (dijagram komponenti i dijagram razvoja)

Fizički dijagrami se po pravilu koriste tek kada je završen razvoj sistema. Oni se koriste
da se opišu fizičke informacije sistema. Fizički dijagrami se dijele u dva tipa:

6
 - dijagram razvoja,
- dijagram komponenti.

Dijagram razvoja prikazuje fizičku vezu između softvera i hardvera sistema, a dijagram
komponenti prikazuje softverske komponente sistema i međusobnu povezanost tih
komponenti.
Ti dijagrami komponenti i razvoja se najčešće kombinuju u jedan fizički dijagram, koji
predstavlja sve osobine oba dijagrama na jednom kombinovanom dijagramu. Dijagram
razvoja u stvari prikazuje čvorove i konekcije između njih. Čvor obično predstavlja dio
hardvera unutar sistema, a konekcija predstavlja put komunikacije koji upotrebljava
hardver zadužen za komunikaciju i najčešće pokazuje na standardni protokol TCP/IP1. Na
slici 1.5 je predstavljen primjer čvorova i konekcije u dijagramu razvoja.

Slika 1.5 Primjer čvorova i konekcije u dijagramu razvoja

U cilju dobijanja što boljeg rješenja dijagram razvoja se upotrebljava kako bi se

istražio način kako uklopiti različite hardverske konfiguracije. Na slici 1.6 je predstavljen
dijagram razvoja sa 3 računara, štampačem u boji, aplikacionim serverom, internet
priključkom i serverom baze podataka. Ovakvi dijagrami se ne koriste za poslovne modele,
jer oni predstavljaju dio koji je posebno napravljen za računarske sisteme.

1
TCP/IP (engl. Transmission Control Protocol/Internet Protocol) protokol stek je skup
protokola razvijen da omogući umreženim računarima da dijele resurse putem mreže. TCP/IP
je jedan od najzastupljenijih protokola svih računarskih mreža i na njemu se zasniva internet.

7
 Slika 1.6 Dijagram razvoja sa tri računara, štampačem, aplikacionim serverom, internet
priključkom i bazom podataka

U softverskom inženjeringu postoje razvojni timovi gdje svaki mora raditi na različitoj
komponenti projekta. Zato je neophodno imati dijagram komponenti u procesu razvoja
sistema.
Dijagram komponenti sadrži komponente i zavisnosti (interfejse i veze). Komponenta
dijagrama je grafički predstavljena kao pravougaonik koji ima dva mala pravougaonika
preko sebe sa lijeve strane. Unutar njega se piše ime komponenti. Ime je string. Ako je
komponenta član paketa, možemo staviti prefiks imena komponente kao ime paketa. Slika
1.7 prikazuje grafičku komponentu na dijagramu

Slika 1.7 Prikaz grafičke komponente na dijagramu

Komponente u suštini predstavljaju fizičku interpretaciju modula koda, kao što su npr.
biblioteke dinamičkog linka, dinamičke komponente, kodovi objekata, izvršne aplikacije i
sl. Zavisnosti između komponenti prikazuje kako promjene učinjene nad jednom
komponentom mogu da pogode drugu komponentu u sistemu. Relacije među

8
komponentama se grafički predstavljaju isprekidanom linijom (strelicom). Na dijagramu
komponenti mogu se grafički prikazati i interfejsi koje komponente koriste u međusobnoj
komunikaciji.
Slika 1.8 predstavlja primjer dijagrama komponenti na kom su prikazane veze između
šest komponenti.

Slika 1.8 Primjer dijagrama komponenti

Kombinovani dijagram razvoja i dijagram komponenti je prikazan na slici 1.9. On

prikazuje čvor1 i čvor2 koji su u stvari dva računara koji međusobno komuniciraju putem
standardnog TCP/IP protokola. Na slici se može primjetiti da druga komponenta
(komponenta2) zavisi od prve komponente (komponenta1) i sve promjene urađene na
drugoj komponenti pogađaju prvu komponentu. Ovaj sistem isto tako uključuje i treću
komponentu (komonenta3) koja je putem interfejsa (interfejs1) u relaciji sa prvom
komponentom. Dijagram poput ovog daje nam veoma brz pregled sistema.
Kombinovan dijagram razvoja i dijagram komponenti

9
 Slika 1.9 Kombinovani dijagram razvoja i dijagram komponenti

1.2.3 Dijagram objekata

Dijagrami objekata nam pokazuju grupu dijagrama klasa i ilustruju slike objekata i
njihove relacije u specifičnom vremenskom trenutku. Objekti i njihove relacije čine
dijagrame objekata. Veze objekata predstavljaju načine na koje su ti objekti povezivani i
grupisani. Slika 1.10 predstavlja primjer dijagrama objekata.

10
 Slika 1.10 Primjer dijagrama objekata

Nazivi objekata su u stvari sastavljeni su od naziva objekta praćenog dvotačkom i

nazivom klase; npr. P1:Poligon. Na tri načina je moguće vršiti obilježavanje:
P1:Poligon ( ime objekta P1, klasa Poligon),
P1 (ime objekta P1, klasa neimenovana),
: Poligon (objekat neimenovan, klasa Grupa).

1.2.4 Dijagram aktivnosti

Dijagram aktivnosti prikazuje korake (nazvane aktivnostima) kao tačke odluke i

grananja. Ovi dijagrami se koriste kako bi se opisali poslovni procesi, radni tok u smislu
organizacije i dešavanja unutar neke operacije. Dijagrami se čitaju u smijeru odozgo prema
dolje i imaju razdvajanja koja služe za opisivanje paralelnih aktivnosti i uslova. Dijagram
aktivnosti prikazuje tok aktivnosti kroz sistem i svaka aktivnost je predstavljena
pravougaonikom zaobljenih strana (zaobljen je više od simbola stanja). Početna tačka
dijagrama aktivnosti je ispunjen krug, a zadnja tačka je predstavljena kao bikovo oko (engl.
bullseye) tj. neispunjenim krugom sa jednim manjim ispunjenim unutar njega. Strelica
predstavlja prelaz sa jedne na drugu aktivnost, a prazan romb predstavlja simbol odluke. Na
slici 1.11 nakon prve aktivnosti (aktivnost1) slijedi razdvajanje, što predstavlja da se druga
i treća aktivnost (aktivnost2 i aktivnost3) odvijaju istovremeno. Nakon druge aktivnosti

11
slijedi grananje i prikazuje se simbolom odluke. Ovo grananje prikazuje aktivnosti koje će
se odigrati poslije zadovoljavajućeg uslova. Sva se grananja završavaju u istoj tački koja se
naziva tačka sjedinjavanja i ona predstavlja kraj grananja. Poslije tačke sjedinjavanja sve
istovremene aktivnosti se spajaju prije završnog stanja.

Slika 1.11 Dijagram aktivnosti

Iako dijagram aktivnosti ima sličnosti sa dijagramom stanja, kod dijagrama aktivnosti
se stanja mijenjaju automatski odnosno čim se završi jedno stanja prelazi se na drugo
stanje. Stanja se kod dijagrama aktivnosti zovu stanja aktivnosti odnosno aktivnosti.
Aktivnosti mogu da se podjele na podaktivnosti. Podaktivnosti se dalje mogu djeliti na
akcije, koje se ne mogu dalje djeliti. Akcije se predstavljaju istim grafičkim simbolom kao
što se i aktivnosti predstavljaju pravougaonikom zaobljenih ivica. Akcije i aktivnosti
povezane su tranzicijama, koje čine kontrolni tok na dijagramu. Na sljedećoj slici 1.12 je
prikazan primjer dijagrama aktivnosti.

12
 Slika 1.12 Primjer dijagrama aktivnosti

1.2.5 Dijagram stanja

U svakom momentu objekti se nalaze u nekim stanjima, a dijagrami stanja

predstavljaju stanja objekta kako se događaji dešavaju. Dijagrami stanja se koriste kako bi
se moglo opisati ponašanje sistema. Dijagrami stanja nam mogu pojasniti ponašanje nekog
objekta i mjenjanje ponašanja od jednog stanja do drugog stanja. Isto tako pokazuje se koji
događaj mijenja stanje objekta, a stanje objekta izraženo je vrijednostima atributa i
relacijama sa drugim objektima.
Na primjer, stanja objekta su:

- Automobil (objekat) je ugašen (stanje),

- Račun (objekat) je plaćen (stanje),
- Prozor (objekat) je otvoren (stanje).

13
 Objekat mijenja stanje kad se neki događaj dogodi. Stanja se u dijagramu stanja
prikazuju zaobljenim pravougaonikom, a puna strelica predstavlja simbol za prelaz.
Ispunjen krug predstavlja početno stanje a zaokruženi ispunjeni krug predstavlja krajnje
stanje. Na slici 1.13 je predstavljen grafički prikaz dijagrama stanja objekta.

Slika 1.13 Grafički prikaz dijagrama stanja objekta

Promjena stanja je imenovana događajem koji je izazvao promjenu stanja. Kada se

neki događaj dogodi, uslov za promjenu iz jednog stanja u drugi je ispunjen.
Na slici 1.14 prikazan je primjer procedure upisa studenata na fakultet korišćenjem
dijagrama stanja. Potrebno je istaći da se na dijagramu nalaze dva završna stanja, kada je
student upisao fakultet i kad nije upisao fakultet.

14
 Slika 1.14 Primjer procedure upisa studenta na fakultet korišćenjem dijagrama stanja

1.2.6 Dijagram slučaja upotrebe (Use case diagram)

Dijagrami slučaja upotrebe (dijagrami slučaja korišćenja) obuhvataju funkcionalne

zahtjeve sistema. Ovim dijagramom je moguće opisati ponašanje sistema iz korisničke
perspektive. Sastavni djelovi Use Case dijagrama su:

- scenariji ili slučaj upotrebe (use cases) - predstavljaju karakteristične dijelove akcija
u najčešćim situacijama korišćenja sistema, odnosno opisuju funkcije koje obavlja
sistem,
- korisnici ili učesnici (actors) - osobe ili vještački entiteti koji sudjeluju u slučaju
upotrebe,
- interakcije - vrste aktivnosti koje se izvršavaju unutar komunikacije korisnika.

Dvije glavne komponente dijagrama slučaja upotrebe su slučajevi upotrebe i korisnici

(učesnici) koji su prikazani na slici Slika 1.15.

15
 Slika 1.15 Glavne komponente dijagrama slučaja upotrebe

Slučaj upotrebe je skup scenarija o upotrebi sistema. Svaki scenario opisuje sekvenca
događaja, svaku sekvencu započinje učesnik (osoba, drugi sistem, dio hardvera ili period
vremena). Entiteti koji počinju sekvence zovu se učesnici (actors). Rezultat sekvence mora
da bude upotrebljiv ili od učesnika koji je započeo sekvencu ili od drugog učesnika.
Učesnik je predstavljen kao korisnika sistema koji je u međusobnoj relaciji sa sistemom
koji se kreira. Slučaj upotrebe predstavlja izgled sistema koji pokazuje redoslijed radnji
koje treba korisnik izvršiti kako bi se obavio neki zadatak. Svaki slučaj upotrebe se treba
fokusirati na sami opis toga kako doći do doređenog zadatka ili cilja. Slučaji upotrebe se
koriste u većini projekata, veoma su korisni za planiranje projekata i predstavljanje zahtjeva
sistema. Dok je početna faza razvoja nekog sistema potrebo je definisati većinu slučaja
upotrebe, ali isto tako je moguće naknadno dodavanje ili smanjivanje broja slučaja upotrebe
po potrebi.
U sistemskom i softverskom inžinjeringu slučaji upotrebe se koriste za opis
funkcionalnosti sistema na horizontalnom nivou. Svaki slučaj upotrebe predstavlja jedan ili
više scenarija koji opisuje kako taj sistem obavlja interakciju među učesnicima
(korisnicima). Slučaji upotrebe opisuju detaljne karakteristike sistema i koriste se kako bi
se mogle prikazati sve funkcije.
Dijagrami slučaja upotrebe se jednostavno crtaju. Na sljedećoj slici je predstavljen
primjer kako je kupac izabrao neki proizvod. Kreće se od kreiranje spiska koraka koje
kupac izvršava prilikom naručivanja nekog proizvoda:

1. listanje kataloga i izbor proizvoda,

2. poziv prodavca,
3. nabavka informacija o kupovini,
4. nabavka informacija o plaćanju,
5. pristizanje odgovora od prodavca.

16
Ovakvi koraci generišu veoma jednostavan dijagrama slučaja upotrebe prikazan na slici
1.16. Na ovom primjeru je učesnik sistema prikazan kao kupac. Dijagram prikazuje
navedene korake kao akcije koje preduzima učesnik sistema (kupac). Isto tako i prodavac
može da bude učesnik sistema jer je i on taj koji vrši interakciju sa sistemom narudžbe.

Slika 1.16 Primjer dijagrama slučaja upotrebe

Slučaj upotrebe se može povezivati sljedećim vezama:

- Include
Uključenje omogućava da ponovo upotrijebimo korake sa jednog slučaja upotrebe
(koji se naziva osnovni slučaj upotrebe) u okviru drugog slučaja upotrebe (koji se
naziva uključeni slučaj upotrebe). Jedan slučaj upotrebe može da pozove veći broj
slučaja upotrebe i može biti uključen u višestrukim slučajevima upotrebe. Kako bi
predstavili uključenje koristimo simbole za veze između klasa - isprekidana linija
koja povezuje klase sa strelicom koja pokazuje na onu od koje zavisi klasa.
- Extend
Nadogradnja veza između dva slučaja upotrebe znači da je osnovni slučaj upotrebe
(slučaj upotrebe koji je proširen) proširen osnovnim ponašanjem proširujućeg
slučaja upotrebe. Nadogradnja se može dodati kao opcija osnovnom slučaju

17
 upotrebe, mada osnovni slučaj upotrebe ne mora da ima dodatni. Za predstavljanje
nadogradnje koristi se isprekidana linija sa strelicom.
- Generalization
Generalizacija između slučaja upotrebe je isto što i generalizacija između klasa.
Klase mogu da naslijede druge klase, pa samim tim slučaj upotrebe može da
naslijedi slučaj upotrebe. U naslijeđivanju slučaja upotrebe, potomak slučaja
upotrebe nasljeđuje ponašanje i značenje pretka, i dodaje svoje ponašanje. Jedan
slučaj upotrebe može biti specijalizovan na više slučajeva upotrebe koji nasljeđuju
ili dodaju osobine tom slučaju upotrebe.
- Grouping
U nekim dijagramima slučaja upotrebe, može da postoji više dijagrama i možda
želimo da ih organizujemo. Ovo može da se desi kad sistem sadrži više podsistema.
Najčešći način da organizujemo grupisanje povezanih slučajeva upotrebe su paketi
(package) to jest označeni direktorijum. Prikazani su isto kao što je prikazana i
generalizacija kod klasa (linija sa strelicom na kraju).

Primjer include veze je prikazan na slici 1.17. Log aktivnost slučaja upotrebe je glavni za
upravljanje resursima, projektom i administracija sistema slučaja upotrebe i uključen je od
strane tih slučaja upotrebe.

Slika 1.17 Log aktivnosti slučaja upotrebe

18
Primjer extend veze je prikazan na slici 1.18. Održavanje projekta, aktivnosti i zadataka
slučajeva upotrebe predstavljaju opcije za Upravljanje projektom slučaja upotrebe.

Slika 1.18 Primjer extend veze

1.2.7 Dijagrami interakcija

Dijagrami interakcije modeluju ponašanje slučajeva upotrebe opisujući način kako

grupa objekata uzajamno djeluju u svrhu izvršenja nekog zadatka. Dijagrami interakcija se
sastoje od dijagrama saradnje i dijagrama sekvenci (sekvencijalnog dijagrama). Ovi
dijagrami će biti opisani u ovom poglavlju.

1.2.8 Dijagram saradnje

Dijagram saradnje prikazuje vezu tj. zavisnost između objekata i redoslijed poruka koje
se prosljeđuju između istih. Pomoću ovih dijagrama mnogo se lakše prikazuju složenije
interakcije i veze između objekata koji sarađuju.
Strelice među objektima predstavljaju poruke koje se prosljeđuju između objekata.
Brojevi koji se nalaze pored poruka predstavljaju sekvencu brojeva. Ovi brojevi
predstavljaju dijelove poruka koje se prosljeđuju među objekatima. Za jednostavnije
primjere se može koristiti sekvenca brojeva (1, 2, 3, itd.) dok se za kompleksnije primjere
koristi složenija sekvenca brojeva (1, 1.1, 1.2, 1.2.1, itd.). Slika 1.19 predstavlja osnovne
elemente: objekte i proslijeđene poruke.

19
 Slika 1.19 Osnovni elementi dijagrama saradnje

Na slici 1.20 je prikazan jednostavan dijagram saradnje na primjeru narudžbe.

Slika 1.20 Dijagram saradnje na primjeru narudžbe

1.2.9 Sekvencijalni dijagram

Kako bi se predstavile i istražile sekvence unutar kojih objekti međusobno djeluju

koristi se sekvencijalni dijagram. Pri tom objekti mogu biti: ljudi, kompanije, računari,
procesi, organizacione jedinice ili neki drugi mehanički objekti. Sekvencijalni dijagram
najčešće predstavlja sekvence poruka među više objekata, gdje su redoslijed i vrijeme
poruka detaljno opisani. Slika 1.21 je primjer takve sekvence. Ovaj model je zasnovan na 4
osnovne faze za interakciju koje se ponavljaju:

1. Prva faza, faza pripreme, se sastoji od:

- pripreme zahtjeva,
- slanja zahtjeva.

2. Faza pregovaranja se sastoji od:

20
 - pripreme ponude,
- slanja ponude,
- pripreme kontra ponude,
- slanja kontraponude,
- slanja ponude korisniku,
- pripreme narudžbe,
- slanja narudžbe i
- obveznice.

3. Faza izvršavanja se sastoji od:

- potvrde,
- izvršenja,
- objave isporuke.

4. Posljednja faza, faza prihvatanja, uključuje:

- potvrdu isporuke,
- primanje,
- pripremu računa (dostavnice),
- slanje računa,
- pripremu plaćanja,
- plaćanje.

Na slici 1.21 vidimo da su objekti smiješteni u vrh modela, a linije su iscrtane vertikalno u
odnosu na objekat. One opisuju kad su objekti kreirani ili uništeni.

21
 Slika 1.21 Primjer sekvencijalnog dijagrama

Slika 1.22 prikazuje kako su objekti kreirani i uništeni za vrijeme izvršenja sekvence. U
sekvencijalnom dijagramu poruke mogu imati parametre kao što je i prikazano na slici
1.22.

22
 Slika 1.22 Objekti za vrijeme izvršenja sekvence

2 ANALIZA INFORMACIONOG SISTEMA

Na samom početku ćemo se osvrnuti na identifikaciju posla, kako bi smo mogli u

sljedećem dijelu izložiti analizu zahtjeva koje smo sakupili tokom intervjua. Zatim moramo
da uradimo specifikaciju određenih dijelova projekta koje ćemo razraditi do detalja. Za
početak, u fazi identifikacije posla je potrebno da se upoznamo sa naručiocem i firmom.
Zatim je potrebno predstaviti detalje intervjua koje smo sproveli sa kontakt osobom i na
kraju ćemo izložiti specifikaciju zahtijeva koje smo saznali.

2.1 Identifikacija posla

Naručilac: Srednjoškolski centar „Ljubiša Mladenović“

Adresa: Despota Stefana Lazarevića bb Banja Luka, Republika
Srpska, Bosna i Hercegovina
Odgovorno lice: Danijela Jokanović
Lice za kontakt: Danijela Jokanović, Biljana Berić

23
Naziv projekta: Analiza informacionog sistema eDnevnik
Krajnji korisnik: Srednjoškolski centar „Ljubiša Mladenović“

2.2 Analiza i specifikacija korisničkih zahtjeva

Prvi korak u procesu razvoja softvera je da se opiše korisnički zahtjev. Najčešće se

počinje sa tekstualnim opisom da bi se, formiranjem slučajeva korišćenja, taj zahtjev
transformisao u manje, ali logički relativno nezavisne cjeline. Zahtjevi (requirements)
predstavljaju svojstva i uslove koje sistem mora da zadovolji i kao što smo ranije pomenuli,
zahtjevi se opisuju pomoću modela slučajeva korištenja (Use-case model). Nakon
odrađenog intervjua sa naručiocem programa zapisani su korisnički zahtjevi.

Pomoću aplikacije eDnevnik profesori bi trebali da imaju sljedeće opcije:

- upis ocjene,
- izmjena ocjene,
- zaključivanje ocjene,
- najava provjere znanja,
- mogućnost prikaza izvještaja svih ocjena po razredu, predmetu, učeniku ili prikaz
svih ocjena predmeta za jednog učeniku,
- mogućnost štampanja izvještaja ocjena radi potrebe izrade redovnih tromjesečnih i
polugodišnjih izvještaja,
- mogućnost prijave greške sistem administratoru.

Dijagram slučaja upotrebe za profesora:

24
 Slika 2.1 Dijagram slučaja upotrebe za profesora

Profesori koji su razredne starješine bi trebali imati dodatne opcije:

- upis izostanaka,
- ažuriranje upisanih izostanaka nakon određenog vremena (opravdan ili
neopravdan),
- brisanje izostanaka,
- prikaz svih izostanaka po učenicima svog odjeljenja ili za jednog učenika,
- mogućnost štampanja izostanaka radi potrebe izrade redovnih tromjesečnih i
polugodišnjih izvještaja,
- najava razrednog starješine roditeljima,
- unos učenika – može biti inicijalni unos razreda, isto tako po potrebi unos novog
učenika u slučaju da se novi učenik priključi razredu,
- sistem komunikacije sa roditeljima putem programa.

Dijagram slučaja upotrebe za razrednike:

25
 Slika 2.2 Dijagram slučaja upotrebe za razrednike

Vannastavno osoblje odnosno članovi školskog kolektiva koji bi takođe trebali imati
pristup eDnevniku, poput direktora, pedagoga ili koordinatora bi trebali imati samo sljedeće
opcije:

- mogućnost prikaza izvještaja svih ocjena po razredu, predmetu, učeniku ili prikaz
svih ocjena predmeta za jednog učeniku,
- mogućnost štampanja izvještaja ocjena radi potrebe izrade redovnih tromjesečnih i
polugodišnjih izvještaja,
- mogućnost prijave greške sistem administratoru.

Dijagram slučaja upotrebe za vannastavno osoblje:

26
 Slika 2.3 Dijagram slučaja upotrebe za vannastavno osoblje

Roditelji koji koriste eDnevnik bi trebalo da imaju sljedeće opcije:

- pregled svih ocjena svog djeteta,

- pregled prosječne ocjene za svaki predmet (trenutni prosjek učenika),
- pregled prosječne ocjene odjeljenja za svaki predmet (da može da uporedi
odstupanja ocjene svog djeteta od ostatka odjeljenja),
- pregled izostanaka,
- pregled najave razrednog starješine (obavještenja o roditeljskim sastancima,
školskih izletima i razna druga obavještenja),
- pregled najave predmetnog profesora (najava kontrolnog rada ili slično),
- mogućnost kontaktiranja razrednika putem programa.

Dijagram slučaja upotrebe za roditelje:

27
 Slika 2.4 Dijagram slučaja upotrebe za roditelje

Sistem administrator će imati mogućnosti:

- pregleda ili ažuriranja svih informacija unutar relacione baze podataka,

- definisanja odjeljenja, razreda, smjerova,
- definisanje rasporeda profesora po predmetima,
- kreiranje naloga za profesore, razrednika ili vannastavno osoblje,
- pregled svih prijavljenih grešaka,
- ispravljanje svih prijavljenih grešaka,
- kreiranja ključeva pomoću koji će roditelji moći pristupiti aplikaciji.

Dijagram slučaja upotrebe za sistem administratora:

28
 Slika 2.5 Dijagram slučaja upotrebe za sistem administratora

Na slici 2.6 je predstavljen sekvencijalni dijagram i način interakcije između administratora

i baze podataka.

29
 Slika 2.6 Način interakcije između administratora i baze podataka

Upotrijebićemo dijagram stanja za prikazivanje tranzicija između stanja i događaja koji

su prouzrokovali promjenu tih stanja. Dijagram stanja na slici 2.7 prikazuje unos novog
odjeljenja od strane administratora koji sadrži sljedeća stanja i događaje.

Stanja:

1. logovanje u program,

30
2. rad sa odjeljenjima,
3. prikazivanje spiska odjeljenja,
4. unesi novo odjeljenje,
5. potvrđivanje unosa,
6. otkazivanje unosa,
7. potvrda unosa.

Događaji:

1. izbor opcije za rad sa odjeljenjima,

2. spisak odjeljenja,
3. ne postoji ni jedno odjeljenje,
4. izbor opcije za unos odjeljenja,
5. odjeljenje već postoji,
6. moguće je unijeti odjeljenje,
7. neuspješna potvrda,
8. uspješna potvrda.

31
 Slika 2.7 Dijagram stanja za unos novog odjeljenja

Na sljedećoj slici 2.8 je prikazan dijagram aktivnosti, na kom su prikazani koraci odnosno
aktivnosti koji opisuju proces modifikovanja ocjene od strane profesora.

32
 Slika 2.8 Dijagram aktivnosti za modifikovanje ocjene

Pošto će se program sastojati od dva dijela (Web aplikaciju i desktop aplikaciju)

Dijagram komponenti ćemo podijeliti u dva dijagrama. Web aplikacija će koristiti roditelji
za pregled informacija dok će desktop aplikaciju koristiti profesori za unošenje podataka.
Web aplikacija ima šest PHP komponenti:

1. index.php
2. login.php
3. ocjene.php
4. kontakt.php
5. slanje.php
6. kontakt-admin.php

33
 Na slici 2.9 je predstavljen dijagram komponenti veb aplikacije.

Slika 2.9 Dijagram komponenti veb aplikacije

Na slici 2.10 je dijagram komponenti desktop aplikacije koju profesori koriste.

Dijagram se sastoji iz 33 komponenete (aplikacionog programa, baze podataka, 5
biblioteka dinamičkog linka, 10 GUI CS formi i 22 klase):

Aplikacioni program:

- program.exe

Baza podataka:

- relaciona baza podataka.

34
Biblioteke dinamičkog linka (DLL2 fajlovi):

- System.Management.dll
- System.Management.Instrumentation.dll
- MySql.Data.dll
- System.Data.dll
- Microsoft.Office.Interop.Excel.dll

CS forme:

- login.cs
- meni.cs
- upis ocjena.cs
- upis učenika.cs
- izvještaji ocjena.cs
- izostanci.cs
- najave provjere znanja.cs
- najava razrednika.cs
- poruke.cs
- prijava greške.

Klase:

- sigurnosna provjera računara,

- sigurnosna provjera profesora,
- upis ocjena,
- izmjena ocjena,
- zaključivanje,
- prikaz stanja ocjena,
- upis najave,
- upis najave razrednika,
- upis učenika,
- lista učenika.
- prikaz poruka,
2
DLL (engl. Dynamic-link library) predstavlja Microsoft-ovu implementaciju zajedničkog
(djeljivog) koncepta biblioteke u Microsoft Windows-u i OS/2 operativnim sistemima.

35
- slanje poruka,
- prikaz izvještaja,
- štampanje,
- prijava greške,
- unos izostanaka,
- brisanje izostanaka,
- pravdanje izostanaka,
- izvještaj izostanaka,
- stanje izostanaka,
- prikaz izvještaja izostanaka,
- štampanje izostanaka.

36
Slika 2.10 Dijagram komponenti desktop aplikacije

37
 2.3 Analiza domena

Ovo poglavlje obuhvata:

- analiziranje intervjua,
- razvijanje dijagrama klasa,
- stvaranje i označavanje klasa i entiteta i povezivanja entiteta,
- određivanje kompozicija i grupa,
- popunjavanje klasa.

2.3.1 Analiza intervjua poslovnog procesa

Glavni cilj analize je da se napravi dijagram klasa. Pošto ćemo koristiti relacionu bazu
podataka gdje ćemo skladištiti podatke, putem UML dijagrama je moguće generisati
dijagram klasa nakon predstavljanja dijagrama veza entiteta (Entity relationship diagram)
relacionih baza podataka. Prvo je potrebno da odredimo apstraktne klase.

2.3.2 Razvijanje dijagrama klasa

Za početak ćemo odrediti prema strukturi baze podataka više entiteta:

- Godine
- Greske
- Izostanci
- Najave
- Najave_razrednog_starjesne
- Ocjene
- Odjeljenja
- Osoblje
- Poruke
- Predmeti
- Pristup
- Profesori
- Razredi
- Smjerovi

38
 - Srednje_ocjene_predmeta
- Trenutne_ocjene
- Ucenici
- Zakljucne_ocjene

Nakon toga kreiraćemo dijagram klasa ovih navedenih entiteta pišući svaku riječ
velikim početnim slovom. Sada ćemo definisati sljedeće veze među klasama:
Godine-Ucenik, Godine-Predmeti, Godine-Razredi, Greske-Profesori, Izostanci-Ucenici,
Najave-Razredi, Najave-Predmeti, Najave_razrednog_starješine-Razred, Ocjene-Predmeti,
Ocjene-Ucenici, Odjeljenja-Razredi, Odjeljenja-Ucenici, Profesori-Poruke, Profesori-
Predmeti, Profesori-Razredi, Razredi-Ucenici, Razredi-Smjerovi, Razredi-
Srednje_ocjene_predmeta, Smjerovi-Predmeti, Ucenici-Poruke, Ucenici-Trenutne_ocjene,
Ucenici-Zakljucne_ocjene, Trenutne_ocjene-Predmeti, Zakljucne_ocjene-Predmeti,
Srednje_ocjene_predmeta-Predmeti.

Slika 2.11 predstavlja apstraktni prikaz klasa i njihovih relacija.

39
 Slika 2.11 Aapstraktni prikaz klasa i njihovih relacija

Nakon što smo napravili apstraktne klase i veze, moramo da pronađemo klase koje su
kompozicije drugih klasa. Primjeri kompozicija su: odjeljenja se sastoje od učenika ili
razredi se sastoje od odjeljenja, godina i smjerova i sl.

40
 Nakon ovoga dijela je moguće da pomoću apstraknog dijagrama klasa sa relacijama
formiramo ER model3 i predstavljene klase prebacimo u entitete relacione baze podataka.
Nakon toga ćemo dodijeliti atribute entitetima i formirati ER model koji će nam služiti za
dalje razvijanje sistema. Kao relacionu bazu podataka ćemo koristiti MySQL.
Na slici 2.12 je predstavljane ER model date baze sa atributima entiteta.

Slika 2.12 ER model baze sa atributima entiteta

3
ER model (engl. Entity–relationship model) je model objekti-veze i jedan je od načina na koji
se mogu projektovati baze podataka. Pored IDEF1x, UML i još nekoliko drugih metoda ovaj
model predstavlja jedan od najpopularnijih metoda.

41
 2.4 Analiza i razvoj sistema

Nakon što imamo dijagram klasa potrebno je da analiziramo sistem koji smo nazvali
eDnevnik prije početka detaljnog razvoja. Pošto je srednjoškolski centar u pitanju i
profesori će unositi sa desktop aplikacije podatke, postojaće 3 računara u zbornici
(Zbornica1-PC, Zbornica2-PC, Zbornica3-PC) na koji će biti intergisan sistem za profesore.
Pored ta 3 računara postojaće još 2 računara, računar direktora (Direktor-PC) i računar
koordinatora nastave (Koordinator-PC) na koje će takođe biti integrisan sistem za njihove
potrebe. Svih 5 računara se nalaze u lokalnoj mreži koji su povezani na štampač isto unutar
lokalne mreže. Na udaljenom serveru će se nalaziti relaciona baza podataka na koju će biti
skladišteni podaci (LinuxServer-PC). Na istom veb serveru gdje se nalazi baza će biti
smješten drugi dio aplikacije koji će koristiti roditelji. Znači svi programi u
srednjoškolskom centru će sa relacionom bazom podataka komunicirati putem interneta, sa
štampačem unutar svoje mreže, dok će veb aplikacija komunicirati unutar localhost-a sa
bazom podataka, a roditelji sa veb aplikacijom pomoću HTTP4 protokola.
Na sljedećoj slici 2.13 je predstavljen dijagram razmještanja.

4
HTTP (engl. HyperText Transfer Protocol) je mrežni protokol koji pripada sloju aplikacije
OSI referentnog modela, predstavlja glavni i najčešći metod prenosa informacija na vebu.

42
 Slika 2.13 Dijagram razmještanja

2.5 Analiza slučajeva upotrebe

U ovom djelu ćemo analizirati nekoliko slučajeva upotrebe. Napravićemo niz slučajeva
upotrebe svrstane u pakete.
Za paket predmetnog profesora slučajevi upotrebe su:
upis ocjene, izmjena ocjene, zaključivanje ocjene, upis najava provjere znanja, prikaz
izvještaja ocjena, štampanje izvještaja ocjena, prijave greške administratoru.
Za paket razrednog starješine:
upis ocjene, izmjena ocjene, zaključivanje ocjene, najava provjere znanja, prikaz izvještaja
ocjena, štampanje izvještaja, prijave greške administratoru, upis izostanaka, ažuriranje
upisanih izostanaka, brisanje izostanaka, prikaz izvještaja izostanaka, štampanje izvještaja
izostanaka, upis najava razrednog starješine, unos učenika, slanje poruka roditeljima,
čitanje primljenih poruka, brisanje poruka.
Za paket vannastavnog osoblja:
prikaz izvještaja ocjena, štampanje izvještaja ocjena, prijava greške administratoru.
Za paket roditelja:

43
pregled ocjena, pregled izostanaka, pregled najava razrednog starješine, pregled najava
predmetnog profesora, slanje poruka razrednom starješini, čitanje primljenih poruka,
prijava greške administratoru.
Za paket administratora:
pregleda svih informacija, definisanja odjeljenja, definisanje razreda, definisanje smjerova,
definisanje rasporeda profesora po predmetima, kreiranje naloga za profesore, kreiranje
naloga za razrednike, kreiranje naloga za vannastavno osoblje, pregled prijavljenih grešaka,
ispravljanje prijavljenih grešaka, kreiranja ključeva pomoću koji će roditelji moći pristupiti
aplikaciji.

2.6 Komponente sistema

Jedan važan aspekt analize slučaja upotrebe je taj da analiziramo komponente sistema.
Prije nego završimo s ovim poglavljem, definišimo predviđene hardverske i softverske
komponente sistema eDnevnik.
Kao što smo gore spomenuli u analizi i razvoju sistema sa hardverske strane će bi
potrebno 5 PC računara u školi koji će biti umreženi u lokalnu mrežu i spojeni na internet,
unutar te mreže je isto potreban štampač. Što se tiče veb servera, potreban je isto PC
računar (takođe spojen na internet) na kom će biti veb aplikacija i baza podataka.
Sa softverske strane će biti potrebno da svih 5 PC računara u školi imaju instaliran
Windows 7 ili noviji Windows OS, jer ćemo aplikaciju razvijati na .NET Framework-u5.
Isto tako je potreban Microsoft Office paket (2003 ili noviji) radi potrebe prebacivanje
izvještaja u Microsoft Excel i štampanja izveštaja. Računarima je takođe potreban MySQL
connector/NET jer omogućava komunikaciju između aplikacije i MySQL baze podataka
standardnim TCP/IP protokolom. Na veb serveru je poželjan Linux OS sa serverskom
aplikacijom Apache HTTP koji će servirati veb aplikaciju klijentima (roditeljima) putem
HTTP protokola, isto tako je potreban MySQL sistem za upravljanje relacionim bazama
podataka (engl. MySQL relational database management system).

5
Microsoft .NET Framework je softverska platforma za Microsoft Windows koji sadrži veliki
broj gotovih biblioteka kodova za uobičajane probleme u programiranju i virtuelnu mašinu
koja upravlja izvršavanjem programa pisanih specijalno za .NET Framework.

44
 3 DIZAJN SISTEMA, IZGLED I ZAŠTITA

3.1 GUI Dizajn

GUI - Grafički korisnički interfejs (engl. Graphical User Interface) predstavlja vrstu
interfejsa koja omogućava korisnicima da interaktiju sa elektronskim uređajima putem
grafičkih ikona i vizualnih indikatora. U softverskom inženjersvu je cilj da se dizajn
grafičkog korisničkog interfejsa maksimalno podesi prema potrebama korisnika. Uspješan
dizajn interfejsa mora da pruži sve potrebne podatke korisniku i to u pravilnom
redoslijedu:

- Grupisanje stavki po značenju,

- Grupisani elementi mogu biti uokvireni,
- Odgovarajuće stavke istaknute podvlačenjem, senčenjem, bojama, posebnim
fontom,
- Čistoća forme postiže se poravnanjem levo ili desno,
- Elegancija i jednostavnost,
- Veličina, kontrast i proporcije,
- Organizacija i vizuelna struktura,
- Stil.

Prilikom korišćenja boja moramo biti vrlo pažljivi, 3 – 4 boje su sasvim dovoljne, takođe
trebamo biti oprezni prilikom slaganja boja.
Dijagramom slučajeva upotrebe se opisuje način korišćenja sistema, zbog toga
korisnički interfejs mora služiti kao sredstvo implementacije slučajeva upotrebe. Prvo ćemo
početi od podjele slučajeva upotrebe po grupama. U jednu grupu ćemo svrstati profesore,
profesore razrednike i osoblje jer će oni koristiti desktop aplikaciju. Druga grupa će biti
sačinjena samo od strane roditelja jer će oni koristiti sistem putem veb aplikacije. Pošto će
program biti podešen da prilikom logovanja prepoznaje ko iz prve grupe ima kakve opcije
unutar programa svima će biti početna strana, strana za prijavu. Za izradu desktop
aplikacije sam koristio Microsoft Visual Studio 2010, aplikacija je bazirana na .NET
Framework-u, a programski jezik koji sam koristio prilikom pisanja programa je C#.
Na slici 3.1 je prikazana strana početna strana za prijavu prilikom pokretanja aplikacije.

45
 Slika 3.1 Početna strana za prijavu

Prilikom logovanja dobijamo meni u skladu sa našim privilegijama pristupa, profesori

dobijaju svoje opcije, razredne starješine svoje a vannastavno osoblje svoje. Na slici 3.2 je
prikaz meni koji dobijaju razrednici prilikom prijave.

Slika 3.2 Prikaz menija

Na sljedećoj slici 3.3 je predstavljen izgled interfejsa na temelju slučajeva upotrebe vezanih
za upis ocjene.

46
 Slika 3.3 Izgled interfejsa za upis ocjene

Na sljedećoj slici 3.4 je predstavljen izgled interfejsa na temelju slučajeva upotrebe vezanih
za izostanke.

47
 Slika 3.4 Izgled interfejsa za izostanke

Na sljedećoj slici 3.5 je predstavljen izgled strane za pregled izvještaja.

48
 Slika 3.5 Prikaz izvještaja

Što se tiče drugog dijela aplikacije tj. veb aplikacije za roditelje sam radio koristeći
HTML56, CSS37, JavaScript i PHP8. Sve skripte koje komuniciraju sa bazom podataka su
pisane u PHP-u. Slika 3.6 predstavlja početni ekran za prijavu kada roditelji unesu link
adresu http://spskola-ednevnik.com u svoj veb pretraživač.

6
HTML5 (engl. HyperText Markup Language) je opisni jezik specijalno namjenjen opisu veb stranica.
7
CSS3 (engl. Cascading Style Sheets) je jezik formatiranja pomoću kog se definiše izgled elemenata
veb stranice.
8
PHP (engl. Hypertext Preprocessor) specijalizovani je skriptni jezik prvenstveno namjenjen za izradu
dinamičkog veb sadržaja i izvodi se na strani servera.

49
 Slika 3.6 Prijava na veb aplikaciju

Na sljedećoj slici 3.7 je predstavljena stranica na kojoj roditelji imaju uvid ocjena,
izostanaka, najava predmetnog profesora i najava razrednog starješine.

50
Slika 3.7 Prikaz informacija za učenika na veb aplikaciji

51
 3.2 Zaštita

Iako se ne odnosi na UML, zaštita prilikom projektovanja sistema je mnogo bitna. Zato
smatram da je veoma važno nešto pomenuti i o tome. Zato je potrebno da osjetljive
podatke, poput lozinki i ostalih ličnih podataka klijenata aplikacije, kriptujemo prije nego ih
uskladištimo u bazu podataka. Takođe je važno imati sigurnosni sistem na veb aplikaciji da
nebi došlo do zlonamjerne krađe sistema. Isto tako je važno imati automatski bekap
podataka u slučaju da ih neko namjerno ili slučajno obriše ili da dođe kvara na računaru na
kom se nalaze podaci. Što se tiče zaštite programa od kopiranja, kao u ovom slučaju gdje je
naručilac programa zatražio da se program podesi na ovih 5 računara unutar
srednjoškolskog centra i da se ne dozvoli kopiranje ja sam uradio jedan sistem zaštite od
kopiranja.
Prilikom instaliranja sistema eDnevnik upotrijebio sam pomoćni podprogram koji sam
isto napisao u C# koristeći Microsoft Visual Studio i on koristi sistemske reference
operativnog sistema Windows koji prepoznaje serijski broj hard diska (diskova) koji su
unutar računara, zatim se pomoću programa serijski brojevi kriptuju i unose u gore
pomenutu tabelu pristup. Slika 3.8 predstavlja izgled aplikacije za prepoznavanje i unos
serijskih brojeva hard diskova na pokrenutom računaru.

Slika 3.8 Izgled aplikacije zaštite

52
 Kada se pokrene klijentska aplikacija eDnevnik, koja isto sadrži sistemske reference,
aplikacija provjeri broj hard diska na klijentskom računaru, uđe u bazu podataka na
udaljenom serveru, iz tabele pristup preuzme kriptovane zapise, dekriptuje ih i poredi da li
se i jedan podudara za pročitanim serijskim brojem. Ako se serijski brojevi podudaraju
pokrene se početna strana programa za logovanje kao što je prikazan prethodno na slici
3.1., a ako se ne podudaraju onda znači da računar nema pristup, prikaže sw obavještenje
korisniku da računar koji koristi nije privilegovan za korišćenje aplikacije eDnevnik i
nakon obavještenja se zatvori.

53
 4 ZAKLJUČAK

Iako se u radu retrospektivno prošlo kroz neke od faza koji bi trebalo da slijede, jer je
analizirani sistem urađen prije analize, to je urađeno iz razloga da se što bolje prikaže
analiza ovog projekta. Teme poput kodiranja, testiranja ili održavanja sistema prelaze
granice ovog rada.
Nakon što se se završi cijeli postupak od slučajeva upotrebe do korisničkog interfejsa,
postavlja se pitanje šta je sljedeće?
Sada kada su završene sve analize sistema i kada su dizajnirani dijelovi sistema
razvojni tim koji je dizajnirao sistem ih pretvara u dokument čija se kopija uručuje klijentu
projekta. Ostale kopije se uručuju programerima koji imaju zadatak da taj dizajn pretvore u
kod.
Ispisani kod je potrebno testirati, nadograditi prema potrebama istraživanja u test fazi,
zatim opet testirati sve dok testirani program ne prođe sve testove. Nakon što program
prođe fazu testiranja onda se sistem može implementirati na krajnje odredište. Potrebno je
napomenuti da analiza slučajeva upotrebe čini osnovu za sprovođenje testova. Nakon toga
se izrađuje dokumentacija o sistemu i priručnici za korišćenje (ako su potrebni). Važno je
istaći da trud koji je uložen u izradu dokumentacije ne treba da bude ništa manji nego
uloženi trud za izradu sistema. Ako su analiza, dizajn i izrada sistema zajedno sa
dokumentacijom dobro urađeni, sve buduće faze poput faze operativnog rada ili održavanja
proteći će bez problema.
Glavna ideja jeste da se u središte pažnje stave analiza i dizajn jer što se oni kvalitetnije
urade tako će svi sljedeći koraci proći veoma jednostavno i sistem će sigurno odgovarati i
protrebama klijenta, za koga se kompletan projekat radi.

54
 LITERATURA

- Miles, Russ i Kim Hamilton. 2006. Learning UML 2.0.

- Larman, Craig. 2004. Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and Iterative Developmen, treće izdanje.
- Flower, Martin. 2003. UML Distilled: A Brief Guide to the Standard Object Modeling
Language, treće izdanje.
- Pfleeger Lawrence, Shari i Joanne M. Atlee. 2006. Softversko inženjerstvo: Teorija i
Praksa, prevod trećeg izdanja. Beograd: Računarski fakultet i CET.
- Podeswa, Howard. 2009. UML For The IT Business Analyst.
- Daoust, Norman. 2012. UML Requirements Modeling For Business Analysts.
- Mala Jeya, D. i S. Geetha. 2013. Object Oriented Analysis and Design Using UML.
- Page-Jones, Meilir. 1999. Fundamentals of Object-Oriented Design in UML.
- W. Ambler, Scott. 2005. The Elements OF UML(TM) 2.0 Style.
- Rumbaugh, James, Ivar Jacobson i Grady Booch. 2004. The Unified Modeling
Language Reference Manual, drugo izdanje.
- Dennis, Alan, Barbara Haley Wixom i David Tegarden. 2012. Systems Analysis and
Design with UML.
- Blaha, Michael. 2014. UML Database Modeling Workbook.
- Gomaa, Hassan. 2011. Software Modeling and Design: UML, Use Cases, Patterns, and
Software Architectures.

55