Seminarski Rad Softverski Proces

UNIVERZITET U BEOGRADU

FAKULTET ORGANIZACIONIH NAUKA

Seminarski rad iz predmeta Softverski proces

Primena paterna u razvoju softverskog sistema za glasanje na izborima

Mentor:

Student:

Prof. dr Siniša Vlajić

Đurđević Jelena 3701/2012

Februar 2013.

Sadržaj 1. Uvod .......................................................................................................................................................... 3 2. Larmanova metoda za razvoj softvera ...................................................................................................... 4 3. Korisnički zahtevi....................................................................................................................................... 5 3.1. Verbalni opis ..................................................................................................................................... 5 3.2. Slučajevi korišćenja ............................................................................................................................ 5 4. Analiza ..................................................................................................................................................... 17 4.1.Ponašanje softverskog sistema – sistemski dijagram sekvenci ........................................................ 17 Rezultat analize sistemskog dijagrama sekvenci ................................................................................ 34 4.2. Ponašanje softverskog sistema – Definisanje ugovora o sistemskim operacijama ......................... 35 4.3. Struktura softverskog sistema – Konceptualni (domenski) model .................................................. 38 4.4. Struktura softverskog sistema – Relacioni model ........................................................................... 39 5. Projektovanje .......................................................................................................................................... 43 5.1. Arhitektura softverskog sistema...................................................................................................... 43 5.2. Projektovanje korisničkog interfejsa ............................................................................................... 45 5.2.1. Projektovanje ekranske forme ................................................................................................. 45 5.3. Projektovanje aplikacione logike ..................................................................................................... 72 5.3.1. Kontroler aplikacione logike ..................................................................................................... 72 5.3.2. Projektovanje ponašanja softverskog sistema – sistemske operacije ..................................... 72 5.3.3. Projektovanje strukture softverskog sistema .......................................................................... 75 5.3.4. Projektovanje aplikacione logike – DatabaseBroker ................................................................ 76 5.4. Projektovanje skladišta podataka .................................................................................................... 77 5.5. Principi, metode i strategije projektovanja softvera ....................................................................... 79 5.5.1. Principi (tehnike) projektovanja softvera ................................................................................. 79 5.5.2. Strategije projektovanja softvera ............................................................................................. 92 5.5.3. Metode projektovanja softvera ............................................................................................... 95 6. Primena paterna u projektovanju ......................................................................................................... 102 6.1. Opšte o paternima ......................................................................................................................... 102 6.2. Paterni kao rešenja problema projektovanja ................................................................................ 103 7. Implementacija .................................................................................................................................... 116 8. Zaključak................................................................................................................................................ 118 Literatura .................................................................................................................................................. 119 1

Dodatak 1 .................................................................................................................................................. 120 Dodatak 2 .................................................................................................................................................. 124 Dodatak 3 .................................................................................................................................................. 126 Dodatak 4 .................................................................................................................................................. 128 Dodatak 5 .................................................................................................................................................. 129 Dodatak 6 .................................................................................................................................................. 132 Dodatak 7 .................................................................................................................................................. 134

2

1. Uvod Da bi se razvio kvalitetan softver nije moguće samo sesti za računar i otkucati odgovarajući programski kod, jer bez obzira koliko neko bio iskusan programer ne može realno da sagleda celokupan problem bez detaljne analize i planiranja svake faze razvoja softvera. Bez dobre metodologije razvoja softvera nema ni dobrog konačnog softverskog proizvoda. Imajući to u vidu u ovom radu korišćena je Larmanova metoda razvoja softvera koja se u praksi pokazala kao odlična metoda za razvoj kvalitetnog, modularnog i lako održivog softvera. Razvijen je softverski sistem za glasanje na izborima prolazeći kroz svih pet faza Larmanove metode razvoja softvera: specifikaciju zahteva, analizu, projektovanje, implementaciju i testiranje. U fazi specifikacija zahteva opisan je skup željenih korišćenja sistema od strane korisnika, preko modela slučaja korišćenja (Use-Case Model). Faza analize oslanja se na dobro definisane i objašnjene slučajeve korišćenja. U fazi analize opisana je logička struktura i ponašanje softverskog sistema (poslovna logika softverskog sistema). U fazi analize kreirani su: dijagrami sekvenci, ugovori i konceptualni model. U fazi projektovanja je, na osnovu objektno orijentisane analize, opisana fizička struktura i ponašanje softverskog sistema (arhitektura softverskog sistema). U fazi projektovanja kreirani su: stvarni slučajevi korišcenja, dijagrami saradnje, sekvencijalni dijagrami , dijagrami klasa. U fazi implementacije izvršeno je kodiranje softverskog sistema u programskom jeziku Java, u NetBeans okruženju. Takođe, u razvoju softvera korišćeni su paterni, odnosno rešenja problema koji su se već javljali i koje je neko već rešio. Predstavljeni su korišćeni paterni, njihov opšti pregled, način na koji funkcionišu i prednosti njihovog korišćenja.

3

2. Larmanova metoda za razvoj softvera Larmanova metoda životnog ciklusa softvera je bazirana na iterativno inkrementalnom modelu životnog ciklusa softvera, vođena slučajevima korišćenja (use-case driven) i objektno orijentisana metoda projektovanja softvera. Za notaciju se koriste UML dijagrami. Faze Larmanove metode razvoja softvera su: 1. Opis zahteva i slučajevi korišćenja 2. Analiza 3. Projektovanje 4. Implementacija 5. Testiranje U prvoj fazi se formulišu zahtevi koje softver treba da ispuni. Zahtevi se opisuju pomoću modela slučaja korišćenja (Use-case Model), kojim se opisuje skup željenih korišćenja sistema od strane korisnika. U ovoj fazi se definišu učesnici u sistemu i svi slučajevi korišćenja. Najčešće se počinje tekstualnim opisom zahteva da bi se, formiranjem slučajeva korišćenja, taj zahtev transformisao u manje ali logički relativno nezavisne celine. Slučajevi korišćenja se opisuju tekstualno i grafički. Faza analize opisuje logičku strukturu i ponašanje softverskog sistema (poslovnu logiku softverskog sistema). Glavni dijagrami koji se kreiraju u fazi analize su: - konceptualni model; - sekvencijalni dijagrami sistema; - ugovori. U ovoj fazi se definiše konceptualni model koji služi kao osnova za izradu relacionog modela i šeme baze podataka. U trećoj fazi vrši se projektovanje aplikacione strukture, njenih klasa i metoda. Na osnovu objektno orijentisane analize koja je prethodila, opisuje fizička struktura i ponašanje softverskog sistema (arhitektura softverskog sistema). Kao ulaz koriste se rezultati iz prethodne faze: konceptualni model i sistemske operacije i njihovi ugovori. Izlaz iz ove faze su stvarni slučajevi korišćenja, dijagrami saradnje, dijagrami sekvenci za sistemske operacije i dijagrami klasa koji obuhvataju sve klase iz aplikacije i njihove relacije i metode. Četvrta faza je faza implementacije. Svaka klasa iz dijagrama se implementira po unapred definisanom redosledu: prvo se implementiraju klase koje ne zavise od drugih klasa, pa se u svakom sledećem ciklusu implementiraju samo one klase koje zavise isključivo od već implementiranih. Izlaz iz faze je program. Poslednja faza je faza testiranja programa. Mada Larman podrazumeva fazu testiranja posle faze implementacije, opšta preporuka je da se ove dve faze vrše paralelno, odnosno da se testovi za klase pišu i izvršavaju uporedo sa implementacijom samih klasa. Sistem raste dodavanjem novih funkcionalnosti sa svakim razvojnim ciklusom. Posle preliminarne faze planiranja i razrade, razvoj se nastavlja u fazi izgradnje kroz seriju razvojnih ciklusa analize,projektovanja, implementacije i testiranja.

4

3. Korisnički zahtevi Korisnički zahtevi se predstavljaju svojstva i uslove koje sistem ili šire gledajući projekat mora da zadovolji. Korisnički zahtevi mogu biti funkcionalni i nefunkcionalni. Funkcionalni zahtevi definšu zahtevane funkcije sistema, dok nefunkcionalni zahtevi definišu sve ostale zahteve. Korisnički zahtevi se kod Larmana opisuju pomoću verbalnog modela i modela slučaja korišćenja sistema. Slučaj korišćenja predstavlja način korišćenja softvera. Sastoji se iz scenarija, osnovnog i alternativnog. Verbalni model predstavlja verbalni opis onoga što se očekuje da softver radi, model u kome se opisuje svrha postojanja softvera.

3.1. Verbalni opis Aplikacija treba da obezbedi manipulaciju podacima o izborima, kandidatima i glasačima kao i da omogući glasačima da glasaju na izborima. Aplikaciju koriste dve vrste korisnika. Sa jedne strane, korisnik je zaposleni u Vladi RS, koji u sistemu čuva jedinstven birački spisak sa stanovnicima države i šiframa njihovih naloga, koji građani dobijaju pre izbora kojim bi se ulogovali i mogli da glasaju na izboru. Takođe, on unosi u sistem kandidate i dodeljuje svakog kandidata određenim izborima za koji se on kandiduje (po određenoj godini izbora i tome da li je kandidat na lokalnom ili državnom nivou). Kao poslednji korak koji aplikacija treba da omogući zaposlenom u Vladi je pregled rezultata glasanja odnosno koji kandidat, iz koje stranke je imao koji broj glasača. Sa druge strane, deo aplikacije koji se odnosi na glasanje treba da omogući građaninu da se prijavi na sistem sa svojim matičnim brojem i šifrom koju je dobio na glasačkom listiću i da glasa. Obzirom da u isto vreme mogu biti aktuelni i lokalni i republički izbori, glasač treba da se odluči na kojim izborima glasa i u zavisnosti od toga mu se prikazuju ponuđeni kandidati (ukoliko glasa za lokalne izbore, na osnovu podataka o građaninu koji su u sistemu, treba da mu se obezbedi da mu budu ponuđeni samo kandidati iz njegovog grada.) Na kraju, kada jednom obavi glasanje, potrebno je obezbediti, da ne može više da glasa na istim izborima. Ovde će biti prikazana pojednostavljena verzija ove aplikacije, pošto glasanje na izborima zahteva visok stepen bezbednosti. Ukoliko bi se ovakva aplikacija našla u realnoj upotrebi, problemi bezbednosti bi morali biti rešeni.

3.2. Slučajevi korišćenja Model slučajeva korišćenja se sastoji od skupa slučaja korišćenja (SK), aktora (AK) I veza između slučaja korišćenja i aktora. Slučaj korišćenja opisuje skup scenarija (use-case pojavljivanja), odnosno skup željenih korišćenja sistema od strane aktora. Scenario opisuje jedno željeno korišćenje sistema od strane aktora. SK ima jedan osnovni I više alternativnih scenarija. Ovu aplikaciju koriste dva aktora: zaposleni u Vladi RS (zaposleni) i građanin (glasač). Na osnovu verbalnog opisa uočeni su sledeći slučajevi korišćenja (slika 1): 1. Unos novog kandidata 2. Izmena kandidata 3. Brisanje kandidata 5

4. 5. 6. 7. 8. 9. 10.

Unos izbora Unos glasača Izmena glasača Brisanje glasača Logovanje glasača Glasanje za kandidata Pregled izbornih rezultata

Slika 1. Slučajevi korišćenja

6

1. Unos novog kandidata Naziv sk: Unos novog kandidata Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa kandidatima. Zaposleni poziva sistem da učita sve gradove (APSO). Sistem učitava sve gradove(SO). Sistem vraća sve gradove(IA). Osnovni scenario sk: 1. 2. 3. 4. 5.

Zaposleni unosi podatke o novom kandidatu (APUSO) Zaposleni kontroliše da li je uneo sve podatke o novom kandidatu (ANSO) Zaposleni poziva sistem da zapamti novog kandidata (APSO) Sistem pamti novog kandidata (SO) Sistem prikazuje poruku da je novi kandidat uspešno zapamćen (IA)

Alternativni scenario: 5.1. Ukoliko sistem ne može da zapamti novog kandidata, prikazuje zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

7

2. Izmena kandidata Naziv sk: Izmena kandidata Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa kandidatima. Zaposleni poziva sistem da učita sve gradove (APSO). Sistem učitava sve gradove(SO). Sistem vraća sve gradove(IA). Osnovni scenario sk: 1. Zaposleni poziva sistem da prikaže listu svih kandidata (APSO) 2. Sistem vraća listu svih kandidata (SO) 3. Sistem prikazuje listu svih kandidata (IA) 4. Zaposleni bira kandidata kojeg želi da izmeni (APUSO) 5. Zaposleni poziva sistem da mu prikaže podatke o odabranom kandidatu (APSO) 6. Sistem pronalazi podatke o odabranom kandidatu (SO) 7. Sistem prikazuje podatke o odabranom kandidatu (IA) 8. Zaposleni vrši izmenu podataka o kandidatu (APUSO) 9. Zaposleni poziva sistem da zapamti unete izmene (APSO) 10. Sistem pamti izmene o kandidatu (SO) 11. Sistem prikazuje poruku da su podaci o kandidatu uspešno promenjeni (IA) Alternativni scenario: 4.1. Ukoliko sistem ne može da prikaže listu kandidata, prikazuje zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija. 7.1. Ukoliko sistem ne uspe da prikaže podatke o kandidatu, obaveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija. 11.1. Ukoliko sistem ne uspe da sačuva promene, izveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

8

3. Brisanje kandidata Naziv sk: Brisanje kandidata Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa kandidatima. Zaposleni poziva sistem da učita sve gradove (APSO). Sistem učitava sve gradove(SO). Sistem vraća sve gradove(IA). Osnovni scenario sk: 1. Zaposleni poziva sistem da prikaže listu svih kandidata (APSO) 2. Sistem vraća listu svih kandidata (SO) 3. Sistem prikazuje listu svih kandidata (IA) 4. Zaposleni iz liste kandidata bira kandidata kojeg želi da obriše (APUSO) 5. Zaposleni poziva sistem da obriše odabranog kandidata (APSO) 6. Sistem briše odabranog kandidata (SO) 7. Sistem prikazuje poruku da je kandidat uspešno obrisan (IA) Alternativni scenario: 4.1. Ukoliko sistem ne može da prikaže listu kandidata, prikazuje zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija. 8.1. Ukoliko sistem ne uspe da obriše odabranog kandidata, prikazuje poruku o tome. (IA) Prekida se izvršenje scenarija.

9

4. Unos novog izbora Naziv sk: Unos novog izbora Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa izborima. Zaposleni poziva sistem da učita sve tipove izbora (APSO). Sistem učitava sve tipove izbora(SO). Sistem vraća sve tipove izbora(IA). Zaposleni poziva sistem da učita sve kandidate (APSO). Sistem učitava sve kandidate(SO). Sistem vraća sve kandidate(IA). Osnovni scenario sk: 1. 2. 3. 4. 5.

Zaposleni unosi podatke o novom izboru (APUSO) Zaposleni kontroliše da li je uneo sve podatke o novom izboru (ANSO) Zaposleni poziva sistem da zapamti novi izbor (APSO) Sistem pamti novi izbor (SO) Sistem prikazuje poruku da je novi izbor uspešno zapamćen (IA)

Alternativni scenario: 5.1. Ukoliko sistem ne može da zapamti novi izbor, prikazuje poruku zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

10

5. Unos novog glasača Naziv sk: Unos novog glasača Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa glasačima. Zaposleni poziva sistem da učita sve gradove (APSO). Sistem učitava sve gradove(SO). Sistem vraća sve gradove(IA). Osnovni scenario sk: 1. 2. 3. 4. 5.

Zaposleni unosi podatke o novom glasaču (APUSO) Zaposleni kontroliše da li je uneo sve podatke o novom glasaču (ANSO) Zaposleni poziva sistem da zapamti novog glasača (APSO) Sistem pamti novog glasača (SO) Sistem prikazuje poruku da je novi glasač uspešno zapamćen (IA)

Alternativni scenario: 5.1. Ukoliko sistem ne može da zapamti novog glasača, prikazuje poruku zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

11

6. Izmena glasača Naziv sk: Izmena glasača Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa glasačima. Zaposleni poziva sistem da učita sve gradove (APSO). Sistem učitava sve gradove(SO). Sistem vraća sve gradove(IA). Osnovni scenario sk: 1. Zaposleni poziva sistem da prikaže listu svih glasača (APSO) 2. Sistem vraća listu svih glasača (SO) 3. Sistem prikazuje listu svih glasača (IA) 4. Zaposleni iz liste kandidata bira glasača kojeg želi da izmeni (APUSO) 5. Zaposleni poziva sistem da mu prikaže podatke o odabranom glasaču (APSO) 6. Sistem vraća podatke o selektovanom glasaču (SO) 7. Sistem prikazuje podatke o selektovanom glasaču (IA) 8. Zaposleni vrši izmenu podataka o glasaču (APUSO) 9. Zaposleni poziva sistem da zapamti unete izmene (APSO) 10. Sistem pamti izmene o glasaču (SO) 11. Sistem prikazuje poruku da su podaci o glasaču uspešno promenjeni (IA) Alternativni scenario: 3.1. Ukoliko sistem ne uspe da prikaže glasače, obaveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija. 7.1. Ukoliko sistem ne uspe da prikaže podatke o glasaču, obaveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija. 11.1. Ukoliko sistem ne uspe da sačuva promene, izveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

12

