SLOBOMIR P UNIVERZITET

Fakultet za informacione tehnologije

Projektni rad

Softverski sistem za podrku rada restorana

Predmet: Nove softverske tehnologije

Mentor: doc dr Sinia Vlaji

Student: Dragana Vidievi 26/08

Slobomir, Oktobar 2012

SADRAJ

1. PRIKUPLJANJE ZAHTJEVA OD KORISNIKA .............................................. 3

1.1. Verbalni opis........................................................................................................ 3 1.2. Opis zahtjeva pomou modela sluajeva korienja............................................ 3

2. NALIZA .................................................................................................................... 11
2.1. Ponaanje softverskog sistema .......................................................................... 11 2.1.1. Sistemski dijagrami sekvenci ............................................................. 11 2.1.2. Definisanje ugovora o sistemskim operacijama ................................. 23 2.1.3 Ogranienja pri izvrenju sistemskih operacija................................... 2.2. Logika struktura softverskog sistema .............................................................. 25 2.2.1. Konceptualni (Domenski) model. ....................................................... 25 2.2.2. Relacioni model .................................................................................. 27

3. PROJEKTOVANJE ................................................................................................... 29
3.1. Arhitektura softverskog sistema ........................................................................ 29 3.1.1. Projektovanje aplikacione logike Kontroler .................................... 30 3.1.2. Projektovanje aplikacione logike Domenske klase ......................... 32 3.1.3. Projektovanje aplikacione logike Sistemske operacije .................... 32 3.1.4. Projektovanje aplikacione logike Database Broker ......................... 40 3.2. Projektovanje skladita podataka ...................................................................... 41 3.3. Struktura korisnikog interfejsa ........................................................................ 43 3.3.1. Projektovanje ekranske forme ............................................................ 43

4. IMPLEMENTACIJA ................................................................................................ 73 5. TESTIRANJE ............................................................................................................. 74

Softverski sistem za podrku rada Restorana

Razvoj softverskog sistema se sastoji iz sljedeih faza: Prikupljanje zahtjeva od korisnika; Analiza; Projektovanje; Implementacija; Testiranje.

1. PRIKUPLJANJE ZAHTJEVA OD KORISNIKA

Zahtjevi predstavljaju svojstva i uslove koje sistem ili ire gredajuci projekat, mora da zadovolji [Larman]. Postoje razliiti tipovi zahtjeva koje sistem mora da zadovolji i oni se kategorizuju prema FURPS (Functional-Funkcionalnost, Usability Upotrebljivost, Reliability Pouzdanost, Performanse Performanse, Supportability Podrivost) modelu. Zahtjevi se esto kategorizuju na funkcionalne i ne funkcionalne zahtjeve.

1.1 Verbalni opis

Softverski sistem treba da prui podrku radu rastorana kako bi se to vei broj poslova automatizovao i samim tim olakao rad. Radnik restorana (konobar), moi e da vri unos novih jela na meni restorana, vri pregled unesenih jela kako bi dobio detaljne informacije o svakom jelu, brie jela kao i da mijenja podatke o izabrabom jelu. Radnik e biti u mogunosti i da vri unos novih prodaja, vri pregled prodaja, brie prodaje i mijenja podatke o prodajama jela u restoranu. Korisnik ovog sistema e biti radnik restorana (konobar).

1.2 Opis zahtjeva pomou modela sluajeva korienja

Zahtevi se kod Larman-a opisuju pomou UML Modela Sluaja Korienja ( Use-Case Model ). Ukoliko je model SK veliki on se dijeli u pakete ( packages ). U konkretnom sluaju identifikovani su sljedei sluajevi korienja: 1. Unos novog jela; 2. Kontrola podataka o jelu; 3. Promjena podataka o jelu; 4. Brisanje jela; 5. Unos novih prodaja jela; 6. Kontrola prodaja jela; 7. Izmjena prodaja jela; 8. Brisanje prodaja jela.

Slika 1: Dijagram sliajeva korienja

SK 1 Sluaj korienja: Unos novog jela Naziv SK: Unos novog jela Aktor SK: Radnik Uesnici SK: Radnik i sistem (program) Preduslov: Sistem je ukljuen. Sistem prikazuje formu za unos novog jela. Osnovni scenario SK:
1. Radnik unosi podatke o novom jelu. (APUSO) 4

2. 3. 4. 5.

Radnik kontrolise unijete podatke. (ANSO) Radnik poziva sistem da sauva podatke o jelu. (APSO) Sistem uva novo jelo. (SO) Sistem prikazuje obavjestenje da je novo jelo uspijesno sauvano. (IA)

Alternativna scenarija:
5.1 Ukoliko sistem nije mogao da sauva jelo, prikazuje poruku da novo jelo ne moe biti

sauvano. (IA) Izvrsavanje scenarija se prekida. SK 2 Sluaj korienja: Pregled podataka o jelu Naziv SK: Pregled jela Aktor SK: Radnik Uesnici SK: Radnik i sistem (program) Preduslov: Sistem je ukljuen. Sistem prikazuje formu za pregled jela.. Osnovni scenario SK:
1. 2. 3. 4.

Radnik unosi kriterijum pretrage jela. (APUSO) Radnik poziva sistem da pronae jelo po navedenom kriterijumu. (APSO) Sistem pronalazi jelo. (SO) Sistem prikazuje jelo koje zadovoljava kriterijum pretrage. (IA)

Alternativni scenario SK:

4.1 Ukoliko sistem nije mogao da pronae jelo, prikazuje poruku da nije mogao da

