PROJEKTOVANJE SOFTVERA PROJEKTOVANJE SOFTVERA Softver moe biti sistemski

PROJEKTOVANJE SOFTVERA

PROJEKTOVANJE SOFTVERA Softver može biti sistemski i aplikativni. l U sistemski softver spadaju operativni sistemi i razni uslužni programi. kao na primer: prevodioci za pojedine jezike, komunikacioni program i drugo. l

PROJEKTOVANJE SOFTVERA l Aplikativni softver piše sam korisnik ili ga kupuje od nekog proizvođača, radi rešavanja određenog zadatka iz domena svog poslovanja.

PROJEKTOVANJE SOFTVERA l Kvalitet i pisanje softvera u celini, još uvek u značajnoj meri zavise od inventivnosti i veštine programera. l l Da bi se pomoglo programerima u pisanju softvera ustanoljene su neka osnovna pravila za pisanje softvera.

DIZAJN SOFTVERA l l l Uz pomoć ustanovljenih pravila pisanje softvera se približava inženjerskim disciplinama i tako otklanjaju problemi u pisanju softvera, kao što su: kašnjenje softverskih projekata, neispunjavanje osnovnih funkcija koje se očekuju od softvera, nekorektno ponašanje u nestandardnim situacijama, složeno upravljanje i drugo.

FAZE DIZAJNA SOFTVERA l l l definicija programa, modularni dizajn, razmatranja o programskom jeziku, pisanje programskih specifikacija, provera dizajna i pregled dizajna.

FAZE DIZAJNA SOFTVERA Definicija programa zahteva pažljivo razmatranje prioriteta, svrhe i funkcije svakog programa, koji će ući u aplikaciju. l Nakon definisanja programa, analitičar ga pažljivo deli na specifične zadatke ili module. l

FAZE DIZAJNA SOFTVERA l Posle identifikacije modula, analitičar se koncentriše na detalje svakog modula, obraćajući posebno pažnju na načine na koji su moduli međusobno vezani. l Celokupna kolekcija definicija programa i modula čini programske specifikacije.

FAZE DIZAJNA SOFTVERA Kada su moduli specificirani, analitičar može da razmatra koji programski jezik bi sistem mogao da koristi za pisanje potrebnog programa. l Ovo se različito rešava u različitim organizacijama. l

FAZE DIZAJNA SOFTVERA l U jednim se koristi samo jedan programski jezik za sve programe, dok se u drugim organizacijama ostavlja velika sloboda analitičaru u izboru odgovarajućeg programskog jezika, čak postoji mogućnost i korišćenja različitih programskih jezika u zavisnosti od potreba pojedinačne aplikacije (aplikativnog sftvera).

FAZE DIZAJNA SOFTVERA l Na kraju, ceo sistem se podvrgava kontroli i reviziji dizajna. l Revizija dizajna daje poslednju šansu upravi i korisnicima da pregledaju predloženi sistem, uvere se da on ispunjava sve njihove potrebe i da podrazumeva prihvatljive troškove. l Menadžment može još uvek da odbaci sistem ili da zahteva modifikacije, pre nego što ovlasti njegovu primenu.

FAZE DIZAJNA SOFTVERA l Faza dizajna se završava pisanjem programskih specifikacija. l Specifikacije uključuju ulaz, bazu podataka, izlaz, mrežu i dizajn softvera.

U izradi programa postoje sledeće faze: postavka problema, l projektovanje programa, l razvoj programa, l ispitivanje performansi programa i l l završno uobličavanje programa.

Kreiranje liste programa l Zahteva od analitičara da pregleda dijagram toka podataka (DFD - data flow diagram) za predloženi sistem, a isto tako i rečnik podataka i formate izveštaja (iz dizajna izlaza), šeme (iz dizajna baze podataka) i kolekciju podataka za formate ekrana (iz dizajna ulaza).

Kreiranje liste programa Za vreme pregleda, analitičar izdvaja tačku od koje sistem treba da proizvodi izveštaje i ispituje svaku aktivnost procesa kao potencijalni program. l Analitičar traži osnovne procese, koji dalje nisu deljivi. l l Ovi procesi su idealni kandidati za programe.

MODULARNI DIZAJN

MODULARNI DIDZAJN l Posle definisanja glavne svrhe svakog programa, analitičar deli svaki program u module, od kojih svaki izvršava jednu funkciju i ima početnu i završnu tačku, koje je moguće identifikovati. l Svaka od ovih funkcija formira poseban modul, koji je povezan sa drugim modulima na određeni način.

Razlozi koji govore u prilog modularnoj izgradnji programa l 1) kod velikih nesegmentiranih programa, troši se mnogo vremena na njihovo održavanje, l 2) kod nemodularnih programa mnogo teže se pronalaze greške,

