RAZVOJ POSLOVNIH APLIKACIJA PROJEKTOVANJE SISTEMA Branko Latinovi UVOD

RAZVOJ POSLOVNIH APLIKACIJA PROJEKTOVANJE SISTEMA Branko Latinović

UVOD Projektovanje sistema je kreativni iterativni proces prevođenja problema u njegovo rešenje. osnova za projektovanje: specifikacija zahteva cilj projektovanja: generisanje rešenja koje zadovoljava potrebe naručioca broj mogućih rešenja je obično veliki (može i ∞) sva rešenja ispunjavaju isti cilj rešenja se razlikuju po aspektima kojima posvećuju veću pažnju projektovanjem se utvrđuje skup komponenata od kojih će biti sastavljen sistem i njihovih međusobnih veza

VRSTE PROJEKATA Projektanti Tehnički dizajn Konceptualni dizajn Kako sistem radi? Šta sistem radi? Kupci • • • detaljno opisuje klijentu šta će sistem da radi identifikuje sve entitete, atribute i njihove veze daje korisnički interfejs opisuje vremenski tok događaja u sistemu daje informacije o ulaznim i izlaznim podacima (izvor, format, obrada) Programeri • • • namenjen razvojnom timu utvrđuje hardver i softver za realizaciju daje način komunikacije u sistemu definiše ulaze i izlaze sistema opisuje arhitekturu sistema

METODE PROJEKTOVANJA modularnost na nivou funkcionalnosti. Izdvajaju se komponente tako da svaka ima svoju funkcionalnost, a sve zajedno u potpunonosti opisuju funkcionalnost sistema. Za svaku komponenetu se utvrđuju: ulaz, izlaz, sadržaj, veze sa drugim komponentama. modularnost na nivou podataka. Zasniva se na strukturama podataka. Projektant definiše globalnu strukturu podataka i opisuje kako će podaci biti korišćeni i kakve su veze među njima. modularnost na nivou događaja. Definiše se skup mogućih stanja sistema. Uočavaju se događaji u sistemu, a onda se analizira kako oni menjaju stanje sistema. projektovanje “spolja ka unutra”. Zasniva se na podacima koje korisnik unosi u sistem. Objašnjava se koji su podaci, šta se sa njima dešava sve do dobijanja rezultata. objektno-orijentisano projektovanje. Definišu se klase objekata i njihove veze.

MODULARNOST Sistem je modularan ako svaku aktivnost u njemu obavlja jedna komponenta sa dobro definisanim ulazima, izlazima i osobinama. rezultat bilo koje metode je hijerarhija komponenata ili modula na više nivoa najviši nivo prvi nivo drugi nivo

STRATEGIJE PROJEKTOVANJA Projektovanje na tri nivoa (Shaw i Garlan, 1996. g. ): projektovanje arhitekture sistema. Povezuju se mogućnosti sistema iz specifikacije zahteva sa komponentama (modulima) koje će biti implementirane. Arhitektura opisuje modularnu strukturu i načine povezivanja podsistema u sistem. projektovanje programskog kôda. Obuhvata izbor programskog jezika, struktura podataka i algoritama za obradu. Utvrđuje se skup programskih modula, procedure i funkcije u njima. završno projektovanje. Detaljnije opisuje implementaciju kroz formate podataka, protokole, upravljanje memorijom, . . .

STILOVI U PROJEKTOVANJU Stilovi Stil podrazumeva strukturalnu organizaciju softverskog sistema koja uključuje izbor komponenata, definisanje njihovih uloga i međusobnih veza. cevi i filtri slojevita arhitektura klijent-server arhitektura ravnopravan pristup arhitektura zasnovana na događajima objektno-orijentisani pristup

CEVI I FILTRI (1) koriste se u sistemima baziranim na tokovima podataka svaki korak u postupku procesiranja podataka izdvojen je u jednu filtarsku komponentu (krug na dijagramu) filtri rade nezavisno i nisu svesni postojanja drugih filtara u sistemu podaci prolaze kroz cevi koje povezuju filtre (linije sa strelicama) cevi se mogu koristiti za memorisanje ili za sinhronizaciju Primer: file cat file | grep xyz | sort | uniq > out cat aj ž r sad grep xyz a es j i n li sort (komanda u Unix OS) nije i l e an r i t sor uniq ja lini h i ljen v o on p z be out

CEVI I FILTRI (2) + sistem se lako modifikuje dodavanjem novih filtara, ili uklanjanjem postojećih filtri predstavljaju nezavisne komponente koje se lako samostalno razvijaju filtri se mogu koristiti više puta, tj. moguće je generisati različite tokove kombinovanjem datog skupa filtara stil omogućava konkurentno procesiranje, zato što filtri rade nezavisno i obavljaju svoju funkciju kada prime potrebne podatke, ne čekajući da se svi podaci učitaju ili obrade drugim filtrima jednostavna analiza ponašanja sistema

CEVI I FILTRI (3) podstiče se paketna obrada, pa stil nije dobar za interaktivne aplikacije nepotrebni gubitak vremena u transformacijama podataka (na pr. ulaz tekstualni, a filtar procesira realne brojeve) može se desiti da filtri ponavljaju pripremne funkcije drugih filtara, što utiče na pad performansi i povećanje stepena složenosti sistema (na pr. provera ispravnosti datuma)

SLOJEVITA ARHITEKTURA (1) dekomponuje aplikaciju u više apstraktnih nivoa svaki nivo predstavlja jedan sloj koji sadrži grupu zadataka slojevi su hijerarhijski raspoređeni tako da svaki sloj pruža usluge sledećem višem sloju u hijerarhiji usluge u jednom sloju implementiraju se korišćenjem usluga koje pruža prvi niži sloj u odnosu na posmatrani Primer: sistem za bezbednost datoteka Kriptografija Šifrovanje/dešifrovanje datodeke Digitalni potpis Provera autentičnosti

