SVEUČILIŠTE U ZAGREBU

FAKULTET ORGANIZACIJE I INFORMATIKE

VARAŢDIN

Vanja Novak

Tomislav Belcar

mStorage

PROJEKT IZ KOLEGIJA ANALIZA I RAZVOJ PROGRAMA

Varaţdin, 2011.
 SVEUČILIŠTE U ZAGREBU
FAKULTET ORGANIZACIJE I INFORMATIKE
VARAŢDIN

Vanja Novak
Redoviti student
Broj indeksa: 39642/10-R
Smjer: Programsko inţenjerstvo
Diplomski studij

Tomislav Belcar
Redoviti student
Broj indeksa: 38787/09-R
Smjer: Baze podataka i baze znanja
Diplomski studij

mStorage
PROJEKT IZ KOLEGIJA ANALIZA I RAZVOJ PROGRAMA

Nositelj kolegija: Prof.dr.sc. Neven Vrček

Suradnici: Zlatko Stapić, dipl. inf., asistent

Dr.sc. Ruben Picek, asistent

Varaţdin, rujan 2011.

Sadrţaj

1. Uvod ............................................................................................................................................ 1

2. Korisnički zahtjevi .................................................................................................................... 3

3. Odabir tehnologije i metodika razvoja .................................................................................... 5

4. Projektna dokumentacija ......................................................................................................... 6

4.1. Projektni tim ......................................................................................................................... 6

4.2. Aktivnosti projekta ............................................................................................................... 8

4.3. Plan projekta ......................................................................................................................... 9

4.3.1. Aktivnosti projekta, trajanje, resursi ........................................................................... 10

4.3.2. Gantogram ................................................................................................................... 11

4.3.3. Cijena projekta............................................................................................................. 12

4.3.4. Tijek novca kroz projekt ............................................................................................... 13

5. Ponuda ...................................................................................................................................... 14

6. Modeliranje – UML dijagrami ............................................................................................... 15

6.1. Dijagrami slučajeva korištenja ........................................................................................... 15

6.1.1. Dijagram slučajeva korištenja – Skladištar ................................................................. 16

6.1.2. Dijagram slučajeva korištenja - Direktor .................................................................... 17

6.2. Dijagram slijeda .................................................................................................................. 24

6.2.1. Logiranje u sustav ........................................................................................................ 25

6.2.2. Izrada primke ............................................................................................................... 27

6.2.3. Izrada otpremnice ........................................................................................................ 29

6.2.4. Pregled knjiženja ......................................................................................................... 31

6.2.5. Dodavanje poslovnog partnera.................................................................................... 33

6.2.6. Dodavanje zaposlenika ................................................................................................ 35

I
 6.2.7. Dodavanje skladišta ..................................................................................................... 37

6.3. Dijagram aktivnosti ............................................................................................................ 39

6.3.1. Logiranje u sustav ........................................................................................................ 41

6.3.2. Izrada primke ............................................................................................................... 43

6.3.3. Izrada otpremnice ........................................................................................................ 45

6.3.4. Pregled knjiženja ......................................................................................................... 47

6.3.5. Dodavanje poslovnog partnera.................................................................................... 49

6.3.6. Dodavanje zaposlenika ................................................................................................ 51

6.3.7. Dodavanje skladišta ..................................................................................................... 53

6.4. ERA model ......................................................................................................................... 55

6.4. ERA model ......................................................................................................................... 55

6.5. Relacijski model ................................................................................................................. 58

6.6. Dijagrami klasa ................................................................................................................... 59

6.6.1. deskStorage .................................................................................................................. 60

6.6.2. mStorage ...................................................................................................................... 63

7. Korisničke upute ..................................................................................................................... 66

7.1. deskStorage ......................................................................................................................... 66

7.2. mStorage ............................................................................................................................. 72

II
1. Uvod

Projekt kojeg smo nazvali mStorage radi se u malom timu koji je sastavljen od dvoje
ljudi. Iz tog razloga bilo bi dobro iskoristiti neke od agilnih metoda u rješavanju zadatka. Kao
prvo bitno je definirati aktivnosti, kako bi mogli procijeniti vrijeme koje će nam biti potrebno za
izradu aplikacije, a prema tome odrediti troškove izrade aplikacije.

Iz razloga što je vrijeme za izradu ovog projekta fiksno, potrebno ja tako i planirati razvoj
same aplikacije. To je razlog kako moţemo utjecati na kvalitetu aplikacije. Najvaţniji cilj nam je
izrada pouzdane aplikacije što veće kvalitete, te se toga i pridrţavamo u svom radu. Tablica 1.1.
prikazuje je naš odnos prema projektu u kojoj su nam definirani rokovi. Sami smo izabrali
resurse vremena kako bi mogućnosti koje će aplikacija nuditi biti na dostatnoj razini.

Tablica 1.1. Fiksni Izabrani Promjenjivi

Raspored 

Resursi 

Mogućnosti 

Tablica 1.1. Naš odnos prema projektu

Prema našim procjenama najviše vremena za izradu projekta potrošiti ćemo na

definiranje samog projekta i shvaćanje korisničkih priča kako bi aplikacija ispala što kvalitetnije.
Tako da nakon modeliranja cijelog programa imamo dokumentaciju iz koje moţemo vrlo brzo i
na definiran način isprogramirati ono što se traţi.
Projekt mStorage bazira se na izradi aplikacije koje omogućavaju osnovne funkcije za
praćenje ulaza i izlaza robe na skladištu. Aplikacije omogućavaju tvrtkama koje imaju
dislocirana skladišta svoje robe da preko mobilne aplikacije aţuriraju stanja u tim skladištima, a
preko stolne verzije prate stanja na skladištima i tako izbjegnu dodatne troškove. Skladištar moţe
na licu mjesta kod primitka robe utipkati u svoj Pocket PC robu koju je primio, a promjene će se
odmah nakon sinkronizacije baza biljeţiti na serveru i stanje zaliha će uvijek biti aţurno.
Direktor poduzeća ili direktor nabave mogu s računala koje ima instaliranu stolnu aplikaciju
pristupiti podacima o artiklima u pojedinim skladištima i tako uvijek biti u toku i znati kada treba
naručiti pojedini artikl.

1
 Realizaciji ovog projekta pristupili smo preko iterativnog pristupa razvoja aplikacije gdje
se raspoređuje potrebno vrijeme na izradi projekta na nekoliko manjih projekata koje nazivamo
iteracijama. To nam omogućava da se fokusiramo na kratkoročne ciljeve i tako ih postupno
završavamo s velikom uspješnošću. U prvoj iteraciji isplanirali smo nekoliko ciljeva koje
moramo postići, a vidljivi su u djelu Iterativni proces. Vaţno je da prilikom početka iterativnog
procesa imamo isplanirano što u tom iterativnom procesu moramo napraviti, koji je prioritet
pojedinih aktivnosti i vrijeme trajanja realizacije tih aktivnosti.

U ovoj projektnoj dokumentaciji opisani su razni UML dijagrami koji nam uvelike
olakšavaju realizaciju samog projekta, kao što su, dijagrami slučajeva korištenja, dijagrami
aktivnosti, dijagrami slijeda, ERA dijagram te dijagram klasa.

Izradi projektne dokumentacije pristupili smo preko prikupljenih korisničkih zahtjeva.

Naš naručitelj nam je usmeno objasnio što očekuje od same aplikacije, koje funkcionalnosti su
njemu potrebne te nam je skicirao nekoliko ekrana kako on zamišlja tu svoju aplikaciju.

2
2. Korisnički zahtjevi

Korisnik preko svojih zahtjeva izraţava ţelju i potrebe koje bi on ţelio da mu mi

omogućimo izradom aplikacije. To je moţda i najvaţniji dio samog projekta. Ovisno o tome
kako i na koji način pristupimo kod dogovaranja korisničkih zahtjeva sa korisnikom takva će biti
i kvaliteta same aplikacije. Ukoliko se maksimalno potrudimo i što bolje uvidimo što naš
korisnik ţeli poslije će nam biti lakše kod modeliranja slučajeva korištenja te programiranja
same aplikacije. Ţelje korisnika moţe se svesti u samo nekoliko rečenica. U tim rečenicama
rečeno je gotovo sve što naš korisnik potraţuje od nas. Evo i zahtjeva:

„Ţelim aplikaciju preko koje će moj skladištar kod zaprimanja ili otpremanja robe u svoj
Pocket PC upisivati artikle, odnosno izrađivati primke i otpremnice, koje ću ja na svojem
računalu odmah moći vidjeti bez da moram njega nazivati i traţiti da mi faksira primku ili
otpremnicu. Isto tako ţelim da mi se omogući dodavanje novih poslovnih partnera, novih
zaposlenik i novih skladišta ukoliko bude potrebe za tim.“

Mi kao izvršitelji ovu rečenicu protumačili smo i u sljedećih nekoliko redaka opisali što
zapravo korisnik od nas očekuje. Korisnik zahtijeva da se napravi aplikacija koja će mu
omogućiti upravljanje svim ulazima i izlazima iz svih skladišta koje posjeduje. On naime ima u
posjedu nekoliko skladišta koja su prostorno dislocirana i ţeli da skladištari koji su zaduţeni za
pojedina skladišta upisuju ulaz ili izlaz proizvoda u skladište i da ih on nakon sinkronizacije baza
moţe vidjeti na svojem računalu u poduzeću.