Razlozi koji govore u prilog modularnoj izgradnji programa l 3) modulnost u dizajnu programa omogućuje: - jednostavnost izrade i najsloženijih programa, - veću pouzdanost programa, - smanjenje razvojnih troškova, - lako proširenje programa, - lako uključivanje novih modula, l - lakšu kontrolu izrade programa. l l l

MODULARNI DIZAJN Ne koristi svaka organizacija analitičara za modularni dizajn. l Neke organizacije dodeljuju posao modularnog dizajna programerima, a koriste analitičare samo da pregledaju dizajne. l U malim organizacijama programer, odnosno analitičar može sam da uradi sve. l

MODULARNI DIZAJN l Modul čini grupa izvornih instrukcija smeštenih između određenih granica, koje imaju svoje ime. l Modulima se daju imena, koja odražavaju njihove aktivnosti (npr. otvaranje, štampanje podataka, zatvaranje i dr. ). l Preko imena modula vrši se njegovo pozivanje.

MODULARNI DIZAJN l Funkcija modula je da izvrši određenu transformaciju ulaza u izlaz.

MODULARNI DIZAJN l Na primer, kod postupka ažuriranja neke datoteke, najčešće logičke celine koje mogu da predstavljaju module su: inicijalizacija i otvaranje datoteke, formiranje novih slogova, ažuriranje postojećih slogova (izmena sloga i brisanje sloga) i zatvaranje datoteka. l Moduli su odvojene, posebne funkcijske celine, koje je moguće identifikovati.

MODULARNI DIZAJN Da bi se prilagodili standardima struktuirane metodologije, svaki modul treba da sadrži samo jednu ulaznu i jednu izlaznu tačku. l Najbolji moduli sadrže jedan ulaz, jedan izlaz i jednu svrhu. l

MODULARNI DIZAJN l Podela programa u module pojednostavljuje posao, čineći ga lakšim za razumevanje. l Osim toga, ispitujući svaki modul posebno, analitičar može lakše da uoči moguće logiške greške. l Što se pre otkriju nastale greške, to ih je lakše popraviti.

Spajanje modula Posle definisanja i usavršavanja svih modula, analitičar počinje važan posao u određivanju veza koje spajaju module. l Glavno pravilo je da očuvamo veze između modula na minimumu. l

Spajanje modula Koristimo termin spajanje da bi uputili na mere kontrole i nezavisnost između modula. l Spajanje nam dozvoljava da se moduli organizuju na način da se smanji veza između modula na minimum. l

Spajanje modula Programi su kolekcija modula, povezanih međusobno u hijerarhijskom redosledu ili u obliku stabla. l Neki moduli služe kao roditelji i oni kontrolišu samo onu decu module, koji su direktno pod njihovom nadležnošću. l

KONTROLNE STRUKTURE Svi programi mogu da se napišu u obliku jedne od tri osnovne kontrolne strukture: sekvence, odluke i ponavljanja ili iteracije. l Kontrolna struktura sekvence opisuje serije akcija (tj. naredbi), koje slede jedna iza druge u linijskom redu, zbog čega se ova kontrolna struktura naziva i linijska struktura. l

KONTROLNE STRUKTURE l Osnovna karakteristika programa sa ovom kontrolnom strukturom jeste da se pri jednom izvršavanju programa svaka naredba izvrši jedanput. l U jednostavnim primerima i ceo program može obrazovati linijsku strukturu.

KONTROLNE STRUKTURE Kontrolna (razgranata) struktura odluke opisuje situaciju u kojoj akcija zavisi od toga koji se od dva uslova ispunjava. l Postoje dve grane, jedna grana označena sa DA, koja se izvršava kada je ispunjen dati uslov i druga označena sa NE, koja se izvršava kada nije ispunjen dati uslov. l

KONTROLNE STRUKTURE Ponavljanje (iteracija ili petlja) predstavlja treću vrstu kontrolne strukture. l Naziva se i ciklička struktura. l Mogućnost obrazovanja programskih ciklusa znatno smanjuje dužinu programa. l

KONTROLNE STRUKTURE l Za organizaciju programskog ciklusa moramo poznavati koje naredbe čine ciklus i kako se izlazi iz ciklusa. l Naredbe koje čine ciklus zovemo telo ciklusa, a uslov pod kojim se izlazi iz ciklusa zovemo izlazni kriterijum. l Prema tome kakav je izlazni kriterijum, cikluse delimo na brojačke i uslovne.

KONTROLNE STRUKTURE l Ciklus u kome je broj ponavljanja ciklusa kriterijum za izlazak iz ciklusa zovemo brojački ciklus. l Uslovni ciklus predstavlja zapis po kome se blok naredbi izvršava sve dok je uslov tačan. l Kada uslov postane netačan, ciklus se završava i program nastavlja izvršavanje naredbom koja sledi iza tela ciklusa.

