Modeliranje - Osnove UML-a PODSETNIK!

‡ ‡ ‡ Softversko in enjerstvo se bavi modelima, metodama i alatima koji su nam potrebni da bi na to jeftiniji na in mogli proizvoditi to kvalitetniji softver. Softverski proces je skup aktivnosti i pripadaju ih rezultata iji je cilj razvoj ili evolucija softvera. Model je prikaz softverskog procesa, kojim se odre uje po eljni na in odvijanja i me usobnog povezivanja aktivnosti.

Metode razvoja softvera ‡ ‡ ‡ Metoda razvoja softvera je profinjenje i konkretizacija odabranog modela za softverski proces. Metoda uvodi specifi nu terminologiju i deli osnovne aktivnosti u pod-aktivnosti. Starije funkcionalno-orijentisane metode programskih jezika (Cobol, C, Fortran). Novije objektno-orijentisane programskih jezika (Java, C++) metode slede logiku starijih funkcionalno-orijentisanih objektno-orijentisanih

predstavljaju

nadgradnju

Modeliranje ‡ ‡ ‡ Alati ‡ CASE alati (Computer Aided Software Engineering) su softverski paketi koji daju automatizovanu podr ku za pojedine aktivnosti unutar softverskog procesa. Obi no su napravljeni u skladu s odredenom metodom razvoja softvera. Alati koji daju podr ku za po etne aktivnosti unutar softverskog procesa, kao to su specifikacija i oblikovanje, ali i za dokumentovanje sistema predstavljaju ALATE ZA MODELIRANJE predstavljanje ili pojednostavljenje stvarnosti omogu ava pravljenje nacrta sistema uklju uje elemente sa irokim efektima i izostavlja bezna ajne na datom nivou apstrakcije

‡

UML Unified Modeling Language ‡ ‡ ‡ ‡ ‡ Grafi ki jezik za vizualizovanje, specifikovanje, konstruisanje i dokumentovanje namenjen ematskom prikazu sistema sa razli itih aspekata Pru a standardizovan na in za prikaz poslovnih procesa i sistemskih funkcija, ali i iskaza programskih jezika, ema baza podataka, doftverskih komponenti,... Objektno orijentisan (OO) jezik modeliranja Jezik za specificiranje, a ne metoda ili procedura - standardizovani jezik za izradu nacrta programa Kompatibilian sa najva nijim objektno-orijentisanim metodama razvoja softvera a doveo je i do pojave novih metoda razvoja softvera.

Kratka istorija UML-a ‡ 1996.godine je Jacobson ujedinio metod Booch-a i Rumbaugh-a da bi dobio UML 0.9

1

‡ ‡ ‡

UML Partneri radili su sa Amigos-om da bi OMG-u predlo ili UML kao standardni jezik za modelovanje 1996. U 1997, UML partneri ponudili su svoj inicijalni predlog (UML 1.0) OMG-u i 9 meseci kasnije podneli su finalni predlog (UML 1.1). Od novembra 1997. odr avanje UML-a preuzima OMG-ova grupa za reviziju RTF (Revision Task Force) i u junu 1998. objavljuje verziju UML 1.2, a iste godine u jesen 1998. RTF objavljuje verziju UML 1.3. Prve zna ajnije razlike pojavljuju se u verziji UML 1.4. iz 2001. koja je kasnije poslu ila kaoosnova za UML 2.0 koji je kona no oformljen 2003.

Modeliranje pomo u UML-a ‡ UML je nezavisan od metodologije koja se koristi za skupljanje i analizu aplikacionih zahteva, tako e je nezavisan od platforme za koju se vr i modeliranje iako se mo e povezati sa konkretnim platformama. Sistem je predmet koji se modeluje. Podsistem je deo sistema koji se sastoji od povezanih elemenata. Model je apstrakcija sistema ili podsistema sa odre enog gledi ta Dijagram je grafi ka predstava skupa elemenata u modelu sistema. Model se sastoji od objekata koji alju poruke Objekti imaju atribute i pona anja (metode). Vrednosti atributa objekata su stanja. Klasa je ³nacrt´ (blueprint) objekata. Objekti su instance klase. Model sistema se predstavlja grafi ki pomo u vi e dijagrama i model sadr i i dokumentaciju ± korisni ke funkcije (slu ajeve kori enja)

‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡

UML jezik ‡ Sa injen je od integrisanog skupa dijagrama i razvijen je da bi pomogao u razvijanju sistema i softvera. Primena UML-a poma e u ostvarivanju slede ih zadataka: ± ± ± ± ± ± specifikaciji vizualizaciji projektovanju arhitekture razvoju simulaciji i testiranju izradi dokumentacije

UML se sastoji od: ‡ ‡ ‡ Elementi ± predstavljaju standardne objektno orijentisane koncepte (klase, objekti, poruke). Relacija ± semanti ka veza me u elementima. Dijagram ± grafi ka predstava skupa elemenata naj e e iskazan kao graf relacije i elemenata.

2

Elementi (koncepti) u UML-u ± ± ± ± ± ± ± ± ± ± ± ± ± Relacije (veze) ± ± ± Dijagrami  Dijagrami strukture y y y y Dijagram klasa (Class diagram) Dijagram objekata (Object diagram) Dijagram komponenti (Component diagram) Dijagram postavljanja (Deployment diagram) Zavisnost (Depends) Generalizacija ili nasle ivanje (Generalization ili Inheritance). Asocijacija (Association) U esnik (Actor) Klasa (Class) Atribut (Attribute) Komponenta (Component) Interfejs (Interface) Objekat (Object) Paket (Package). Use case (Use Case). Doga aj (Event) Poruka (Message) Metod (Method) Operacija (Operation) Stanje (State) 

Dijagrami ponasanja      Dijagram slu ajeva kori tenja (Use Case diagram) Dijagram redosleda (Sequence diagram) Dijagram saradnje (Collaboration diagram) Dijagram stanja (Statechart diagram) Dijagram aktivnosti (Activity diagram)

3