Nakon razgovora s korisnikom, zaključili smo da korisniku treba mobilna aplikacija koja
će se pokretati na Pocket PC-u i stolna aplikacija koja će omogućiti praćenje stanja zaliha na
svim skladištima iz bilo kojeg drugog računala u poduzeću s pristupom na Internet. Mobilna
aplikacija će se koristiti u udaljenim skladištima gdje će se skladištari prvo morati prijaviti u
sustav, odnosno obaviti identifikaciju i autentikaciju kako ne bi došlo do bilo kakvih sigurnosnih
problema prilikom upravljanja skladištem. Nakon što se skladištar prijavi odabire neku od
ponuđenih akcija na glavnom izborniku. Nudi mu se unos materijala u skladište preko skladišne
primke te izrada otpremnice, odnosno izlaza robe iz skladišta. Skladištar kad dobije robu otvara
izradu nove primke i unosi primljene materijale ili proizvode u primku. Kada završava sa
izradom primke, on ju sprema jednostavnim klikom. Izradom otpremnice iz skladišta se
otpremaju proizvodi ili materijali u proizvodnju ili neko drugo skladište.

3
 Stolna aplikacija isto kao i mobilna aplikacija mora sadrţavati neki tip sigurnosnog ulaza
u aplikaciju, pa se javlja potreba za implementiranjem prijave korisnika. U ovoj aplikaciji mora
se vidjeti izvještaj svih ulaza i izlaza po svim skladištima i poţeljno je da se moţe upravljati
korisnicima koji pristupaju stolnoj i mobilnoj aplikaciji. Stolna aplikacija će biti postavljena na
istom mjestu kao i centralna baza, a to mora biti provjereno i sigurno web mjesto za koje
moţemo osigurati pravljenje sigurnosnih kopija podataka.

Obje aplikacije moraju biti intuitivne za korištenje, a mobilna aplikacija zahtijeva

određenu brzinu pristupa i unošenja podataka kako ne bi bilo zastajkivanja kod dolaska robe i
njene evidencije.

4
3. Odabir tehnologije i metodika razvoja

Kako bi razvili što kvalitetniji programski proizvod s što manje troškova, većinom ćemo
se bazirati na korištenje tehnologija koje su nam dostupne preko fakulteta, a koje predstavljaju
izuzetno kvalitetno rješenje. Kako bi izradili korisnu projektnu dokumentaciju koristit ćemo
Microsoft Office paket. Za planiranje projekta koristit ćemo alat Microsoft Project 2007 u kojem
moţemo detaljno planirati sve aktivnosti, njihov tijek odvijanja, sve resurse i njihova zaduţenja
te na kraju dobiti detaljne izvještaje u obliku gantograma ili izračuna proračuna projekta.
Nadalje, za modeliranje ćemo koristiti alat Visual Paradigm u kojem izrađujemo sve UML
dijagrame. Izrađujemo dijagrame slučajeva korištenja, dijagrame aktivnosti, dijagrame slijeda, te
dijagram klasa i ERA model. Za programiranje koristimo razvojno okruţenje Microsoft Visual
Studio 2010. Za bazu podataka koristit ćemo Microsoft SQL Server 2005, a kao okruţenje za
upravljanje bazom podataka koristit ćemo Microsoft SQL Server Management Studio Express.

Metodika razvoja korištena u ovom projektu temelji se na RUP (engl. Rational Unified
Process) metodici koju prema potrebi prilagođavamo svojim potrebama i potrebama projekta.
Prema RUP metodici, projekt ima svoj ţivotni ciklus koji se sastoji od 4 faze. Te faze su slične
vodopadnom modelu razvoja programskog proizvoda, ali glavna prednost leţi u iterativnom
razvoju koji se odvija u svakoj od pojedinih faza. Slika 4.1 prikazuje faze prema RUP metodici u
odnosu na vrijeme.

Slika 3.1. RUP faze i discipline

5
4. Projektna dokumentacija

4.1. Projektni tim

Tim koji će raditi na projektu mStorage sastoji se od dva člana. Bilo koji od dva član na
projektu zaduţen je za dio aktivnosti koje dobio nakon podjele poslova, dok je voditelj projekta
odgovoran za rad svih članova tima. Kako imamo mali tim potrebno je ravnopravno podijeliti i
poslove u njemu, a sam projekt moţemo u grubo podijeliti na poslove, odnosno aktivnosti prije
sklapanja ugovora, ili davanje ponude i aktivnosti poslije sklapanja ugovora.

 Aktivnosti koje se izvršavaju na projektu prije potpisivanja ugovora uključuje:

 definiranje osnovnih točaka projekta

 definiranje osnovnih aktivnosti projekta

 kreiranje trajanja projekta

 definiranje budţeta projekta

 izrada ponude naručitelju

 Aktivnosti koje se izvršavaju na projektu prilikom izrade aplikacije:

 opis i specifikacija korisničkih zahtjeva

 kreiranje UML dijagrama

 kreiranje ERA modela i baze podataka

 izrada skica formi programa

 programiranje aplikacije

 testiranje aplikacije

Pošto se naš tim sastoji samo od samo dva člana, većina će zaduţenja između nas biti
podijeljena, tako ćemo i „developement“ dio međusobno podijeliti.

6
Slika 4.1. Zaduţenja za pojedinog člana tima

7
4.2. Aktivnosti projekta

I. Planiranje projekta
1. Sastanak projektnog tima
2. Pisanje plana projekta
3. Razmatranje i analiza korisničkih zahtjeva
4. Sastanak projektnog tima i podjela aktivnosti
5. Izrada projektne dokumentacije
II. Realizacija projekta
1. Modeliranje korisničkih zahtjeva
6. Analiza poslovne domene
2. Izrada UML dijagrama
7. Izrada dijagrama korištenja
8. Izrada dijagrama slijeda
9. Izrada dijagrama aktivnosti
10. Izrada ERA modela
11. Izrada dijagrama klasa
3. Modeliranje podataka
12. Izrada SQL skripte
13. Izrada idejnih skica ekrana
4. Izrada aplikacije
14. Stvaranje baze podataka iz postojećeg ERA modela
15. Dizajniranje sučelja
16. Izrada modula na temelju dijagrama korištenja
17. Povezivanje modula u cjelinu
5. Testiranje aplikacije
18. Alfa testiranje
19. Beta testiranje
20. Ispravljanje grešaka
6. Aţuriranje projektne dokumentacije
20. Aţuriranje dokumentacije
21. Pisanje korisničkog dokumentacije
5. Isporuka aplikacije
22. Instalacija aplikacije
23. Osposobljavanje korisnika
24. Zaključivanje projekta s klijentom
8
4.3. Plan projekta

Detaljni vremenski plan projekta mStorage izrađen je u alatu Microsoft Project 2007.

Tim15 sastoji se od dva programera/arhitekta koji u paru mogu funkcionirati kao veći tim
i raditi poslove svih uloga kao što su primjerice projektni menadţer, arhitekt, analitičar, razvojni
programer i tester aplikacija. Pošto je naš tim vrlo malen svaki član tima obavlja sve uloge koje
smo prethodno naveli. Svako jutro obavljaju se sastanci s nogu gdje se raspravlja o tome što će
tko napraviti i kako će to realizirati. Prije svake vaţnije aktivnosti rade se i dodatni sastanci gdje
se raspravlja kako će se nešto napraviti te koji bi bio najbolji način rješavanja pojedinog
problema.

Vremenski plan projekta izradili smo u alatu Microsoft Project 2007 u kojem imamo
nekoliko ključnih točaka. Prvi dio projekta odnosi se na detaljno planiranje cjelokupnog projekta
i izradu plana dok se drugi dio odnosi na realizaciju projekta. Realizacija projekta je pak
podijeljena na modeliranje korisničkih zahtjeva, modeliranje podataka i izradu stolne i mobilne
aplikacije. Kao početak projekta stavili smo 23. lipnja 2011, a okvirni završetak projekta bi bio
29. kolovoza 2011. Radno vrijeme ne moţemo definirati pošto su ljudi koji rade na projektu
studenti koji obveze izvršavaju prema dogovoru i prilagođavaju se planu projekta koji to i uzima
u obzir. Resursi korišteni na ovom projektu su dva računala koja su u vlasništvu članova tima te
po potrebi posuđuju prijenosno računalo.

9
4.3.1. Aktivnosti projekta, trajanje, resursi

Slika 4.2. prikazuje popis aktivnosti, trajanje i resurse koji se upotrebljavaju prilikom
izvedbe projekta.

Slika 4.2. Popis aktivnosti, trajanje, i resursi pridruţeni aktivnostima

10
4.3.2. Gantogram

Ganttov dijagram, odnosno gantogram je vremenski dijagram koji prikazuje popis

aktivnosti u vremenu. On nam omogućava da lakše pratimo tijek našeg projekta i daje nam uvid
u resurse koji se koriste na pojedinim aktivnostima. Preko gantograma moţemo pratiti
eventualna odstupanja i lakše se prilagoditi nekim neţeljenim situacijama koje nastaju na
projektu. Slika 4.3. prikazuje gantogram našeg projekta.

Slika 4.3. Gantogram projekta

11
4.3.3. Cijena projekta

Proračun projekta je izrađen na temelju raspodjele resursa po aktivnostima vidljivih u

vremenskom planu projekta. U projektnom timu sudjeluju dva člana: Vanja Novak,Tomislav
Belcar. Svaki članova kao opremu zasebno koristi vlastito računalo. Cijena bruto satnice svakog
člana tima procijenjena je na 20 kn/h.. Isto tako u cijenu je uračunati i trošak opreme (računala 1
i računala 2) od 7kn/h. Proračun projekta je prikazan na slici 4.4..

