Vedran Ove Prez

Zahtjevi
Requirements
Literatura:
Somerville, Software Engineering, 8th edition, Chapter 6.
Pressman, Software Engineering: A Practitioner's Approach, 6th edition, Chapter 7.
ta su zahtjevi?
Zajedniko razumijevanje problema
Mogu biti: apstraktan opis usluge ili

ogranienja sistema, ali i matematiki ili
tehniki opis funkcionalnosti
Mogu biti polazna taka za pregovore

oko ugovora
... ali mogu biti i dio samog ugovora
ta je korisniku trebalo...
Korisniki zahtjevi
(User Requirements)
Opis sistema pisan obinim
jezikom, uz dijagrame.
Namijenjen korisniku.
Sistemski zahtjevi
(System Requirements)
Strukturiran dokument sa detaljnim
opisom funkcionalnosti sistema.
Definie ta treba implementirati.
Moe biti dio ugovora.
Funkcionalni zahtjevi
(Functional Requirements)
Opis servisa koje sistem treba da prua,
reakcije na date ulaze i ponaanje u
odreenim situacijama.
Nefunkcionalni zahtjevi
(Non-Functional Requirements)
Ogranienja na servise i funkcionalnosti
kao posljedica: rokova, razvojnog
procesa, koritenih standarda itd.
Primjeri (digitalna biblioteka)

Korisnik moe pretraivati, downloadovati i
tampati knjige. (funkcionalni korisniki)
Za razliite tipove datoteka sistem e

ponuditi odgovarajue preglednike.
(funkcionalni sistemski)
Sistem treba biti lagan za upotrebu iskusnim

korisnicima. (nefunkcionalni korisniki)
Iskusan korisnik treba biti u stanju da u

potpunosti koristi sistem nakon dva sata obuke.
(nefunkcionalni sistemski)
Inenjering zahtjeva
Koraci inenjeringa zahtjeva

1.
2.
3.
4.
5.
6.
Zapoinjanje (inception)
Pribavljanje (elicitation)
Elaboracija
Pregovori
Validacija
Upravljanje (management)
Zapoinjanje (inception)
Inenjer mora objasniti problem
samom sebi
Okvirna feasibility studija (obavlja

klijent)
Prepoznati stakeholders
Uvaiti razliita miljenja
Rezultat je definicija problema i

razumijevanje problemskog domena
Pribavljanje (elicitation)
Kolaboracija u malim timovima
Dugotrajan proces...
Korisniki scenariji a.k.a sluajevi

upotrebe
Prvobitni demonstracioni prototip

(rapidno prototipiranje)
Izlaz: okvirni spisak zahtjeva,

neprecizno sroenih
Pribavljanje problemi!
U idealnom svijetu razgovarate sa
kljunom osobom (stakeholderom), u
stvarnosti...
Korisnik nema informacije!

Korisnik nema ovlasti!
Korisnik nema interesa!
Elaboracija
Izrada modela sistema
Dijagrami sluajeva upotrebe (usecase)
Dijagrami aktivnosti (activity)
Dijagrami stanja (state)
Funkcionalni prototipi
Primjena analitikih ablona

(patterns)
Pregovori
...
Validacija
1.
2.
3.
4.
5.
6.
7.
Konzistentnost sa ciljevima
Nivo apstrakcije
Neophodnost
Ogranienja i dvosmislenosti
Porijeklo
Konflikti izmeu zahtjeva
Ostvarivost
Validacija [2]
8. Testabilnost
9. Informacije, funkcija i ponaanje
sistema
10. Organizacija i particionisanje
11. Primjena analitikih ablona
Upravljanje zahtjevima
Izmjene nad zahtjevima
Traje tokom itavog ivotnog

ciklusa
Dokument specifikacije
IEEE 830-1998 standard

Naslovna strana
Sadraj
Historija revizija
1. Uvod
1.1. Svrha dokumenta

1.2. Opseg (scope) dokumenta
1.3. Standardi dokumentovanja
1.4. Akronimi i definicije
1.5. Reference
2. Opis
2.1. Perspektiva proizvoda - ta ovaj projekat
predstavlja za korisnika? Da li je samostalan ili dio veeg
sistema? Osnovni pregled interfejsa (npr. korisnikog).
Konceptualni dijagram.
IEEE 830-1998 standard str. 2

2.2. Funkcionalnosti proizvoda - Saeti pregled
mogunosti proizvoda na visokom nivou. Dijagrami toka.
Nadovezati se na poslovne procese koje podravaju.
2.3. Karakteristike korisnika - Opte karakteristike koje
utiu na SRS: nivoi iskustva, tehnika ekspertiza,
operaciono okruenje
2.4. Ogranienja - Zakonska regulativa. Ogranienja
hardvera i softvera. Vanjski interfejsi (npr. prema drugim
sistemima). Zahtjevi revizije. Komunikacijski protokoli.
Zahtjevi kritinosti ili real-time zahtjevi. Operacioni zahtjevi.
2.5. Pretpostavke i zavisnosti - Ako ove pretpostavke
nisu ispunjene SRS e se morati mijenjati. Npr. dostupnost
hardvera, ponaanje i interfejsi drugih sistema itd.
2.6. Planiranje zahtjeva - Koji zahtjevi e biti
specificirani kasnije (i kada). Procedura za promjenu
zahtjeva.
IEEE 830-1998 standard str. 3

3. Konkretni zahtjevi
3.1. Vanjski interfejsi - Korisniki, hardverski, softverski
(API, formati datoteka), komunikacijski.
3.2. Funkcionalni zahtjevi - Trebaju biti grupisani po
nekim logikim kategorijama radi lakeg itanja.
3.3. Nefunkcionalni zahtjevi - Atributi performansi,
sigurnosti, zatite...
3.4. Atributi kvalitete softvera
Prilozi
http://www.cs.purdue.edu/homes/apm/courses/BITSC461fall03/miller-guidelines/IEEE830-1998.html
Revision
Control
Literatura:
Fitzpatrick, Pilato, Version Control with Subversion, http://svnbook.red-bean.com
Somerville, Software Engineering, 8th edition, Chapter 29.
Pressman, Software Engineering: A Practitioner's Approach, 6th edition, Chapter 27.
Kontrola revizija
Omoguuje istovremeni rad vie ljudi
na istom kodu
Istovremeni razvoj vie varijanti

softvera
ta je isporueno kojem klijentu?
Prosljeivanje krivnje: tano se zna:

ko, kad, kako, zato...
Repozitorij
neto kao file server, ali:

prati istoriju izmjena svake
datoteke
omoguuje istovremeni rad
vie korisnika
Historijat
rcs (revision control system)
cvs (concurrent versioning
system)
svn (subversion)
...
rcs i cvs: svaka datoteka ima

svoju verziju
vs.
svn: verzija kompletnog koda
Copy-Modify-Merge model
1. Preuzmi kod - checkout (pravi se lokalna
kopija)
2. Napravi izmjene na lokalnoj kopiji
3. Poalji izmjene na server - commit
3a. Ako se u meuvremenu neto
promijenilo na serveru: konflikt! Razrijei
runo
Copy-Modify-Merge - primjer:
Verzija na serveru je 7.18

1. Ahmed preuzima verziju 7.18 sa servera, pravi lokalnu
kopiju
2. Branko preuzima verziju 7.18 sa servera, pravi lokalnu
kopiju
3. Branko alje modifikovanu verziju 7.18B na server - ona
postaje 7.19
4. Ahmed pokuava poslati svoju verziju 7.18A, ali dobija
poruku da najprije mora napraviti update na verziju 7.19
Mogue solucije: a) Ahmed odustaje od promjene b)
Branko odustaje od promjene c) Ahmed runo spaja 7.18A sa
7.19 i alje ovu verziju kao 7.20.
Subversion - pojmovi
trunk - glavno radno stablo (npr. verzija 4.0
alpha, nightly builds)
branch - grana koja se razvija odvojeno od
trunk stabla (npr. verzije 3.2.x, 3.1.x ...,
feature branch)
merge - spajanje: branch -> trunk ili
trunk->branch
Subversion - pojmovi [2]

tag - oznaka koja daje ime odreenom
statusu repozitorija (npr. izdanje 3.2.0,
3.2.1 ...)
revision - stanje kompletnog repozitorija u
datom trenutku vremena (npr. r13854),
nastaje nakon svakog commita
diff - linije koda koje su promijenjene
commit log - vid dokumentacije, kao i
komentari! obavezno koristiti!
trunk
branch
tag
branch
Subversion - osnovne naredbe

svn checkout REPO DIR - preuzmi
repozitorij REPO u direktorij DIR
svn update - auriraj repozitorij
svn commit - poalji izmjene na repozitorij
svn add FAJL - dodaj fajl na repozitorij
(bie poslan prilikom sljedeeg commita)
svn delete FAJL - analogno
svn diff REV - pregled izmjena u reviziji
Klasini RC: klijent server model

vs.
Distribuirani RC: peer-to-peer model
(svaki korisnik je praktino server,
svaki checkout je fork)
Distribuirani RC
Bazaar (Ubuntu)
Git (Linux)
Mercurial (Mozilla i dr.)
Budunost?
Vie o Subversion
http://svnbook.red-bean.com/
TortoiseSVN klijent:
http://tortoisesvn.tigris.org/
URL repozitorija na Forge:
http://f.etf.unsa.ba/svn/si2011-timX
gdje je X redni broj tima
TortoiseSVN
Bug tracking
ili
Issue tracking
ili
Request management
ili
Change management
ili
...
Change management
Potrebno dokumentovati svaki zahtjev
za promjenom
Porijeklo zahtjeva: eksterni (korisnik)

ili interni (drugi tim ili odjel)
Praenje procedure rjeavanja (ko

koi zahtjev!?)
ivotni ciklus zahtjeva

Novi zahtjev
Potvren
Odbijen
Odobren
Nije odobren
Rijeen
Nerjeiv
Provjeren
ivotni ciklus zahtjeva

Potvren/Odbijen - Da li zahtjev ima smisla? Da li
je dostavljen u skladu s procedurom?
Odobren/Nije odobren - Da li je zahtjev u skladu sa
SRS dokumentom i projektnim planom? Da li je
izmjena SRS dokumenta obostrano prihvaena?
Nerjeiv - Moe se naknadno pokazati da je
tehniki nemogue usvojiti zahtjev.
Potvren - Da li se sve strane slau da je zahtjev
rijeen na odgovarajui nain?
Nije rijeen - status ne postoji :)
ETF Forge, sekcija Issues
ETF Forge, sekcija Issues

Moe se koristiti i za planiranje
Tracker: Bug, Feature (zahtjev), Support
Subject: Naslov zahtjeva (4-5 rijei)
Description: Opis zahtjeva
Status: (vidjeti ivotni ciklus)
Priority: planiranje prioriteta zahtjeva
Assigned To: ko e rijeiti zahtjev
Start, Due date: datum poetka i kraja rada na

ispunjavanju zahtjeva
ETF Forge, sekcija Issues [2]

Estimated time: vrijeme uloeno u rjeavanje
zahtjeva
% Done: koliko je procentualno uraeno?
Files: prilog (attachment)
Watchers: ko e sve biti informisan o promjeni

statusa (osim Assigned To)
Mogue je zadati ciljnu verziju kreiranjem

verzija softvera pod Settings / Versions
Softversko
Prototipiranje
(beta verzija prezentacije)
Literatura:
Somerville, Software Engineering, Chapter 17.
Google.
Prototip != alfa verzija
Softverski prototip
Nepotpuna varijanta sistema koja se koristi
za demonstraciju koncepata i isprobavanje
dizajn opcija
Koristi se u: inenjeringu zahtjeva, procesu

dizajna UI, procesu testiranja
Prototip se treba odbaciti nakon razvoja jer

nije dobra osnova za radni sistem
Zato odbacujemo prototip?

Nemogue primijeniti nefunkcionalne
zahtjeve!
Nije dokumentovan!
Rapidan razvoj degradira strukturu

prototipa!
Ne zadovoljava standarde kvalitete!
Softver se pie dvaput
Vrste prototipa (1)
Horizontalni prototip
(to vie funkcija)
Vertikalni prototip
(jedna ili par funkcija detaljno)
Vrste prototipa (2)
Vizualni prototip
(interaktivna animacija)
Funkcionalni prototip
(sadri sve funkcije, ali nepotpune)
Prototipanje
Prototip kao dio ivotnog
ciklusa razvoja softvera
(npr. u inkrementalnom ili agilnom

razvoju softvera)
Rapidno prototipiranje
(prototip se odbacuje)
Rapidno prototipiranje
Porijeklo iz industrije (3D tampanje)
Razvoj vizuelnog prototipa u RAD alatu kao to

