Skripta RVA

1. Postupci razvoja softvera. Kaskadni i iterativni procesi. - poređenje.

Postupci razvoja softvera se sastoje od analize zahteva, projektovanja, programiranja, testiranja i

isporuke i održavanja. Kod kaskadnog procesa, radi se jedna faza i kada se završi, prelazi se na
drugu sve do kraja isporuke i održavanja. Čest je povratak na analizu i projektovanje i postoji
problem provere da li je projekat na pravom putu. Kod faznog (iterativnog) procesa, projekat se
deli na podskupove po funkciji (npr. jednogodišnji projekat se deli na tromesečne iteracije -
kvartale) i u svakom kvartalu se obavlja četvrtina funkcija, a svaki kvartal sadrži svih 5 faza razvoja.
Istraživanje prethodi iterativnom procesu. Koristi se ranija verzija sistema - release. Mana je
vremensko ograničenje iteracija.

2. UML dijagrami. Namena, načini korišćenja, vrste.

UML je vizuelni jezik koji se koristi za vizuelizaciju, specifikovanje, konstruisanje i dokumentovanje

softverskih sistema.
Namena:
• komunikacija - programera, njegovih kolega iz tima, programera i klijenata
• razumevanje - jasnija slika o sistemu
• preciznost - dobar opis koda sa aspekta OO dizajna
• dokumentacija
Načini korišćenja:
• Izrada skica - najčešće korišćen, neformalan i dinamički način. Često se ne koriste sva
pravila UML-a. Postoje dva načina:
1. Direktan razvoj (forward engineering) - UML se crta pre pisanja koda
2. Povratna analiza (reverse engineering) - dijagram se pravi prema postojećem kodu
• Opis projekta - potpuni dijagrami, detaljan opis sistema, omogućuje jednoznačno direktno
pisanje koda. Koriste se složeniji alati za izradu UML projekata.
• Programski jezik - kada se celokupan sistem opisuje UML dijagramima - UML se koristi kao
programski jezik. UML dijagrami se neposredno prevode u izvršni kod (UML je izvorni kod)
Vrste:
• Strukturni dijagrami
1. Dijagram klasa
2. Dijagram komponenti
3. Kompozitno strukturni dijagram
4. Dijagram objekata
...
• Dijagrami ponašanja
1. Dijagram aktivnosti
2. Use Case dijagram
3. Dijagram stanja
4. Dijagram interakcija
a) Sekvencijalni dijagram
b) Vremenski dijagram
c) Komunikacioni dijagram
...
 Agregacija predstavlja "