Iz proračuna projekta je vidljivo da najviše novčanih sredstava otpada na izradu projektne

dokumentacije te izradu aplikacije, budući da na toj aktivnost sudjeluju svi članovi tima sa svom
opremom.

Slika 4.4. Cijena projekta

12
4.3.4. Tijek novca kroz projekt

Slika 4.5. Tijek novca kroz projekt

13
5. Ponuda

Na temelju zaprimljenih zahtjeva izradili smo ponudu za naručitelja mStorage sustava.

Tim15
OIB: 123456789
Adresa: Pavlinska 2, 42000 Varaždin
Tel: 097/777-777
Email: foi@foi.hr

Ponuda programskog proizvoda mStorage

Zaprimili smo Vaš upit za izradu programskog proizvoda za upravljanje skladištima te smo na
temelju prikupljenih korisničkih zahtjeva izradili ovu ponudu.

Naš sustav mStorage će Vam omogućiti izradu digitalnih primki i otpremnica te praćenje svih
nastalih knjiţenja preko centralne aplikacije. Rok izrade cjelokupnog sustava je 4 mjeseca od
datuma sklapanja ugovora i prihvaćanje ponude. Cijena sustava procijenjena prema danim
zahtjevima iznosi 12080,67 kn u što spada i dostupnost našeg stručnjaka 24 sata na dan za prvih
mjesec dana korištenja sustava.

Odrţavanje sustava vršimo besplatno u slučaju ispadanja istog, dok se dodatna odrţavanja kao i
sve dodatne nadogradnje sustava naplaćuju prema dogovorenom cjeniku.

Srdačan pozdrav,

Tim15.

Datum: Potpis:

________________ ________________

14
6. Modeliranje – UML dijagrami

U ovom djelu projektne dokumentacije prikazani su svi izrađeni dijagrami za naš projekt.
Izradili smo dva dijagrama slučajeva, jednog za skladištara, a drugog za direktora te nekoliko
detaljnih dijagrama za neke vaţnije slučajeve korištenja.

6.1. Dijagrami slučajeva korištenja

Dijagram slučaja korištenja (eng. UseCase) koristi se za opis osnovnih funkcionalnih

cjelina i njihovo ponašanje, te za opis vanjskih učesnika i njihove interakcije sa sustavom. Uz
pomoć UseCase dijagrama prikazali smo primjer rada sustava sa stajališta korisnika, odnosno
učesnika. Osnovni koncepti UseCase dijagrama su:

 slučaj korištenja (eng. UseCase)

 učesnik (eng. Actor)

 veza između njih

Svaki slučaj korištenja ima svoju specifikaciju, odnosno opisni tekst scenarija koji se
odvija kada korisnik obavlja neki slučaj korištenja. Imamo opisane sve moguće scenarije koji se
očekuju pri radu sa aplikacijom.. Specifikacije slučajeva korištenja su zapravo najvaţniji dio
modela slučajeva korištenja, dok dijagrami sluţe za ilustraciju scenarija.

15
6.1.1. Dijagram slučajeva korištenja – Skladištar

Dijagramima slučajeva korištenja definiramo slučajeve korištenja odnosno korisničke

zahtjeve koje smo zaprimili od naručitelja. Slika 6.1 prikazuje dijagram slučajeva korištenja za
ulogu skladištara.

Slika 6.1. Dijagram slučajeva korištenja za skladištara

U našem modelu slučajeva korištenja imamo samo dva učesnika. Prvi od njih kojeg ćemo
ukratko objasniti jest skladištar. Skladištar bi uz pomoć aplikacije trebao imati mogućnost
obavljanja nekih od funkcija koje su vezane za sam problem. On koristi mobilnu aplikaciju koja
mu omogućuje navedene funkcionalnosti:

 logiranje u sustav

 upravljanje knjiţenjima

 izrada primke

 izrada otpremnice

 sinkronizacija baze

16
 Kako bi se dodijelili resursi aplikaciji za koje skladištar posjeduje ovlasti, on se mora
prijaviti u aplikaciju, što znači da je ova aktivnost obavezna i bez nje nije moguće ništa raditi na
aplikaciji. Sukladno tome sve slučajeve korištenja koje imamo u našem UseCase dijagramu
povezani su vezom uključi (<<include>>) sa slučajem korištenja Logiranje u sustav. Kada se
skladištar uspješno logira u aplikaciju tada on dobiva jasan pregled sučelja mobilne aplikacije. Iz
toga glavnog ekrana on moţe pozvati bilo koji od navedenih slučajeva korištenja. Ukratko,
aplikacija omogućuje skladištaru da nakon što se uspješno logira u istu ima mogućnost da
upravlja knjiţenjem, bilo da ţeli izraditi primke, odnosno otpremnice. Još jedan slučaj korištenja
je sinkronizacija baza podataka koja se vrši kada glavna baza ne sadrţava podatke koje su
upisani u mobilnoj bazi podataka.

6.1.2. Dijagram slučajeva korištenja - Direktor

Slika 6.2. prikazuje dijagram slučajeva korištenja za direktora odnosno korisnika stolne
aplikacije.

Slika 6.2. Dijagram slučajeva korištenja za direktora

17
 Kao i kod prvog slučaja korištenja za korisnika skladištara, tako I u ovom za korisnika
direktora vaţno je da uz pomoć aplikacije isti ima mogućnost obavljanja nekih od funkcija koje
su vezane za sam problem. Direktor za razliku od skladištara koristi stolnu aplikaciju koja mu
omogućuje navedene funkcionalnosti:

 logiranje u sustav

 pregled knjiţenja

 dodavanje poslovnog partnera

 dodavanje zaposlenika

 dodavanje skladišta

 sinkronizacija baze

Direktor se također prije upotrebe aplikacije mora uspješno prijaviti u sustav inače mu je
aplikacija beskorisna. Sukladno tome sve slučajeve korištenja koje imamo u našem UseCase
dijagramu za direktora povezani su vezom uključi (<<include>>) sa slučajem korištenja
Logiranje u sustav. Direktoru se pruţa mogućnost da kroz samu aplikaciju dodaje nove poslovne
partnere u bazu, moţe dodavati zaposlenike koji mogu pristupati aplikaciji, moţe dodavati nova
skladišta, moţe pregledavati knjiţenja te sinkronizirati baze podataka. Najvaţniji slučaj
korištenja je pregledavanje knjiţenja i on je najvaţniji za stolnu aplikaciju.

18
1. Logiranje u sustav

1. Naziv slučaja korištenja: Logiranje u sustav

2. Učesnik: Skladištar i direktor

3. Opis slučaja korištenja: Pretpostavljamo da skladištar ili direktor ţeli vršiti interakciju
kako sa mobilnom tako i sa stolnom aplikacijom. U tom slučaju aplikacija prikazuje
formu za logiranje na ekranu. Skladištar ili direktor ima za zadaću unijeti svoje
korisničko ime i lozinku, kako bi mogao ući u samu aplikaciju. Nakon napisanog
korisničkog imena i lozinke sustav provjerava podatke. U slučaju da su podaci ispravni,
otvara se aplikacija, i skladištar ili direktor mogu vršiti radnje koje im aplikacija
omogućuje. Ukoliko nisu podaci valjani, opet mu se javlja forma za logiranje sve dok ne
unese ispravne podatke.
4. Početni dogaĎaj: Pokretanje aplikacije
5. Scenarij: U slučaju da skladištar ili direktor ispravno unesu podatke za logiranje,
omogućen im je ulaz u aplikaciju, s druge strane ako podaci koje unesu skladištar ili
direktor nisu valjani onemogućen im je ulaz u aplikaciju i javlja se greška.
6. Uvjeti potrebni za izvršenje: Skladištar ili direktor mora unijeti točne podatke prilikom
logiranja, odnosno točno korisničko ime i lozinku. Isto tako ti podaci moraju postojati u
bazi podataka.
7. Promjene po izvršenju: Skladištar ili direktor ima omogućen uvid u podatke a isto tako
moţe i uređivati iste.
8. Vaţnost: Slučaj korištenja Logiranje je presudan za projekt, iz razloga što skladištar ili
direktor prije svega ostalog mora uspješno izvršiti isti.

19
2. Izrada nove primke

1. Naziv slučaja korištenja: Izrada primke

2. Učesnik: Skladištar
3. Opis slučaja korištenja: Nakon što se uspješno prijavio u sustav skladištar ima
mogućnost izrade primke. U slučaju da to poţeli, on mora izabrati opciju za izradu
primke. Nakon odabira opcije popunjava formu za unos primke i navedeni podaci
pospremaju se u bazu podataka ukoliko to poţeli.
4. Početni dogaĎaj: Odabir opcije za izradu primke
5. Scenarij: Nakon izbora opcije za izradu primke, javlja se forma za unos primke.
Slijedeći korak je ispunjavanje iste i spremanje primke. Na kraju se podaci iz primke
spremaju u bazu podataka.
6. Uvjeti potrebni za izvršenje: Skladištar mora biti prijavljen u aplikaciju putem podataka
koje koristi za logiranje, te nakon toga ima mogućnost izrade primke.
7. Promjene po izvršenju: Skladištar ima omogućen uvid u novo unesene podatke a isto
tako moţe i uređivati iste.
8. Vaţnost: Slučaj korištenja izrada primke je vaţan za korisnika skladištara, iz razloga što
skladištar pomoću izrade primke unosi nove podatke u bazu podataka.

3. Izrada nove otpremnice