je VisualBasic
Problemi: teko koordinirati timski rad,

nepostojanje arhitekture sistema, teko
odravanje
COTS (Common Off-The-Shelf Systems) rekonfigurisati postojee komponente
Aktivni dokumenti
Jezici, Biblioteke
Toolkits, Frameworks
Platforms
Literatura:
McConnell, Code Complete, Chapter 4.
Koji programski jezik izabrati?

Studija Cocomo II (2000.) pokazuje da je prosjean
programer 30% produktivniji u jeziku koji koristi tri ili
vie godina nego u novom jeziku.
Generalno, jezici vieg-nivoa omoguuju veu

produktivnost programera i bolju kvalitetu koda.
Koriteni jezik utie na nain razmiljanja i

programiranja.
Koji programski jezik izabrati?

Jedna linija koda u jeziku je ekvivalentna X linija koda u
C-u:
Programski jezik
Nivo u odnosu na C
C
C++
Fortran
Java
Perl
Python
Smalltalk
MS VisualBasic
1
2,5
2
2,5
6
6
6
4,5
Programske paradigme
imperativno programiranje
struktuirano programiranje
objektno-orjentisano programiranje
deklarativno programiranje
funkcionalno programiranje
logiko programiranje
agent-oriented, aspect-oriented, event-driven itd.
Ada
programski jezik baziran na Pascalu

koristi se u vojnim aplikacijama (US DoD)
striktna kontrola tipova i prava pristupa
provjerljivi programi
dobila ime po Adi Lovelace, prvom programeru
Asembler
jezik niskog nivoa u kojem naredbe odgovaraju

mainskim instrukcijama
specifian za datu procesorsku arhitekturu npr. Intel

x86, Motorola, ARM, MIPS...
koristi se samo kada treba dosegnuti limite brzine

izvrenja ili veliine izvrnog koda
BASIC
jezik za uenje programiranja, nastao 1964
Go To Statement Considered Harmful, Edsger Dijkstra
Microsoft ga uinio popularnim (i obrnuto)
VisualBasic - dodato struktuirano programiranje, OOP
VB for Applications (VBA) - omoguuje skripting raznih

aplikacija (npr. MS Office)
ASP - razvoj web stranica u jeziku VBScript (npr.)
VB.NET - moderan, moan programski jezik
jezik srednjeg nivoa, nastao 1972, autor Dennis Ritchie

usko povezan sa razvojem UNIX operativnih sistema
zovu ga portabilni asembler
de facto standardni jezik 80tih godina
danas uglavnom za sistemske i embedded aplikacije
C++
nastao 1983 kako bi se Cu dodala objektna orijentacija
autor Bjarne Stroustrup
skoro potpuno kompatibilan sa C-om, ali dodaje OOP,

izuzetke, templates, te monu standardnu biblioteku
90tih godina veliki broj poslovnih aplikacija

razvijeno u C++u, danas uglavnom sistemski software
C#
kombinuje osobine C++ i Java
nastao 1999. u Microsoft laboratorijama, voa tima

Anders Hejlsberg (raniji arhitekta Delphi-ja)
usko vezan za .NET platformu
Mono - opensource implementacija C# - kompatibilna

sa jezikom ali ne i (potpuno) sa bibliotekom (npr. Forms)
COBOL
nastao 1959-1961, imitira engleski jezik

previe rjeit
Adobe Flash
dodaje multimedijalne mogunosti web stranicama
nastao 1996, stekao popularnost zbog neadkevatnosti

Java appleta
ActionScript - moan jezik na bazi JavaScript
Flash Video - format sa mogunou ugradnje u web

stranice (npr. YouTube)
FORTRAN
prvi jezik visokog nivoa, nastao 1953-1957

i danas se koristi za naune primjene (zbog brzine)
Java
nastao 1995 kao dio Java platforme
slian C++u uz dosljedniju primjenu OOP
pisan da bi bio portabilan
applet - program ugraen u drugu aplikaciju npr. web

browser (tipino dio web stranice)
servlet - komponenta koja proiruje mogunosti web

servera
Java Server Pages - dinamike web aplikacije
JavaScript
ispravan naziv: ECMAScript
jezik za razvoj interaktivnih web stranica, izvrava se u

web browseru
praktino razvijen u firmi Netscape
sve popularniji za skripting (npr. OpenOffice)
Lisp
nastao 1958, funkcionalni jezik inspirisan Lambda
kalkulusom
popularan u vjetakoj inteligenciji i skripting-u
osnovna struktura je lista
Pascal
imperativni i proceduralni jezik koji promovie dobre

programerske prakse (strukturirano programiranje)
autor Niklaus Wirth, 1968/69
uvijek prisutan u koli/fakultetu, ali slabo u praksi
ObjectPascal - OOP proirenje Pascala, najpoznatija

implementacija je Delphi
Perl
skripting jezik za UNIX orjentisan na analizu teksta i
izvjetaje
autor Larry Wall, lingvista, 1987
poznat po teko itljivom (ali saetom) kodu
popularna implementacija regularnih izraza (regex)
90tih godina se esto koristio za razvoj web aplikacija
PHP
jezik za razvoj web aplikacija, glavna inspiracija Perl
omoguuje jednostavno kombinovanje PHP, HTML,

JavaScript i SQL
autor Rasmus Leerdorf, 1995
nema formalnu specifikaciju, esto kritikovan zbog

nesigurnosti (koja je vremenom dosta unaprijeena)
Python
vie-paradigmatini jezik, naglasak na itljivosti koda
autor Guido van Rossum, 1999
koristi whitespace za oznaku blokova
popularan kao skriptni jezik (RedHat i Ubuntu instaler),

jezik za web aplikacije (Plone, Trac, YouTube), GUI
aplikacije (BitTorrent, Morpheus, Mercurial) i sloenije
Ruby
slian Pythonu i Perlu
ciljevi: programiranje treba biti zabavno! zadovoljava

potrebe ljudi, a ne maina; popularan meu Apple fanovima
autor Yukishiro Matsumoto, 1993/1996
Ruby on Rails - popularna platforma za vrlo brz razvoj

web aplikacija (npr. Redmine)
SmallTalk
najdosljedniji objektno-orjentisani jezik, popularan u
akademiji
nastao 70tih godina
jedno od prvih razvojnih okruenja (IDE)
SQL
Structured Query Language, primjer deklarativnog jezika
Popularnost programskih jezika

Kako izmjeriti popularnost jezika?
ta znai popularan jezik?
Da li je Google / Yahoo / Bing!? pretraga mjerilo
popularnosti
Google Trends
Broj prodatih knjiga - O'Reilly
Open-source projekti - Freshmeat
Poslovi - Craigslist
Analiza komercijalnog softvera

...
nije nam dostupno, plaa se
Kombinovano - Tiobe
Kombinovano - Tiobe trends
Koji je najbolji programski jezik?
Google Go ?
Visual F# ?
Haskell ?
D?
SmallTalk ?
Scala ?
....
Biblioteka
Skup podprograma ili klasa koji se koriste pri razvoju
softvera.
Razvoj biblioteka je najpouzdaniji pristup za ponovnu
upotrebu koda (code reuse) i kao takav je jedan od
temeljnih principa struktuiranog programiranja.
Toolkit
Biblioteka koja sadri elemente grafikog interfejsa
kao to su dugme, prozor itd. (widgets). Primjeri:
Gimp Toolkit (gtk), Fast Light ToolKit (fltk), Google
Web Toolkit (GWT), Xt (X toolkit), Standard Widget
Toolkit (SWT)
Okvir (framework)
Sveobuhvatna biblioteka koja svojim dizajnom
namee odreeni pristup dizajnu aplikacije i na taj
nain proiruje sam programski jezik.
Framework moe biti dostupan za vie jezika i time
olakati tranziciju sa jednog jezika na drugi.
(Softverska) platforma
Framework koji apstrahuje hardversku platformu, tako
da se aplikacije vie ne razvijaju za hardversku nego
za softversku platformu.
Na softverskoj platformi se implementiraju razni jezici
Toolkits
Kao primjer, napraviemo usporedbu toolkits za Javu:
AWT (Abstract Window Toolkit)
apstrakcija grafikih mogunosti svih platformi na

kojima se Java izvrava
direktno poziva kod platforme => dobre

performanse
ponuene mogunosti najmanji zajedniki

sadralac svih platformi => siromaan toolkit
izgled nije ba isti na svim platformama
generalno runo izgleda, ak i na Windowsu
Toolkits
Swing
uveden u Java 1.2 (a.k.a. 2.0)
koristi Java2D primitive (osnovni oblici - linija,

pravougaonik...) za crtanje widgeta
performanse slabije od AWTa
izgled aplikacije identian

na svim platformama, ali se
ne uklapa dobro u platformu
skinnable, ljepe izgleda

od AWTa
danas praktino niko ne

koristi AWT
Toolkits
SWT (Standard Window Toolkit)
kompromis izmeu AWT i Swing
koristi native widgets platforme, ali pri tome ne

nudi podskup mogunosti; umjesto toga, osobine
koje platforma ne podrava su implementirane preko
Java2D primitiva (kao Swing)
rezultat: komforan API nalik na Swing, solidne

performanse (na dobro podranim platformama kao
to je Windows), izgled se bolje uklapa u izgled
platforme
nema screenshota zato to se ne razlikuje od native

aplikacije
Swing vs. SWT

JFrame f = new JFrame(Swing primjer);
f.setLayout(new FlowLayout());
f.add(new JLabel(Pozdrav svijete!));
f.add(new JButton(U redu));
f.pack();
f.setDefaultCloseOperation(JFrame.DISPOS
E_ON_CLOSE);
f.setVisible(true);
SWT
Swing
Shell s = new Shell();

s.setText(SWT primjer);
Label l = new Label(s, SWT.NONE);
l.setText(Pozdrav svijete!);
Button b = new Button(s, SWT.NONE);
b.setText(U redu);
s.pack();
s.open();
Swing vs. SWT

Swing
SWT
Moe se stilizirati tokom izvrenja
Stil se definie u konstruktoru
Automatska dealokacija
Radi efikasnijeg rada, poeljno je dealocirati

widgete pozivom metode dispose()
Kompleksna hijerarhija klasa
Vrlo jednostavna hijerarhija klasa
Obavezna upotreba Model-ViewController (MVC) pristupa
Nije nuno koristiti MVC, ali moe se dobiti

kroz JFace biblioteku
Frameworks
to je klasa za objekat, to je okvir (framework) za
aplikaciju.
Okvir sadri sve to je potrebno za pravljenje

aplikacije - osim same aplikacije. Preostaje posao
popunjavanja praznina.
Frameworks
Java framework
.NET framework
Ova dva su ujedno i platforme.
Qt framework
Originalno toolkit za C++.
Frameworks - principi
Inversion of Control (IoC)
U proceduralnom programiranju, neki centralni dio koda kontrolie

izvrenje programa (npr. main funkcija). esto se ovaj princip prenosi
i na OOP.
IoC znai da se ovo naputa, a uvode se klase i objekti koji meusobno
komuniciraju - razmjenjuju poruke. Pri tome, klasa ne pravi nikakve
pretpostavke o implementaciji druge klase.
Hot Spots
Framework nije izvrna datoteka. Da bi se dobila izvrna datoteka

treba implementirati odreene hot spots - apstraktne klase ili metode
koje specificiraju ta ustvari aplikacija treba da radi. Na program ne
odreuje kojim redom e se pozivati hot spots - to odreuje
framework.
Convention over Configuration
Treba imati razumne default vrijednosti. Framework klase moraju

raditi neto korisno out of the box, bez pretjerane konfiguracije.
Dobar primjer je Ruby on Rails.
Proirivost
Framework treba podsticati proirivanje postojeeg koda npr. pomou

nasljeivanja klasa ili automatskog generisanja koda. S druge strane,
ne smije se dozvoliti korisniku da mijenja kod frameworka.
Design Patterns
Framework treba promovisati i kodificirati primjenu ablona dizajna

(design patterns). Generalno, razumijevanje pojma framework je teko
bez shvatanja design patterns-a.
Don't Repeat Yourself!
Treba postojati tano jedan nain da se uradi bilo ta. Ovo poboljava
itljivost i smanjuje dupliciranje koda.
OOP
Framework je u pravilu objektno-orjentisan, i implementiran je u OO

