1. Analiza sistema je razlaganje problema na delove, tj. potprobleme (PP) koje moemo da razumemo i koje moemo da reimo. Veze izmeu potproblema su izuzetno vane, jer mogu biti kljuni faktor u nalaenju reenja sloenog problema. Sinteza reenja je sklapanje parcijalnih reenja (R) u cilju nalaenja kompletnog reenja problema. 2. Aplikativni softver ine programi napravljeni za specifinu svrhu i nisu u direktnoj vezi sa hardverom. Pri svom izvravanju oslanjaju se na sistemski softver, posebno na operativni sistem. Obino se kupuju odvojeno od raunarskog hardvera. Sistemski softver obuhvata programe na niskom nivou (low-level) koji slue za kontrolu operacija nad raunarskom opremom. 3. Neoekivana upotreba sistema usled zloupotrebe usled nestrunog rukovanja Trite diktira brz razvoj softvera brza isporuka ostavlja malo vremena za testiranje, pa su greke ee ponekad je tee ispraviti uoene nedostatke, nego napisati kompletan novi softver Kvalitet je neophodan to je nedostatak due neotkriven, njegovo otklanjanje vie kota (trokovi ispravljanja greke u fazi analize su 10 puta manji od trokova nakon isporuke). 4. Kvalitet softvera mora se posmatrati na vie naina: Kvalitet proizvoda Kvalitet postupka izrade proizvoda Kvalitet proizvoda u kontekstu poslovnog okruenja u kome e se koristiti 5. Karakteristike proizvoda koje odreuju kvalitet zavise od toga ko analizira softver: Korisnik smatra da je softver kvalitetan ako radi na odgovarajui nain, lako se ui i koristi. Korisnik meri: tip i broj otkaza Projektantrazmatra interne karakteristike proizvoda i procenjuje nedostatke. Projektant meri: broj nedostataka u zahtevima, projektu i kodu. Modeli kvaliteta dovode u vezu spoljni pogled korisnika i unutranji pogled programera na softver 6. Boehm-ov model kvaliteta (Boehm i dr., 1978.) je jedan od najpoznatijih modela. On predstavlja hijerarhiju karakteristika od kojih svaka doprinosi ukupnom kvalitetu. U model su ukljuena oekivanja kako korisnika, tako i programera.

Po ovom modelu, kvalitetan softver je onaj koji: radi ono to korisnik od njega trai, ispravno i efikasno koristi raunarske resurse, jednostavan je za uenje i korienje, dobro je projektovan, dobro kodiran i lako se testira i odrava.

PrenosivostPouzdanost

Samosadrivost Tanost Potpunost Robustnost/integritet

Efikasnost

Doslednost Odgovornost

Opta korisnost

Osnovni naruilac

Ljudsko inenjerstvo

Efikasnost ureaja Pristupanost

Mogunost testiranja

Komunikativnost Samoopisivost Strukturisanost

Mogunost odravanja

Razumljivost

Mogunost izmene

Saetost itljivost Proirivost

7. Kvalitet sa aspekta poslovanja se posmatra u zavisnosti od proizvoda i usluga koje prua poslovni sistem iji je softver sastavni deo. Pri tome se analizira poslovna vrednost proizvoda.

Tehnika vrednost proizvoda Poslovna vrednost proizvoda

Povratak investicije ........

Krai put do kupca Kvalitet proizvoda Kvalitet procesa

Produktivnost

8.

Kupac je kompanija, Projektant jekompanija, organizacija ili pojedinac koji pravi softverski sistem za kupca.a ez av ob rna o u ov eb Ug otr ap Im

Kupac

organizacija ili pojedinac koji finansira razvoj softverskog sistema.

Korisnik jejedan ili vie pojedinaca koji e stvarno koristiti sistem.

Softverski sistem Ima potrebu

Projektant

Kupac

Uesnici u projektu mogu istovremeno da imaju vie uloga. Na primer, ako neki sektor u kompaniji razvija sam softver za svoje potrebe, on je istovremeno i kupac i korisnik i projektant.

9.Faze u razvoju softvera su: Analiza i definisanje zahteva. U ovoj fazi se u saradnji sa kupcem utvruju zahtevi koji opisuju sistem. Pri njihovom definisanju uzimaju se u obzir entiteti, aktivnosti i ogranienja koja postoje u sistemu, kao i interakcija sistema sa okruenjem. Projektovanje (dizajn) sistema. U cilju zadovoljenja definisanih zahteva, generie se projekat sistema koji opisuje finkcionalnost sistema i njegov izgled sa stanovita kupca. Projekat obino sadri snimke ekrana, izvetaje koji e se generisati, interakciju sistema sa korisnikom, itd. Projektovanje programa. Kada kupac odobri projekat sistema, generiu se pojedinani podprojekti pogodni za programsku realizaciju. Implementacija (pisanje) programa.

Testiranje modula. Nakon pisanja programa, najpre se testiraju individualni delovi koda, tj. pojedinani moduli. Testiranje integrisanog sistema. Moduli se povezuju u celinu i testira se da li moduli dobro rade u spezi sa drugim modulima.

Zavrno testiranje sistema. Proverava se da sistem slui svojoj nameni, tj. da li zadovoljava postavljene zahteve. Isporuka sistema.