1. Naziv slučaja korištenja: Izrada otpremnice

2. Učesnik: Skladištar

3. Opis slučaja korištenja: Druga mogućnost koju ima skladištar nakon što se uspješno
prijavio u sustav je izrada otpremnice. To izvršava na način da izabere opciju za izradu
otpremnice. Nakon odabira opcije popunjava se danu inicijaliziranu forma i navedeni
podaci pospremaju se u bazu podataka.

4. Početni dogaĎaj: Odabir opcije za izradu otpremnice

5. Scenarij: Prilikom izbora opcije za izradu otpremnice, inicijalizira se forma za istu.

Slijedeći korak je popunjavanje iste i spremanje. Na kraju se podaci koji su uneseni u
otpremnicu spremaju u bazu podataka.

6. Uvjeti potrebni za izvršenje: Skladištar mora biti prijavljen u aplikaciju putem podataka
koje koristi za logiranje, te nakon toga ima mogućnost izrade otpremnice.

20
 7. Promjene po izvršenju: Skladištar ima omogućen uvid u novo unesene podatke.

8. Vaţnost: Izrada otpremnice od velike je vaţnosti za skladištara i samu aplikaciju. Sama

otpremnica omogućuje skladištaru uvid u podatke koje je upisao u istu, dok su ti podaci
pospremljeni u bazu podataka.

4. Dodavanje novog poslovnog partnera

1. Naziv slučaja korištenja: Dodavanje poslovnih partnera

2. Učesnik: Direktor

3. Opis slučaja korištenja: Kada se direktor uspješno prijavi u sustav imam mogućnost
dodavanja poslovnih partnera. Odabirom te opcije javlja se forma koja se popunjava se
ţeljenim podacima, te se nakon toga vrši pospremanje podataka ukoliko se to zaţeli ili se
odustaje od toga.

4. Početni dogaĎaj: Odabir opcije za dodavanje poslovnog partnera

5. Scenarij: U slučaju da se izabere opcija dodavanja novog poslovnog partnera, pojavljuje

se forma za upis novog poslovnog partnera. Nakon što direktor unese podatke ima dvije
solucije. Prva je da potvrdi spremanje unesenih podataka, a druga je da odustane od
spremanja podataka.

6. Uvjeti potrebni za izvršenje: Direktor mora biti uspješno prijavljen u aplikaciju. Tek
nakon toga ima mogućnost da odabere opciju za unos novog poslovnog partnera.

7. Promjene po izvršenju: Direktor ima uvid u novo unesene podatke o poslovnim

partnerima.

8. Vaţnost: Unos novog poslovnog partnera vaţan je za direktora, iz razloga ukoliko se javi
neki novi poslovni partner. Nakon što se prijavi direktor ima mogućnost unosa novog
poslovnog partnera te svih potrebnih informacija koje su vezane uz njega u bazu
podataka.

21
5. Dodavanje novog zaposlenika

1. Naziv slučaja korištenja: Dodavanje zaposlenika

2. Učesnik: Direktor

3. Opis slučaja korištenja: Nakon prijave u sustav direktor je u mogućnosti dodati novog
zaposlenika ukoliko za to postoji potreba. Izabire opciju dodavanja novog zaposlenika, te
popunjava formu sa podacima vezanim za novog zaposlenika. Nakon toga vrši spremanje
iste ili odustaje od toga.

4. Početni dogaĎaj: Odabir opcije za dodavanje zaposlenika

5. Scenarij: Izabire se opcija za dodavanje novog zaposlenika, te se popunjava

inicijalizirana forma. Nakon popune postoje mogućnosti spremanja ili odustajanje od
spremanja danih podataka.

6. Uvjeti potrebni za izvršenje: Direktor mora biti uspješno prijavljen u aplikaciju. Nakon
toga izabire opciju za unos novog zaposlenika.

7. Promjene po izvršenju: Direktor ima uvid u novo unesene podatke o zaposleniku.

8. Vaţnost: Unos novog zaposlenika bitan je za samu aplikaciju, iz razloga ukoliko se javi
neki novi zaposlenik. Nakon što se prijavi direktor ima mogućnost unosa novog
zaposlenika te svih potrebnih informacija koje su vezane uz njega u bazu podataka.

6. Dodavanje novog skladišta

1. Naziv slučaja korištenja: Dodavanje skladišta

2. Učesnik: Direktor

3. Opis slučaja korištenja: Ukoliko je direktor uspješno prijavljen u sustav ima mogućnost
dodavanja novog skladišta. Kad odabere opciju javlja se forma koju popunjava se
ţeljenim podacima, te se nakon toga vrši pospremanje podataka ukoliko se to zaţeli ili se
odustaje od toga.

4. Početni dogaĎaj: Odabir opcije za dodavanje skladišta

5. Scenarij: Dodavanje novog skladišta radi se tako da direktor izabire opciju za unos
novog skladišta. Prilikom toga se pojavljuje forma za upis novog skladišta. Nakon što

22
 direktor unese podatke on je u stanju te podatke pospremiti u bazu podataka ili odustati
od pospremanja.

6. Uvjeti potrebni za izvršenje: Direktor mora biti uspješno prijavljen u aplikaciju.

Ukoliko je uspješno prijavljen ima mogućnost unosa novog skladišta.

7. Promjene po izvršenju: Direktor ima uvid u novo unesene podatke o skladištu.

8. Vaţnost: Ukoliko dođe do situacije da nema više mjesta u skladištima koje koristimo,
traţi se neko novo skladište te se vrši unos novog skladišta u bazu podataka. Nakon što se
prijavi direktor ima mogućnost unosa novog skladišta te svih potrebnih informacija koje
su vezane uz njega.

7. Pregled knjiţenja

1. Naziv slučaja korištenja: Pregled knjiţenja

2. Učesnik: Direktor

3. Opis slučaja korištenja: Ukoliko je direktor uspješno prijavljen u sustav ima mogućnost
pregledavanja knjiţenja koje je unio skladištar, bilo da ţeli pregledati primke ili
otpremnice.

4. Početni dogaĎaj: Odabir opcije za pregled knjiţenja

5. Scenarij: Direktor izabire opciju pregleda knjiţenja koja se sastoji od dvije mogućnosti.
Prva mogućnost je da pregledava primke a druga mogućnost je da pregledava
otpremnice.

6. Uvjeti potrebni za izvršenje: Direktor mora biti uspješno prijavljen u aplikaciju.

Ukoliko je uspješno prijavljen ima mogućnost pregleda knjiţenja, bilo da ţeli
pregledavati primke ili otpremnice.

7. Promjene po izvršenju: Direktor ima uvid u obavljena knjiţenja od strane skladištara.

8. Vaţnost: Ukoliko direktor iz bilo kojeg razloga ţeli provjeriti neku od primki ili
otpremnica to mu ova opcija omogućuje vrlo lako. Uz pomoć te opcije veoma lako dolazi
do podataka koji ga zanimaju, a vezani su uz knjiţenja.

23
6.2. Dijagram slijeda

Koristi se za detaljan prikaz pojedinog slučaja korištenja kojim je prikazan detaljan slijed
akcija za taj slučaja korištenja. Dijagram slijeda (eng. Sequence Diagram) prikazuje vremenski
uređenu interakciju između instanci koje sudjeluju u njoj. Pod interakcijom se podrazumijeva
skup poruka koje se izmjenjuju između instanci objekata koje surađuju radi postizanja nekog
učinka.

U ovom djelu prikazat ćemo dijagrame slijeda za najvaţnije slučajeve korištenja. Tako
ćemo prikazati navedene dijagrame slijeda za slučaj korištenja Logiranje u sustav koji je jednak
za stolnu i mobilnu aplikaciju, za slučaj korištenja izrada primke i izrada otpremnice koji se
odnosi na skladištara i mobilnu aplikaciju, za slučaj korištenja pregled knjiţenja kojeg provodi
direktor na svom stolnom računalu te dodavanje poslovnih partnera, dodavanje zaposlenika i
dodavanje skladišta koji se također odnosi na direktora i stolnu aplikaciju. Što se tiče konkretnih
dijagrami slijeda oni se sastoje od tri instance objekata koji sudjeluju u aplikaciji, a većinom su
to korisnik (bilo da se govori o skladištaru ili direktoru), aplikacija (mobilna ili stolna) i razni
moduli.

24
6.2.1. Logiranje u sustav

Slika 6.3. Dijagram slijeda: Logiranje u sustav

25
 Dijagram slijeda Logiranje u sustav sastoji se od tri učesnika: korisnik (skladištar ili
direktor), aplikacija (mStorage ili dStorage) i modul baze podataka.
Slijed započinje korisnik koji pokreće sustav. Nakon pokretanja aplikacija inicijalizira
objekt i prikazuje obrazac za prijavu. Nakon toga izvršava se petlja sve dok se korisnik uspješno
ne prijavi u aplikaciju. To se radi na način da korisnik najprije unosi podatke za logiranje u
obrazac prijave, a nakon toga aplikacija upisane podatke šalje bazi podataka koja te iste podatke
provjerava. Odgovor da li podaci koji su uneseni postoje u bazi šalje se natrag aplikaciji, koja
nakon toga u slučaju da su podaci uspješno uneseni prikazuje aplikaciju ili ispisuje grešku u
slučaju da su podaci pogrešni. Nakon što se izvrši uspješna prijava u aplikaciju dealocira se
objekt.

26
6.2.2. Izrada primke

Slika 6.4. Dijagram slijeda: Izrada primke

27
 Kod ovog dijagrama slijeda imamo isto tako tri učesnika, a to su skladištar kao korisnik,