jeziku (mada moe imati veze / bindings i za ne-OO jezike).
Framework se moe baviti nekim specifinim problemskim domenom

ili moe generalno specificirati dizajn aplikacije.
Frameworks primjer - Qt
#include
#include
#include
#include
<QApplication>
<QFont>
<QPushButton>
<QWidget>
class MyWidget : public QWidget

{
public:
MyWidget(QWidget *parent = 0);
};
MyWidget::MyWidget(QWidget *parent)
: QWidget(parent)
{
setFixedSize(200, 120);
QPushButton *quit = new QPushButton(tr("Quit"), this);
quit->setGeometry(62, 40, 75, 30);
quit->setFont(QFont("Times", 18, QFont::Bold));
connect(quit, SIGNAL(clicked()), qApp, SLOT(quit()));
}
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
MyWidget widget;
widget.show();
return app.exec();
}
#include
#include
#include
#include
<QApplication>
<QFont>
<QPushButton>
<QWidget>

{
public:
};
: QWidget(parent)
{
}
{
MyWidget widget;
widget.show();
return app.exec();
}
Inversion of Control
main() ne radi gotovo nita, samo
poziva exec() metodu klase
QApplication koja preputa kontrolu
frameworku
#include
#include
#include
#include
<QApplication>
<QFont>
<QPushButton>
<QWidget>

{
public:
};
Proirivost (extensibility)
Poinjemo tako to emo
napraviti vlastitu podklasu
klase QWidget
: QWidget(parent)
{
}
{
MyWidget widget;
widget.show();
return app.exec();
}
frameworku
#include
#include
#include
#include
<QApplication>
<QFont>
<QPushButton>
<QWidget>

{
public:
};
: QWidget(parent)
{
klase QWidget
Hot Spot
U ovom sluaju implementiraemo
samo konstruktor nae klase koji
ustvari odreuje ta e se desiti

}
{
MyWidget widget;
widget.show();
return app.exec();
}
frameworku
#include
#include
#include
#include
<QApplication>
<QFont>
<QPushButton>
<QWidget>

{
public:
};
: QWidget(parent)
{
klase QWidget
Hot Spot
U ovom sluaju implementiraemo
Hot Spot
Preko signala odreujemo druge
interesantne dogaaje, npr. klik na
dugme smo povezali sa
zavretkom programa
}
{
MyWidget widget;
widget.show();
return app.exec();
}
frameworku
#include
#include
#include
#include
<QApplication>
<QFont>
<QPushButton>
<QWidget>

{
public:
};
: QWidget(parent)
{
klase QWidget
Default implementacija klasa
QWidget i QPushButton radi
Hot Spot
gotovo sve to nam treba, nije
U ovom potrebna
sluaju implementiraemo
konfiguracija
Hot Spot
Preko signala odreujemo druge
interesantne dogaaje, npr. klik na
dugme smo povezali sa
zavretkom programa
}
{
Ni ovo nismo morali raditi (istopoziva exec() metodu klase
MyWidget widget;
radi estetike =)
widget.show();
return app.exec();
frameworku
}
Softverske platforme
Java platforma
Jezici: Java, Clojure, Groovy, JRuby, Rhino, Jython,
Scala, Web Language
.NET platforma
Jezici: C#, C++/CLR, VB.NET, F#, IronPython,
IronRuby...
User Interface
Design
(alfa verzija prezentacije)
Literatura:
Pressman, Software Engineering, Chapter 12.
Somerville, Software Engineering, Chapter 16.
Osobine korisnikog iface

1. Sakriva kompleksnost
sve suvine opcije odvojiti u advanced sekcije,

koristiti razumne default vrijednosti
2. Jednostavan za uenje
davati savjete (tooltips), pomo (help), operacije

trebaju imati logine efekte
3. Pristupaan
omoguiti rad tastaturom, ne koristiti iskljuivo

ikone (slike)
Osobine korisnikog iface (2)

4. Interno konzistentan
sve opcije sa istim imenom/izgledom trebaju imati

isti efekat (npr. dugme Izvjetaj), bez iznenaenja
5. Eksterno konzistentan
standardni elementi UI trebaju se ponaati kao u

ostatku OS-a (npr. dugme Ok/U redu vs.
Cancel/Odustani)
6. Estetika
ne treba ni to zaboraviti
Human interface guidelines

Microsoft Windows User Experience
Guidelines
Apple Human Interface Guidelines
Java Look & Feel Design Guidelines
Eclipse User Interface Guidelines
Android User Interface Guidelines
...
Obavezno proitati! I koristiti!
Specifikacija UI
definisanje sluajeva upotrebe (use-case)

nacrt dizajna (eme, skice)
pisanje dokumenta specifikacije
Sadraj dokumenta
historija izmjena
uvod
poznati problemi
logiki tok (na koji nain su povezani

razni ekrani, kako se korisnik kree s jednog
ekrana na drugi)
opisi ekrana
Opis pojedinanog ekrana

ilustracija - na ilustraciji oznaiti elemente
strelicama, kockama, brojevima
opisati svaki element oznaen brojem u

tekstu ispod
navesti eventualno pravila za organizaciju

elemenata (npr. sortiranje)
koji dijalozi e biti prikazani i u kojoj

situaciji
koji linkovi postoje na druge ekrane?
Opis pojedinanog ekrana (2)

ne pretjerivati u ljepoti i vizuelnim
detaljima kako se ne bi ne potrebno skretala
panja korisnika
CASE (Computer
Aided Software
Engineering) alati
Literatura:
McConnell, Code Complete, Chapter 30.
CASE
- nauno zasnovana
primjena alata i metoda na
softverski sistem sa ciljem
razvoja proizvoda visoke
kvalitete, bez defekata i
laganih za odravanje
CASE alati
upper CASE
(vii nivo planiranja i projektovanja sistema)
lower CASE
(podrka konkretnim aktivnostima razvoja
softvera)
generalno, postoje alati za svaku fazu ivotnog

ciklusa
CASE alati - dizajn

upper CASE
razne vrste UML dijagrama
generisanje koda?
Rational Rose, Umbrello, Visio,

StarUML
CASE - rapidno prototipiranje

alat za brz razvoj prototipa sa naglaskom na
vizuelne aspekte (izgled)
dotjeran korisniki interfejs / vidljive osnovne

funkcionalnosti softvera
olakava prikupljanje zahtjeva i projektovanje

korisnikog interfejsa, a korisniku daje ideju kako
e izgledati zavren program
alati za prototipiranje: generatori koda,

VisualBasic, MS Access, Dreamweaver + PHP i sl.
upper / lower ?
CASE - editor koda

bojenje sintakse (highlighting), preklapanje
dijela koda (folding), automatsko poravnanje
(indentation), uparivanje zagrada (brace matching)
AutoComplete / IntelliSense / ...
navigacija koda
mone search replace opcije (kroz vie fajlova)
makro naredbe (automatizacija odreenih

akcija) i abloni (templates - polugotovi fajlovi)
CASE - source code tools

diff - vizualni prikaz razlika izmeu fajlova
merge - spajanje dva fajla, kombinujui razlike

ili pitajui korisnika koju od razlika prihvatiti
uljepivai koda (source code formatters) popravljaju poravnanje
alati za kros-reference i generisanje hijerarhije

klasa
otkrivanje uobiajenih greaka: lint
alati za softverske metrike
alati za restructuring i refactoring
CASE - executable code tools

kompajler, linker, interpreter
preprocesori - kod koji se generie iz drugog

(jednostavnijeg? itljivijeg?) koda: m4; DSLs...;
transformacija koda - yacc i drugi
alati za automatsku izgradnju koda: make,

cmake, jam, Apache Ant...
alati za konfigurisanje koda: autoconf...
alati za izgradnju instalacije: InstallShield,

NSIS...
biblioteke
CASE - revision control
SVN (Tortoise)
CVS (sve rjee)
Git
Mercurial, Bazaar...
Visual SourceSafe
plugins za razvojna okruenja
CASE - unaprjeenje izvrnog

koda
debugging - postupno izvrenje, otkrivanje
greaka
profiliranje - prikupljanje statistikih

informacija o izvrenju programa radi otkrivanja
potencijalnih problema
alati: strace, Valgrind (memcheck, cachegrind

itd.), JProfiler
CASE - testiranje
automatsko testiranje - unit testing (npr. JUnit,
NUnit, CppUnit itd.)
generatori testova
generatori problema (defect injectors)
obino u kombinaciji sa prethodnim slajdom
Nedostaci CASE
nekompatibilnost alata
pretjerano oslanjanje na alate (ne moe alat

uraditi va posao)
4GL - najavljeni 80tih godina!?
dugotrajno i skupo uvoenje
Integrisani CASE alati

vei ili manji stepen integracije, dodaci
(plugins)
MS VisualStudio, Eclipse, NetBeans,

KDevelop, Anjuta... Emacs?
prednosti: laka standardizacija, laka upotreba
nedostaci: prejednostavni - previe stvari

sakrivaju, ponueni alati moda nisu najbolji
Okruenja orjentisana na alate

KISS - Keep It Simple, Stupid
jednostavno uvezivanje alata
moni skripting jezici
kovencije (stdin/stdout/stderr, return value,

signali)
UNIX na Windowsu - Cygwin
Razvoj vlastitih alata

sudbina svakog programera :)
procesno i projektno specifini alati
skripting jezici (Perl, bash, PowerShell?,

Python?)
Web
Tehnologije
Literatura:
Pressman, Software Engineering, Chapters 16-20.
ta je to web?
web server: na zahtjev alje fajl korisniku
koristei HTTP (HyperText Transfer Protocol) (i to
je sve (uglavnom))
web stranica: dokument sastavljen od teksta i

slika, opisan jezikom HTML (HyperText Markup
Language)
web preglednik (browser): program koji alje

zahtjev web serveru i prikazuje primljene datoteke
(a pogotovo HTML)
Primjer HTML dokumenta

<html>
<head>
<title>Naslov dokumenta</title>
<meta http-equiv=Content-Type
content=text/html; charset=UTF-8>
</head>
<body>
<h1>Pozdrav</h1>
<p>U ovom tekstu pozdravljam sve
studente koji obraaju panju.</p>
</body>
</html>
URL: Uniform Resource Locator i URI: Uniform

Resource Identifier
ta je to web? (cont.)
statika web stranica - HTML (ili neki drugi)
dokument koji je uvijek isti
dinamika web stranica - mijenja se (npr.

stranica vijesti, courseware i slino)
web aplikacija - sve vie aplikacija se

danas prave kao dinamike web stranice
prednosti: podrava sve platforme uklj.

mobilne, nema instalacije, lako se odrava
nedostaci: interfejs nije isti kao native, ima

ogranienja, treba dodatno paziti na sigurnost
Vrste web aplikacija (web

tehnologija)
klijentske
serverske
kombinovane
Klijentske web tehnologije

program se preuzima (downloaduje) sa servera i
zatim automatski izvrava na korisnikovom
raunaru, unutar prozora web preglednika
(browsera)
glavni problem: sigurnost, zahtjevi na

korisnikov hardver i softver
Klijentske web tehnologije:

JavaScript
pravo ime: ECMAScript, jedva nalik Java-i
interpretirani jezik, izvrava ga browser
kod ugraen u HTML (web stranicu)
manipulie nad DOM (Document Object

Model)
primjene: DHTML (interaktivne web stranice meniji i sl.)
raznolika podrka web preglednika
JavaScript primjer
.... ....
<script language=JavaScript>
function PrikaziSakrij(sta){
if (sta.style.display=="none"){
sta.style.display="inline";
}
else {
sta.style.display="none";
}
}
</script>
<img src=slika.gif id=slika>
<input type=button
value=Prikai/sakrij sliku
onclick=PrikaziSakrij(document.getElem
entById['slika'])>

Applets
aplikacijice
dodatak (plugin) za web preglednik izvrava

(interpretira) applet
nedostaci: sigurnosni problemi u plugin-ima,

korisniku mrsko downloadovati plugin
Java applets (implementira klasu JApplet),

Flash applets, Macromedia Director itd.
primjene: animacije, igrice, video

ActiveX
klasian Windows program se downloaduje s
neta i izvrava u kontekstu web browsera
praktino backdoor!!!
podran samo na Windows + Internet Explorer

(uz minimalni security settings)
primjene: VisualBasic programeri koji su