SLOJEVITA ARHITEKTURA (2) + niži slojevi mogu biti više puta korišćeni od strane različitih viših slojeva postojanje slojeva čini lakšom standardizaciju zadataka razvoj i testiranje jednog sloja se obavljaju nezavisno od drugih slojeva, pošto se veze (interfejsi) između slojeva ne menjaju, već se sve promene obavljaju unutar sloja

KLIJENT-SERVER ARHITEKTURA (1) klijentske komponente zahtevaju usluge od servera serverska komponenta pruža usluge većem broju klijentskih komponenata serveri su stalno aktivni i osluškuju da li ima Klijent zahteva od klijenata zahtevi se šalju komunikacionim kanalima koji zavise od mašina na kojima se server i klijent nalaze Primeri: aplikacije sa udaljenim pristupom bazama podataka udaljeni fajl sistemi web aplikacije Server

KLIJENT-SERVER ARHITEKTURA (2) prispeli zahtevi se obično opslužuju u odvojenim nitima na serveru u komunikaciji često ima „praznog hoda“ zbog saobraćaja na mreži zbog neophodnog transformisanja zahteva i rezultata u formate koji su često različiti na serverskoj i klijentskog strani u distribuiranim sistemima sa više servera koji obavljaju istu funkciju, mora se obezbediti transparentnost (primer Google pretraživač)

RAVNOPRAVAN PRISTUP (1) može se shvatiti kao simetrična klijent-server arhitektura ista komponenta može da radi i kao klijent (zahteva usluge od drugih komponenata) i kao server (pruža usluge drugim komponentama) komponenta može i da zadrži samo jednu funkcionalnost, bilo klijentsku ili serversku komponenta može dinamički da menja svoju ulogu između navedene tri

RAVNOPRAVAN PRISTUP (2) Prednosti komponente mogu da koriste ne samo svoje, već i kapacitete kompletne mreže administriranje je jednostavnije, zato što su ovakve mreže samoorganizujuće skalabilan i otporan sistem na otkaze pojedinih komponenata konfiguracija sistema se može menjati dinamički u toku rada (uključivanje i isključivanje komponenata) Nedostaci nema garancije u pogledu kvaliteta pruženih usluga, pošto komponente sarađuju na dobrovoljnoj osnovi teško je obezbediti sigurnost mreže performanse ovakvih sistema rastu sa povećanjem broja komponenata, ali i opadaju sa njegovim smanjenjem

ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA radi na principu difuzionog emitovanja poruka Primer: okruženje za razvoj softvera komponente (izvori događaja) šalju poruke o tome da je nastupio neki događaj na magistralu događaja ostale komponente na magistrali mogu događajima da pridružuju procedure (registrovanje procedura) zatim sistem poziva sve registrovane procedure Magistrala događaja izmena kôda Alat za editovanje izmena kôda Alat za razvoj izmenjen projeka t test u redu Alat za testiranje

OBJEKTNO-ORIJENTISANI PRISTUP (1) veliki broj savremenih sistema koristi delimično ili u celosti ovaj pristup problem i njegovo rešenje se organizuju kao skup objekata kojima se opisuju ne samo podaci, već i ponašanja pristup koristi enkapsuliranje informacija, pa mnogi projektanti posmatraju klase i objekte sa stanovišta mogućnosti njihovog ponovnog korišćenja u drugim projektima pristup se koristi u celom procesu razvoja (definisanje zahteva, projektovanje, programiranje, testiranje)

OBJEKTNO-ORIJENTISANI PRISTUP (2) Karakteristike identitet. Podaci su organizovani u diskretne celine koje se nazivaju objektima. Objekat ima ime, svoja stanja i ponašanja (na primer, objekat brana, stanja potpuno_otvorena i potpuno_zatvorena, ponašanje zvučno_upozorenje kada branu treba otvoriti). apstrakcija. Predstavlja različite aspekte sistema. Skup apstrakcija formira hijerarhiju koja prikazuje međusobne odnose različitih pogleda na sistem. klasifikacija. Grupisanje objekata sa zajedničkim svojstvima i ponašanjem. Jedna grupa odgovara klasi koja može da ima svojstva (atributi) i ponašanja (operacije). Načini grupisanja mogu biti različiti (na primer, avioni i bicikli – zasebne grupe, ili grupa – prevozna sredstva). Objekat je instanca neke klase. Svaka instanca ima svoje vrednosti atributa, a sa ostalim instancama iz klase ima samo zajednička imena atributa.

OBJEKTNO-ORIJENTISANI PRISTUP (3) Karakteristike enkapsulacija. Pakovanje informacija tako da se spolja vidi ono što treba da bude vidljivo, a ostalo je sakriveno. Klasa enkapsulira atribute i ponašanja objekta, a skriva implementacione detalje. nasleđivanje. Organizovanje klasa u hijerarhiju na osnovu njihovih sličnosti i razlika. Na vrhu je klasa sa opštim osobinama, koja se rafinira u specijalizovane potklase. Potklasa nasleđuje strukturu, atribute i ponašanje nadređene klase. polimorfizam. Osobina da se isto ponašanje različito manifestuje kod različitih klasa i potklasa. Metod klase predstavlja implementaciju operacije klase. U sistemu sa polimorfizmom, više različitih metoda implementira istu operaciju. perzistencija. Sposobnost da ime, stanje i ponašanje objekta opstanu u vremenu, tj. da se očuvaju i nakon promene objekta. Takav objekat je trajan. Ovo se koristi ukoliko se vrednost nekog atributa često menja, a potrebno je sačuvati sve njegove vrednosti.