mobilna aplikacija (mStorage) i modul za izradu primke. Proces započinje nakon što skladištar
odabere opciju za izradu primke. Aplikacija pritom inicijalizira objekt i prikazuje formu za
izradu primke te zahtjeva podatke o artiklima. Modul dohvaća podatke i šalje ih aplikaciji koja ih
zatim prikazuje skladištaru. On ţeljene podatke unosi u formu, te nakon toga aplikacija
prosljeđuje podatke modulu koji ih naknadno posprema. Za kraj ovog procesa vrši se dealokacija
objekta.

28
6.2.3. Izrada otpremnice

Slika 6.5. Dijagram slijeda: Izrada otpremnice

29
 Ovaj dijagram slijeda isto tako ima tri učesnika kao i kod prošlog s tom razlikom što je
umjesto modula za izradu primke sad modul za izradu otpremnice. Slijed je isti kao i kod izrade
primke. Skladištar odabire opciju za izradu primke dok aplikacija inicijalizira objekt i prikazuje
formu za izradu otpremnice. Nakon toga traţi podatke o artiklima od modula za izradu
otpremnice. Modul dohvaća podatke iz baze i prosljeđuje ih aplikaciji koja ih prikazuje
skladištaru. On unosi ţeljene podatke u formu, koje zatim aplikacija prosljeđuje modulu i sprema
ih u bazu podataka. Na kraju svega se vrši dealokacija objekta.

30
6.2.4. Pregled knjiženja

Slika 6.6. Dijagram slijeda: Pregled knjiţenja

31
 Ovo je dijagram slijeda u kojem sudjeluje isključivo direktor kao korisnik. Isto tako on
koristi stolnu aplikaciju te kao treći učesnik koristi se modul za pregled knjiţenja. Za početak
direktor izabire opciju za pregled knjiţenja, nakon čega se inicijalizira objekt i prikazuje forma
za pregled knjiţenja. Direktor prilikom toga izabire skladište za koje ţeli pregledavati knjiţenja.
Aplikacija zatim prosljeđuje upit za pregled knjiţenja sa izabranim skladištem modulu koji zatim
dohvaća knjiţenja na temelju upita. Zatim ih prosljeđuje aplikaciji koja knjiţenja prikazuje
direktoru, te za kraj dealocira objekt.

32
6.2.5. Dodavanje poslovnog partnera

Slika 6.7. Dijagram slijeda: Dodavanje poslovnog partnera

33
 Kao i kod prijašnjeg dijagrama u ovu sudjeluje direktor kao korisnik, zatim dStorage
aplikacija i modul za dodavanje poslovnog partnera. Direktor izabire opciju dodavanja novog
poslovnog partnera. Nakon toga inicijalizira se objekt i prikazuje forma za upis. Direktor unosi
podatke o poslovnom partneru u formu te nakon toga ukoliko ţeli sprema podatke ili odustaje od
spremanja podataka. Ako izabere opciju spremanja podataka, aplikacija upisane podatke šalje
modulu koji zatim sprema te podatke u bazu podataka. No postoji i druga situacija ukoliko se
direktor predomisli i ne ţeli spremiti podatke izlazi iz aplikacije, te se nakon toga dealocira
objekt.

34
6.2.6. Dodavanje zaposlenika

Slika 6.8. Dijagram slijeda: Dodavanje zaposlenika

35
 Analogno prijašnjem dijagramu slijeda izvršava se i ovaj. Imamo tri učesnika, direktor,
dStorage aplikacija i modul za dodavanje zaposlenika. Slijed započinje kada direktor izabere
opciju dodavanja novog zaposlenika. Najprije se inicijalizira objekt a zatim se prikazuje forma
za unos novog zaposlenika. Direktor unosi podatke o novom zaposleniku u formu te ima izbor
spremanja ili odustajanja od spremanja istih. Ukoliko odabere spremanje, aplikacija šalje upisane
podatke modulu koji ih zatim sprema. Ako ih kojim slučajem direktor ne ţeli spremiti, odustaje
od toga i tu završava proces. Još se na kraju svega dealocira objekt.

36
6.2.7. Dodavanje skladišta

Slika 6.9. Dijagram slijeda: Dodavanje skladišta

37
 Dijagram slijeda isti kao i u prošla dva s tom razlikom što im kao učesnika modul za
dodavanje skladišta. Proces započinje nakon što direktor odabere opciju za dodavanje novog
skladišta. Prilikom toga inicijalizira se objekt i aplikacija prikazuje formu za unos novog
skladišta. Direktor unosi ţeljene podatke u tu formu te odabire spremanje ukoliko to ţeli ili
odustaje od spremanja tih podataka. Ako ţeli spremanje aplikacija prosljeđuje upisane podatke
do modula koji ih zatim sprema u bazu podatka. Ako ih direktor ne ţeli spremiti odustaje od
toga, te se vrši dealokacija objekta.

38
6.3. Dijagram aktivnosti

Ili (eng. Activity Diagram) je specijalni oblik dijagrama prijelaza stanja, koji prikazuje
stanja i prijelaze između slučajeva korištenja. Dijagrame aktivnosti smo organizirali u domene
odgovornosti (eng. swimlane), kako bi ga uspjeli što bolje razumjeti.

Svaki učesnik u dijagramu aktivnosti ima svoju plivačku stazu (eng. swimlane) uz pomoć
koje lako očitamo koja aktivnost pripada kojem učesniku.
Sustav koncepata koji su uključeni u dijagram aktivnosti nešto je drugačiji od onog u
dijagramima slijeda ili dijagramu slučajeva korištenja. Promatrajući dijagrame koji slijede,
moţemo primijetiti nekoliko koncepata, predstavljenih svojim oblicima:
 Akcije: mali pravokutnik zaobljenih kutova, predstavlja aktivnosti u slijedu, a sa drugim
aktivnostima spojen je kontrolnim tokom
 Aktivnosti: veliki pravokutnici zaobljenih kutova, predstavljaju jednu cjelinu, tj. nekoliko
spojenih akcija
 Objekti: mali pravokutnici pravih kutova, predstavljaju instancu određene klase, sa
pripadajućim stanjem
 Područje aktivnosti podloţno prekidu: predočeno područjem unutar aktivnosti, a
uokvirenim crtkanom crtom, predstavlja područje koje je podloţno prekidu bilo kakve
vrste, a koji se detaljnije definira unutar samog područja okvira
 Upravitelj prekidom: predstavljen „munja strelicom“, opisuje slijed u slučaju prekida iz
prekidu podloţnog područja
 Početna točka: prikazana crnom točkom, označava početak slijeda aktivnosti
 Završna točka: prikazana crnom točkom sa bijelim prstenom, označava konačni kraj
slijeda aktivnosti
 eng. Pin: mali kvadratić uz aktivnost, predstavlja element koji daje vrijednost
aktivnostima, ili sprema vrijednosti njihovih rezultata (Input/Output Pin)
 Grananje: mali pravokutnik crno ispunjen, prikazuje da se slijed dijeli na dva
jednakopravna slijeda
 Odluka: prikazan rombom, ovaj koncept označava odluku, mjesto odakle nastavlja samo
jedan od ponuđenih sljedova
 Pošiljatelj signala: prikazan pravokutnikom sa izbočenjem s desne strane, ovo je koncept
koji označava da se šalje signal u program, primatelju tog signala, gdje se moţe pokrenuti
stroj stanja ili izvršiti neka aktivnost, tj. slijed aktivnosti

39
  Primatelj signala (događaja): pravokutnik sa uvučenim dijelom s lijeve strane, predstavlja
koncept koji čeka događaj koji odgovara postavljenim kriterijima kako bi nastavio sa
aktivnostima ili pokrenuo slijed aktivnosti

Kako u našem projektu imamo sedam dijagrama slijeda, tako ćemo i za svaki od tih
dijagrama napraviti dijagram aktivnost. Svi ti dijagrami aktivnosti prikazani su na slikama i
opisani u daljnjem tekstu koji slijedi.

40
6.3.1. Logiranje u sustav

Slika 6.10. Dijagram aktivnosti: Logiranje u sustav

41
 Ovaj dijagram aktivnosti koji prikazuje logiranje u sustav ima tri domene odgovornosti.
To su redom korisnik (skladištar ili direktor), aplikacija (mStorage ili dStorage) te modul za
logiranje u sustav. Korisnik započinje aktivnost na način da pokrene aplikaciju koja zatim
inicijalizira formu za logiranje te ju prikazuje korisniku. Korisnik nakon toga unosi korisničko
ime i lozinku koje zatim modul provjerava, na način da gleda postoje li takvi podaci u bazi
podataka. Ukoliko podaci nisu valjani aplikacija javlja grešku te ponovno prelazi na akciju unosa
korisničkog imena I lozinke sve dok se ne unesu valjani podaci. S druge strane ako se ustanovi
da su uneseni podaci od strane korisnika valjani njemu se dodjeljuju prava. Ispisuje se poruka I
prilagođava sučelje za rad s aplikacijom. Nakon toga dealocira se forma za logiranje i tu nastaje
kraj.

42
6.3.2. Izrada primke

Slika 6.11. Dijagram aktivnosti: Izrada primke

43
 Kod ovog dijagrama imamo tri domene odgovornosti, s tom razlikom što imamo samo