l RAZMATRANJA O PRIHVATANJU PROGRAMSKOG JEZIKA

Izbor odgovarajućeg programskog jezika Pošto menadžment odobri sistemski dizajn, analitičar bira odgovarajući programski jezik koji će se koristiti. l U različitim organizacijama postoje različiti pristupi razmatranju o prihvatanju nekog programskog jezika. l Ako postoji neko ograničenje, analitičar može da izabere programski jezik koji najviše odgovara aplikaciji. l

PROGRAMSKE SPECIFIKACIJE Imaju formu izveštaja sa sledećim elementima: l sistemski pregled, l dijagram toka podataka, l format izlaznog izveštaja, l šema baze podataka, l izgled ekrana ili formati ulaza, l definicije programa, l opisi modula.

PROGRAMSKE SPECIFIKACIJE l Sada kada ima definisane programe, planirane module, izabrane kontrolne strukture, razložene i obrađene module, utvrđene veze između modula i izabrani programski jezik, analitičar sjedinjuje izlaze iz svih drugih faza dizajna i obrazuje programske specifikacije.

SISTEMSKI PREGLED l U ovom delu procesa dizajna prikuplja se i sumira sav materijal koji je proizveden u toku prethodnih faza dizajna. l Sistemski pregledi često uključuju i opise metoda kolekcije podataka i sistemskih operacija, objašnjenja svrhe svakog programa unutar sistema i šemu programiranja - plus imena analitičara, programera i svih individualnih programa.

DIJAGRAM TOKA PODATAKA l Razvijen u toku analize i možda usavršen u toku dizajna, DFD (dijagram toka podataka) orijentiše čitaoca gde se on nalazi u sistemu.

FORMAT IZLAZNOG IZVEŠTAJA l Razvijeni na početku faze dizajna, formati izlaznog izveštaja, takođe, obrazuju deo programskih specifikacija.

ŠEMA BAZE PODATAKA l Četvrta komponenta programskih specifikacija je šema baze podataka, koja se može napisati korišćenjem, na primer, Oracle-ovog SQL-a.

IZGLED EKRANA ILI FORMATI ULAZA Dizajni ekrana specificiraju zahteve koji su vezani za unos podataka. l Dizajn ekrana treba da specificira tipove podataka (numerički, alfanumerički ili drugi, koje podržava DBMS) i da definišu zahteve. l

DEFINICIJA PROGRAMA Definicije programa i opisi modula završavaju specifikaciju. l Definicija programa je doslovan opis cilja i svrhe programa. l

PROVERA DIZAJNA l Obezbeđuje pažljivo ispitivanje sistemskog dizajna i programskih specifikacija. l U toku ove faze analitičar, programer (ili vođa programerskog tima), drugi analitičari i nekada i korisnik kritikuju specifikacije u pokušaju da lociraju greške modula, da provere dovršenost i da osiguraju jasnoću konačnog programa.

PROVERA DIZAJNA l Kao zaključak provere analitičar može prostudirati probleme, napraviti potrebne ispravke i onda pustiti ispravljen sistem i programske specifikacije na dalje razmatranje. l Ako tim nađe dosta grešaka može da predvidi da se izvrši naknadna provera.

PROVERA DIZAJNA l Pošto provera ne bi trebalo da bude ocenjivanje analitičarevog rada, već bi trebalo da osigura kvalitet, onda nikakav formalan rezime ne ide menadžmentu. l Provera nije test softvera, ali je prilika da se uoče greške, pre nego što one porastu. l Testiranje je važan deo svih projekata razvoja softvera, ali se ostvaruje u trećoj fazi, implementaciji softvera. l

PREGLED DIZAJNA l Kada analitičar ispravi sve greške i doda sve nedostajuće elemente, tada menadžment, korisnici i analitičar izvršavaju formalan pregled dizajna. l Tokom ove prezentacije sistema svi proučavaju programske specifikacije.

PREGLED DIZAJNA l Analitičari bi trebalo da povedu dosta računa tokom ovog pregleda, zato što on obezbeđuje poslednju šansu svim zainteresovanim stranama da provere da li će sistem ispuniti potrebe organizacije uz prihvatljive troškove i planirana ograničenja.

PREGLED DIZAJNA l U nekim slučajevima, promene u poslednjem času mogu odložiti razvijanje sistema, ali obavljanje promena će sada manje koštati nego kada bi se one vršile pošto programiranje otpočne. l Ako se svi slažu da sistem treba da produži da se razvija, memorandumom se formalno ovlašćuje sledeći korak.