7. Brisanje glasača Naziv sk: Brisanje glasača Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa glasačima. Zaposleni poziva sistem da učita sve gradove (APSO). Sistem učitava sve gradove(SO). Sistem vraća sve gradove(IA). Osnovni scenario sk: 1. Zaposleni poziva sistem da prikaže listu svih glasača (APSO) 2. Sistem vraća listu svih glasača (SO) 3. Sistem prikazuje listu svih glasača (IA) 4. Zaposleni iz liste kandidata bira glasača kojeg želi da obriše (APUSO) 5. Zaposleni poziva sistem da obriše odabranog glasača (APSO) 6. Sistem briše odabranog glasača (SO) 7. Sistem prikazuje poruku da je glasač uspešno obrisan (IA) Alternativni scenario: 3.1. Ukoliko sistem ne uspe da prikaže glasače, obaveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija. 7.1. Ukoliko sistem ne uspe da obriše odabranog glasača, prikazuje poruku o tome. (IA) Prekida se izvršenje scenarija.

13

8. Prijavljivanje glasača na sistem Naziv sk: Prijavljivanje glasača na sistem Akteri sk: Glasač Učesnici sk: Glasač i sistem Preduslov: Sistem je uključen. Prikazana je forma za glasanje. Zaposleni poziva sistem da učita sve izbore (APSO). Sistem učitava sve izbore(SO). Sistem vraća sve izbore(IA). Osnovni scenario sk: 1. Glasač unosi svoje podatke potrebne za glasanje (APUSO) 2. Glasač poziva sistem da prijavi na sistem za glasanje (APSO) 3. Sistem proverava unete podatke (SO) 4. Sistem prikazuje poruku o uspesnom prijavljivanju na sistem (IA) Alternativni scenario: 4.1. Ukoliko glasač ne unese ispravne podatke, ne može da se prijavi na sistem i sistem obaveštava glasača o tome. (IA) Prekida se izvršenje scenarija.

14

9. Glasanje Naziv sk: Glasanje Akteri sk: Glasač Učesnici sk: Glasač i sistem Preduslov: Sistem je uključen. Prikazana je forma za glasanje. Glasač je prijavljen na sistem. Zaposleni poziva sistem da učita sve kandidate (APSO). Sistem učitava sve kandidate(SO). Sistem vraća sve kandidate(IA). Osnovni scenario sk: 1. Glasač bira kandidata za kojeg želi da glasa (APUSO) 2. Glasač poziva sistem da zapamti njegovo glasanje (APSO) 3. Sistem pamti glasanje(SO) 4. Sistem prikazuje poruku da li je glasanje bilo uspešno (IA) Alternativni scenario: 4.1. Ukoliko sistem ne uspe da sačuva glasanje, izveštava glasača o tome. (IA) Prekida se izvršenje scenarija.

15

10. Pregled izbornih rezultata Naziv sk: Pregled izbornih rezultata Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za prikaz izbornih rezultata. Zaposleni poziva sistem da učita sve izbore (APSO). Sistem učitava sve izbore(SO). Sistem vraća sve izbore(IA). Osnovni scenario sk: 1. Zaposleni bira izbor čije rezultate želi da pogleda (APUSO) 2. Zaposleni poziva sistem da prikaže rezultate izbora (APSO) 3. Sistem pronalazi rezultate izbora (SO) 4. Sistem prikazuje rezultate izbora (IA) Alternativni scenario: 4.1. Ukoliko sistem ne uspe da prikaže rezultate izbora, izveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

16

4. Analiza Faza analize opisuje logičku strukturu i ponašanje softverskog sistema, tj. poslovnu logiku softverskog sistema. Ponašanje opisujemo pomoću: o sistemskih dijagrama sekvenci, koji se prave za svaki prethodno utvrdjen SK; o ugovora o sistemskim operacijama, koje se dobijaju na osnovu sistemskih dijagrama sekvenci. Strukturu opisujemo pomoću: o konceptualnog modela i o relacionog modela.

4.1.Ponašanje softverskog sistema – sistemski dijagram sekvenci Za svaki SK, odnosno za svaki scenario SK, prave se sistemski dijagrami na kojima se vide akcije tipa: APSO (Aktor Poziva sistem da izvrši Sistemsku Operaciju) i IA (Izlazni argument).

17

Dijagram sekvenci 1. Unos novog kandidata Osnovni scenario: 1. Zaposleni poziva sistem da zapamti novog kandidata (APSO) 2. Sistem prikazuje poruku da je novi kandidat uspešno zapamćen (IA)

Slika 2. Dijagram sekvenci za slučaj korišćenja unos novog kandidata- osnovni scenario Alternativni scenario: 1.1.

Ukoliko sistem ne može da zapamti novog kandidata, prikazuje zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 3. Dijagram sekvenci za slučaj korišćenja unos novog kandidata- alternativni scenario Na osnovu ovog dijagrama sekvenci možemo uočiti jednu sistemsku operaciju koju treba projektovati: signal UnesiKandidata(Kandidat)

18

Dijagram sekvenci 2. Izmena kandidata Osnovni scenario: 1. Zaposleni poziva sistem da prikaže listu svih kandidata (APSO) 2. Sistem prikazuje listu svih kandidata (IA) 3. Zaposleni poziva sistem da mu prikaže podatke o odabranom kandidatu (APSO) 4. Sistem prikazuje podatke o odabranom kandidatu (IA) 5. Zaposleni poziva sistem da zapamti unete izmene (APSO) 6. Sistem prikazuje poruku da su podaci o kandidatu uspešno promenjeni (IA)

Slika 4. Dijagram sekvenci za slučaj korišćenja izmena kandidata- osnovni scenario

19

Alternativna scenarija: 2.1. Ukoliko sistem ne može da prikaže listu kandidata, prikazuje zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 5. Dijagram sekvenci za slučaj korišćenja izmena kandidata-prvi alternativni scenario 4.1. Ukoliko sistem ne uspe da prikaže podatke o kandidatu, obaveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 6. Dijagram sekvenci za slučaj korišćenja izmena kandidata- drugi alternativni scenario

20

6.1. Ukoliko sistem ne uspe da sačuva promene, izveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 7. Dijagram sekvenci za slučaj korišćenja izmena kandidata- treći alternativni scenario

Na osnovu ovih dijagrama sekvenci možemo uočiti tri sistemske operacije koje treba projektovati: signal PrikaziListuKandidata(List) signal PrikaziOdabranogKandidata(Kandidat) signal ZapamtiIzmeneKandidata(Kandidat)

21

Dijagram sekvenci 3. Brisanje kandidata Osnovni scenario: 1. Zaposleni poziva sistem da prikaže listu svih kandidata (APSO) 2. Sistem prikazuje listu svih kandidata (IA) 3. Zaposleni poziva sistem da obriše odabranog kandidata (APSO) 4. Sistem prikazuje poruku da je kandidat uspešno obrisan (IA)

Slika 8. Dijagram sekvenci za slučaj korišćenja brisanje kandidata- osnovni scenario

Alternativna scenarija: 2.1. Ukoliko sistem ne može da prikaže listu kandidata, prikazuje zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 9. Dijagram sekvenci za slučaj korišćenja brisanje kandidata- prvi alternativni scenario 22

4.1. Ukoliko sistem ne uspe da obriše odabranog kandidata, prikazuje poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 10. Dijagram sekvenci za slučaj korišćenja brisanje kandidata- drugi alternativni scenario

Na osnovu ovih dijagrama sekvenci možemo uočiti dve sistemske operacije koje treba projektovati: signal PrikaziListuKandidata(List) signal ObrisiOdabranogKandidata(Kandidat)

23

Dijagram sekvenci 4. Unos novog izbora Osnovni scenario: 1. Zaposleni poziva sistem da zapamti novi izbor (APSO) 2. Sistem prikazuje poruku da je novi izbor uspešno zapamćen (IA)

Slika 11. Dijagram sekvenci za slučaj korišćenja unos novog izbora- osnovni scenario Alternativni scenario: 2.1. Ukoliko sistem ne može da kreira novi izbor, prikazuje poruku zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 12. Dijagram sekvenci za slučaj korišćenja unos novog izbora- alternativni scenario

Na osnovu ovog dijagrama sekvenci možemo uočiti jednu sistemsku operaciju koju treba projektovati: signal UnesiIzbor(Izbor)

24

Dijagram sekvenci 5. Unos novog glasača Osnovni scenario: 1. Zaposleni poziva sistem da zapamti novog glasača (APSO) 2. Sistem prikazuje poruku da je novi glasač uspešno zapamćen (IA)

Slika 13. Dijagram sekvenci za slučaj korišćenja unos novog glasača- osnovni scenario Alternativni scenario: 2.1. Ukoliko sistem ne može da kreira novog glasača, prikazuje poruku zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 14. Dijagram sekvenci za slučaj korišćenja unos novog glasača- alternativni scenario

Na osnovu ovog dijagrama sekvenci možemo uočiti jednu sistemsku operaciju koju treba projektovati: signal UnesiGlasaca(Glasac)

25

Dijagram sekvenci 6. Izmena glasača Osnovni scenario: 1. Zaposleni poziva sistem da prikaže listu svih glasača (APSO) 2. Sistem prikazuje listu svih glasača (IA) 3. Zaposleni poziva sistem da mu prikaže podatke o odabranom glasaču (APSO) 4. Sistem prikazuje podatke o odabranom glasaču (IA) 5. Zaposleni poziva sistem da zapamti unete izmene (APSO) 6. Sistem prikazuje poruku da su podaci o glasaču uspešno promenjeni (IA)

Slika 15. Dijagram sekvenci za slučaj korišćenja izmena glasača- osnovni scenario

26

Alternativna scenarija: 2.1. Ukoliko sistem ne uspe da prikaže glasače, obaveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 16. Dijagram sekvenci za slučaj korišćenja izmena glasača- prvi alternativni scenario

1.1. Ukoliko sistem ne uspe da prikaže podatke o glasaču, obaveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 17. Dijagram sekvenci za slučaj korišćenja izmena glasača- drugi alternativni scenario 27

6.1. Ukoliko sistem ne uspe da sačuva promene, izveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 18. Dijagram sekvenci za slučaj korišćenja izmena glasača- treći alternativni scenario

Na osnovu ovih dijagrama sekvenci možemo uočiti tri sistemske operacije koje treba projektovati: signal PrikaziListuGlasaca(List) signal PrikaziOdabranogGlasaca(Glasac) signal ZapamtiIzmeneGlasaca(Glasac)

28

Dijagram sekvenci 7. Brisanje glasača Osnovni scenario: 1. Zaposleni poziva sistem da prikaže listu svih glasača (APSO) 2. Sistem prikazuje listu svih glasača (IA) 3. Zaposleni poziva sistem da obriše odabranog glasača (APSO) 4. Sistem prikazuje poruku da je glasač uspešno obrisan (IA)

Slika 19. Dijagram sekvenci za slučaj korišćenja brisanje glasača- osnovni scenario

29

Alternativna scenarija: 2.1. Ukoliko sistem ne uspe da prikaže glasače, obaveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 20. Dijagram sekvenci za slučaj korišćenja brisanje glasača- prvi alternativni scenario 4.1. Ukoliko sistem ne uspe da obriše odabranog glasača, prikazuje poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 21. Dijagram sekvenci za slučaj korišćenja brisanje glasača- drugi alternativni scenario

Na osnovu ovih dijagrama sekvenci možemo uočiti dve sistemske operacije koje treba projektovati: signal PrikaziListuGlasaca(List) signal ObrisiOdabranogGlasaca(Glasac) 30

Dijagram sekvenci 8. Prijavljivanje glasača na sistem Osnovni scenario: 1. Glasač poziva sistem da prikaže listu kandidata (APSO) 2. Sistem prikazuje listu kandidata (IA)

Slika 22. Dijagram sekvenci za slučaj korišćenja prijavljivanje na sistem- osnovni scenario Alternativni scenario: 2.1. Ukoliko glasač ne unese ispravne podatke, ne može da se uloguje i sistem neće prikazati odgovarajuću listu kandidata za glasanje. Sistem obaveštava glasača o tome. (IA) Prekida se izvršenje scenarija.

Slika 23. Dijagram sekvenci za slučaj korišćenja prijavljivanje na sistem- alternativni scenario

Na osnovu ovih dijagrama sekvenci možemo uočiti jednu sistemsku operaciju koje treba projektovati: signal PrikaziListuKandidata(Glasac, Izbor, List)

31

Dijagram sekvenci 9. Glasanje Osnovni scenario: 1. Glasač poziva sistem da zapamti njegovo glasanje (APSO) 2. Sistem prikazuje poruku da li je glasanje bilo uspešno (IA)

Slika 24. Dijagram sekvenci za slučaj korišćenja glasanje- osnovni scenario

Alternativni scenario: 2.1. Ukoliko sistem ne uspe da sačuva glasanje, izveštava glasača o tome. (IA) Prekida se izvršenje scenarija.

Slika 25. Dijagram sekvenci za slučaj korišćenja glasanje- alternativni scenario

Na osnovu ovih dijagrama sekvenci možemo uočiti jednu sistemsku operaciju koje treba projektovati: signal ZapamtiGlasanje(Glasac, Izbor, Kandidat)

32

Dijagram sekvenci 10. Prikaz rezultata glasanja Osnovni scenario: 1. Zaposleni poziva sistem da prikaže rezultate izbora (APSO) 2. Sistem prikazuje rezultate izbora (IA)

Slika 26. Dijagram sekvenci za slučaj korišćenja prikaz rezlutata izbora- osnovni scenario

Alternativna scenarija: 2.1. Ukoliko sistem ne uspe da prikaže rezultate izbora, izveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 27. Dijagram sekvenci za slučaj korišćenja prikaz rezlutata izbora- alternavni scenario

Na osnovu ovih dijagrama sekvenci možemo uočiti jednu sistemsku operaciju koje treba projektovati: signal PrikaziRezultateIzbora(Izbor)

33

Rezultat analize sistemskog dijagrama sekvenci Kao rezultat analize scenarija dobijeno je ukupno 19 sistemskih operacija koje treba projektovati. Za svaku od SO ulazni argument će biti istovremeno i izlazni argument. Svaka od SO shodno uspešnosti izvršenja vratiće odgovarajući signal. 1. signal UnesiKandidata(Kandidat); 2. signal PrikaziListuKandidata(List); 3. signal PrikaziOdabranogKandidata(Kandidat); 4. signal ZapamtiIzmeneKandidata(Kandidat); 5. signal ObrisiOdabranogKandidata(Kandidat); 6. signal UnesiIzbor(Izbor); 7. signal PrikaziListuIzbora(List); 8. signal UnesiGlasaca(Glasac); 9. signal PrikaziListuGlasaca(List); 10. signal PrikaziOdabranogGlasaca(Glasac); 11. signal ZapamtiIzmeneGlasaca(Glasac); 12. signal ObrisiOdabranogGlasaca(Glasac); 13. signal PrikaziListuKandidata(Glasac, IzborID, List); 14. signal ZapamtiGlasanje(GlasacID, IzborID, KandidatID); 15. signal PrikaziRezultateIzbora(Izbor); 16. signal PostaviKandidata(Izbor, Kandidat); 17. signal PrikaziGradove(List); 18. signal PrikaziTipoveIzbora(List<TipIzbora>).

34

4.2. Ponašanje softverskog sistema – Definisanje ugovora o sistemskim operacijama UGOVOR UG1: UnesiKandidata Operacija: UnesiKandidata(Kandidat): signal Veza sa SK: SK1 Preduslovi: Prosto vrednosno ograničenje nad objektom Kandidat mora biti zadovoljeno. Postuslovi: Unet je novi kandidat. UGOVOR UG2: PrikaziListuKandidata Operacija: PrikaziListuKandidata(List): signal Veza sa SK: SK2, SK3 Preduslovi: Postuslovi: UGOVOR UG3: PrikaziOdabranogKandidata Operacija: PrikaziOdabranogKandidata(Kandidat): signal Veza sa SK: SK2 Preduslovi: Postuslovi: UGOVOR UG4: ZapamtiIzmeneKandidata Operacija: ZapamtiIzmeneKandidata(Kandidat): signal Veza sa SK: SK2 Preduslovi: Prosto vrednosno ograničenje nad objektom Kandidat mora biti zadovoljeno. Postuslovi: Kandidat je izmenjen. UGOVOR UG5: ObrisiOdabranogKandidata Operacija: ObrisiOdabranogKandidata(Kandidat): signal Veza sa SK: SK3 Preduslovi: Postuslovi: Kandidat je obrisan. UGOVOR UG6: UnesiIzbor Operacija: UnesiIzbor(Izbor): signal Veza sa SK: SK4 Preduslovi: Prosto vrednosno ograničenje nad objektom Izbor mora biti zadovoljeno. Postuslovi: Unet je novi izbor. UGOVOR UG7: PrikaziListuIzbora Operacija: PrikaziListuIzbora (List): signal 35

Veza sa SK: SK4, SK8, SK10 Preduslovi: Postuslovi: UGOVOR UG8: UnesiGlasaca Operacija: UnesiGlasaca(Glasac): signal Veza sa SK: SK5 Preduslovi: Prosto vrednosno ograničenje nad objektom Glasac mora biti zadovoljeno. Postuslovi: Unet je novi glasač. UGOVOR UG9: PrikaziListuGlasaca Operacija: PrikaziListuGlasaca(List): signal Veza sa SK: SK6, SK7 Preduslovi: Postuslovi: UGOVOR UG10: PrikaziOdabranogGlasaca Operacija: PrikaziOdabranogGlasaca(Glasac): signal Veza sa SK: SK6 Preduslovi: Postuslovi: UGOVOR UG11: ZapamtiIzmeneGlasaca Operacija: ZapamtiIzmeneGlasaca(Glasac): signal Veza sa SK: SK6 Preduslovi: Prosto vrednosno ograničenje nad objektom Glasac mora biti zadovoljeno. Postuslovi: Glasač je izmenjen. UGOVOR UG12: ObrisiOdabranogGlasaca Operacija: ObrisiOdabranogGlasaca(Glasac): signal Veza sa SK: SK7 Preduslovi: Postuslovi: Glasač je obrisan. UGOVOR UG13: PostaviKandidata Operacija: PostaviKandidata(KandidatID, IzborID): signal Veza sa SK: SK4 Preduslovi: -. Postuslovi: Za dati izbor određen je kandidat. UGOVOR UG14: PrikaziListuKandidataZaGlasanje Operacija: PrikaziListuKandidata(GlasacID, IzborID, List): signal 36