Odravanje. Tokom upotrebe sistema mogu se uoiti razni problemi koje treba reavati. napomena Proces razvoja softvera je svaki opis razvoja softvera koji sadri neke od nabrojanih faza, organizovanih tako da proizvode proveren kod. 10.

SPECIFIKACIJA SPECIFIKACIJA ZAHTEVA ZAHTEVA

MODEL MODEL PROCESA PROCESA RAZVOJA RAZVOJA

ISPORUENI ISPORUENI PROIZVOD PROIZVOD

Razlozi za modelovanje procesaKada grupa opie primenjivani proces projektovanja, opis postaje zajedniko shvatanje aktivnosti, resursa i ogranienja ukljuenih u razvoj softvera. Modelovanje pomae u nalaenju nedoslednosti, vikova i izostavljenih elemenata u samom procesu, to poboljava efikasnost procesa. Model treba da odraava ciljeve razvoja. Nakon izrade modela projektni tim ocenjuje aktivnosti sa aspekta njihove usklaenosti sa postavljenim ciljevima. Svaki proces mora biti napravljen prema situaciji u kojoj e se primenjivati. Modelovanje procesa pomae da projektni tim utvrdi mesta na kojima su potreba prilagoavanja.

11. Kaskadni model ili model vodopada (Royce, 1970.) predstavlja veoma visok nivo apstrakcije razvojnog procesa ije su faze kaskadno prikazane.ANALIZA ZAHTEVA ANALIZA ZAHTEVA PROJEKTOVANJE PROJEKTOVANJE KODIRANJE KODIRANJE

Osobine modela Jedna faza razvoja treba da se u potpunosti okona pre poetka sledee faze.

Za svaku aktivnost procesa definiu se kritine take i meuproizvodi, to olakava praenje stepena gotovosti projekta. Prednosti modela

TESTIRANJE TESTIRANJE OPERATIVNI RAD OPERATIVNI RAD I ODRAVANJE I ODRAVANJE

Jednostavnost koja olakava pruanje objanjenja kupcima. Dobijanje pune funkcionalnosti sistema. Eksplicitno ukazivanje na meuproizvode koji su neophodni za zapoinjanje sledee faze. Pogodan za sluaj kada je neophodno odjednom zameniti stari sistem Nedostaci modela Ne odraava povratne sprege koje zbog greaka i nepreciznosti zahteva postoje u stvarnosti. Sistem je obino preveliki da se uradi u jednoj iteraciji. Nije pogodan kod znatnih izmena zahteva.

12.

V model (nemako Ministarstvo odbrane, 1992.) je modifikovani kaskadni model koji pokazuje odnos testiranja i faza analize i projektovanja, inei eksplicitnim neke povratne sprege koje su skrivene u kaskadnom modelu.ANALIZA ZAHTEVA ANALIZA ZAHTEVA Validacija zahteva

OPERATIVNI RAD I OPERATIVNI RAD I ODRAVANJE ODRAVANJE

PROJEKTOVANJE PROJEKTOVANJE SISTEMA SISTEMA Verifikacija projekta PROJEKTOVANJE PROJEKTOVANJE PROGRAMA PROGRAMA KODIRANJE KODIRANJE

ZAVRNO ZAVRNO TESTIRANJE TESTIRANJE TESTIRANJE TESTIRANJE SISTEMA SISTEMA

TESTIRANJE DELOVA TESTIRANJE DELOVA I INTEGRACIJE I INTEGRACIJE

V model se prvenstveno bavi aktivnostima i ispravnim radom sistema, za razliku od kaskadnog modela koji je usredsreen na dokumente i meuproizvode. Kako se koristi V model?

Testiranje delova, testiranje sistema pri integraciji i testiranje sistema bave se ispravnou programa i mogu se koristiti za verifikovanje dizajna programa. Zavrni test slui za validaciju zahteva, tj. proveru da li su svi zahtevi potpuno implementirani. Ako se pronau problemi tokom verifikacije ili validacije, aktivnosti sa leve strane V modela mogu se ponoviti radi popravke i poboljanja zahteva, dizajna ili koda, pre nego to se ponove testiranja na desnoj strani modela.

13.

PROJEKTNI TIM

Fazni razvoj je nain projektovanja softvera koji omoguava isporuivanje sistema u delovima, tako da je korisnicima na raspolaganju jedan deo funkcija, dok je ostatak funkcija jo u razvoju. Zato obino postoje dva sistema koji uporedo funkcioniu: produkcioni i razvojni sistem.Razvojni sistemi

Izrada verzije 1

Izrada verzije 2

Izrada verzije 3Vreme

KORISNICI

Produkcioni sistemi

Upotreba verzije 1

Upotreba verzije 2

Upotreba verzije 3

Produkcioni sistem je onaj koji trenutno koriste naruilac i korisnik. Razvojni sistem predstavlja sledeu verziju koja se priprema da zameni postojei produkcioni sistem. Sistemi se obino nazivaju prema rednom broju njihove verzije. Tako, projektni tim uvek radi na verziji n+1, dok je verzija n u fazi operativnog korienja.

14.

Inkrementalni razvoj podrazumeva da se sistem u skladu sa specifikacijom zahteva deli na podsisteme prema funkcijama. Verzije se definiu kao funkcionalni podsistemi, tako da se svakoj novoj verziji prikljuuju nove funkcije. Sistem se nadograuje do potpune funkcionalnosti.

