milinko dragovic - pisanje programa.docx

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


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


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


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


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


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


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


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


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%.



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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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.


/*

* Ukljucivanje kamere

*/

private void getCamera() {

if (camera == null) {

try {

camera = Camera.open();

params = camera.getParameters();

30


} 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.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.


/*

* Iskljucivanje lampe

*/

private void turnOffFlash() {

if (isFlashOn) {

if (camera == null || params == null) {

31


return;

}

// aktiviranje zvuka

playSound();


params.setFlashMode(Parameters.FLASH_MODE_OFF);

camera.setParameters(params);

camera.stopPreview();

isFlashOn = false;

// promjena dugmeta slike

toggleButtonImage();

}

}

Zatim pozvati funkciju:


/*

* 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


* 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


@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


// 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


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


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

milinko dragovic - pisanje programa.docx

Documents