previe smotani da naprave ASP aplikaciju
Serverske web tehnologije

program se izvrava na serveru, rezultati rada se
alju korisniku i prikazuju
problemi: efikasnost transporta, limitacije

HTML baziranog korisnikog interfejsa,
kompleksan razvoj
Serverske web tehnologije:

CGI skripte
web server pokree program sa datim
parametrima i standardni izlaz alje korisniku
neizmijenjen
preko header polja Content Type: odreuje se

ta e browser uraditi s tim
najee pisane u Perlu
nedostaci: sigurnost, komplicirana upotreba

zbog sigurnosnih ogranienja
Primjer CGI skripte

ulazni parametri se daju preko URLa, nakon
znaka upitnik (?) Primjer:
http://www.mojserver.com/cgi-bin/skripta.cgi?ime=Vedran
#include <stdio.h>
int main(int argc, char** argv) {
printf (Content-Type:
text/html\n\n<h1>Pozdrav</h1>);
for (int i=1; i<argc; i++)
if (strncmp(argv[i], ime=, 4)==0)
printf(Zdravo, %s!, argv[i]+4);
return 0;
}
Serverske web tehnologije:

PHP
PHP kod se nalazi unutar HTMLa u formi
tagova
interpreter modul za web server - svaka

datoteka sa ekstenzijom .php e biti interpretirana!
danas najpopularniji jezik za web aplikacije
sigurnosni problemi uglavnom posljedica loeg

dizajna samog jezika
Primjer PHP skripte

... 
<p>Izaberite dan u mjesecu: <select name=dan>
<?php
for ($i=1; $i>=31; $i++)
echo <option>$i</option>\n;
?>
</select></p>
...
Serverske web tehnologije...

ASP (Active Server Pages), JSP (Java Server
Pages), ColdFusion... inspirisani uspjehom PHPa
web frameworks - olakavaju razvoj web

aplikacija tako to sakrivaju nain rada; korisnik
ima dojam da razvija desktop aplikaciju
http://en.wikipedia.org/wiki/List_of_web_application_frameworks
Kombinovane web tehnologije

AJAX (Asynchronous Javascript And XML):
klijent (JavaScript) i server (PHP/ASP/JSP/...)
komuniciraju koristei dobro definisan protokol otvara nove mogunosti u razvoju web aplikacija
stranice se auriraju bez klikanja, nema potrebe

za hackovima (hidden IFRAME i sl.)
AJAX frameworks: GWT...
piete Java kod koji generie serversku (Java)

i klijentsku (JavaScript) komponentu
Kako pisati
itljiv kod?
Upotreba praznog prostora

(whitespace)
Uporedite sljedei kod:
for (i=0; i<n; i++) { int
x=niz[i]; int pos=i; while
(x<niz[pos-1])
{ niz[pos]=niz[pos-1]; pos--;
} niz[pos]=x; }
for (i=0; i<n; i++) {

int x=niz[i];
int pos=i;
while (x<niz[pos-1]) {
niz[pos]=niz[pos-1];
pos--;
}
niz[pos]=x;
}

(whitespace)
Uporedite sljedei kod:
for (i=0; i<n; i++) {
int x=niz[i];
int pos=i;
pos--;
}
niz[pos]=x;
}
for (i=0; i<n; i++) {

int x=niz[i];
int pos=i;
pos--;
}
niz[pos]=x;
}

Pregled logike koda:
for (i=0; i<n; i++) {
int x=niz[i];
int pos=i;
pos--;
}
niz[pos]=x;
}

Pregled logike koda:
for
while
}
}

Uoite greku u sljedeem kodu:
for (i=0; i<MAX_ELEMENTS; i++)
leftElement = left[i];
left[i] = right[i];
right[i] = leftElement;
Koja je vrijednost sljedeeg izraza:
x = 3+4 * 2+7

(whitespace)
Praz anprost orjeodsu tinsko gzn aa ja

Svrha poravnanja (indentacije) je da
opie logiku strukturu programa.
Postoji vie stilova poravnanja koda:
K&R (a.k.a. one true brace style)
Allman
Whitesmits
GNU style
....

http://en.wikipedia.org/wiki/Indent_style
Upotreba stila poravnanja je vjersko pitanje najee je standardizovan
Poravnanje jako dugakih redova:
while ( (pathName[startPath+position] != ';')

&& (startPath+position) <= pathname.length() ) {
Nije praktino imati redove due od 80-tak

znakova
Zagrade
12 + 4 % 3 * 8 / 2 = ?
Zagrade
12 + 4 % 3 * 8 / 2 = 16
Ako vam je za ovaj odgovor trebalo vie od 5
sekundi, znai da bi ovdje pomogle zagrade!

Prazni redovi mogu pomoi da se program
razbije na cjeline, posebno ako ih prate komentari
cursor.start = startingScanLine;
cursor.end = endingScanLine;
window.title = editWindow.title;
window.dimensions = editWindow.dimensions;
window.foregroundColor = userPreferences.foregroundColor;
cursor.blinkRate = editMode.blinkRate;
window.backgroundColor = userPreferences.backgroundColor;
SaveCursor(cursor);
SetCursor(cursor);
(neki preferiraju da ubace suvine / nepotrebne

begin/end blokove odnosno zagrade)
// Podesavanje prozora
window.dimensions = editWindow.dimensions;
window.title = editWindow.title;
window.foregroundColor = userPreferences.foregroundColor;
window.backgroundColor = userPreferences.backgroundColor;
// Podesavanje kursora
cursor.start = startingScanLine;
cursor.end = endingScanLine;
cursor.blinkRate = editMode.blinkRate;
SaveCursor(cursor);
SetCursor(cursor);
Daljnji savjeti za prazan

prostor
Ne koristiti vie naredbi u istom redu!
Smanjiti broj operatora u redu, radi

izbjegavanja nepredvidivih sporednih efekata.
Primjer:
PrintMessage(++n, n+2);
Deklarisati samo jednu promjenljivu u redu?
Komentari
Misteriozni kod (1)
ta radi sljedei program?

// ispisi sume 1..n za svako n od 1 do num
trenutna = 1;
prethodna = 0;
suma = 1;
for (int i=0; i<num; i++) {
System.out.println(Suma = + suma);
suma = trenutna + prethodna;
prethodna = trenutna;
trenutna = suma;
}
Misteriozni kod (2)

// postavi proizvod na bazu
proizvod = baza;
// petlja od 2 do num
for (int i=2; i<=num; i++) {
// pomnozi bazu za proizvodom
proizvod = proizvod * baza;
}
System.out.println(proizvod = + proizvod);
Misteriozni kod (3)

// izracunaj kvadratni korijen koristeci metodu
// Newton-Raphson
r = num/2;
while ( abs(r - (num/r)) > LIMIT) {
r = 0.5 * (r + (num/r));
}
System.out.println(r = + r);
Zakljuci
Zastarjeli (i inae netani) komentari proizvode
vie tete nego koristi!
Komentari koji samo ponavljaju kod ne

doprinose razumijevanju koda. Ustvari, samo
oteavaju itanje koda inei kod duim.
Komentari mogu biti nezamijenjivi za

razumijevanje koda.
Komentar treba izraavati

NAMJERU
Komentar treba da opisuje problem prije nego
rjeenje
Primjer dobrog komentara:

// Preuzmi podatke o korisniku iz baze
Primjer loeg komentara:

// Azuriraj objekat uposlenikSlog
I ovo su komentari
return NULL; // TODO: nedovrseno!
Ne elite ovo vidjeti kada korisnik prijavi

problem :)
Postoje neki standardi za ovakve komentare,

moe se konfigurisati u editoru, kompajleru
// Copyright (c) ETF 2006-2010.
Version control tag (obino na vrhu fajla):

// $Id$
Humor u komentarima
Kako pisati komentare?

Ako ste dugo razmiljali o relativno malom
dijelu koda, napiite komentar
Ako razdvajate kod u dijelove praznim

redovima, vjerovatno treba dodati komentar
Komentari se piu istovremeno kad i kod, ne

naknadno!
Ako ti je teko napisati komentar, znai da ne

razumije kako si rijeio/la problem - razmisli jo
malo.
Komentar = pseudokod?
Pozivanje na bugove / zahtjeve?
Kako pisati komentare?

Koristi komentar da pripremi itaoca na ono
to slijedi
Koristiti komentare kao bookmarks
Dokumentuj iznenaenja
Izbjegavaj skraenice
Opravdaj odstupanje od dobrog stila
Nekada je bolje prepraviti kod nego pisati

komentar
Dokumentuj deklaracije varijabli: jedinice

mjere, dozvoljene vrijednosti, implicitna znaenja
Gdje pisati komentare?

Komentar prije svake funkcije! Treba
sadravati: opis rada, ulazne i izlazne vrijednosti,
eventualne sporedne efekte...
Komentari na pojedinane linije su rijetko

potrebni
Komentari na kraju reda su loa praksa!

Primjer:
int* p = GetMemory();
// preuzmi pokazivac na memoriju
Izuzetak: deklaracije promjenljivih
Ispravna organizacija klase

// Sta je klasa, cemu sluzi, primjeri
// upotrebe itd.
class NazivKlase {
public:
NazivKlase(); // obicno je nepotreban komentar
// Uputstva za poziv metode, namijenjena programeru
metoda();
...
protected:
// Uputstva namijenjena implementatoru podklase
metoda();
private:
var atribut; // detaljan opis atributa
// komentar kao za funkciju
privatnaMetoda();
};
Komentarisanje klasa
Komentarisati osnovni dizajn pristup: koriteni
abloni (patterns), filozofija, eventualne alternative
koje su razmatrane i odbaene
Komentari u interfejsu klase (header fajl) ne

trebaju se baviti implementacijom!
Pisati komentare iz perspektive korisnika programera
Svaka klasa treba biti u datoteci sa istim

imenom
JavaDoc
Alat koji generie programersku dokumentaciju
iz posebno formatiranih komentara
Dvije muhe jednim udarcem
Automatski generie linkovane HTML

dokumente prema hijerarhiji klasa
http://java.sun.com/j2se/javadoc/writingdoccomments/
Za C++: doxygen
www.doxygen.org
JavaDoc
Alat koji generie programersku dokumentaciju
iz posebno formatiranih komentara
Dvije muhe jednim udarcem
Automatski generie linkovane HTML