pronae jelo koje zadovoljava postavljeni kriterijum. (IA) Izvrsavanje scenarija se prekida. SK 3 Sluaj korienja: Promjena podataka o jelu Naziv SK: Promjena podataka o jelu Aktor SK: Radnik Uesnici SK: Radnik i sistem (program)

Preduslov: Sistem je ukljuen. Sistem prikazuje formu za promjenu podataka o jelu. Osnovni scenario SK: Radnik unosi kriterijum pretrage jela. (APUSO) Radnik poziva sistem da pronae jelo po navedenom kriterijumu. (APSO) Sistem pronalazi jelo. (SO) Sistem prikazuje jelo koje zadovoljava kriterijum pretrage. (IA) Radnik mijenja podatke o jelu. (APUSO) 6. Radnik poziva sistem da zapamti unijete izmjene. (APSO) 7. Sistem pamti izmjene o jelu. (SO) 8. Sistem prikazuje poruku da su podaci uspjeno promjenjeni. (IA)
1. 2. 3. 4. 5.

Alternativni scenario:
4.1 Ukoliko sistem nije mogao da pronae jelo, prikazuje poruku da nije mogao da

pronae jelo koje zadovoljava postavljeni kriterijum. (IA) Izvrsavanje scenarija se prekida.
8.1 Ukoliko sistem ne uspije da sauva promjene o jelu, prikazuje poruku o tome. (IA)

Izvravanje scenarija se prekida. SK 4 Sluaj korienja: Brisanje jela Naziv SK: Brisanje jela Aktor SK: Radnik Uesnici SK: Radnik i sistem (program) Preduslov: Sistem je ukljuen. Sistem prikazuje formu za brisanje jela. Osnovni scenario SK:
1. 2. 3. 4. 5. 6. 7.

Radnik unosi kriterijum pretrage jela. (APUSO) Radnik poziva sistem da pronae jelo po navedenom kriterijumu. (APSO) Sistem pronalazi jelo. (SO) Sistem prikazuje jelo koji zadovoljava kriterijum pretrage. (IA) Radnik poziva sistem da izbrise pronaeno jelo. (APSO) Sistem brise jelo. (SO) Sistem prikazuje poruku da je jelo uspjeno izbrisano. (IA)

Alternativna scenarija:

4.1 Ukoliko sistem nije mogao da pronae jelo, prikazuje poruku da nije mogao da

pronae jelo koje zadovoljava postavljeni kriterijum. (IA) Izvrsavanje scenarija se prekida.
7.1 Ukoliko sistem nije mogao da obrie jelo, sistem prikazuje poruku da jelo nije

obrisano. (IA) Izvravanje scenarija se prekida. SK5 Sluaj korienja: Unos nove prodaje Nazi SK: Unos nove prodaje Aktor SK: Radnik Uesnici SK: Radnik i sistem (program) Preduslov: Sistem je ukljuen. Sistem prikazuje formu za izbor jela za prodaju. Osnovni scenario SK:
1. 2. 3. 4. 5.

Radnik unosi podatke o novoj prodaji. (APUSO) Radnik kontrolise unijete podatke. (ANSO) Radnik poziva sistem da sauva podatke o prodaji. (APSO) Sistem uva novu prodaju. (SO) Sistem prikazuje obavjestenje da je nova prodaja uspijesno sauvana. (IA)

Alternativna scenarija:
5.1 Ukoliko sistem nije mogao da sauva prodaju, prikazuje poruku da nova prodaja ne

moe biti sauvana. (IA) Izvrsavanje scenarija se prekida. SK 6 Sluaj korienja: Pregled podataka o prodaji Naziv SK: Pregled prodaje Aktor SK: Radnik Uesnici: Radnik i sistem (program) Preduslov: Sistem je ukljuen. Sistem prikazuje formu za pregled prodaje.

Osnovni scenario SK:

1. 2. 3. 4.

Radnik unosi kriterijum pretrage prodaje. (APUSO) Radnik poziva sistem da pronae prodaju po navedenom kriterijumu. (APSO) Sistem pronalazi prodaju. (SO) Sistem prikazuje prodaju koja zadovoljava kriterijum pretrage. (IA)

Alternativni scenario SK:

4.1 Ukoliko sistem nije mogao da pronae prodaju, prikazuje poruku da nije mogao da

pronae prodaju koja zadovoljava postavljeni kriterijum. (IA) Izvrsavanje scenarija se prekida. SK 7 Sluaj korienja: Promjena podataka o prodaji Naziv SK: Promjena podataka o prodaji Aktor SK: Radnik Uesnici SK: Radnik i sistem (program) Preduslov: Sistem je ukljuen. Sistem prikazuje formu za promjenu podataka o prodaji. Osnovni scenario SK: Radnik unosi kriterijum pretrage prodaje. (APUSO) Radnik poziva sistem da pronae prodaju po navedenom kriterijumu. (APSO) Sistem pronalazi prodaju. (SO) Sistem prikazuje prodaju koja zadovoljava kriterijum pretrage. (IA) Radnik mijenja podatke o prodaji. (APUSO) Radnik poziva sistem da zapamti unijete izmjene. (APSO) Sistem pamti izmjene o prodaji. (SO) 8. Sistem prikazuje poruku Radniku da su podaci uspijeno promijenjeni. (IA)
1. 2. 3. 4. 5. 6. 7.

Alternativni scenario:
4.1 Ukoliko sistem nije mogao da pronae prodaju, prikazuje poruku da nije mogao da

