PROJEKTOVANJE SOFTVERA


� Softver može biti sistemski i aplikativni.

� U sistemski softver spadaju operativni sistemi i razni uslužni programi. kao na primer: prevodioci za pojedine jezike, komunikacioni prevodioci za pojedine jezike, komunikacioni program i drugo.


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


� Kvalitet i pisanje softvera u celini, još uvek u značajnoj meri zavise od inventivnosti i veštine programera.

�

Da bi se pomoglo programerima u pisanju � Da bi se pomoglo programerima u pisanju softvera ustanoljene su neka osnovna pravila za pisanje softvera.

DIZAJN SOFTVERA

� 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,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

� definicija programa,

� modularni dizajn,

� razmatranja o programskom jeziku,

� pisanje programskih specifikacija, � pisanje programskih specifikacija,

� provera dizajna i

� pregled dizajna.


� Definicija programa zahteva pažljivo razmatranje prioriteta, svrhe i funkcije svakog programa, koji će ući u aplikaciju.

� Nakon definisanja programa, analitičar ga � Nakon definisanja programa, analitičar ga pažljivo deli na specifične zadatke ili module.


� 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. su moduli međusobno vezani.

� Celokupna kolekcija definicija programa i modula čini programske specifikacije.


� Kada su moduli specificirani, analitičar može da razmatra koji programski jezik bi sistem mogao da koristi za pisanje potrebnog programa. programa.

� Ovo se različito rešava u različitim organizacijama.


� 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 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).


� Konačno, ceo sistem se podvrgava kontroli i reviziji dizajna.

� Revizija dizajna daje poslednju šansu upravi i korisnicima da pregledaju predloženi sistem, korisnicima da pregledaju predloženi sistem, uvere se da on ispunjava sve njihove potrebe i da podrazumeva prihvatljive troškove.

� Čak i u ovoj fazi dizajna menadžment može još uvek da odbaci sistem ili zahteva modifikacije, pre nego što ovlasti njegovu primenu.


� Celokupna faza dizajna se završava pisanjem programskih specifikacija.

� Specifikacije uključuju ulaz, bazu podataka, � Specifikacije uključuju ulaz, bazu podataka, izlaz, mrežu i dizajn softvera.

U izradi programa postoje sledeće faze:

� postavka problema,

� projektovanje programa,

� razvoj programa,

� ispitivanje performansi programa i

� završno uobličavanje programa.

Kreiranje liste programa

� 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 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. potencijalni program.

� Analitičar traži osnovne procese, koji dalje nisu deljivi.

� Ovi procesi su idealni kandidati za programe.

MODULARNI DIZAJN

MODULARNI DIDZAJN

� 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.završnu tačku, koje je moguće identifikovati.

� 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

� 1) kod velikih nesegmentiranih programa, troši se mnogo vremena na njihovo održavanje,

� 2) kod nemodularnih programa mnogo teže se pronalaze greške,pronalaze greške,

Razlozi koji govore u prilog modularnoj izgradnji programa

� 3) modulnost u dizajnu programa omogućuje:

� - jednostavnost izrade i najsloženijih programa,

� - veću pouzdanost programa,� - veću pouzdanost programa,

� - smanjenje razvojnih troškova,

� - lako proširenje programa,

� - lako uključivanje novih modula,

� - lakšu kontrolu izrade programa.

MODULARNI DIZAJN

� Ne koristi svaka organizacija analitičara za modularni dizajn.

� Neke organizacije dodeljuju posao modularnog dizajna programerima, a koriste analitičare samo dizajna programerima, a koriste analitičare samo da pregledaju dizajne.

� U malim organizacijama programer, odnosno analitičar može sam da uradi sve.

MODULARNI DIZAJN

� Modul čini grupa izvornih instrukcija smeštenih između određenih granica, koje imaju svoje ime.