celina-deo" odnos gde
jedan objekat može biti
deo više celina. To je
slabiji oblik
kompozicije.Simbol:
3. Blokovi za izgradnju UML-a. Klase i relacije. Prazan romb na strani
celokupnog
objekta.Primer:
Blokovi: Department —
• Stvari (things) CourseplaintextCopy
code+-----------------+<>---
1. Strukturne - klasa, interfejs, kolaboracija, komponenta, čvor -------->+-----------------+|
2. Statusna - poruka, stanje Department | |
Course
3. Grupišuće - paket |+-----------------+
4. Anotacija - komentar +-----------------+|
-deptName | |
• Relacije -courseName ||
1. Zavisnost - označava da promena u specifikaciji jedne stvari može uticati na drugu stvar |
-deptID |
(obrnuto ne mora da važi). -courseCode
|+-----------------+
+-----------------+|
+addCourse() |
| +addStudent()
|+-----------------+
+-----------------+3.
Kompozicija
(Composition)
Kompozicija je jači oblik
agregacije gde deo ne
može postojati bez
2. Asocijacija - povezuje dve klase. Opciona podešavanja: ime asocijacije (npr. "radiceline.
za"),Kada se celina
uništi, uništavaju se i
usmerenje, uloge, višestrukost (min/max kardinaliteti), grupisanje. Prenošenje osobina
delovi.Simbol: Popunjen
realizuje se nasleđivanjem. romb na strani
celokupnog
objekta.Primer: House —
RoomplaintextCopy
code+-----------------+<#>-
--------->+-----------------+|
House | |
Room
|+-----------------+
+-----------------+|
-address | |
-roomNumber ||
-numRooms |
| -size
|+-----------------+
+-----------------+|
+addRoom() |
|
|+-----------------+
+-----------------+4.
Generalizacija
3. Generalizacija - povezuje opštiju klasu sa specifičnijom (natklasa/potklasa). Potklasa
(Inheritance)
može da ima svoje atribute. Generalizacija ili
nasleđivanje predstavlja
odnos gde jedna klasa
nasleđuje osobine i
ponašanje druge
klase.Simbol: Prazna
strelica sa punom
linijom.Primer: Person —
StudentplaintextCopy
code+-----------------+
+-----------------+|
Person |<|------------|
Student
|+-----------------+
+-----------------+| -name
| | -studentID
|| -birthDate |
4. Realizacija - relacija između interfejsa i klase koja ga implementira +-----------------++-----------
------+ | +enroll
• Dijagrami (course) || +displayInfo()
|
+-----------------++-----------
------+ 5.
Realizacija (Realization)
Realizacija se koristi za
prikazivanje odnosa
Klasa je skup objekata koji dele iste atribute, operacije, relacije i semantiku. Grafički se predstavlja
pravougaonikom. Atribut je imenovana osobina klase bitna za aspekt modelovanja. Operacija je
apstrakcija akcije nad objektom.

4. Dijagrami klasa. Osnovni i napredni elementi.

Klasni dijagram je najčešće korišćen dijagram. Opisuje tipove objekata u sistemu i veze izeđu njih.
Objekti imaju svojstva (properties) i operacije. Svaka klasa ima javne, privatne, zaštićene i paketne
elemente. Atributi opisuju svojstvo klase (npr. - cena : double). Kardinalitet može biti 1, 0..1, *.
Operacije su aktivnosti koje klasa može da obavlja (npr. + Pozovi (string brojTelefona) : bool).
Napomene i komentari se mogu pojaviti na svakoj vrsti dijagrama. Nezavisni su od drugih
elemenata ili su spojeni isprekidanom linijom sa elementima koje objašnjavaju. Statičke operacije i
atributi se odnose na celu klasu, ne na njenu instancu. Relacija agregacije predstavlja odnos celina-
deo (npr. automobil-guma). Kompozicija je specijalan slučaj kada svaka instanca mora pripadati
samo jednom vlasniku. Izvedena svojstva se mogu izračunati na osnovu drugih svojstava i
označavaju se kosom crtom (npr. - /duzina: int; - pocetak: int; kraj: int; duzina = kraj - pocetak).
Objekti apstraktne klase se ne mogu napraviti, već samo njene podklase. Ona sadrži apstraktne
operacije. Nije realizovana, već deklarisana. U UML-u su napisane iskošeno.
Interfejs je klasa koja nije realizovana i označava se sa <<interface>>. Klasa može da realizuje
interfejs ili da zahteva interfejs. Jedna od razlika je to što apstraktna klasa može da ima apstraktne i
neapstraktne metode, a interfejs samo apstraktne.
Klasa asocijacija omogućuje da se asocijacijama dodaju atributi i operacije koje se čuvaju samo u
jednoj klasi. Može postojati samo jedan primerak ove klase.

Nabrojive liste prikazuju se rečju enumeration.

5. Dijagrami sekvence

Najčešći dijagram interakcije je dijagram sekvence. Koriste se kada se želi posmatrati ponašanje
objekta u okviru jednog slučaja upotrebe. Prikazuje jedan scenario koji obuhvata više objekata i
poruka koje oni razmenjuju za dati slučaj korišćenja. Opisuje interakciju između objekata prikazanih
vertikalnom linijom života i poruka koje se čitaju odozgo nadole. Elementi dijagrama su učesnici-
objekti, poruke, linija života, traka aktivnosti, primljena poruka. Nisu zgodni za prikazivanje petlji i
uslova, ali to se može odraditi okvirima interakcije. U okvire se dodaju operatori, npr. loop za petlju
sa jednim fragmentom, opt za uslov sa jednim fragmentom itd. Ako su poruke sinhrone (pošiljalac
čeka na odgovor), vrh strelice je popunjen, ako su asinhrone (pošiljalac nastavlja sa radom bez
čekanja odgovora) onda je prazan.
6. Dijagrami aktivnosti

Dijagram aktivnosti je jedan od dijagrama ponašanja. Opisuje tok poslovne logike. Za razliku od
dijagrama toka, može da prikaže paralelno ponašanje. Polazi se od početnog čvora, može doći do
grananja (paralelne radnje), sinhronizacije paralelnog izvršavanja (oznaka join), odluke (jedan
ulazni tok i nekoliko uslovnih izlaznih) i stapanja (više ulaznih tokova i jedan izlazni). Particije
pokazuju koja klasa ili celina izvršava date akcije. Signali se mogu primati i slati. Vremenski signal
nastaje zbog protoka vremena. Signal ukazuje da aktivnost prima spoljašnji događaj.

7. Dijagrami slučajeva upotrebe

Dijagram slučajeva upotrebe je jedan od dijagrama ponašanja. Opisuju uobičajene interakcija

korisnika i sistema. Slučaj upotrebe (use case) je skup scenarija povezanih jednim ciljem korisnika.
Učesnik je uloga korisnika u odnosu na sistem (npr. kupac, prodavac, direktor). Jedan učesnik može
da izvodi više slučajeva upotrebe, a jedan slučaj upotrebe može da ima više učesnika. Bolji termin
od učesnika je uloga (role).
Primer: Kupac pregleda katalog i dodaje proizvode u korpu. Kada kupac hoće da plati, on daje
informacije o načinu dostave i platnoj kartici i potvrđuje kupovinu. Sistem proverava ispravnost
podataka o platnoj kartici i potvrđuje prodaju, neposredno, a zatim i putem elektronske pošte.
Postoji poseban scenario ukoliko podaci o kartici nisu ispravni. Svi scenariji imaju isti cilj.
Na početku se bira jedan osnovni uspešan scenario, a zatim se dodaju drugi scenariji kao
proširenja. Definiše se glavni učesnik, a zatim sporedni. U slučajeve upotrebe mogu se dodati
preduslov (uslov da počne korišćenje), garancija (stanje sistema na kraju slučaja upotrebe - uspeh/
neuspeh), okidač (događaj koji inicira slučaj upotrebe).
Dijagrami slučajeva upotrebe nisu mnogo dokumentovani, bitno je tekstualno ih obraditi. Oni treba
da budu spoljni pogled na sistem, a ne da opisuju klase sistema.

8. Dijagrami stanja

Dijagram stanja je jedan od dijagrama ponašanja. Početno pseudostanje se vezuje za nastanak

objekta. Prelaz ukazuje na pomeranje iz jednog stanja u drugo. Ima obeležje koje se sastoji iz 3
dela: potpis-okidača [uslov] / aktivnost. Svi delovi su opcioni. Potpis-okidača je događaj koji
omogućava promenu stanja. Uslov je logički izraz koji mora biti tačan da bi došlo do promene
stanja. Aktivnost je ponašanje koje se izvršava tokom prelaza. Završno stanje zaustavlja promene.
Npr. Da bi se otkrila brava sefa, mora se ukloniti specijalna sveća iz svećnjaka, ali vrata pri tome
moraju biti zatvorena. Potpis-okidača je "uklonjena sveća", uslov je "zatvorena vrata", a aktivnost
je "otkrivanje brave".

9. Dijagrami interakcije – Dijagrami komunikacije, dijagrami pregleda interakcija, vremenski

dijagrami

Dijagram interakcije je jedan od dijagrama ponašanja. Vrste dijagrama interakcije su:

• Dijagrami komunikacije - Naglašava povezanost podataka između učesnika u interakciji.
Omogućava proizvoljan raspored učesnika. Korišćenje decimalnih brojeva za raspoređivanje
poziva. Umesto brojeva mogu se koristiti oznake poput B4, C2 itd. (različite niti). Koristi se
za isticanje veze između učesnika.
• Dijagrami pregleda interakcija - Može se posmatrati kao dijagrami aktivnosti koji su
predstavljeni dijagramima sekvenci.
• Vremenski dijagrami - Ima više načina prikaza ovih dijagrama (stanja - linije, stanja - oblasti).
 • Dijagrami sekvence - Naglašava redosled i vreme angažovanja učesnika u toku interakcije
(određenog scenarija).

10. Dijagrami strukture – Dijagrami komponenata, složene strukture, dijagrami raspoređivanja,

dijagrami objekata i dijagrami paketa

Dijagrami komponenata - Komponenta je

analogna običnoj klasi. Komponente su delovi
koji se mogu nezavisno kupovati i
nadograđivati. Podela sistema na komponente
je komercijalna, a ne tehnička odluka.

Dijagrami složene strukture - Omogućuju hijerarhijsko

razdvajanje klase (složeni objekat se rastavlja na delove).
Pruža nam pogled na unutrašnjost komponente. Klasa je
razložena na dva dela. Delovi klase nisu specifikacije instance.
Dva načina prikaza klase:

Dijagrami raspoređivanja - Otkrivaju fizičku organizaciju sistema i delove aplikacije koji se izvršavaju
na određenim delovima računarskog sistema. Osnovni elementi su čvorovi:
• Uređaj - fizički element
• Izvršno okruženje - program koji sadrži neki drugi program, npr. operativni sistem
• Sadrži artefakte - fizička manifestacija softvera (najčešće datoteke: izvršne, konfiguracione,
podaci, HTML dokumenti)
Komunikacione putanje između čvorova označavaju da se između delova sistema obavlja
komunikacija.

Dijagrami objekata - Presek objekata sistema u nekom trenutku (uglavnom instance, ne klase).
Naziva se i dijagram instanci. Može se posmatrati i kao dijagram komunikacije bez poruka.

Dijagrami paketa - Paketi se dobijaju grupisanjem elemenata (bilo koje strukture UML-a, ne samo
klasa) u celine višeg nivoa (veliki broj klasa, dijagrama, use case). Oni su u hijerarhijskoj strukturi -
klasa pripada paketu, paket drugom paketu itd. Svaki paket pripada jednom namespace-u. U isti
paket treba stavljati klase koje treba menjati iz istih ili sličnih razloga ili one koje će se zajedno
koristiti. Na dijagramima je moguće prikazati sadržaj paketa.

11. Stilovi arhitekture. Podela i karakteristike.

Stilovi softverske arhitekture su familije sistema - obrasci (paterni) strukture. Korisno je poznavati
softverske obrasce jer nam to omogućuje da prepoznamo koji obrazac nam je najpogodniji za
korišćenje kada krećemo sa nekim projektom. Podela stilova po kategorijama:
• Komunikacija
◦ Servisno-orijentisana arhitektura (SOA)
◦ Arhitektura zasnovana na porukama (Message Bus)
• Raspoređivanje
◦ Klijent-server
◦ N-slojna
◦ 3-slojna
 • Domen
◦ Dizajn vođen domenom
• Struktura
◦ Arhitektura zasnovana na komponentama
◦ Objektno-orijentisana arhitektura
◦ Slojevita arhitektura
◦ Mikroservisna arhitektura
Stilovi nisu isključivi.
Klijent-server arhitektura je dvoslojna arhitektura. Inicijalno je to UI-baza podataka, a opštije
gledano klijent-jedan ili više servera. Druge varijante ovog stila su: klijent - queue - klijent sistemi,
P2P, aplikativni serveri.
Arhitektura zasnovana na komponentama dekomponuje dizajn na funkcionalne ili logičke
komponente sa jasno definisanim interfejsima, metodama, atributima. Obezbeđuje viši nivo
apstrakcije od objektno-orijentisanog stila. Komponente mogu višestruko da se koriste, da se
menjaju, koriste u različitim okruženjima, proširive su, nezavisne.
Dizajn vođen domenom je objektno-orijentisan stil fokusiran na modelovanje poslovnog domena.
Potrebno je dobro poznavanje poslovnog domena.
Slojevita arhitektura je logička arhitektura, tj. razdvaja tipove po funkcionalnosti. Slojevi se mogu
nalaziti na istom ali i na različitim fizičkim računarima. Komponente komuniciraju u istom sloju i sa
susednima, a nekad i sa svim slojevima ispod sebe. Minimizira zavisnost između slojeva u cilju što
manjih promena.
Arhitektura zasnovana na porukama koristi kanale komunikacije kojima softverski sistem šalje i
prima poruke. Obično koristi ruter poruka ili Message Queueing. Strane koje komuniciraju su slabo
povezane.
Višeslojna fizička arhitektura (N-tier, 3-tier) predstavlja višeslojnu arhitekturu kod koje se delovi
aplikacije izvršavaju na različitim računarima. Uglavnom ima 3 sloja: prezentacioni, poslovni i sloj za
pristup bazi podataka. Svaki sloj je nezavisan od ostalih, osim što komunicira (obično asinhrono) sa
ostalim slojevima.
Objektno-orijentisani stil omogućuje programiranje na nivou objekata. Objekti predstavljaju
komponente sa određenim funkcionalnostima.
Servisno-orijentisana arhitektura obezbeđuje funkcionalnosti putem servisa. Servisi koriste
standardne interfejse. Servisi su organizovani tako da budu autonomni.
Mikroservisna arhitektura se poistovećuje sa korišćenjem cloud-a. Mikroservisi su organizovani
tako da aplikacija može da se razvija nezavisno od cloud-a, pa se posle postavi na cloud. Microsoft-
ov Service Fabric je razvojno okruženje koje omogućuje razvoj mikroservisa i testiranje aplikacije u
lokalu. Postoji simulator koji simulira izvršavanje aplikacije na cloud-u. On nudi dve vrste servisa:
statefull i stateless. Servisi su raspoređeni na više fizičkih računara (nodova) i ukoliko primarni
servis na jednom otkaže, sekundarni preuzima njegovu ulogu (failover). U cloud-u je to vreme
minimalno. Podaci su replicirani na sve nodove na kojima se nalaze sekundarni servisi. Replikacija
se obavlja tako što se piše i čita iz primarnih, a promene se prosleđuju u sekundarne i oni vraćaju
potvrdu. Do rekonfiguracije dolazi kada primarni server otkaže (sekundarni postaje primarni), kada
sekundarni otkaže (uklanjanje njega), pri obnavljanju replike i izgradnji novog sekundarnog
servisa/noda.

12. Tehnike za dizajniranje arhitekture

Potrebno je jasno definisanje ulaza (slučajevi korišćenja, funkcionalni zahtevi, tehnološki uslovi
itd.). Sam proces dizajniranja je iterativni proces koji se koristi za formiranje arhitekture, jako je
bitno jasno definisati ciljeve, važne slučajeve upotrebe kao i ključna pitanja. Osnovne faze su
identifikovanje ciljeva, definisanje ključnih scenarija, kreiranje izgleda aplikacije, identifikacija
ključnih pitanja i definisanje kandidata (prototipa). Horizontalne analize su po slojevima, a
vertikalne su interakcija između slojeva.

13. Osnovne faze dizajniranja softverske arhitekture

Osnovne faze su:

• Identifikovanje ciljeva arhitekture- Potrebno je definisati početne ciljeve arhitekture,
identifikovati korisnike, identifikovati ograničenja. Npr. kreiranje kompletnog dizajna
aplikacije, razvoj prototipa itd. Vreme je bitan faktor (ograničenje).
• Definisanje ključnih scenarija - Definisanje slučajeva upotrebe (skupova interakcija izmežu
sistema i jednog ili više aktera) se radi pomoću UML-a. Scenario koji šire opisuje interakcije
korisnika i sistema od slučaja korišćenja se piše kao tekst. Ključni scenariji su skup
najvažnijih scenarija.
• Kreiranje izgleda aplikacije - Odrediti kako će aplikacija da izgleda kad se završi, tip
aplikacije, infrastrukturna ograničenja, važne arhitektonske obrasce, relevantne tehnologije
i skicirati arhitekturu aplikacije.
• Identifikacija ključnih pitanja - Identifikovati kritična pitanja vezana za arhitekturu: promena
poslovnih zahteva (Da li se može preći na novi tip klijenta?) i promena tehnologije (Da li se
može migrirati na drugu tehnologiju?)
• Definisanje kandidata (prototipa) - Kreira se inicijalna osnovna arhitektura. Vrši se validacija
na osnovu osnovnih ključnih scenarija i definisanih zahteva. Moguće je modifikovati
arhitekturu više puta u više iteracija.

14. Slojevite arhitekture. Osnovne karakteristike

Aplikacija se deli po slojevima po različitim funkcionalnostima i ulogama. Podela na slojeve je

najviši nivo apstrakcije - logička argitektura sistema. Najčešća je troslojna aplikacija koja sadrži sloja
za prezentaciju, poslovni sloj (osnovna logika funkcionisanja sistema) i sloj podataka (omogućuje
pristup nekim podacima, baza podataka ili server). Može postojati servisni sloj, preko koga se
definišu kanali za pristup biznis sloju, ponaša se kao dodatni posrednik između prezentacionog i
biznis sloja.

15. Koraci projektovanja slojevite arhitekture

Koraci su sledeći:
1. Izabrati strategiju slojevitosti (definišu se načini grupisanja funkcionalnosti po slojevima)
2. Odrediti potrebne slojeve (kako i na koji način ćemo odrediti slojeve)
3. Odlučiti kako distribuirati slojeve i komponente (distribuiranje slojeva se radi saom kada je
neophodno, npr. kada želimo da ispunimo neke zahteve bezbednosti)
4. Utvrditi da li treba spojiti slojeve (kada je logika prosta pa neki sloj nije potreban)
5. Odrediti pravila za interakciju između slojeva (jednosmerna, dvosmerna itd.)
6. Identifikovati poprečne nadležnosti (da li se neki delovi mogu ponovo koristiti)
7. Definisati interfejse između slojeva (svaka izmena interfejsa je jako osetljiva)
8. Izabrati strategiju raspoređivanja (na koliko mesta i gde staviti određene komponente)
9. Izabrati komunikacione protokole
16. Prezentacioni sloj. Komponente, karakteristike

Prezentacioni sloj se deli na komponente korisničkog interfejsa (UI) i prezentacione logike (obrasci
poput MVC-a). MVC obrazac deli UI interakcije na tri izdvojene uloge: View, Controller, Model.
Zahteva analizu i definiciju tipa aplikacije, UI tehnologije, projektantskih obrazaca (npr. MVC),
dizajniranja entiteta i korisničkih zahteva.

17. Dizajn poslovnog sloja. Komponente, karakteristike

Obično sadrži komponente:

• Application Facade (obezbeđuje interfejs ka komponentama poslovne logike, klijent može
direktno preko njega da pistupa)
• Poslovna logika
◦ Workflow komponente - koraci-tokovi poslovnog procesa
◦ Komponente entiteta - npr. Customers ili Orders, validacija podataka
Projektantska pravila za poslovni sloj su:
• Da li je potrebno izdvojiti poslovni sloj?
• Idenifikovati nadčežnosti i korisnike poslovnog sloja
• Ne mešati različite vrste komponenti
• Smanjiti komunikaciju ka udaljenom poslovnom sloju
• Izbegavati čvrstu povezanost između slojeva
Posebni projektantski zahtevi: autentifikacija, autorizacija, keširanje, povezanosti (coupling) i
kohezija, rukovanje izuzecima, logovanje, validacija
Koraci u dizajniranju poslovnog sloja:
• Kreiranje dizajna visokog nivoa
• Projektovanje poslovnih komponenti
• Projektovanje komponente poslovnih entiteta
• Projektovanje toka poslovnog procesa
Osnovni obrasci:
• Transaction Script (proceduralni stil, jedna procedura za svaku poslovnu transakciju)
• Domain Model (objektno-orijentisani model podataka i ponašanja, polazi se od
pretpostavke da ne postoji baza podataka, sinonim za Domain Driven Design)
• Table Module (mapira objektni model na model baze, jedan objekat predstavlja tabelu u
bazi)

18. Sloj podataka. Komponente, karakteristike

Predstavlja sloj kod koga imamo mogućnost pristupa nekim izvoruma podataka na osnovu
poznavanja njihove destinacije i opisa samih podataka. Najčešće komponente koje se ovde
pojavljuju omogućuju i sam pristup tim podacima. Pristup je centralizovan, omogućena je
sinhronizacija i konzistentnost podataka. U okviru ovih komponenti je omogućena i logika pristupa
podacima u cilju efikasnijeg pristupa podacima. Najčešće komponente su pristup podacima (tu
spada centralizacija pristupa podacima i logika pristupa podacima) i servisni agenti (upravljaju
komunikacijom sa određenim servisima iz susednih slojeva i izoluju različite zahteve, obezbeđuju
npr. keširanje, mapiranje podataka).
19. Servisni sloj. Komponente, karakteristike

Servisni sloj obično ima zadatak da bude posrednik između prezentacionog sloja i poslovnog sloja i
da po potrebi omogući nekim spoljašnjim sistemima/servisima pristup našoj aplikaciji. Obično
sadrži interfejse servisa i tipove poruka (strukture sa podacima iz poruka da bi se komunikacija
mogla izvršiti)

20. Karakteristike loše dizajniranog softvera

• Krutost (rigidnost) - Dizajn je teško promeniti, promene se propagiraju preko zavisnosti na

druge module, nemogućnost prilagođavanja i proširivanja postojećeg koda
• Krhkost - Dizajn je lako razbiti, promene se kaskadno propagiraju na različitim mestima,
rešenje jednog problema uzrokuje druge probleme
• Nemobilnost - Nemogućnost prenošenja određene komponente u drugo okruženje, dizajn
je teško ponovo iskoristiti, zamršen je
• Viskoznost - Dva tipa: viskoznost softvera (promene koda ili dodavanje funkcionalnosti je
lakše implementirati na "pogrešan" način) i viskoznost okruženja (dugo kompajliranje,
veoma povezane komponente, dugotrajno testiranje)
• Nepotrebna složenost - Dizajn sadrži delove koda koji se trenutno ne koriste, možda će
nekad zatrebati, to je suprotno agilnim principima
• Nepotrebno ponavljanje koda (copy-paste) -Nedostatak apstrakcije programera,
ponavljanje bug-ova
• Nejasnoća - Moduli postaju nejasni tokom vremena i potreban je konstantan napor za
održavanje čitljivog koda

21. Smernice prilikom dizajniranja komponenti

Primeniti SOLID principe:

• S - Single Responsibility Principle
• O - Open Closed Principle
• L - Liskov Substitution Principle
• I - Interface Segregation Principle
• D - Dependency Inversion Principle
Projektovati komponente sa velikom kohezijom (da se funkcionalnosti između komponenti ne
mešaju dok podaci koje neka komponenta koristi u okviru svojih metoda treba da budu u njoj). Na
neku komponentu ne treba da utiču detalji implementacije druge komponente. Treba razumeti
kako će komponente komunicirati, odvojiti kod poprečnih funkcionalnosti (bezbednost,
komunikaciju) od logike aplikacije, primeniti ključne principe arhitekturalnog stila baziranog na
komponentama.

22. Single Responsibility Principle (SRP)

Bavi se kohezijom na nivou komponenti. Njegovo pravilo je da jedna klasa treba da ima samo jedan
razlog za promenu (samo jednu odgovornost). Promena jedne odgovornosti može narušiti ili
onemogućiti sposobnost klase da ispuni drugu odgovornost.
23. Open/Closed Principle (OCP)

Softverski entiteti (klase, moduli, entitet) treba da budu otvoreni za proširenja, ali zatvoreni za
modifikacije. Da bi se ovo implementiralo potrebno je da se koristi apstrakcija (npr. klijent-server).
Proširenje predstavlja dodavanje novih funkcionalnosti, a modifikacija promenu postojećih.
Modifikacija uzrokuje izmenu postojećih metoda i funkcionalnosti i direktno utiče na uspešnost
izvršavanja testova čime je u mnogome ugrožena funkcionalnost softvera.

24. Liskov Substitution Principle (LSP)

Njegovo pravilo je da bazni tipovi treba da budu zamenjivi njihovim podtipovima. Narušavanje LPS-
a često uzrokuje narušavanje OCP-a (primer kvadrat i pravougaonik).

25. Interface Segregation Principle

Klijenti ne treba da zavise od metoda koje ne koriste (primer sigurnosna vrata, klasa ne treba da
nasleđuje interfejs koji ima metode koje ta klasa ne koristi)

26. Dependency-Inversion Principle

• Moduli višeg nivoa ne treba da zavise od modula nižeg nivoa. I jedni i drugi bi trebalo da
zavise od apstrakcije
• Apstrakcije ne bi trebalo da zavise od detalja, već obrnuto
Kada imamo distribuirane aplikacije koje poseduju objekte koji treba međusobno da komuniciraju,
one ne bi trebalo direktno da referenciraju jedan drugog, nego da zavise od inerfejsa koji jedan
implementira, a drugi koristi.

27. Projektni obrasci

Aleksandrova definicija obrasca: Svaki obrazac opisuje problem koij se stalno pojavljuje u našem
okruženju i zatim opisuje srž rešenja tog problema tako da se to rešenje može koristiti milion puta
na različite načine. On je smatrao da sve dobre građevine imaju zajedničke osobine, da procena da
je lepa građevina nije samo stvar ukusa i da treba tražiti zajedničke osobine u okviru problema koji
se rešavaju. Karakteristike softverskih obrazaca su: ime, namena, problem, rešenje, učesnici i
saradnici, posledice, realizacija. Klasifikacija obrazaca na osnovu domena (nivo apstrakcije): klase ili
objekti, a na osnovu namene: kreacioni, strukturalni/arhitektonski i obrasci ponašanja.

28. Softverski obrazac - Unikat

Unikat(Singleton) je kreatorski obrazac koji govori na koji način i šta je potrebno implementirati
kako bi se obezbedila funkcionalnost jedne instance klase sa globalnim pristupom. Npr. imamo
jedan serverski objekat i više klijentskih objekata koji mu pristupaju. Imajući u vidu da klijenti dele
informacije međusobno (neko šalje a neko ćita sa servera) i svi oni imaju pristup samo jednom
serveru, pitanje je kako sinhronizovati komunikaciju između servera i klijenta prilikom startovanja
servera. Singleton nam govori baš to, na koji način i šta je potrebno implementirati na serveru kako
bi se obezbedila funkcionalnost jedne instance klase sa globalnim pristupom. Klijent dobja pravu
instancu tipa Singleton preko metode getInstance() bez da vodi računa da li ona postoji ili ne. Ta
metoda proverava da li je instanca formirana ili je NULL. Ukoliko je NULL, kreiramo instancu, u
suprotnom vraćamo mu već napravljenu. Problem nastaje ukoliko više klijenata istovremeno
pozove tu metodu i tada se svakom od njih vraća nova instanca servera, a to ne želimo. To se rešava
pomoću atomskih regiona i mogućnošću njihovog zaključavanja. Primenjuje se duplo zaključavanje,
ukoliko oba klijenta prođu prvi uslov i dođu do drugog dela provere samo jedan klijent može da
kreira instancu do se drugom samo prosledi ta napravljena.

29. Softverski obrazac - Komanda

Komanda pripada klasi obrazaca ponašanja. Može se koristiti za vraćanje stanja pre izvršavanja
zahteva - undo, izvršavanje zahteva preko redova čekanja, pravljenje dnevnika zahteva (logging) i sl.
Zahtevi se pretaraju u objekte koji su podklasa apstraktne klase Komanda, sa operacijom Execute()
i Undo().

30. Softverski obrazac - Adapter

Adapter je strukturni obrazac. Pretvara interfejs klase u drugi interfejs koji klijent očekuje.
Predstavlja nešto što se koristi za prilagođavanje u svakodnevnom životu (npr. punjač telefona,
slušalice). Nije potrebno menjati klasu našeg sistema, kao ni klasu sistema sa kojim želimo da
izvršimo spajanje, dodatni kod i sve promene se vrše u adapteru.

31. Softverski obrazac - Fasada

Fasada je strukturni obrazac. Fasada je ono što posmatrač vidi spolja, što skriva unutrašnjost.
Fasada pojednostavljuje interfejs, dok Adapter menja interfejs u neki drugi. Ona skriva realizaciju
funkcionalnosti klasa ili interfejsa. Pruža jednostavan interfejs ka podsistemu. Služi da bi se izbegao
veliki broj zavisnosti između klijenata i klasa, već se sve obavlja preko njenih metoda.

32. Softverski obrazac - Šablonski metod

Šablonski metod (Template) je obrazac ponašanja. Ukoliko postoje klase koje koriste slične metode,
potrebno je kreirati apstraktnu Template klasu koju će implementirati konkretne klase u kojima će
biti definisane metode iz Template klase. Primer recept za kafu i čaj. Template klasa ima jednu
metodu koja određenim redom poziva sve ostale, a te ostale metode su implementirane u
konkretnim klasama koje je nasleđuju.

33. Softverski obrazac - Sastav

Sastav je strukturni obrazac. Podrazumeva sastavljanje objekata u hijerarhijsku strukturu (stabla).

Klijenti tada mogu uniformno da tretiraju i proste i složene objekte iz ove strukture. Primer
direktorijum sadrži stavke - fajlove i druge direktorijume. Upravlja se potomcima pomoću metoda
addChild() i removeChild().

34. Softverski obrazac - Posmatrač

Observer je obrazac ponašanja. Definiše zavisnost

objekata - kada dođe do promene stanja jednog objekta,
obaveštavaju se zavisni objekti. Primer više otvorenih
prozora koji prikazuju ista stanja i klijenti ih ažuriraju.
Uvodi se objekat za obaveštavanje kako bi se izbegla
tesna povezanost između objekata.
35. Softverski obrazac - Prototip

Prototip je kreatorski obrazac. Omogućava da se kada imamo dosta objekata koji liče jedan na
drugi (isti su) novi objekti prave kopiranjem postojećeg objekta prototipa. Primer note i notne
linije. Postoje dve vrste kopiranja u C#: MemberwiseClone() - plitko kopiranje (shallow copy) gde se
ne kopiraju referencirani objekti i IClonable interfejs sa Clone() metodom koja pravi novu instancu
sa svim istim poljima kao i postojeća - deep copy. Korisnik bira na koji način će implementirati
metodu za kopiranje.

36. Softverski obrazac - Strategija

Strategija je obrazac ponašanja. Koristi se kada hoćemo da

definišemo neku familiju algoritama. Da bi se izbegao veliki broj
uslovnih iskaza, iz te klase se uklanja algoritam i prebacuje se u
posebne klase (razdeljuje se kako ne bismo imali uslove). Strategy
obrazac omogućava klijentu da odabere koji algoritam želi da koristi
iz familije postojećih. Primer patke koje na isti način kvaču i plivaju,
ali različito izgledaju. Tada klasa za prikaz njihovog izgleda treba da
bude implementirana u klasi konkretne vrste patke.

37. Softverski obrazac - Muva

Muva je strukturni obrazac. Koristi se kada imamo potrebu da rukujemo velikim brojem objekata.
Ne pravi pojedinačne instance za svaki od potrebnih objekata (primer navijača na utakmici), već
koristi deljeni objekat - muvu. Glavna prednost je smanjenje memorije. Mana je nemogućnost
nezavisnog upravljanja instancom u okviru muve.

38. Softverski obrazac - Dekorater

Dekorater je strukturni obrazac. Koristi se kada želimo dinamički da pridružimo neke dodatne
funkcionalnosti objektu. Koristi se kod multi-layer struktura (npr. korisnički interfejs, kafa sa raznim
dodacima itd.). Svaku od dodatnih odgovornosti pakujemo u jedan objekat. Objekti se hijerarhijski
referenciraju. Koristi open-closed princip, da klasa treba da bude otvorena za proširenja, a
zatvorena za modifikacije.

39. Softverski obrazac - Proizvodni metod

Factory metod je kreatorski obrazac. Radi se o metodi za pravljenje objekata, odnosno definisanje
interfejsa u okviru kojeg se nalazi metoda za pravljenje objekta. Cilj ovog obrasca je da se odvoji
objekat koji se pravi od klijenta, tj. implementacija koju klijent poziva od njega samog. Na taj način
se vrši enkapsulacija implementacije podataka.

40. Softverski obrazac - Apstraktna fabrika

Apstraktna fabrika je kreatorski obrazac i predstavlja proširenje Factory method obrasca. Koristi
interfejs za pravljenje familija povezanih objekata kojih klijenti nisu svesni. Klijent metodama
apstraktne fabrike prozvodi konkretne proizvode. Učesnici su apstraktna fabrika, konkretna fabrika
(nasleđuje apstraktnu), apstraktni objekat, konkretni objekat (nasleđuje apstraktni i kreira ga
konkretna fabrika).
41. Softverski obrazac - Proksi

Proksi je strukturni obrazac. Služi za posredovanje između

objekta koji pruža servis i objekta koji koristi servis u cilju
implementacije kontrole pristupa, transparentnog pristupa
udaljenim objektima i sl. Klijent nije svestan da postoji
posrednik između njega i objekta koji obezbeđuje servis.
Vrste su daljinski, virtuelni, zaštitni i pametni proksi. Proksi najčešće obavlja neke operacije pre i
posle poziva metode realnog subjekta kao što su provera prava, oslobađanje resursa itd.

42. Softverski obrazac - Iterator

Iterator je obrazac ponašanja. Koristi se za sekvencijalno pristupanje elementima kolekcija bez

uvida u unutrašnjost objekta. Npr. pristupanje elementima liste, klasa iterator definiše interfejs za
pristupanje njima, pruža podršku za više istovremenih obilazaka iste kolekcije kao i jedan interfejs
za obilaženje različitih kolekcija. Interfejs Iterator ima metode First(), Next(), IsDone() i
CurrentItem().

43. Softverski obrazac - Stanje

Stanje je obrazac ponašanja. Omogućava da objekat promeni

ponašanje kad mu se promeni unutrašnje stanje. Omogućen je
prelazak iz jednog stanja u drugo. Primer mrežna konekcija sa
više stanja povezanosti. U Context klasi se čuva stanje i u
zavisnosti od trenutnog konkretnog stanja, zahtev se izvršava na određeni način. Time se
izbegavaju glomazni uslovi.

44. Refaktorisanje koda

Refaktorisanje predstavlja izmenu koda u cilju lakšeg razumevanja i jednostavnije modifikacije, ali
bez promene njegovog ponašanja. Osnovno pravilo je ostaviti kod u boljem stanju nego što si ga
zatekao. Proces refaktorisanja omogućava olakšano održavanje, dobro testiranje, TDD (Test Driven
Development). Preporučuje se konstantno testiranje refaktorisanog koda.

45. Tipovi refaktorisanja koda

• Refaktorisanje "čišćenje smeća" - podrazumeva čišćenje koda od očiglednog smeća. Neki od

razloga postojanja takvog koda su stalno dodavanje funkcionalnosti, neiskusan programer
itd. Čišćenjem koda omogućuje se brže i jednostavnije dodavanje novih funkcionalnosti.
• Refaktorisanje sa razumevanjem - podrazumeva promenu imena klasa, metoda ili
promenljivih, kao i izdvajanje blokova u posebne metode radi lakšeg razumevanja. Postavlja
pitanje šta radi neki blok koda.
• Pripremno refaktorisanje - podrazumeva refaktorizaciju pre dodavanja nove
funkcionalnosti, jer struktura koda nije bila adekvatna. Nakon izmene je olakšano
dodavanje novih funkcionalnosti.
• Planirano refaktorisanje - planira se u okviru posebnih user story-ja, koristi se za
popravljanje većih celina u kodu, ponekad se unapred definiše refaktorisanje.
• Dugoročno refaktorisanje - se radi kada je neophodno izmeniti relacije i takve izmene
zahtevaju više meseci rada. Npr izmena modela podataka, mehanizma komunikacije i sl.