Veza sa SK: SK8, SK9 Preduslovi: Postuslovi: UGOVOR UG15: ZapamtiGlasanje Operacija: ZapamtiGlasanje(GlasacID, IzborID, KandidatID): signal Veza sa SK: SK9 Preduslovi:Prosta vrednosna ograničenja nad objektima Kandidat, Glasac i Izbor moraju biti zadovoljena. Postuslovi: Glasanje je zapamćeno. UGOVOR UG16: PrikaziRezultateIzbora Operacija: PrikaziRezultateIzbora(NazivIzbora, Rezultat): signal Veza sa SK: SK10 Preduslovi: Postuslovi: UGOVOR UG17: PrikaziGradove Operacija: PrikaziGradove(List): signal Veza sa SK: SK1, SK2, SK3,SK5, SK6, SK7 Preduslovi: Postuslovi: UGOVOR UG18: PrikaziTipoveIzbora Operacija: PrikaziTipoveIzbora(List<TipIzbora>): signal Veza sa SK: SK4 Preduslovi: Postuslovi: -

37

4.3. Struktura softverskog sistema – Konceptualni (domenski) model Na osnovu slučajeva korišćenja i dijagrama sekvenci dolazimo do strukture softverskog sistema, koja je u ovoj fazi predstavljena konceptualnim (domenskim) modelom:

Slika 28. Konceptualni model

38

4.4. Struktura softverskog sistema – Relacioni model Na osnovu konceptualnog modela može se napraviti relacioni model, koji će predstavljati osnovu za projektovanje relacione baze podataka: TipIzbora (TipIzboraID, NazivTipa) Izbor (IzborID, Godina, TipIzboraID) Grad (GradID, Naziv, PostanskiBroj) Kandidat (KandidatID, ImePrezime, Stranka, GradID) KandidatIzbor (KandidatID, IzborID) Glasac(GlasacID, ImePrezime, Jmbg, UlicaBroj, GradID) Glasanje(GlasacID, IzborID, KandidatID, VremeGlasanja) Tabela TipIzbora Atributi Ime

Prosto ograničenje Tip atributa

TipIzboraID String NazivTipa String

vrednosno Složeno vrednosno ograničenje

Strukturno ograničenje Vrednost Međuzavisnost Međuzavisnost INSERT / atributa atributa jedne atributa više UPDATE CASCADES tabele tabela Izbor Not null DELETE RESTRICTED Izbor Tabela 1. TipIzbora

Tabela Izbor

Prosto vrednosno Složeno vrednosno ograničenje ograničenje Atributi Ime Tip Vrednost Međuzavisnost Međuzavisnost atributa atributa atributa jedne atributa više tabele tabela IzborID String Not null Godina String TipIzboraID String

Strukturno ograničenje INSERT / UPDATE CASCADES KandidatIzbor, Glasanje DELETE RESTRICTED KandidatIzbor, Glasanje

Tabela 2. Izbor

39

Tabela Grad

Prosto vrednosno Složeno vrednosno ograničenje ograničenje Atributi Ime Tip Vrednost Međuzavisnost Međuzavisnost atributa atributa atributa jedne atributa više tabele tabela GradID String Not null Naziv String PostanskiBroj String

Strukturno ograničenje INSERT / UPDATE CASCADES Kandidat, Glasac DELETE RESTRICTED Kandidat, Glasac

Tabela 3. Grad Tabela Kandidat

Prosto vrednosno Složeno vrednosno ograničenje ograničenje Atributi Ime Tip Vrednost Međuzavisnost Međuzavisnost atributa atributa atributa jedne atributa više tabele tabela KandidatID String Not null ImePrezime String Stranka String GradID String

Strukturno ograničenje INSERT / UPDATE CASCADES Glasanje, KandidatIzbor DELETE RESTRICTED Glasanje, KandidatIzbor

Tabela 4. Kandidat Tabela KandidatIzbor Atributi Ime

Prosto ograničenje Tip atributa

KandidatID String IzborID String

vrednosno Složeno vrednosno ograničenje

Strukturno ograničenje Vrednost Međuzavisnost Međuzavisnost INSERT atributa atributa jedne atributa više RESTRICTED Kandidat, tabele tabela Izbor Not null UPDATE Not null RESTRICTED Kandidat, Izbor Tabela 5. KandidatIzbor

40

Tabela Glasac Atributi Ime

GlasacID ImePrezime Jmbg UlicaBroj GradID

Prosto ograničenje Tip atributa

String String Char String String

vrednosno Složeno vrednosno ograničenje Vrednost atributa Not null

Strukturno ograničenje Međuzavisnost Međuzavisnost INSERT / atributa jedne atributa više UPDATE CASCADES tabele tabela Glasanje DELETE CASCADE Glasanje

Tabela 6. Glasač Tabela Glasanje

Prosto vrednosno Složeno vrednosno ograničenje ograničenje Atributi Ime Tip Vrednost Međuzavisnost Međuzavisnost atributa atributa atributa jedne atributa više tabele tabela GlasacID String Not null IzborID String Not null KandidatID String Not null VremeGlasanja DateTime

Strukturno ograničenje INSERT RESTRICTED Glasac, Izbor, Kandidat UPDATE RESTRICTED Glasac, Izbor, Kandidat

Tabela 7. Glasanje

41

Rezultat faze analize Kao rezultat analize scenarija SK i pravljenja konceptualnog modela dobija se logička struktura i ponašanje softverskog sistema.

Slika 29. Logička struktura i ponašanje softverskog sistema 42

5. Projektovanje Faza projektovanja opisuje fizičku strukturu i ponašanje softverskog sistema (arhitekturu softverskog sistema). Projektovanje arhitekture softverskog sistema obuhvata projektovanje korisničkog intefejsa, aplikacione logike i skladišta podataka. Projektovanje korisničkog interfejsa obuhvata projektovanje ekranskih formi i kontrolera korisničkog interfejsa. U okviru aplikacione logike se projektuju kontroler aplikacione logike, poslovna logika i broker baze podataka. Projektovanje poslovne logike obuhvata projektovanje logičke strukture i ponašanja softverskog sistema.

5.1. Arhitektura softverskog sistema Arhitektura softverskog sistema izvedena je iz tronivoske arhitekture, sastavljene od sledećih nivoa: • korisnički interfejs • aplikaciona logika • skladište podataka

Slika 30. Tronivojska arhitektura

43

Slika 31. Arhitektura softverskog sistema – Aplikaciona logika Kontroler prihvata zahtev za izvršenje sistemske operacije od klijenta i prosleđuje ga do poslovne logike koja je odgovorna za izvršenje sistemske operacije. Poslovna logika opisana je strukturom (domenskim klasama) i ponašanjem (sistemskim operacijama). Broker baze podataka je odgovoran za komunikaciju između poslovne logike i skladišta podataka.

Slika 32. Arhitektura softverskog sistema – Poslovna logika 44

5.2. Projektovanje korisničkog interfejsa Korisnički interfejs predstavlja realizaciju ulaza i/ili izlaza softverskog sistema. Korisnički interfejs čine ekranska forma i kontroler korisničkog interfejsa. Ekranska forma prihvata podatke i događaje od aktora, prosleđuje kontroleru te podatke i prihvata podatke od kontrolera i prikazuje ih na ekranskoj formi. Kontroler korisničkog interfejsa prihvata podatke od ekranske forme, konvertuje ih u objekat tj u ulazni arguments za SO, šalje zahtev za izvršenje SO do aplikacionog servera, prihvata objekat (izlaz) softverskog sistema koji nastaje kao rezultat izvršenja SO i konvertuje objekat u podatke za prikaz na grafičkom interfejsu.

5.2.1. Projektovanje ekranske forme Pre prikazivanja ekranske forme potrebno je napraviti odabir moda- mod za glasanje ili mod za administraciju.

Slika 33. Odabir moda za rad Nakon odabira moda za administraciju ekranska forma izgleda kao na slici 34.

Slika 34. Mod za administraciju

45

A nakon odabira moda za glasanje ekranska forma izgleda kao na slici 35.

Slika 35. Mod za glasanje

46

Projektovanje scenarija SK 1. Unos novog kandidata Naziv sk: Unos novog kandidata Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa kandidatima. Zaposleni poziva sistem da učita sve gradove (APSO). Sistem učitava sve gradove(SO). Sistem vraća sve gradove(IA).

Slika 36. Izgled forme za unos novog kandidata Osnovni scenario sk: 1. Zaposleni unosi podatke o novom kandidatu (APUSO) 2. Zaposleni kontroliše da li je uneo sve podatke o novom kandidatu (ANSO)

47

Slika 37. Unos podataka o kandidatu 3.

4. 5.

Zaposleni poziva sistem da zapamti novog kandidata (APSO) Opis akcije: Zaposleni klikom na dugme “Sacuvaj” poziva sistemsku operaciju UnesiKandidata (Kandidat) koja pravi novog kandidata. Sistem pamti novog kandidata (SO) Sistem prikazuje poruku da je novi kandidat uspešno zapamćen (IA)

48

Slika 38. Prikaz poruke sistema da je sačuvan novi kandidat Alternativni scenario: 5.1. Ukoliko sistem ne može da zapamti novog kandidata, prikazuje zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 39. Prikaz poruke sistema da kandidat nije sačuvan 49

2. Izmena kandidata Naziv sk: Izmena kandidata Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa kandidatima. Zaposleni poziva sistem da učita sve gradove (APSO). Sistem učitava sve gradove(SO). Sistem vraća sve gradove(IA).

Slika 40. Izgled forme za izmenu kandidata

Osnovni scenario sk: 1.

2. 3.

Zaposleni poziva sistem da prikaže listu svih kandidata (APSO) Opis akcije: Zaposleni klikom na opciju glavnog menija “Izmena kandidata” poziva sistemsku operaciju PrikaziListuKandidata(). Sistem vraća listu svih kandidata (SO) Sistem prikazuje listu svih kandidata (IA)

50

Slika 41. Izgled forme za izmenu kandidata sa prikazanom listom svih kandidata 4. 5.

6. 7.

Zaposleni bira kandidata kojeg želi da izmeni (APUSO) Zaposleni poziva sistem da mu prikaže podatke o odabranom kandidatu (APSO) Opis akcije: Zaposleni klikom na dugme “Izmeni” poziva sistemsku PrikaziOdabranogKandidata(Kandidat). Sistem pronalazi podatke o odabranom kandidatu (SO) Sistem prikazuje podatke o odabranom kandidatu (IA)

operaciju

Slika 42. Prikaz i izmena podataka odabranog kandidata 51

8. 9.

10. 11.

Zaposleni vrši izmenu podataka o kandidatu (APUSO) Zaposleni poziva sistem da zapamti unete izmene (APSO) Opis akcije: Zaposleni klikom na dugme “Sacuvaj izmene” poziva sistemsku operaciju ZapamtiIzmeneKandidata(Kandidat) koja čuva izvršene izmene podataka o kandidatu. Sistem pamti izmene o kandidatu (SO) Sistem prikazuje poruku da su podaci o kandidatu uspešno promenjeni (IA)

Slika 43. Prikaz poruke sistema o uspešnoj izmeni kandidata Alternativni scenario: 4.1. Ukoliko sistem ne može da prikaže listu kandidata, prikazuje zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 44. Prikaz poruke sistema da nije uspeo da vrati listu kandidata 7.1. Ukoliko sistem ne uspe da prikaže podatke o kandidatu, obaveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 45. Prikaz poruke sistema da nije uspeo da prikaže podatke o kandidatu 52

11.1. Ukoliko sistem ne uspe da sačuva promene, izveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 46. Prikaz poruke sistema da nije uspeo da izmeni kandidata

53

3. Brisanje kandidata Naziv sk: Brisanje kandidata Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa kandidatima. Zaposleni poziva sistem da učita sve gradove (APSO). Sistem učitava sve gradove(SO). Sistem vraća sve gradove(IA).

Slika 47. Izgled forme za brisanje kandidata Osnovni scenario sk: 1.

2. 3.

Zaposleni poziva sistem da prikaže listu svih kandidata (APSO) Opis akcije: Zaposleni klikom na opciju glavnog menija “Brisanje kandidata” poziva sistemsku operaciju PrikaziListuKandidata(). Sistem vraća listu svih kandidata (SO) Sistem prikazuje listu svih kandidata (IA)

Slika 48. Prikaz liste svih kandidata

54

4. 5.

6. 7.

Zaposleni iz liste kandidata bira kandidata kojeg želi da obriše (APUSO) Zaposleni poziva sistem da obriše odabranog kandidata (APSO) Opis akcije: Zaposleni klikom na dugme “Obrisi” poziva sistemsku ObrisiOdabranogKandidata(Kandidat) koja briše kandidata. Sistem briše odabranog kandidata (SO) Sistem prikazuje poruku da je kandidat uspešno obrisan (IA)

operaciju

Slika 49. Prikaz poruke sistema da je kandidat uspešno obrisan

Alternativni scenario: 4.1. Ukoliko sistem ne može da prikaže listu kandidata, prikazuje zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 50. Prikaz poruke sistema da nije uspeo da vrati listu kandidata 8.1. Ukoliko sistem ne uspe da obriše odabranog kandidata, prikazuje poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 51. Prikaz poruke sistema o neuspešnom brisanju kandidata 55

3. Unos novog izbora Naziv sk: Unos novog izbora Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa izborima. Zaposleni poziva sistem da učita sve tipove izbora (APSO). Sistem učitava sve tipove izbora(SO). Sistem vraća sve tipove izbora(IA). Zaposleni poziva sistem da učita sve kandidate (APSO). Sistem učitava sve kandidate(SO). Sistem vraća sve kandidate(IA).

Slika 52. Izgled forme za unos izbora Osnovni scenario sk: 1. Zaposleni unosi podatke o novom izboru (APUSO) 2. Zaposleni kontroliše da li je uneo sve podatke o novom izboru (ANSO) 3. Zaposleni poziva sistem da zapamti novi izbor (APSO) Opis akcije: Zaposleni klikom na dugme “Sacuvaj” poziva sistemsku operaciju UnesiIzbor (Izbor) koja pravi novi izbor. 4. Sistem pamti novi izbor (SO) 5. Sistem prikazuje poruku da je novi izbor uspešno zapamćen (IA)

56

Slika 53. Poruka sistema da je izbor uspešno sačuvan

Alternativni scenario: 5.1. Ukoliko sistem ne može da zapamti novi izbor, prikazuje poruku zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 54. Poruka sistema da izbor nije uspešno sačuvan

57

4. Unos novog glasača Naziv sk: Unos novog glasača Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa glasačima. Zaposleni poziva sistem da učita sve gradove (APSO). Sistem učitava sve gradove(SO). Sistem vraća sve gradove(IA).

Slika 55. Izgled forme za unos glasača Osnovni scenario sk: 1. Zaposleni unosi podatke o novom glasaču (APUSO) 2. Zaposleni kontroliše da li je uneo sve podatke o novom glasaču (ANSO) 3. Zaposleni poziva sistem da zapamti novog glasača (APSO) Opis akcije: Zaposleni klikom na dugme “Sacuvaj” poziva sistemsku operaciju UnesiGlasaca (Glasac) koja pravi novog glasača. 4. Sistem pamti novog glasača (SO) 5. Sistem prikazuje poruku da je novi glasač uspešno zapamćen (IA)

58

Slika 56. Poruka sistema da je glasač uspešno sačuvan Alternativni scenario: 5.1. Ukoliko sistem ne može da zapamti novog glasača, prikazuje poruku zaposlenom poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 57. Poruka sistema da je čuvanje glasača neuspešno

59

6. Izmena glasača Naziv sk: Izmena glasača Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa glasačima. Zaposleni poziva sistem da učita sve gradove (APSO). Sistem učitava sve gradove(SO). Sistem vraća sve gradove(IA).

Slika 58. Izgled forme za izmenu glasača Osnovni scenario sk: 1. Zaposleni poziva sistem da prikaže listu svih glasača (APSO) Opis akcije: Zaposleni klikom na opciju glavnog menija “Izmena glasaca” poziva sistemsku operaciju PrikaziListuGlasaca(). 2. Sistem vraća listu svih glasača (SO) 3. Sistem prikazuje listu svih glasača (IA)

60

Slika 59. Prikaz liste svih glasača 4. Zaposleni iz liste kandidata bira glasača kojeg želi da izmeni (APUSO) 5. Zaposleni poziva sistem da mu prikaže podatke o odabranom glasaču (APSO) Opis akcije: Zaposleni klikom na dugme “Izmeni” poziva sistemsku PrikaziOdredjenogGlasaca (Glasac). 6. Sistem vraća podatke o selektovanom glasaču (SO) 7. Sistem prikazuje podatke o selektovanom glasaču (IA)

operaciju

Slika 60. Prikaz podataka o odabranom glasaču 61

