PROJEKTOVANJE SOFTVERA

Презентација на тему: "PROJEKTOVANJE SOFTVERA"— Транскрипт презентације:

1 PROJEKTOVANJE SOFTVERA

2 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 program i drugo.

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

4 PROJEKTOVANJE SOFTVERA
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 softvera ustanoljene su neka osnovna pravila za pisanje softvera.

5 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, neispunjavanje osnovnih funkcija koje se očekuju od softvera, nekorektno ponašanje u nestandardnim situacijama, složeno upravljanje i drugo.

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

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

8 FAZE DIZAJNA SOFTVERA 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. Celokupna kolekcija definicija programa i modula čini programske specifikacije.

9 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. Ovo se različito rešava u različitim organizacijama.

10 FAZE DIZAJNA SOFTVERA 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).

11 FAZE DIZAJNA SOFTVERA Na kraju, ceo sistem se podvrgava kontroli i reviziji dizajna. 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. Menadžment može još uvek da odbaci sistem ili da zahteva modifikacije, pre nego što ovlasti njegovu primenu.

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

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

14 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 dizajna baze podataka) i kolekciju podataka za formate ekrana (iz dizajna ulaza).

15 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. Analitičar traži osnovne procese, koji dalje nisu deljivi. Ovi procesi su idealni kandidati za programe.

16 MODULARNI DIZAJN

17 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. Svaka od ovih funkcija formira poseban modul, koji je povezan sa drugim modulima na određeni način.

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

19 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, - smanjenje razvojnih troškova, - lako proširenje programa, - lako uključivanje novih modula, - lakšu kontrolu izrade programa.

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

21 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, zatvaranje i dr.). Preko imena modula vrši se njegovo pozivanje.

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

23 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 postojećih slogova (izmena sloga i brisanje sloga) i zatvaranje datoteka. Moduli su odvojene, posebne funkcijske celine, koje je moguće identifikovati.

24 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 jednu svrhu.

25 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 greške. Što se pre otkriju nastale greške, to ih je lakše popraviti.

26 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 modula na minimumu.

27 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 minimum.

28 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 samo onu decu module, koji su direktno pod njihovom nadležnošću.

29 KONTROLNE STRUKTURE Svi programi mogu da se napišu u obliku jedne od tri osnovne kontrolne 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.

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

31 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, koja se izvršava kada je ispunjen dati uslov i druga označena sa NE, koja se izvršava kada nije ispunjen dati uslov.

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

33 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 uslov pod kojim se izlazi iz ciklusa zovemo izlazni kriterijum. Prema tome kakav je izlazni kriterijum, cikluse delimo na brojačke i uslovne.

34 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. Kada uslov postane netačan, ciklus se završava i program nastavlja izvršavanje naredbom koja sledi iza tela ciklusa.

35 RAZMATRANJA O PRIHVATANJU PROGRAMSKOG JEZIKA

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

37 Programski jezici Po stepenu zavisnosti programskog jezika od računara programske jezike delimo na: mašinski zavisne (mašinski i simbolički jezik) mašinski nezavisne (jezici višeg nivoa)

38 - Mašinski zavisni jezici -
Mašinski jezici Izgrađeni su nad binarnom azbukom (0,1) Nije potrebno prevođenje Vezan je za konkretan računar (svaka familija procesora ima svoj mašinski jezik)

39 - Mašinski zavisni jezici -
Simbolički jezici Uvode mnemotehničke skraćenice za operacije i simboličke oznake podataka Jednoj naredbi mašinskog jezika odgovara jedna naredba simboličkog

40 Program koji prevodi simbolički u mašinski jezik zove se asembler.
Za programiranje u mašinski zavisnim jezicima potrebno je dobro poznavanje načina rada i arhitekture određenog računara.

41 Program koji prevodi simbolički u mašinski jezik zove se asembler.
Obično se koriste za programiranje računara za interakciju računara sa I/O uređajima : štampačima skenerima uređajima za čuvanje podataka,... Njime su pisani programi poznati kao drajveri.

42 - Jezici višeg nivoa - Bliži su prirodnom jeziku, čitljiviji i lakši za pisanje programa. Imaju visok stepen nezavisnosti od arhitekture računara

43 - Jezici višeg nivoa - Bliži su prirodnom jeziku, čitljiviji i lakši za pisanje programa. Imaju visok stepen nezavisnosti od arhitekture računara Na osnovu načina prevođenja i izvršavanja dele se na : Kompajlerske (Algol, Fortran, Cobol, PL/I,...) Interpreterske (Lisp, Prolog, Basic,...)

