5 predavanje III dio Oblikovanje i implementacija U

5. predavanje III. dio Oblikovanje i implementacija

U ovom poglavlju trebali bi. . . definirati što je oblikovanje, dizajn i implementacija nabrojiti pod-aktivnosti unutar oblikovanja opisati strukturiranje sustava i opisati poznatije modele

Osnovni pojmovi oblikovanje je dio softverskog procesa koji dolazi nakon specifikacije nakon što smo utvrdili ŠTA treba sustav raditi, sada trebamo utvrditi KAKO će sustav raditi Rezultat oblikovanja je dizajn sustava – precizni opis građe svih dijelova sustava (iterativni postupak koji dovodi do konačnog dizajna) Implementacija dolazi nakon oblikovanja – realizacija u nekom od programskih jezika

Pod-aktivnosti unutar oblikovanja 1/2

Pod-aktivnosti unutar oblikovanja 2/2 Svih 6 pod-aktivnosti generiraju neke rezultate (najčešće su to neki dokumenti) Posebno treba voditi računa da se specificiraju sučelja prema drugim pod-sustavima i sučelja prema korisniku Svaki pod-sustav se rastavlja na manje dijelove, a svaki se opisuje zasebno Veći dijelovi se dalje rastavljaju na manje Detaljno se oblikuju algoritmi i potrebne strukture podataka!

Dekompozicija većih dijelova sustava u manje Dva osnovna pristupa Funkcionalni pristup – oblikovanje sa stanovišta funkcija (procesa). Dobiva se hijerarhijski sustav koji je lagano implementirati u klasičnim programskim jezicima. Objektni pristup – oblikovanje kao skup objekata koji međusobno komuniciraju. Dijelovi su objekti odnosno klase. Implementira se u OOP jezicima.

Modeli sustava koji se koriste u oblikovanju Modeli koji su stvoreni tijekom specifikacije koriste se i dalje profinjavaju u oblikoanju Kod funkcionalnog pristupa polazište je model toka podataka, daljnjim profinjavanjem dobivamo strukturalni model sustava. Za objektni pristup, polazište su objektni modeli (nasljeđivanje, agregacija, ponašanje)

Primjer strukturalnog modela sustava

Primjer objektnog modela za obradu faktura – objektni model

Primjer objektnog modela za obradu faktura – model toka podataka

Oblikovanje i kvaliteta softvera Oblikovanje direktno utječe na kvalitetu softvera Softver treba oblikovati u skladu s time koji su nam atributi kvalitete najvažniji Ako je naglasak na 'održavanju' – onda je dobro da se dizajn sastoji od velikog broja malih dijelova, najbolje primijeniti objektni pristup Ako je naglasak na 'efikasnosti' – onda je bolje imati mali broj relativno velikih dijelova čija komunikacija će biti minimalna, potreban je i direktan pristup podacima (koji su onda globalno definirani) iz tih dijelova pa je najbolji funkcionalni pristup

CASE alati za oblikovanje podršku za oblikovanju daju nam i upper-CASE alati koje smo spominjali za implementaciju i testiranje neophodni su nam lower-CASE alati poput MS Visual Studio lower-CASE alati trebaju imati editor za pisanje izvornog koda, prevodilac (compiler), linker, biblioteku standardnih funkcija ili klasa, debugger, statički odnosno dinamički analizator koda, itd.

Oblikovanje arhitekture sustava početna faza oblikovanja dekompozicija sustava na nekoliko pod-sustava od kojih svaki obavlja određeni skup zadataka okvirno se određuju načini komuniciranja, te način kontrole pod-sustava pod-sustav je relativno samostalna cjelina, čije funkcioniranje uglavnom ne ovisi o servisima koje pružaju drugi pod-sustavi

Pod-aktivnosti kod oblikovanja arhitekture sustava Strukturiranje sustava – rastavljanje na podsustave i utvrđivanje komunikacije između njih (razmjena podataka) Modeliranje kontrole – određuje se tok kontrole između pod-sustava, dakle tko s kime upravlja (jer, nije dovoljno samo definirati pod-sustave nego i odrediti odnose između njih)

Strukturiranje sustava Rezultat strukturiranja je nekakav blok dijagram Primjer s robotom koji pakira proizvode koji dolaze s tekuće vrpce:

Još jedan primjer strukture protuprovalnog sustava

Uobičajeni modeli strukture sustava Ponekad se može modelirati s već postojećim, isprobanim i provjerenim modelima, primjerice: Model s repozitorijem Model klijent-poslužitelj (client-server) Model apstraktnog stroja (slojeviti model)

Model s repozitorijem 1/2 Svi zajednički podaci čuvaju se u središnjoj bazi podataka (repozitoriju) Sam repozitorij je isto jedan pod-sustav sam za sebe