pronae rezervaciju koja zadovoljava postavljeni kriterijum. (IA) Izvrsavanje scenarija se prekida.
8.1 Ukoliko sistem ne uspije da sauva promjene o prodaji, prikazuje poruku o tome. (IA)

Izvravanje scenarija se prekida.

SK 8 Sluaj korienja: Brisanje prodaje Naziv SK: Brisanje prodaje Aktor SK: Radnik Uesnici SK: Radnik i sistem (program) Preduslov: Sistem je ukljuen. Sistem prikazuje formu za brisanje prodaje. Osnovni scenario SK:
1. 2. 3. 4. 5. 6. 7.

Radnik unosi kriterijum pretrage prodaje. (APUSO) Radnik poziva sistem da pronae prodaju po navedenom kriterijumu. (APSO) Sistem pronalazi prodaju. (SO) Sistem prikazuje prodaju koji zadovoljava kriterijum pretrage. (IA) Radnik poziva sistem da izbrise pronaenu prodaju. (APSO) Sistem brise prodaju. (SO) Sistem prikazuje poruku da je prodaja uspjeno izbrisana. (IA)

Alternativna scenarija:
4.1 Ukoliko sistem nije mogao da pronae prodaju, prikazuje poruku da nije mogao da

pronae prodaju koja zadovoljava postavljeni kriterijum. (IA) Izvrsavanje scenarija se prekida.
7.1 Ukoliko sistem nije mogao da obrie prodaju, sistem prikazuje poruku da prodaja nije

obrisana. (IA) Izvravanje scenarija se prekida.

2. ANALIZA
Faza analize opisuje logiku strukturu i ponaanje softverskog sistema. Ponaanje softvarskog sistema je opisano pomou sistemskih dijagrama sekvenci, koji se prave za svaki sluaj korienja i pomou ugovora o sistemskim operacijama, koje se dobijaju na osnovu sistemskih dijagrama sekvenci. Struktura softverskog sistema se opisuje pomou konceptualnog i relacionog modela.

2.1 Ponaanje softverskog sistema

2.1.1 Sistemski dijagrami sekvenci Ponaanje sistema se moe opisati preko UML-ovih sekvencnih dijagrama [ Larman ], odnosno preko dijagrama saradnje [JPRS]. Sistemski dijagram sekvenci prikazuje, za izdvojeni scenario sluajeva korienja, dogaaje u odreenom redoslijedu, koji uspostavljaju interakciju izmeu aktora i softverskog sistema. DS1 Dijagram sekvenci za sluaj korienja: Unos novog jela Osnovni scenario SK:
1. Radnik poziva sistem da sauva podatke o jelu. (APSO) 2. Sistem prikazuje poruku da je jelo uspijesno uneeno. (IA)

Alternativna scenarija SK: 2.1 Ukoliko sistem nije mogao da sauva jelo, prikazuje se poruka da novo jelo ne moe

biti sauvano. (IA) Izvravanje aplikacije se prekida.

10

Sa navedenih dijagrama sekvence uoava se jedna sistemska operacija: 1. UnesiJelo(Jelo)

DS2 Dijagram sekvenci za slucaj korienja: Pregled podataka o jelu Osnovni scenario SK: 1. Radnik poziva sistem da pronae jelo po navedenom kriterijumu (APSO) 2. Sistem prikazuje jelo koje zadovoljava kriterijum pretrage (IA)

Alternativni scenario SK:

2.1 Ukoliko sistem nije mogao da pronae jelo, prikazuje poruku da nije mogao pronai jelo

koje zadovoljava postavljeni kriterijum. (IA).

11

Sa navedenih dijagrama sekvenci uoava se jedna sistemska operacija: 1. PronadjiJelo(Jelo)

DS3 Dijagram sekvenci za sluaj korienja: Promjena podataka o jelu Osnovni scenario SK: 1. Radnik poziva sistem da pronae jelo po navedenom kriterijumu. (APSO) 2. Sistem prikazuje jelo koje zadovoljava kriterijum pretrage. (IA) 3. Radnik poziva sistem da zapamti unijete izmjene. (APSO) 4. Sistem prikazuje poruku da su podaci o jelu uspijeno promijenjeni. (IA)

Alternativni scenario SK: 2.1 Ukoliko sistem nije mogao da pronae jelo, prikazuje se poruka da nije mogao da pronae jelo koje zadovoljava postavljeni kriterijum. (IA) Izvravanje scenarija se prekida. 2.2

12

4.1 Ukoliko sistem ne uspije da sauva promjene o jelu, prikazuje poruku o tome. (IA)

Izvravanje scenarija se prekida.

Sa navedenih dijagrama sekvenci uoavaju se dvije sistemske operacije: 1. PronadjiJelo(Jelo) 2. IzmjenaJela(Jela)

DS4 Dijagram sekvenci za sluaj korienja: Brisanje jela Osnovni scenario SK: 1. Radnik poziva sistem da pronae jelo. (APSO) 2. Sistem prikazuje traeno jelo. (IA) 3. Radnik poziva sistem da izbrise pronaeno jelo. (APSO) 4. Sistem prikazuje poruku da je jelo uspijeno izbrisano. (IA)

13

Alternativna scenarija: 2.1 Ukoliko sistem nije mogao da pronae jelo sa zadatim atributom pretrage, prikazuje poruku da takavo jelo ne postoji. (IA) Izvravanje scenarija se prekida.

4.1 Ukoliko sistem nije mogao da izbrise jelo, sistem prikazuje poruku da jelo nije

obrisano. (IA) Izvrsavanje scenarija se prekida.