[kompletan kod je zavr en] 2/3 gre aka u softverskim sistemima nastaje u toku faze n injerstav zahteva. Vrste zahteva:     korisni ki sistemski funkcionalni nefunkcionalni Slede i korak u procesu razvoja softvera    In injerstvo zahteva (requirement engineering ± RE) RE je proces koji se sastoji od izdvajanja (otkrivanja). Svaki proces razvoja softvera mora obuhvatiti in injerstvo zahteva. Pa iljivo definisanje zahteva ne zna i da ne e biti kasnijih izmjena U prosjeku 25% izmjena u razoju softvera odnosi se na izmjenu zahteva. analize. dokumentovanja i validacije prikupljenih zahteva. In injerstvo zahteva (RE) 4 . uop ten) ili kao detaljni funkcionalni zahtev.In enjerstvo zahteva (Requirements engineering) Specifikacija zahteva     Specifikacija je proces evidentiranja zahteva zahtev defini e TA sistem treba da radi a ne KAKO zahtev mo e biti opisan na visokom nivou apstrakcije (bez detalja. Za to in injerstvo zahteva?  Prednosti dokumentovanja zahteva    Opisuju se funkcionalnosti sistema za korisnike ( ne za programere) Smanjuje se mogu nost gre aka u razvoju Izjene zahteva su vrlo skupe i ko taju:         3 x vi e u toku faze dizajna 5-10 x vi e u fazi implementacije 10-100 x vi e kada je sistem implementiran. Va no je planirati tako da se uzimaju u obzir mogu e izmjene zahteva. U slu aju da je projekat zavr en ovo bi zna ilo 70-80% izmjena u svim ostalim fazama razvoja.

potrebnu opremu ii. Studija izvodljivosti (Feasibility study) 2. De ini e: i. uklapanje u organizaciju sistema ii. Specifikacija zahteva 4. Radi se timski (obi no traje 2-3 nedelje) c. identifikacija najpovoljnijeg re enja iv. Prvi poku aj da se zahtevi opi u ii. utvr ivanje projektnih zahteva 1. tehni ka izvodljivost iii. Analizira: i. Klasifikacija i organizacija zahteva ‡ Grupi u srodne zahteve i organizuju ih u koherentne grupe. Studija izvodljivosti (2) a. Predstavlaju se dijagramima i/ili tekstom iv. operativna izvodljivost ii. ekonomska izvodljivost (opravdanost) Koraci spiralnog procesa ‡ Otkrivanje (prepoznavanje) zahteva ‡ ‡ Interakcija sa nosiocima projekta u pronala enju njihovih zahteva. Validacija zahteva 5. potrebne ulaze iii. ‡ Prioritetnost i pregovori ‡ Prioritetnost zahteva re ava konflikte izme u zahteva ‡ Dokumentacija zahteva ‡ zahtevi su dokumentovani i uba eni u slede i krug spirale. Izdvajanje (otkrivanje) prikupljenih zahteva (1) a. Predla e na in re avanja problema u okviru datih ograni enja b. 2. analiza mogu ih rje enja iii. utvr ivanje ta nih potreba korisnika ii. Obra uje komercijalnu stranu. Izdvajanje (otkrivanje) zahteva i analiza 3. Defini u funkcije i ograni enja sistema iii. Obuhva ena podru ja: i. o ekivane izlaze b. Korisni ki zahtevi i. RE obuhvata pet aktivnosti: 1. Razumljivi su svima 5 . o ekivanu dobit (cost-benefit) c. a ne tehni ku d. Dokumentovanje zahteva 1. Studija izvodljivosti (1) a. Ciljevi: i.

3. bibliotekarstvo. Da li su uklju ene sve funkcije koje su potebne korisniku? Realnost. Predstavlaju se tekstualno. development method«). lako a kori enja  Organizacioni zahtevi o Primjer: zahtevi za implementaciju. pouzdanost. Primjer ograni enja: Vremensko ogrni enje. Defini u funkcije sistema (funkcionalnost za korisnike) ii. Funkcionalni zahtevi i. grafi ki ili pomo u neke formalne specifikacije (razumiljivo malom broju stru njaka). ta bi sistem trebao da radi a ta ne u odre enim siituacijama. Mogu biti kategorisani kao:  zahtevi vezani za ³pona anje´ sistema o Primjer: brzina rada. language. implementacija u odre enom programskom jeziku (CASE. Ograni enja funkcija sitema ii. hemija itd. b. Da li zahtevi mogu biti implementirani usled zbog dostupnog bud eta i tehnologije? Proverenost. standardi i sl. Precizno opisuju sve slu ajeve pona anja iv. zakonski propisi. tabelarno. c. Detaljno defini u f-je i ograni enja sistema ii. Tehnike validacije zahteva o Provjera zahteva  Sistematsko ru no analiziranje zahteva 6 . Napomena: Mogu postojati korisni ki i sistemski funkcionalni i ne-funkcionalni zahtevi. Da li zahtevi mogu biti provjereni? Primjer: Interoperabilnost. primjena specifi nih standarda i sl. Ne-funkcionalni zahtevi i. Sistemski zahtievi i. Ne funkcionalni zahtevi   Ne funkcionalni zahtevi mogu biti va niji za procjenu uspjeha u razvoju softverskog sistema. Domenski zahtevi i. Poti u od ograni enja domena za koji se aplikacija razvija ii. Koriste ih dizajneri i programeri iii. Mogu biti funkcionalni i ne-funkcionalni iii.  Spolja nji zahtevi o Validacija zahteva ‡ ‡ ‡ ‡ ‡ Valjanost.b. Izdvajanje (otkrivanje) prikupljenih zahteva (1) a. isporuku i sl. Da li postoje bilo kakvi koflikti me u zahtevima? Kompletnost. Primjeri: Mediciina. Da li sistem obavlja funkcije sa najboljom podr kom koja je korisnicima potrebna? Konzistencija.

Prirodni jezik nije pogodan za predstavljanje zahteva. o Generisanje test-slu aja  Razvijanje testova za zahteve. ta se provjerava? y y y Da li se zahtevi zaista mogu testirati? Da li su zahtevi pravilno shva eni? Mogu li se zahtevi promijeniti bez velikih uticaja na druge zahteve? Menad ment zahtevima U gotovo svim sistemima. modifikacije se de avaju na hardveru. Zahtevi i dizajn sistema   zahtevi opisuju ta sistem treba da radi a ne kako. U praksi zahtevi defini u dizajn sistema. Kako se zahtevi predstavljaju    zahtevi se sakupljaju i zapisuju u prirodnom jeziku.  Dizajn sistema zavisi od domena u kojem se sistem razvija. Pregledi mogu biti formalni (sa kompletnom dokmentacijom ili informativno) Dobra komunikacija izmedju kreatora.  Arhitektura sistema mora biti dizajnirana u skladu sa zahtevima. kupaca i korisnika mo e rije iti probleme u ranoj fazi. softveru i okru enju.  Sistem mo e biti povezan sa drugim sistemom koji generi e zahteve. zahtevi se menjaju. Razlozi za to su: y y y ljudi vremenom bolje razumiju ta zapravo ele da im softver radi. y y  Oba klijenta i ugovara i bi trebali da budu uklju eni u pregled. Pregled i provjera zahteva  Redovni pregled zahteva se odvija u toku formulisanja definicija zahteva. Problemi sa prirodnim jezikom  esto zahtevi ne mogu biti dovoljno jasno opisani (dvosmislenost) 7 . organizacija koja kupuje sistem se neprestano mijenja. Proces upravljanja promjenama u zahtevima se naziva upravljanje ili menad ment zahtevima.o Prototipovi  Koriste se izvr ni modeli sistema da se provjere zahtevi.

  mogu e je istu stvar opisati (i protuma iti) na razli ite na ine nije pogodan za opis sistemskih zahteva Alternative prirodnom jeziku     Struktuirani prirodni jezik Jezici za opis dizajna sistema (design description language) Grafi ka notacija Matemati ka specifikacija Struktuirani prirodni jezik  Svi zahtevi pi u se na standardan na in.2-1988 IEEE Guide for The Use of IEEE Standard Dictionary of Measures to Produce Relible Softvare 8 . X/Open i OSF standardi za grafiku ISO.  U SI postoje me unarodni standardi za  pisanje dokumentacije  vrednovanje softvera (provjera kvaliteta)  testiranje i sl. ANSI i IEEE komunikacioni standardi IEEE standardi softverskog in enjerstva      IEEE 1012-1986 Software Verification & Validiation Plans IEEE 828-1990 Softvare Configuration Management Plan IEEE 1058.  Koriste se predefinisani templejti  Terminologija je uglavnom limitirana standardima.1-1987 Software Project Management Plan IEEE 830-1993 Software Requirements Specification IEEE 982. Me unarodni standardi y y y y y y y ISO/IEC 14102 Software Engineering ISO standardi programskih jezika ISO/IEC standardi baza podataka IEEE standardi otvorenih sistema ISO i DoD standardi za tite ISO.

Opisuje tok doga aja o o o These show the sequence of events that take place during some user interaction with a system.1-1993 Software Design Document IEEE 1044. U okviru specifikacije zahteva koriste se: o o Use case dijagrami ili Dijagrami aktivnosti Napomena: Nije potrebno koristiti oba UML dijagrama .1 Severity Clasification IEEE 1008-1987 Road Map for Unit Testing ANSI/IEEE 829-1991 Software Test Documentation IEEE 1219-1992 Software Maintanance Specifikacija pomo u formi      Definicija funkcije ili entiteta. Dijagrami sekvenci (engl. You read them from top to bottom to see the order of the actions that take place. Navo enje ostalih entiteta (ukoliko su potrebni). Tabelarna specifikacija   Koristi se kao dodatak prirodnom jeziku.       IEEE 730-1989 Software Quality Assurance Plans IEEE P1233 Guide to Developing System Requirements Specifications IEEE 1016. Sequence diagrams) . Pred i post uslovi (ukoliko postoje). Grafi ki modeli ± UML dijagrami    UML dijagrami su iroko prihva en na in za predstavljanje specifikacija sistema Postoji veliki broj razli itih UML modela kojima je mogu e opisati sistem sa razli itih aspekata. Opis ulaznih parametara i odakle poti u. Cash withdrawal from an ATM y Validate card.u zavisnosti od prirode sistema treba izabrati dijagram. Posebno korisno kada treba definisati vi e mogu ih tokova (akcija sistema) u zavisnosti od ulaznih parametara. 9 . Opis izlaznih parametara i emu su namijenjeni. Pojedini slu ajevi kori enja mogu se detaljnije opisati pomo u dijagrama aktivnosti.

zahtevi mogu da sadr e specifikaciju interfejsa . Complete transaction.SRS)  Sastoji se iz:  Specifikacije korisni kih zahteva  Specifikacije sistemskih zahteva  Specifikacije modela sistema  SRS defini e TA sistem treba da radi a ne KAKO Kome je namijenjena specifikacija zahteva sistema (SRS)? 10 . Specifikacija interfejsa    Sistemi su u interakciji sa drugim sistemima putem interfejsa. Koriste se jezici za opis dizajna sistema. Krajnji rezultat in injerstva zahteva  Krajnji rezultat RE je specifikacija sistema (software requirement document .y y Handle request.

koji je stvoren zato da bi se prodao. Menjanje u skladu s promenjenim potrebama korisnika. Treba da ima slede e atribute kvaliteta:     Mogu nost odr avanja. Softver mora imati zadovoljavaju e performanse i koristiti hardverske resurse na tedljiv na in. i za njega mora postojati dokumentacija. koje bi bile u stanju da kontroli u kompleksnost velikog softverskog projekta.  Zaklju ak  tehnike individualnog programiranja se ne mogu uspe no ³preslikati´ na velike programe gde u estvuje veliki broj programera  Re enje  potreba za slo enijim metodama razvoja softvera. 11 .Software engineering Po etci   1968. Efikasnost. Upotrebljivost. FAQs about software engineering   ta je softver ili softverski proizvod? ta je softversko in enjerstvo?  Kakva je razlika izme u softverskog in enjerstva i ra unarskih nauka?  Kakva je razlika izme u softverskog in enjerstva i sistemskog in enjerstva?    ta je softverski proces? ta je model softverskog procesa? ta je metoda razvoja softvera?  Koliki su tro kovi softverskog proizvoda?   ta su CASE alati? ta su atributi dobrog softvera? Softverski proizvod ili softver   Softverski proizvod je skup ra unarskih programa i pripadaju e dokumentacije. je pojam prvi put upotrebljen na NATO konferenciji Razlog?  projekti koji su vi estruko prema ili planirane tro kove i rokove.Uvod u dizajn aplikativnog softvera . Softver treba da radi ono ta korisnici od njega o ekuju. Pouzdanost i sigurnost. a korisni ki interfejs treba da bude zadovoljavaju i. Softver se mora pona ati na predvidiv na in.

to predstavlja primenu in enjerstva na softver. implementacija. Softverski proces   Softverski proces je skup aktivnosti i pripadaju ih rezultata iji je cilj razvoj ili evolucija softvera. Osnovne aktivnosti softverskog procesa su: y  specifikacija. Software engineering ± IEEE Definition  Primena sistemati nog i ogranizovanog pristupa razvoju. validacija i odr avanje.  Razlika izme u softverskog in enjerstva i sistemskog in enjerstva?    Sistemsko in enjerstvo (system engineering) je orijentisano na sve aspekte razvoja slo enih sistema u kojima programska podr ka igra glavnu ulogu. Generi ke aktivnosti u svim softverskim procesima su: 12 . systems written to support a particular business process air traffic control systems.. custom) ± razvijen za odre enog klijenta prema zahtevanoj specifikaciji. npr. Softversko in enjerstvo . metodama i alatima koji su nam potrebni da bi na to jeftiniji na in mogli proizvoditi to kvalitetniji softver. Naru eni (bespoke. Neka znanja iz domena ra unarskih nauka su zna ajna za programske in enjere na isti na in to su neka znanja iz domena fizike zna ajna za in enjere elektrotehnike. Excel. Sistemsko in enjerstvo je starija disciplina od softverskog in enjerstva. Word. politike razvoja i procesa projektovanja kao i postavljanja sistema.Nau na disciplina koja se bavi svim aspektima proizvodnje softvera.  Softverski proizvod mo e biti razvijen za odre enog klijenta ili za tr i te generalno. dizajniranje. verifikacija. npr. Softverski proizvod mo e biti:   Generi ki ± razvijen sa namerom da se proda velikom broju razli itih klijenata. Razlika izme u softverskog in enjerstva i ra unarskih nauka?  BITNO: ra unarske nauke (computer science) su orijentisane na teorije i metode u vezi s ra unarom neposredno dok je softversko in enjerstvo orijentisano na prakti ne probleme koji se javljaju pri proizvodnji programske podr ke ± software-a.    control systems for electronic devices.. Sistemsko in enjerstvo je orijentisano i na razvoj tehni ke podr ke.)   Input: opis problema od strane klijenta Output: softverski sistem kao dugoro no re enje klijentovog zahteva. funkcionisanju i odr avanju softvera. softversko in enjerstvo se bavi modelima.  Dakle. (IEEE Std 610-1990.

posmatran iz odre ene perspective ili Model je prikaz softverskog procesa. Alati su napravljeni u skladu sa odre enom metodom razvoja softvera.y specifikacija softvera ± ta bi sistem trebao da radi (funkcionalnosti softvera) i koja ograni enja moraju biti ispo tovana. Metoda uvodi specifi nu terminologiju. CASE alati (Computer Aided Software Engineering)   CASE alati su softverski paketi koji daju automatizovanu podr ku za pojedine aktivnosti unutar softverskog procesa. implementiraju pravila iz te metode. 13 .  an interactive game must be responsive. CASE alati namenjeni za podr ku analize i razvoja se nazivaju . razvoj softvera ± produkcija softvera prema zadatoj specifikaciji validacija softvera ± provera valjanosti (da li je to ono to je naru ilac posla tra io) odr avanje softvera ± dorada programa prema izmenama u zahtevima naru ioca.  a telephone switching system must be reliable.   Atributi dobrog softvera  Primeri:  a banking system must be secure. Softver bi trebao da pru i zahtevanu funkcionalnost i performanse korisniku u zavisnosti od zna aja okru enju. y y y Model softverskog procesa    Pojednostavljen prikaz softverskog procesa. deli osnovne aktivnosti u pod-aktivnosti itd. program editors se nazivaju lower-CASE alati. kojim se odre uje po eljni na in odvijanja i medusobnog povezivanja aktivnosti. CASE alati koji podr avaju implementaciju i testiranje kao to su debuggers. model mo e zahtevati sekvencijalno ili simultano odvijanje aktivnosti. test case generators. etc. Primeri perspektiva:  tok procesa (workflow) prikazuje redosled aktivnosti  Na primer.   tok podataka (Data-flow) prikazuje tok informacija uloge/akcije (Role/action) prikazuje ta ko radi Metoda razvoja softvera   Metoda razvoja softvera je konkretizacija odabranog modela za softverski proces. program analysis systems.upper-CASE alati jer podr avaju rane faze. sadr e editore za odgovaraju e dijagrame i slu e za izradu odgovaraju e dokumentacije.

naru ioca ± sastoji se od softverskih in enjera. ali . U esnici u razvoju softverskog procesa  ULOGE:    Kupac ± kompanija koja pla a za softverski sistem koji se razvija Korisnik ± stvarno radi na sistemu Razvojni tim ± pravi softverski sistem za kupca tj.. 60% ± 70% svih gre aka otkrivenih u velikim projektima su nastale u fazi definisanja zahteva ili u fazi projektovanja. i naziva se Svaka faza ivotnog ciklusa ima sopstvene aktivnosti i resurse.prakti ni opis ± ivotnom ciklusu. ivotni ciklus softvera . Generalno atributi dobrog software-a su     mogu nost odr avanja pouzdanost upotrebljivost efikasnost Modeli za softverski proces U esnici u razvoju softverskog procesa  Broj osoba koje rade na razvoju sotfvera zavisi od veli ine i slo enosti projekta. ve i 14 . ali svaki od njih mo e da se specijalizuje za poseban aspekt razvojnog procesa. ivotni ciklus softvera(Software lifecycle)    ivotni ciklus softvera        Analiza zahteva i specifikacija Projektovanje Implementacija Testiranje Integracija Isporuka Odr avanje Proces razvoja softvera se mo e predstaviti nizom koraka po ev od formulisanja osnovnih koncepata. Zadatak softverskog in enjerstva je ne samo da se rano otkriju gre ke u prevencija da ne dodje do gre aka.. preko implementacije do isporuke i odr avanja.

To je lista zahteva koju sistem mora zadovoljavati. kada klijent prihvati Funkcionalnu specifikaciju. softver se isporu uje i instalira. da bi se ono to kupac ho e razlo ilo na pojedina ne zahteve. Beta testiranje (ili debugging). 15 . Testni in enjeri rade na otkrivanju gre aka koje previde programeri. Softver se razvija prema Specifikaciji dizajna. ivotni ciklus softvera uklju uje slede e procedure:  Definisanje ciljeva ± Odre ivanje glavnih ishoda tj. Prikupljanje. Ovim se navodi ta sistem treba da radi.  Integracija. programeri pi u kod koji implementira ono to je formulisano u zahtevima.  Analiza zahteva i specifikacija. osigurava da se razli iti moduli integri u u jednu aplikaciju. Ovim se defini e kako e sistem biti razvijen. pregled i formulisanje klijentskih zahteva i procena mogu ih ograni enja. proverava da li softver odgovara na po etne zahteve. ali ne i kako e to raditi. tim za testiranje i kupac zajedno rade na verifikovanju celokupnog sistema u odnosu na postavljene zahteve. individualno testiranje svakog modula aplikacije da se osigura da su kreirani prema po etnoj specifikaciji. analiti ar radi sa projektantima na generisanju opisa funkcija sistema. Jednom. Softver se testira da se proveri da li odgovara Specifikaciji dizajna.  Detaljni dizajn. Dalje.  Documentacija dokumentuje neophodne informacije za korisnike softvera i budu i razvoj. Kada razvojni tim bude zadovoljan sa kvalitetom sistema.  Implementacija  Odr avanje. Softver se testira prema Funkcionalnoj specifikaciji. Sofver se zatim odr ava prema povremenim zahtevima klijenata. Da li zadovoljava sve zahteve? Jedanput kada se testiranje uspe no zavr i.  Testiranje modula aplikacije. tj. precizira definiciju svake komponente aplikacije. rezultata projekta. koje su definisane tokom faze dizajna.  Programiranje je implementacija pomo u nekog programskog jezika u cilju kreiranja funkcija budu eg sistema. sve korekcije (korektivno odr avanje) i manji softverski update (teku e odr avanje) lanovi razvojnog tima ‡ ‡ ‡ ‡ ‡ Analiti ar zahteva komunicira sa kupcem. Kreira se Funkcionalna specifikacija za klijenta. kreira se Specifikacija dizajna.  Generalni dizajn Generalni zahtevi u pogledu arhitekture aplikacije.‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ Projekat zapo inje klijentovim zahtevima za novi sistem. Kada zahtevi postanu dokumentovani.

Model je dobro prihva en od rukovodstva. mo e se desiti da je sistem u trenutku pu tanja u rad ve nea uran i zastareo. ta polazna verzija se pobolj ava. Primeri modela: Model vodopada (engl. Unutar svake iteracije. Nakon dovoljnog broja iteracija dobija se kona na verzija sistema. itd. Na primer. Model treba koristiti za velike sisteme gde postoje jasni zahtevi. Zbog tendencije da se zbog po tovanja rokova u odredenom trenutku ³zamrzne´ pojedina faza.‡ Instruktori obu avaju korisnike za operativno kori enje sistema. Razli iti pristupi u ivotnom ciklusu softvera su potrebni i svaki pristup je pogodan za odre enu primenu. Model evolucijskog razvoja ili Prototipski model 16 . Waterfall Model )   Softverski proces je gradjen kao niz vremenski odvojenih aktivnosti. Na osnovu korisnikovih primedbi. opet pokazuje. o o Model evolucijskog razvoja ili Prototipski model    Na osnovu pribli nog opisa problema razvija se polazna verzija sistema koja se pokazuje korisniku. Mane modela vodopada su slede e Faze je u praksi te ko razdvojiti. model mo e zahtevati sekvencijalno odnosno simultano odvijanje aktivnosti. osnovne aktivnosti se obavljaju simultano i ne razdvajaju se. Prednosti modela vodopada: o o o o Model omogu uje lako pra enje stanja u kome se softverski proces nalazi. Modeli softverskog procesa    Model za softverski proces je idealizovani prikaz softverskog procesa. kojim se odreduje po eljni na in odvijanja i medusobnog povezivanja osnovnih aktivnosti. pa dolazi do naknadnog otkrivanja gre aka i vra anja u prethodne faze.

ivotnim vekom. Analiza raspolo ivih delova Modifikacija zahteva Projektovanje sistema uz vi estruku upotrebu delova Specifikacija zahteva Implementacija i integracija Verifikacija i validacija sistema  Prednosti modela 17 . tj.  Mane modela evolucijskog razvoja  Proces nije transparentan za rukovodstvo. oni ne mogu oceniti koji deo posla je obavljen i kada e sistem biti zavr en.  Zahtevaju se posebni alati i natprose ni softverski in enjeri. pogotovo za Model orijentisan ka ponovnoj upotrebi (reuse-oriented development)   Model polazi od pretpostavke da ve postoje gotove i upotrebljive softverske celine ili delovi ranije razvijenih sistema. Prednosti modela evolucijskog razvoja  Model proizvodi brz odgovor na zahteve korisnika.  Kona ni sistem je obi no je lo e strukturiran zbog stalnih promena.  Postoji mogu nost da se specifikacija postepeno razvija u skladu sa sve boljim korisnikovim razumevanjem problema.  Model se uspe no koristi za razvoj malih sistema sa kratkim sisteme sa nejasnim zahtevima. i nepogodan za odr avanje. Novi sistem treba u to ve oj meri realizovati spajanjem postoje ih delova.

Stavlja se oslonac na proverene i dobro testirane delove softvera. na primer u varijanti ³extreme programming´. veku. Delimi no je izgubljena kontrola nad evolucijom sistema. ali pojedina iteracija ne dora uje ve realizovani deo sistema. Model inkrementalnog razvoja    Hibrid modela vodopada i modela evolucijskog razvoja. a korisnici imaju sve manje vremena za ekanje re enja.inkrement. Defini i okvirne zahteve Rasporedi zahteve na inkremente Projektuj arhitekturu sistema Specificiraj. razvija. testira itd. Razvoj jednog inkrementa u okviru jedne iteracije odvija se po bilo kom modelu . Sistem se opet razvija u nizu iteracija. tro ak i rizik. Ovo je vrlo upotrebljiv model koji se intenzivno koristi u praksi. Mane modela    Zbog kompromisa u specifikaciji mogu e je da sistem ne e u potpunosti odgovoriti stvarnim potrebama korisnika. budu i da ne upravljamo razvojem novih verzija kori enih delova. 18 . projektuj i implementiraj novi inkrement Verifikuj i validiraj novi inkrement Sistem je nedovr en Integri i novi inkrement Krajnji sistem       Prednosti modela Proces je prili no transparentan za rukovodstvo. ve mu dodaje sasvim novi deo .  Agilne metode (Agile methods)  Disciplina za na in kako se sofver dokumentuje. Mane modela Ponekad je te ko podeliti korisni ke zahteve u smislene inkremente. ime se smanjuje vreme.   Smanjuje se koli ina softvera koga stvarno treba razviti. Korisnici ne moraju dugo ekati da bi dobili prvi inkrement koji zadovoljava njihove potrebe. jer je broj gotovih re enja sve ve i. O ekuje se da e ovaj model postati prevladavaju i u 21. jer je vidljivo do kog smo inkrementa do li. te ko je odrediti zajedni ke module koji su potrebni raznim inkrementima i koji bi morali biti implementirani u prvom inkrementu. Budu i da celokupni zahtevi nisu dovoljno razradjeni na po etku. Razvoj sledi prioritete.na primer vodopad.

Postoje razne metode i alati. o o o Ekstremno programiranje . Zajedni ki rad sa naru iocem u klju nim aspektima razvojnog procesa. ‡ Agilni manifest: o Pojedinci imaju ve u va nost od procesa i alata. Te ko je videti rezultat i proceniti koliki deo posla je obavljen. Tehnologija se brzo menja. jer je nemogu e da se svi zahtevi predvide na po etku razvojnog procesa. Cilj je odgovoriti na promene.XP (eXtreme Programming)   Skup tehnika za nivelisanje kreativnosti projektnog tima uz minimizaciju prekomernog administriranja. Pojavljuju se nepredvidjeni problemi. Ulo iti vreme u izradu softvera. 19 . a ne na planiranje i pra enje plana. ta je y Projekt je obi no ³neponovljiv´. Stara iskustva obi no nisu primenjiva. ali se ne zna najpogodnije u datim okolnostima. Posao upravljanja softverskim projektom obavlja softverski manad er.    Karakteristika: fleksibilnost Treba brzo odgovoriti zahtevima tr i ta Mogu nost dodavanja i menjanja zahteva u kasnim fazama ivotnog ciklusa Agilne metode su najpogodnije za male/srednje poslovne sisteme  "Agilne metode" razvoja softvera skra uju vreme ivotnog ciklusa softvera ( ime se ubrzava razvoj softvera). Nema standardnog procesa. Na ovaj na in se brzo odgovara na zahteve naru ioca posla. a ne preko dokumentacije. Timovi se samoorganizuju i komuniciraju direktno licem u lice. a zatim integri e funkcionalnost. umesto u izradu dokumentacije. Osobine softverskog projekta  razlikuje se od klasi nog tehni kog projekta u slede em: y y Proizvod je ³neopipljiv´. best-known agile method Karakteristike XP    Nove verzije mogu biti napravljene vi e puta dnevno Inkrementi se daju kupcu svakih 15 dana Svi testovi moraju biti uradjeni za svaku verziju i verzija se prihvata samo ako su svi testovi bili uspe ni Upravljanje softverskim projektom (software project management)   potrebno je zato da bi se softver razvio na vreme i u okvirima planiranih tro kova. Primarno merilo uspeha je stepen do koga softver radi ispravno. tako to se prvo razvija prototip.

20 . Podela poslova. Hardverski i softverski zahtevi. Opisivanje mogu ih rizika i strategija smanjenja rizika. Aktivnosti. Planiranje i pra enje projekta        Uvod. ograni enja. zadaci. Definisanje trajanja aktivnosti. Resursi. Analiza rizika. Rasporedjivanje ljudi i drugih resursa na aktivnosti. Analiziraju se zahtevi budu eg sistema. izbor i ocenjivanje saradnika. definiranje ciljeva i ograni enja. Upravljanje rizicima  Rizi ni inioci po Boehmu: o o o o o o o Manjak osoblja Nerealni rokovi i bud eti Razvoj pogre nih softverskih funkcija Razvoj pogre nog korisni kog interfejsa Pozla ivanje (dodavanje vi e nego to je potrebno) Neprekidni niz izmena u zahtevima Nedostatak performansi u realnom vremenu Zahtevi i specifikacije za dizajniranje aplikativnog softvera Zahtevi i specifikacije   po etna faza softverskog procesa. Zbog ovih osobina. Organizacija. procenjivanje tro kova projekta. Pra enje izvr enja aktivnosti. Poslovi softverskog manad era  Izme u ostalog uklju uju slede e:      pisanje predloga projekta. izve taji rukovodstva. upravljanje softverskim projektom je izuzetno te ak mand erski zadatak i zahteva izuzetno dobrog manad era. pisanje izve taja i prezentovanje. alokacija zadataka. njihova medjuzavisnost. Mehanizmi izve tavanja. Raspored rada. planiranje i pra enje projekta.

Problemi u zahtevima    Problemi nastaju kada zahtevi nisu dovoljno dobro opisani. kao i ograni enja koja moraju postojati u sistemu. Sistemski zahtevi (System requirements) o Strukturirani dokument koji daje detaljni opis funkcija sistema. o Ovaj dokument se naziva i funkcionalna specifikacija. Razmotrite termin µappropriate viewers¶ iz 2. a ne na pojedinu funkciju. tako da mo e biti deo ugovora izme u klijenta i izvr ioca. usluga i operativnih ograni enja.  Nefunkcionalni zahtevi  ograni enja funkcionalnosti sistema. Zahtevi mogu imati dvojnu ulogu: 1. Pi e se za klijenta. ta je zahtev   Zahtev mo e biti opisan na visokom nivou apstrakcije (bez detalja. npr. zahteva. Dvosmisleni zahtevi se mogu interperetirati na razli ite na ine od strane korisnika i softverskih in enjera. osnova ugovaranje novog posla (tada moraju biti razumljivi za interpetaciju) 2. Nekada ovi zahtevi opisuju i ta sistem ne bi smeo da radi. y  Korisni ki zahtev o LIBSYS sistem treba da vodi evidenciju o svim zahtevima za dobijanje licence za tampanje ud benika u celoj zemlji. osnova samog ugovora (tada moraju biti detaljno opisani) Vrste zahteva y Korisni ki zahtevi (User requirements) o Iskazi u govornom jeziku plus dijagrami sa uslugama koje sistem treba da pru i. uop ten) ili kao detaljni funkcionalni zahtev. naslovu i dobavlja u. koji opisuje ta sistem treba da radi. Defini e ta treba da se implementira.  Sistemski zahtevi o Svi formulari za zahteve LIBSYS sistemu moraju biti indeksirani po autoru. kako sistem treba da reaguje na odgovaraju e ulaze i kako sistem treba da se pona a u specifi nim situacijama. Zahtevi koji se upu uju LIBSYS sistemu se moraju uvati pet godina od datuma prijema. 21 . Naj e e se odnose na sistem kao celinu. vremenska ograni enja i ograni enja usled standarda. Rezultat je dokument o zahtevima. o Funkcionalni i nefunkcionalni zahtevi  Funkcionalni zahtevi  Opisuju ta sistem treba da obezbedi.

Konzistentnost y Ne sme da postoji kontradiktornost u opisima zahteva.  ZAKLJU AK: Zahtevi ozna avaju kakvo pona anje naru ilac ostvareno. Kompletnost y  Treba da sadr e opise svih zahtevanih specifi nosti. Radnik je osoba koju pla a kompanija) Entitete koji name u ograni enja (npr.y y Korisni ko vi enje ± preglednici za svaki razli iti tip dokumenta. operateri ili korisnici). bez opisa kako e to pona anje biti Klju ne entitete (npr. Kompletnost i konzistentnost zahteva   U principu. Specifikacija: Proces evidentiranja zahteva    U toku ove faze pravi se odluka koje zahteve e softverski sistem da ispuni (nasuprot zahtevima koji realizuju hardverski ure aji. drugi softverski sistemi. Evidentiranje zahteva = razumevanje osnovnih problema i potreba naru ioca Primer sistema: Generisanje platnih listi a  Mogu i zahtevi:  Listi e treba izdavati na 15 dana  Direktna uplata depozita za radnike sa odre enom visinom plate  Pristup sistemu za obra un plate sa vi e razli itih lokacija u okviru kompanije  Obavezan prikaz opisa na ina prora una plate na samom listi u Tra imo zahteve koji identifikuju:    VA NO  Zahtevi ne odre uju na in implementacije sistema. zahtevi treba da zadovolje i kompletnost i konzistentnost.  U praksi je gotovo nemogu e proizvesti kompletan i konzistentan dokument o zahtevima.  To jest. Vi enje in enjera ± obezbediti tekstualni preglednik sa prikazom sadr aja fajlova. Radnik ne mo e biti pla en za vi e od 40 sati nedeljno) Odnose me u entitetima (npr. Radnika X nadgleda radnik Y i svaki radnik ima nekog nadre enog radnika) 22 . a ne re enju ili implementaciji. zahtevi su okrenuti naru iocu i problemu. Izvr ilac: analiti ar sistema eli.

23 . Slu i softverskim in enjerima kao polazi te za dizajniranje.   Korisni ki zahtevi  Softver mora da pru i na ine predstavljanja i pristupa eksternim fajlovima kreiranim drugim alatima. Informacije skupljene analizom pretvaraju se u tekstove koji defini u zahteve. Modeli sistema. tako to se posmatraju postoje i sistemi. Na taj na in stvaraju se modeli sistema. da li bi predlo eni sistem bio isplativ u poslovnom smislu. Dokument o zahtevima. Prikupljaju se zahtevi. Prilagoden je krajnjim korisnicima. analiziraju radni procesi. Re je o detaljnom i preciznom opisu funkcija sistema i ograni enja. Na in odvijanja pod-aktivnosti Vrste dokumenata za opis zahteva Rezultat specifikacije su dokumenti koji opisuju zahteve. To je manje precizan tekst u prirodnom jeziku. Postoje dva nivoa u opisivanju zahteva: ³korisni ki zahtevi´ i ³zahtevi za sistem´. Re je o kona nom rezultatu specifikacije. Nastaju tokom analize zahtjeva kao sredstvo komunikacije izmedu razvija a softvera i budu ih korisnika.  Validacija zahteva. To su dijagrami koji opisuju pona anje sistema na na in koji je precizniji od prirodnog jezika. a ponekad i prototipovi. Procenjuje se da li se uo cene potrebe korisnika mogu zadovoljiti uz pomo dostupnih hardverskih i softverskih tehnologija. sve u cilju boljeg razumevanja sistema kog treba kreirati.Aktivnost specifikacije se mo e podeliti u podaktivnosti:  Studija izvodljivosti.  Utvr ivanje zahteva. i da li sistem mo e biti razvijen s raspolo ivim bud etom. Sistemski zahtevi. konzistentni (nisu u me usobnom konfliktu). Mo e slu iti kao temelj ugovora izmedu kupca i razvija a softvera. i potpuni (uklju ene su sve potrebne funkcije i ograni enja). itd.   Korisni ki zahtevi. intervjui u budu i korisnici i njihovi rukovodioci. Pisan je u donekle strukturiranom prirodnom jeziku.  Prikupljanje i analiza zahteva. dobijenom kao unija svih prethodno opisanih dokumenata. Proverava se da li su zahtevi realni (mogu da se ostvare raspolo ivom tehnologijom i bud etom).

 Svaki tip eksternog fajla mo e imati dodeljen alat kojim se otvara.  Svaki tip eksternog fajla se mo e predstaviti specijalnom ikonom na ekranu. Razlika izmedju definicije i specifikacije zahteva  Definicija zahteva: y y y  namenjena poslovnom auditorijumu (kupci.Sistemski zahtevi  Korisniku treba pru iti mogu nost definisanja tipa eksternih fajlova. koji kupuju softver  Korisnici. korisnici) Osnova ugovora ta treba isporu iti kupcu pi u je naru ilac i analiti ar Specifikacija zahteva: y y Namenjena tehni kom auditorijumu (projektanti) Referencira samo one entitete kojima mo e da se pristupi iz sistema posredstvom interfejsa Pi e je analiti ar y Doprinos procesu evidentiranja zahteva daju slede i subjekti:  Klijenti koji finansiraju razvoj softvera  Kupci. oni koji poznaju postoje i i koji e koristiti budu i sistem  Eksperti iz date oblasti primene  Pravnici i revizori. koji poznaju propise potrebne za dati sistem  Softverski in enjeri Dopunska sredstva:     Raspolo iva dokumentacija Posmatranje postoje eg sistema Intervjuisanje korisnika U enje od korisnika Kako korisnici i projektanti vide jedni druge Vi enje projektanta    Korisnici ne znaju ta ho e Sve ho e odmah Nisu sposobni da objasne ta im treba 24 .

    Nisu radi da prave kompromise Ne ele da preuzmu odgovornost za sistem Ne umeju da dodele prioritete svojim potrebama Ne mogu da prate rokove Vi enje korisnika        Projektanti ne razumeju operativne potrebe Ne mogu jasno da prevedu navedene potrebe u sistem Stavljaju veliki naglasak na tehni ka pitanja Projektanti uvek kasne Uvek prema uju bud et Sve vreme govore ³ne´ Ho e da nam ka u kako da radimo svoj posao Modeliranje sistema 25 .

veza i atributa . Model posmatra sistem iz neke odredjene perspektive. Vodoravna linija ± doga aj ili interakcija me u entitetima Vreme te e odozgo na dole.Sequence diagrams      pokazuje veze izme u klasa koje se uspostavljaju time to objekti jedne klase pokre u operacije druge klase. Modeluju samo funkcionalnost sistema koju mo e da inicira neki od u esnika iz okru enja. veze medu entitetima i atributi Opisuje se i funkcionalnost veza (1:1.kontekst Model entiteta. Da bi dobili celovitu sliku o sistemu. Pona anje. Daje pojednostavljenu sliku sistema. moramo imati nekoliko komplementarnih modela koji ga posmatraju. 1:n. Navode se entiteti. Najva nije perspektive su:    Kontekst. Sistem za biblioteku ‡ ‡ ‡ granice sistema prikazane u esnici ± akteri b slu ajevi kori enja Model entiteta. Doga aj iznad se desio pre. Modelira se arhitektura samog sistema ili gradja podataka koje on obradjuje. Promatraju se transformacije podataka. m:n). i promene njegovih stanja.struktura Class diagram Dinami ki model ± pona anje Dijagram sekvenci (sequence diagram) Dijagram slu ajeva kori enja UML Use-case Koristi se na po etku novog projekta za opis su tinskih funkcija na najvi em nivou apstrakcije. pa isti e neke njegove osobine a zanemaruje druge. Trag doga aja je grafi ki opis niza doga aja koji se razmenjuju izme u entiteta u stvarnosti. Struktura.Modeli predstavljaju va an most izmedu specifikacije i dizajniranja sistema. Modeli u fazi definisanja i specifikovanja zahteva y y y Model toka podataka ± za koji se koristi UML Use-case dijagram . veza i atributa    posmatra sistem iz perspektive strukture i opisuje gra u podataka. Jedan graf = jedno pona anje 26 . Dijagram klasa (Class diagram) Predstavlja entitete i me usobne odnose Model pona anja objekata Dijagram sekvence. reakcije sistema na dogadaje. Odreduje se granica izmedu sistema i njegove okoline.

U dizajniranju struktura podataka ili algoritama detaljno se dizajniranju i opisuju slo enije strukture podataka odnosno algoritmi koji se pojavljuju u sistemu. a zatim dolazi re enje problema. Mre ni server na kraju alje dokument u kompresovanom obliku. Pod-aktivnosti dizajniranja sistema ‡ ‡ Svaka pod-aktivnost daje svoje izlazne rezultate. a ve i delovi se dalje rastavljaju na manje. U dizajniranju arhitekture uo avaju se i dokumentuju pod-sistemi koji ine sistem.Korisnik napre pristupa katalogu biblioteke da vidi da li je odre eni dokument dostupan u elektronskom obliku. Zatim tra i da mu se taj elektronski dokument dostavi preko mre e. Dekompozicija ve ih delova sistema u manje  Dizajniranje se u velikoj meri svodi na dekompoziciju ve ih delova u manje.  Dizajn sistema obuhvata: precizni opis gra e sistema. U mnogim slu ajevima je broj re enja neograni en. korisni kog interfejsa. za svaki pod-sistem se dizajnira i dokumentira interfejs prema drugim pod-sistemima i prema korisniku. delova od kojih se on sastoji. Softverski dizajn   Na sli an na in specifikacija zahteva defini e problem. Dizajniranje sistema  Nakon faze analize zahteva dobijaju se dva dokumenta: y y  Jedan za klijenta. 27 .  Dizajniranje sistema je iterativni postupak. U apstraktnom specificiranju. do dizajna se dolazi postepenim profinjavanjem i razradom kroz vi e iteracija. U sklopu dizajna korisni kog interfejsa. tj. interfejsa izme u delova. od korisnika se zahteva da prihvati ugovor o licenciranju. ‡ Dizajniranje delova obavlja se tako da se svaki pod-sistem dalje rastavlja na sastavne delove: opisuje se svaki deo zasebno. dakle apstraktni i vrlo precizni opis zahteva.  Poslednja iteracija dizajniranja se obi no preklapa sa implementacijom. i veze me u tim pod-sistemima. Slede i korak u razvoju je prevo enje tih elja u re enje: y Dizajn koji e zadovoljiti potrebe klijenta ta je to dizajn?  To je kreativni proces pretvaranja PROBLEMA u RE ENJE  Opis re enja se tako e naziva dizajn. gde su obuhva ene njegove potrebe Drugi za dizajnere u kome se problem obja njava tehni kom terminologijom. Zbog za tite autorskih prava. za svaki pod-sistem pi e se specifikacija softverskog dizajna.

y y y o Strukturiranje sistema   Rezultat strukturiranja je blok dijagram. Modeliranje kontrole. Komponente su obi no moduli. a arhitektura opisuje i njihove me usobne veze. Pod-sistemi i odnosi me u njima  Pod-sistem je relativno samostalna celina. a mo e se posmatrati iz perspektive nasle ivanja. odnosno kori enja operacija me u klasama. . delovi su objekti odnosno klase. Sistem se dizajnira kao skup objekata koji medjusobno komuniciraju. Komunikacija izmedu pod-sistema se odvija tako da jedan zapi e podatke u bazu. . Pod-sistem je sastavljen od svojih delova (moduli. ) i ima definisan interfejs za komunikaciju s drugim pod-sistemima. Okvirno se odre uje na in komunikacije pod-sistema i na in njihove kontrole. Objektni pristup. Rezultat je hijerarhijski sistem koji je lako implementirati u klasi nim programskim jezicima. . Postoji vi e modela strukture koji su se pokazali upotrebljivi za razne sisteme. tj. a strelice ozna avaju komunikaciju. ije funkcionisanje uglavnom ne zavisi od drugih podsistema. a kasnije kod dizajniranja delova. svaki pod-sistem dalje razla emo na svoje module i tako dalje. kome pristupaju svi podsistemi. U sklopu dizajniranja arhitekture se pojavljuju dve pod-aktivnosti: o Strukturiranje sistema. Ovo je uobi ajena struktura za sisteme koji rade s velikim koli inama podataka (informacioni sistem banke ili preduze a)  Model klijent-server 28 . o Dizajniranje arhitekture sistema     ARHITEKTURA ± povezuje sposobnosti sistema navedene u specifikaciji zahteva sa sistemskim komponentama koje e ih implementirati. objekti. Utvr uje se komunikacija izme u pod-sistema. Odre uje se tok kontrole izmedu pod-sistema. Sistem se rastavlja na pod-sisteme. Najpre kod dizajniranja arhitekture se ceo sistem razlo i na pod-sisteme. tj. Sistem se direktno mo e implementirati u objektno-orijentisanim programskim jezicima. agregacije. Postoje dve razli ite vrste odnosa pod-sistema: me usobna komunikacija i me usobna kontrola. Sistem se dekomponuje na nekoliko pod-sistema. Gra a sistema obi no nije hijerarhijska. Sistem se dizajnira sa stanovi ta funkcija (procesa). razmena podataka. Dekompozicija se uglavnom obavlja nekim od dva pristupa: o Funkcionalni pristup. ko nad kim upravlja. gde su blokovi pod-sistemi. Zna i. od kojih svaki obavlja odre eni skup zadataka. Vrlo je va no odrediti odnose izme u pod-sistema. Model s repozitorijumom  Svi zajedni ki podaci uvaju se u sredi njoj bazi podataka (repozitoriju). a drugi pro ita te podatke.

Softverski dizajn je kreativni proces pretvaranja problema u rje enje. spolja nje karakteristike sistema. Dobar konceptualni dizajn y y y y y y y Pisan jezikom klijenta Ne sadr i tehni ke izraze Opisuje funkcije sistema Ne zavisi od implementacije Povezan sa dokumentima specifikacije zahtjeva Omogu ava klijentu da shvati to e sistem da radi Obja njava vidljive. klijenti: pod-sistemi koji tra e usluge ponu ene od servera mre a: omogu uje komunikaciju klijenata i servera. Priroda rje enja mo e da se mijenja i u toku opisa ili implementacije sistema. Konceptualni i tehni ki dizajn y y y y Dizajn je iterativni proces koji iz dva dijela. omogu uje lako dodavanje novog servera. Prednosti modela klijent-server:    omogu uje distribuciju sistema na mre u ra unara. Opis rje enja se tako e naziva dizajn. Po to klijent odobri konceptualni dizajn. 29 . Prvo se formira konceptualni dizajn ili dizajn sistema koji opisuje korisniku ta e sistem da radi. Model klijent-server y y Ovo je uobi ajena struktura za mre no-orijentisane sisteme. Mane modela klijent-server:  svaki server se mora sam brinuti za administriranje svojih podataka. Tehni ki dizajn omogu ava sistemskim in injerima i programerima da utvrde karakteristike sistema (koji softver i hardver e se koristiti za rje avanje problema). Modeli sistema Faze razvoja softverskog sistema o o o o Specifikacija zahtijeva defini e problem koji treba rije iti. Prilog prikazuje zami ljenu multimedijsku biblioteku. vr i se prevo enje u mnogo detaljniji dokument ± tehni ki dizajn.  svaki klijent mora znati koje usluge se nalaze na kom serveru. Sistem se sastoji od slede ih delova:    serveri: pod-sistemi koji nude usluge drugim pod-sistemima. Nakon analize i specifikacije zahtijeva slijedi dizajniranje sistema.

To su: ‡ ‡ ‡ ‡ ‡ Modeli konteksta Modeli pona anja Modeli podataka Objektni modeli CASE (Computer-Aided System/Software Engineering ) Modeli konteksta    U ranoj fazi analize zahteva. U konceptualnom dizajnu sistema modeli moraju biti razumljivi korisnicima.  Izdvoji emo naj e e kori enje savremene tehnike za modelovanje sistema. potrebno je odrediti granice novog sistema. 30 . ta je unutar sistema. Kada se ovo uradi na po etku smanjuju se tro kovi i vreme potrebno za analizu sistema.Dobar tehni ki dizajn l Opisuje: ‡ ‡ ‡ ‡ ‡ ‡ Konfiguraciju hardvera Hijerarhiju i funkcije softverskih komponenti Korisni ki interfejs Ulaze i izlaze sistema Mre nu arhitekturu Strukturu i tokove podataka Modelovanje sistema ‡ ‡ ‡ ‡ Dizajn sistema opisuje se modelima. tj. problema koje treba re iti i samog sistema koji treba da se razvije. Modeli konteksta se koriste da ilustruju gde su granice sistema. Modeli tako e predstavljaju most izme u faze analize i dizajna Razli iti modeli opisuju sistem iz razli itih perspektiva ‡ ‡ ‡ Spolja nja perspektiva je prikaz konteksta sistema i okru enja. Izbor modela zavisi od problema koji se re ava. a ta je okru enje. Perspektiva pona anja prikazuje pona anje sistema: Strukturna perspektiva prikazuje arhitekturu sistema ili strukturu podataka. Tehnike modelovanja sistema Sistem se mo e modelovati na mnogo na ina. Modeli sistema su grafi ki prikazi poslovnih procesa. U tehni kom dizajnu modeli moraju biti razra eni i opisani do detalja.

Modeli stanja     Ovi modeli opisuju kako sistem reaguje na spoljne i unutra nje doga aje.  Mo e biti dopunjen tabelama koje opisuju stanje i pobudu.  U njega je upisan opis akcije koju to stanje obavlja  Strelice predstavljaju pobudu koja uzrokuje prelaz iz jednog stanja u drugo. pa se esto koriste za modelovanje real-time sistema. Model stanja koji pokazuje kako sistem reaguje na doga aje.  Postoje dva tipa modela pona anja: o o Model toka podataka koji pokazuje kako se podatak obra uje dok se kre e kroz sistem.  Funkcionalno orjentisane metode 31 . Modeli toka podataka  Dijagrami toka podataka (Data flow diagrams) se koriste za prikaz koraka obrade podataka kroz sistem.  Naj e e je za poslovne sisteme dovoljno samo napraviti dijagram toka podataka. o Potreban je veliki broj dijagrama stanja to ote ava sistem in injerima i programerima da razumiju kako sistem funkcioni e. sistem prelazi iz jednog stanja u drugo. sistemi za rad u realnom vremenu su esto vo eni doga ajima (event-driven) i za njih je najpogodniji model stanja koji prikazuje pona anje sistema za razli ite doga aje. Oni prikazuju odzive sistema na doga aj.  Podaci se transformi u u svakom koraku obrade i u druga ijem obliku se prenose u slede i korak. Ne prikazuju tok podataka u sistemu Problem sa modelima stanja o Broj mogu ih stanja rapidno raste i postaje nemogu e predstaviti na jednom dijagramu sva stanja sistema.  Nasuprot tome. u zavisnosti od vrste i namene sistema koji se razvija.  Jednostavna i univerzalna notacija koju korisnici mogu razumjeti.Modeli pona anja  Modeli pona anja se koriste da opi u celokupno pona anje sistema. da bi se prikazalo pona anje sistema.  Ovi modeli mogu biti kori eni zajedno ili posebno. Modeli podataka  Koriste se za opisivanje logi ke strukture podataka obra enih od strane sistema.  Ve ina poslovnih sistema je zasnovana na podacima (data-driven) i njima se upravlja na osnovu unetih podataka. Dijagrami stanja  Zaobljeni pravougaonik u dijagramu ozna ava stanje sistema. Kada se doga aj desi.

 ER dijagram ilustruje logi ku strukturu baze podataka. Objektni modeli     Objektno-orijentisani pristup celom procesu razvoja softvera je danas uobi ajen. veze izme u tih entiteta.  Objektno orjentisane metode  UML ne posjeduje specifi ne notacije za modeliranje podataka. objekte. Strategija dizajniranja . ne od operacije ili funkcije Sistem ine objekti koji su me usobno u interakciji Oblikuju se klase objekata i odnosi izme u klasa (stati ki i dinami ki prikaz) Objektno orijentisano modelovanje ± deo objektno orijentisanog razvoja sistema gdje se objektno-orijentirana strategija prote e kroz razvojni proces: o o o Objektno-orijentisana analiza Objektno-orijentisani dizajn Objektno-orijentisano programiranje Objektno orjentisana anliza i dizajn sistema  Metoda je prikladna za dizajn sistema koji rade u realnom vremenu. postavlja po etne entitete sistema.  Faze metode su: o Identifikacija objekata i klasa o Identifikacija semantike objekata (interfejs objekata. naslje ivanje. tako to se svaki entitet mo e posmatrati kao klasa objekta. jer podrazumeva objektno-orijentisani proces razvoja i modelira podatke kori enjem objekata i veza. Re nik podataka  Re nik podataka je lista svih imena kori enih u modelima sistema.  Metoda podr ava klase. Tako e uklju uje i opis entiteta. atributi entititeta kao atributi klase.Naj e e kori en model je Entitet-veza-atribut model (Entity Realationship model ± ER model). pona anje objekata) o Logi ki dizajn (relacije klasa i objekata) o Implementacija  Objektni modeli i UML  UML predstavlja standardno prikazivanje uvedeno od strane razvojnog tima koji kreira objektno orjentisane metode za analizu i dizajn. veza i atributa. slanje poruka. i njihove atribute. dizajn i implementaciju.  Me utim UML se mo e koristiti za modeliranje podataka. a relacije izme u entiteta kao veze me u klasama.  On je postao standard za objektno-orijentisano modelovanje.  UML je jezik za: o specifikaciju.  Primena o Podr ka upravljanju imenima i izbegavanju duplikata o Skladi te organizacionih znanja povezuje analize.  Mnogi CASE alati podr avaju re nike podataka.polazi od objekta. 32 .

transformi u projekat u izvr ni kod o Kontrolori kvaliteta ± provjeravaju strukturu i pona anje sistema 33 . and components) integrisanje i razvijanje prakti nim iskustvom. arhitektura. grafi ki jezik.  Generalni ciljevi kojima UML jezik te i: o stvaranje jezika za modelovanje kojim je mogu e razvijati i razmjenjivati modele sa odre enim zna enjem. slo enih softverskih sistema. o nezavisnost od programskih jezika i razvojnih procesa o pru anje formalne osnove za razumijevanje jezika za modelovanje o o podsticanje razvoja OO programskih jezika podr ka apstraktnih razvojnih pojmova kao to su saradnja.  nedvosmisleni i potpuni modeli.  UML je standardni vizuelni jezik za modelovanje dominantno. projekat.koji je postavljen kao standard od OMG (Object Management Group ± http://www. ali ne isklju ivo. o konstrukciju  pomo u jezika UML konstrui e se softverski sistem koji se posle mo e implementirati.rational. o Ko su korisnici UML-a?  Korisnici UML-a su: o Sistem-analiti ari i krajnji korisnici ± specificiraju zahtijevanu strukturu i pona anje sistema o Rukovodioci projekta ± vo enje i usmjeravanje kadrova i upravljanje resursima o Projektanti ±projektuju sistem na osnovu zahtijeva o Razvojni in injeri . dokumentovaje  Razvila ga je kompanija Rational Software Corporation (http://www.omg.  UML se koristi za modelovanje softverskih sistema naro ito onih koji se zasnivaju na OO metodologiji. frameworks. patterns. konstruisanje.2. okvirni rad. o specifikaciju  pomo u UML jezika formiraju se precizni.o o o vizualizaciju. izvorni kod itd. o dokumentovanje  pomo u jezika UML mogu se dokumentovati zahtijevi.org).2003 u sastavu IBM-a) UML  UML je grafi ki jezik za: o vizualizaciju  UML je vizuelni.com) (od 20. uzorci i komponente (collaborations. ta je cilj UML jezika ?  UML je razvijen sa ciljem da pojednostavi veliki broj OO razvojnih metoda.

UML ± 9 osnovnih dijagrama 34 .

UML pogledi na arhitekturu sistema (4+1 Arhitectural Views) UML defini e 4+1 pogleda na arhitekturu (Arhitectural Views) koji se opisuju pomo u 13 dijagrama Primjer upotrebe UML dijagrama u iterativnom procesu razvoja PRIMER: MODELOVANJE SISTEMA RENT-A-CAR AGENCIJE POGLEDOpis funkcionalnosti sistema  Sakupljanje zahteva o funkcionalni i nefunkcionalni zahtevi  Kreiranje specifikacije zahteva za sistem o UML Use Case dijagram o Opis Use Case dijagrama  Identifikacija akteri i njihovih relacija sa slu ajevima kori enja 35 .

Use Case Pogled Opis Use Case scenarija  Scenario = Tok aktovnosti u slu aju kori enja o Osnovni o Alternativni  UML Dijagram aktivnosti o Opisuje kako se aktivnosti de avaju u sistemu Primer: Rent-a-Car ± Logi ki aspekt Dizajniranje logi ke strukture sistema  Identifikacija entiteta o Identifikacija atributa o Identifikacija operacija o Identifikacija relacija o Identifikacija mnogostrukosti  Kreiranje Dijagrama klasa Primjer: Rent-a-Car ± Dinami ki aspekt  Identifikacija objekata  Identifikacija interakcije (poruke) o Opis pona anja sistema .AutoPark .³kako´ sistem funkcioni e 36 .