8. Zaposleni vrši izmenu podataka o glasaču (APUSO) 9. Zaposleni poziva sistem da zapamti unete izmene (APSO) Opis akcije: Zaposleni klikom na dugme “Sacuvaj izmene” poziva sistemsku operaciju ZapamtiIzmeneKandidata(Kandidat) koja čuva izvršene izmene podataka o kandidatu. 10. Sistem pamti izmene o glasaču (SO) 11. Sistem prikazuje poruku da su podaci o glasaču uspešno promenjeni (IA)

Slika 61. Prikaz poruke sistema o uspešnoj izmeni glasača Alternativni scenario: 3.1. Ukoliko sistem ne uspe da prikaže glasače, obaveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 62. Prikaz poruke sistema da nije uspeo da vrati listu glasača 7.1. Ukoliko sistem ne uspe da prikaže podatke o glasaču, obaveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

62

Slika 63. Prikaz poruke sistema da nije uspeo da prikaže podatke o glasaču 11.1. Ukoliko sistem ne uspe da sačuva promene, izveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 64. Prikaz poruke sistema da nije uspeo da sačuva glasača

63

7. Brisanje glasača Naziv sk: Brisanje glasača Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za rad sa glasačima. Zaposleni poziva sistem da učita sve gradove (APSO). Sistem učitava sve gradove(SO). Sistem vraća sve gradove(IA).

Slika 65. Izgled forme za brisanje glasača Osnovni scenario sk: 1. Zaposleni poziva sistem da prikaže listu svih glasača (APSO) Opis akcije: Zaposleni odabirom opcije na meniju “Brisanje glasaca” poziva sistemsku operaciju PrikazuListuGlasaca(). 2. Sistem vraća listu svih glasača (SO) 3. Sistem prikazuje listu svih glasača (IA)

Slika 66. Prikaz svih glasača na formi za brisanje glasača 4. Zaposleni iz liste kandidata bira glasača kojeg želi da obriše (APUSO) 5. Zaposleni poziva sistem da obriše odabranog glasača (APSO) 64

Opis akcije: Zaposleni klikom na dugme “Obrisi” poziva sistemsku ObrisiOdabranogGlasaca(Glasac) koja čuva izvršene izmene podataka o kandidatu. 6. Sistem briše odabranog glasača (SO) 7. Sistem prikazuje poruku da je glasač uspešno obrisan (IA)

operaciju

Slika 67. Prikaz poruke sistema da je glasač uspešno obrisan Alternativni scenario: 3.1. Ukoliko sistem ne uspe da prikaže glasače, obaveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 68. Prikaz poruke sistema da nije uspeo da vrati listu glasača 7.1.

Ukoliko sistem ne uspe da obriše odabranog glasača, prikazuje poruku o tome. (IA) Prekida se izvršenje scenarija.

Slika 69. Prikaz poruke sistema da nije uspeo da obriše glasača

65

8. Prijavljivanje glasača na sistem Naziv sk: Prijavljivanje glasača na sistem Akteri sk: Glasač Učesnici sk: Glasač i sistem Preduslov: Sistem je uključen. Prikazana je forma za glasanje. Zaposleni poziva sistem da učita sve izbore (APSO). Sistem učitava sve izbore(SO). Sistem vraća sve izbore(IA).

Slika 70. Izgled forme za prijavljivanje glasača na sistem Osnovni scenario sk: 1. Glasač unosi svoje podatke potrebne za glasanje (APUSO) 2. Glasač poziva sistem da prijavi na sistem za glasanje (APSO) Opis akcije: Glasač klikom na dugme “Log in” poziva sistemsku operaciju PrikaziListuKandidata(Glasac,Izbor) koja prijavljuje glasača na sistem i prikazuje listu kandidata za taj izbor za koji se glasač prijavio. 3. Sistem proverava unete podatke (SO) 4. Sistem prikazuje poruku o uspesnom prijavljivanju na sistem (IA)

66

Slika 71. Prikaz poruke sistema o uspešnoj prijavi na sistem Alternativni scenario: 4.1. Ukoliko glasač ne unese ispravne podatke, ne može da se prijavi na sistem i sistem obaveštava glasača o tome. (IA) Prekida se izvršenje scenarija.

Slika 72. Prikaz poruke sistema o neuspešnom prijavljivanju na sistem

67

9. Glasanje Naziv sk: Glasanje Akteri sk: Glasač Učesnici sk: Glasač i sistem Preduslov: Sistem je uključen. Prikazana je forma za glasanje. Glasač je prijavljen na sistem. Zaposleni poziva sistem da učita sve kandidate (APSO). Sistem učitava sve kandidate(SO). Sistem vraća sve kandidate(IA).

Slika 73. Izgled forme za glasanje Osnovni scenario sk: 1. Glasač bira kandidata za kojeg želi da glasa (APUSO) 2. Glasač poziva sistem da zapamti njegovo glasanje (APSO) Opis akcije: Glasač klikom na dugme “Glasaj” poziva sistemsku operaciju ZapamtiGlasanje(GlasacID, IzborID,KandidatID) koja čuva izvršene izmene podataka o kandidatu. 3. Sistem pamti glasanje(SO) 4. Sistem prikazuje poruku da li je glasanje bilo uspešno (IA)

68

Slika 74. Prikaz poruke sistema o uspešnom glasanju Alternativni scenario: 4.1. Ukoliko sistem ne uspe da sačuva glasanje, izveštava glasača o tome. (IA) Prekida se izvršenje scenarija.

Slika 75. Prikaz poruke o neuspešnom glasanju

69

10. Pregled izbornih rezultata Naziv sk: Pregled izbornih rezultata Akteri sk: Zaposleni Učesnici sk: Zaposleni i sistem Preduslov: Sistem je uključen. Prikazana je forma za prikaz izbornih rezultata. Zaposleni poziva sistem da učita sve izbore (APSO). Sistem učitava sve izbore(SO). Sistem vraća sve izbore(IA).

Slika 76. Izgled forme za prikaz rezultata Osnovni scenario sk: 1. Zaposleni bira izbor čije rezultate želi da pogleda (APUSO) 2. Zaposleni poziva sistem da prikaže rezultate izbora (APSO) Opis akcije: Zaposleni klikom na opciju iz padajućeg menija sa nazivom izbora poziva sistemsku operaciju PrikaziRezultateIzbora(Izbor). 3. Sistem pronalazi rezultate izbora (SO) 4. Sistem prikazuje rezultate izbora (IA)

Slika 77. Prikaz rezultata izbora

70

Alternativni scenario: 4.1. Ukoliko sistem ne uspe da prikaže rezultate izbora, izveštava zaposlenog o tome. (IA) Prekida se izvršenje scenarija.

Slika 78. Prikaz poruke sistema da nije uspeo da vrati rezultate izbora

71

5.3. Projektovanje aplikacione logike 5.3.1. Kontroler aplikacione logike Kontroler aplikacione logike zadužen je za pokretanje severskog soketa. Serverski soket će osluškivati mrežu i generisaće niti za komunikaciju sa klijentom u onom trenutku kada klijentski soket uspostavi vezu sa serverskim soketom. Klijent šalje zahtev za izvršenje neke od sistemskih operacija preko soketa do odgovarajuće niti (NitObradaKlijenta), koja prima i obrađuje zahtev, odnosno prosleđuje ga dalje do klasa koje su odgovorne za izvršenje SO. Kada se sistemska operacija izvrši, rezultat se vraća do aplikacione logike koja taj rezultat šalje dalje, preko soketa, do klijenta.

5.3.2. Projektovanje ponašanja softverskog sistema – sistemske operacije Projektovanje sistemskih operacija odnosno klasa koje su odgovorne za izvršenje sistemskih operacija se vrši na sledeći način: prvo projektujemo svaku od SO a zatim jednu opštu klasu OpstaSO u kojoj ćemo imati metodu izvrsiSO(). U okviru te metode se definiše algoritam kako se koja operacija izvršava. Pre i posle svake SO otvara se transakcija, proverava preduslov, izvršava konkretna SO i poziva Commit ili Rollback u zavisnosti od toga da li je SO uspešno izvršena ili ne. Nakon toga, konekcija se zatvara. Svaka od SO treba da nasledi klasu OpstaSO. Za svaki od ugovora projektuje se konceptualno rešenje. UGOVOR UG1: UnesiKandidata Operacija: UnesiKandidata(Kandidat): signal Veza sa SK: SK1 Preduslovi: Prosto vrednosno ograničenje nad objektom Kandidat mora biti zadovoljeno. Postuslovi: Unet je novi kandidat.

Slika 79. Dijagram sekvenci za SO UnesiKandidata UGOVOR UG2: PrikaziListuKandidata Operacija: PrikaziListuKandidata(List): signal Veza sa SK: SK2, SK3 Preduslovi: 72

Postuslovi: -

Slika 80. Dijagram sekvenci za SO PrikaziListuKandidata UGOVOR UG3: ZapamtiIzmeneKandidata Operacija: ZapamtiIzmeneKandidata(Kandidat): signal Veza sa SK: SK2 Preduslovi: Prosto vrednosno ograničenje nad objektom Kandidat mora biti zadovoljeno. Postuslovi: Kandidat je izmenjen.

Slika 81. Dijagram sekvenci za SO ZapamtiIzmeneKandidata UGOVOR UG4: ObrisiOdabranogKandidata Operacija: ObrisiOdabranogKandidata(Kandidat): signal Veza sa SK: SK3 Preduslovi: Postuslovi: Kandidat je obrisan.

Slika 82. Dijagram sekvenci za SO ObrisiOdabranogKandidata 73

Preko klase KontrolerAL prihvata se zahtev od klijenta za izvršenje sistemskih operacija (SO) i isti se prosleđuje do odgovarajućih klasa koje su odgovorne za izvršenje SO. Za svaku SO postoji softverska klasa koja treba da realizuje tu SO, a svaka od tih klasa nasleđuje klasu OpstaSO. Ove klase nazivaju se softverske klase ponašanja a odnos između tih klasa i kontrolera aplikacione logike prikazan je niže na slici 83.

Slika 83. Klase koje su odgovorne za SO nasleđuju klasu OpstaSO

74

5.3.3. Projektovanje strukture softverskog sistema Na osnovu konceptualnih klasa prave se softverske klase strukture. Klase strukture prikazane su niže na slici 84.

Slika 84. Softverske klase strukture Klase strukture (domenske klase) implementiraju interfejs DomenskiObjekat, što je prikazano na slici 85.

Slika 85. Domenske klase i domenski objekat 75

5.3.4. Projektovanje aplikacione logike – DatabaseBroker Klasa DatabaseBroker se projektuje kako bi se obezbedio perzistentni servis objektima domenskih klasa koji se čuvaju u bazi podataka. Tako klasa DatabaseBroker predstavlja perzistentni okvir koji posreduje u svim operacijama nad bazom podataka. Metode DatabaseBrokera su projektovane kao generičke, što znači da mogu da prihvate različite domenske objekte preko parametara.

Slika 86. Odnos DBBrokera i domenskih klasa

76

5.4. Projektovanje skladišta podataka Na osnovu softverskih klasa strukture projektovane su tabele (skladišta podataka) relacionog sistema za upravljanje bazom podataka (MS Access): TableName: Kandidat Name KandidatID (kljuc) ImePrezime Stranka GradID TableName: Grad Name GradID (kljuc) Naziv PttBroj TableName: TipIzbora Name TipIzboraID (kljuc) NazivTipaIzbora TableName: Izbor Name IzborID Godina TipIzboraID

Type Size Number 10 Text 20 Text 20 Number 10 Tabela 8.Tabela Kandidat relacionog sistema Type Size Number 10 Text 20 Number 5 Tabela 9.Tabela Grad relacionog sistema Type Size Number 10 Text 20 Tabela 10. Tabela TipIzbora relacionog sistema Type Size Number 10 Text 20 Number 10 Tabela 11.Tabela Izbor relacionog sistema

TableName: KandidatIzbor Name Type Size KandidatID Number 10 IzborID Number 10 Tabela 12. Tabela KandidatIzbor relacionog sistema TableName: Glasac Name Type Size GlasacID Number 10 ImePrezime Text 20 Jmbg Number 13 UlicaBroj Text 20 GradID Number 10 Tabela 13. Tabela Glasač relacionog sistema

77

TableName: Glasanje Name GlasacID IzborID KandidatID

Type Size Number 10 Number 10 Number 10 Tabela 14. Tabela Glasanje relacionog sistema

Nakon projektovanja tabela baze podataka dobijamo celokupnu arhitekturu softverskog sistema prikazanu niže na slici 87.

Slika 87. Arhitektura softverskog sistema

78

5.5. Principi, metode i strategije projektovanja softvera 5.5.1. Principi (tehnike) projektovanja softvera Apstrakcija je proces svesnog izdvajaja opštih od specifičnih informacija tako da stvari koje su različite mogu biti tretirane kao da su iste. Mehanizmi apstrakcije U kontekstu softverskog projektovanja postoje dva ključna mehanizma apstrakcije: • •

Parametrizacija i Specifikacija

Apstrakcija specifikacijom vodi do 3 glavne vrste apstrakcija: • • •

Proceduralna apstrakcija Apstrakcija podataka Apstrakcija kontrolom

Parametrizacija Parametrizacija je apstrakcija koja izdvaja iz nekog skupa elemenata njihova opšta svojstva koja su predstavljena preko parametara. Razlikujemo pet slučaja parametrizacije: • • • • •

Parametrizacija skupa elemenata prostog tipa Parametrizacija skupa elemenata složenog tipa Parametrizacija skupa operacija Parametrizacija skupa procedura Parametrizacija skupa naredbi

Parametrizacija skupa elemenata prostog tipa Ako posmatramo skup celih brojeva 1,2,3… oni se mogu predstaviti npr. preko parametra x koji je u tom slučaju opšti predstavnik svih celih brojeva. Programerski bismo to zapisali kao: Int x To znači da je deklarisana promenljiva x koja je celobrojnog tipa. Deklarisanjem promenljive prostog tipa implicitno se ukazuje na skup operacija koje se mogu izvršiti nad tom promenljivom. Parametrizacija skupa elemenata složenog tipa Ukoliko posmatramo skup glasača (gl1, gl2,gl3) iz ovog studijskog primera: 79

((3011989738537, Jelena Đurđević, Kuršumlija), (1209989853745, Jasmina Gavrilović, Požega), (1809989654782, Jelena Haži-Stančić, Požarevac)) tada parametrizacijom dobijamo opšta svojstva (atribute) glasača : Matični broj, Ime i prezime i Grad. Parametrizacija se radi za svaki skup vrednosti atributa. Skup matičnih brojeva glasača (3011989738537, 1209989853745, 1809989654782) parametrizuje se preko svojstva Matični broj; skup imena i prezimena glasača (Jelena Đurđević, Jasmina Gavrilović, Jelena Hadži-Stančić) preko svojstva Ime i prezime, a skup gradova iz kojih su glasači (Kuršumlija, Požega, Požarevac) parametrizuje se preko svojstva Grad.

Parametrizacijom dolazimo do opštih svojstava elemenata skupa. Navođenje opštih svojstava elemenata skupa predstavlja specifikaciju skupa. Apstrakcija podataka je definisana imenom i specifikacijom skupa: Glasač (Matični broj, Ime i prezime, Grad). Kao što se može primetiti, parametrizacija prethodi specifikaciji, jer specifikacija koristi rezultate parametrizacije. Parametrizacija skupa operacija Ukoliko imamo skup nekih operacija ((5+2), (7+1),(3+8)) tada se parametrizacijom dobija opšta operacija x+y. Elementi neke operacije su operandi x i y (nad kojima se izvodi operacija) i operator + , koji ukazuje na to šta operacija radi.

80

Kao rezultat parametrizacije dobija se x+y, opšta operacija za sabiranje dva broja. Parametrizacija skupa procedura Ukoliko posmatramo skup procedura (pr1, pr2, pr3): 1. List vratiListuObjekata (ResultSet rs){metoda koja vraća listu glasača iz resultset-a} 2. List vratiListuObjekata (ResultSet rs){metoda koja vraća listu kandidata iz resultset-a} 3. List vratiListuObjekata (ResultSet rs){metoda koja vraća listu gradova iz resultset-a} Tada se parametrizacijom dobija opšta procedura: List vratiListuObjekata(ResultSet rs). Elementi neke procedure su: šta procedura vraća, naziv procedure, argumenti (parametri) procedure i telo procedure.

Kao rezultat parametrizacije dobija se: List vratiListuObjekata (ResultSet rs)

81

Parametrizacijom dolazimo do opštih svojstava procedura njihovim navođenjem dolazimo do potpisa procedura. Potpis procedure je jedan od glavnih delova specifikacije procedure (proceduralna apstrakcija). Parametrizacija skupa naredbi Ukoliko posmatramo skup naredbi: System.out.println (“Glasac : ”+ glasaci[0].getImePrezime()+”sa maticnim brojem ” + glasaci[0].getJmbg) System.out.println (“Glasac : ”+ glasaci[1].getImePrezime()+”sa maticnim brojem ” + glasaci[1].getJmbg) System.out.println (“Glasac : ”+ glasaci[2].getImePrezime()+”sa maticnim brojem ” + glasaci[2].getJmbg) Koje prikazuju elemente liste glasaci, tada se parametrizacijom dobija opšta naredba: System.out.println (“Glasac glasaci[i].getJmbg)

:

”+

glasaci[i].getImePrezime()+”sa

maticnim

brojem

”

+

”

+