14

Sa navedenih dijagrama sekvence uoavaju se dvije sistemske operacije: 1. PronadjiJelo(Jelo) 2. BrisiJelo(Jelo) DS5 Dijagram sekvence za sluaj korienja: Unos nove prodaje Osnovni scenario SK: 1. Radnik poziva sistem da pronae unese novu prodaju. (APSO) 2. Sistem unosi novu prodaju. (IA)

15

Alternativna scenarija: 2.1 Ukoliko sistem nije mogao da unese prodaju, prikazuje poruku da takava prodaja ne postoji. (IA) Izvravanje scenarija se prekida.

Sa navedenih dijagrama sekvence uoava se tri sistemske operacije: 1. UnesiProdaju(Prodaja);

DS6 Dijagram sekvence za sluaj korienja: Pregled podataka o prodaji Osnovni scenario SK: 1. Radnik poziva sistem da pronae prodaju po navedenom kriterijumu. (APSO) 2. Sistem prikazuje prodaju koja zadovoljava kriterijum pretrage. (IA)

16

Alternativna scenarija: 2.1 Ukoliko sistem nije mogao da pronadje prodaju, prikazuje poruku da takava prodaja ne postoji. (IA) Izvravanje scenarija se prekida.

Sa navedenih dijagrama sekvenci uoava se jedna sistemska operacija: 1. PronadjiProdaju(Prodaja)

DS7 Dijagram sekvenci za sluaj korienja: Promjena podataka o prodaji Osnovni scenario SK: 1. Radnik poziva sistem da pronae prodaju po navedenom kriterijumu. (APSO) 2. Sistem prikazuje prodaju koje zadovoljava kriterijum pretrage. (IA) 3. Radnik poziva sistem da zapamti unijete izmjene. (APSO) 4. Sistem prikazuje poruku da su podaci o prodaji uspijeno promijenjeni. (IA)

17

Alternativni scenario SK:

2.1 Ukoliko sistem nije mogao da pronae prodaju, prikazuje se poruka da nije mogao da

pronae prodaju koje zadovoljava postavljeni kriterijum. (IA) Izvravanje scenarija se prekida.

4.1 Ukoliko sistem ne uspije da sauva promjene o prodaji, prikazuje poruku o tome. (IA)

Izvravanje scenarija se prekida.

18

Sa navedenih dijagrama sekvenci uoavaju se dvije sistemske operacije: 1. PronadjiProdaju(Prodaja) 2. IzmjenaProdaje(Prodaja)

DS4 Dijagram sekvenci za sluaj korienja: Brisanje prodaje Osnovni scenario SK: 1. Radnik poziva sistem da pronae prodaju. (APSO) 2. Sistem prikazuje traenu prodaju. (IA) 3. Radnik poziva sistem da izbrise pronaenu prodaju. (APSO) 4. Sistem prikazuje poruku da je prodaja uspijeno izbrisana. (IA)

19

Alternativna scenarija: 2.1 Ukoliko sistem nije mogao da pronae prodaju sa zadatim atributom pretrage, prikazuje poruku da takava prodajane postoji. (IA) Izvravanje scenarija se prekida.

4.1 Ukoliko sistem nije mogao da izbrise prodaju, sistem prikazuje poruku da prodaja nije

obrisano. (IA) Izvrsavanje scenarija se prekida.

20

Sa navedenih dijagrama sekvenci uoavaju se dvije sistemske operacije: 1. PronadjiProdaju(Prodaja) 2. BrisanjeProdaje(Prodaja)

2.1.2. Definisanje ugovora o sistemskim operacijama

Za svaki od uoenih sistemskih operacija ( opisuje ponaanje softverskog sistema, ima svoj potpis, koji sadri ime metode i opciono ulazne i izlazne argumente, ona je javna i njoj se moe pristupiti iz okruenja softverskog sistema ) prave se ugovori. Ugovori opisuju ta operacija treba da radi, bez objanjenja kako e to da uradi. Jedan ugovor je vezan za jednu sistemsku operaciju. Ugovori se sastoje od sljedeih sekcija :

Operacija ime operacije i njen ulazni i izlazni argumenti; Veza sa SK imena SK u kojima se poziva sistemska operacija; Preduslov pre izvrenja sistemske operacije moraju biti zadovoljeni odreeni preduslovi (sistem mora biti u odgovarajuem stanju). Postuslovi posle izvrenja sistemske operacije u sistemu moraju biti zadovoljeni odreeni postuslovi (sistem mora biti u odgovarajuem stanju ili se ponitava rezultat operacije).

21

Postuslovi SO ukazuju na to ta treba da se desi (efekti izvrenja SO), nakon izvrenja SO, a ne kako e to da se desi. Postuslovi se izraavaju u prolom vremenu, kako bi se naglasilo da je objekat doao u novo stanje, a ne da e doe u novo stanje. Preduslovi SO ukazuju na to ta je trebalo da se desi, kako bi SO mogla da se izvri, a ne kako se to desilo.

Ugovor UG1 UnesiJelo Operacija: UnesiJelo(Jelo):signal; Veza sa SK: SK1 Preduslov: Postuslov: Jelo je uneeno

Ugovor UG2 PronadjiJelo Operacija: PronadjiJelo(Jelo):signal; Veza sa SK: SK2 Preduslov: Jelo postoji Postuslov: Pronaeno je traeno jelo

Ugovor UG3 IzmijenaJela Operacija: IzmjenaJela(Jelo):signal; Veza sa SK: SK3 Preduslov: Jelo postoji Postuslov: Jelo je izmijenjeno