Iterativni razvoj takoe podrazumeva podelu sistema na podsisteme prema funkcijama, ali se potpun sistem isporuuje u svim verzijama, s tim to se u svakoj novoj verziji menjaju funkcije svakog podsistema. Svaka sledea verzija unapreuje prethodnu.

15.

Prototipski model se zasniva na izradi prototipova. Ovaj model omoguava da se kompletan sistem ili delovi sistema brzo konstruiu radi razjanjenja ili boljeg razumevanja otvorenih pitanja, sve sa ciljem smanjenja rizika i neodreenosti prilikom projektovanja sistema.LISTA REVIZIJArevizija prototipa

LISTA REVIZIJA

LISTA REVIZIJA

pogled korisnika ili naruioca PROTOTIPSKI PROTOTIPSKI PROJEKAT PROJEKAT PROTOTIPSKI PROTOTIPSKI SISTEM SISTEM TEST TEST ISPORUENI SISTEM

PROTOTIPSKI PROTOTIPSKI ZAHTEVI ZAHTEVI ZAHTEVI SISTEMA (nekada neformalni ili nekompletni)

Prototip je delimino razvijen proizvod koji omoguava naruiocima i projektantima da ispitaju neke aspekte predloenog sistema i odlue da li je on pogodan i potreban u sklopu gotovog proizvoda.

Definisanje skupa zahteva od strane naruioca i korisnika. Ispitivanje alternativa (analize moguih ekrana, tabela i dr. izlaza iz sistema). Revizija zahteva prema eljama naruioca i korisnika. Prelazak na fazu projektovanja. Istraivanje varijanti u projektovanju. Revidiranje inicialnog dizajna dok svi uesnici ne budu zadovoljni. Ako se pri razmatranju varijanti dizajna naie na probleme koji potiu od zahteva, vraa se na ponovnu specifikaciju zahteva. Kodiranje sistema uz razmatranje varijanti sa moguim iteracijama kroz zahteve i dizajn.

16. Spiralni model (Boehm, 1988.) posmatra razvoj softvera u svetlu prisutnih rizika tako to kombinuje aktivnosti razvoja sa upravljanjem rizicima. Na taj nain se postiu manji rizici, a i njihova kontrola je olakana.Po spiralnom modelu, proces razvoja softvera se odvija u 4 iteracije:Zahtevi i plan razvoja Validacija zahteva 1. Opis funkcionisanja sistema na visokom nivou apstrakcije 2. Definisanje skupa zahteva 3. Generisanje dizajna sistema Testiranje 4. Testiranje Validacija i verifikacija dizajna Dokument Principi rada

U svakoj iteraciji, radi se analiza rizika koja identifikuje rizike i odreuje razliite varijante sa aspekta zahteva i ogranienja za njihovo minimiziranje. Zatim se izradom prototipova verifikuju izvodljivost i pogodnost varijanti pre nego to se odabere odgovarajua.

17.

Agilne metode (Agile Alliance, 2001.) su nastale kao otpor mnogim ranijim modelima razvojnog procesa koji su pokuavali da nametnu neki oblik discipline vezane za osmiljavanje softvera, dokumentovanje, razvoj i testiranje. Ideja je da se naglasi uloga fleksibilnosti u spretnom brzom razvoju softvera. 4 principa agilnog razvojaZa uspenost projekta najvaniji su kvalitet ljudi koji na njemu rade i kvalitet njihove saradnje. Postupci i alati imaju sporedni znaaj. Bolje je uloiti vreme u izradu softvera koji radi, nego u izradu sveobuhvatne dokumentacije. Umesto planiranja i praenja plana, vanije je odgovarati na promene, jer se ne mogu svi zahtevi predvideti na poetku razvoja. Zajedniki rad sa naruiocem je vrlo vaan, jer se tako naruilac ukljuuje u kljune aspekte razvoja.

18.ekstremno_programiranje

Komunikacija podrazumeva neprestanu razmenu informacija izmeunaruioca i projektnog tima.

Jednostavnost ohrabruje projektni tim da odabere najjednostavniji dizajn iliimplementaciju koji odgovaraju potrebama naruioca.

Odvanost je posveenost blagovremenim i estim isporukama funkcija. Povratne sprege se ugrauju u razliite aktivnosti tokom procesa razvoja.Igra planiranja. Generiu se mape svihbuduih verzija (ta sadre i rokovi isporuke).

Programiranje u paru. Kolektivna svojina. Svaki uesnik moe daizmeni bilo koji deo sistema, dok je on u fazi razvoja.

Male verzije. Funkcije su dekomponovanena male delove koji se isporuuju, a zatim proiruju. Koriste se inkrementalni i iterativni ciklusi.

Metafora. Pojektni tim se usaglaava okozajednike vizije rada sistema.

Neprekidna integracija. Rade se dnevneili satne isporuke. Naglasak na malim inkrementima poboljanja.

Jednostavan dizajn.Tretiraju se samoaktuelne potrebe.

Odriv korak. Umorni ljudi vie gree.Sugerie se 40 sati nedeljno rada. Ako to nije dovoljno, neto nije u redu (rokovi ili resursi).