Kao rezultat parametrizacije dobija se: for(int i=0;i
:

”+

glasaci[i].getImePrezime()+”sa

maticnim

brojem

Parametrizacijom dolazimo do opštih svojstava naredbi. Navođenjem opštih svojstava naredbi dolazi se do specifikacije naredbe koja postaje opšta naredba. Navedena specifikacija je u stvari apstrakcija naredbi, jedan od oblika apstrakcije kontrolom. Specifikacija Specifikacija je apstrakcija koja izdvaja iz nekog skupa elemenata njihova opšta svojstva koja mogu biti predstavljena preko procedure, podatka ili kontrole. Proceduralna apstrakcija 82

Proceduralnom apstrakcijom se izdvaja iz nekog skupa procedura ono što su njihova opšta svojstva: • • •

Tip onoga što vraća procedura Ime procedure Argumenti procedure

Proceduralnom apstrakcijom se dobija potpis procedure. Pored potpisa, proceduralna apstrakcija obuhvata i dopunske sekcije koje detaljno opisuju šta radi procedura i koji su uslovi izvršenja procedure. Opšti slučaj proceduralne apstrakcije prema uprošćenoj Larmanovoj metodi, ima sledeće elemente: Potpis procedure, Veza sa SK, Preduslovi i postuslovi. Kao primer opšteg slučaja proceduralne apstrakcije možemo navesti ugovor o sistemskoj operaciji unesiGlasaca Potpis procedure: unesiGlasaca(Glasac): signal Veza sa SK: SK1 Preduslovi: Prosto vrednosno ograničenje nad objektom Glasac mora biti zadovoljeno. Postuslovi: Unet je novi glasac.

83

Apstrakcija podataka Apstrakcijom podataka se izdvaja iz nekog skupa podataka ono što su njihova opšta svojstva. Na prethodnom primeru pokazano je da ukoliko posmatramo skup glasača (gl1, gl2,gl3) iz ovog studijskog primera: ((3011989738537, Jelena Đurđević, Kuršumlija), (1209989853745, Jasmina Gavrilović, Požega), (1809989654782, Jelena Haži-Stančić, Požarevac)) tada parametrizacijom dobijamo opšta svojstva (atribute) glasača : Matični broj, Ime i prezime i Grad. Navođenje opštih svojstava elemenata skupa (Matični broj, Ime i prezime i Grad) predstavlja specifikaciju skupa. Apstrakcija podataka je definisana imenom (Glasač) skupa i specifikacijom skupa. Ukoliko elementi, kao u ovom slučaju, imaju i strukturu i ponašanje (objekti) tada se nad njima radi i proceduralna apstrakcija i apstrakcija podataka. Kao rezultat navedenih apstrakcija dobija se klasa, koja se sastoji od atributa i procedura (metoda), koji su učaureni u klasi. Apstrakcija kontrolom Postoje dva oblika apstrakcije kontrole: • •

Apstrakcija naredbi, kojom se izdvaja iz nekog skupa naredbi ono što su njihova opšta svojstva i predstavljaju se preko kontrolne strukture i opšte naredbe. Apstrakcija struktura podataka, kojoj se izdvaja iz nekog skupa struktura podataka ono što su njihova opšta svojstva i predstavljaju se preko iteratora, koji u opštem smislu kontroliše kretanje kroz strukturu podataka.

SPOJENOST – KOHEZIJA U razvoju obejktno-orijentisanog softvera potrebno je postići dva cilja: • •

Treba izgraditi klase koje imaju visoku koheziju (high cohesion) Klase treba da budu slabo povezane (weak coupling).

Kohezija Klasa X je odgovorna da obezbedi neko ponašanje m1(). class X { public m1(){} } Ukoliko u realizaciji navedenog ponašanje učestvuju ostale metode (m11, m12, m13) klase X, 84

class X { public m1(){m11();m12();m13();…} private m11(){…} m12(){…} m13(){…} } Tada za ovakvu klasu možemo kažemo da ima visoku koheziju. Kohezija je mera kojoj se utvrđuje koliko su metode unutar klase međusobno povezane. U ovom primeru razvoja softverskog sistema za glasanje klase koje su odgovorne za realizaciju sistemskih operacija imaju visoku koheziju, kao npr. kod apstraktne klase OpstaSO koja je odgovorna za izvršenje sistemske operacije izvrsiOperaciju(Object obj) public abstract class OpstaSO { public void izvrsiOperaciju(Object obj) throws Exception{ try { // zapocni transakciju zapocniTransakciju(); // proveri preduslov proveriPreduslov(obj); // izvrsi operaciju izvrsiKonkretnuOperaciju(obj); // ako je uspesna potvrdi transakciju potvrdiTransakciju(); } catch (Exception e){ // ako nije uspesna ponisti transakciju ponistiTransakciju(); throw new Exception(e.getMessage()); } } private void zapocniTransakciju() throws SQLException, IOException, Exception{ DBBroker.vratiObjekat().otvoriKonekciju(); 85

} protected abstract void proveriPreduslov(Object obj); protected abstract void izvrsiKonkretnuOperaciju(Object obj) throws Exception; private void potvrdiTransakciju() throws SQLException, IOException, Exception { DBBroker.vratiObjekat().commitTransakcije(); } private void ponistiTransakciju() throws SQLException, IOException, Exception { DBBroker.vratiObjekat().rollbackTransakcje(); } } U navedenom primeru sve metode klase OpstaSO su u funkciji realizacije metode izvrsiOperaciju(Object obj). Gubitak kohezije bi značio da je neka klasa X odgovorna da obezbedi više različitih ponašanja m1, m2, m3 koje nisu između sebe povezana. Ovakva klasa je teška za održavanje i nadogradnju. Trebalo bi praviti klase koje imaju jaku koheziju kako bi se njima lakše upravljalo tj. kako bi se one lako održavale i nadograđivale. Spojenost Spojenost (kuplovanje) znači da su klase u međusobnoj zavisnosti, odnosno da klasa ne može da obavi neku operaciju ako ne postoji neka druga klasa. Npr. klasa X je odgovorna da obezbedi neko ponašanje metodom m1() tako što poziva metodu m2() klase Y. Klasa X je zavisna od klase Y. class X { Y y; X(){y=new Y();} public m1(){y.m2();} } class Y { m2(){...} } U ovom primeru razvoja softverskog sistema za glasanje klasa TFImePrezime, koja predstavlja klasu za realizaciju tekstualnog polja na formi. Ona je odgovorna da obezbedi uzimanje vrednosti iz tog tekstualnog polja sa prethodnom validacijom unete vrednosti, koja se vrši pozivanjem metode validate() klase ComponentValidator.

86

public class TFImePrezime extends javax.swing.JPanel implements IGetValue,ISetValue{ ComponentValidator validator; /** Creates new form TFImePrezime */ public TFImePrezime() { initComponents(); setValidator(new ImePrezimeValidator()); } public String getValue() throws Exception { try{ validator.validate(txtIme.getText()); txtIme.setBorder(new LineBorder(Color.BLACK)); }catch(Exception e){ txtIme.setBorder(new LineBorder(Color.RED)); throw new Exception(e.getMessage()); } return txtIme.getText().trim(); } public void resetuj(){ txtIme.setText(" "); } @Override public void setValue(Object value) throws Exception { String v=(String) value; txtIme.setText(v); } private void setValidator(ImePrezimeValidator godinaValidator) { this.validator=godinaValidator; } } public interface ComponentValidator { public abstract void validate(Object tekst) throws Exception; } public class ImePrezimeValidator implements ComponentValidator{ @Override public void validate(Object tekst) throws Exception { String t=(String) tekst; if (t != null && t.length() != 0){ }else{ 87

throw new Exception("Niste uneli ime i prezime!"); } } } Za klasu TFImePrezime kažemo da je klasa sa niskom (low coupling) ili slabom (weak coupling) povezanošću jer ne zavisi mnogo od drugih klasa, odnosno zavisi samo od jedne druge klase. Takođe, slabu povezanost vidimo i na primeru klasa odgovornih za realizaciju sistemskih operacija, čija se povezanost ogleda preko klase OpstaSO koja ovim klasama obezbeđuje generičko ponašanje. Dekompozicija i modularizacija Dekompozicija (raščlanjivanje), u najopštijem smislu, je proces koji početni problem deli u skup podproblema, koji se nezavisno rešavaju i time omogućavaju lakše rešavanje početnog problema. Ukoliko dekompoziciju posmatramo u kontekstu razvoja softverskog sistema može se reći da se dekompozicijom softverski sistem deli u više modula, odnosno da je modularizacija rezultat procesa dekompozicije. Dekompozicija se javlja u nekoliko različitih aspekata razvoja softvera: • Dekompozicija kod prikupljanja zahteva Korisnički zahtev se dekomponuje na skup zahteva koji se opisuju preko slučajeva korišćenja (unos kandidata, izmena kandidata, brisanje kandidata, unos izbora, unos glasača, izmena glasača, brisanje glasača, prijavljivanje glasača na sistem, glasanje i pregled izbornih rezultata).

88

• Dekompozicija kod projektovanja softvera U fazi projektovanja pravi se arhitektura softverskog sistema koja se obično dekomponuje na tri modula (komponente): korisnički interfejs, aplikaciona logika i skladište podataka. Nakon toga se ti moduli dalje dekomponuju a svaki od modula koji je dobijen dekompozicijom može se nezavisno projektovati i implementirati u odnosu na druge module.

Principi koji treba da budu zadovoljeni kada se softverski sistem dekomponuje u module su: 1. Moduli treba da imaju jaku koheziju (high cohesion) 2. Moduli treba da budu što je moguće slabije povezani (weak coupling) 3. Svaki modul treba da čuva svoje interne informacije (information hiding). • Dekompozicija funkcija (metoda) Funkcija (metoda) neke klase ukoliko je složena može se dekomponovati u više podfunkcija, koje se zatim nezavisno rešavaju da bi se na kraju integrisale u jednu celinu i na taj način realizovala početna funkcija.

89

Učaurenje (encapsulation) / Sakrivanje informacija (Information hiding) Učaurenje je proces u kome se razdvajaju osobine modula (npr. klase) koje su javne za druge module od osobina koje su sakrivene od drugih modula sistema. Sakrivanje informacija nastaje kao rezultat procesa učaurenja, gde se sakrivaju osobine modula koje nisu javne za korisnika modula. Primer: public class TFImePrezime extends javax.swing.JPanel implements IGetValue,ISetValue{ ComponentValidator validator; public TFImePrezime() { //osobine klase koje su javne i koje mogu koristiti korisnici initComponents(); setValidator(new ImePrezimeValidator()); } private void setValidator(ImePrezimeValidator validator) { //osobine klase koje nisu javne i koje se sakrivaju od korisnika this.validator=godinaValidator; } } Klasi TFImePrezime se može pristupiti preko konstruktor metode TFImePrezime() i metode getValue() koje su javne, dok je metoda setValidator(ImePrezimeValidator validator) privatna odnosna sakrivena od korisnika te klase. Klasa UnosGlasacaForm je klasa koja je korisnik klase TFImePrezime i ona zna kako se inicijalizuje objekat klase TFImePrezime preko konstruktora kome može direktno da pristupi dok metodi setValidator() ne može pristupiti direktno jer je privatna. public class UnosGlasacaForm { private UnosGlasacaPanelForm unosGlasacaPanelForm; 90

public void setUnosGlasacaPanelForm(UnosGlasacaPanelForm unosGlasacaPanelForm) { this.unosGlasacaPanelForm = unosGlasacaPanelForm; } public UnosGlasacaForm(UnosGlasacaPanelForm unosGlasacaPanelForm) { this.unosGlasacaPanelForm = unosGlasacaPanelForm; } public UnosGlasacaPanelForm getUnosGlasacaPanelForm() { unosGlasacaPanelForm.setIdPanel(new TFId()); unosGlasacaPanelForm.setImePrezimePanel(new TFImePrezime()); unosGlasacaPanelForm.setJmbgPanel(new TFJmbg()); unosGlasacaPanelForm.setSifraGlasacaPanel(new TFSifraGlasaca()); unosGlasacaPanelForm.setUlicaBrojPanel(new TFUlicaBroj()); unosGlasacaPanelForm.setGradPanel(new CBIzborGrada()); return unosGlasacaPanelForm; } } Odvajanje interfejsa i implementacije (Separation of interface and implementation) Interfejs se odvaja od implementacije i izlaže se korisniku, koji ne zna kako su operacije interfejsa implementirane. U navedenom primeru korisnik je DBBroker, dok je OpstiDomenskiObjekat interfejs koji izlaže operacije korisniku. DBBroker ne zna kako su operacije domenskih klasa (Glasac, Kandidat, Grad, Izbor, TipIzbora) implementirane. Sve domenske klase realizuju interfejs OpstiDomenskiObjekat.

91

5.5.2. Strategije projektovanja softvera Neke od poznatih strategija projektovanja softvera su: • • • •

Podeli i pobedi S vrha na dole Odozgo na gore Iterativno – inkrementalni pristup

Podeli i pobedi Strategija podeli i pobedi zasnovana je na principu dekompozicije koja početni problem deli u skup podproblema koji se nezavisno rešavaju, u cilju lakšeg rešavanja početnog problema. Primer: Ova strategija se najčešće primenjuje u sledećim fazama razvoja softvera: • • •

Prikupljanje zahteva – Zahtevi se opisuju preko skupa nezavisnih slučajeva korišćenja Analiza – Struktura se opisuje preko skupa koncepata koji čine konceptualni model. Ponašanje se opisuje preko skupa nezavisnih sistemskih operacija Projektovanje – Arhitektura sistema se deli u tri nivoa: korisnički interfejs, aplikaciona logika i skladište podataka. Korisnički interfejs se deli na dva dela: ekranske forme i kontroler KI. Aplikaciona logika se deli u tri dela: kontroler aplikacione logike, poslovna logika i broker baze podataka.

92

S vrha na dole (top down) Strategija s vrha na dole je zasnovana na principu dekompozicije funkcija koja početnu funkciju dekomponuje u više podfunkcija koje se rešavaju nezavisno, kako bi se njihovim integrisanjem u celinu na kraju realizovala početna funkcija. Primer: Projektovanje metode izvrsiOperaciju() apstraktne klase opstaSO public abstract class OpstaSO { public void izvrsiOperaciju(Object obj) throws Exception{ try { zapocniTransakciju(); proveriPreduslov(obj); izvrsiKonkretnuOperaciju(obj); potvrdiTransakciju(); } catch (Exception e){ ponistiTransakciju(); throw new Exception(e.getMessage()); } } private void zapocniTransakciju() throws SQLException, IOException, Exception{ DBBroker.vratiObjekat().otvoriKonekciju(); } protected abstract void proveriPreduslov(Object obj); protected abstract void izvrsiKonkretnuOperaciju(Object obj) throws Exception; private void potvrdiTransakciju() throws SQLException, IOException, Exception { DBBroker.vratiObjekat().commitTransakcije(); } private void ponistiTransakciju() throws SQLException, IOException, Exception { DBBroker.vratiObjekat().rollbackTransakcje(); } } Odozgo na gore (bottom-up) Strategija odozgo na gore je zasnovana na principu generalizacije, koji u nekoj funkciji koja je složena uočava jednu ili više logičkih celina koje proglašava za funkcije. Na taj način je jedna složena funkcija 93

dekomponovana u više nezavisnih funkcija, a kompozicija tih funkcija obezbeđuje istu funkcionalnost kao i složena funkcija. Primer: Pre primene strategije odozgo – na gore , gde je metoda izvrsiOperaciju() bila malo složenija: public abstract class OpstaSO { public void izvrsiOperaciju(Object obj) throws Exception{ try { DBBroker.vratiObjekat().otvoriKonekciju(); proveriPreduslov(obj); izvrsiKonkretnuOperaciju(obj); DBBroker.vratiObjekat().commitTransakcije(); } catch (Exception e){ DBBroker.vratiObjekat().rollbackTransakcje(); throw new Exception(e.getMessage()); } } protected abstract void proveriPreduslov(Object obj); protected abstract void izvrsiKonkretnuOperaciju(Object obj) throws Exception; } A nakon primene strategije: public abstract class OpstaSO { public void izvrsiOperaciju(Object obj) throws Exception{ try { zapocniTransakciju(); proveriPreduslov(obj); izvrsiKonkretnuOperaciju(obj); potvrdiTransakciju(); } catch (Exception e){ ponistiTransakciju(); throw new Exception(e.getMessage()); } } private void zapocniTransakciju() throws SQLException, IOException, Exception{ DBBroker.vratiObjekat().otvoriKonekciju(); } protected abstract void proveriPreduslov(Object obj); 94

protected abstract void izvrsiKonkretnuOperaciju(Object obj) throws Exception; private void potvrdiTransakciju() throws SQLException, IOException, Exception { DBBroker.vratiObjekat().commitTransakcije(); } private void ponistiTransakciju() throws SQLException, IOException, Exception { DBBroker.vratiObjekat().rollbackTransakcje(); } }

Iterativno – inkrementalni pristup (iterative and incremental approach) Sistem se deli u više mini projekata koji se nezavisno razvijaju i prolaze kroz sve faze razvoja softvera. Mini projekat može biti vezan za slučaj korišćenja ili za složenu sistemsku operaciju. Svaki mini projekat prolazi kroz više iteracija, čiji rezultat, interno izdanje (release) ili build predstavlja inkrement za sistem. Na kraju se implementirani mini projekti integrišu u softverski sistem. Primer: U primeru razvoja softverskog sistema za glasanje na izborima imali smo nekoliko nezavisnih slučajeva korišćenja iz kojih smo dobili nekoliko nezavisnih sistemskih operacija. Razvoj pojedinačne sistemske operacije nije zavisila od razvoja bilo koje druge sistemske operacije, odnosno neka sistemska operacija može biti implementirana i integrisana u sistem dok druga sistemska operacija može tek biti identifikovana u fazi analize. 5.5.3. Metode projektovanja softvera Neke od najvažnijih metoda projektovanja softvera su: • • • •

Funkcionalno orijentisano projektovanje Objektno orijentisano projektovanje Projektovanje zasnovano na strukturi podataka Projektovanje zasnovano na komponentama

Funkcionalno orijentisano projektovanje je zasnovano na funkcijama. Problem se posmatra iz perspektive njegovog ponašanja odnosno funkcionalnosti. Prvo se uočavaju funkcije sistema, zatim se određuju strukture podataka nad kojima se izvršavaju te funkcije. Objektno orijentisano projektovanje je zasnovano na objektima (klasama). Objekti mogu da reprezentuju i strukturu (atribute) i ponašanje (metode) softverskog sistema. Kod objektno orijentisanog projektovanja paralelno se razvijaju i struktura i ponašanje. Projektovanje zasnovano na strukturi podataka problem posmatra iz perspektive strukture. Prvo se uočava struktura sistema, zatim se određuju funkcije koje se izvršavaju nad tom strukturom. Projektovanje zasnovano na komponentama problem posmatra iz perspektive postojećih komponenti koje se mogu (ponovo) koristiti u rešavanju problema. Prvo se uočavaju delovi problema koji se mogu 95

realizovati preko postojećih komponenti a nakon toga se implementiraju delovi za koje nije postojalo rešenje. Objektno orijentisano projektovanje (Object – oriented design) Objektno orijentisano projektovanje je zasnovano na objektima (klasama). Objekti mogu da reprezentuju i strukturu (atribute) i ponašanje (metode) softverskog sistema. Kod objektno orijentisanog projektovanja paralelno se razvijaju i struktura i ponašanje. U ovom primeru kao rezultat analize se dobija logička struktura i ponašanje softverskog sistema. Struktura je opisana preko konceptualnog modela, dok je ponašanje opisano preko dijagrama sekvenci. Konceptualni model se sastoji od skupa međusobno povezanih koncepata (klasa, odnosno njihovih pojavljivanja objekata), dok sekvencni dijagram opisuje interakciju između objekata (aktora i softverskog sistema). To znači da su u osnovi logičke strukture i ponašanja softverskog sistema objekti. Zato se ovakva analiza zove objektno orijentisana analiza. Kasnije se u fazi projektovanja i implementacije određuju klase koje će da relizuju strukturu (domenske klase) i ponašanje (klase koje realizuju sistemske operacije). To znači da su u osnovi fizičke strukture i ponašanja softverskog sistema takođe objekti, odnosno klase. Zato se ovakvo projektovanje naziva objektno – orijentisano projektovanje. Principi objektno orijentisanog projektovanja klasa (Principles od Object Oriented Class Design) Postoje sledeći principi kod objektno – orijentisanog projektovanja klasa: • • • • •

Princip Otvoreno – Zatvoreno Princip zamene Barbare Liskov Princip inverzije zavisnosti Princip umetanja zavisnosti Princip izdvajanja interfejsa

Princip Otvoreno – Zatvoreno (Open – Closed principle) Princip Otvoreno – Zatvoreno: Modul treba da bude otvoren za proširenje ali i zatvoren za modifikaciju. Primer 1: U ovom primeru klasa OpstaSO je zatvorena za promenu njenog ponašanja ali je u isto vreme i otvorena za promenu njenog ponašanja u klasama koje su iz nje izvedene kao npr. Klasa SacuvajSO: public abstract class OpstaSO { public void izvrsiOperaciju(Object obj) throws Exception{ try { zapocniTransakciju(); proveriPreduslov(obj); izvrsiKonkretnuOperaciju(obj); potvrdiTransakciju(); } catch (Exception e){ 96

ponistiTransakciju(); throw new Exception(e.getMessage()); } } private void zapocniTransakciju() throws SQLException, IOException, Exception{ DBBroker.vratiObjekat().otvoriKonekciju(); } protected abstract void proveriPreduslov(Object obj); protected abstract void izvrsiKonkretnuOperaciju(Object obj) throws Exception; private void potvrdiTransakciju() throws SQLException, IOException, Exception { DBBroker.vratiObjekat().commitTransakcije(); } private void ponistiTransakciju() throws SQLException, IOException, Exception { DBBroker.vratiObjekat().rollbackTransakcje(); } } public class SacuvajSO extends OpstaSO{ @Override protected void proveriPreduslov(Object obj) { } @Override protected void izvrsiKonkretnuOperaciju(Object obj) throws Exception { try { //KomunikacijaSaBazom.vratiObjekat().ubaciKandidata((Kandidat) obj); DomenskiObjekat objekat=(DomenskiObjekat) obj; DBBroker.vratiObjekat().sacuvajObjekat(objekat); } catch (Exception ex) { throw new Exception("Cuvanje nije uspesno."); } } }

97

Princip zamene Barbare Liskov (The Liskov Substitution Principle) Princip zamene Barbare Liskov: Podklase treba da budu zamenljive. Primer: Klase Glasac i Kandidat mogu se zameniti njihovom nadklasom OpstiDomenskiObjekat: public class DBBroker { public void sacuvajObjekat(DomenskiObjekat domenskiObjekat) throws Exception { try { String upit = "INSERT INTO " + domenskiObjekat.vratiNazivTabele() + " VALUES " + domenskiObjekat.vratiVrednostiZaINSERT(); Statement st = konekcija.createStatement(); st.executeUpdate(upit); } catch (SQLException ex) { System.out.println("Greska!"); throw new Exception("Objekat nije sacuvan: " + ex.getMessage()); } } } public class Kontroler { public void ubaciKandidata(Kandidat k) throws Exception { OpstaSO unosKandidata=new SacuvajSO(); unosKandidata.izvrsiOperaciju(k); } } public class SacuvajKandidataSO extends OpstaSO{ protected void izvrsiKonkretnuOperaciju(Object obj) throws Exception { try { Kandidat objekat=(Kandidat) obj; DBBroker.vratiObjekat().sacuvajObjekat(objekat); } catch (Exception ex) { throw new Exception("Cuvanje nije uspesno."); } } }

98

Princip inverzije zavisnosti (The dependency Inversion Principle) Princip inverzije zavisnosti : Zavisi od apstrakcije a ne od konkretizacije. Moduli najvišeg nivoa ne treba da zavise od modula nižeg nivoa, već oba isključivo od apstrakcije. Apstrakcije ne treba da zavise od detalja, a detalji treba da zavise od apstrakcije. U navedenom primeru se izbegava direktna povezanost između brokera baze podataka i domenskih klasa već se broker povezuje sa interfejsom DomenskiObjekat koga realizuju navedene domenske klase. Na taj način DBBroker je posredno povezan preko interfejsa opšti domenski objekat sa svakom klasom koja realizuje taj interfejs.

99

Opšti slučaj:

Princip umetanja zavisnosti (The dependency injection principle) Princip umetanja zavisnosti : Zavisnosti između dve komponente programa se uspostavljaju u vreme izvršenja programa preko neke treće komponente. U navedenom primeru zavisnost između brokera baze podataka i konkretne domenske klase se uspostavlja u vreme izvršavanja programa preko klase OpstaSO.

100

Opšti slučaj:

101

6. Primena paterna u projektovanju Za projektovanje realnog softverskog sistema za glasanje, kao i bilo kog drugog velikog sistema, veoma je bitno njegovo održavanje. U praksi, veliki deo softverskog koda može se više puta koristiti. Moguće je da deo koda jednog projekta upotrebimo za neki novi projekat kako bismo skratili vreme njegove realizacije. Svaki problem koji se javi tokom razvoja softvera ne treba rešavati od početka. Potrebno je koristiti rešenja koja su uspešno korišćena ranije. Takođe, svako novo dobro rešenje treba se uključiti i koristiti ponovo. Iz tog razloga se u mnogim objektno orijentisanim sistemima nailazi na iste uzore klasa i objekata koji komuniciraju. Ti uzori rešavaju specifične probleme projektovanja i omogućavaju fleksibilnost i ponovnu upotrebljivost objektno orijentisanog dizajna. Oni projektantima pomažu da ponovo upotrebe uspešne projekte tako što će novi projekat zasnovati na prethodnom iskustvu. Ovi uzori nazivaju se još i paterni.

6.1. Opšte o paternima Paterni tj. uzori su gotova rešenja koja se primenjuju u projektovanju softvera. „Svaki uzorak opisuje problem koji se stalno ponavlja u našem okruženju i zatim opisuje suštinu rešenja problema tako da se to rešenje može upotrebiti milion puta, a da se dva puta ne ponovi na isti način.“(Cristopher Alexander) Svaki patern sastoji se od tri dela: problema koji se rešava, konteksta u smislu određenih ograničenja i rešenja problema. Kada je konteks odgovarajući, ista pravila se mogu primeniti da bi se problem rešio u tom konkretnom slučaju. Paterni su razvijeni kako bi podržali izgradnju velikih, složenih sistema, da bi se dokumentovao svaki potencijalni problem i njegovo rešenje i da bi ovakvo znanje programeri u budućnosti koristili i primenjivali. Paterni su definisani i kao opisi komunikacije objekata i klasa koji su prilagođene za rešavanje opštih problema u datom kontekstu. Takođe, imena paterna, apstrakcije i identifikacija ključnih aspekata zajedničke strukture čine ih korisnim za kreiranje objektno orijentisanog dizajna za ponovno korišćenje. Paterni identifikuju klase i njihove instance koje učestvuju u strukturi, njihove uloge i veze i raspodelu odgovornosti, odnosno daju apstraktan opis problema projektovanja i kako se on rešava opštim uređenjem elemenata (klasa i objekata) . Svaki patern koncentrisan je na određeni problem. Opisuje kada se može primeniti, da li se ili ne može primeniti uzimajući u obzir ograničenja ili posledice njegove primene. Postoji kategorizacija paterna u tri grupe: paterni za kreiranje objekata, strukturni paterni i paterni ponasanja. • Paterni za kreiranje objekata apstrahuju proces instancijalizacije, tj. kreiranja objekata. Daju veliku prilagodljivost u tome šta će biti kreirano, ko će to kreirati, kako i kada će biti kreirano. Oni pomažu da se izgradi sistem nezavisno od toga kako su objekti kreirani, komponovani ili reprezentovani. • Strukturni paterni opisuju složene strukture međusobno povezanih klasa i objekata. • Paterni ponašanja opisuju način na koji klase ili objekti sarađuju i raspoređuju odgovornosti.

102

6.2. Paterni kao rešenja problema projektovanja Softverski sistem za glasanje na izborima treba da obezbedi određene funkcije za dve vrste korisnika: za administratora glasanja na izborima treba da omogući unos, izmenu i brisanje podataka o glasačima, kandidatima i izborima, kao i glasanje za samog administratora dok običnim glasačima treba da obezbedi prijavljivanje na sistem i glasanje na izborima. Zahtev 1: Potrebno je obezbediti obe vrste funkcija, manipulaciju podacima i glasanje za administratora sa jedne i glasanje na izborima za obične korisnike sa druge strane. Rešenje: U zavisnosti od ova dva tipa funkcija potrebne su i dve forme za unos podataka. Najjednostavniji način bio bi da se prilikom pokretanja sistema korisniku omogući izbor moda aplikacije u kome želi da radi i na osnovu odgovora otvori forma za administraciju izbora ili forma za glasanje.

Slika 88. Odabir moda za rad Umesto kreiranja dve različite forme, mogu se kreirati dva panela koji će se, u zavisnosti od odabira korisnika, postavljati na jednu glavnu formu. Ukoliko se korisnik odluči za administraciju, na formu se postavlja panel koji sadrži meni sa opcijama za manipulaciju različitim podacima (slika 89.).

Slika 89. Panel – mod za administraciju Iz ovog administratorskog panela takođe se može odabrati opcija za glasanje, koja vodi administratora do prijavljivanja na sistem. Obzirom da je korisnik osoba koja vrši administraciju sistema, polje za unos šifre može biti obično tekst polje, dok izbor za koji će glasati bira preko radio button-a.

103

Slika 90. Panel za prijavljivanje na sistem- administratorski mod Ukoliko korisnik odabere mod za glasanje, pojavljuje se panel sa poljima za unos podataka potrebnih za prijavljivanje na sistem kao na slici 91.

Slika 91. Panel za prijavljivanje na sistem – mod za glasanje Za običnog korisnika polje za unos šifre postavićemo kao password field, tako da se ne vidi šifra koju je korisnik uneo, a izbor za koji želi da glasa biraće u padajućoj listi combo-boxa. Da bismo izbegli prosto dodavanje polja na formu, i time i kreiranje dve ili više sličnih formi, ove dve forme implementirali smo na različit način. Prvi korak je uočavanje delova koji su zajednički i za jednu i za drugu formu, u ovom slučaju polja za unos matičnog broja, koje je identično u oba slučaja. U ovom slučaju imamo jedno polje koje je isto, ali u sledećim formama odnosno zahtevima će ih verovatno biti i više. Ovi zahtevi za dodavanjem ili oduzimanjem polja za unos mogu se olakšati, tako što će svako polje 104

postati panel koji će se zatim dodavati po potrebi, a neće se na formu jedno polje dodavati više puta. Dakle, umesto polja za unos podataka koji se nalaze na samim formama napravimo pojedinačne panele koji će za svaki potrebni podatak sadržati jednu labelu sa nazivom i jedno polje za unos, i kasnije te panele dodamo formi u zavisnosti od zahteva. Ovakva struktura će ne samo olakšati kasnije dodavanje ili brisanje polja za unos, već će i smanjiti ponavljanja istih polja na različitim formama. Pojedinačni paneli izgledaju kao na slici 92.

Slika 92. Izgled pojedinačnih panela Kombinovanjem ovih panela dobijamo dve različite forme koje će zadovoljavati potrebe za obe vrste korisnika. Na prvu formu ćemo postaviti panel za matični broj, panel šifre koja se unosi kao običan tekst i panel za izbor gde su prikazane opcije a korisnik označava onu koju želi (radio button), i ova forma služi za glasanje administratora. Na drugu formu ćemo postaviti panel-polje za unos matičnog broja,panel za unos šifre u vidu tačkica i panel izbora gde se opcija bira iz padajuće liste combo box-a. Ova forma je prikladnija kada je u pitanju glasanje običnog korisnika.

Slika 93. Forma za logovanje administratora

105

Slika 94. Forma za logovanje običnog korisnika Pri projektovanju ovog rešenja koristili smo Abstract Factory patern. Abstract Factory patern nam omogućava da prvenstveno vodimo računa o celini, dok detalje ostavljamo za kasnije, osnosno obezbeđuje klase koje će se pobrinuti o kreiranju delova željenog objekta umesto nas. Interfejs Abstract Factory prenosi odgovornost za kreiranje objekata do Concrete Factory podklasa. Klijent ne brine o tome koji će od konkretnih objekata dobiti od kog Concrete Factory već koristi isključivo generički interfejs. Ovaj patern odvaja detalje implementacije od opšte upotrebe. Definicija: Obezbeđuje interfejs (AbstractFactory) za kreiranje(CreateProductA(),CreateProductB()) familije povezanih ili zavisnih objekata (AbstractProductA, AbstractProductB) bez navođenja (specificiranja) njihovih konkretnih klasa (ProductA1,ProductA2, ProductB1, ProductB2).

Slika 95. Abstract Factory patern

106

U ovom konkretnom slučaju:

Slika 96. Abstract Factory patern na datom primeru Primer koda za Abstract Factory dat je na kraju rada u dodatku 1. Koji će se od ova dva panela naći na glavnoj formi rešava se u klasi KoordinatorForm, tačnije u njenoj metodi pokreni aplikaciju. Uzor koji ćemo u ovom slučaju koristiti je Builder pattern. Builder patern je kreacioni patern. Njegova namena je da uvede apstrakciju u koracima konstrukcije objekata tako da različite implementacije ovih koraka mogu kreirati različite reprezentacije objekata. Definicija: Razdvaja izgradnju složenog objekta od njegove reprezentacije da bi isti proces pravljenja mogao da proizvede različite reprezentacije.On deli odgovornost za kontrolu konstrukcije (Director) 107

složenog objekta od odgovornosti za realizaciju njegove reprezentacije-konkretne konstrukcije(Builder), tako da isti konstrukcioni proces(Director.Construct()) može da kreira različite reprezentacije u zavisnosti od ConcreteBuildera.Director nadzire proces pravljenja proizvoda.

Slika 97. Builder patern U konkretnom primeru: Na osnovu odgovora korisnika za koji se odlučuje pri pojavljivanju pitanja u formi modalnog dijaloga pri pokretanju aplikacije, on bira da li će se na glavnoj formi naći panel za administraciju ili panel za glasanje.

Slika 98. Builder patern na datom primeru Primer koda za Builder dat je na kraju rada u dodatku 2.

108

Builder patern je veoma sličan Abstract Factory paternu po tome što i on može da konstruiše složene objekte. Osnovna razlika je u tome što se Builder patern usredsređuje na izgradnju složenog objekta korak po korak dok je kod Abstract Factory paterna naglasak na familijama objekata proizvoda. Builder vraća proizvod kao završni korak dok se kod Abstract Factory proizvod vraća odmah. Zahtev 2: Kako bi se obuhvatili svi podaci vezani za glasanje, osim podataka o kandidatima potrebno je čuvati i podatke o izborima i glasačima. Trenutno rešenje: Kada želimo da unesemo novi izbor ili novog glasača, potrebno je da kreiramo potpuno novu formu za unos izbora ili glasača. Potencijalni problem: Jedan od potencijalnih problema je u prethodnim koracima rešen. Naime, nećemo imati problema pri kreiranju novih polja koja nemamo u strukturi postojeće dve forme, već je potrebno samo kreirati onoliko novih panela koliko nam polja za unos novih podataka treba. Međutim, sa trenutnom strukturom našeg sistema potrebno je napraviti još jednu praznu formu na kojoj će se prema potrebama dodeliti određena polja za unos. Tako dolazi do nepotrebnih gomilanja praznih formi i ponavljanja metoda za postavljanje panela. Predlog rešenja: Sa ciljem izbegavanja nepotrebnih gomilanja praznih formi i ponavljanja metoda za postavljanje panela postojeću strukturu ćemo izmeniti tako što ćemo zadržati samo jednu, glavnu formu na kojoj će se u zavisnosti od izbora prikazivati određena polja za unos potrebnih podataka. Pored glavne forme na kojoj će se prikazivati sva potrebna polja, kreiraćemo i jedan panel koji će sadržati metode za pojedinačno postavljanje svih panela sa poljima za unos. Sa ovako implementiranim rešenjem postojaće samo jedna glavna forma na koju će se postavljati različiti paneli.

Slika 99. Postavljanje panela za unos na formu Dok svaki od panela sa poljima (na slici 99. to su paneli sa desne strane ) postavljamo na panel za unos (na slici 99. nalazi se u sredini) preko metoda koja se na samom tom panelu nalaze, postavlja se pitanje 109

na koji način će se paneli za unos postavljati na formu. Ovaj problem ćemo rešiti kreiranjem klase UnosGlasacaForm u kojoj ćemo imati atribut koji predstavlja panel za unos, metodu za dodeljivanje konkretnog panela tom atributu, kao i metodu getUnosKandidataPanelForm(), u kojoj se na panel za unos postavljaju pojedinačni paneli-polja koji se istovremeno i kreiraju. U ovom slučaju primenjujemo patern dekorator. Pridružuje odgovornost do objekta dinamički. Dekorator proširuje funkcionalnost objekta dinamičkim dodavanjem funkcionalnosti drugih objekata. Definicija: Pridružuje odgovornost do objekta dinamički. Dekorator proširuje funkcionalnost objekta (ConcreteComponent) dinamičkim dodavanjem funkcionalnosti drugih objekata (ConcreteDecoratorA, ConcreteDecoratorB)

. Slika 100. Decorator patern Na konkretnom primeru: Komponente u vidu pojedinačnih panela obuhvatamo drugim objektom koji predstavlja panel odnosno okvir oko njih. Taj drugi objekat nazivamo dekorator. Dekorator se prilagođava interfejsu komponente koju ukrašava, tako da je njegovo prisustvo transparentno za klijente komponente. Dekorator prosleđuje zahteve komponenti i može da obavi dodatne radnje pre ili posle prosleđivanja.

Slika 101. Patern Decorator na datom primeru 110

Primer koda za Decorator dat je na kraju rada u dodatku 3. U glavnoj formi regulišemo koji će se panel pojaviti na formi u zavisnosti od toga za koju se opciju sa glavnog menija forme korisnik odluči. Metodu postaviNoviPanel() ćemo pozivati iz klase koju ćemo nazvati KoordinatorForm i koja će biti implementirana kao Singletone uzor čime se obezbeđuje da klasa ima samo jedno pojavljivanje, odnosno onemogućava se ponovno kreiranje njene instance. Ovakva implementacija je bitna jer je potrebno da samo jedan objekat koordiniše akcije postavljanja panela na glavnu formu. Singleton patern obezbeđuje klasi samo jedno pojavljivanje i globalni pristup do nje. Definise Instance() operaciju koja omogućava klijentima pristup do njenog jedinstvenog pojavljivanja.

Slika 102. Singleton patern U konretnom primeru:

Slika 103. Singleton patern na datom primeru Obezbedili smo da se svaki put pozivanjem statičke metode vratiKoordinatora() vrati jedan jedinstven objekat KoordinatorForm ili, ukoliko isti ne postoji da se kreira. Primer koda za Singleton dat je na kraju rada u dodatku 4. Zahtev 3: Potrebno je izvršiti validaciju unetih podataka pre nego što se isti prihvate od korisnika. Validacija treba da obuhvati sledeće: proveru da li je unet odgovarajući tip podatka (tekst ili broj), proveru dužine unetog teksta, proveru da li je neko polje ostalo nepopunjeno. Takođe, obzirom da postoji veliki broj različitih polja, čak i na jednom panelu, potrebno je korisniku ukazati precizno na grešku koju je napravio kako bi je bez većih poteškoća ispravio. Trenutno rešenje: Pri preuzimanju podataka svake komponente proveriti sadržaj koji je korisnik uneo. Potencijalni problem: Obzirom da postoji veliki broj polja i komponenata, onome ko projektuje ovaj zahtev predstavljaće veliki problem da pojedinačno za svaku komponentu iznova proverava da li vrednosti zadovoljavaju ograničenja.

111

Predlog rešenja: Ono što može da se uradi u ovom slučaju je da se kreira interfejs ComponentValidator sa metodom validate(), a zatim klase koje će predstavljati validatore za svako polje, a koje će implementirati ovaj interfejs. Samim tim svaka od njih će implementirati metodu validate() na odgovarajuć način za to polje. Prednost je u tome što sada kod svakog polja možemo dodati referencu na ComponentValidator a njemu dodeliti konkretan validator. Nakon toga, kod metode getValue() koja vraća vrednost datog polja samo možemo da pozovemo metodu validate() bez obzira o kom polju se radilo jer smo za to polje već dodelili njegov validator koji unapred “zna” šta treba da proverava. Drugi deo zahteva, vezan za davanje obaveštenja o grešci korisniku, rešavamo tako što definišemo različite izuzetke u samoj metodi validate() kod validatora, a zatim, kada kod datog panela- polja pozivamo tu metodu, stavljamo je u try- catch blok i eventualno obrađujemo izuzetke koji se jave. Pri rešavanju ovog problema koristimo Strategy pattern. Strategy patern koristi se kada se više srodnih klasa razlikuje samo po ponašanju, kada su potrebne različite verzije jednog algoritma i kada treba da se izbegnu ispoljavanja složenih struktura podataka specifičnih za pojedine algoritme. Definicija: Strategy pattern definiše familiju algoritama, enkapsulira svaki od njih i omogućava da se mogu međusobno zamenjivati. Strategija omogućava da se algoritam menja nezavisno od klijenata koji ga koriste.

Slika 104. Strategy pattern U konkretnom primeru: Context predstavlja interfejs TekstPolje koji definiše interfejs koji implementiraju sva polja i preko koga strategy objekat može pristupiti njihovim podacima. Strategy objekat je interfejs ComponentValidator koji definiše algoritam validate(). ConcreteStrategy A,B,C predstavljaju konkretne validatore za određena polja.

Slika 105. Strategy patern na datom primeru Primer koda za Strategy dat je na kraju rada u dodatku 5. 112

Zahtev 4: Kada korisnik klikne na dugme i time pošalje zahtev za čuvanjem, brisanjem ili izmenom nekih podataka, serverska strana treba da prihvati i da obradi taj zahtev. Trenutno rešenje: Obzirom da izvršenje bilo koje od tih konkretnih operacija podrazumeva proveru nekih preduslova, početak transakcije, potvrdu ili poništenje transkakcije i izvršenje konkretne operacije, taj kod će se ponavljati u svakoj klasi zaduženoj za izvršenje svake sistemske operacije. Potencijalan problem koji se javlja sa ovim rešenjem je višestruko ponavljanje koda. Predlog rešenja: Nepromenljive delove algoritma za izvršenje sistemske operacije izdvajamo na jednom mestu, odnosno u posebnoj apstraktnoj klasi OpstaSO a implementaciju ponašanja koja se menja prepušta se podklasama. Svako ponašanje koje je zajedničko za podklase treba izdvojiti i staviti u zajedničku klasu kako bi se izbeglo dupliranje koda. Ovo rešenje će se realizovati koristeći Template patern. Template metod predstavlja jednu od osnovnih tehnika za višestruku upotrebu koda. Posebno je značajan u bibliotekama klasa pošto predstavlja sredstvo za izdvajanje zajedničkog ponašanja u klase biblioteke. Definicija: Template metod definiše skelet algoritma u operaciji, prepuštajući izvršenje nekih koraka operacija podklasama. Template metod omogućava podklasama da redefinišu neke od koraka algoritama bez promene algoritamske strukture.

Slika 106. Template method Na konkretnom primeru: U jednoj apstraktnoj klasi OpstaSO izdvojićemo algoritam izvrsiOperaciju(Object obj) koji se sastoji od operacija zapocniTransakciju(), proveriPreduslov(obj), izvrsiKonkretnuOperaciju(obj), potvrdiTransakciju() i ponistiTransakciju(). Odmah možemo da primetimo da su operacije koje su nepromenljive zapocniTransakciju(),potvrdiTransakciju() i ponistiTransakciju() dok su proveriPreduslov(obj), izvrsiKonkretnuOperaciju(obj) metode koje se menjaju u zavisnosti od toga šta sistemska operacija radi. Prema tome, operacije proveriPreduslov(obj), izvrsiKonkretnuOperaciju(obj) predstavićemo kao apstraktne metode, koje će svaka klasa koja nasleđuje OpstaSO implementirati na svoj način, dok ćemo nepromenljive operacije implementirati direktno u klasi OpstaSO.

113

Slika 107. Template method na datom primeru Primer koda za Template dat je na kraju rada u dodatku 6. Zahtev 5: Potrebno je obraditi različite zahteve korisnika koji on sa klijentske strane šalje serveru pritiskom na bilo koje dugme na formi. Potencijalni problem: Klijent je vezan za različite funkcionalnosti softverskog sistema i da bi obezbedio agregatne funkcionalnosti mora da zna sve klase i potpise metoda. Rešenje: Serverska strana postavlja ispred sebe interfejs sa funkcionalnostima koje će klijent koristiti bez potrebe da zna sve o metodama i klasama. Da bismo došli do ovog rešenja koristićemo Facade patern. Strukturisanje sistema u podsisteme pomaže da se smanji složenost. Uobičajeni cilj projektovanja je da se komunikacija i međuzavisnost podsistema svedu na minimum. Jedan od načina da se postigne ovaj cilj je da se uvede objekat fasada koji će ponuditi jedan uprošćeni interfejs za opštije poslove podsistema. Definicija: Facade patern pruža ujednačen interfejs za skup interfejsa jednog podsistema. Fasada definiše interfejs višeg nivoa da bi se podsistem lakše koristio.

Slika 108. Facade patern

114

U konkretnom primeru: Kontroler u ovom slučaju predstavlja interfejs koji prihvata zahtev od klijenta i prosleđuje ga dalje sistemskim operacijama. On tačno zna koja klasa podsistema je odgovorna za svaki zahtev. Klase podsistema, u ovom slučaju klase koje predstavljaju sistemske operacije implementiraju funkcionalnost podsistema i izvršavaju zahtev koji im objekat Facade dodeljuje. Fasada zaklanja komponente podsistema od klijenata i tako smanjuje broj objekata sa kojima klijenti imaju posla, što olakšava upotrebu podisistema.

Slika 109. Facade patern na datom primeru Primer koda za Facade dat je na kraju rada u dodatku 7.

115

7. Implementacija Softverski sistem, rezultat ovog rada razvijen je u programskom jeziku Java, a izvorni kod je priložen na pratećem CD-u. Sistem je projektovan kao klijent-server. Kao razvojno okruženje korišćen je NetBeans. Kao sistem za upravljanjem bazom podataka korišćen je MS Access. Server i klijent su implementirani kao desktop aplikacije. Na osnovu arhitekture softverskog sistema dobijene su sledeće softverske klase: • Klijent/forme/FrmAdmin.java • Klijent/forme/PocetniDijalog.java • Klijent/glasac/BrisanjeGlasacaForm.java • Klijent/glasac/IzmenaGlasacaForm.java • Klijent/glasac/UnosGlasacaForm.java • Klijent/glasanje/GlasanjeForm.java • Klijent/glasanje/LogInForm.java • Klijent/izbor/PostavljanjeKandidataZaIzborForm.java • Klijent/izbor/UnosIzboraForm.java • Klijent/kandidat/BrisanjeKandidataForm.java • Klijent/kandidat/IzmenaKandidataForm.java • Klijent/kandidat/UnosKandidataForm.java • Klijent/komunikacija/Komunikacija.java • Klijent/modeli/GlasacTableModel.java • Klijent/modeli/KandidatTableModel.java • Klijent/panel.ISetValue/ISetValue.java • Klijent/panel.IGetValue/IGetValue.java • Klijent/panel.form/BrisanjeGlasacaPanelForm.java • Klijent/panel.form/BrisanjeKandidataPanelForm.java • Klijent/panel.form/GlasanjePanelForm.java • Klijent/panel.form/IzmenaGlasacaPanelForm.java • Klijent/panel.form/IzmenaKandidataForm.java • Klijent/panel.form/LogInPanelForm.java • Klijent/panel.form/PostavljanjeKandidataZaIzborPanelForm.java • Klijent/panel.form/PrikazRezultataPanelForm.java • Klijent/panel.form/UnosGlasacaPanelForm.java • Klijent/panel.form/UnosKandidataPanelForm.java • Klijent/panel.form/UnosIzboraForm.java • Klijent/paneli/CBIzbor.java • Klijent/paneli/CBIzborGrada.java • Klijent/paneli/CBTipIzbora.java • Klijent/paneli/PSSifra.java • Klijent/paneli/TFGodina.java • Klijent/paneli/TFId.java 116

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Klijent/paneli/TFImePrezime.java Klijent/paneli/TFJmbg.java Klijent/paneli/TFSifraGlasaca.java Klijent/paneli/TFStranka.java Klijent/paneli/TFUlicaBroj.java Klijent/projekat.forme.koordinator/KoordinatorForm.java Klijent/rezultati/PrikazRezultataForm.java Klijent/start/PokreniProjekat.java Klijent/validator/ComponentValidator.java Klijent/validator/GodinaValidator.java Klijent/validator/IdValidator.java Klijent/validator/ImePrezimeValidator.java Klijent/validator/JmbgValidator.java Klijent/validator/StrankaValidator.java Klijent/validator/UlicaBrojValidator.java Server/dbkonekcija/DBBroker.java Server/dbkonekcija/KomunikacijaSaBazom.java Server/dbkonekcija/Util.java Server/forma/ServerForm.java Server/kontroler/Kontroler.java Server/nit.klijent/NitObradaKlijenta.java Server/nit.sat/NitSat.java Server/server/KontrolerPoslovneLogike.java Server/so/OpstaSO.java Server/so.izmeni/IzmeniSO.java Server/so.obrisi/ObrisiSO.java Server/so.sacuvaj/SacuvajSO.java Server/so.vrati/VratiSO.java Zajednicki/domen/Glasac.java Zajednicki/domen/Glasanje.java Zajednicki/domen/Grad.java Zajednicki/domen/Izbor.java Zajednicki/domen/Kandidat.java Zajednicki/domen/KandidatIzbor.java Zajednicki/domen/Rezultat.java Zajednicki/domen/TipIzbora.java Zajednicki/domen.opsti/DomenskiObjekat.java Zajednicki/transfer/TransferKlasa.java Zajednicki/util/Konstante.java

117

8. Zaključak U prošlosti se programiranje svodilo na to da programer sedne za računar i odmah počne da kuca kod, a što se u praksi pokazalo kao veoma loše. Bez obzira na to koliko neko bio spretan u programiranju, ukoliko ne sagleda problem koji treba rešiti iz različitih uglova i ne osmisli, analizira i detaljno projektuje korake koje treba sprovesti prilikom pravljenja softvera, on ne može to kvalitetno da odradi. U ovom radu stavljen je akcenat na Larmanovu metodu razvoja softvera, pri čemu programiranje nastaje kao završna faza jasno definisane i precizne metodologije razvoja softvera. Pri razvoju softvera se ne treba dugo zadržavati i detaljno opisivati svaki deo programa, već je potrebno obratiti pažnju na to šta je bitno, odnosno koji delovi softverskog sistema su bitni, i koliko detaljno ih treba grafički i tekstualno predstaviti u zavisnosti od razmatrane faze razvoja softvera. Posebno je bitno da se kvalitetno urade faze kao što su: specifikacija zahteva i analiza slučajeva korišćenja, jer ukoliko se one ne urade kako treba potrebno je stalno se vraćati na te faze i vršiti krupne izmjene u čitavom softveru, što dovodi do prekoračenja predviđenog vremena za razvoj softvera. Takođe, upotreba paterna znatno utiče na skraćivanje vremena razvoja softvera. Paterni obezbedjuju pristup dokazanim metodologijama za rešavanje opštih problema, pomažu u organizovanju koda, omogućavaju bolju modularnost i slabu spregnutost. U ovom radu prikazani su samo neki od paterna koji su korišćeni u razvoju softverskog sistema za glasanje. Činjenica je i da bi u razvoju nekog zahtevnijeg softverskog sistema i broj paterna koji se koriste bili sigurno veći.

118

Literatura 1. Dr Siniša Vlajić: Projektovanje softvera (Skripta), FON, Beograd 2011. 2. Dr Siniša Vlajić: Sofverski paterni (Skripta) , FON, Beograd 2011. 3. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides : Gotova rešenja- elementi objektno orijentisanog softvera, CET, Beograd 2002. 4. Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra : Head First Design Patterns 5. http://en.wikipedia.org/wiki/Design_Patterns

119

Dodatak 1 Abstract Factory public interface Panel { //AbstractFactory public void setIzborPanel(JPanel jpanel); public void setPasswordPanel(JPanel jpanel); } public class LogInPanelForm1 extends javax.swing.JPanel implements Panel{ //ConcreteFactory 1 /** Creates new form LogInPanelForm1*/ public LogInPanelForm1() { initComponents(); } JPanel jmbgPanel; JPanel passwordPanel; JPanel izborPanel; public JPanel getIzborPanel() { return izborPanel; } public void setIzborPanel(JPanel izborPanel) { this.izborPanel = (CBTipIzbora)izborPanel; jPanel1.add(this.izborPanel); } public JPanel getjPanel1() { return jPanel1; } public void setjPanel1(JPanel jPanel1) { this.jPanel1 = jPanel1; } public JPanel getJmbgPanel() { return jmbgPanel; } public void setJmbgPanel(JPanel jmbgPanel) { this.jmbgPanel = jmbgPanel; jPanel1.add(this.jmbgPanel); } public JPanel getPasswordPanel() { return passwordPanel; } public void setPasswordPanel(JPanel passwordPanel) { this.passwordPanel = (PFSifra)passwordPanel; jPanel1.add(this.passwordPanel); 120

} } public class LogInPanelForm2 extends javax.swing.JPanel implements Panel{ //ConcreteFactory 2 /** Creates new form LogInPanelForm2 */ public LogInPanelForm2() { initComponents(); } TFJmbg jmbgPanel; TFSifra passwordPanel; RBTipIzbora izborPanel; public JPanel getIzborPanel() { return izborPanel; } public void setIzborPanel(JPanel izborPanel) { this.izborPanel = (RBTipIzbora)izborPanel; jPanel1.add(this.izborPanel); } public JPanel getjPanel1() { return jPanel1; } public void setjPanel1(JPanel jPanel1) { this.jPanel1 = jPanel1; } public JPanel getJmbgPanel() { return jmbgPanel; } public void setJmbgPanel(JPanel jmbgPanel) { this.jmbgPanel = jmbgPanel; jPanel1.add(this.jmbgPanel); } public JPanel getPasswordPanel() { return passwordPanel; } public void setPasswordPanel(JPanel passwordPanel) { this.passwordPanel =(TFSifra) passwordPanel; jPanel1.add(this.passwordPanel); } } public class FrmAdmin extends javax.swing.JFrame {

//Client

/** Creates new form FrmAdmin */ 121

public FrmAdmin() { initComponents(); } Panel aktivanPanel; public void postaviAktivanPanel(JPanel noviPanel){ if (aktivanPanel!=null) this.remove(aktivanPanel); aktivanPanel = noviPanel; getContentPane().add(aktivanPanel,java.awt.BorderLayout.CENTER); aktivanPanel.setVisible(true); validate(); repaint(); pack(); } private void glasajActionPerformed(java.awt.event.ActionEvent evt) { LogInForm lif=new LogInForm(new panel.form.LogInPanelForm1()); KoordinatorForm.vratiKordinatora().postaviNoviPanel(lif.getLogInPanelForm1()); } } public interface SifraField { //AbstractProductA } public class PFSifra implements SifraField { public PFSifra() { initComponents(); } } public class TFSifra implements SifraField { public CBTipIzbora() { initComponents(); } } public interface TipIzboraField { } public class CBTipIzbora implements TipIzboraField { public CBTipIzbora() { initComponents(); } } public class RBTipIzbora implements TipIzboraField {

//ConcreteProductA1

//ConcreteProductA2

//AbstractProductB

//ConcreteProductB1

//ConcreteProductB2 122

public RBTipIzbora() { initComponents(); } } public class LogInForm { private LogInPanelForm1 logInPanelForm1; private LogInPanelForm2 logInPanelForm2;

public void setLogInPanelForm1(LogInPanelForm1 logInPanelForm1) { this.logInPanelForm1 = logInPanelForm1; } public void setLogInPanelForm2(LogInPanelForm2 logInPanelForm2) { this.logInPanelForm2 = logInPanelForm2; }

public LogInPanelForm1 getLogInPanelForm1() { logInPanelForm.setJmbgPanel(new TFJmbg()); logInPanelForm.setPasswordPanel(new PFSifra()); logInPanelForm.setIzborPanel(new CBIzbor()); return logInPanelForm1; } public LogInPanelForm2 getLogInPanelForm2() { logInPanelForm1.setJmbgPanel(new TFJmbg()); logInPanelForm1.setPasswordPanel(new TFSifra()); logInPanelForm1.setIzborPanel(new RBIzbor()); return logInPanelForm2; } }

123

Dodatak 2 Builder public abstract class PanelForm { //Builder protected Panel panel; public Panel getPanel() { return panel; } public void KreirajPanel() { panel = new Panel(); } public abstract void kreirajPanelSifra(); public abstract void kreirajPanelTipIzbora(); } public class Panel { private JPanel jmbgPanel; private JPanel sifraPanel; private JPanel tipIzboraPanel; } public class LogInForm1 extends PanelForm { //ConcreteBuilder1 private LogInPanelForm logInPanelForm; public LogInForm1(LogInPanelForm logInPanelForm) { this.logInPanelForm = logInPanelForm; } @Override public void kreirajPanelSifra() { logInPanelForm.setPasswordPanel(new PFSifra()); } @Override public void kreirajPanelTipIzbora() { logInPanelForm.setIzborPanel(new CBIzbor()); } @Override public void kreirajPanelJmbg() { logInPanelForm.setJmbgPanel(new TFJmbg()); } @Override public LogInPanelForm getLogInPanelForm() { kreirajPanelJmbg(); kreirajPanelSIfra(); kreirajPanelTipIzbora(); 124

return logInPanelForm; }} public class LogInForm2 extends PanelForm { //ConcreteBuilder2 private LogInPanelForm logInPanelForm; public LogInForm2(LogInPanelForm logInPanelForm) { this.logInPanelForm = logInPanelForm; } @Override public void kreirajPanelSifra() { logInPanelForm.setPasswordPanel(new TFSifra()); } @Override public void kreirajPanelTipIzbora() { logInPanelForm.setIzborPanel(new RBIzbor()); } @Override public void kreirajPanelJmbg() { logInPanelForm.setJmbgPanel(new TFJmbg()); } @Override public LogInPanelForm getLogInPanelForm() { kreirajPanelJmbg(); kreirajPanelSIfra(); kreirajPanelTipIzbora(); return logInPanelForm; } } public class FrmAdmin extends javax.swing.JFrame { //Director private PanelForm panelForm; private void glasajActionPerformed(java.awt.event.ActionEvent evt) { LogInForm1 lif=new LogInForm1(new panel.form.LogInPanelForm()); KoordinatorForm.vratiKordinatora().postaviNoviPanel(lif.getLogInPanelForm()); } }

125

Dodatak 3 Decorator public interface UnosForm { //Component public void setUnosPanelForm(JPanel unosPanelForm); } public class UnosGlasacaForm implements UnosForm { //ConcreteComponent private UnosGlasacaPanelForm unosGlasacaPanelForm; public void setUnosPanelForm(UnosGlasacaPanelForm unosGlasacaPanelForm) { this.unosGlasacaPanelForm = unosGlasacaPanelForm; } public UnosGlasacaForm(UnosGlasacaPanelForm unosGlasacaPanelForm) { this.unosGlasacaPanelForm = unosGlasacaPanelForm; } public UnosGlasacaPanelForm getUnosGlasacaPanelForm() { unosGlasacaPanelForm.setIdPanel(new TFId()); unosGlasacaPanelForm.setImePanel(new TFImePrezime()); unosGlasacaPanelForm.setJmbgPanel(new TFJmbg()); unosGlasacaPanelForm.setSifraGlasacaPanel(new TFSifraGlasaca()); unosGlasacaPanelForm.setUlicaBrojPanel(new TFUlicaBroj()); unosGlasacaPanelForm.setGradPanel(new CBIzborGrada()); return unosGlasacaPanelForm; } } abstract public class UnosKandidataForm implements UnosForm { //Decorator public UnosForm unosForm; public UnosKandidataForm(unosForm unosForm) { this.unosForm = unosForm; } public void setUnosPanelForm(UnosKandidataPanelForm unosKandidataPanelForm) { this.unosKandidataPanelForm = unosKandidataPanelForm; } public UnosKandidataForm(UnosKandidataPanelForm unosKandidataPanelForm) { this.unosKandidataPanelForm = unosKandidataPanelForm; } } public class TFId implements UnosKandidataForm { private UnosKandidataForm unosKandidataForm; public TFId () { initComponents();

//ConcreteDecorator1

126

} public void setUnosPanelForm(UnosKandidataPanelForm unosKandidataPanelForm) { this.unosKandidataPanelForm = unosKandidataPanelForm; } public void setIdPanel(){ unosKandidataPanelForm.setIdPanel(new TFId()); } } public class TFImePrezime implements UnosKandidataForm { //ConcreteDecorator2 private UnosKandidataForm unosKandidataForm; public TFImePrezime () { initComponents(); } public void setUnosPanelForm(UnosKandidataPanelForm unosKandidataPanelForm) { this.unosKandidataPanelForm = unosKandidataPanelForm; } public void setImePrezimePanel(){ unosKandidataPanelForm.setImePrezimePanel(new TFImePrezime()); } } public class TFStranka implements UnosKandidataForm { //ConcreteDecorator3 private UnosKandidataForm unosKandidataForm; public TFStranka () { initComponents(); } public void setUnosPanelForm(UnosKandidataPanelForm unosKandidataPanelForm) { this.unosKandidataPanelForm = unosKandidataPanelForm; } public void setStrankaPanel(){ unosKandidataPanelForm.setStrankaPanel(new TFStranka()); } } public class CBGrad implements UnosKandidataForm { //ConcreteDecorator4 private UnosKandidataForm unosKandidataForm; public CBGrad() { initComponents(); } public void setUnosPanelForm(UnosKandidataPanelForm unosKandidataPanelForm) { this.unosKandidataPanelForm = unosKandidataPanelForm; } public void setCBGrad(){ unosKandidataPanelForm.setCBGradPanel(new CBGrad());}} 127

Dodatak 4 Singleton public class KoordinatorForm { private FrmAdmin glavnaForma; private static KoordinatorForm objekat; private KoordinatorForm() { glavnaForma = new FrmAdmin(); } public void pokreniAplikaciju(int a) { glavnaForma.setVisible(true); if (a == 1) { glavnaForma.iskljuciMeni(); } } public void postaviNoviPanel(JPanel noviPanel) { glavnaForma.postaviAktivanPanel(noviPanel); } public static KoordinatorForm vratiKordinatora() { if (objekat == null) { objekat = new KoordinatorForm(); } return objekat; } }

128

Dodatak 5 Strategy public class TekstPolje{ //Context private ComponentValidator validator; public TekstPolje(ComponentValidator validator) { this.validator = validator; } public int izvrsiValidaciju() { return validator.validate(a, b); } } public interface ComponentValidator { //Strategy public abstract void validate(Object tekst) throws Exception; } public class ImePrezimeValidator implements ComponentValidator{ //ConcreteStrategy1 @Override public void validate(Object tekst) throws Exception { String t=(String) tekst; if (t != null && t.length() != 0){ }else{ throw new Exception("Niste uneli ime i prezime!"); } } public class JmbgValidator implements ComponentValidator{ //ConcreteStrategy2 @Override public void validate(Object tekst) throws Exception { String te=(String) tekst; String t=te.trim(); if (t != null && t.length() != 0){ if(t.length()==13){ for (int i = 0; i < t.length(); i++) { if (Character.isDigit(t.charAt(i))){ System.out.println("Validacija:Polje jmbg ispravno."); } else{ throw new Exception("Jmbg je broj! Proverite kako ste uneli!"); } } }else{ throw new Exception("Maticni broj mora imati 13 cifara!"); 129

} }else{ throw new Exception("Niste uneli maticni broj!"); } } public class IdValidator implements ComponentValidator{ //ConcreteStrategy3 @Override public void validate(Object tekst) throws Exception { String t=(String) tekst; if (t != null && t.length() != 0){ for (int i = 0; i < t.length(); i++) { if (Character.isDigit(t.charAt(i))){ System.out.println("Validacija:Polje id ispravno."); } else{ throw new Exception("ID mora biti broj!"); } } }else{ throw new Exception("Niste uneli ID!"); } } } public class StrankaValidator implements ComponentValidator{ //ConcreteStrategy4 @Override public void validate(Object tekst) throws Exception { String t=(String) tekst; if (t != null && t.length() != 0){ }else{ throw new Exception("Niste uneli stranku!"); } } } public class GodinaValidator implements ComponentValidator{ //ConcreteStrategy5 @Override public void validate(Object tekst) throws Exception { String t=(String) tekst; if (t != null && t.length() != 0){ if(t.length()==4){ for (int i = 0; i < t.length(); i++) { 130

if (Character.isDigit(t.charAt(i))){ System.out.println("Validacija:Polje godina ispravno."); } else{ throw new Exception("Godina mora biti uneta u formi broja!"); } } }else{ throw new Exception("Godina mora imati 4 cifre! Proverite kako ste uneli!"); } }else{ throw new Exception("Niste uneli godinu!"); } } }