Ugovor UG4 BriiJelo Operacija: BrisiJelo(Jelo):signal;

22

Veza sa SK: SK4 Preduslov: Jelo postoji Postuslov: Jelo je obrisano

Ugovor UG5 UnesiProdaju Operacija: UnesiProdaju(Prodaju):signal; Veza sa SK: SK5 Preduslov: - Jelo postoji Postuslov: Prodaja je uneena

Ugovor UG6 PronadjiProdaju Operacija: PronadjiProdaju(Prodaja):signal; Veza sa SK: SK6 Preduslov: Jelo postoji Postuslov: Pronaena je traena prodaja

Ugovor UG7 IzmijenaProdaje Operacija: IzmjenaProdaje(Prodaja):signal; Veza sa SK: SK7 Preduslov: Prodaja postoji Postuslov: Prodaja je izmijenjena

Ugovor UG8 BriiProdaju Operacija: BrisiProdaju(Prodaja):signal;

23

Veza sa SK: SK8 Preduslov: Prodaja postoji Postuslov: Prodaja je obrisana

2.1.3

Ogranienja pri izvrenju sistemskih operacija

Sistemske opercije se mogu sstojti od:

Opercij odrvnj bze podtk (ubci, izbci i promjeni) i/ili Opercij izvjetvnj.

U toku izvrenj sistemske opercije nd strukturom softverskog sistem (odnosno nd bzom podtk) podci (objekti u opertivnoj memoriji i slogovi u bzi podtk) morju d ostnu konzistentni, odnosno morju d budu zdovoljen vrijednosn i strukturn orgnienj definisn nd podcim. Vrijednosn ogrnienj se odnose n dozvoljene vrednosti tribut domenskih kls (tbel) i on se dijele n: ) prost vrednosn ogrnienj - ogrnienj n domen (tip) tribut i vrijednost tribut. b) sloen vrijednosn ogrnienj - meuzvisnost tribut. Strukturn orgnienj su definisn preko krdinlnosti preslikvnj izmeu domenskih kls (tbel). Pri izvrenju opercij ubci i promjeni objekt (slog) provjervju se i vredijnosn i strukturn ogrnienj. Kod ugovor z sistemske opercije u odjeljku postuslovi se nvodi rezultt opercij ubci i promjeni . Kod ugovor z sistemske opercije u odeljku preduslovi se nvode prost vredijnosn ogrnienj. Sloen vrijednosn ogrnienj se mogu nvesti u odjeljku preduslovi ili se mogu nvesti kroz relizciju sistemske opercije. Pri izvrenju opercije obrii objekt (slog) provjervju se strukturn ogrnienj. Kod ugovor z sistemske opercije u odjeljku postuslovi se nvodi rezultt opercij obrii dok se u odeljku preduslovi nit ne nvodi. Pri izvrenju opercije izvjetvnj ne provervju se vrijednosn i strukturn ogrnienj. Kod ugovor z sistemske opercije u odjeljcim postuslovi i preduslovi nit se ne nvodi.

24

2.2

Logika struktura softverskog sistema

2.2.1

Konceptualni (Domenski) model

Struktura softverskog sistema se opisuje pomou konceptualnog modela. Konceptualni model opisuje konceptualne klase domena problema. Konceptualni model sadri konceptualne klase i asocijacije izmeu konceptualnih klasa. esto se za konceptualne klase kae da su to domenski modeli ili modeli objektne analize.

25

26

2.2.1. Relacioni model

Na osnovu konceptualnog modela moe se napraviti relacioni model, koji e u daljem toku razvoje informacionog sistema, predstavljati osnovu za projektovanje relacione baze podataka.

Jelo (ID_jela, naziv_jela, prodajna_cijena). Prodaja (broj_racuna, ID_jela, kolicina_jela, ukupna_cijena, datum_prodaje).

Tabela jelo

Prosto vrijednosno ogranienje Tip atributa Integer String Double Vrednost atributa not null not null not null

Sloeno vrijednosno ogranienje Meuzav. atributa jedne tabele Meuzav. atributa vie tabela

Strukturn o ogranien je INSERT CASCADE S prodaja UPDATE RESTRICT ED prodaja DELETE RESTRICT ED prodaja

Ime

ID_jela naziv_jela cijena

Tabela prodaja Atri buti Ime

Prosto vrijednosno ogranienje Tip Vredno atribu st ta atribut a

Sloeno vrijednosno ogranienje Meu zav. atrib uta jedne tabel e Meuzav. atributa vie tabela

Strukturno ogranienj e

INSERT RESTRICTE D jelo prodaja.ID_jela=jelo.I D_jela

broj_racuna ID_jela kolicina_jela ukupna_cijen a datum-

Intege r Intege r Doubl e Doubl e String

not null not null not null not null not

27

prodaje

null

3.0. PROJEKTOVANJE
Faza projektovanja opisuje fiziku strukturu i ponaanje softverskog sistema. Projektovanje arhitekture softverskog sistema obuhvata projektovanje aplikacione logike, skladista podataka i korisnikog interfejsa. U okviru aplikacione logike se projektuju kontroler, poslovna logika i database broker. Projektovanje poslovne logike obuhvata projektovanje logike strukture i ponaanje softverskog sistema.

3.1

Arhitektura softverskog sistema

U projektovanju softverskog sistema korien je model arhitekture sa tri nivoa: korisnikim interfejsom, aplikacionom logikom i skladistem podataka.

Tronivojska arhitektura se sastoji iz sljedeih nivoa:

1. Korisnikog interfejsa koji predstavlja ulazno izlaznu reprezentaciju softverskog

sistema.
2. Aplikacione logike koja opisuje strukturu i ponaanje softverskog sistema. 3. Skladista podataka koji uva stanje atributa softverskog sistema.

28

Aplikaciona logika se sastoji od: kontrolera aplikacione logike, poslovne logike i upravljaa bazom podataka.

Poslovna logika je opisana strukturom (domenskim klasama) i ponaanjem (sistemskim operacijama). Kontroler je odgovoran da prihvati zahtjeve za izvrenje sistemske operacije od klijenta i da ga proslijedi do poslovne logike koja je odgovorna za izvravanje sistemske operacije. Database broker je odgovoran za komunikaciju izmeu poslovne logike i skladita podataka. Dakle do sada smo kroz faze prikupljanja zahtjeva i analize dali specifikaciju strukture i ponaanja softverskog sistema, odnosno specifikaciju poslovne logike softverskog sistema.

3.1.1. Projektovanje aplikacione logike Kontroler

Preko klase KontrolerAL prihvatamo zahtjeve od klijenta i izvravanje sistemskih operacija i iste prosleujemo do odgovarajuih klasa koje su odgovorne za izvravanje SO. Za svaku od SO prave se softverske klase koje treba da realizuju SO i takve klase nazivamo softverske klase ponaanja, jer SO opisuju ponaanje sistema.
29

30

3.1.2. Projektovanje aplikacione logike domenske klase

Na osnovu konceptualnih klasa prave se softverske klase strukture (Jelo, Prodaja).

3.1.3. Projektovanje aplikacione logike sistemske operacije

U poetku projektovanja SO treba napraviti konceptualne relacije za svaku SO. Konceptualne relacije treba da budu direktno povezane sa logikom probema. Moe se predpostaviti da se podaci uvaju u bazi i u tom smislu mogu se pozvati neke od osnovnih operacija baze (insert, update, delete, ), bez ulaenja u nain njihove realizacije. Konceptualne realizacije se mogu opisati preko: objektnog pseudokola, dijagrama saradnje, sekvencnih dijagrama, dijagrama aktivnosti, dijagrama prelaza stanja ili dijagrama struktura.

31

Projektovanje konceptualnih reenja SO Ugovor UG1 UnesiJelo Operacija: UnesiJelo(Jelo):signal; Veza sa SK: DS1 Preduslov: Postuslov: Jelo je uneeno Dijagram sekvence:

Dijagram saradnje:

32

Ugovor UG2 PronadjiJelo Operacija: PronadjiJelo(Jelo):signal; Veza sa SK: DS2, DS3, DS4 Preduslov: Jelo postoji Postuslov: Pronaeno je traeno jelo Dijagram sekvence:

Dijagram saradnje:

33

Ugovor UG3 IzmijeniJelo Operacija: IzmjeniJelo(Jelo):signal; Veza sa SK: DS3 Preduslov: Jelo postoji Postuslov: Jelo je izmijenjeno Dijagram sekvence:

Dijagram saradnje:

34

Ugovor UG4 BriiJelo Operacija: BrisiJelo(Jelo):signal; Veza sa SK: DS4 Preduslov: Jelo postoji Postuslov: Jelo je obrisano Dijagram sekvence:

Dijagram saradnje:

35

Ugovor UG5 UnesiProdaju Operacija: UnesiProdaju(prodaja):signal; Veza sa SK: DS5 Preduslov: -Jelo postoji Postuslov: prodaja je uneena Dijagram sekvence:

Dijagram saradnje:

36

Ugovor UG6 PronadjiProdaju Operacija: PronadjiProdaju(Prodaja):signal; Veza sa SK: DS5, DS6, DS7 Preduslov: Prodaja postoji Postuslov: Pronaena je traena prodaja Dijagram sekvence:

Dijagram saradnje:

37

Ugovor UG7 IzmijeniProdaju Operacija: IzmjeniProdaju(Prodaja):signal; Veza sa SK: DS7 Preduslov: Prodaja postoji Postuslov: Prodaja je izmijenjena Dijagram sekvence:

Dijagram saradnje:

38

Ugovor UG8 BrisiProdaju Operacija:BrisiProdaju(Prodaja):signal; Veza sa SK: DS8 Preduslov: Prodaja postoji Postuslov: Prodaja je obrisana Dijagram sekvence:

Dijagram saradnje:

39

Projektujemo klasu koja e biti zaduena za uspostavljanje veze sa bazom, raskidanje veze i provjeru uspijenosti transtakcije. Da bi se obezbijedilo da se izvrenje svih SO prati kao transakcija, sve SO nasledice klasu (OpstaSO).

40

3.1.4. Projektovanje aplikacione logike DatabaseBroker

Klasa koja e obezbijediti perzistentnost objekata razliitih klasa je DatabaseBroker. Da bi se obezbijedila univerzalnost korienja metoda projektovanja klase (da bi se mogle koristiti sve domenske klase), izvriemo generalizaciju interfejs OpstiDomenskiObjekat, koje e implementirati sve domenske klase.

41

3.2. Projektovanje skladita podataka

Na osnovu softverskih klasa strukture projektovali smo tabele (skladita podataka) relacionog sistema za upravljanje bazom podataka. Za izradu skladita podataka koriten je MySQL.

Tabela: jelo

42

Tabela: prodaja

43

3.3 Struktura korisnikog interfejsa