� Modulima se daju imena, koja odražavaju njihove aktivnosti (npr. otvaranje, štampanje podataka, aktivnosti (npr. otvaranje, štampanje podataka, zatvaranje i dr.).

� Preko imena modula vrši se njegovo pozivanje.

MODULARNI DIZAJN

� Modulima se daju imena, koja odražavaju njihove aktivnosti (npr. otvaranje, štampanje podataka, zatvaranje i dr.).

� Preko imena modula vrši se njegovo pozivanje.

� Funkcija modula je da izvrši određenu transformaciju ulaza u izlaz.

MODULARNI DIZAJN

� 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 datoteke, formiranje novih slogova, ažuriranje postojećih slogova (izmena sloga i brisanje sloga) i zatvaranje datoteka.

� 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.

� Najbolji moduli sadrže jedan ulaz, jedan izlaz i � Najbolji moduli sadrže jedan ulaz, jedan izlaz i jednu svrhu.

MODULARNI DIZAJN

� Podela programa u module pojednostavljuje posao, čineći ga lakšim za razumevanje.

� Osim toga, ispitujući svaki modul posebno, analitičar može lakše da uoči moguće logiške analitičar može lakše da uoči moguće logiške greške.

� Što se pre otkriju nastale greške, to ih je lakše popraviti.

KONTROLNE STRUKTURE

� Corrado Bohm i Guiseppe Jacopini su 1964. godine pokazali da svi programi mogu da se napišu u obliku jedne od tri osnovne kontrolne strukture: sekvence, odluke i ponavljanja ili strukture: sekvence, odluke i ponavljanja ili iteracije.

� 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.

KONTROLNE STRUKTURE

� Osnovna karakteristika programa sa ovom kontrolnom strukturom jeste da se pri jednom izvršavanju programa svaka naredba izvrši jedanput.svaka naredba izvrši jedanput.

� U jednostavnim primerima i ceo program može obrazovati linijsku strukturu.

� To su programi u kojima se obično javljaju naredbe ulaza, dodele i izlaza.

KONTROLNE STRUKTURE

� U jednostavnim primerima i ceo program može obrazovati linijsku strukturu.

� To su programi u kojima se obično javljaju naredbe ulaza, dodele i izlaza.naredbe ulaza, dodele i izlaza.

� Kontrolna struktura odluke opisuje situaciju u kojoj akcija zavisi od toga koji se od dva uslova ispunjava.

KONTROLNE STRUKTURE

� U jednostavnim primerima i ceo program može obrazovati linijsku strukturu. strukturu.

� To su programi u kojima se obično javljaju naredbe ulaza, dodele i izlaza.

KONTROLNE STRUKTURE

� Kontrolna (razgranata) struktura odluke opisuje situaciju u kojoj akcija zavisi od toga koji se od dva uslova ispunjava.

� Postoje dve grane, jedna grana označena sa DA, � 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.

KONTROLNE STRUKTURE

� Ponavljanje (iteracija ili petlja) predstavlja treću vrstu kontrolne strukture.

� Naziva se i ciklička struktura.

� Mogućnost obrazovanja programskih ciklusa � Mogućnost obrazovanja programskih ciklusa znatno smanjuje dužinu programa.

KONTROLNE STRUKTURE

� Za organizaciju programskog ciklusa moramo poznavati koje naredbe čine ciklus i kako se izlazi iz ciklusa.

� Naredbe koje čine ciklus zovemo telo ciklusa, a � Naredbe koje čine ciklus zovemo telo ciklusa, a uslov pod kojim se izlazi iz ciklusa zovemo izlazni kriterijum.

� Prema tome kakav je izlazni kriterijum, cikluse delimo na brojačke i uslovne.

KONTROLNE STRUKTURE

� Ciklus u kome je broj ponavljanja ciklusa kriterijum za izlazak iz ciklusa zovemo brojački ciklus.

� Uslovni ciklus predstavlja zapis po kome se blok naredbi izvršava sve dok je uslov tačan.naredbi izvršava sve dok je uslov tačan.

� Kada uslov postane netačan, ciklus se završava i program nastavlja izvršavanje naredbom koja

sledi iza tela ciklusa.

Dekompozicija i prerada

� Većina sistema se deli na module, od kojih svaki može ponovo da se podeli na još više modula, što u obrnutom smeru može značiti potrebu za daljom preradom dok sve aktivnosti ne ostvare jedan cilj, preradom dok sve aktivnosti ne ostvare jedan cilj, ulazni i izlazni kriterijum.

� Ovo kontinuirano rastavljanje sistema na njegove osnovne komponente zove se dekompozicija i prerada.

Spajanje modula

� Programi su kolekcija modula, povezanih međusobno u hijerarhijskom redosledu ili u obliku stabla.

� Neki moduli služe kao roditelji i oni kontrolišu � Neki moduli služe kao roditelji i oni kontrolišu samo onu decu module, koji su direktno pod njihovom nadležnošću.

Spajanje modula

� Koristimo termin spajanje da bi uputili na mere kontrole i nezavisnost između modula.

� Spajanje nam dozvoljava da se moduli organizuju na način da se smanji veza između modula na na način da se smanji veza između modula na minimum.

Spajanje modula

� Posle definisanja i usavršavanja svih modula, analitičar počinje važan posao u određivanju veza koje spajaju module.

� Glavno pravilo je da očuvamo veze između � Glavno pravilo je da očuvamo veze između modula na minimumu.

Spajanje modula

� Podrazumeva se da su nezavisni moduli slobodno spojeni, a zavisni moduli su čvrsto spojeni.

� Moduli pokazuju pet tipova spajanja: podacima, pečatom, putem kontrole, obično i sadržajem.pečatom, putem kontrole, obično i sadržajem.

Spajanje modula

� Pošto promene unutar slobodno spojenih modula ne zahtevaju uvek promene u drugim modulima, one nisu tako komplikovane za program.

� S druge strane, čvrsto spojeni moduli mogu � S druge strane, čvrsto spojeni moduli mogu drastično da utiču na druge module.

� Iako izgleda poželjno da se prave moduli što je moguće više slobodno spojeni, u praksi samo mali broj modula su slobodno spojeni.

Spajanje modula podacima

� Moduli koji obrađuju podatke i šalju ih drugim modulima pokazuju spajanje podacima i oni su najpoželjniji tip modula.

� Spajanje podacima se pojavljuje kada jedan � Spajanje podacima se pojavljuje kada jedan modul predaje vrednost podataka drugom modulu radi obrade.

� Drugi modul tada manipuliše vrednošću podataka.

Spajanje modula “pečatom”

� Spajanje pečatom postoji kada modul prima više podataka nego što mu je potrebno.

� Na primer, potreban nam je modul da izračunamo popust na fakturu.

� Jedini podaci koji su potrebni modulu su datum, iznos i procenat popusta.

� Poslati ovom modulu broj, ime i adresu prodavca znači kršenje koncepta spajanja pečatom.

� Pravilo kojim treba da se rukovodimo ovde jeste da treba poslati modulu samo potrebne podatke i ništa drugo.

Spajanje modula putem kontrole

� Spajanje putem kontrole se događa kada modul prođe drugi modul sa zastavicom ili indikatorom, koji utiče na logiku pozvanog modula.

� Prekidač za kraj dokumenta je dobar primer � Prekidač za kraj dokumenta je dobar primer spajanja putem kontrole.

� Kada dostignemo kraj dokumenta program izvršava drugačije aktivnosti od onih kada nismo na kraju dokumenta.

Obično spajanje modula

� Situacije koje se odnose na obično spajanje odigravaju se kada dva ili više modula manipulišu

sa istim podacima.

Spajanje modula sadržajem

� Spajanje sadržajem se odigrava tamo gde se jedan modul premešta u sredinu drugog modula ili kada se jedan modul upućuje u sredinu drugog modula. Ovo je najmanje poželjan tip spajanja, zato što on � Ovo je najmanje poželjan tip spajanja, zato što on krši pravilo jedinstvenosti ulaza i izlaza strukturne metodologije.

� Spajanje sadržajem se često pojavljuje kada programeri naprave nepravilnu upotrebu GO TO komande.

Vezivanje modula

� funkcionalno

� sekvencionalno

� komunikaciono

proceduralno � proceduralno

� vremensko

� logičko

� slučajno

Funkcionalni moduli

� Funkcionalni moduli su idealni.

� To su moduli koji se zaista pridržavaju pravila jedinstvenosti.

� Neki od primera takvih modula su: moduli koji � Neki od primera takvih modula su: moduli koji štampaju zaglavlja stranica, uređuju podatke po određenom redosledu i otvaraju ili zatvaraju dokumenta.

Vezivanje modula

� Sekvencijalno vezani moduli su oni koji uzimaju podatke iz prethodnog modula i izvode sledeći zadatak sa podacima.

� Komunikaciono vezivanje se javlja u onim � Komunikaciono vezivanje se javlja u onim modulima koji uzimaju iste podatke i koriste ih u dve ili više svrha.

� Proceduralno vezivanje nastaje onda kada ima mnogo različitih zadataka i modul odlučuje koji će zadatak izvesti.

Vezivanje modula

� Vremenski vezani moduli u ovoj klasifikaciji su oni koji su izvršeni u isto vreme i ne moraju da imaju veze jedan s drugim.

Logički vezani moduli obično imaju više � Logički vezani moduli obično imaju više funkcija i time ne prate pravilo jedinstvenosti.

� Moduli su slučajno vezani kada zadaci koje oni izvode nisu povezani jedan sa drugim. Ovo je najgora kategorija.

Vezivanje modula

� Najbolji moduli su oni koji su spojeni podacima i koji su funkcionalno vezani.

� 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.

U različitim organizacijama postoje različiti � U različitim organizacijama postoje različiti pristupi razmatranju o prihvatanju nekog programskog jezika.

� Ako postoji neko ograničenje, analitičar može da izabere programski jezik koji najviše odgovara aplikaciji.

PROGRAMSKE SPECIFIKACIJE

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

Programske specifikacije imaju formuizveštaja sa sledećim elementima:

� sistemski pregled,

� dijagram toka podataka,

� format izlaznog izveštaja,� format izlaznog izveštaja,

� šema baze podataka,

� izgled ekrana ili formati ulaza,

� definicije programa,

� opisi modula.

SISTEMSKI PREGLED

� U ovom delu procesa dizajna prikuplja se i sumira sav materijal koji je proizveden u toku prethodnih faza dizajna.

� Sistemski pregledi često uključuju i opise metoda kolekcije podataka i sistemskihoperacija, objašnjenja svrhe svakog programa unutar sistema i šemu programiranja - plus imena analitičara, programera i svih individualnih programa.

DIJAGRAM TOKA PODATAKA

� 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

� Razvijeni na početku faze dizajna, formati izlaznog izveštaja, takođe, obrazuju deo programskih specifikacija.

ŠEMA BAZE PODATAKA

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

IZGLED EKRANA ILI FORMATI ULAZA

� Dizajni ekrana specificiraju zahteve koji su vezani za unos podataka.

� Dizajn ekrana treba da specificira tipove podataka (numerički, alfanumerički ili drugi, podataka (numerički, alfanumerički ili drugi, koje podržava DBMS) i da definišu zahteve.

DEFINICIJA PROGRAMA

� Definicije programa i opisi modula završavaju specifikaciju.

� Definicija programa je doslovan opis cilja i svrhe programa. svrhe programa.

PROVERA DIZAJNA

� Obezbeđuje pažljivo ispitivanje sistemskog dizajna i programskih specifikacija.

� U toku ove faze analitičar, programer (ili vođa � 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

� Greške modula mogu nastati zbog nekorektnog spoja, nedovršene prerade ili zbog kršenja jedinstvenosti ulaza, svrhe, izlaza i pravila kontrolnih struktura.

� Cilj provere dizajna je otkrivanje, a ne popravljanje problema.

PROVERA DIZAJNA

� Kao zaključak provere analitičar može prostudirati probleme, napraviti potrebne ispravke i onda pustiti ispravljen sistem i programske specifikacije na dalje programske specifikacije na dalje razmatranje.

� Ako tim nađe dosta grešaka može da predvidi da se izvrši naknadna provera.

PROVERA DIZAJNA

� Pošto provera ne bi trebalo da budeocenjivanje analitičarevog rada, već bi trebalo da osigura kvalitet, onda nikakav formalan rezime ne ide menadžmentu.formalan rezime ne ide menadžmentu.

� Provera nije test softvera, ali je prilika da se uoče greške, pre nego što one porastu.

� Testiranje je važan deo svih projekata razvojasoftvera, ali se ostvaruje u trećoj fazi, implementaciji softvera.

�

PREGLED DIZAJNA

� 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. pregled dizajna.

� Tokom ove prezentacije sistema svi proučavaju programske specifikacije.

PREGLED DIZAJNA

� 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 stranama da provere da li će sistem ispuniti potrebe organizacije uz prihvatljive troškove i planirana ograničenja.

PREGLED DIZAJNA

� 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 nego kada bi se one vršile pošto programiranje otpočne.

� Ako se svi slažu da sistem treba da produži da se razvija, memorandumom se formalno ovlašćuje sledeći korak.

PROJEKTOVANJE SOFTVERA - University of...

Documents

Transcript of PROJEKTOVANJE SOFTVERA - University of...