131

Dodatak 6 Template public abstract class OpstaSO { public void izvrsiOperaciju(Object obj) throws Exception{ try { zapocniTransakciju(); proveriPreduslov(obj); izvrsiKonkretnuOperaciju(obj); potvrdiTransakciju(); } catch (Exception e){ ponistiTransakciju(); throw new Exception(e.getMessage()); } } private void zapocniTransakciju() throws SQLException, IOException{ KomunikacijaSaBazom.vratiObjekat().pokreniTransakciju(); } protected abstract void proveriPreduslov(Object obj); protected abstract void izvrsiKonkretnuOperaciju(Object obj) throws Exception; private void potvrdiTransakciju() throws SQLException, IOException { KomunikacijaSaBazom.vratiObjekat().potvrdiTransakciju(); } private void ponistiTransakciju() throws SQLException, IOException { KomunikacijaSaBazom.vratiObjekat().ponistiTransakciju(); } } public class SacuvajSO extends OpstaSO{ @Override protected void proveriPreduslov(Object obj) { } @Override protected void izvrsiKonkretnuOperaciju(Object obj) throws Exception { try { //KomunikacijaSaBazom.vratiObjekat().ubaciKandidata((Kandidat) obj); DomenskiObjekat objekat=(DomenskiObjekat) obj; DBBroker.vratiObjekat().sacuvajObjekat(objekat); } catch (Exception ex) { throw new Exception("Cuvanje nije uspesno."); } }} 132

public class IzmeniSO extends OpstaSO{ @Override protected void proveriPreduslov(Object obj) { } @Override protected void izvrsiKonkretnuOperaciju(Object obj) throws Exception { DomenskiObjekat objekat=(DomenskiObjekat) obj; DBBroker.vratiObjekat().izmeniDomenskiObjekat(objekat); } } public class ObrisiSO extends OpstaSO{ @Override protected void proveriPreduslov(Object obj) { } @Override protected void izvrsiKonkretnuOperaciju(Object obj) throws Exception { try { //KomunikacijaSaBazom.vratiObjekat().ubaciKandidata((Kandidat) obj); DomenskiObjekat objekat=(DomenskiObjekat) obj; DBBroker.vratiObjekat().obrisiObjekat(objekat); } catch (Exception ex) { throw new Exception("Brisanje nije uspesno."); } }} public class VratiSO extends OpstaSO{ private List listaVrednosti = new ArrayList(); @Override protected void proveriPreduslov(Object obj) { } @Override protected void izvrsiKonkretnuOperaciju(Object obj) throws Exception { listaVrednosti = DBBroker.vratiObjekat().vratiDomenskeVrednosti((Kandidat)obj); for (DomenskiObjekat d : listaVrednosti) { Kandidat kandidat=(Kandidat) d; Grad grad= (Grad) DBBroker.vratiObjekat().vratiDomenskuVrednost(kandidat.getGrad()); kandidat.setGrad(grad); } } public List vratiListuKandidata(Object o) throws Exception{ izvrsiKonkretnuOperaciju(o); return listaVrednosti; }} 133

Dodatak 7 Facade public class Kontroler { //Facade private static Kontroler kontroler; OpstaSO so; private Kontroler() { } public static Kontroler vratiObjekat() { if (kontroler == null) { kontroler = new Kontroler(); } return kontroler; } public List vratiListuKandidata() throws Exception { so=new VratiSOKandidat(); return so.izvrsiOperaciju(); } public List vratiListuGradova() throws Exception { return KomunikacijaSaBazom.vratiObjekat().vratiSveGradove(); } public void ubaciKandidata(Kandidat k) throws Exception { so=new SacuvajSOKandidat(); so.izvrsiOperaciju(k); } public void obrisiKandidata(Kandidat k) throws Exception { so=new ObrisiSOKandidat(); so.izvrsiOperaciju(k); } public void izmeniKandidata(Kandidat k) throws Exception { so=new IzmeniSOKandidat(); so.izvrsiOperaciju(k); } public void ubaciGlasaca(Glasac glasac) throws Exception { so=new SacuvajSOGlasac(); so.izvrsiOperaciju(glasac); } public void obrisiGlasaca(Glasac glasac) throws Exception { so=new ObrisiSOKandidat(); so.izvrsiOperaciju(glasac); } 134

public void izmeniGlasaca(Glasac glasac) throws Exception { so=new IzmeniSOGlasac(); so.izvrsiOperaciju(glasac); } }

135