44 U početku se razlikovala primena u:
Oblasti poslovanja – karakterisao je veliki broj I/O podataka i relativno jednostavan opis obrade podataka (Cobol) Nauci i tehnici – karakterisao je mali broj I/O podataka, ali veoma složen opis obrade, pa su razvijani jezici za tu namenu (Fortran, Algol...) Vremenom se gubi ova podela i savremeni programski jezici mogu se koristiti ravnopravno u ovim oblastima.

45 PREMA NAČINU REŠAVANJA PROBLEMA
Proceduralne – dajemo računaru kompletan skup instrukcija kojim se rešava problem, tj. dajemo mu algoritam za rešavanje zadatka (pa se zovu i algoritamski). Tu spadaju: Pascal, Cobol, C, Basic, Fortran, mašinski,... Deklarativne – opisujemo šta znamo o problemu i šta želimo da dobijemo rešavajući ga, a sistem (interpreter) sam dolazi do postupka za rešavanje problema. Primeri deklarativnih jezika su Prolog i SQL.

46 Na osnovu načina alokacije memorije:
Programske jezike sa statičkom alokacijom memorije (C++, C#, Java, Pascal,...). Programske jezike sa dinamičkom alokacijom memorije (Ruby, Lisp, JavaScript i Python).

47 Najčešća podela programskih jezika:
Objektno orijentisani jezici Proceduralni jezici Funkcijski jezici Logički jezici

48 U funkcijskom programiranju funkcije se primenjuju na argumente i vrednosti.
Vraćene vrednosti se koriste kao argumenti za druge funkcije sa izbegavanjem pripisivanja naredbi. Primer je Lisp kod koga je primarna struktura sa kojom radi lista.

49 Proceduralni jezici su se menjali i razvijali tokom vremena.
Fortran i Cobol spadaju u prve jezike višeg nivoa. Oko god došlo je do velike softverske krize jer je naredba GO TO dovela do toga da se programi teško prate i imaju previše grešaka.

50 Proceduralni jezici su se menjali i razvijali tokom vremena.
Dolazi do razvoja strukturiranih programskih jezika (Algol, Pascal,...) i “zabrane” korišćenja naredbe GO TO. Sledeća faza je razvijanje modularnih programskih jezika koji funkcionišu tako što razbijaju program na manje celine (module) gde svaki modul obavlja određenu funkciju.

51 Objektno orijentisani jezici su jezici poslednje generacije.
Objekti su jedinice informacija koje sadrže podatke kao i metode za procesiranje i rad sa podacima. Da bismo koristili gotov objekat ne moramo da znamo kako je on pravljen niti šta je u njemu, već samo kako i šta on radi. U OO jezike se ubrajaju : Java, C++, Python...

52 Logički programski jezici
Pripadaju klasi deklarativnih (neproceduralnih) programskih jezika. Zasnovani su na predikatima (logičkim izrazima). Logički jezici: Prolog (PROgramming in LOGic) Datalog

53 Razvoj programskih jezika je veoma brz.
Posebno je uslovljen razvojem hardvera i komunikacija. Sve navedene podele nisu striktne, jer razvojem neki programski jezik može da preuzme dobra rešenja iz drugih jezika, a koja su se pokazala korisnim.

54 www.tiobe.com TIOBE index

55 www.tiobe.com TIOBE index

56 www.tiobe.com TIOBE index

57 www.tiobe.com TIOBE index

58 www.tiobe.com TIOBE index

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

60 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 programski jezik, analitičar sjedinjuje izlaze iz svih drugih faza dizajna i obrazuje programske specifikacije.

61 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 sistemskih operacija, objašnjenja svrhe svakog programa unutar sistema i šemu programiranja - plus imena analitičara, programera i svih individualnih programa.

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

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

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

65 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, koje podržava DBMS) i da definišu zahteve.

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

67 PROVERA DIZAJNA Obezbeđuje pažljivo ispitivanje sistemskog dizajna i programskih specifikacija. 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.

68 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 razmatranje. Ako tim nađe dosta grešaka može da predvidi da se izvrši naknadna provera.

69 PROVERA DIZAJNA 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. 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 razvoja softvera, ali se ostvaruje u trećoj fazi, implementaciji softvera.

70 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. Tokom ove prezentacije sistema svi proučavaju programske specifikacije.

71 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 potrebe organizacije uz prihvatljive troškove i planirana ograničenja.

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