Testovi pre kodiranja. Funkcionalnetestove definie naruilac, a izvrava tim. Testove delova realizuje tim radi verifikacije.

Naruilac raspoloiv na terenu. Standardi kodiranja. Insistira se na njimazbog boljeg razumevanja u timu.

Preraivanje koda. Promena zahtevaprimorava tim da preispita postojea reenja. Ovo je najvei problem.

19. Unified Modeling Language

UML se koristi za modelovanje i projektovanje softverskih sistema, naroito sistema pravljenih primenom objektno-orijentisanih tehnologija.UML je skup grafikih notacija zasnovanih na jedinstvenom metamodelu. Notacija je skup grafikih elemenata koji se koriste u modelima, tj. grafika sintaksa jezika za modelovanje. Metamodel predstavlja dijagram koji definie koncepte jezika za modelovanje.

20.

Direktni razvoj (forward engineering) UML dijagramgenerisanje

Programski kod

Povratna analiza (reverse engineering) Programski kod21.nacini korescenaj uml-a: -izrada skica -izrada projekata -kao programski jezik 22. Skice opisuju pojedine aspekte sistema korienjem UML-a kao pomonog sredstva. Osobine skica: predstavljaju najei nain upotrebe UML-a obino se generiu neformalno i dinamiki, tako da se rade brzo i na tabli nepotpune su i uglavnom imaju obavetajni karakter omoguavaju jednostavno ispitivanje vie alternativnih reenja mogu se koristiti u dokumentaciji Skice u direktnom razvoju: sadre samo nekoliko znaajnih problema koji e se javiti u kodu saoptavaju ideje i alternative predstojeeg posla vizualizuju delove projekta pre programiranja tumaenje

UML dijagram

Skice u povratnoj analizi: objanjavaju kako radi neki deo sistema (samo klase o kojima je vano razgovarati)

23. UML projekti opisuju sistem sveobuhvatno, kako bi se programiranje koje predstoji svelo uglavnom na mehaniku aktivnost. Osobine UML projekata: za izradu projekata koriste se sloeni, tzv. CASE alati za raunarsko projektovanje softvera projekti se moraju dosledno sprovoditi Direktni razvoj: Projekti sadre detaljan opis sistema, obino do nivoa interfejsa podsistema (dalja razrada realizacije se preputa programerima), na osnovu koga se pie kod. CASE alati omoguavaju crtanje dijagrama i uvanje informacija u memoriji. 24.Parcijalno UML modelovanje programiranje Intenzivno UML modelovanje CASE alati UML modelovanje celog sistemaIzvorni kod

Povratna analiza: Projekti sadre detaljne informacije o kodu u obliku papirne ili elektronske dokumentacije. Mogu prikazati svaki detalj neke klase u grafikom obliku koji programer razume. CASE alati itaju izvorni kod, tumaenja stavljaju u memoriju i generiu dijagrame.

CASE alati

automatizacija

Programski kod

Programski kod

Programski kod

UML postaje programski jezik u sluaju kada se celokupni sistem modelira UML dijagramima, a zatim se ti dijagrami primenom CASE alata . neposredno prevode u izvrni kod. Tada UML postaje izvorni kod, to odgovara programskom jeziku. Ovaj nain upotrebe UML-a jo nije doiveo punu praktinu afirmaciju.

25. Dijagram klasa opisuje tipove objekata u sistemu i razliite vrste statikih veza koje postoje meu njima, kao i ogranienja u nainu njihovog povezivanja. Dijagrami klasa su najee korieni dijagrami UML-a. Najbogatiji skup tehnika za modelovanje u UML-u imaju upravo dijagrami klasa. Model klase Ime klase Atributi klase Operacije klasedatumNaruivanja:Date[0..1] plaenoUnapred:Boolean[1] Broj:String[1] cena:Novac poalji zakljui

Primer klase Porudbina

26.Naini predstavljanja na dijagramu Upotreba

Atributi Svojstva klase Asocijacije

za predstavljanje manje vanih svojstava, kao to su datumi ili logike promenljive

za eksplicitno isticanje vanih klasa u sistemu

Veina informacija se moe prikazati ravnopravno na oba navedena naina, mada postoje i neke razlike meu njima. Izbor naina prikazivanja se ne zasniva na znaenju pojmova, ve na tome ta elimo da naglasimo na dijagramu.

27. Kardinalnost pokazuje na koliko objekata se odnosi neko svojstvo. Definie se donjom (DG) i gornjom granicom (GG) u obliku DG..GG, za koje vae sledea pravila: Donja granica moe biti bilo koji pozitivan broj ili 0. Gornja granica moe biti bilo koji pozitivan broj ili *(znai da nema ogranienja). Ako su donja i gornja granica jednake, moe se koristiti jedan broj. Umesto 0.. *, to je est sluaj, moe se koristiti samo *. Najei primeri kardinalnosti

(pr. Kupac moe poslati nula ili vie porudbina, nema gornje granice.) 28. Atribut opisuje neko svojstvo u jednom redu teksta unutar odgovarajueg dela klase. Potpuni oblik zapisa atributa vidljivost ime: tip kardinalnost = podrazumevana-vrednost {opis-svojstva}Objanjenje vidljivost (visibility) oznaava da li je atribut javni (+) ili privatni (-) ime (name) odreuje ime atributa u klasi tip (type) ukazuje na tip atributa u klasi kardinalnost (multiplicity) ukazuje na broj objekata na koje se odnosi atribut podrazumevana-vrednost (default value) je vrednost atributa u novom objektu opis-svojstva (property string) definie dodatne osobine atributa