dokumente prema hijerarhiji klasa
http://java.sun.com/j2se/javadoc/writingdoccomments/
Za C++: doxygen
www.doxygen.org
JavaDoc
/**
* Returns an Image object that can then be painted on the screen.
* The url argument must specify an absolute {@link URL}. The name
* argument is a specifier that is relative to the url argument.
* <p>
* This method always returns immediately, whether or not the
* image exists. When this applet attempts to draw the image on
* the screen, the data will be loaded.
*
* @param url an absolute URL giving the base location of the image
* @param name the location of the image, relative to the url
argument
* @return
the image at the specified URL
* @see
Image
*/
public Image getImage(URL url, String name) {
try {
return getImage(new URL(url, name));
} catch (MalformedURLException e) {
return null;
}
}
JavaDoc
getImage
public Image getImage(URL url,
String name)
Returns an Image object that can then be painted on the screen. The url argument
must specify an absolute URL. The name argument is a specifier that is relative to
the url argument.
This method always returns immediately, whether or not the image exists. When
this applet attempts to draw the image on the screen, the data will be loaded. The
graphics primitives that draw the image will incrementally paint on the screen.
Parameters:
url - an absolute URL giving the base location of the image
name - the location of the image, relative to the url argument
Returns:
the image at the specified URL
See Also:
Image
JavaDoc
Poinje sa /**
Kljune rijei:
@author (samo za klase i interfejse)
@version (samo za klase i interfejse)
@param (samo za metode i konstruktore)
@return (ta vraa - samo za metode)
@exception (koje izuzetke baca)
@see (vidjeti - referenca)
@since (oznake verzija)
@serial (bitno za serijalizaciju)
@deprecate (prevaziena metoda ili klasa,
ostavljena radi kompatibilnosti)
JavaDoc
Poinje sa /**
Kljune rijei:
@author (samo za klase i interfejse)
@version (samo za klase i interfejse)
@param (samo za metode i konstruktore)
@return (ta vraa - samo za metode)
@exception (koje izuzetke baca)
@see (vidjeti - referenca)
@since (oznake verzija)
@serial (bitno za serijalizaciju)
@deprecate (prevaziena metoda ili klasa,
ostavljena radi kompatibilnosti)
Nomenklatura
Nazivi promjenljivih
Naziv promjenljive treba da potpuno i precizno
opisuje njenu svrhu
Nauno utvrena idealna duina naziva

promjenljive: 10-16 znakova (mada je 8-20
prihvatljivo)
...to ne znai da sve varijable MORAJU biti te

duine :)
Varijabla kratkog naziva (npr. i) oznaava neto

nebitno, kratkog ivotnog vijeka - npr. indeks u
petlji
Izbjegavati skraenice!!!
Nomenklature
U jezicima koji razlikuju velika i mala slova,
nomenklatura olakava razlikovanje tipa
identifikatora
Poeljno je razlikovati: promjenljive/objekte,

funkcije/metode, klase, konstante
Postoji vie standarda...
Nomenklatura - primjer
Ako se naziv sastoji od vie rijei, one se piu
spojeno pri emu svaka rije poinje velikim
slovom
Objekti i metode uvijek poinju prvim malim

slovom, klase poinju velikim slovom
Konstante su sve velikim
Primjer:
NekaKlasa objekatNekeKlase;
objekatNekeKlase.metodaKlase(KONST);
Nomenklatura - nastavak
Globalne vrijednosti poinju sa g_
Privatni atributi (lanovi klase koji nisu javni)

poinju sa m_
Vrijednosti vidljive unutar fajla poinju sa f_
Statike vrijednosti sa s_
Vlastiti tipovi (typedef) su velikim slovima
Pobrojani tipovi se imenuju kao klase, a

vrijednosti su naziv tipa, znak _ i naziv
Primjer: enum Boja { Boja_Crvena,

Boja_Plava, Boja_Zuta };
Razliiti stilovi
U C-u je obiaj da se imena promjenljivih i
funkcija piu malim slovima, uz upotrebu znaka
donja crta (_) kao razmaka
int neka_funkcija(float neki_parametar);
U VisualBasic programima mogu se vidjeti

raznovrsni stilovi
Perl i drugi jezici imaju sigils - obavezne

prefikse za razne vrste identifikatora
Maarska notacija
Koristi se u MS Windows bibliotekama
Autor Charles Simonyi
Prefiksi za razliite tipove podataka (l - long, i int, sz - string koji se zavrava nulom, arr - niz, p pokaziva...)
Semantiki prefiksi (st - struktura, fn - funkcija,

rw - red, us - unsafe string, d - razlika, f - flag, rg raspon...)
Primjeri: arru8NumberList, lpszOwner,

rgfpBalances, aulColors
Jo savjeta
Izbjegavati globalne promjenljive zbog
neeljenih sporednih efekata
...
// Ovdje je postavljen broj_elemenata
UnesiMatricu();
// Da li je ovdje promijenjen broj_elemenata?
StepenujMatricu();
for (i=0; i<broj_elemenata; i++)
IspisiRed(matrica[i]);
Drugi programer koji mijenja StepenujMatricu()

moe sluajno promijeniti broj_elemenata ...
Jo savjeta
Ispravno rjeenje:
...
// Ovdje je postavljen broj_elemenata
broj_elemenata=UnesiMatricu(matrica);
// Ovdje SIGURNO nije promijenjen broj_elemenata
StepenujMatricu(matrica, broj_elemenata);
for (i=0; i<broj_elemenata; i++)
IspisiRed(matrica[i]);
Jo savjeta
Izbjegavati magine konstante

...
// Zasto 78 ???
for (i=0; i<78; i++)
....
Deklarisati pravu konstantu sa komentarom

// U jednom redu moze stati najmanje 78 znakova
const int SIRINA_EKRANA 78;
...
// Ahaaaa...
for (i=0; i<SIRINA_EKRANA; i++)
....
I jo savjeta!
C (i srodni jezici) daju mnogo prilika za
neitljiv kod, kao to su:
zloupotreba zaglavlja for petlje za neto za

ta nije namijenjena
Primjer: for (a=1,b=2; ; printf(%d,*c++))
koritenje shejtan operatora (,)

Primjer: x=1,2; vs. x=(1,2);
ternarni operator (x?a:b) generalno

promovie neitljivost
igra sa makro-ima
Primjeri loeg koda

http://blog.paulbiggar.com/archive/introducingmalicious-code-reviews/
Code::Blocks!!!
Design
Patterns
abloni dizajna (Design patt.)

Poznata i dobro istraena rjeenja
za este probleme
...ali i pristup rjeavanju problema
Nude zajedniki rjenik

softverskim inenjerima
Moe li se design pattern

staviti u biblioteku?
Problem: nai kvadratni korijen
broja x
Rjeenje: sqrt(x) - nije pattern!
Jedan jednostavan primjer

Problem: Primijeniti funkciju f(x) na
sve lanove niza niz.
Rjeenje:
for (i=0; i<vel; i++)

f(niz[i]);
Design patterns
knjiga Design patterns, autori
Gang of Four (GoF) - Gamma et al.
veinom specifini za OOP
rjeavaju probleme Jave i C++-a
anti-pattern
svakodnevno novi patterns?
Model-View-Controller (MVC)
Design pattern ili filozofija?
Arhitekturalni pattern
Omoguuje odvojen razvoj

korisnikog interfejsa i podataka
Separation of Concerns
Model-View-Controller (cont.)
Osnovni princip: sve klase su
svrstane u tri kategorije
Model: sadri podatke i biznis

logiku
View: korisniki interfejs prema

modelu
Controller: povezuje Model i

View
MVC trijada klasa:
StudentModel - pasivna klasa sa

podacima (npr. klasa Student sa TPa)
StudentView - forma za auriranje

studenta
StudentController - aurira model u

sluaju promjene view
StudentController
sm : StudentModel
sv : StudentView
StudentView
sm : StudentModel
sc : StudentContr...
ok : Button
ime : TextEdit
update()
okClicked()
StudentModel
set*()
changed()
get*()
MVC frameworks nude generike
MVC klase
mnoge stvari nedefinisane:
MVP(resenter)
MVVM (ViewModel)
MVA(dapter)
alternativa: naked objects
Da li je mogu MVC na webu?
view = HTML (template),

controller i model na serveru
kako aurirati view nakon

promjene modela? (AJAX!)
MVC framework generiu

HTML+JS sakrivajui implementaciju
Tronivoska arhitektura
(three-tier)
arhitekturalni pattern
server-klijent arhitektura, nivoi su

zasebne aplikacije, na raunaru
korisnika samo zadnji nivo
nivoi: prezentacija, poslovna

logika, podaci
ActiveRecord pattern
objektno-relaciono mapiranje
(ORM)
klasa = tabela ili pogled
objekat = red (slog)
programer ne razmilja o SQLu,

radi sa klasama i objektima
ORM podrka u frameworks
ActiveRecord pattern (cont.)

Primjer:
Student s = new Student;
s.ime = Meho;
s.prezime = Mehic;
s.insert();
s = Student.find(Meho);
s.ime = Mehica;
s.update();
Factory pattern
fabrika (factory) je metoda koja
kreira novi objekat neke klase
class Nesta {
Nesta(int x);
Nesta dajNesta(int x) {
return new Nesta(x);
}
}
Factory pattern - upotreba

jedan od objekata iz hijerarhije na
osnovu parametra
Krug dajKrug(Boja b) {
if (b==Crvena)
return new CrveniKrug;
if (b==Plava)
return new PlaviKrug;
...
}
paralelne hijerarhije (abstract f.) - C++:
class Oblik {...};

class Kvadrat : public Oblik {...};
class Krug : public Oblik {
virtual Kvadrat* dajKvadrat();
};
class CrveniKrug : public Krug {
Kvadrat* dajKvadrat() {
return new CrveniKvadrat;
}
};
paralelne hijerarhije (abstract f.) - Java:
class Oblik {...}

class Kvadrat extends Oblik {...}
class Krug extends Oblik {
Kvadrat dajKvadrat();
}
class CrveniKrug extends Krug {
Kvadrat dajKvadrat() {
return new CrveniKvadrat;
}
}
uspostavljena je veza izmeu paralelnih hijerarhija

nasljeivanje
factory
Oblik
Kvadrat
Krug
CrveniKvadrat
CrveniKrug
PlaviKvadrat
PlaviKrug

ako nam je potrebno vie konstruktora sa istim
brojem parametara, ili sa jasnijim imenom:
class Kompleksan {
Kompleksan(double re, double im); // iz
Dekartovih koordinata
Kompleksan(double abs, double angle); //
iz polarnih koordinata
// Syntax error
// Ne mozemo imati dva konstruktora sa
istim brojem i tipom parametara
};
rjeenje problema preko factory-ja (Java)
class Kompleksan {
Kompleksan(double re, double im);
Kompleksan izDekartovih(double re, double
im) { return new Kompleksan(re,im); }
Kompleksan izPolarnih(double abs, double
angle) { return new Kompleksan(abs*cos(angle),
abs*sin(angle); }
// Jasnije je sta koji radi
}
Kompleksan k = izPolarnih(a,b);

kod Unit testova, pravimo testne
varijante klasa koje ne rade nita
opasno koristei factory metodu
koja stvara RealClass ili TestClass
ovisno da li je poziva unit test ili
pravi program
Singleton pattern
klasa koja ima samo jednu
instancu (de facto globalni objekat)
instanca je statiki atribut
konstruktor je zatien (protected),

ne moe se direktno pozvati
najee se koristi zajedno sa

factory patternom (npr. sistemska
konfiguracija)
Singleton pattern - impl. Java

public class Klasa {
private static Klasa instanca = null;
protected Klasa() { // zabranjeno }
public static Klasa dajInstancu() {
if (instanca == null)
instanca = new Klasa();
return instanca;
}
}
Singleton pattern - impl. C++

// C++ primjer je nesto slozeniji...
class Klasa {
private:
static Klasa instanca;
// Sve ovo zabranjujemo
~Klasa() {}
Klasa(const Klasa&);
Klasa& operator=(const Klasa&);
protected:
Klasa() {}
public:
static Klasa& dajInstancu();
};
Singleton pattern - impl. C++

Klasa Klasa::instanca;
// ovom deklaracijom je kreirana instanca
klase
Klasa& Klasa::dajInstancu() {
// Alternativa: atribut metode!
// static Klasa instanca;
return instanca;
}
// Poziv singletona
Klasa::dajInstancu().metoda();
Singleton pattern - problemi

problemi sa paralelizacijom
problemi sa unit testingom
problemi sa redoslijedom
inicijalizacije (kod statikih
vrijednosti)
mnogi ga nazivaju anti-pattern
Adapter (Wrapper) pattern

omotava klasu u drugu klasu kako bi joj
dao interfejs koji korisnik oekuje
esto se koristi sa viestrukim

nasljeivanjem (C++)
Kvadrat k;
...
// metoda ispisiKrug prima Krug, a mi
imamo samo Kvadrat... sta sad?
ispisiKrug(KvadratniKrug(k));
Adapter pattern - primjer C++

class Oblik { ... }
class Kvadrat : public Oblik {...}
class Krug : public Oblik {...}
class KvadratniKrug : public Krug {
private:
Kvadrat* _k;
public:
KvadratniKrug(Kvadrat* k) {_k=k;}
double poluprecnik() {
return sqrt( _k->stranica() *
_k->stranica() * 2 ) / 2;
}
};
Adapter pattern - primjer Java

class Oblik { ... }
class Kvadrat extends Oblik {...}
class Krug extends Oblik {...}
class KvadratniKrug extends Krug {
private Kvadrat _k;
KvadratniKrug(Kvadrat k) {_k=k;}
return sqrt( _k.stranica() *
_k.stranica() * 2 ) / 2;
}
}
Adapter pattern - primjer

// drugi nacin, preko visestrukog
// nasljedjivanja - C++ only
class KvadratniKrug : public Krug,
Kvadrat {
return sqrt( stranica() *
stranica() * 2 ) / 2;
}
};
Facade pattern (fasada)

razlika izmeu adaptera i fasade
je u tome to se adapter koristi kada
klasa mora imati odreeni intefejs, a
fasada slui za pojednostavljenje
intefejsa klase
Decorator pattern
koristi se kada je potrebna izmjena
osobina klase ili dodavanje novih osobina
prilikom izvrenja
vri se tako da se napravi izvedena

dekorator klasa, u kojoj se reimplementiraju
sve funkcije
dekorator prima pokaziva na baznu klasu
Decorator pattern - primjer iz

Java biblioteke
PrintWriter izlazna = new
PrintWriter(new BufferedWriter(new
FileWriter("statistika.txt")));
Decorator pattern - primjer C++

class Osoba {
private: std::string _ime;
public: Osoba(std::string ime) { _ime=ime; }
virtual std::string dajIme() { return ime; }
};
class DekorisanaOsoba : public Osoba {
private: Osoba* _o;
std::string _d;
public: DekorisanaOsoba(Osoba* o) { _o=o; }
std::string dajIme() { return _d +
_o->dajIme(); }
void dekorisi(std::string d) { _d=d; }
};
Decorator pattern - primjer Java

class Osoba {
private String _ime;
Osoba(String ime) { _ime=ime; }
String dajIme() { return ime; }
}
class DekorisanaOsoba extends Osoba {
private Osoba _o;
private String _d;
DekorisanaOsoba(Osoba o) { _o=o; }
String dajIme() { return _d + _o.dajIme(); }
void dekorisi(String d) { _d=d; }
}
Decorator pattern - primjer Java

// Biramo neku osobu
Osoba o(Meho Mehic);
// dekorisanje osobe o
if (korisnikDoktorirao()) {
DekorisanaOsoba do = new DekorisanaOsoba(o);
do.dekorisi(dr. );
o=do; // polimorfizam!
}
...
System.out.println(o.dajIme());
// dr. Meho Mehic
Iterator pattern
iterator klasa slui za kretanje
kroz elemente neke kolekcije, pri
tome ne otkrivajui internu strukturu
klase
dosta primjera u standardnim

bibliotekama
Observer (promatra) pattern

koristi se kada je potrebno
obavijestiti vie objekata
(promatraa) o promjenama na
nekom objektu (koji se naziva
subjekt)
esto se koristi za MVC
podrka u Javi
Observer pattern - impl.

klasa Observer sadri metodu notify()
svi promatrai nasljeuju ovu klasu

npr. koristei viestruko nasljeivanje
subjektna klasa sadri kao atribut listu

Observer objekata, sadri metode
addObserver(), removeObserver() i sl.
subjektna klasa prilikom promjene

prolazi kroz listu i poziva metodu notify()
Observer pattern - primjer Java

interface Observer {
void notify();
}
class StudentView extends JFrame implements
Observer {
private StudentModel sm;
private JTextField jtf;
....
void notify() {
jtf.setText(sm.getName());
}
}
Observer pattern - primjer Java

// Prema MVC pristupu StudentModel klasa ne smije znati
nista o StudentView... ali moze implementirati Observer
pattern!
class StudentModel {
ArrayList<Observer> observers;
String name;
...
void setName(name) {
this.name=name;
for (Observer o : observers)
o.notify(); // Obavijesti sviju
}
void addObserver(Observer o) {
observers.add(o);
}
...
}
Procesi i
metodologije
Literatura:
Pressman, Software Engineering, Chapter 3: Process Models
Zato razliite metodologije?
Debata u SI krugovima
Razliite vrste projekata
poslovni sistemi
off-the-shelf
vladini i vojni projekti
Web 2.0 projekti
Waterfall (vodopad) proces

Primjer loeg pristupa (W. Royce,
1970)
Koristi se zbog jednostavnosti
Intuitivno jasan: programerima,

menaderima, klijentima
Precizno definisane faze, bez

preklapanja, sa jasnim ulazima i
izlazima
Waterfall (vodopad) proces

Korisniki
zahtjevi
Dizajn
Implementacija
Testiranje
Dokumentovanje
Verifikacija
i validacija
W. Royce (1970)
Deployment
Odravanje
Faza 1: Korisniki zahtjevi

Metodama intervjua, ankete,
prototipa itd. prikupiti zahtjeve korisnika
(requirements)
Ulaz: definicija projekta (mission

statement), izvodivost projekta
(feasibility study)
Izlaz: potpisana specifikacija

korisnikih zahtjeva
Faza 1: Korisniki zahtjevi
Faza 2: Analiza i dizajn

Detaljan opis sistema koristei
standardnu notaciju (UML)
Dizajn visokog i niskog nivoa:
arhitektura, apstraktna specifikacija, korisniki

interfejs, dizajn komponenti, dizajn struktura
podataka, dizajn algoritama
Izlaz: niz dizajn dokumenata koji

skoro potpuno opisuju konani
proizvod
Faza 3: Implementacija
Programiranje je individualan
proces, ne postoji univerzalan metod
Izlaz: alfa verzija softvera
Faza 4: Testiranje
Pronalaenje nedostataka u kodu
(debugging)
U toku implementacije?
Automatizovani testovi
Izlaz: beta verzija softvera
Faza 5: Dokumentovanje
Dokumentovanje finalnog
projekta a ne koda (komentari itd.)
Izlaz: tehnika i korisnika

dokumentacija, release notes, help...
Da li je UML dobra tehnika

dokumentacija?
Faza 6: Verifikacija i validacija

Testiranje komponenti (unit testing)
Testiranje sistema (emergent properties!)
Testiranje integracije
Testiranje prihvaenosti (acceptance),

sukladnost specifikaciji kor. zahtjeva
Sukladnost standardima kvalitete
Pregledi koda (code reviews)
Izlaz: finalna verzija softvera, izjava o

prihvatanju
Faza 7: Primjena (deployment)

Nepredviene okolnosti u primjeni
Podrka za razliite hw&sw

konfiguracije, mree itd.
Obuka korisnika
Izlaz: naplata, ugovor o

odravanju
Faza 8: Odravanje
(maintenance)
Ispravka nedostataka i nove
funkcionalnosti
Da li je neto nedostatak?
Izlaz: point release (1.0.1, 1.0.2...)
ivotni ciklus razvoja softvera

Korisniki
zahtjevi
Odravanje
Verzija 1.0
Dizajn
Verzija 2.0
Implementacija
Deployment
Verifikacija
i validacija
Testiranje
Dokumentovanje
Nedostaci waterfall-a
Puno vremena se gubi u ranim
fazama (preko 50% prve dvije faze)
Korisnik je uvijek u pravu,

odbija da potpie
Svaka promjena vodi do vraanja

u neku od prethodnih faza
restart procesa je skup
Povratak u prethodnu fazu

Korisniki
zahtjevi
Dizajn
Implementacija
Testiranje
Dokumentovanje
Verifikacija
i validacija
Deployment
Odravanje
Modifikovani waterfall
Korisniki
zahtjevi
Dizajn
Implementacija
Testiranje
Dokumentovanje
Verifikacija
i validacija
W. Royce (1970)
Deployment
Odravanje
Modifikovani waterfall (2)

Korisniki zahtjevi
Dizajn
Implementacija
Testiranje
Dokumentovanje
Verifikacija i validacija
Deployment
Odravanje
Zato priamo o waterfall-u?

Veina projekata i danas su
waterfall :(
Vi praktiki koristite waterfall
Faze waterfall procesa se nalaze u

svim drugim procesima
Iterativni pristup
Rjeenje za waterfall probleme!
Softver se razvija u iteracijama

(verzija 1.0, 1.1, 2.0 ...)
Svaka iteracija predstavlja prototip

za sljedeu iteraciju
Vea ukljuenost korisnika
Suprotno od Big Design Up Front

(BDUF)
Iterativni pristup
Poetni
zahtjevi
Analiza i
dizajn
Implementacija
Prototip
Zahtjevi za
slj. iteraciju
MINI IVOTNI
CIKLUS
Evaluacija
Deployment
Testiranje
Prednosti iterativnog pristupa

Restart je jeftin (samo se odbaci zadnja
iteracija)
Manje vremena se provodi na dosadnim

stvarima
Evolutivni razvoj - zahtjevi zamrznuti

unutar iteracije, mijenjaju se izmeu iteracija
Svaka iteracija predstavlja upotrebljiv

proizvod za korisnika - vee zadovoljstvo
korisnika
Manji rizik od neuspjeha
Problemi iterativnog pristupa

Kljuni problem IP: beskonane
iteracije
Treba definisati uslov za prekid

procesa
...ili ne treba?
Najprije se rjeavaju zahtjevi

visokog prioriteta
potrebno prioritizirati zahtjeve
Prototip vs. iteracija?
Evolutivni razvoj
Poslovni sistem se mijenja, pa se i
informacioni sistem treba mijenjati
Razvoj se nikada ne zavrava?
in-house razvoj ili po ugovoru
Exploratory programming &

throw-away prototyping
Evolutivni razvoj
Konkurentne aktivnosti
Specifikacija
Grubi opis
sistema
Razvoj
Validacija
Prva verzija
Meuverzije
Meuverzije
Meuverzije
Finalna verzija
Evolutivni model, drugi pogled

Upravljanje zahtjevima, izmjenama, defektima
Upravljanje arhitekturom, frameworks, patterns
Upravljanje integracijom, testiranjem i izdanjima
Raspodjela
zadataka
Integracija
Implementacija
Upravljanje programom proizvoda
Precizirane varijante IP
Iterativni razvoj sa
inkrementalnom isporukom
Spiralni pristup
Agilni razvoj
Iterativni razvoj sa inkrement.

isporukom (a.k.a. i&i)
Projektni zadatak se dijeli na
cjeline ili module (inkremente)
Svaki inkrement se razvija

zasebno
Kombinacije inkremenata u
raznim stepenima dovrenosti ine
iteracije
Iterative & Incremental
Incremental approach
Iterations within an increment

Project level
iterations
Iterative & incremental

Trajanje iteracije je fiksirano i
nezavisno od statusa razvijenosti
Inicijalizacija (bazna verzija

sistema, nulta iteracija)
Project Control List - checklista

stvari koje treba uraditi u datoj
iteraciji
Spiralni model
Naglasak na kontroli rizika,
prototipu, top-down & bottom-up
Sadri kompletan waterfall,

formalniji od IP
Due trajanje iteracije
Pogodan za velike projekte

(vladini i vojni projekti)
Spiralni model
Agilni razvoj softvera

Mali, samoorganizujui timovi
Programiranje u parovima
Timovi rade u otvorenim prostorima koji

olakavaju komunikaciju
Vrlo kratke iteracije (1-4 sedmice) uz

minimum planiranja
Korisnik je lan tima
Naglasak na ivoj komunikaciji
Vrlo malo dokumentacije
Agilni razvoj softvera

Specifikacija korisnikih zahtjeva
ne postoji!
Kako sastaviti ugovor?
Kako provjeriti ta je uraeno?
ime mjeriti napredak?
Dokumentacija se pravi po potrebi
Jednostavnost je imperativ
Ekstremno programiranje (XP)

Varijatna agilnog razvoja
Naglasak na to brem izdavanju verzija i

razvoju osobina/ispravki
Konstantan refactoring
Korisnike prie (user stories) su osnovni

dokument
Automatizovani (unit) testovi se piu prije

koda, preduslov za razvoj (TDD)
Ne postoji vlasnitvo nad dijelovima koda
Agilni razvoj i XP
Naglasak na ovjeku, ne na
procesu!
npr. XP zabranjuje prekovremeni rad

pretpostavka je dobar ovjek!
Prihvati promjenu kao nunost
ne planiraj promjenu nego osmisli

proces koji se adaptira
Jo procesa...
Ratonal Unified Process (RUP)
Feature Driven Development (FDD)
Dynamic Systems Development

Method (DSDM)
Scrum
Capability/Maturity Model
Integration (CMMI)
Component Based Software

Engineering (CBSE)
Prepoznati koje postojee
komponente se mogu iskoristiti, koje
modificirati, a koje praviti nove
Posebno upotrebljivo u opensource projektima
Code
refactoring
Literatura:
Martin Fowler, Refactoring
Programi se nikada ne
piu ispoetka!
Code refactoring
Transformacija koda koja ne mijenja
njegovu funkcionalnost
Razlozi:
bolja itljivost
reorganizacija radi lakeg

proirivanja
primjena design patterns
Code refactoring
Code smells - loe prakse u
programiranju, signal da je potreban
refactoring
Formalne metode minimizuju anse

sluajnih promjena funkcije
Testiranje nakon svake sitne izmjene nema refactoringa bez unit testova!
Code refactoring
Bez refactoringa, dizajn propada
Da li je refactoring gubljenje
vremena?
Konstantni refactoring
Izmjene baze?
Code smells
1. Ponavljanje koda!
2. Ponavljanje koda!
3. Ponavljanje koda!!!
4.
5.
...
100. Ponavljanje koda!?!?#@$!
Code smells
101. Predugake metode ili klase

Metoda ne treba biti zamjena za
kilometarski main() - prednost OOP je
vie kraih metoda
Simptom prekomplicirane klase je

puno atributa
102. Puno parametara metode
Komplikovano koritenje,
razumijevanje, promjena
Code smells
103. Shotgun Surgery
104. Divergent Change
Nedovoljna promjenljivost klase potrebna promjena na puno mjesta

Pretjerana promjenljivost klase promjena potrebna za nevezane stvari
105. Feature Envy
Metode koje se previe bave drugom

klasom
Code smells
106. Grupe podataka
Pretvoriti u klasu!
107. Opsesija primitivnim

tipovima
to vie koristiti klase za tipove
108. Upotreba switch naredbe
Vjerovatno treba koristiti

polimorfizam
Code smells
109. Paralelne hijerarhije

110. Beskorisne klase
111. Spekulativna generalnost
Kompleksna hijerarhija zbog moe

nekad zatrebati
112. Privremena polja
Vjerovatno treba napraviti novu

klasu
Code smells
113. Lanci poruka
114. Suvini posrednik
115. Preintimne klase
116. Sline metode nemaju slina

imena
117. Loe biblioteke
Code smells
118. Podatkovne klase
Podatkovne klase su poput djece...
119. Odbijeno nasljedstvo

120. Komentari
Komentari nisu loi :) ali mogu

signalizovati lo kod
Refactoring metode
72 metode u Fowleru
naziv, opis, motivacija, mehanika,

primjeri
Extract Method
izdvojiti dio metode u novu metodu
lokalne varijable pretvoriti u

parametre
Refactoring metode
Form Template Method
iz dvije sline metode izvui jednu

zajedniku
esto omoguuje Pull Up Method
Extract Class
rastaviti klasu na dvije
napraviti jednosmjerni ili dvosmjerni

link, ali samo ako je nuno
koristiti Move Field i Move Method
Refactoring metode
Extract Subclass
klasa ima osobine koje se koriste

samo ponekad - napraviti podklasu
varijacija Replace Type Code with

Subclasses
koristiti Push Down Method/Field
Refactoring metode
Move Method / Field
premjetanje metode ili polja iz jedne

klase u drugu
koristi se kada su klase preintimne

ili isto radi unaprjeenja dizajna
Encapsulate Field
napraviti setter i/ili getter metode
Hide Method
npr. sakriti setter/getter ako ima bolje
Refactoring metode
Inline Class
Pull Up Method / Field
dvije identine metode ili polja u

podklasama izvui u klasu roditelj
da li je programer koristio isto ime za

razliite stvari?
Push Down Method / Field
lake, jer se program nee

kompajlirati ako neto pogrijeite
Refactoring metode
Replace Param. with Method
Preserve Whole Object
metoda poziva niz drugih metoda i

svakoj prosljeuje rezultat prethodne
kao parametar - neka pozvana poziva
poslati itav objekat klasi a ne
pojedinane vrijednosti / metode
Introduce Parameter Object
CASE alati (Eclipse)

Preimenovanje klasa, metoda, polja
Premjetanje metoda i klasa
Push Down i Pull Up
Use Supertype Where Possible
Extract Method - od koda koji ste

selektovali i obrnuto: Inline
Extract Variable / Constant
CASE alati (Eclipse)

Encapsulate Field
Change Signature - potrebno jo

runog popravljanja
Introduce Parameter - uvodi par.

metode umjesto varijable ili polja
Introduce Factory
Conv. Local Variable to Field
Testiranje
Literatura:
Steve McConnell, Code Complete, Chapter 21: Collaborative Construction, Chapter
22: Developer Testing, Chapter 23: Debugging
Pressman, Software Engineering, Chapter 13: Testing Strategies, Chapter 14:
Testing tactics
Somerville, Software Engineering, Chapter 23: Software Testing
Testiranje
Unit testing
Component testing
Integration testing
Regression testing
System testing
Black-box testing
White-box testing
Osnovni principi
Cilj testiranja je da se dokae da
greke postoje - ne obrnuto
Svako ima crnu taku za greke koje sam

pravi
Testing team odvojen od dev teama
Testovi ne dokazuju odsustvo greaka
Test je indikator kvalitete, ali

testiranje ne popravlja kvalitetu
Kada pisati testove?

U teoriji prije, u praksi najee
poslije...
Test-driven development (TDD):

1. zahtjevi
2. analiza i dizajn -> class dijagram
3. class dijagram -> testovi
4. implementacija
5. ...
Kada vriti testove? (2)

Ne treba zaboraviti ni white-box
(prije) ni black-box (poslije)
Test regresije - nakon uoene greke
Testiranje sistema - nakon integracije
ta testirati?
100% unit test coverage - sulud cilj (u
praksi je obino oko 50% sasvim ok)
String dajIme() { return ime; }

^^ ta je ovdje test?
int f(int x) { .. }
^^ treba li testirati sve int brojeve?
Kako testirati?
Testirati rubne sluajeve

dijeljenje s nulom, negativni brojevi, prazan string,
null pokaziva/referenca, prevelik/premali podatak...
ne zaboraviti normalne podatke
ovisi od prirode podataka
zahtijeva programersko iskustvo
Testirati sve grane koda

if - dvije grane koda (uslov ispunjen/nije ispunjen)
petlja - tri grane (0, 1 i n izvrenja), ali uzeti u obzir

rubne sluajeve petlje
Kako testirati? (2)
Data-Flow testing
gdje je varijabla definisana, postavljena, a gdje se

koristi?
Black-Box testiranje
koristiti boolean logiku da ustanovimo koje grane

koda su disjunktne tj. obje e se izvriti ili nijedna
(code smell)
Equivalence partitioning
Client-server testiranje
Real-time testiranje
Kako testirati integraciju?
Testni scenariji
Model ponaanja
iz use-case dijagrama
Statika analiza koda
ta oekujemo od testiranja?
U industriji prosjek je 10-20
greaka na 1000 linija koda
Vai 80-20 pravilo: 80% greaka se

nalazi u 20% koda
Oko 50% greaka su tipfeleri!
Sljedei najei uzrok: loe shvaen

dizajn
Testing procedure otkrivaju max.

60% svih greaka
Jedino pravo testiranje je

koritenje
Testing vs. debugging

Testing = ima li greke?
Debugging = gdje se greka nalazi?

kako je popraviti?
Debugging moe uzeti i do 50%

vremena
Iskustvo vrlo vano
Kako NE raditi debugging

Pronai greku metodom pogaanja
Ne gubiti vrijeme na shvaanje

problema
Rjeavanje problema na oigledan

nain
Programerska praznovjerja
Kako raditi debugging
NAUNA METODA
1. Eksperiment
2. Ponovljiv eksperiment
3. Hipoteza
4. Eksperiment koji obara hipotezu
5. Teorija
Primjena na debugging
1. Stabilizujte greku
2. Locirajte greku
a) Prikupite podatke o greci
b) Formirajte hipotezu
c) Dokaite ili oborite hipotezu
3. Popravite greku
4. Testirajte ispravku greke
5. Pronaite sline greke
Brute-force debugging
Detaljan pregled svake linije koda
Rewrite dijela koda (ili itavog

programa?)
Koristiti debugger za prolazak kroz

svaku liniju koda
Detaljan unit testing
Kreirajte beskonanu petlju koja

poziva kod dok ne doe do greke
Koristiti razliite kompajlere / alate
Kako raditi debugging (2)

Potrebno je shvatiti problem
Da bi se shvatio problem mora se

razumjeti program
Saekajte prije popravke
Minimalan fix je najbolji
Popravljajte greke jednu po jednu (i

aljite svaku popravku na repo!)
Kolaborativne metode razvoja
Cilj je prevencija greaka

Programiranje u parovima
Dvije osobe rade za jednim raunarom
Istraivanja pokazuju dobre rezultate, ipak

neki ga mrze
Formalne inspekcije koda

Detaljan pregled dijelova koda po checklisti
Moderator, autor, inspektor, zapisniar
Vano kontrolisati ego-e!

Ostalo: prezentacije, iitavanje koda
Verifikacija &
validacija (V&V)
Literatura:
Somerville, Pressman, McConnel, predavanja PiKKS ...
Verification:
Is the product done right?
Validation:
Is the right product done?
Verifikacija:
Pravimo li proizvod kako
treba? (Da li je odreena funkcionalnost
korektno implementirana?)
Validacija:
Pravimo li pravi proizvod?
(Da li proizvod proizlazi iz zahtjeva korisnika?)
O verifikaciji i validaciji
Provodi se neprekidno, u svim
fazama ivotnog ciklusa
Ne garantuje da je proizvod savren!
...samo da je dovoljno dobar
1. Pregledi (inspekcije), 2. Metrike, 3.

Testiranje
Potrebno napraviti testni plan
Faktori kvalitete softvera
Korektnost
Upotrebljivost
Efikasnost
Pouzdanost
Integritet
Prilagodljivost
Preciznost
Robusnost
...ali postoje i interni faktori

Mogunost odravanja
(maintainability)
Fleksibilnost
Portabilnost
Mogunost ponovne upotrebe

(reusability)
itljivost
Mogunost testiranja (testability)
Razumljivost
What gets measured,

gets done
Metrike koda
LoC
SLOC, NCSS
Cyclomatic complexity (McCabe)
NPath - broj unit testova

OO metrike
Metrike repozitorija
V&V vrimo po fazama

projekta koristei:
V&V checklist
1. SRS - Validacija
1.1. Da li svaki zahtjev slijedi iz: eksplicitnih
zahtjeva korisnika, optih ciljeva projekta,
tehnologija ili iz okruenja (relevantnih standarda i
normativa...)?
1.2. Da li je zahtjev neophodan (moe li se bez
njega)?
1.3. Da li je zahtjev dovoljno ogranien? Moe li se
protumaiti na pogrean nain?
1.4. Da li je zahtjev realno ostvariv?
2. SRS - Verifikacija
2.1. Da li je zahtjev prezentovan na odgovarajuem
nivou apstrakcije?
- Da li je dovoljno precizno specificiran kako bi
se mogao implementirati?
- Da li je zahtjev previe detaljno specificiran
tako da ograniava opcije kod implementacije?
2.2. Postoje li kontradikcije / konflikti meu
zahtjevima?
2.3. Testabilnost - moe li se pouzdano utvrditi da li
je zahtjev ispunjen?
2.4. Da li su zahtjevi logiki organizovani u cjeline?
3. OOAD - Validacija
3.1. Da li svaka modelirana funkcionalnost slijedi iz
zahtjeva korisnika?
3.2. Postoje li konflikti sa SRS dokumentom
(posebno use-case dijagram)?
3.3. Da li je modelirani sistem u stanju da ispuni sve
postavljene zahtjeve?
3.4. Da li modelirani sistem ispunjava nefunkcionalne
zahtjeve? (npr. modeliran je sistem koji je nesiguran ne ispunjava funkcionalni zahtjev sigurnost)
4. OOAD - Verifikacija
4.1. Postoje li formalne greke u dijagramima (npr.
nisu koriteni odgovarajui simboli, prezentovani su
koncepti koji su nemogui ili neizvodivi itd.)
4.2. Da li su dijagrami na odgovarajuem nivou
apstrakcije? (prekomplikovani / prejednostavni)
Slijede detaljnije provjere nekih dokumenata koji
spadaju pod OOAD.
5. Podaci (ERD) - Validacija

5.1. Da li ERD sadri sve podatke navedene u SRSu?
5.2. Da li sadri podatke koji nisu navedeni u SRSu
niti su potrebni za implementaciju?
6. Podaci (ERD) - Verifikacija

6.1. Da li ERD zadovoljava principe normalizacije?
7. UI specifikacija - Validacija
7.1. Da li UI specifikacija prikazuje sve funkcionalne
zahtjeve?
7.2. Postoje li elementi UI specifikacije koji nisu
navedeni kroz zahtjeve?
7.3. Postoje li elementi koji su realno neizvodivi uz
zahtjeve i ogranienja navedene u SRSu?
8. UI specifikacija - Verifikacija
(ujedno i verifikacija UIja u krajnjem kodu)
8.1. Da li je dizajnirani UI interno konzistentan?
8.2. Da li je dizajnirani UI eksterno konzistentan i
sukladan pravilima platforme (HIG)?
8.3. Da li je dizajnirani UI jednostavan za upotrebu?
8.4. Da li je dizajnirani UI pristupaan (pogodan za
upotrebu tastaturom, za itae ekrana itd.)?
8.5. Da li dizajnirani UI podrava osobine podruja i
jezika za koje e se koristiti prema SRS dokumentu?
8.6. Postoje li besmislene / neodgovarajue poruke?
9. Class dijagram - Verifikacija

9.1. Kohezija: Da li klase dovoljno dobro odgovaraju
konceptima iz problemskog domena?
9.2. Da li su klase prekomplikovane (sadre previe
atributa, metoda)?
9.3. Da li je koriteno nasljeivanje kako bi se
reducirala kompleksnost?
9.4. Da li je stablo nasljeivanja preduboko?
10. Kod - Validacija

10.1. Da li kod sadri sve funkcionalnosti opisane u
SRSu?
10.2. Da li kod sadri funkcionalnosti koje se ne
spominju u SRSu?
10.3. Da li kod odgovara svakom pojedinom dizajn
dokumentu?
11. Kod - Verifikacija

Pored dinamikog testiranja, potrebno je provjeriti i:
11.1. Da li projekat sadri code smells?
- Prije svega: dupliciranje koda, mrtav kod,
varijable koje se ne koriste, predugake klase
ili metode, metode sa previe parametara, klase
sa previe atributa itd.
11.2. Da li je kompleksnost klasa ili metoda
prevelika? (indikator moguih problema)
11.3. Da li je u kodu koritena adekvatna koliina
komentara?
11.4. Nazivi klasa, metoda i promjenljivih?
12. Unit testovi - Verifikacija

12.1. Da li su testovi korektni? (da li se kompajliraju?
ako doe do greke, da li e je test prijaviti?)
12.2. Da li postoje dijelovi koda nepokriveni
testovima koji nisu a) generisani ni b) trivijalni
(setter/getter i slino)?
12.3. Procenat pokrivenosti klasa testovima.
13. Dokumentacija - Validacija

14. Dokumentacija Verifikacija
Ovo za sada ne moete raditi jer jo nismo priali o
dokumentaciji!
Detalji e biti dati kasnije.
Kako rijeiti v&v probleme?
Modifikovati SRS
Problem: korisnik mora odobriti
Modifikovati dizajn dokumente
Modifikovati kod
Problem: puno posla, kaskadni efekti
Modifikovati dokumentaciju
It's a feature!
Dokumentacija
Literatura:
???
Korisnika dokumentacija
(User documentation)
Tehnika dokumentacija
(Technical documentation)
Korisnika dokumentacija
Namijenjena krajnjem korisniku:
uposlenicima, osoblju za podrku
Pisana obinim jezikom
Tehniki termini pojanjeni u indeksu

termina
Piu je tehniki pisci (technical

writers)
IEEE 1063-2001
Vrste korisnike dok.
Korisniki prirunik (User manual)

Korisniki vodi (User guide)
Pomo (Help)
Kontekstualna pomo
Tooltips
Agenti pomonici
Napomene izdanja (Release notes)
READ.ME datoteka
Pomo (Help)
Kontekstualna pomo
Agenti pomonici
Napomene izdanja
Tehnika dokumentacija
Namijenjena osobama koje
modifikuju ili odravaju sistem
U pravilu to su budui uposlenici vae

firme
Ali moe i korisnik zahtijevati
Treba biti to detaljnija i konkretnija

Pie razvojni tim
Vrste tehnike dok.
Komentari u kodu :)
Samo-dokumentujui kod
Dokumentovanje internih APIja
Javadoc, Doxygen
Dijagrami: class, erd, component
Unit Development Folders (UDF)
Upute za instalaciju
Upute za modifikaciju - HACKING.TXT
Poznati bugovi, plan buduih izmjena
Javadoc
http://research.cs.queensu.ca/home/cisc124/2001f/Javadoc.html
Dokumentacija se generie iz komentara

Sva Java dokumentacija je Javadoc!
Javadoc primjer
/** Opis klase MojaKlasa
*
* @author Pero Peric
* @author Meho Mehic
* @version 6.0z r475 3. Jan 1970.
*/
public class MojaKlasa {
/** opis polja mojeIntPolje */
public int mojeIntPolje;
/** Opis konstruktora MojaKlasa()
*
* @throws MojIzuzetak Opis izuzetka
*/
public MojaKlasa() throws MojIzuzetak {
// Bla Bla Bla...
}
/** Opis metode mojaMetoda(int a, String b)
*
* @param a
Opis parametra a
* @param b
Opis parametra b
* @return
Opis vrijednosti koju metoda vraca
*/
public Object mojaMetoda(int a, String b) {...
Dijagrami
OpenOffice.org dijagram meuzavisnosti
komponenti
(component dependency diagram)
INSTALL.TXT
HACKING.TXT
=========================================
D-Bus Python bindings - notes for hackers
=========================================
:Author: Simon McVittie, `Collabora`_
:Date: 2007-01-24
.. _Collabora: http://www.collabora.co.uk/
Upstream development
====================
dbus-python is developed at freedesktop.org using ``git``.
See UsingGit_ for some details.
.. _UsingGit: http://www.freedesktop.org/wiki/UsingGit
Anonymous
``git
Committer
``git
access
clone git://anongit.freedesktop.org/git/dbus/dbus-python``
access (requires freedesktop.org shell account)
clone git+ssh://git.freedesktop.org/git/dbus/dbus-python``
Modules
=======
``dbus``, ``dbus.service`` and ``dbus.mainloop`` are core public API.
``dbus.lowlevel`` provides a lower-level public API for advanced use.
``dbus.mainloop.glib`` is the public API for the GLib main loop integration.
``dbus.types`` and ``dbus.exceptions`` are mainly for backwards
compatibility - use ``dbus`` instead in new code. Ditto ``dbus.glib``.
``dbus._dbus``, ``dbus.introspect_parser``, ``dbus.proxies`` are internal
implementation details.
``_dbus_bindings`` is the real implementation of the Python/libdbus
integration, while ``_dbus_bindings`` is the real implementation of
Python/libdbus-glib integration. Neither is public API, although some
of the classes and functions are exposed as public API in other modules.
Threading/locking model
=======================
All Python functions must be called with the GIL (obviously).
Before calling into any D-Bus function that can block, release the GIL;
as well as the usual "be nice to other threads", D-Bus does its own
locking and we don't want to deadlock with it. Most Connection methods
13. Validacija dokumentacije

13.1. Da li sistem posjeduje sve potrebne vrste
dokumentacije?
13.2. Da li dokumentacija opisuje sve
funkcionalnosti navedene u SRSu?
13.3. Da li dokumentacija navodi pretpostavke i
zavisnosti opisane u SRSu (hardverski zahtjevi
itd.)?
13.4. Da li korisniki prirunik opisuje sve ekrane
navedene u UI specifikaciji?
14. Verifikacija dokumentacije

14.1. Postoje li razlike ili kontradikcije izmeu
dokumentacije i sistema?
14.2. Da li korisnik sa predznanjima opisanim u
SRSu moe instalirati i koristiti sistem uz pomo
dokumentacije?
14.3. Da li za svaki ekran aplikacije postoji
kontekstualna pomo?
14.4. Postoje li nepredviene situacije, rubne
okolnosti itd. i da li su one opisane u dokumentaciji?
14.5. Da li su svi bugovi koje je tim odbio popraviti
dokumentovani?
Instalacija i
odravanje
Literatura:
???
Deployment
Skup aktivnosti koje su potrebne da
bi korisnik poeo koristiti proizvod
Priprema za prelazak u fazu

odravanja (maintenance)
Deployment aktivnosti
Izdavanje softvera (release)
Pakovanje finalnog proizvoda
Instalacija
Aktivacija
Adaptacija
Obuka (poetak obuke)
Update (auriranje)
Izdavanje
Release engineering
Taan skup koraka za kreiranje izdanja
Koja verzija koda je isporuena korisniku?
Da li sve komponente meusobno sarauju

(integracija)?
Release manager
Kontrola revizija krucijalna
Alati: installers, build tools...
Problemi deploymenta
Neadekvatno specificirani zahtjevi

OS ukljuuje Windows, Linux, Solaris,
BSD, OS/2...
Windows ukljuuje Windows 3.1?
Windows XP ukljuuje SP1, SP2, SP3
Home, Professional, Starter Edition
Regional settings
Da li je korisnik akao po sistemu?
nLite, Bart PE...
Problemi deploymenta (2)
tetne interakcije sa sistemom
Problemi sa hardverom
Operativnim sistemom
Drugim softverom na sistemu
Mrenom konfiguracijom
Najbolje isporuiti kompletan sistem :)
Popravke u posljednjem trenutku
Da li je showstopper? Ima li workaround?

Beta proces smanjuje rizik
Odravanje (maintenance)
Ispravke na sistemu radi popravki
greaka, poboljanja performansi i dr.
Korektivne ispravke - inicirane od korisnika
Preventivne ispravke - prije nego to

problem postane efektivan (advisories)
Adaptivne ispravke - reakcija na promjene u

okruenju
Perfektivne ispravke - nove mogunosti ili

poboljanja
Odravanje (2)
Ugovor o odravanju
ta jeste ili nije predmet odravanja?

Pod kojim uslovima?
Zahtjev za odravanje
Slino kao zahtjev za promjenu SRSa:

Prihvaanje/odbijanje zahtjeva, uslovi
Analiza zahtjeva
Preduzimanje akcije (modifikacije)
Instalacija, integracija
Potvrda korisnika da je problem rijeen
Odravanje (3)
Zahtjev moe rezultirati novim
projektom
Patch (zakrpa)
Ispravke ne moraju biti inicirane od

strane korisnika
Automatski update?
Takoe spada u odravanje:

Migracija
Penzionisanje - kraj ivotnog ciklusa softvera,

treba li deinstalirati softver?

Vedran Ove Prez

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vedran Ove Prez

Uploaded by

Copyright:

Available Formats

Zahtjevi

Mogu biti: apstraktan opis usluge ili

Mogu biti polazna taka za pregovore

... ali mogu biti i dio samog ugovora

Primjeri (digitalna biblioteka)

Za razliite tipove datoteka sistem e

Sistem treba biti lagan za upotrebu iskusnim

Iskusan korisnik treba biti u stanju da u

Koraci inenjeringa zahtjeva

Okvirna feasibility studija (obavlja

Uvaiti razliita miljenja

Rezultat je definicija problema i

Korisniki scenariji a.k.a sluajevi

Prvobitni demonstracioni prototip

Izlaz: okvirni spisak zahtjeva,

Korisnik nema informacije!

Dijagrami sluajeva upotrebe (usecase)

Dijagrami aktivnosti (activity)

Dijagrami stanja (state)

Primjena analitikih ablona

Traje tokom itavog ivotnog

IEEE 830-1998 standard

1.1. Svrha dokumenta

IEEE 830-1998 standard str. 2

IEEE 830-1998 standard str. 3

Istovremeni razvoj vie varijanti

ta je isporueno kojem klijentu?

Prosljeivanje krivnje: tano se zna:

neto kao file server, ali:

rcs i cvs: svaka datoteka ima

Verzija na serveru je 7.18

Subversion - pojmovi [2]

Subversion - osnovne naredbe

Klasini RC: klijent server model

Porijeklo zahtjeva: eksterni (korisnik)

Praenje procedure rjeavanja (ko

ivotni ciklus zahtjeva

ivotni ciklus zahtjeva

ETF Forge, sekcija Issues

ETF Forge, sekcija Issues

Tracker: Bug, Feature (zahtjev), Support

Subject: Naslov zahtjeva (4-5 rijei)

Description: Opis zahtjeva

Status: (vidjeti ivotni ciklus)

Priority: planiranje prioriteta zahtjeva

Assigned To: ko e rijeiti zahtjev

Start, Due date: datum poetka i kraja rada na

ETF Forge, sekcija Issues [2]

% Done: koliko je procentualno uraeno?

Files: prilog (attachment)

Watchers: ko e sve biti informisan o promjeni

Mogue je zadati ciljnu verziju kreiranjem

Prototip != alfa verzija

Koristi se u: inenjeringu zahtjeva, procesu

Prototip se treba odbaciti nakon razvoja jer

Zato odbacujemo prototip?

Rapidan razvoj degradira strukturu

Ne zadovoljava standarde kvalitete!

Softver se pie dvaput

Vrste prototipa (1)

(to vie funkcija)

(jedna ili par funkcija detaljno)

Vrste prototipa (2)

(sadri sve funkcije, ali nepotpune)