Model s repozitorijem 2/2 Uobičajena struktura za sustave koji rade s velikim količinama podataka (banke, velika poduzeća, . . . ) Prednosti: - pojednostavljena komunikacija pod-sustava - administriranje podataka centralizirano - jednostavno nadodati novi pod-sustav Mane: - pod-sustavi se moraju pokoriti zajedničkom modelu podataka -> loš utjecaj na peformanse - repozitorij postaje 'usko grlo' kako ga sve više pod-sustava koristi

Primjer modela s repozitorijom – arhitektura lower-CASE alata

Model klijent-poslužitelj 1/2 Sastoji se iz 3 dijela: - poslužitelji: nude usluge drugim pod-sustavima - klijenti: traže usluge od poslužitelja - mreža: omogućuje komunikaciju

Model klijent-poslužitelj 2/2 Uobičajena za mrežno-orijentirane sustave Prednosti: - omogućuje distribuciju sustava na mrežu računala - omogućuje lagano dodavanje novog poslužitelja ili poboljšanje rada postojećeg - svaki poslužitelj može imati svoj optimizirani model podataka Mane: - svaki poslužitelj mora se brinuti za administriranje svojih podataka - svaki klijent mora znati koje se usluge nalaze na kojem poslužitelju

Primjer klijent-poslužitelj modela – multimedijska biblioteka

Model apstraktnog stroja 1/2 pod-sustavi složeni kao 'slojevi' svaki sloj je 'apstraktni stroj' čiji strojni jezik (skup usluga) služi za implementaciju idućeg sloja

Model apstraktnog stroja 2/2 Najčešće kod sustava gdje želimo ostvariti neovisnost o hardverskoj platformi (Java, OSI model za mrežne protokole sa 7 slojeva, . . . ) Prednosti: - podržan je inkrementalni razvoj sustava - bilo koji sloj može se promijeniti ukoliko zadrži isto sučelje - ako se promijeni sučelje sloja, pogođeni su samo susjedni slojevi - lako se prenosi na drugu platformu Mane: - često je teško podijeliti sustav u slojeve - problemi s performansama zbog višestrukog interpretiranja

Primjer modela apstraktnog stroja – sustav za upravljanje verzijama

Modeliranje kontrole Dva bitno različita pristupa ostvarenju toka kontrole sustava: Centralizirana kontrola – jedan pod-sustav služi 'kontroli' i on pokreće i zaustavlja druge Kontrola upravljana događajima (eng. event driven) – pojedini pod-sustavi samostalno reagiraju na vanjske događaje koji su generirani ili od drugih pod-sustava ili iz dolaze iz okoline

Uobičajeni modeli kontrole sustava Opet postoje neki standardni, već isprobani i provjereni modeli, primjerice: 'Call-return' model Model menadžera 'Broadcast model' Model upravljan prekidom (interrupt driven)

Call-return model 1/2 Model s centraliziranom kontrolom Implementiran u klasičnim programskim jezicima

Call-return model 2/2 Kontrola kreće s vrha hijerarhije (glavni program) i prosljeđuje se na niže članove hijerarhije preko poziva potprograma Primjenjiv je samo za sekvencijalne sustave Prednosti: - mogućnost jednostavne analize toka kontrole Mane: - teško je obraditi iznimne situacije koje remete normalni rad sustava

Model menadžera Jedan pod-sustav kontrolira ostale šaljući im signale za početak i kraj, te ih tako sinkronizira Svi pod-sustavi rade paralelno (menadžer je u beskonačnoj pletlji i stalno ispituje stanje pod-sustava) Pogodan za sustave u stvarnom vremenu gdje zahtjevi za brzinom odgovora nisu prestrogi

Broadcast model 1/2 Spada u modele upravljane događajima Bilo koji događaj emitira se svim pod-sustavima Odgovaraju samo oni za koji jeste taj događaj predviđen

Broadcast model 2/2 Primjenjuje se za sustave u stvarnom vremenu gdje su zahtjevi na brzinu odgovora na događaje 'srednje tvrdi' Prednosti: - lagano se dodaje novi pod-sustav - bilo koji pod-sustav lagano može aktivirati bilo koji drugi - primjenjiv je u slučaju distribuiranih sustava (npr. mreža računala) Mane: - pod-sustavi ne znaju da li će i kada će biti obrađen neki događaj - mogući su i konflikti ako više pod-sustava obrađuje isti događaj

Model upravljan prekidom 1/2 Spada u modele upravljane događajima Svakoj vrsti događaja pridružen je jedan hardverski prekid (interrupt) Svakom prekidu pridružen je posebni podsustav (interrupt handler)

Model upravljan prekidom 2/2 Ovaj model koristi se za 'tvrde' sustave stvarnog vremena Može se kombinirati s nekim od sustava centralizirane kontrole Prednosti: - daje najbrži mogući odgovor na odabrane događaje Mane: - nepogodan je za testiranje - otežana je nadogradnja kad se potroši predviđeni broj prekida