2..4 1 0..1 mora.) *

(pr. U timu mogu da uestvuju 2 do 4 programera.) (pr. Jedna porudbina mora imati tano jednog kupca.) (pr. Za klijentsku firmu moe biti zaduen poseban predstavnik, ali ne

29. Asocijacija opisuje neko svojstvo punom linijom izmeu dve klase, usmerenom od izvorne klase ka odredinoj. Ime svojstva je na odredinom kraju asocijacije, kao i njena kardinalnost. Odredina klasa odreuje tip svojstva. Kardinalnost asocijacije moe biti definisana na oba kraja linije. Izvorna klasaime svojstva kardinalnost

Odredina klasa

Primer asocijacijeDate0..1 + datumNaruivanja izvor odredite * stavke {ordered}

Porudbina1

+ plaenoUnapred 1

Boolean

StavkaPorudbine

30. Operacije su aktivnosti koje klasa moe da obavi. operacija klase klase deklaracija procedure metod Vrste operacija: telo procedure Upiti ne menjaju stanje sistema, tj. nemaju sporedne efekte vraaju proitanu vrednost iz klase redosled izvravanja im se moe menjati, a da se ne promeni ponaanje sistemaPodtip operacijametod3

Primer polimorfizma Nadtip operacijametod

Podtip operacijametod1

Podtip operacijametod2

Modifikatori menjaju stanje sistema obino nemaju rezultat

Sintaksa operacija na UML-u

vidljivost ime (lista-parametara) : tip-rezultata {opis-svojstva}Primer operacije

+ stanjeNa (datum:Datum) : Novacvidljivost oznaava da li je operacija javna (+) ili privatna (-) Objanjenje ime je niz znakova lista-parametara je lista parametara operacije Sintaksa parametara operacije je: smer ime: tip = podrazumevana-vrednostime, tip i podrazumevana-vrednost imaju isto znaenje kao u sintaksi atributa smer pokazuje da li je parametar ulazni (in), izlazni (out), ili ulazno-izlazni (inout)

tip-rezultata ukazuje na tip rezultata operacije opis-svojstva ukazuje na svojstva operacije (pr. query)

31. Zavisnost izmeu dva elementa postoji ako promene definicije jednog elementa, tzv. davaoca (supplier), mogu izazvati promene drugog elementa, tzv. klijenta (client).Upravljanje zavisnostima je vrlo vano jer se svaka promena u sistemu reflektuje na druge elemente koji se onda moraju menjati. Izmene u klasama se reflektuju samo preko interfejsa.

Razlozi zavisnosti izmeu klasa: jedna klasa alje poruku drugoj jedna klasa sadri drugu klasu objekat jedne klase prosleuje objekat druge klase kao parametar neke operacije

klijent

Prozor za pregled bonusazavisnost

davalac

Zaposleni

Podaci o zaposlenima

Podaci o bonusima

32. Dijagram sekvence (DS) opisuje saradnju objekata prilikom neke aktivnosti. DS uspeno prikazuju saradnju, tj. interakciju izmeu objekata, ali nisu pogodni za precizno definisanje ponaanja objekata. Korisni su kada treba analizirati vie sluajeva korienja. DS opisuju interakciju pomou: Linije ivota (lifeline) vertikalna isprekidanalinija koja predstavlja uesnika u interakcijilinija ivota poruka traka aktivnosti

Ime klase

Poruke (message) linije zavrene strelicomkoje se itaju odozgo na dole

Traka aktivnosti (activation bar) pravougaonik na liniji ivota koji pokazuje kada je uesnik aktivan u interakciji

33.

Centralizovano upravljanjeporudbinaraunajCenu

stavka porudbineuesnik

proizvod

kupac

uzmiKoliinu uzmiProizvod proizvod uzmiPodatkeOCeni

primljena poruka

povratak

raunajOsnovnuCenu povrat ni poziv uzmiPodatkeOPopustima

raunajPopuste

Kod centralizovanog upravljanja, jedan uesnik obrauje najvei deo podataka, dok ga drugi uesnici snabdevaju njima. Ovaj nain upravljanja je jednostavniji i pogodan za poetnike, s obzirom da se celokupna obrada odvija na jednom mestu.

Distribuirano upravljanjeporudbinaraunajCenu raunajCenu uzmiCenu(koliina:number) parameta r

stavka porudbine

proizvod

kupac

uzmiCenuSaPopustom(porudbina) uzmiOsnovnuCenu

povratak cenaSaPopustom

Kod distribuiranog upravljanja, obrada je rasporeena izmeu vie uesnika, od kojih svaki izvrava deo algoritma. Ovaj nain upravljanja je manje pregledan, ali je efikasan i obino ga koriste iskusniji projektanti.

34.

Pravljenje i brisanje uesnikaupit nad bazom podataka

Upravlja

Notacija za pravljenje uesnikaNacrtati strelicu poruke koja je povezana neposredno sa oznakom uesnika. Ime poruke se moe zadati (nov), ali ne mora. Ako uesnik odmah po nastanku zapone aktivnost, traka aktivnosti se crta neposredno ispod oznake uesnika.

nov

Upitnov

pravljenj e

Naredba baze podatakaizvri

rezultati izdvoj rezultate brisanje iz drugog objekta

Notacija za brisanje uesnikaOznaka za brisanje uesnika je X. Brisanje jednog uesnika od strane drugog oznaava se strelicom poruke. X na kraju linije ivota znai da uesnik brie samog sebe.rezultati

zatvori

brisanje samog sebe

35.Notacija za prikazivanje petljiUvode se okviri interakcije (interaction frames) koji obuhvataju deo dijagrama sekvence (fragment). Svaki okvir sadri operator, a moe mu biti pridruen i uslov. operatorNapomena: Dijagrami sekvence nisu pogodni za prikazivanje petlji i uslova, pa je za njihovo modelovanje bolje koristiti dijagrame aktivnosti ili kod. okvir interakcijeporudbina stavka proizvod kupac

loop

[for each stavka]uzmiKoliinu uzmiProizvod proizvod uzmiPodatkeOCeni raunajOsnovnuCenu

uslov

raunajPopuste uzmiPodatkeOPopustima

Operator alt loop opt

Znaenje Alternativni izbor fragmenata izvrava se samo onaj iji je uslov ispunjen Petlja fragment se izvrava vie puta, uslov daje osnov iteracije Opcioni fragment se izvrava samo ako je uslov ispunjen

36. Sluajevi korienja su nain prikupljanja funkcionalnih zahteva sistema. Oni opisuju uobiajene interakcije izmeu korisnika i sistema u obliku prie. Sluaj korienja je skup scenarija povezanih jednim ciljem korisnika. Scenario je niz koraka koji opisuje interakciju izmeu korisnika i sistema. Primer tri scenarijaKupac pregleda katalog i dodaje proizvode u korpu. Kada hoe da plati, on daje informacije o nainu dostave i platnoj kartici i potvruje kupovinu. Sistem proverava ispravnost podataka o platnoj kartici i potvruje prodaju. Podaci o kartici su netani. Ako je kupac redovan, nije potrebno uzimati podatke o dostavi i kartici. Razlika izmeu sluaja korienja i funkcija sistema je u tome to imaju razliitu namenu. Funkcije opisuju sistem, a sluajevi korienja opisuje kako korisnici koriste sistem.

37.

Sadraj sluaja korienjaPrimer uobiajenog zapisa

Nain pisanja sadraja sluaja korienja nije standardizovan, pa format zavisi od sluaja. Postupak pisanjaNavesti osnovni uspeni scenario u vidu numerisanih koraka. Navesti sva odstupanja od osnovnog scenarija, tj. proirenja, sa referisanjem na mesta povratka (ako ih ima).

Kupovina proizvoda Nivo cilja: osnovni Osnovni uspean scenario: Kupac pregleda katalog i bira proizvode koje hoe da kupi Kupac zavrava pregled kataloga Kupac unosi podatke o isporuci (adresa, isporuka kroz tri dana) Sistem prikazuje sve podatke o trokovima (sa potarinom) Kupac unosi podatke o platnoj kartici Sistem proverava podatke o nainu plaanja Sistem odmah potvruje prodaju Proirenja: 3.a Kupac je redovan :1 Sistem prikazuje podatke o isporuci, cenama i iznosu rauna :2 Kupac potvruje ili menja podrazumevane vrednosti, povratak na korak 6. 6.a Podaci o platnoj katrici nisu ispravni :3 Kupac moe ponovo uneti podatke o kartici ili prekinuti rad

Korisni savetiSvaki korak predstavlja deo interakcije uesnika i sistema. Opis koraka mora biti jasan i da ukazuje na njegovog izvrioca. Korak pokazuje nameru uesnika, a ne nain kako se neto ostvaruje.

38.

Ukljueni sluajevi korienja

Jedan, sloeniji sluaj korienja moe da ukljuuje (includes) druge, jednostavnije sluajeve korienja. Ne postoji standardan nain tekstualnog prikazivanja ukljuenog sluaja korienja, ali se kao pogodna mogunost preporuuje podvlaenje koje ukazuje na hipervezu.PrimerKupovina proizvoda Nivo cilja: osnovni Osnovni uspean scenario: Kupac pregleda katalog i bira proizvode koje hoe da kupi Kupac zavrava pregled kataloga ....................

Kada se koriste ukljueni SK?

Pogodni za opisivanje sloenih koraka koji bi zauzeli puno prostora u osnovnom scenariju. Pogodni za opisivanje koraka koji se ponavljaju u vie sluajeva korienja. Nije pogodno praviti vie nivoa ugnjedavanja.

39. Dijagram sluajeva korienja je grafiki prikaz sadraja skupa sluajeva korienja. Ukazuje na granice sistema i njegovu interakciju sa spoljnim svetom. Prikazuje uesnike, sluajeve korienja i veze izmeu njih: koji uesnici izvravaju koje sluajeve korienja koji sluajevi korienja ukljuuju druge sluajeve korienjaDefinisanje ogranienja Komercijalni direktor Analiza rizika Utvrivanje cene Komercijalista uesnik Utvrivanje potranje sluaj korienja granica sistema Prodavac Auriranje podataka o raunima include ukljuuje Utvrivanje vrednosti

Sistem naplate

include

40. Sluajevi korienja se mogu razvrstati po sledeim nivoima:

Osnovni nivo (sea-level) centralni sluajevi koji obino predstavljaju pojedinane interakcije izmeu glavnog uesnika i sistema. Oni daju rezultat znaajan za glavnog uesnika. Nii nivo (fish-level) - sluajevi korienja ukljueni u sluajeve osnovnog nivoa. Vii nivo (kite-level) obino poslovni sluajevi korienja koji pokazuju kako se sluajevi osnovnog nivoa uklapaju u iri kontekst poslovnih interakcija.

Najvei broj sluajeva korienja treba da bude na osnovnom nivou. 41. Dijagrami aktivnosti slue za opisivanje logike procedura, poslovnih postupaka i toka posla.Akcija

poetni vor

Struktura dijagrama aktivnosti Poetak: akcija poetnog vora (initial node) Izvravanje akcije Grananje (fork): ima jedan ulazni tok i nekoliko paralelnih izlaznih tokova Spajanje (join): ima vie ulaznih tokova i jedan izlazni tok koji zapoinje tek kada svi ulazni tokovi stignu do take spajanja Kraj: zavrni vor

grananje

Akcija

spajanje Akcija zavrni vor

Postoji razlika izmeu aktivnosti i akcije. Aktivnost predstavlja niz akcija, pa dijagram aktivnosti prikazuje aktivnost koja je sainjena od akcija. vorovi u dijagramu aktivnosti su akcije, a ne aktivnosti.

42. Dijagram aktivnosti ima mogunost prikazivanja paralelnih ponaanja, to je bitno jer se mnogi postupci u praksi odvijaju paralelno. Redosled izvravanja akcija koje se odvijaju paralelno nije vaan (mogu se naizmenino kombinovati akcije iz razliitih tokova). Kod paralelnog izvravanja bitna je sinhronizacija, to se prikazuje oznakom spajanja.poetni vor Primljena narudbina grananje akcija Pripremi narueno [prioritetna narudbina] odluk a Poalji fakturu

[else]

tok/ivica

Hitna isporuka

Obina isporuka Naplati

stapanje spajanje Zakljui narudbinu zavrni vor

43.U dijagramu aktivnosti uslovno ponaanje se opisuje odlukama i stapanjima.poetni vor Primljena narudbina grananje

Odluka (decision) ima jedan ulazni tok inekoliko uslovnih izlaznih tokova. Svakom izlaznom toku je pridruen jedan uslov, tj. logiki izraz izmeu ugaonih zagrada. Pri svakom nailasku na odluku mogue je nastaviti samo jednim od izlaznih tokova, pa uslovi treba da budu meusobno iskljuivi. Rezervisana re [else] kao uslov ukazuje na tok kojim treba nastaviti ukoliko su netani svi ostali uslovi odluke.Pripremi narueno [prioritetna narudbina] odluka [else] Obina isporuka Naplati Poalji fakturu

Hitna isporuka

Stapanje (merge) ima vie ulaznih tokova ijedan izlazni. Oznaava kraj uslovnog ponaanja zapoetog odlukom.

stapanje spajanje Zakljui narudbinu zavrni vor

44. Akcije se mogu razloiti u podaktivnosti (subactivities). Dijagram podaktivnosti se moe prikazati primenom simbola rave.Ime aktivnosti Primljena narudbina Isporui narudbinu Obina isporuka [else] Narudbina [prioritetna narudbina] Hitna isporuka izlazni prametar Narudbina Pripremi narueno Poalji fakturu

Isporui narudbinu

Naplati

Pomoni dijagram aktivnosti

rava ukazuje na dijagram podaktivnost i

Zakljui narudbinu

Poziv aktivnosti sa pomonog dijagrama

45.Magacin Korisnika sluba Raunovodstvo

Dijagrami aktivnosti pokazuju ta se deava, ali ne i ko ta radi. Da bi se prikazalo ko izvrava koje akcije, dijagram aktivnosti se deli u particije. Particije (partitions) pokazuju koje akcije izvrava jedna organizaciona celina.

Primljena narudbina

Pripremi narueno

Poalji fakturu

Isporui narudbinu

Naplati

Zakljui narudbinu

Postoje jednodimenzionalna (esto se zove plivaka staza) i dvodimenzionalna podela na particije.

46.Akcije mogu primati i slati signale. Signali omoguavaju interakciju sa spoljnim procesima. Ukoliko aktivnost prima dogaaj iz spoljnog procesa, ona neprekidno oslukuje signale, a na dijagramu je opisano kako aktivnost reaguje nakon prijema signala. Oznake za prijem mogu imati i ulazni tok ime se oznaava da oslukivanje zapoinje tek kada tok aktivira prijem. Aktivnost moe i da poalje poruku, pa da saeka odgovor pre nego to nastavi sa radom. Vremenski signal nastaje zbog protoka vremena.

Primer 1vremenski signal

Primer 2Rezervii mesto Kreni na aerodromprijem signala

Pakuj stvari

Poalji plan

Potvren plan

Potvrdi putovanje Odustani od putovanja

Stie taksiprijem signala slanje signala

ekaj 48 sati

47. Akcije mogu imati parametre, kao to ih imaju metode. Informacije o parametrima se po potrebi mogu prikazivati pomou noica.Transformacija parametara se naznaava u sluaju kada izlazni parametri jedne akcije ne odgovaraju ulaznim parametrima sledee akcije. Izraz za transformaciju ne sme proizvoditi sporedne efekte. To je u stvari upit na izlaznom delu noice, a tip rezultata upita treba da odgovara ulaznoj noici.Primer Otkai pregledPreglednoica za parametar

transformation pregled.obavetenjeOOtkazivanju Poruka Pacijent

transformation pregled.pacijent

Obavesti pacijenta

Izraz za transformaciju

48. U situaciji kada nakon neke akcije treba vie puta izvriti drugu akciju, koristi se oblast primene koja predstavlja deo dijagrama aktivnosti u kome se akcije izvravaju po jednom za svaki element kolekcije. Na sledeu akciju se prelazi nakon kompletiranja izlazne kolekcije. Brojevi elemenata u ulaznoj i izlaznoj kolekciji ne moraju biti isti (ako se oblast primene ponaa kao filtar). Dva naina obrade elemenata ulazne kolekcijeParalelna obrada (oznaava se rezervisnom reju concurrent), kada se elementi obrauju istovremeno. Iterativna obrada, kada se elementi moraju obraivati jedan za drugim.Primerrezervisana re concurrent oblast primene

lista tema

Napii tekst

Pregledaj tekst

Objavi bilten

noica u obliku liste

49. Projektni uzorak, obrazac ili ablon predstavlja zabeleeno iroko primenjivano iskustvo u projektovanju vezano za neki opti problem. Uzorak opisuje problem koji se esto ponavlja, daje sutinu njegovog reenja i to na takav nain da se to reenje moe primenjivati u mnogim posebnim kontekstima u kojima se dati problem pojavljuje. Osnovni elementi projektnog uzorka su: naziv uzorka postavka problema opis reenja diskusija konsekvenci 50. Klasifikacija uzoraka doprinosi boljem i brem snalaenju prilikom traenja odgovarajueg uzorka, a istovremeno i usmerava napore ka otkrivanju novih uzoraka. Za klasifikaciju uzoraka koriste se dva kriterijuma: kriterijum namene, koji razvrstava uzorke u zavisnosti od toga ime se bave kreiranjem objekata (creational patterns) strukturom, tj. kompozicijom klasa i objekata (structural patterns) ponaanjem, tj nainom interakcije objekata i klasa (behavioral patterns) kriterijum domena, koji razvrstava uzorke zavisno od toga da li se primarno primenjuju na klase ili objekte

klasni uzorci koji se fokusiraju na relacije izmeu klasa i podklasa (class patterns) objektni uzorci koji se fokusiraju na relacije izmeu objekata (object patterns) 51. Za svaki uzorak, katalog sadri sledee stavke: Ime uzorka i klasifikacija Namena odgovori na pitanja "ta radi?, emu slui? i koji problem reava? Drugi nazivi isti uzorak moe imati vie naziva Motivacija scenario koji ilustruje projektni problem Primenljivost situacije u kojima se uzorak moe primeniti Struktura grafika reprezentacija klasnih i objektnih dijagrama koji opisuju uzorak Uesnici klase i objekti koji uestvuju u uzorku i njihove odgovornosti Kolaboracije kako uesnici sarauju da bi ispunili svoje odgovornosti Konsekvence diskusija dobrih i loih strana primene uzorka Implementacija preporuke i tehnike kojih treba biti svestan pri implementaciji Primer koda deo koda koji pokazuje kako se uzorak moe implementirati Poznate primene primeri primene uzorka u realnim sistemima Korelisani uzorci uzorci bliski sa datim, razlike meu njima UML notacija grafiki simbol za saradnju koja realizuje uzorak 52.

SingletonSingleton -jedinstvenaInstanca: Singleton -podaci +instanca(): Singleton +dohvatiPodatke() +nekaOperacija() instanca():Singleton{ if (jedinstvenaInstanca==null) jedinstvenaInstanca=new Singleton; return jedinstvenaInstanca; }

Uesnici Singleton klasa

Definie operaciju instanca()kao operaciju klase koja daje klijentima pristup do jedinstvene instance Moe biti odgovorna za kreiranje vlastite instance Kolaboracije Klijenti pristupaju objektu Singleton klase iskljuivo kroz njenu operaciju instanca() Konsekvence dobre strane Kontrolisani pristup do jedine instance poto klasa kapsulira jedinu instancu, ona moe imati striktnu kontrolu nad tim kako i kada klijenti pristupaju instanci Redukovan prostor imena Singleton uzorak je bolji koncept od globalne promenljive; on izbegava optereivanje prostora imena globalnom promenljivom koja uva jedinu instancu Dozvoljeno doterivanje operacija i reprezentacije iz Singleton klase se moe izvoditi aplikaciju je lako konfigurisati instancom izvedene klase, ak i u vreme izvrenja Dozvoljava kontrolisano poveanje broja instanci uzorak omoguava projektantu da se po maloj ceni predomisli i povea broj dozvoljenih instanci Fleksibinost u odnosu na operacije klase drugi nain za realizaciju funkcionalnosti Singleton-a je usluna (utility) klasa sa uslunom klasom je komplikovano promeniti broj instanci