Upload
momir-stankovic
View
28
Download
4
Embed Size (px)
Citation preview
SEMINARSKI RADPANEVROPSKI UNIVERZITET APEIRON
FAKULTET INFORMACIONIH TEHNOLOGIJA
Redovne studije
Smer „IT inžinjering”
Predmet
Softverski inženjering sa objektnim programiranjem
„ PISANJE PROGRAMA ”
Predmetni nastavnikProf. dr Zoran Ž. Avramović, dipl.inž.elek.
Student
Milinko Dragović
Index br. 42-10/RPI
Banja Luka, Februar 2014.
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
SADRŽA
JUvod................................................................................................................................3
1. Standardi i procedure programiranja.......................................................................4
1.1 Standardi za vas.................................................................................................4
1.2 Standardi za druge.............................................................................................5
1.3 Uparivanje dizajna sa implementacijom............................................................6
2. Smjernice za programere.........................................................................................6
2.1. Kontrolne strukture............................................................................................7
2.2. Algoritmi............................................................................................................8
2.3. Struktura podataka...........................................................................................10
2.4. Opšte smjernice...............................................................................................13
3. Dokumentacija.......................................................................................................18
3.1. Unutrašnja dokumentacija...............................................................................18
3.2. Spoljna dokumentacija.....................................................................................22
4. Proces programiranja.............................................................................................23
4.1. Programiranje kao rješavanje problema..........................................................23
4.2. Ekstremno programiranje................................................................................25
4.3. Programiranje u parovima...............................................................................25
5. Primjer iz prakse....................................................................................................26
5.1. Kreiranje projekta...............................................................................................26
5.1.1. Provjera da li uređaj hardverski ima lampu.................................................29
5.1.2. Ukljčivanje lampe........................................................................................30
5.1.3. Isključivanje lampe......................................................................................31
Zaključak.......................................................................................................................34
2
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
LITERATURA:.............................................................................................................35
Uvod
U ovom seminarskom radu govoriću o pisanju programa, šta je sve potrebno da bi
nastao jedan softver, o standardima programiranja, smernicama za višekratno korišćenje,
dizajnu kao okviru koda, unutrašnjoj i spoljašnjoj dokumentacij i navešću primjer jedne
aplikacije koja je rađena za Android OS.
Programiranje zahtjeva mnogo kreativnosti. Dizajn predstavlja opis funkcije ili svrhe svake
komponente, ali da programer ima veliku slobodu pri implementiranju dizajna u kod. Dizajn
ili specifikacija zahtjeva može da, bilo neposredno, kao zahtjev projektanta ili kupaca, bilo
posredno, zbog namere da se koriste gotovi djelovi koda, sugeriše korišćenje određenog
programskog jezika. Bez obzira na programski jezik koji se koristi, svaka programska
komponenta uključuje najmanje tri osnovna aspekta: kontrolne strukture, algoritme i
struktrure podataka.
Pisanje programa može izazvati komplikacije iz nekoliko razloga.
Prvo, projektanti možda nisu uzeli u obzir sve specifičnosti platforme i programskog
okruženja; strukture i relacije koje je lako opisati grafikonima i tabelama nije uvijek
jednostavno preslikati u kod.
Drugo, kod moramo pisati tako da bude razumljiv ne samo nama kada mu se vratimo radi
testiranja, već takođe i drugima u toku evolucije sistema.
Treće, moramo iskoristiti prednosti koje poseduju organizacija projekta, struktura podataka i
programski sklopovi, a pri tome kreirati kod koji se može jednostavno ponovno koristiti.
Jasno je da postoji više načina da se implementira isti dizajn, da postoje mnogi jezici i alati, i
nećemo ih moći sve navesti i obraditi. Koristićemo primjer aplikacije koja je rađena u Java
programskom jeziku. Biće prikazani praktični elementi iz domena softverskog inženjerstva.
3
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
1. Standardi i procedure programiranja
Kroz vašu karijeru vjerovatno ćete se susretati sa više različitih softverski projekata i
pisati kod za različita područja primjene, koristeći različite alate i tehnike. Jedan dio
aktivnosti uključivaće i analizu postojećeg koda, bilo da ga treba u potpunosti zamjeniti ili
samo promjeniti, ili ponovo upotrebiti u sklopu druge aplikacije. Zatim, učestvovati u
formalnim i neformalnim pregledima koda koji ste pisali vi ili neko drugi. U samom pisanju
koda obično učestvuje više ljudi i potreban je visok stepen saradnje i koordinacije. Zbog toga,
kod treba da bude takav da ga i drugi mogu shvatiti, ne samo vi koji ste ga pisali, da bi se što
lakše uklopio u njihov dio posla.
Iz tog razloga treba se upoznati sa standardima i procedurama koje važe u određenoj
organizaciji pre nego se počne pisati kod.
1.1 Standardi za vas
Da bi se izbjegle greške prilikom pisanja koda postoje standardi i procedure koje
mogu pomoći.
Neke procedure odnose se na način dokumentovanja koda da bi on bio jasan i da bi mogao
lako da se prati. Takva dokumentacija omogućava lakši rad i preciznost. Standardizova
dokumentacija takođe pomaže pri pronalaženju grešaka i unošenju izmjena, jer pojašnjava
koji dijelovi programa izvršavaju koje funkcije.
Standardi i procedure takođe pomažu pri prevođenju dizajna u kod. Strukturisanjem koda
prema standardima, održava se usklađenost elemenata na nivou dizajna sa elementima na
nivou koda. To za poslijedicu ima lakše implementiranje promjene u kodu koje su poslijedice
promjena u dizajnu. Slično tome, izmjene koda koje su poslijedice promjena u spefikaciji
hardvera ili interfejsa, jednostavno se sprovode i time se značajno smanjuje mogućnost
pojave grešaka.
4
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
1.2 Standardi za druge
Po završetku koda, postoji mogućnost da će ga drugi koristiti na različite načine. Na
primjer, možda će drugi tim vršiti testiranja, ili će druga grupa ljudi integrisati vaš softver sa
drugim programima da bi izradili i testirali podsisteme, a kasnije i cijeli sistem. Čak i kad je
sistem podignut i kada radi, može se javiti potreba za promjenama, bilo zbog neke greške ili
zato što kupac želi da promjeni način na koji sistem obavlja funkcije. Vi možda nećete biti dio
timova za održavanje ili testiranje i zato je bitno da organizujete, formatirate i dokumentujetes
svoj kod tako da drugi mogu lako da razumiju šta on treba da radi i kako to realizuje.
Npr. pretpostavimo da svaki program proizveden u vašoj kompaniji počinje jednim odeljkom
u kojem se opisuju funkcije programa i njegovi interfejsi sa ostalim programima. Početni dio
mogao bi da izgleda ovako:
Ovaj blok komentara informiše čitaoca šta radi kod koji slijedi i daje pregled načina
rešavanja. Nekome ko traži komponente za ponovno korišćenje ovaj blok pruža dovoljno
informacije za donošenje odluke da li je to ono što traži. Nekome ko traži uzrok otkaza ovaj
blok daje dovoljno elemenata za procjenu vjerovatnoće da je razmatrana komponenta direktni
krivac ili možda saučesnik. Programer koji radi na održavanju lakše će pronaći komponentu
koja treba da se promjeni. Kada se pronađe komponenta, ako su imena podataka jasna, a
5
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
interfejsi dobro definisani, programer koji radi na održavanju može da bude siguran da
zahtjevana promjena neće proivesti neočekivane posljedice po druge dijelove koda.
Postoje automatizovani alati za analizu koda i utvrđivanje koje procedure komponenta poziva,
a koje procedure nju pozivaju. Dokumentacija koju ti alati proizvedu ukazuje na komponente
koje mogu pozvati razmatranu procedurui komponente koje ona poziva. Uz takve informacije
relativno je jednostavno vršiti promjene u sistemu.
1.3 Uparivanje dizajna sa implementacijom
Najkritičniji standard se tiče direktne usklađenosti komponenti iz dizajna programa sa
komponentama iz programskog koda. Cijelokupan proces dizajna ništa ne vrijedi ako se
modularnost prisutna u dizajnu ne prenese i na kod. Karakteristike dizajna, kao što su slaba
spregnutost, visoka kohezija i dobro definisani interfejsi trebalo bi da budu i karakteristike
programa, da bi algoritmi funkcije, interfejsi i strukture podataka mogli lako da se prate iz
dizajna u kod i obratno. Npr. pretpostavimo ste u timu koji projektuje računarski upravljanje
displeja za automobile. Siste koji gradite vjerovatno će se uvijek ugrađivati u automobile, ali
meniji i uređaji mogu da se promjene, ili da se dodaju nove mogućnosti. Te promjene se prvo
vrše u sklopu dizajna visokog nivoa, a zatim prosleđuju, kroz niz detalja na nižem nivou
apstrakcije, na kod koji treba promjeniti. Zbog toga uskađenost dizajna i koda je važna.
2. Smjernice za programere
Programiranje zahtjeva mnogo kreativnosti. Dizajn predstavlja opis funkcije ili svrhe
svake komponente, ali da programer ima veliku slobodu pri implementiranju dizajna u kod.
Dizajn ili specifikacija zahtjeva može da, bilo neposredno, kao zahtjev projektanta ili kupaca,
bilo posredno, zbog namere da se koriste gotovi djelovi koda, sugeriše korišćenje određenog
programskog jezika. Bez obzira na programski jezik koji se koristi, svaka programska
komponenta uključuje najmanje tri osnovna aspekta: kontrolne strukture, algoritme i
struktrure podataka.
2.1. Kontrolne strukture
6
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Mnoge kontrolne strukture komponente predložene su na nivou arhitekture i dizajna, i
potrebno ih je očuvati prilikom transformacije dizajna u kod. Kod nekih arhitektura, kao što
su implicitno povezivanje i objektno orijentisani dizajn, kontrola se zasniva na stanjima
sistema i na promjenama vrijednosti promjenjivih. U drugima, koje su više proceduralne,
kontrola zavisi od strukture samog koda. Za svaku vrstu dizajna važno je da struktura
programa održava kontrolne strukture definisane u sklopu dizajna. Onaj ko čita kod ne bi
trebao praviti velike skokove kroz kod da bi našao ono što traži, radi neke izmjene ili
korišćenja koda. Treba da se usresredi na to šta program radi, a ne na tok kontrole. Mnoga
upustva i standardi zahtjevaju da se kod piše tako da komponenta može lako da se pročita,
odozgo nadole.
Jedan primjer kako promjena strukture može da poveća razumljivost. Prenos kontrole u
sklopu programa je skokovit i zato se teško prati.
Isti rezultat možemo postići oslanjajući se na strukturu koja se lakše prati. Preurediti se može
na sledeći način:
Nije uvijek moguće, niti praktično, da tok ide strogo odozgo nadole. Na primjer,
postizanjem uslova završetka petlje može se narušiti tok. Međutim, korisno je da , gdje god je
to moguće, zahtjevana akcija bude neposredno nakon odluke koja je uslovljena. Programsku
komponentu možemo modelarno posmatrati, a zatim koristiti makroe, procedure,
7
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
potprograme, metode i nasleđivanje kao sredstva za skrivanje detalja uz povećanje stepena
razumljivosti. Što je komponenta koda modularnija, lakše će se održavati u ponovo upotrebiti
u drugim aplikacijama. Prilikom pisanja koda bitno je opšto pisati, kod ne bi trebao da bude
specijalizovan više nego što je to neophodno.
Na primjer, komponenta koja u nizu od osamdeset znakova traži tačku, može da se
napiše sa ulaznim parametrima: dužina stringa i znak koji se traži. Tako će komponenta moći
da se upotrebi za pretraživanje niza znakova proizvoljne dužine na bilo koji znak.
Spregnutost i kohezija su još dvije karakteristike dizajna koje se prenose u komponente koda.
Prilikom pisanja programa, treba koristiti imena parametara i komentare koji će iskazati snagu
među komponentama. Na primjer, pisanje komponente za procjenu poreza na dohodak. Ona
koristi iznos bruto prihoda i olakšice koje dobija od drugih komponenti.
Umjesto da kod opišemo kao
Ponovo izračunati POREZ
bolje je da napišemo
Ponovo izračunati POREZ na osnovu vrijednosti BRUTO_PRIHOD i OLAKŠICE
Ovaj drugi komentar objašnjava kako se izračunavanje povezuje sa stavkom podataka iz
drugih komponenti.
Kod treba da omogući čitaocu da prepozna parametre koji se prenose u vašu komponentu i iz
nje. Zavisnost među komponentama mora biti vidljiva. U isto vreme, kao što su komponente
sistema projektovane da međusobno kriju informacije, potkomponente našeg programa bi
trebalo jedna od druge da kriju detalje u vezi sa izračunavanjima. Na primer, u prethodnom
programu za pretraživanje niza znakova, komponenta koja pretražuje tekst mora da poseduje
svijest o načinu traženja navedenog znaka. Ali, komponenta koja je poziva ne mora da zna
kako se znak pronalazi, već samo da je on pronađen i na kojem mjestu se nalazi. To
sakrivanje informacija omogućava promenu algoritma pretraživanja bez uticaja na ostatak
koda.
2.2. Algoritmi
8
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Dizajn programa često definiše klasu algoritama koju treba upotrebiti prilikom
kodiranja komponente. Na primer, dizajn može da nalaže upotrebu algoritma Quicksort, ili
može da navodi logičke korake tog algoritma. Međutim, postoji visok stepen fleksibilnosti u
postupku konvertovanja algoritma u kod, zavisno od ograničenja implementacionog
programskog jezika i hardvera.
Jedna od oblasti u kojoj imamo veliko diskreciono pravo jeste performansa ili efikasnost
implementacije. Instinkt nas moža navoditi da pravimo kod koji će se izvršavati najvećom
mogućom brzinom. Međutim, ubrzavanje koda može da sadrži prikrivene troškove:
• trošak pisanja bržeg koda koji je možda složeniji i zato zahtjeva više vremena za pisanje;
• troškove vremena za testiranje koda čija složenost zahtjeva više primjera za testiranje ili
više test podataka;
• troškove vremena potrebnog da korisnici shvate kod;
• troškove vremena za promjenu koda ako se pojavi potreba.
Prema tome, vrijeme izvršavanja predstavlja samo mali dio u ukupnoj jednačini troškova.
Pitanja vremena izvršavanja treba razmatrati zajedno sa kvalitetom dizajna, standardima i
zahtevima kupca. Posebno je važno obratiti pažnju na jasnoću i ispravnost radi brzine. Ako je
brzina značajna za našu implementaciju, moramo da proučimo na koji način prevodilac
oplimizuje kod. U protivnom se može dogoditi da optimizacija uspori naizgled brži kod. Da bi
smo videli kako može doći do tog paradoksa, pretpostavićemo da pišete kod za
implementaciju trodimenzionalnog niza. U cilju povećanja efikasnosti, umesto
trodimenzionalne, koristimo jednodimenzionalnu matricu i sami izračunamo indeks. Na
osnovu toga, u kodu se javljaju promenljive, kao na primjer:
index = 3*i + 2*j + k;
za izračunavanje položaja elemenata trodimenzionalnog niza.
9
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Međutim, možda prevodilac, da bi skratio vrijeme izvršavanja, za indeksiranje niza koristi
registre. Ako se prevodilac oslanja na tehniku automatskog inkrementiranja registara a ne na
izračunavanje svake pozicije množenjem i sabiranjem, korišćenje jednodimenzionalnog niza i
izračunavanje indeksa produžavaju vrijeme izvršavanja.
2.3. Struktura podataka
Prilikom pisanja programa podatke bi trebalo da formatiramo i čuvamo na takav način
da se njima jednostavno upravlja. Postoji nekoliko tehnikaa u kojima se organizacija
programa prilagođava strukturi podataka.
Očuvanje jednostavnosti programa. Ponekad su u dizajnu programa definisane strukture
podataka koje treba koristiti za implementaciju funkcija. Često se te strukture biraju zato što
se uklapaju u sveukupnu šemu sakrivanja informacija i kontrole interfejsa komponenti.
Manipulisanje podacima unutar komponente može da, na sličan način, utiče na izbor
strukture podataka. Na primer, ponovno strukturisanje podataka može da uprosti
izračunavanje u programu. Da bi to bilo jasnije, pisaćemo program za izračunavanje visine
saveznog poreza na dohodak. Na ulazu dobijamo određeni iznos oporezivog dohotka i
slijedeća pravila:
1. Za prvih 10.000 dolara dohotka porez iznosi 10%.
2. Za sledećih 10.000 dolara dohotka iznad 10.000 dolara porez iznosi 12%.
3. Za sledećih 10.000 dolara dohotka iznad 20.000 dolara porez iznosi 15%.
4. Za sledećih 10.000 dolara dohotka iznad 30.000 dolara porez iznosi 18%.
5. Za svaki dohodak iznad 40.000 dolara porez iznosi 20%.
Znači da neko sa oporezivim dohotkom od 35.000 dolara plaća 10% od prvh 10.000 dolara (ili
1.000 dolara), 12% od slijedećih 10.000 dolara ( ili 1.200 dolara) , 15% od slijedećih 10.000
dolara ( ili 1.500 dolara) i 18% od preostalih 5.000 dolara ( ili 900 dolara) što ukupno iznosi
4.600 dolara. Za izračunavanje tog poreza možemo u našu komponentu da ubacimo kod koji
učitava oporezivi dohodak i zatim primjenjuje sledeći algoritam:
10
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Može se definisati tabela poreza u kojoj za svaki interval imamo osnovni iznos i procenat.
Korišćenje struktura podataka za utvrđivanje strukture programa. U primjeru sa
tabelom poreza, način definisanja podataka diktira način na koji se vrši izračunavanje. U
opštem slučaju, strukture podataka mogu da utiču na organizaciju i tok programa. U nekim
slučajevima struktura podataka može da utiče i na izbor jezika. NA primjer LISP, je
projektovan za obradu listi i sadrži strukture koje ga čine primerenijim od drugih jezika kada
treba obrađivati liste. Slično tome, Ada i Eiffel sadrže sklopove za obradu nedozvoljenih
stanja, koja nazivamo izuzeci. Za strukturu podataka se kaže da je rekurzivna ako se definiše
pomoću jednog po-četnog elementa, a svi slijedeći elementi se izvode kao funkcije prethodno
11
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
definisanih. Na primer, stablo sa korjenom je graf sastavljen od čvorova i grana i koji
zadovoljava slijedeće uslove:
1. Samo jedan čvor u stablu predstavlja korjen.
2. Ako se izbrišu grane koje polaze iz korjena, dobija se graf koji se sastoji od skupa grafova
koji se ne sjeku i od kojih svaki predstavlja stablo sa korjenom.
Na slikama prikazano je stablo sa korjenom i stablo kako se uklanjanjem korjena proizvodi
skup manjih stabala. Korjen svakog manjeg stabla je čvor koji je prethodno bio povezan sa
prvobitnim korjenom većeg stabla. Prema tome, stablo sa korjenom definiše se u smislu
korjena i podstabala: to je rekurzivna definicija.
12
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Programski jezici kao što je Pascal dozvoljavaju da rekurzivne procedure obrađuju rekurzivne
strukture podataka. Možda će nam za ovu vrstu podataka bolje odgovarati rekurzivne
procedure pošto se njihovim korišćenjem teret upravljanja strukturom podataka prenosi sa
programa na prevodioca. Tako će programiranje biti lakše i program će se lakše razumjevati.
Prema tome, u opštem slučaju bi trebalo pažljivo razmotriti strukture podataka pri odlučivanju
na kom programskom jeziku će se implernendrati dizajn.
2.4. Opšte smjernice
Da bi se u našem kodu očuvao kvalitet dizajna, korisno je da budemo upoznati sa
nekoliko opštih strategija.
Lokalizovanje ulaza i izlaza.
Djelovi programa koji učitavaju ulaz ili stvaraju izlaz veoma su specijalizovani i moraju da
odražavaju karakteristike osnovnog hardvera i softvera. Zbog te zavisnosti, ponekad je teško
testirati djelove programa koji obavljaju ulazne i izlazne funkcije. U stvari, to su djelovi koji
će se najvjerovatnije mjenjati ako se promjene hardver ili softver. Prema tome, poželjno je da
u komponentama ti djelovi budu odvojeni od ostatka koda. Dodatna prednost lokalizacije je
uopštavanje cjelog sistema. U specijalizovanu komponentu mogu da se uključe i druge opšte
funkcije koje treba obaviti nad ulaznim podacima (kao što je formatiranje i provera tipa) tako
da se ostale komponente rasterećuju i time eliminišu ponavljanja. Slično tome, stavljanjem
izlaznih funkcija na jedno mjesto dobija se sistem koji se lakše shvata i mjenja.
Uključivanje pseudokoda.
Obično se u fazi dizajna postavlja okvir za svaku programsku komponentu. Zatim se, uz
dodatak individualne kreativnosti i znanja, piše kod kojim se taj dizajn implementira. Na
primjer, dizajn ne mora biti strogo vezan za programski jezik i može da ostavi slobodu izbora
jezičkih sklopova, načina njihove upotrebe, načina predstavljanja podataka itd. Pošto dizajn
postavlja konture onoga što programska komponenta mora da uradi, korisno je da se od
13
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
dizajna ka kodu ide u fazama, a ne da se dizajn odmah prevodi u kod. Za prilagođavanje
dizajna izabranom programskom jeziku može se upotrebiti pseudokod.
Adaptiranjem sklopova i reprezentacija podataka ne ulazeći u specifičnosti svake komande,
možemo da eksperimentišemo i posmatramo koja bi implementacija bila najpogodnija. Na taj
način, kod može da se preuređuje i da mu se mjenja struktura uz minimum dopisivanja.
Na primjer, pretpostavimo da ovako izgleda dizajn jedne komponente sistema za obradu
teksta:
Zavisno od izabranog jezika i programskih skolonisti, dizajn može da se implementira na
mnoge načine. U prvoj fazi koda prevođenje dizajna u kod možda ćemo ispitati u svaku
pojedinačnu vrstu komande da bismo utvrdili šta je sve potrebno za njeno kodiranje. Na
sledeći način bismo mogli, opet pomoću pseudokoda, da napišemo ono što želimo da naš kod
postigne:
14
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Međutim, dodatnim pregledom ovog pseudokoda možda ćemo uočiti da se pojedini koraci
mogu grupisati tako da neke zajedničke funkcije budu jedna uz drugu:
Nakon što smo opisali komande na ovaj način, primetićemo da se grupa radnji FIRST i
THIRD odnosi na istu vrstu komande. Osim toga, pokazivač reda zavisi od leve margine u
15
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
svim slučajevima, osim ako je komanda PARAGRAPH. Koristeći to, pseudokod možemo
napisati na sledeči način:
Na kraju, kod za implementaciju dizajna:
16
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Prema tome, pseudokod je poslužio kao radni okvir za konstruisanje koda. Organizacija
dizajna se nekoliko puta promjenila prilikom izvođenja koda iz dizajna na opisani način.
Takve promjene treba prijaviti projektantima i od njih dobiti saglasnost, da bi se
dokumentovale i održavale veze između zahtjeva, dizajna i koda.
Pre nego što upotrebimo postojeću komponentu unutar nekog projekta, treba provjeriti četiri
ključne karakteristike:
1. Da li komponenta izvršava funkciju ili pribavlja podatke koji su nam potrebni?
2. Ako je potrebna mala izmjena, da li je manje potrebno za promjenu ili za izgradnju
komponente od nule?
3. Da li je komponenta dobro dokumentovana tako da se može potpuno razumjeti bez
potrebe da se verifikuje cjelokupna implementacija?
4. Postoji li potpuna evidencija o testiranju i revizijama komponente tako da možemo biti
sigurni da u njoj nema grešaka?
Takođe, moramo da procjenimo koliko koda treba napisati da bi naš sistem mogao da sarađuje
sa višekratno upotrebljivim komponentama.
S druge strane, ako smo proizvođač višekratno upotrebljivih komponenti, trebalo bi da imamo
na umu nekoliko stvari:
17
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Neka komponente budu opšte, neka koriste parametre i pretpostvaljaju postojanje
uslova sličnih onima u kojima ih naš sistem poziva;
Razdvojimo djelove prema zavisnostima tako da odvojimo djelove koji su podložni
promjenama, od onih koji će vjerovatno ostati nepromjenjene;
Neka interfejs komponente bude uopšten i dobro definisan;
Uključimo informacije o pronađenim i ispravljenim greškama;
Koristimo jasne konvencije za imenovanje;
Dokumentovanje strukture podataka i algoritme;
Neka djelovi za komunikaciju i za obradu grešaka budu razdvojeni i laki za mjenjanje.
3. Dokumentacija
Mnogi korporacijski standardi i procedure stavljaju akcenat na opise koji prate skup
programa. Programskom dokumentacijom smatramo skup opisa u pisanoj formi koji
objašnjavaju šta programi rade i kako to postižu. Unutrašnja dokumentacija predstavlja opise
koji se direktno upisuju u kod; sva ostala dokumentacija je spoljašnja dokumentacija.
3.1. Unutrašnja dokumentacija
Unutrašnja dokumentacija sadrži informacije namenjene nekome ko će čitati izvorni
kod programa. Zato se daje kratak pregled za identifikaciju programa i opis njegovih struktura
podataka, algoritama i toka kontrole. Obično se te informacije stavljaju na početak svake
komponente u skup komentara koji nazivamo zaglavlje bloka komentara.
U zaglavlje bloka komentara svake komponente treba unijeti sledeće informacije:
1. naziv komponente;
2. autora komponente;
3. koje je mjesto komponente u cjelokupnom dizajnu sistema;
4. kada je komponenta napisana i revidirana;
5. zašto ta komponenta postoji;
6. kako komponenta koristi svoju strukturu podataka, algoritme i tokove kontrole.
18
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Prvo, ime komponente mora da bude uočljivo u dokumentaciji. Zatim, u bloku treba navesti
autora, njegov broj telefona i adresu e-mail da bi timovi koji rade na održavanju i testiranju
mogli da ga pronađu ako imaju pitanja i komentare. Tokom životnog ciklusa sistema,
komponente se često ažuriraju i revidiraju bilo zbog ispravljanja grešaka, bilo zbog promjena
iii proširenja zahtjeva. Zaglavlje bi takođe trebalo da objasni kako se komponenta poziva.
Za objašnjenje kako komponenta izvršava svoj cilj, potrebne su detaljnije informacije. U
bloku bi trebalo navesti:
Ime, tip i svrhu svake veće strukture podataka i promenljive;
Kratak opis logičkog toka, algoritama i obrade grešaka;
Očekivani ulaz i mogući izlaz;
Pomoćna sredstva za testiranje i kako ih treba koristiti;
Očekivana proširenja ili revizije.
Standardi organizacije obično definišu redosled i sadržaj zaglavlja bloka komentara. Primjer
kako treba da izgleda zaglavlje bloka komentara:
PROGRAM SCAN: Program kojim se u jednom redu teksta traži dati
znak
PROGRAMER: Marko Marković 00 387 66 000 000/[email protected]
POZIVNI NIZ: CALL SCAN (DUŽINA, ZNAK, NTEKST)
gdje je DUŽINA dužina reda koji treba pretražiti;
ZNAK je znak koji se traži. Red teksta se predaje
kao matrica NTEKST.
VERZIJA 1: napisana 14 februara 2014, autor M.Marković
REVIZIJA 1.1: 18 februar 2015, autor M.Marković da se poboljša
algoritam traženja.
SVRHU: Model za pretraživanje opšte svrhe, za pretraživanje bilo
kakvog reda teksta, bez obzira na dužinu. Jedan iz grupe pomoćnih
programa za tekst projektovanih za dodavanje znaka u red teksta,
čitanje jednog znaka, promjenu jednog znaka ili brisanje znaka.
STRUKTURE PODATAKA: Promjenljiva DUŽINA - integer
Promjenljiva ZNAK - characher
Matrica NTEKST - matrica znakova dužine DUŽINA
ALGORITAM: Čitati matricu NTEKST znak po znak; ako se pronađe
ZNAK, mjesto u matrici NTEKST vratiti u promjenljivu
DUŽINA; inače promjenljiva DUŽINA dobija vrijednost 0.
19
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Ostali komentari u programu. Zaglavlje bloka komentara služi kao uvod u naš program, kao
što u knjizi uvod objašnjava njenu namjenu. Dodatni komentari usmjeravaju čitaoca dok čita
vaš program, pomaže mu da shvati kako su u kodu implementirane namjene koje su opisane u
zaglavlju. Ako organizacija koda reflektuje dobro strukturisan dizajn, ako su naredbe jasno
formulisane i ako su oznake, imena promjenljivih i imena podataka opisna i lako
prepoznatljiva, tada će broj dodatnih komentara biti mali. To jest, ako se poštuju jednostavne
preporuke za format i strukturu koda, on će sam po sebi biti izvor informacija.
Komentari imaju svoje mjesto čak i u jasno strukturisanom i dobro napisanom kodu. Mada
jasnoća koda i strukture umanjuje potrebu za dodatnim komentarima, oni su korisni gdje god
se komponenti mogu dodati pomoćne informacije. Bitno je da komentari reflektuju ponašanje
samog koda. Osim toga, treba se potruditi da komentari pruže dodatne informacije, a ne da
opisuju ono što je već očigledno iz našeg dobrog korišćenja labela i imena promjenljivih. Na
primjer, nepotrebno je pisati:
// Povećati i3
i3 = i3 + 1;
kada možemo dodati daleko važniju informaciju ako napišemo
// Podesiti brojač za učitavanje sledećeg znaka
i3 = i3 + 1;
Obično se kodiranje započinje prelaskom sa dizajna na pseudokod, koji zatim obezbeđuje
radni okvir za naš konačni kod i osnovu za komentare. Treba pisati komentare dok pišemo
kod, a ne kasnije, da bismo zabilježili i dizajn u našu namjeru.
Razumljiva imena promjenljivih i oznake naredbi. Za promjenljive i naredbe najbolje je
da biramo imena koja opisuju njihovu ulogu. Ako napišemo
Nedeljna plata = (cijena sata * sati) + (.5) *(cena sata) * (sati – 40.);
Biće čitaocu jasnije nego
Z = (a * b) + (.5) * (a) * (b – 40.);
Ovaj primjer nedeljna plata vjerovatno neće morati da se komentariše i manja je vjerovatnoća
da se u njemu pogriješi.
20
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Tekstualne oznake naredbi bi trebalo da upute čitaoce u to šta označeni dio programa radi.
Ako oznake moraju da budu numeričke, trebale bi da budu u rastućem redoslijedu i grupisane
prema svrsi.
Unapređene razumljivosti pomoću formatiranja.
Format komentara može da pomogne čitaocu da razumije svrhu našeg koda i način na koji se
ta svrha ostvaruje. Uvlačenje i prored naredbi može da objasni i osnovnu strukturu kontrole.
Primjer koda bez uvlačenja:
if (xcoord < ycoord)
Reslut = -1;
elseif (xcoord == ycoord)
if (slope1 > slope2)
Result = 0;
else result = 1;
eleseif (slope1 > slope2)
Result = 2;
elseif (slope1 < slope2)
Result = 3;
Result = 4;
ovo bi moglo da postane mnogo jasnije sa uvlačenjem i razmacima:
if (xcoord < ycoord) reslut = -1;
elseif (xcoord == ycoord)
ef (slope1 > slope2) Result = 0;
else result = 1;
eleseif (slope1 > slope2) Result = 2;
elseif (slope1 < slope2) Result = 3;
else Result = 4;
Osim što se pomoću formatiranja može prikazati struktura kontrole, Weinberg (1971)
preporučuje formatiranje naredbi tako da komentari budu na jednom djelu stranice, a naredbe
na drugom. Na ovaj način možemo da prekrijemo komentare dok testiramo program kako
nam ne bi zavela nepravila dokumentacija. U primjeru, kod može da se čita ako se gleda samo
lijeva strana:
void free_store_empty()
{
21
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
static int i = 0;
if(i++ == 0) // sprečavanje da cerr
// dodeli memoriju
cerr << “Out of memory\n”; // obavjestite korisnika
abort();the // odustati
}
Dokumentovanje podataka. Čitaocima program najteže je da shvate strukturu podatakai
njihovo korišćenje. Mapa podataka je veoma korisna za tumačenje postupaka u kodu, pogotov
kada sistem obrađuje više datoteka različitog tipai namjenu i kada koristi veliki broj
indikatora i parametara. Ta mapa bi trebala da odgovara rečniku podataka iz spoljne
dokumentacije, da bi čitalac mogao da prati manipulisanje podacima, počevši od zahtjeva,
preko dizajna, pa sve do koda.
Objektivno orijentisani dizajn svodi se na minimum ili čak eleminiše neke od ovih problema,
ali ponekad to sakrivanje informacija otežava čitaocu da tačno shvati kako se vrijednost
podatka mjenja. Zbog toga bi unutrašnja dokumentacija trebala da sadrži opise strukture
podataka i njenog korišćenja.
3.2. Spoljna dokumentacija
Dok je unutrašnja dokumentacija koncizna i piše se na nivou koji odgovara
programeru, spoljna dokumentacija je namjenjena i onima koji možda nikad neće čitati sam
kod. Na primjer, projektanti mogu da pregledaju spoljnu dokumentaciju kada razmatraju o
izmjenama i unapređivanjima. Spoljna dokumentacija omogućava da se stvari opširnije
objasne nego što je moguće sa komentarima unutar programa. Ako posmatramo zaglavlje
bloka komentara kao pregled ili rezime našeg programa, onda je spoljna dokumentacija
cjelokupan izvještaj. Ona se bavi istim pitanjima – ko, šta, zašto, kada, gdje i kako – samo iz
perspektive sistema, a ne iz perspektive komponente.
Spoljna dokumentacija komponenti čini dio sveukupne dokumentacije sistema. U trenutku
kada se komponenta piše, veći dio obrazloženja za strukturu i tok komponente već je dataljno
opisan u dokumentima dizajna. Dizajn je okosnica spoljne dokumentacije koja se dopunjava
tekstualnim opisom pojedinosti koda komponente.
Opis problema.
22
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
U prvom djelu dokumentacije koda trebalo bi da se objasne problemi koja komponenta
rješava.
U ovom odeljku se postavlja osnovica za opisivanje razmatranih opcija rješenja i
razloga zbog kojih je izabrano konkretno rješenje. Opis problema nije ponavljanje
dokumentacije zahtjeva, već opšti opis okvira sa objašnjenjem kada se komponenta poziva i
zašto je ona potrebna.
Opis algoritma.
Nakon što smo objasnili zašto komponenta postoji, treba obrazložiti izvor algoritma. Treba
objasniti svaki algoritam koji se koristio u komponenti, uključujući formule, ograničenja i
posebne uslove, pa čak i njihovo izvođenje ili reference na knjigu ili časopis iz kojih su
preuzeti.
Ako za algoritam postoje posebni slučajevi, treba opisati svaki od njih i objasniti kako se on
obrađuje. Ako se neki slučajevi ne obrađuju zato što se ne očekuje njihovo pojavljivanje, onda
treba iznjeti obrazloženje i opisati odgovarajuću obradu grešaka u kodu.
Opis padataka.
U spoljnoj dokumentaciji bi korisnici ili programeri trebali da vide tok podataka na nivou
komponente. Dijagrame toka podataka trebalo bi da prate relativne reference na rječnike
podataka. Kod objektno orjentisanih komponenti bi opšti pregled objekta i klase trebalo da
opiše glavne interakcije objekata.
4. Proces programiranja
U ovom poglavlju opisuju se smjernice, standardi i dokumentacija. Postavlja se
pitanje, kakvu vrstu postupka primjenjuje programer da bi obezbjedio visok kvalitet svoga
koda. Do skora se proces programiranja nije mnogo proučavao. Kako ističu istraživači u
domenu softverskog inženjerstva često polaze od pretpostavke da će na osnovu dobrog
dizajna svaki programer napraviti solidan kod. Ali, dobar kod nije rezultat samo dobrog
dizajna nego i vještine, iskustva i umjeća koji potiču od maštovitosti dobrog rješavanja
problema.
4.1. Programiranje kao rješavanje problema
Pronalaženje dobrog rješenja sastoji se od četiri odvojene faze:
23
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
1. Razumjevanje problema,
2. Smišljanje plana,
3. Izvršavanje plana,
4. Provjera.
Da bismo razumjeli problem, analiziramo sve njegove elemente. Šta je poznato? Šta
nije poznato? Šta se može saznati? Šta se ne može znati? Ova pitanja odnose se i na podatke i
na relacije. Kao što dobar analitičar sistema prikazuje problem u smislu granica sistema
ukazujući na to šta se nalazi unutar granice, a šta je izvan nje, dobar rešavač problema mora
da razumije uslove u kojima problem mora da se rješava. Zatim, pošto definišemo uslove, mi
ispitujemo da li se uslovi mogu zadovoljiti.
Ponekad je problem lakše razumjeti pomoću slike. Programeri to često postižu crtanjem
dijagrama toka, koji pokazuje kako dinamički alocirana struktura podataka mjenja oblik dok
se nad njom vrše različite operacije. Takvo prikazivanje nam pomaže da prepoznamo različite
djelove uslova, a možda čak i da razložimo problem na manje probleme koji se lakše
savladuju. Na neki način, preformulisanje radi boljeg razumjevanja je aktivnost mikrodizajna:
dizajn programa se pažljivo posmatra i reorganizuje u djelove koji se lakše savlađuju nego
prvobitni okvir dizajna.
Zatim se smišlja plan kako da se rješenje izvede od onog što znamo o postojećem problemu.
Kakve su veze između podataka i nepoznatih? Ako veze nisu trenutno vidljive, da li problem
na neki način liči na neke druge poznatije probleme? Ovde razmišljamo o trenutnom
problemu u smislu šablona: postoji li šablon ili skup šablona koji možemo da prilagodimo
našem problemu?
Da bismo pronašli pravilan plan, možemo da isprobamo nekoliko tehnika:
• Prepoznavanje sličnog problema: postoje li podaci, algoritmi, biblioteke ili metodi koji
mogu da se upotrebe za rješavanje našeg problema?
• Preformulisanje problema: koje su ključne definicije? Može li problem da se uopšti ili da se
konkretizuje da bi se lakše savladao? Mogu li se postaviti pretpostavke koje će uprostiti
problem?
• Razlaganje problema: Koji su osnovni elementi problema? Mogu li se podaci grupisati u
kategorije tako da se svaka kategorija obrađuje zasebno?
Perkins (2001) predlaže grupnu diskusiju za traženje rješenja, da bi se postigao efekat koji on
naziva „eureka": prepoznavanje najboljeg rješenja. On predlaže posmatranje više različitih
24
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
mogućnosti, proširivanje misli i razmatranje čak i nemogućih scenarija. Treba takođe tražiti
suptilne znakove koji upozoravaju na anomalije - razloge zbog kojih neko od mogućih
rješenja ne bi funkcionisalo. Osim preuređivanja problema, Perkins predlaže „promjenu
usmjerenja" sa trenutnih fiksacija, ispitivanjem svake pretpostavke i stava. On savjetuje da
posmatramo kreativnost kao uzvišeni oblik dovođenja svega u pitanje; da koristimo našu
kreativnost kako bismo doveli u pitanje predložena rješenja i pronađemo bolje rješenje za naš
problem.
4.2. Ekstremno programiranje
U ekstremnom programiranju imamo dvije vrste učesnika: kupce i programere. Kupci
predstavljaju korisnike budućeg sistema. U toj ulozi oni izvršavaju sledeće aktivnosti:
• definišu svojstva koja će programeri da implementiraju, koristeći formu scenarija da opišu
način funkcionisanja sistema;
• opisuju detaljne testove koje će izvršavati kada softver bude spreman, kako bi provjerili da
li su scenariji pravilno implementirani;
• dodjeljuju prioritete scenarijima i njihovom testiranju.
Zatim programeri pišu kod kojim implementiraju scenarije i to redosledom kojim su kupci
postavili prioritete. Da bi pomogli kupcima, programeri moraju da procjene koliko će trajati
kodiranje svakog scenarija kako bi kupci mogli da planiraju testove prihvatanja. Planiranje se
vrši za periode od po dvije nedelje i tako se gradi povjerenje između kupaca i programera.
Martin (2000) ističe da se ekstremno programiranje ne svodi samo na ovaj dijalog između
programera i kupaca, već da postoji i dijalog između programera kada rade u parovima: sjede
zajedno za radnom stanicom i sarađuju na izgradnji jednog programa.
4.3. Programiranje u parovima
Koncept programiranja u parovima je jedna od radikalnijih tehnika bržih metoda
razvoja. Kod programiranja u parovima, jedan par programera koristi istu tastaturu, monitor i
miša. Svaki član u tom paru preuzima veoma specifičnu ulogu. Jedna osoba je vozač ili pilot
25
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
koji kontroliše računar i fizički upisuje kod. Druga osoba je navigator koji pregleda vozačev
kod i obezbeđuje povratne informacije. Dva člana takvog tima povremeno mjenjaju uloge.
O programiranju u parovima iznijeta su do sada mnoga različita mišljenja, pa tako neki tvrde
da ono podiže produktivnost i kvalitet. Medutim, dokazi su tanki i često dvosmisleni. Na
primer, Parrish i dr. (2004) izvještavaju o uticaju na produktivnost koji se dobija upotrebom
parova dizajnera. Programeri iz te studije su imali u proseku po deset godina radnog iskustva.
U studiji se saradnja programera mjerila kao stepen do kojeg su parovi programera u istom
danu radili na istom modulu. Parrish i njegove kolege su utvrdili da su „parovi koji su imali
veći stepen istovremenog rada bili značajno manje produktivni i pored toga što su bili iskusni
i obučeni za tu metodologiju. Štaviše, studijom je utvrđeno da parovi nisu bili ništa
produktivniji u radu na kasnijim modulima nego na početnim. Medutim, izveštaji Instituta za
softversko inženjerstvo (SEI) (iz istraživanja o personalnom procesu izrade softvera)
nagoveštavaju da programeri koji koriste tradicionalne metode postaju sve produktivniji i
kvalitetniji kako stiču više prakse. Uz zaključak da parovi koji zajedno rade nisu po prirodi
produktivniji. Parrish i njegove kolege napominju da postoje načini da se prevaziđe prirodno
opadanje produktivnosti do kojeg dolazi u parovima.
Ako stariji iskusan programer daje savjete početniku dok on piše kod, to može biti značajno
iskustvo u učenju.
5. Primjer iz prakse
Prikazaću jedan primjer jednostavne aplikacije, koja je rađena u Java programskom
jeziku namjenjena za Android uređaje. Ovaj program je za uključivanje i isključivanje
uređaja lampe sa jednostavnim dodirom. Aplikacija je testirana na telefonu Sony Xperia S.
Ovaj aplikacija ne sadrži previše složen dizajn. Dizajnirana je u grafičkom programu Adobe
Photoshop. Na slici prikazani su svi folderi i fajlovi aplikacije.
26
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Slika – Pregled datoteke MDLampa
5.1. Kreiranje projekta
Kreiranje novog projekta u Eclipse IDE odlaskom na File ⇒ New ⇒ Android Application
Project. Nazvao sam svoj paket kao com.example.mdlampa; i glavnu klasu kao
MainActivity.java . Otvorio sam AndroidManifest.xml datoteku i dodao potrebne dozvole:
android:screenOrientation="portrait" – ekran će biti samo da bude u portret modu.
android.permission.CAMERA - potreban je za pristup uređaja s kamerom
android.hardware.camera - potreban je za pristup hardvera kamere.
Pregled koda : AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.androidhive.flashlight"
android:versionCode="1"
android:versionName="1.0" >
<uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="17" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-feature android:name="android.hardware.camera" />
<application
27
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
<activity
android:name="com.androidhive.flashlight.MainActivity"
android:label="@string/app_name"
android:screenOrientation="portrait">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
Zatim sam ubacio slike za aplikaciju unutra drawable datoteke. Sliku btn_switch_off.png za
isključivanje lampei btn_switch_on.png za uključivanje lampe. Kreirao sam novi xml fajl pod
nazivom radial_background.xml unutar foldera res ⇒ drwable-hdpi i ubacio sledeći kod za
aplikaciju.
Pregled koda: radial_background.xml
<?xml version="1.0" encoding="UTF-8"?>
<shape xmlns:android="http://schemas.android.com/apk/res/android">
<gradient
android:type="radial"
android:startColor="#343030"
android:endColor="#151515"
android:gradientRadius="300"
android:angle="270"
android:centerY="0.3"/>
</shape>
Otvorio sam acitivity_main.xml, fajl koji je automatski kreiran sa MainActiviy klasom.
Unutar acitivity_main.xml fajla ubacio sam kod za grafički prikaz aplikacije. Prvo je ubačena
gradient pozadina koristeći xml fajl koji smo ranije napravili, radial_backgroud.xml. Nakon
toga ubacili smo slike koje su se nalazile u drawable folderu.
28
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Pregled koda: activity_main.xml
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="@drawable/radial_background"
tools:context=".MainActivity" >
<ImageButton
android:id="@+id/btnSwitch"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_centerHorizontal="true"
android:layout_marginTop="100dip"
android:src="@drawable/btn_switch_on"
android:background="@null"
android:contentDescription="@null"
/>
</RelativeLayout>
U MainActivity klasi ubacili smo odgovarajuće varijable.
public class MainActivity extends Activity {
ImageButton btnSwitch;
private Camera camera;
private boolean isFlashOn;
private boolean hasFlash;
Parameters params;
MediaPlayer mp;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
// Dugme za paljenje lampe
btnSwitch = (ImageButton) findViewById(R.id.btnSwitch);
29
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
5.1.1. Provjera da li uređaj hardverski ima lampu
Jedna od glavnih stvari jeste da li uređaj ima svijetlo tj. lampu. U MainActivity klasi ubačen
je kod koji će prijaviti grešku ukoliko ne bude imao. Iskočiće alert dialog sa porukom i
ugasiće se program nakon izvršavanja naredbe finish().
Pregled koda: MainActivity.java
if (!hasFlash) {
// uredjaj nema lampu(flash)
// Prikazace alert dialog i izace iz programa
AlertDialog alert = new AlertDialog.Builder(MainActivity.this)
.create();
alert.setTitle("Greska");
alert.setMessage("Zao mi je, vas uredjaj nema lampe!");
alert.setButton("OK", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int which) {
// izlazi iz programa
finish();
}
});
alert.show();
return;
}
5.1.2. Ukljčivanje lampe
Uključivanje lampe može se namjestiti u podešavanju kamere blica, prebacivanjem u
FLASH_MODE_TORCH. Naredne dvije funkcije getCamera() i turnOnFlash će omogućiti
pristup lampi, dodavanjem u MainActivity klasi.
Pregled koda: MainActivity.java
/*
* Ukljucivanje kamere
*/
private void getCamera() {
if (camera == null) {
try {
camera = Camera.open();
params = camera.getParameters();
30
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
} catch (RuntimeException e) {
Log.e("Greska na kameri. Greska: ", e.getMessage());
}
}
}
/*
* Ukljucivanje lampe
*/
private void turnOnFlash() {
if (!isFlashOn) {
if (camera == null || params == null) {
return;
}
// akiviranje zvuka
playSound();
params = camera.getParameters();
params.setFlashMode(Parameters.FLASH_MODE_TORCH);
camera.setParameters(params);
camera.startPreview();
isFlashOn = true;
// promjena dugmeta slike
toggleButtonImage();
}
}
5.1.3. Isključivanje lampe
Lampa se može isključiti u podešavanjima flash mod-a u FLASH_MODE_OFF.
Pregled koda: MainActivity.java
/*
* Iskljucivanje lampe
*/
private void turnOffFlash() {
if (isFlashOn) {
if (camera == null || params == null) {
31
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
return;
}
// aktiviranje zvuka
playSound();
params = camera.getParameters();
params.setFlashMode(Parameters.FLASH_MODE_OFF);
camera.setParameters(params);
camera.stopPreview();
isFlashOn = false;
// promjena dugmeta slike
toggleButtonImage();
}
}
Zatim pozvati funkciju:
Pregled koda: MainActivity.java
/*
* Promjena dugmeta lampe on/off
*/
btnSwitch.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
if (isFlashOn) {
// gasenje lampe
turnOffFlash();
} else {
// paljenje lampe
turnOnFlash();
}
}
});
}
Kada korisnik dotakne prekidač na ekranu treba da se promjeni slika, da je isključena ili
uključena lampa. Kod za prebacivanje slika:
/*
32
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
* Aktiviranje zvuka
* aktivira se na on/off dugmeta
* */
private void toggleButtonImage(){
if(isFlashOn){
btnSwitch.setImageResource(R.drawable.btn_switch_on);
}else{
btnSwitch.setImageResource(R.drawable.btn_switch_off);
}
}
Nakon što se kamera upali, kako bi aktivirali lampu, kameru treba ugasiti. Dodavanjem koda
u MainActivity klasu.
In onPause() metod isključivanja lampa ulaskom u background state
In onResume() metod uključivanja lampe ponovnim pokušajem
In onStop() metod isključivanja kamere pozivanjem camera.release() metode
Pregled koda: MainActivity.java
@Override
protected void onDestroy() {
super.onDestroy();
}
@Override
protected void onPause() {
super.onPause();
// gasenje lampe na pauzu
turnOffFlash();
}
@Override
protected void onRestart() {
super.onRestart();
}
@Override
protected void onResume() {
super.onResume();
33
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
// na ponovo vracanje, paljenje lampe
if(hasFlash)
turnOnFlash();
}
@Override
protected void onStart() {
super.onStart();
// prilikom pokretanja lampe get camera params
getCamera();
}
@Override
protected void onStop() {
super.onStop();
// na stop gasenje kamere
if (camera != null) {
camera.release();
camera = null;
}
}
34
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
Slika – Ekrani aplikacije
Zaključak
U ovom seminarskom radu pomenuli i objasnili smo nekoliko smjernica za
implementiranje programa. Prilikom pisanja koda treba imati na umu o standardima i
smjernicama koje postoje u organizaciji, ponovnom korišćenju koda iz drugih projekata,
pisanje koda treba da bude upotrebljivo za ponovno korišćenje u budućim projektima,
korišćenje dizajna niskog nivoa kao početnog radnog okvirai prelaženja od dizajna ka kodu u
nekoliko iteracija, pridruživanje iste strategije za obradu grešaka u cijelom sistemu, korišćenje
dokumentacije unutar programa i spoljne dokumentacije da bi se obasnila organizacija,
podaci, kontrola i funkcija koda, kao i odluke o dizajnu i odlučivanje o jeziku za
implementaciju na osnovu aspekata dizajna.
Postoji više dobrih knjiga sa specijalizovanim savjetima vezanim za implementaciju na bazi
izbora konkretnih programskih jezika.
Za pisanje programa, treba poznavati algoritme. Kada je jednom algoritam gotov pisanje
programa u nekom programskom jeziku je prepisivanje simbola iz dijagrama toka u naredbe
35
MILINKO DRAGOVIĆ SEMINARSKI RAD APEIRON
programskog jezika. Postoje mnogi programski jezici, u seminarskom radu pomenut je Java
programski jezik, zato što je primjer rađen u njemu.
Obično svaki simbol u dijagramu toka predstavlja jednu naredbu u programu. Dijagram toka
bi trebao biti dio svake dobre programske dokumentacije.
Prilikom pisanja koda treba obratiti pažnju na spoljašnu i unutrašnju dokumentaciju kako bi
olakšali i sebi i drugima posao. Takođe treba voditi računa o komentarima unutar koda, kakvi
komentari se stavljaju i gdje.
U primjeru Android aplikacije, pisao sam komentare nakon svake naredbe, označavajući tako
šta koja naredba i funkcija radi. Kod je bio raspoređen tako da je lagan za čitanje, da se čitaoc
može lakše snaći u njemu. Sva dokumentacija je smještena u odgovarajuće foldere radi lakše
navigacije. Za pisanje kvalitetnog programa treba dosta iskustva i znanja.Praksa, samostalni
rad predstavljaju faktor ka bržem i boljem učenju i napredovanju pored škole.
LITERATURA:
- Software Engineering: Theory and Practice , By Forrest Shull and Roseanne Tesoriero
Adrese:
- http://developer.android.com/index.html
- http://www.thenewboston.org
36