Korisniki interfejs predstavlja relaciju ulaza i/ili izlaza softverskog sistema. Korisniki interfejs se sastoji od: Ekranske forme koja je odgovorna da: 1. Prihvata podatke koje unosi aktor, 2. Prihvata dogaaje koje pravi aktor, 3. Poziva kontrolera grafikog interfejsa, prosleuje mu prihvaene podatke, 4. Prikazuje podatke koje je dobio od kontrolera grafikog interfejsa. Kontrolera korisnikog interfejsa koji je odgovoran da: 1. Prihvata podatke koje alje ekranska forma, 2. Konvertuje podatke (koji se nalaze u grafikim elementima) u objekat koji predstavlja ulazni argument SO koja e biti pozvana, 3. alje zahtjeve za izvrenje SI do aplikacionog softvera (softverskog sistema), 4. Prihvata objekat softverskog sistema koje nastaje kao rezultat izvrenja SO i 5. Konvertuje objekat u podatke grafikih elemenata.

3.3.1. Projektovanje ekranske forme Glavni meni je realizovan u klasi Restoran.java, preko kog se pozivaju sve druge korisnike forme. Sa glavnog menija se pozivaju sledee forme. I. Jelo II. Prodaja Unos Pregled Brisanje Izmjena

Unos Pregled Brisanje Izmjena

44

Izgled poetne forme

45

SK 1 Sluaj korienja: Unos novog jela Preduslov: Sistem je ukljuen. Sistem prikazuje formu za unos novog jela. Osnovni scenario SK:
1. Radnik unosi podatke o novom jelu. (APUSO) 2. Radnik kontrolise unijete podatke. (ANSO) 3. Radnik poziva sistem da sauva podatke o jelu. (APSO)

4. Sistem uva novo jelo. (SO) 5. Sistem prikazuje obavjestenje da je novo jelo uspijesno sauvano. (IA)

46

Alternativna scenarija:
5.2 Ukoliko sistem nije mogao da sauva jelo, prikazuje poruku da novo jelo ne moe biti

sauvano. (IA) Izvrsavanje scenarija se prekida.

SK 2 Sluaj korienja: Pregled podataka o jelu Preduslov: Sistem je ukljuen. Sistem prikazuje formu za pregled jela.. Osnovni scenario SK:
1. Radnik unosi kriterijum pretrage jela. (APUSO) 2. Radnik poziva sistem da pronae jelo po navedenom kriterijumu. (APSO) 3. Sistem pronalazi jelo. (SO) 4. Sistem prikazuje jelo koje zadovoljava kriterijum pretrage. (IA)

47

Alternativni scenario SK:

4.2 Ukoliko sistem nije mogao da pronae jelo, prikazuje poruku da nije mogao da

pronae jelo koje zadovoljava postavljeni kriterijum. (IA) Izvrsavanje scenarija se prekida.

SK 3 Sluaj korienja: Promjena podataka o jelu Preduslov: Sistem je ukljuen. Sistem prikazuje formu za promjenu podataka o jelu. Osnovni scenario SK:
1. 2. 3. 4.

Radnik unosi kriterijum pretrage jela. (APUSO) Radnik poziva sistem da pronae jelo po navedenom kriterijumu. (APSO) Sistem pronalazi jelo. (SO) Sistem prikazuje jelo koje zadovoljava kriterijum pretrage. (IA)

48

5. Radnik mijenja podatke o jelu. (APUSO)

6. Radnik poziva sistem da zapamti unijete izmjene. (APSO)

7. Sistem pamti izmjene o jelu. (SO) 8. Sistem prikazuje poruku da su podaci uspjeno promjenjeni. (IA)

Alternativni scenario:
4.2 Ukoliko sistem nije mogao da pronae jelo, prikazuje poruku da nije mogao da

pronae jelo koje zadovoljava postavljeni kriterijum. (IA) Izvrsavanje scenarija se prekida.

49

8.2 Ukoliko sistem ne uspije da sauva promjene o jelu, prikazuje poruku o tome. (IA)

Izvravanje scenarija se prekida.

SK 4 Sluaj korienja: Brisanje jela Preduslov: Sistem je ukljuen. Sistem prikazuje formu za brisanje jela. Osnovni scenario SK:
1. 2. 3. 4.

Radnik unosi kriterijum pretrage jela. (APUSO) Radnik poziva sistem da pronae jelo po navedenom kriterijumu. (APSO) Sistem pronalazi jelo. (SO) Sistem prikazuje jelo koji zadovoljava kriterijum pretrage. (IA)

5. Radnik poziva sistem da izbrise pronaeno jelo. (APSO) 6. Sistem brise jelo. (SO) 7. Sistem prikazuje poruku da je jelo uspjeno izbrisano. (IA)

50

Alternativna scenarija:
4.2 Ukoliko sistem nije mogao da pronae jelo, prikazuje poruku da nije mogao da

pronae jelo koje zadovoljava postavljeni kriterijum. (IA) Izvrsavanje scenarija se prekida.

7.2 Ukoliko sistem nije mogao da obrie jelo, sistem prikazuje poruku da jelo nije

obrisano. (IA) Izvravanje scenarija se prekida. SK5 Sluaj korienja: Unos nove prodaje Preduslov: Sistem je ukljuen. Sistem prikazuje formu za izbor jela za prodaju. Osnovni scenario SK:
1. Radnik unosi podatke o novoj prodaji. (APUSO) 2. Radnik kontrolise unijete podatke. (ANSO)

51