jednu vrstu korisnika, a to je skladištar i jednu vrstu aplikacije a to je mobilna aplikacija
mStorage, te još i modul za izradu primke. Aktivnost započinje kada skladištar izabire opciju za
izradu primke. Aplikacija nakon toga inicijalizira formu za unos primke te istu prikazuje. Modul
u isto vrijeme dohvaća podatke o artiklima te ih integrira u formu. Nakon toga korisnik izabire
ţeljene podatke i s njima popunjava formu. Kako je sada forma popunjena korisnik odabire
spremanje primke. Aplikacija priprema podatke za spremanje i šalje ih modulu koji ih zatim
sprema u bazu podataka. Pred sam kraj aktivnosti vrši se dealokacija primke i tu aktivnost
završava.

44
6.3.3. Izrada otpremnice

Slika 6.12. Dijagram aktivnosti: Izrada otpremnice

45
 Dijagram aktivnosti koji je gotovo identičan kao i prethodni dijagram s tom razlikom što
se tu radi o otpremnici dok se u prijašnjem slučaju radilo o primci. Aktivnost kreće tako što
skladištar odabire opciju za izradu otpremnice. Slijedom toga aplikacija inicijalizira formu za
unos otpremnice i prikazuje ju. Modul za izradu otpremnice dohvaća podatke o artiklima koji se
zatim integriraju u formu. Zatim slijedi popunjavanje forme od strane skladištara, te nakon što se
forma popuni korisnik izabire spremanje otpremnice. Aplikacija priprema podatke te ih
prosljeđuje modulu koji ih zatim sprema u bazu podataka. Nakon spremanja izvršava se
dealokacija forme za unos otpremnice i tu je kraj ove aktivnosti.

46
6.3.4. Pregled knjiženja

Slika 6.13. Dijagram aktivnosti: Pregled knjiţenja

47
 Što se tiče ovog dijagrama, ovdje isto imamo tri domene odgovornosti. To su korisnik
koji je u ovom slučaju direktor, stolna aplikacija dStorage i modul za pregled knjiţenja. Direktor
odabire opciju za pregled knjiţenja i to je ustvari početak aktivnosti. Slijedom toga aplikacija
inicijalizira i prikazuje formu za pregled knjiţenja. Nakon toga direktor ima mogućnost izbora
skladišta za koje će pregledavati knjiţenja. Odabire skladište i aplikacija priprema podatke za
dano skladište, dok ih modul dohvaća. Tu slijedi grananje. Imamo situaciju u kojoj imamo
knjiţenje za dano skladište ili nemamo. U slučaju da nemamo, forma je prazna, a u slučaju da
imamo forma je popunjena sa podacima. Nakon toga direktor moţe pregledati knjiţenja. Kada
završi sa pregledom ima mogućnost opet pregledavanja knjiţenja za neko novo skladište, ili
odustajanje od daljnjeg pregledavanja. Za kraj se izvršava dealokacija forme za pregled knjiţenja
i tu aktivnost završava.

48
6.3.5. Dodavanje poslovnog partnera

Slika 6.14. Dijagram aktivnosti: Dodavanje poslovnog partnera

49
 Dijagram aktivnosti za dodavanje poslovnog partnera isto ima tri domene odgovornosti.
Kao i prethodni ima dvije iste domene dok je treća domena modul za dodavanje poslovnog
partnera. Aktivnost započinje kada direktor odabire opciju dodavanja novog poslovnog partnera.
Aplikacija nakon toga inicijalizira formu za dodavanje poslovnog partnera i prikazuje je na
zaslonu. Korisnik zatim popunjava formu, te nakon što je ona popunjena odabire opciju
spremanja ili odustaje od spremanja. Ukoliko se odluči za spremanje podataka o poslovnom
partneru javlja to aplikaciji dok aplikacija javlja modulu da su upisani podaci spremni za
pohranu u bazu podataka. Nakon toga slijedi dealokacija forme za dodavanje poslovnog partnera
isto ako i u slučaju ako direktor ne ţeli spremiti unesene podatke.

50
6.3.6. Dodavanje zaposlenika

Slika 6.15. Dijagram aktivnosti: Dodavanje zaposlenika

51
 Dijagram aktivnosti gotovo identičan kao i prijašnji s tom razlikom što ovdje imamo
domenu odgovornosti u kojoj se nalazi modul za dodavanje zaposlenika. Aktivnost kreće kada
direktor odabere opciju za dodavanje zaposlenika. Aplikacija pritom inicijalizira i prikaţe formu
za dodavanje zaposlenika. Tada direktor upisuje podatke o novom zaposleniku i nakon što je
forma popunjena zatraţi spremanje ili odustaje od spremanja podataka koje je unio. Ukoliko ţeli
spremiti podatke aplikacija priprema iste i prosljeđuje ih modulu koji ih sprema u bazu podataka.
Prije samog kraja aktivnosti, dealocira se forma za dodavanje zaposlenika isto kao i u slučaju
ako direktor ne ţeli pospremiti podatke o novom zaposleniku.

52
6.3.7. Dodavanje skladišta

Slika 6.16. Dijagram aktivnosti: Dodavanje skladišta

53
 Ovaj dijagram aktivnosti analogan je kao prethodna dva, samo što u ovom slučaju imamo
skladišta umjesto poslovnog partnera ili zaposlenika. Isto tako imamo i novu domenu
odgovornosti a to je modul za dodavanje skladišta. Isto tako imamo još dvije domene
odgovornosti, a to su korisnik (direktor) i aplikaciju (dStorage). Za početak aktivnosti direktor
izabire opciju za dodavanje novog skladišta. Aplikacija shodno tome inicijalizira i prikazuje
formu za dodavanje skladišta. Direktor nakon toga popunjava formu sa podacima o skladištu i
nakon što ju popuni sprema podatke ili odustaje od spremanja. Ako korisnik zaţeli spremanje
podataka o skladištu, aplikacija priprema podatke koje su upisani i šalje modulu koji ih zatim
sprema u bazu podataka. Nakon pospremanja dealocira se forma za dodavanje skladišta isto kao i
u slučaju ako bi direktor odustao od spremanja upisani podataka o skladištu.

54
6.4. ERA model

ERA model je skraćenica od engl. riječi Entity, Relationship, Attributes, što u prijevodu
znači Entiteti, Veze, Atributi. ERA model je grafička prezentacija znanja o objektima, vezama i
svojstvima. Objekti mogu biti jaki i slabi. Jaki mogu postojati nezavisno od drugih objekata, a
slabi egzistencijalno zavise o drugim objektima. Kad govorimo o svojstvu (atributu), razlikujemo
dvije stvari: deskriptor i identifikator. Deskriptor upotpunjuje opis objekta dok identifikator
jednoznačno određuje svaku instancu objekta. O vezama moţemo govoriti na tri načina. Prvi
način je kad govorimo o redu veze (unarna i binarna veza), drugi je način učešća (obvezno i
opcionalno) i treći način je kad govorimo o tipu povezanosti (1:1, 1:M, M:N).

ERA model koristili smo kao metodu konceptualnog i fizičkog modeliranja podataka.

Evo i osnovnih koncepata modela entiteti – veze koje smo koristili:

 Entitet – je koncept ili objekt od interesa, bilo da je stvarni ili apstraktni predmet
odnosno događaj u kojemu se u informacijskom sustavu pamte podaci, sadrţi niz atributa

 Atribut – govori o identifikaciji, klasifikaciji, kvantifikaciji, kvaliteti ili stanju entiteta, to

je jedinstveno obiljeţje entiteta

 Veza – je relacija dvaju entiteta, one su dvosmjerne i prikazuju međusobne odnose

entiteta u oba smjera

 Ograničenja – ili cjelobrojnosti veza, nam kazuju koliki broj entiteta jednog tipa moţe
biti u vez s entitetima drugom tipa.

55
 Slika 6.17. ERA model

Slika 6.17 prikazuje ERA model naše baze podataka u koju ćemo spremati sve podatke o
artiklima, skladištima, poslovnim partnerima, zaposlenicima i knjiţenjima.

Najvaţniju tablicu čini tablica Knjiženja preko koje se sve vrti i preko koje su povezane
sve ostale tablice. U toj tablici spremamo podatke o knjiţenjima, a u nju se dohvaćaju
identifikatori skladišta, partnera i zaposlenika koji čine strane ključeve i preko kojih
evidentiramo knjiţenja po skladištima.

U tablici Skladista spremljen je naziv skladišta koje je u posjedu našeg naručitelja i ono
se evidentira u knjiţenjima i njegova adresa.

56
 Tablica Partneri sadrţi podatke o poslovnim partnerima kao što su naziv, adresa, OIB i
sl.

Tablica Zaposlenici sadrţi podatke potrebne za prijavu u aplikaciju, ali i identifikaciju

korisnika kod knjiţenja. Vaţno je da se zna koji korisnik je napravio koja knjiţenja kako bi se
postigla određena sigurnost sustava.

Tablica Vrsta_zaposlenika sluţi nam za definiranje uloga zaposlenika kao što su npr. u
našem slučaju skladištar i direktor.

Tablica Artikli sadrţi osnovne podatke o artiklima koje naručuju i otpremaju u

skladištima. ID artikla sadrţaj je u tablici Artikli_po_knjizenju kako bi se lako mogli dohvatiti
ostali podaci vezani uz pojedini artikl. Spomenuta tablica Artikli_po_knjizenju sadrţava sve
artikle koji su spremljeni u određenom knjiţenju te njihove vrijednosti ulaza, odnosno izlaza te
dugovanja i potraţivanja.

Tablica Mjerne_jedinice predstavlja šifarnik mjernih jedinica koje mogu imati pojedini
artikli, a to mogu biti kilogrami, tone, litre i sl.

Vaţno je napomenuti da se naša baza podataka koristi i kod stolne i kod mobilne
aplikacije i svugdje ima jednaku strukturu kako bi se olakšalo sinkroniziranje podataka. Vaţnu
ulogu u tome ima atribut sync koji označava da li je neki redak sinkroniziran u odnosu na drugu
bazu. Kod sinkronizacije mobilne i web baze podataka moţemo jednostavnim podizanjem sync
atributa iz vrijednosti 0 u vrijednost 1 označiti da li smo taj redak sinkronizirali s obzirom na
drugu bazu i tako smanjiti veličinu prenesenih podataka.

57
6.5. Relacijski model

Relacijski model podataka predstavlja nam drugu fazu logičkog modeliranja podataka
vezano za našu aplikaciju mStorage. Izrađen temeljem prije oblikovanog ERA modela. Kao
sama baza relacijskog modela koristi se relacija. Relacija u relacijskom modelu predstavlja
dvodimenzionalnu tablicu – svaki red relacije sadrţi jednu n-torku, odnosno slog, a svaki stupac
relacije odgovara jednom elementu domene.

LEGENDA: prikazuje primarni ključ, prikazuje vanjski ključ

 Mjerne_jedinice
 kratica
 naziv
 Artikli
 ID_artikla
 naziv
 opis
 kratica
 cijena
 sync
 Skladišta
 ID_skladišta
 naziv
 adresa
 sync
 Knjiţenja_Artikli
 ID_knjiženja
 ID_artikli
 ulaz
 izlaz
 duguje
 potrazuje
 sync
 Knjiţenja
 ID_knjizenja
 datum
 duguje
 potrazuje
 napomena
 ID_skladista
 ID_partnera
 ID_zaposlenika
 sync
 Partneri
 ID_partnera
 naziv
 adresa
 OIB
58
  tel
 email
 ziro
 sync
 Vrsta_zaposlenika
 ID_vrsta_zaposlenika
 naziv
 Zaposlenici
 ID_zaposlenika
 ime
 prezime
 adresa
 mob
 tel
 mail
 korisnicko_ime
 lozinka
 ID_vrsta_zaposlenika
 sync

6.6. Dijagrami klasa

Klase (eng. class) kao koncept koristili smo za definiranje opisa skupa objekata koji
dijele iste atribute, operacije i metode, veze i semantiku.

Operacije, kojima smo opisali ponašanje objekta, sadrţe naziv te opcionalno listu
argumenata (parametara) i vrijednosti koje vraćaju (koje zajedno čine eng. signature of the
operation jer opisuje sve što je operaciji potrebno). Kao i atributi, i operacije imaju vidljivost.

Dijagram klasa (eng. Class Diagram) predstavlja skup elemenata strukture kao što su
klase, sučelja, a ponekad i same instance (objekti), njihovu unutrašnju strukturu te međusobnu
povezanost prikazujemo određenim tipovima relacija. Osnovne komponente dijagrama klasa su
same klase te veze između njih. Klase moţemo povezivati osnovnim vezama generalizacije i
asocijacije.
Dijagramom klasa opisujemo objekte iz stvarnog svijeta ali i veze između njih.
Asocijacija je najvaţnija veza korištena u dijagramu klasa, a označava sposobnost objekta da
pošalje poruku drugom objektu.

Naši dijagrami izrađeni su u programskom okruţenju Microsoft Visual Studio 2008 iz

razloga što nam taj alat pruţa iznimne mogućnosti povezivanja dijagrama s programskim kodom
te nam olakšava implementaciju veza između klasi. Najveći nedostatak korištenja ovog alata za
izradu dijagrama klasa je nedostatak tipa veze ovisnosti (engl. dependency) jedne klase o drugoj

59
(<<use>>). Takva veza predstavlja slabiji oblik veze koji označava ovisnost jedne klase o drugoj
iz razloga što jedna klasa u nekom trenutku koristi tu drugu klasu. U programskom kodu to moţe
značiti da jedna klasa prima drugu klasu kao parametar ili je u njoj sadrţana u obliku lokalne
varijable.

Pošto se naš cjelokupni sustav sastoji od dvije aplikacije, prikazat ćemo dijagrame klasa
za svaku od njih.

6.6.1. deskStorage

Slika 6.18. prikazuje dijagram klasa stolne aplikacije zvane deskStorage.

6.18. Dijagram klasa – deskStorage

60
 Na dijagramu klasa za stolnu aplikaciju prikazane su sve klase koje koristi stolna
aplikacija, a moţemo ih podijeliti na forme (frmLogin, frmGlavna, frmMjerneJedinice,
frmVrsteZaposlenika i frmOprogramu), logičku klasu (Logika) i na statičku klasu (Postavke).
Vaţno je napomenuti da stolna aplikacija preko klase Logika komunicira s web servisom i preko
te klase dohvaća sve podatke iz baze podataka smještene na web-u. Moţemo reći da je glavna
baza podataka za stolnu aplikaciju web baza podataka iz koje se preko web servisa dohvaćaju svi
podaci i prosljeđuju klasi Logika.

frmLogin je forma koja se prikazuje prilikom pokretanja aplikacije i predstavlja glavni

ekran za prijavu korisnika. Povezana je s glavnom formom frmGlavna jer se nakon uspješne
prijave prikazuje glavna forma te s klasom Logika u kojoj su smještene sve metode za obradu i
dohvat podataka iz web baze podataka.

frmGlavna je glavna forma na kojoj su smještene kartice za upravljanje svim stavkama

kao što su zaposlenici, skladišta itd. Povezana je s klasom Logika te s formom za upravljanje
vrstama zaposlenika (frmVrsteZaposlenika) i s formom za upravljanje mjernim jedinicama
artikala (frmMjerneJedinice). Veza prema frmLogin označava da klasa frmGlavna ima varijablu
frmLogin tipa frmLogin u koju spremamo formu za prijavu. To nam je potrebno iz razloga što
prilikom zatvaranja glavne forme natrag prikazujemo formu za prijavu.

frmVrsteZaposlenika je forma koja nam sluţi za upravljanje vrstama zaposlenika. U

aplikaciji su najvaţnije vrste skladištar i direktor, a po potrebi se mogu dodavati još i nove vrste
zaposlenika. Ova klasa je kao i sve ostale klase koje zahtijevaju neku logičku obradu i pristup
bazi podataka povezana s klasom Logika.

Forma frmMjerneJedinice sluţi nam za upravljanje mjernim jedinicama artikala.

Korisnik moţe dodavati, brisati i aţurirati mjerne jedinice, a sve to se ostvaruje vezom prema
klasi Logika.

frmOprogramu je jednostavna forma u kojoj se nalaze osnovne informacije o

deskStorage aplikaciji. Forma sadrţi nekoliko vaţnih svojstava (engl. property) preko kojih
razvojno okruţenje postavlja informacije o aplikaciji.

Statička klasa Postavke sluţi nam za spremanje nekih glavnih postavki aplikacije koje se
koriste tako dugo dok je korisnik prijavljen i ima pristup aplikaciji. U ovu klasu prilikom
uspješne prijave spremamo ID_zaposlenika kako bi u svakom djelu aplikacije točno i
jednoznačno mogli odrediti tko se prijavio, korisničko ime prijavljenog zaposlenika u svojstvo
61
KorisnickoIme te vrstu prijavljenog zaposlenika u svojstvo Vrsta_zaposlenika. Vaţno je
napomenuti kako se prilikom odjave pokreće metoda odjava() unutar klase Logika i kako se sva
svojstva klase Postavke postavljaju na vrijednosti koje ne moţe imati niti jedan zaposlenik
spremljen u bazi podataka.

Srţ cjelokupne aplikacije čini klasa Logika. Preko te klase komunicira se s web servisom
koji pak komunicira s web bazom podataka i tako dohvaća ili prima za obradu sve podatke koje
mu prosljeđuje klasa Logika. Moţemo reći da se u klasi Logika podaci samo pripremaju i šalju
web servisu koji onda nad njima vrši zadane obrane. Velika je šteta što Visual Studio 2008 ne
dopušta prikazivanje klasi iz nekog drugog projekta na dijagramu klasa kako bi se što bolje
prikazale veze između naše deskStorage aplikacije i našeg web servisa.

62
6.6.2. mStorage

Na slici 6.19. prikazan je dijagram klasa za mStorage mobilnu aplikaciju.

6.19. Dijagram klasa – mStorage

Dijagram klasa mobilne aplikacije je po mnogo čemu sličan dijagramu klasa stolne
aplikacije, ali ipak ima razlike. Najveća razlika je u tome što u mobilnoj aplikaciji imamo osim

63
prezentacijskog i logičkog sloja, sloj za pristup bazi podataka. Još jedna razlika je u tome što u
mobilnoj aplikaciji koristimo takozvane poslovne objekte (engl. business objects) koji su
specifični za troslojnu arhitekturu aplikacija, a uvelike nam pomaţu u odvajanju poslovne logike
i prezentacije sadrţaja i omogućuju nam bolje strukturiranje cjelokupne aplikacije.

frmLogin forma je forma za prijavu korisnika u aplikaciju i povezana je s formom

frmGlavna kako bi ju mogla pozvati nakon uspješne prijave te s klasom Logika u kojoj je
opisana poslovna logika.

Forma frmGlavna je takozvana forma dobrodošlice u kojoj korisnik odabire što ţeli
raditi. Glavna forma povezana je s formom za pregled knjiţenja (frmPregledKnjizenja) te s
formom frmKnjizenje gdje se izrađuju primke i otpremnice. Naravno, tu je i veza prema glavnoj
klasi Logika.