3. Radnik poziva sistem da sauva podatke o prodaji. (APSO) 4. Sistem uva novu prodaju. (SO) 5. Sistem prikazuje obavjestenje da je nova prodaja uspijesno sauvana. (IA)

Alternativna scenarija:
5.2 Ukoliko sistem nije mogao da sauva prodaju, prikazuje poruku da nova prodaja ne

moe biti sauvana. (IA) Izvrsavanje scenarija se prekida.

SK 6 Sluaj korienja: Pregled podataka o prodaji Preduslov: Sistem je ukljuen. Sistem prikazuje formu za pregled prodaje. Osnovni scenario SK:
1. Radnik unosi kriterijum pretrage prodaje. (APUSO)

52

2. Radnik poziva sistem da pronae prodaju po navedenom kriterijumu. (APSO) 3. Sistem pronalazi prodaju. (SO) 4. Sistem prikazuje prodaju koja zadovoljava kriterijum pretrage. (IA)

Alternativni scenario SK:

4.2 Ukoliko sistem nije mogao da pronae prodaju, prikazuje poruku da nije mogao da

pronae prodaju koja zadovoljava postavljeni kriterijum. (IA) Izvrsavanje scenarija se prekida.

SK 7 Sluaj korienja: Promjena podataka o prodaji Preduslov: Sistem je ukljuen. Sistem prikazuje formu za promjenu podataka o prodaji.

53

Osnovni scenario SK:

1. Radnik unosi kriterijum pretrage prodaje. (APUSO)

2. Radnik poziva sistem da pronae prodaju po navedenom kriterijumu. (APSO) 3. Sistem pronalazi prodaju. (SO) 4. Sistem prikazuje prodaju koja zadovoljava kriterijum pretrage. (IA)

54

5. Radnik mijenja podatke o prodaji. (APUSO)

6. Radnik poziva sistem da zapamti unijete izmjene. (APSO)

7. Sistem pamti izmjene o prodaji. (SO)

8. Sistem prikazuje poruku Radniku da su podaci uspijeno promijenjeni. (IA)

Alternativni scenario:
4.2 Ukoliko sistem nije mogao da pronae prodaju, prikazuje poruku da nije mogao da

pronae rezervaciju koja zadovoljava postavljeni kriterijum. (IA) Izvrsavanje scenarija se prekida.

55

8.2 Ukoliko sistem ne uspije da sauva promjene o prodaji, prikazuje poruku o tome. (IA)

Izvravanje scenarija se prekida. SK 8 Sluaj korienja: Brisanje prodaje Preduslov: Sistem je ukljuen. Sistem prikazuje formu za brisanje prodaje. Osnovni scenario SK:
1. Radnik unosi kriterijum pretrage prodaje. (APUSO)

2. Radnik poziva sistem da pronae prodaju po navedenom kriterijumu. (APSO) 3. Sistem pronalazi prodaju. (SO) 4. Sistem prikazuje prodaju koji zadovoljava kriterijum pretrage. (IA)

56

5. Radnik poziva sistem da izbrise pronaenu prodaju. (APSO) 6. Sistem brise prodaju. (SO) 7. Sistem prikazuje poruku da je prodaja uspjeno izbrisana. (IA)

Alternativna scenarija:
4.2 Ukoliko sistem nije mogao da pronae prodaju, prikazuje poruku da nije mogao da

pronae prodaju koja zadovoljava postavljeni kriterijum. (IA) Izvrsavanje scenarija se prekida.

7.2 Ukoliko sistem nije mogao da obrie prodaju, sistem prikazuje poruku da prodaja nije

obrisana. (IA) Izvravanje scenarija se prekida.

57

4. IMPLEMENTACIJA Softverski proizvod je implementiran u programskom jeziku JAVA, a kao razvojno okruenje korien je NetBeans 6.1. Za realizovanje skladita podataka, korien je MySQL 5.5.17. Na osnovu arhitekture siftverskog sistema, dobili smo sledee softverske klase: DatabaseBroker.java IzmijenijJelo.java IzmijeniProdaju.java Jelo.java KontrolerAL.java KontrolerKI.java Main.java ObrisiJelo.java ObrisiProdaju.java OpstaSO.java OpstiDomenskiObjekat.java Prodaja.java PronadjiJela.java PronadjiJelo.java PronadjiProdaje.java PronadjiProdaju.java UnesiJelo.java UnesiProdaju.java frmBrisanjejela.java frmBrisanjeProdaje.java frmIzmjenaJela.java frmIzmjeniProdaju.java frmPocetnaRestoran.java frmPregledProdaje.java frmPregledSviProdaja.java frmPregledSvihJela.java frmPrpnadjiJelo.java frmUnesiJelo.java frmUnesiProdaju.java

58

5. TESTIRANJE
Testiranje, shodno arhitekturi softverskog sistema, moe da se podijeli u nekoliko nezavisnih jedinica testiranja. Nezavisne jedinice testiranja su softverske komponente koje smo dobili u fazi implementacije softverskog sistema. Testiranje svake softverske komponente podrazumijeva pravljenje: Test sluajeva koji opisuju sta test treba da provjeri. Test procedura koje opisuju kako e se izvriti test. Test komponente koje treba da autometizuju test procedure ukoliko je to mogue.

Nakon testiranja softverskih komponenti vri se njihova integracija. U tom smislu se prave testovi integracije softverskih komponenti. Svaki sluaj korienja je testiran, pri tome se u procesu testiranja forme popunjavaju ispravnim, kao i neispravnim podacima, iji je cilj bio da se vidi reagovanje sistema na sve mogue situacije koje mogu da se pojave.

59