frmPregledKnjizenja je jednostavna forma koja samo prikazuje popis knjiţenja koja su

napravljena. Povezana je s klasom Logika preko koje se dohvaćaju sva ta knjiţenja.

frmKnjizenje je glavna forma za izradu primke ili otpremnice. Povezana je s klasom

Knjizenje koja sadrţi sve podatke koji se prikazuju na formi i s klasom Logika koja sadrţi
metode za spremanje knjiţenja u bazu podataka.

Kao što smo već spomenuli, klase Knjizenje, ArtikliPoKnjizenju, Partner, Skladiste i
Zaposlenik su poslovni objekti koji se koriste u mobilnoj aplikaciji. Većinom se poslovni objekti
podudaraju tablicama u bazi podataka, ali to ne mora uvijek biti tako. Iako smo mogli koristiti
poslovne objekte, odnosno klase, iz web servisa, odlučili smo se na ovu izvedbu kako bi
osigurali neovisnost mobilne aplikacije koja bi se na taj način kasnije mogla lakše nadograđivati
i unaprjeđivati. U ovom slučaju zamjećujemo nedostatak već prije spomenute veze ovisnosti u
Visual Studiu te naše poslovne objekte ne moţemo nikako povezati s klasama koje ih koriste.

Klasa Logika sadrţi glavne metode koje omogućuju rad aplikacije i preko klase Baza
komuniciraju s bazom podataka. Logika sadrţi metode spremanja i aţuriranja stavki primljenih
od web servisa kako bi se sinkronizirale baze podataka, sprema knjiţenja i pripadajuće artikle,
vraća sve potrebne podatke iz baze podataka itd.

Klasa Baza čini podatkovni sloj u našoj aplikaciji i sadrţi metode za izvršavanje upita na
bazu podataka.

64
 Mobilna aplikacija također sadrţi statičnu klasu Postavke u kojoj spremamo iste podatke
kao i u stolnoj aplikaciju, ali smo tu klasu u ovoj aplikaciji realizirali na drugačiji način. U
stolnoj aplikaciji korištena su svojstva dok ovdje koristimo metode za postavljanje (get) i
dohvaćanje (set) vrijednosti pojedinih atributa klase.

65
7. Korisničke upute

U ovom djelu dat ćemo detaljne korisničke upute za korištenje naše stolne i mobilne
aplikacije. Prva je na redu stolna deskStorage aplikacija koja je namijenjena direktoru poduzeća
ili direktoru nabave.

7.1. deskStorage

Kada korisnik pokrene deskStorage aplikaciju prikazuje mu se prozor za prijavu gdje se

upisuju korisničko ime i pripadajuća lozinka. Ako korisnik upiše pogrešne podatke, u statusnoj
traci se prikazuje poruka o grešci i zahtijeva se ponovni unos podataka. Korisnik klikom na
gumb Izlaz moţe u bilo kojem trenutku ugasiti aplikaciju. Slika 7.1. prikazuje prozor za prijavu u
deskStorage aplikaciju.

Slika 7.1. Prozor za prijavu

Ako je korisnik upisao točne podatke prikazuje se glavni prozor aplikacije s označenom
karticom Knjiženja i prikazom svih knjiţenja iz baze podataka. Slika 7.2. prikazuje karticu
Knjiženja.

66
 Slika 7.2. Kartica Knjiženja

Glavni meni prikazuje trenutno prijavljenog korisnika gdje se klikom na njega prikazuje
opcija za odjavu korisnika. Klikom na opciju O programu otvara se prozor s osnovnim
informacijama o programu. Kartica Knjiženja prikazuje sva knjiţenja iz baze podataka, a
korisnicima je omogućeno i filtriranje tih podataka. Korisnik moţe odabrati ţeli li pregledavati
primke, otpremnice ili sve zajedno te moţe uključiti neki od filtera kao što su filter skladišta,
filter partnera i filter zaposlenika. Pritiskom na gumb Filtriraj prikazuju se podaci ovisno o
odabranim filterima. Gumb Reset vraća filter u prvotno stanje i prikazuje sva knjiţenja.

67
 Kartica Skladišta prikazana je na slici 7.3., a odnosi se na upravljanje skladištima.

Slika 7.3. Kartica Skladišta

U tablici su prikazana sva skladišta iz baze podataka, a klikom na pojedini redak

popunjavaju se polja ispod mjesta tablice s odabranim podacima. Nakon što su polja popunjena,
korisnik moţe obrisati odabrani redak ili pak promijeniti neke podatke i spremiti ih klikom na
gumb Spremi. Ako korisnik ţeli upisati novo skladište, mora kliknuti na gumb Isprazni polja
kako bi se polja za upis ispraznila i ondje upisuje podatke o svom novom skladištu i sprema ih
klikom na gumb Spremi.

68
 Na slici 7.4. prikazana je kartica Artikli.

Slika 7.4. Kartica Artikli

Aţuriranje, brisanje i spremanje novih artikala radi na istom principu kao što je i
objašnjeno u prethodnom djelu na kartici Skladišta. U ovoj kartici korisniku se nudi mogućnost
upravljanja mjernim jedinicama. Klikom na poveznicu Mjerne jedinice otvara se novi prozor
prikazan na slici 7.5.

69
 Slika 7.5. Upravljanje mjernim jedinicama

U ovom prozoru korisnici mogu dodavati, brisati ili aţurirati postojeće mjerne jedinice
koje mogu imati naši artikli. Nakon zatvaranja prozora, padajući izbornik s mjernim jedinicama
će se automatski aţurirati s novim podacima.

Kartica Partneri sluţi nam za upravljanje partnerima na već objašnjen način, a prikazana
je na slici 7.6.

Slika 7.6. Kartica Partneri

70
 U zadnjoj kartici korisnik moţe upravljati zaposlenicima i vrstama zaposlenika na već
prije objašnjen način. To je prikazano na slikama 7.7. i 7.8.

Slika 7.7. Kartica Zaposlenici

Slika 7.8. Upravljanje vrstama zaposlenika

71
7.2. mStorage

mStorage aplikacija za mobilni uređaj namijenjena je skladištarima koji preko te

aplikacije mogu jednostavno i brzo izrađivati primke i otpremnice u skladištu.

Prilikom pokretanja aplikacije pojavljuje se forma za prijavu korisnika u aplikaciju.

Korisnik mora upisati svoje korisničko ime i pripadajuću lozinku i tek onda moţe koristiti glavni
dio aplikacije. Ako korisnik upiše krive podatke izbacuje mu se poruka o pogrešnom unosu.
Slika 7.9. prikazuje formu za prijavu u mobilnu aplikaciju mStorage.

Slika 7.9. Prijava u mStorage

Nakon uspješne prijave, korisniku se otvara glavna forma u kojoj on odabire što ţeli
napraviti. Poţeljno je da se nakon prijave prvotno napravi sinkronizacija baze podataka. Klikom
na ikonu na glavnoj formi ili odabirom sinkronizacije iz glavnog izbornika pokreće se asinkrono
sinkroniziranje bazi podataka. Korisniku se u izborniku Sinkronizacija također nudi i testiranje
veze na web servis. Ako je veza uspješno uspostavljena, korisniku se prikazuje poruka
obavijesti, a ako je pak došlo do greške, javlja se poruka greške. Nakon sinkronizacije bazi
podataka, korisniku se prikazuje poruka da je sinkronizacija završila. Slika 7.10. prikazuje ekran
nakon uspješne sinkronizacije bazi podataka.

72
 Slika 7.10. Sinkronizacija bazi podataka

Glavna djelatnost skladištara je izrada primki i otpremnici, a to mu je u aplikaciji

omogućeno odabirom ikone Novo knjiženje ili odabirom novog knjiţenja iz glavnog izbornika
pod stavkom Knjiženja. Nakon što korisnik zatraţi izradu novog knjiţenja, otvara se forma za
odabir vrste knjiţenja te unos podataka o knjiţenju. Kartica Knjiženje prikazana je na slici 7.11.

73
 Slika 7.11. Izrada novog knjiţenja

Ovdje korisnik odabire sve osnovne podatke kao što su skladište za koje se izrađuje
primka ili otpremnica, koji je partner i upisuje se napomena. Nakon što je popunio sve podatke,
odabire karticu Artikli po knjiženju. Slika 7.12. prikazuje tu karticu.

74
 Slika 7.12. Odabir artikala po knjiţenju

Ovdje korisnik upisuje sve artikle koje ţeli imati na svojoj primci/otpremnici. To radi
tako da na padajućem izborniku odabere ţeljeni artikl, upiše količinu i klikne na gumb Dodaj.
Ako ţeli neki artikl obrisati s liste artikala, odabire ga i pritišče gumb Obriši. Korisnik moţe
nakon unosa odustati od spremanja odabirom gumba Odustani ili pak spremiti knjiţenje
odabirom gumba Spremi, a aplikacija ga vraća na glavnu formu aplikacije.

Nakon unosa knjiţenja korisnik ih moţe pregledavati odabirom opcije Pregled knjiženja
iz izbornika Knjiženja. Također, poţeljno je da se obavi sinkronizacija baza kako bi sva
knjiţenja bila spremljena u centralnu bazu podataka. Slika 7.13. prikazuje pregledavanje
knjiţenja dok slika 7.14. prikazuje izlaz iz programa.

75
Slika 7.13. Pregled knjiţenja

Slika 7.14. Izlaz iz aplikacije

76