case proizvodistroga.anonima.free.fr/pdf/glava13.pdf · bolje performanse racunarskih i...

13. Glava

CASE proizvodi

Racunarske nauke i tehnologije su se u poslednje dve decenije razvijale, svakako,vrlo intenzivno u vise razlicitih pravaca. Moze se reci, kako za danas tako i za proteklovreme, da impuls tom brzom razvoju daju svakim danom sve vece tehnicke mogucnosti ibolje performanse racunarskih i komunikacionih uredjaja.

Uslovi savremenog nacina poslovanja, s jedne strane, a mogucnosti hardvera, sdruge strane, diktiraju da krajnji korisnici racunarskih sistema imaju sve slozenije informa-cione zahteve. Za takve korisnicke zahteve treba realizovati i odgovarajuce programskeproizvode, koji treba da ispunjavaju sledece, medjusobno konfliktne zahteve:• odgovarajuca sveobuhvatnost, aktuelnost i funkcionalnost s obzirom na domen pri-

mene,• visoka pouzdanost u radu,• dovoljno brz odziv pri davanju odgovora na informacioni zahtev korisnika,• jednostavnost za upotrebu,• jednostavnost za odrzavanje i• da budu dovoljno brzo realizovani, s obzirom na trenutak identifikacije informacionog

zahteva.Vremenom se pokazalo da su se mogucnosti hardverskih uredjaja povecavale

prilicno "paralelno", ili s manjim zaostajanjem u odnosu na porast obima i slozenosti in-formacionih zahteva korisnika, dok su karakteristike postojecih programskih proizvodabitno zaostajale za iskazanim potrebama korisnika i mogucnostima hardvera. Cini se da jetakav trend prisutan i u trenutku pisanja ovog teksta. Fenomen zaostajanja realizovanih pro-gramskih proizvoda, s obzirom na aktuelne potrebe i mogucnosti hardvera, dosta je ranoidentifikovan, a poznat je pod nazivom softverska kriza.

408. P. Mogin, I. Lukovic, M. Govedarica / Principi projektovanja baza podataka

Ovo poglavlje se bavi pojmom i ulogom CASE proizvoda i, delom, jezika IV ge-neracije, u postupku razvoja informacionog sistema i motivima za razvoj samih CASE pro-izvoda. Ti motivi su direktna posledica softverske krize. Zato se i pojmu krize softvera pos-vecuje duzna paznja. Razvoj CASE proizvoda je omogucio i prakticnu primenu prototips-kog pristupa razvoju softvera i reverznog inzenjeringa, te se i ovim pojmovima posvecujeodredjeni prostor. Pored toga, u poglavlju ce biti nesto detaljnije predstavljena dva CASEproizvoda: ORACLE/Designer 2000 i IIS*CASE.

13.1. Softverska kriza

Razvoj programskih proizvoda je, u proslosti, bio oslonjen na razlicite tipove alataza programiranje.

U prvoj fazi, u upotrebi su bili masinski jezici (jezici I generacije), cija je karak-teristika bila vrlo teska citljivost i zavisnost od hardvera.

U drugoj fazi, koristili su se asembleri (jezici II generacije), koji su takodje bilizavisni od hardvera i tesko citljivi.

Nakon toga, u trecoj fazi, u upotrebu su usli jezici III generacije (3GL)*). Jezici IIIgeneracije su, kao i masinski jezici i asembleri, proceduralno orijentisani. Osim toga, bitnakarakteristika ovih jezika je nezavisnost od hardvera. S jezicima trece generacije, u upotre-bu je usla i tehnika strukturiranog programiranja.

Glavna karakteristika uvodjenja u upotrebu jezika III generacije je bilo povecanjeproduktivnosti programiranja (odnosno povecanje kvaliteta i brzine realizacije programskihproizvoda). S druge strane, povecanje produktivnosti islo je na ustrb performansi (brzinerada) tadasnjih programskih proizvoda i funkcionalnosti (sirine primene) jezika III genera-cije. Problem pada performansi je resavan uvodjenjem u upotrebu sve "mocnijeg" hardvera,a problem smanjene funkcionalnosti je resavan tehnikom povezivanja programa, pisanihputem jezika III generacije, s asemblerskim programima, ili daljim povecavanjem moguc-nosti samih jezika III generacije.

Ulaganja u softver, hardver, ljudskeresurse i razvoj programskog proizvoda

Oèekivani efekti ulaganja

Slika 13.1.

*) 3GL je skracenica za Third(3) Generation Language.

Glava 13. CASE proizvodi 409.

Ocekivanja da ce programski proizvodi, koji su razvijani upotrebom jezika IIIgeneracije, pratiti potrebe krajnjih korisnika i mogucnosti hardvera se vec sedamdesetihgodina nisu ostvarivala, sto je dovelo do fenomena, nazvanog kriza softvera. Osnovni po-javni oblik softverske krize je bio u tome da ocekivani efekti od razvoja programskih proiz-voda brzo izostaju, bez obzira na znatno povecanje ulaganja u ovu delatnost, sto je ilustro-vano dijagramom na slici 13.1.

Identifikovani su sledeci problemi, kroz koje se softverska kriza prelamala:• najveci deo programerskog vremena je odlazio na odrzavanje postojecih programskih

proizvoda, sto je blokiralo dalji razvoj informacionih sistema i• programiranje upotrebom jezika III generacije je bilo neefikasno i dugotrajno.

Cinjenica da je najveci deo programerskog vremena odlazio na odrzavanje pos-tojecih proizvoda se moze potkrepiti statistickim podacima [Fi], prema kojima se 64%gresaka pri razvoju informacionog sistema pravilo u toku analize korisnickih zahteva i pro-jektovanja informacionog sistema, dok se preostalih 36% gresaka pojavljivalo tokom reali-zacije informacionog sistema. Od pomenutih 64% "ranih" gresaka, svega 30% je otklanjanopre same isporuke softvera. Pri tome, kasno otkrivanje i otklanjanje gresaka iz pocetnih fazarazvoja programskog proizvoda dovodi do eksponencijalnog rasta troskova uvodjenja uupotrebu i odrzavanja proizvoda. Tako, na primer, otklanjanje strateske greske u fazi odr-zavanja kosta i do 100 puta vise, nego ako se greska otkrije na pocetku rada na projektu.Ovo je dovelo do jedne "neprirodne" raspodele finansijskih sredstava, ulozenih u razvojinformacionog sistema, prema kojoj preko 70% ukupnih sredstava ulozenih u razvoj infor-macionog sistema odlazi na njegovo odrzavanje (slika 13.2).

KorisnièkiZahtevi

Analiza &Projektovanje

Programiranje Testiranje Odrûavanje

%

0

20

40

60

80

KorisnièkiZahtevi

Analiza &Projektovanje

Programiranje Testiranje Odrûavanje

%

"Neprirodna" raspodela ulaganja u razvoj informacionog sistema

Slika 13.2.

Poskupljenje odrzavanja i neefikasno programiranje su dovodili do velikih za-kasnjenja u realizaciji projekata informacionih sistema (prema nekim podacima, veliki pro-jekti u Sjedinjenim americkim drzavama su 1985. godine "kasnili" od 30 do 45 meseci).


Saglasno ovim cinjenicama, vremenom su identifikovani sledeci uzroci krize softvera, uoblasti razvoja informacionih sistema:1. Ad hoc projektovanje informacionog sistema, bez primene odgovarajuce metodologije,

sto dovodi do loseg projekta, pojave velikog broja gresaka i prekoracenja zadatih vre-menskih rokova.

2. Nepostojanje softverskih alata, koji bi podrzali projektovanje informacionih sistema, iliautomatizovali postupke projektovanja s dovoljnim nivoom ekspertskog znanja. Ovo,takodje, vodi ka nekvalitetnom projektu, usled otezanog rukovodjenja projektom, frag-mentiranog i nekonzistentnog dokumentovanja i neusaglasenosti delova projekta.

3. Nepostojanje odgovarajucih softverskih alata za razvoj aplikacija informacionog sis-tema, sto vodi ka neefikasnoj realizaciji i odrzavanju informacionog sistema.

Sve to je dovelo do prethodno opisanih posledica. Resenje krize softvera je, prema tome,trebalo traziti u otklanjanju ova tri uzroka. To je vodilo ka:• formalizaciji metodologija i tehnika projektovanja informacionih sistema i• pojavi CASE proizvoda i jezika IV generacije, kao podrske odgovarajucim metodolo-

gijama i tehnikama.

13.2. Softversko inzenjerstvo

Prvi uzrok softverske krize (ad hoc projektovanje) je najranije uocen i predstavljaoje motiv za formiranje posebne discipline u racunarstvu, nazvane softversko inzenjerstvo.Ovaj pojam se pojavljuje pocetkom sedamdesetih godina, pre pojma CASE proizvoda.Ideja softverskog inzenjerstva je bila uvodjenje metodoloskog, inzenjerskog pristupa prirazvoju programskih proizvoda, s ciljem da se u zadatim vremenskim rokovima, preciznomprimenom odgovarajucih tehnika, dodje kako do dovoljno kvalitetnog projektaprogramskog proizvoda, tako i do dovoljno kvalitetnog samog programskog proizvoda.Okosnicu takvog koncepta predstavljaju metodologija zivotnog ciklusa i strukturiranipristup razvoju programskog proizvoda. Posto cilj ovog poglavlja nije bavljenjemetodologijom zivotnog ciklusa i strukturiranim pristupom, na ovom mestu ce, radijasnoce, biti samo ukratko izlozene glavne ideje, vezane za ova dva pojma.

Metodologija zivotnog ciklusa polazi od cinjenice da zivotni vek (ciklus) svakogprogramskog proizvoda prolazi kroz iste faze. To znaci da i razvoj programskog proizvodatreba da prati faznu logiku zivotnog ciklusa. Faze zivotnog ciklusa programskog proizvodasu:• strategija (stratesko planiranje razvoja programskog proizvoda),• snimanje i analiza (detaljna analiza ponasanja realnog sistema i korisnickih zahteva i

konceptualno projektovanje programskog proizvoda),• projektovanje (oblikovanje izvodjackog - implementacionog projekta programskog pro-

izvoda),• programiranje (realizacija programskog proizvoda),• uvodjenje u upotrebu i• eksploatacija i odrzavanje.


Treba naglasiti da sve nabrojane faze prati aktivnost izrade odgovarajuce projektne, od-nosno izvodjacke dokumentacije, dok se u fazi programiranja izradjuju i uputstva za upo-trebu aplikacija, koja predstavljaju sastavni deo programskog proizvoda.

Strukturirani pristup predstavlja opstu tehniku, koja se primenjuje u okviru fazasnimanja i analize, projektovanja i programiranja programskog proizvoda i znaci primenusledecih principa:• postepeno dekomponovanje slozenog sistema na podsisteme manje slozenosti,• nezavisna izgradnja podsistema,• integracija nezavisno izgradjenih komponenti u jedinstvenu celinu (programski proizvod,

informacioni sistem) i• odvajanje pojma projekta programskog proizvoda od pojma njegove realizacije.

13.3. Pojam i namena CASE proizvoda

Drugi i treci uzrok krize softvera (nepostojanje odgovarajucih softverskih alata zapodrsku razvoja programskih proizvoda), kao i kompleksnost zadataka i tehnika koje se umetodologiji zivotnog ciklusa i u strukturiranom pristupu primenjuju, predstavlja motiv zapojavu CASE proizvoda. CASE predstavlja skracenicu od engleskih reci "Computer AidedSoftware Engineering", sto bi u prevodu znacilo "racunarom podrzano softversko inzenjer-stvo" ili, slobodnije, "razvoj programskih proizvoda uz pomoc racunara".

CASE proizvod je bilo koji programski proizvod, namenjen za podrsku, ili auto-matizaciju makar jednog zadatka u okviru zivotnog ciklusa drugog programskog proizvoda,ili je namenjen za kompletnu podrsku projektovanju i realizaciji drugog programskog pro-izvoda. Osnovni ciljevi primene CASE proizvoda su:• obezbedjenje zadovoljavajuceg kvaliteta projekta i projektne dokumentacije,• obezbedjenje zadovoljavajuceg kvaliteta samog programskog proizvoda,• povecanje produktivnosti projektanata i programera,• skracenje vremena projektovanja i realizacije programskog proizvoda i• obezbedjenje jednostavnog i jeftinog odrzavanja programskog proizvoda.

Primena metodologije zivotnog ciklusa i strukturiranog pristupa znace upotrebuveceg broja manje ili vise formalnih tehnika i crtanja razlicitih dijagrama i matrica zavis-nosti na razlicitim nivoima detaljnosti. Pri tome, izmena na jednom nivou detaljnosti cestozahteva izmene i na drugim nivoima detaljnosti. Izmena na jednom dijagramu moze znaciti ipotrebu sprovodjenja izmena na vise drugih dijagrama. Ukoliko je rec o projektu vecegobima, rucno projektovanje i sprovodjenje ovih izmena, odrzavanje konzistentne projektnedokumentacije i kontrola kompletnosti projekta postaju naporan posao, s neizvesnim isho-dom. Tako, na primer, o manuelnom projektovanju baze podataka ima smisla govoriti samoako broj tipova entiteta i poveznika konceptualne seme ne prelazi nekoliko desetina, odnos-no, ako broj identifikovanih obelezja ne prelazi sto. Kada velicina konceptualne semeprelazi ove granice, pokazuje se da problem, zbog kompleksnosti, prouzrokovane obimom,prevazilazi covekove moci percepcije i koncentracije. Tada vreme i napor, potrebni zaizradu projekta, postaju tesko prihvatljivi, a kvalitet rezultata nepredvidiv. U projektu se


javljaju greske u vidu: sinonima, homonima, protivrecnih ogranicenja i, generalno, greske,ucinjene u ranijim fazama projekta, uocavaju se tek u kasnijim fazama, kada ih je tezeotkloniti. Iterativno vracanje na ranije faze projekta u cilju otklanjanja gresaka, mozedovesti do pojave novih gresaka.

Pored toga, strukturirani pristup zahteva od projektanta i programera da posedujuvisoki nivo ekspertskog znanja iz oblasti softverskog inzenjerstva i zadovoljavajuci nivoznanja iz predmetne oblasti za koju se pravi programski proizvod, sto u praksi ne mora bitiuvek obezbedjeno.

Saglasno navedenim razlozima, od CASE proizvoda se ocekuje da obezbede stovisi stepen automatizacije, prilikom izvodjenja sledecih zadataka:• vodjenje dokumentacije,• izrada dijagrama i matrica,• konceptualno i implementaciono projektovanje seme baze podataka,• projektovanje programskih specifikacija aplikacija,• izrada (generisanje) programskog koda,• sprovodjenje izmena,• integracija parcijalnih rezultata projektovanja u jedinstvenu celinu,• kontrola konzistentnosti, kompletnosti i kvaliteta projekta, itd.

U cilju ostvarenja navedenih zahteva, CASE proizvodi su organizovani tako darade nad jedinstvenom bazom podataka, koja se naziva recnik podataka*) CASE proizvoda.Recnik sadrzi podatke o svim elementima (objektima, vezama, dijagramima, matricama,dokumentaciji, itd.), definisanim u okviru jednog, ili vise projekata, koji se smestaju u rec-nik. Svi pojedinacni alati jednog CASE proizvoda, prema tome, koriste i smestaju podatke uisti recnik, sto je ilustrovano primerom, prikazanom na slici 13.3.

Postoje razlicite klasifikacije CASE proizvoda. Jedna, uobicajena i ne suvise se-lektivna, je izvrsena saglasno fazama zivotnog ciklusa koje CASE proizvod pokriva. Sag-lasno toj klasifikaciji, razlikuju se:• projektantski CASE

*) proizvodi - namenjeni za podrsku prve ("gornje") tri faze zivotnogciklusa (strategija, snimanje i analiza i projektovanje), odnosno za podrsku projektovanjuprogramskog proizvoda,

• programerski CASE *) proizvodi - namenjeni za podrsku poslednje ("donje") tri faze

zivotnog ciklusa (programiranje, uvodjenje u upotrebu, eksploatacija i odrzavanje), od-nosno za podrsku realizacije programskog proizvoda i

• integrisani CASE proizvodi - integrisani projektantski i programerski CASE proizvodi,namenjeni da podrze svih sest faza zivotnog ciklusa, odnosno kompletan zivot program-skog proizvoda.

*) Na engleskom: data dictionary, ili repository.*) Na engleskom: Upper CASE.*) Na engleskom: Lower CASE.


Reènikpodataka

Alat za modeli-ranje ERdijagrama

Alat za modeli-ranje dijagramatoka podataka

Alat za modeli-ranje programs-kih specifikacija

…

Generatori koda

Alat za modeli-ranje matrica

Slika 13.1.

13.3.1. Projektantski CASE proizvodi

Projektantski CASE proizvodi treba da podrze prve tri faze zivotnog ciklusa. Udomenu projektovanja informacionih sistema, CASE proizvod koji podrzava fazu strategije,moze da sadrzi alate za podrsku:• planiranja projekta (izbora metodologije i tehnika razvoja informacionog sistema, nacina

i standarda za primenu izabrane metodologije i tehnika),• upravljanja projektom (detaljnog planiranja i izdavanja zadataka i vremenskog termi-

niranja projekta),• planiranja i upravljanja resursima (materijalnim, kadrovskim i finansijskim),• pracenja realizacije projekta i• sprovodjenja postupaka kontrole kvaliteta.

Kada je u pitanju podrska u fazi snimanja i analize, CASE proizvod moze dasadrzi alate za izradu:• strukturnih modela sistema (model funkcionalne, organizacione i prostorne strukture),• modela procesa koji se odvijaju u realnom sistemu,• dijagrama toka podataka,• konceptualne seme baze podataka i• matrica, kojima se iskazuju medjuzavisnosti izmedju elemenata konceptualne seme baze

podataka, kao i funkcionalne, organizacione, ili prostorne strukture sistema.Za fazu projektovanja, CASE prozivod moze sadrzati alate za:


• prevodjenje konceptualne seme baze podataka u implementacionu semu,• implementaciono projektovanje seme baze podataka, koje se moze sprovoditi direktno,

bez prethodne izrade i prevodjenja konceptualne seme, ili putem modifikacija prevedenekonceptualne seme,

• generisanje programskih specifikacija aplikacija (struktura menija, opisa ekranskih ilistampanih formi, podsema i standardnih procedura za upite i azuriranje baze podataka) i

• implementaciono projektovanje programskih specifikacija aplikacija, koje se moze spro-voditi direktno, bez prethodnog generisanja programskih specifikacija, ili putem modifi-kacija prethodno izgenerisanih programskih specifikacija.

Moze se reci da je pri razvoju savremenih projektantskih CASE proizvoda, svenaglaseniji zahtev da CASE sadrzi "inteligentne" alate i alate koji u sebe ukljucuju elementeekspertskog znanja. To prvo znaci da sami alati treba da primoravaju projektanta na posto-vanje formalnih pravila upotrebe odgovarajuce tehnike, koju dati alat podrzava. Na tajnacin, projektant dobija tehnicku pomoc u radu. Pored toga, na visem nivou, ocekuje se daalat "pruzi" projektantu i ekspertsku, tj. intelektualnu pomoc u primeni odgovarajucetehnike. Takva pomoc se ogleda u mogucnosti da sam alat pruza odgovarajuca projektant-ska resenja, ili da je u stanju da analizira, vrednuje i ocenjuje resenja, koja je sacinio samprojektant.

13.3.2. Programerski CASE proizvodi i jezici IV generacije

Pod programerskim CASE proizvodima, kada je u pitanju razvoj informacionihsistema, najcesce se podrazumevaju generatori koda, koji su u mogucnosti da:• na osnovu opisa implementacione seme baze podataka izgenerisu DDL*) opis seme baze

podataka za konkretan sistem za upravljanje bazama podataka i• na osnovu programskih specifikacija izgenerisu 4GL*) programe aplikacija informaci-

onog sistema.Jezici IV generacije (4GL) predstavljaju dalju nadgradnju jezika III generacije u

smislu povecanja nivoa deklarativnosti, preglednosti i lakoce programiranja. Tesko je datipreciznu definiciju pojma jezika IV generacije, jer on podrazumeva siroki spektar progra-merskih ili korisnickih alata, razlicitih namena i mogucnosti - od jednostavnih alata do raz-vijenih jezika. Zbog toga se cesto govori o pojmu okruzenja IV generacije. Na slici 13.4 suprikazani moguci elementi jednog 4GL okruzenja. Treba zapaziti da u takvo okruzenjeulaze i jezici III generacije, sto znaci da ova vrsta jezika i dalje ima svoje mesto u postupkurealizacije programskog proizvoda.

Treba napomenuti da su svi alati iz okruzenja IV generacije, iz istih razloga kao iCASE proizvodi, oslonjeni na jedinstveni recnik podataka. Sta vise, teznja je da ovi alatibudu integrisani s CASE proizvodima, u smislu koriscenja zajednickog recnika podataka,cime se obezbedjuje jedinstveno razvojno okruzenje programskih proizvoda.

*) DDL je skracenica za Data Definition Language (videti knjigu Mogin P, Lukovic I:

"Principi baza podataka").*) 4GL je skracenica za Fourth(4) Generation Language.


Reènikpodataka

Generatori ieditori ekranskih

formi

Jezik podatakaSQL

Generatori ieditori izveštaja

Alati zaprogramiranje

logike aplikacija

Jezici IIIgeneracije

Generatori ieditori menija

Generatori ieditori upita

Slika 13.1.

Generatori koda i 4GL okruzenje su razvijani s ciljem da se prevazidje neproduk-tivno i dugotrajno programiranje uz upotrebu jezika III generacije. Direktni pozitivni efektiprimene generatora koda i 4GL okruzenja se ogledaju u sledecem:• ubrzava se i olaksava proces izrade programskog proizvoda i• smanjuju se troskovi odrzavanja aplikacije, posto je olaksano otkrivanje, pronalazenje i

ispravljanje uocenih gresaka.Posredni pozitivni efekat jeste mogucnost primene prototipskog pristupa razvoju programs-kih proizvoda, o cemu se detaljnije govori u tacki 13.4.

Postoje, svakako, i negativni efekti primene generatora koda i jezika IV generacije.Oni se ogledaju u sledecim cinjenicama:• 4GL, ili generisana 4GL aplikacija je, na istoj hardverskoj platformi, sporija od odgo-

varajuce aplikacije, razvijane uz pomoc jezika III generacije i• funkcionalnost (tj. sirina primene) generatora koda i 4GL okruzenja je manja od funk-

cionalnosti jezika III generacije.Zapaza se da ovi nedostaci predstavljaju kontinuitet trendova, koji se odnose i na uvodjenjeu upotrebu jezika III generacije.

Navedene prednosti i nedostaci upotrebe generatora koda i 4GL okruzenja, uka-zuju da se pravilnim izborom:• generatora koda i 4GL okruzenja,• jezika III generacije i nacina povezivanja s 4GL okruzenjem i• odgovarajuce ("jace") hardverske platforme,mogu obezbediti sve prednosti upotrebe generatora koda i 4GL okruzenja, uz ocuvanje do-voljno dobrih performansi izvrsavanja razvijene aplikacije i dovoljno dobre funkcionalnostiza rad. To znaci da se dodatnim ulaganjima u hardver i alate za razvoj aplikacija mogupostici velike ustede pri realizaciji i odrzavanju aplikacija informacionog sistema.

Dijagram na slici 13.5 ilustruje problematiku funkcionalnosti generatora koda,4GL okruzenja i jezika III generacije. Pokazuje se da se manje slozene aplikacije mogu


direktno dobiti upotrebom generatora koda. Za slozenije aplikacije je, nakon generisanjakoda potrebno izvrsiti dodatna prilagodjavanja, upotrebom alata IV generacije, dok se vrloslozeni i dominantno proceduralni delovi aplikacija, mogu uspesno realizovati samo upo-trebom jezika III generacije. Zbog toga je prethodno i naglasena potreba kombinovaneupotrebe alata IV generacije i jezika III generacije.

Složenost aplikacije

Ulo ženi napor, potre banza realizaciju aplikacije

Granica upotrebe 4GL

Granica upotrebe generatora koda (CG)

Upotreba CG

Upotreba 4GL

Upotreba 3GL

Upotreba kombinacijeCG & 4GL & 3GL

Slika 13.2.

Uz vec navedene, upotreba generatora koda ima jos jedan nedostatak: ponovnogenerisanje aplikacije, nakon vec izvrsenog prilagodjavanja generisanog koda putem alataIV generacije, moze znaciti "unistavanje" prethodno izvrsenih prilagodjavanja. Savremenitrendovi razvoja generatora koda idu ka tome da se ovaj nedostatak ublazi, na dva nacina:• pomeranjem granice upotrebljivosti generatora koda, tako da se putem generatora mogu

napraviti i slozenije aplikacije (cilj je da se predje granica od 80% ukupno generisanogkoda, koji bi bez daljih dorada bio spreman za upotrebu) i

• sistematicnim evidentiranjem doradjenih delova generisanog koda u okviru recnika po-dataka, tako da svako sledece regenerisanje uzme u obzir i postojeca prilagodjenja koda.

13.3.3. CASE proizvodi za projektovanje seme baze podataka

Postoje samostalni CASE proizvodi koji su iskljucivo namenjeni za projektovanjeseme baze podataka. Kao takvi, oni pretezno pripadaju klasi projektantskih CASE proiz-voda. Ukoliko sadrze i generatore opisa seme baze podataka, prilagodjene konkretnim sis-temima za upravljanje bazama podataka, tada pripadaju i klasi programerskih CASE pro-izvoda. Integrisani CASE proizvodi, namenjeni za razvoj informacionog sistema, obaveznomoraju sadrzati alate za projektovanje konceptualne, implementacione i interne seme bazepodataka.


Kada su u pitanju postupci projektovanja seme baze podataka, CASE proizvodi zaprojektovanje konceptualne, implementacione i interne seme, na danasnjem nivou razvoja,najcesce omogucavaju projektovanje konceptualne seme u ER modelu i automatskoprevodjenje ER konceptualne u implementacionu semu, zasnovanu na relacionom modelupodataka. Neki CASE proizvodi omogucavaju i projektovanje fizicke organizacije relacionebaze podataka. Konacni rezultat takvog projektovanja treba da predstavlja automatski izge-nerisani opis implementacione i interne seme u jeziku podataka SQL. Obicno se moze gene-risati opis implementacione seme, specifican za nekoliko rasprostranjenijih relacionih sis-tema za upravljanje bazama podataka.

CASE alat za projektovanje ER konceptualne seme sadrzi:• graficki editor za poluautomatsko crtanje ER dijagrama eksternih i konceptualne seme

baze podataka i• analizator konzistentnosti nacrtanih sema.Graficki editor sadrzi predefinisane standardne geometrijske simbole koncepata ER modela.Crtanje ER dijagrama se obavlja biranjem tih simbola i njihovim povezivanjem, saglasnopravilima strukturiranja ER dijagrama. Analizator konzistentnosti je namenjen za proveruusaglasenosti nacrtanog ER dijagrama sa pravilima strukturiranja i dijagnosticiranje poten-cijalnih homonima i sinonima.

Pojedini CASE alati pruzaju i mogucnost definisanja funkcionalnih zavisnosti,obicno u skupu obelezja tipa entiteta ili poveznika. Nakon definisanja skupa funkcionalnihzavisnosti, CASE alat je u stanju da izvrsi normalizaciju. Ako rezultat normalizacije pokazeda posmatrani tip entiteta ili poveznika treba dekomponovati, CASE alat automatski spro-vodi tu izmenu u ER dijagramu.

Redje se srecu CASE proizvodi za projektovanje relacione seme baze podataka,zasnovani na definisanju univerzalnog skupa obelezja i skupa funkcionalnih zavisnosti, nakoje se primenjuje postupak normalizacije. Ovakav pristup ima potencijalnu prednost, jerizbegava fazu crtanja ER dijagrama, a kao rezultat daje implementacionu semu, koja jesigurno u trecoj normalnoj formi. U praksi se, cesto, pokazuje da ER dijagrami i ne pred-stavljaju tako lako razumljivu podlogu za komunikaciju izmedju projektanta i korisnika,kako se to u literaturi istice. Naime, krajnji korisnik je prevashodno zainteresovan da putemracunara olaksa, ubrza i poveca kvalitet obavljanja svojih radnih zadataka i nije spreman dase udubljuje u analizu kvaliteta konceptualne seme, predstavljene putem, za njega ipak ap-straktne i strane notacije. Tek kada dobije gotove programe, ili njihove prototipove, koris-nik moze da oceni da li mu resenje odgovara ili ne. Kada su u pitanju programeri, njih presvega interesuju podseme u implementacionom modelu podataka. Saglasno tome, crtanjeER dijagrama se moze posmatrati i kao samo usputan i ne bas jednostavan korak u projek-tovanju implementacione seme. Osim toga, kvalitet konceptualne seme u ER modelu poda-taka izuzetno zavisi od znanja projektanta, jer je crtanje ER dijagrama, u sustini, heuristickipostupak. Nema dokaza da "pazljivo" projektovanje ER dijagrama, nakon prevodjenja urelacioni model podataka, uvek rezultuje u skupu sema relacija, koje su bar u trecoj normal-noj formi.

Ozbiljan nedostatak direktnog projektovanja relacione implementacione semepredstavlja potreba definisanja funkcionalnih zavisnosti nad skupom obelezja relativnovelikog kardinaliteta. Taj zadatak ponovo prevazilazi moci percepcije i koncentracije pro-


jektanata. Resenje se trazi u postupcima formalne specifikacije funkcionalnih zavisnosti,putem nekog jezika visokog nivoa. Jedno od takvih resenja predstavlja koncept tipa forme,opisan u sklopu prikaza proizvoda IIS*CASE, u tacki 13.6.2.

13.4. Prototipski pristup razvoju programskogproizvoda

Prototipski pristup razvoju programskog proizvoda predstavlja jos jednu koncep-ciju koja se, uz strukturirani pristup, moze primeniti u okviru metodologije zivotnog ciklu-sa. Iako je ideja o prototipskom pristupu u softverskom inzenjerstvu bila prisutna dostarano, sam prototipski pristup postaje u punoj meri prakticno primenljiv tek pojavom sveo-buhvatnih i kvalitetnih projektantskih i programerskih CASE proizvoda, koji su integrisani sokruzenjem IV generacije. Zbog toga mu se, na ovom mestu, posvecuje odredjena paznja.

13.4.1. Kriticki osvrt na metodologiju zivotnog ciklusa imotivi za pojavu prototipskog pristupa

Motivi za razmisljanje o uvodjenju prototipskog pristupa i njegovog kombinovanjas metodologijom zivotnog ciklusa su povezani s cinjenicom da sve veci "pritisak" trzistainicira potrebu poboljsanja efikasnosti poslovanja u jednom realnom sistemu. Ovo pobolj-sanje efikasnosti intenzivira zahteve za dobijanje pravih informacija u pravo vreme, odaklesledi da vec postojeci trendovi:• povecanja obima i kompleksnosti informacionih zahteva korisnika i• skracenja trazenog vremena, koje je potrebno za realizaciju korisnickih zahteva putem

programskog proizvoda,jos vise dobijaju na znacaju. Prema tome, slikovito se moze reci da je cilj realizovati,postujuci stroge vremenske rokove, dovoljno dobre programske proizvode "za danas",umesto da se razvijaju "idealni" programski proizvodi "za juce".

Osnovna pretpostavka metodologije zivotnog ciklusa je da se faze realizuju strogosekvencijalno, za ceo programski proizvod odjednom. Kada je rec o informacionom siste-mu, tada se svaka faza istovremeno primenjuje na svaki od podsistema, u okviru identifi-kovane arhitekture informacionog sistema. Odjednom se, takodje, projektuje i sema bazepodataka informacionog sistema. Realizacija naredne faze ne zapocinje, dok se tekuca fazane zavrsi. Greske iz prethodnih faza, otkrivene u tekucoj, zahtevaju da se one otklone i do-kumentuju, vracanjem u prethodne i prolaskom kroz sve faze, koje slede iza faze gde jegreska ucinjena. Ovakav nacin primene metodologije zivotnog ciklusa i strukturiranogpristupa se, cesto naziva klasicni, sekvencijalni ili vodopadni model primene metodologijezivotnog ciklusa. On ima svoje dobre osobine da obezbedjuje:• integrisanost informacionog sistema,• dobru dokumentovanost,


• prakticno istovremen zavrsetak svih podsistema informacionog sistema,• zahvaljujuci dobroj dokumentovanosti, pojednostavljeno odrzavanje aplikacija informa-

cionog sistema i• solidne garancije da ce se u konacnom vremenu doci do zadovoljavajuceg resenja pro-

gramskog proizvoda, cime se smanjuje rizik od neuspeha pri njegovom razvoju. I pored svojih dobrih osobina, sekvencijalni pristup, nazalost, nije uvek davaoprave efekte, kada je u pitanju ostvarenje prethodno definisanog cilja. Postoji vise nedos-tataka, koji su ovakvu pojavu uzrokovali. Neki od njih su sledeci:1. Krajnji korisnik u ovom modelu primene metodologije zivotnog ciklusa nije dovoljno

ukljucen u proces razvoja programskog proizvoda.2. Vremenski interval koji protekne od pocetka projekta, do pojave prvih, operativno pri-

menljivih rezultata kod korisnika, je dosta dug.3. Cesta je potreba da se precizni, metodoloski kompleksni projektantski koraci izvode na

osnovu nedovoljno precizno identifikovanih informacionih zahteva.4. Postoji potreba da se u razvoj informacionog sistema uloze znacajna finansijska sredstva

odjednom, umesto da to bude postupno.Prvi nedostatak je povezan s cinjenicom da, nakon faze strategije i samog pocetka

faze analize, korisnik se ponovo intenzivnije ukljucuje u razvoj informacionog sistema tek ufazi uvodjenja proizvoda u upotrebu. Tokom najveceg dela faze analize i tokom faza pro-jektovanja i programiranja, korisnici ostaju skoro potpuno po strani, a te faze najduze traju iu njima se donose vrlo bitne projektantske odluke. Moguce negativne posledice se ogledajuu sledecem:• Privikavanje korisnika na rad s aplikacijama, pogotovo ako je on neiskusan u primeni

informacionih tehnologija, postaje dosta tesko i s neizvesnim ishodom.• Korisnici mogu imati utisak da im neko sa strane namece postupke za izvrsavanje radnih

zadataka, sto radja odbojnost i destruktivan stav prema informacionom sistemu.Kombinacija prva tri nedostatka sekvencijalnog pristupa dovodi do posledice da se

skrivene mane programskog proizvoda i prethodno neidentifikovani korisnicki zahtevi,cesto, otkrivaju tek u fazi uvodjenja aplikacija u upotrebu, sto je jako kasno, jer se korekcijagresaka i odrzavanje komplikuju, a produzava se vreme, potrebno za dobijanje konacnogresenja aplikacija.

U cilju izbegavanja pojave navedenih negativnih efekata, javili su se prototipskipristup, kao i drugaciji modeli primene metodologije zivotnog ciklusa. U neke od njihspadaju: evolutivni, zvezdasti i inkrementalni model.

Prototipski pristup se zasniva na primeni principa komunikacije s krajnjim kori-snikom putem prototipa aplikacije.

Evolutivni, ili kako se jos naziva, spiralni ili iterativni model primene metodolo-gije zivotnog ciklusa se zasniva na ideji: "od globalnog ka detaljnom", u vise iteracija pri-mene faza i koraka metodologije zivotnog ciklusa (videti sliku 13.6). Mada se, formalno,evolutivni pristup moze primeniti bez oslonca na prototipski pristup, pravi smisao ovogpristupa dolazi do izrazaja kada se on kombinuje s prototipskim pristupom.

Zvezdasti model ne uvodi stroga ogranicenja u redosledu primene faza i korakametodologije zivotnog ciklusa (slika 13.6). To ne znaci da prirodnog redosleda izvrsavanjaodredjenih koraka metodologije u ovom modelu nema, vec znaci da on zavisi od vise fakto-


ra, impliciranih konkretnim projektom. Tako, na primer, reverzno inzenjerstvo, ili potrebaza reinzenjeringom postojeceg informacionog sistema, mogu zahtevati potpuno obrnuti re-dosled primene faza zivotnog ciklusa (primena "odozdo na gore").

Inkrementalni model, ili model ogranicenog vremena *) zahteva formiranje rela-

tivno manjih projekata, s nizim stepenom medjusobne integracije, koji se u velikoj meri raz-vijaju nezavisno, prema metodologiji zivotnog ciklusa.

Vazno je napomenuti da, bez obzira na to koji se model primene metodologijezivotnog ciklusa izabere, sve faze i koraci metodologije se, u opstem slucaju, sprovode.

Snimanje i analiza

ProjektovanjeProgramiranje

Uvoðenje u upotrebu

Spiralni model životnog ciklusa

Nivo detaljnosti

Zvezdasti model životnog ciklusa

Snimanje ianaliza

ProjektovanjeProgramiranje

Uvoðenje uupotrebu

Upravljanje projektom

Slika 13.1.

Pogodnim kombinovanjem odgovarajuceg modela primene metodologije zivotnogciklusa i prototipskog pristupa, ocekuje se ispunjenje sledecih zahteva:• skracenje ukupnog vremena razvoja programskog proizvoda, odnosno povecanje pro-

duktivnosti u odnosu na klasicnu primenu metodologije zivotnog ciklusa i• zadrzavanje "niskog" nivoa rizika od neuspeha pri razvoju programskog proizvoda, ili

njegovo smanjivanje, u odnosu na nivo, postavljen klasicnom primenom metodologijezivotnog ciklusa.

Na slici 13.7 je prikazan jedan dijagram koji ilustruje ocekivanu zavisnost nivoa produk-tivnosti i nivoa rizika od primenjenog pristupa pri razvoju programskog proizvoda.

U nastavku teksta, nesto vise paznje bice posveceno prototipskom, evolutivnom iinkrementalnom pristupu.

*) Na engleskom: Timeboxing.


Nivo(rizika/produktivnosti)

Ad hoc projektovanje

Klasièna primena MŽC istrukturiranog pristupa

Prototipski pristup, kombino-van s odgovarajuæim modelomprimene MŽC

Rizik

Produktivnost

Slika 13.2.

13.4.2. Pojam prototipa i koncepcija primene prototipskogpristupa

Prototipski pristup polazi od iskustvene pretpostavke da tehnike snimanja i inter-vjua, kao i ostali klasicni postupci, nisu dovoljni za precizno utvrdjivanje informacionih za-hteva korisnika. Osnovna ideja prototipskog pristupa je da se odmah, nakon ne mnogo de-taljnog snimanja i identifikovanja informacionih zahteva, ne troseci vreme na izvodjenjekompleksnih projektantskih zahvata pri projektovanju seme baze podataka i specificiranjuaplikacija, naprave prva i provizorna resenja, nazvana prototipovi aplikacija informacionogsistema. Putem njih, korisnici i razvojni tim treba intenzivno da saradjuju u svim fazamazivotnog ciklusa. Komunikacija s korisnikom se dinamizira brzim intervencijama na pro-totipu (cak i na licu mesta, kod korisnika), tako da je korisnik u mogucnosti da efekte tihbrzih promena odmah proveri i verifikuje, ili ih odbaci. Na taj nacin, projektanti testiraju ipoboljsavaju prototipska resenja zajedno s korisnikom.

Ciljevi primene prototipskog pristupa treba da budu:• pravovremeno prikupljanje svih relevantnih informacija od korisnika, koje se ticu:

• verifikacije postavljenih ciljeva razvoja programskog proizvoda (odnosno informa-cionog sistema) i predlozenih projektnih resenja,

• identifikacije kriticnih delova buduceg informacionog sistema,• pravilne identifikacije korisnickih zahteva,• strukturiranja seme baze podataka,• strukturiranja i nacina funkcionisanja aplikacija informacionog sistema, itd. i


• rano navikavanje korisnika na nacin funkcionisanja aplikacija informacionog sistema iformiranje pozitivnog odnosa prema informacionom sistemu, nasuprot mogucem de-struktivnom stavu. Pri tome, postoji teznja da se korisnik, kroz zajednicki rad, emotivnoveze za resenje aplikacije, posto aplikacija postaje i "njegovo delo".

Na pocetku ovog poglavlja je vec receno da je vazan preduslov za primenu proto-tipskog pristupa u praksi postojanje dobrih projektantskih i programerskih CASE proiz-voda, koji su integrisani s okruzenjem IV generacije. Sledeci bitan preduslov za njegovuprimenu je angazovanje iskusnog projektantskog tima, kako po pitanju akumuliranogznanja iz predmetne oblasti za koju se realizuje programski proizvod, tako i u oblasti me-todologije razvoja informacionih sistema, a narocito po pitanju vestine upotrebe CASEalata, okruzenja IV generacije i sistema za upravljanje bazama podataka. Treci preduslov seodnosi na krajnje korisnike. Potrebno je angazovati iskusne timove - reprezentativne grupekorisnika informacionog sistema. Njihovo iskustvo se vezuje i za predmetnu oblast i zaupotrebu informatickih tehnologija.

Prototipovi se, saglasno nivou funkcionalnosti, mogu klasifikovati u sledece grupe:• nefunkcionalni,• funkcionalni i• formalni.Nefunkcionalni prototipovi se ne mogu koristiti u obavljanju radnih zadataka korisnika. Unjih spadaju izgledi ekranskih formi, menija i izvestaja. Funkcionalni prototipovi se, baremdelom, mogu koristiti u obavljanju zadataka za koji su namenjeni. Formalni prototipovi suvrlo bliski konacnom resenju.

Nefunkcionalni i funkcionalni prototipovi se izradjuju za takve delove aplikacijakoji su intenzivno orijentisani ka korisniku, dok se formalni izradjuju za one delove aplika-cija u kojima je nivo komunikacije s korisnikom nizak, ali su dosta slozeni postupci obradepodataka (na primer za komplikovane procedure, paketnu obradu podataka, i slicno).

Prema drugoj klasifikaciji, prototipovi mogu biti:• neodbacivi i• odbacivi.

Neodbacivi prototipovi se evolutivnim podesavanjem pretvaraju u konacna resenjaaplikacija, dok sa odbacivim prototipovima to nije slucaj.

Dominantni cilj izrade odbacivog prototipa je precizno identifikovanje informa-cionih zahteva. Takav prototip se dobija primenom generatora koda, a koristi bazu poda-taka, cija sema ne mora biti blizu konacnog resenja. U situaciji kada sema baze podatakanije blizu konacnog resenja, a s druge strane, generisani programski kod cesto moze bitineefikasan i funkcionalno nekompletan, dolazi do potrebe da se programski kod aplikacije,nakon utvrdjivanja informacionih zahteva korisnika, odbaci. Nakon toga, vrse se potrebneizmene u projektu seme baze podataka i razvija novo resenje aplikacije. Korisnicki interfejsi definisani zahtevi u odnosu na funkcionalnost postojece aplikacije se, ukoliko je to mogu-ce, ne odbacuju, vec se ugradjuju u novo resenje aplikacije. Konacno resenje se razvija naosnovu konacne seme baze podataka, u okruzenju koje dovodi do efikasnog programskogkoda. Pri tome, u oblikovanju konacne verzije aplikacije, ponovo se moze poci od resenja,dobijenog putem generatora koda, ili se, ako to zahtevi izricito nalazu, odmah prelazi u pot-puno novo, ciljno okruzenje za razvoj aplikacija.


13.4.3. Prakticni aspekti primene prototipskog pristupa

U ovom delu teksta se diskutuju odredjene preporuke i potencijalne opasnostiprilikom primene prototipskog pristupa, bez pretenzije da je njihov spisak na ovom mestuiscrpljen. Rec je, uglavnom, o cinjenicama, proisteklim iz iskustava u prakticnoj primeniprototipskog pristupa. Zbog toga, moze se reci da su te cinjenice pre savetodavnog, negoformalno strogog karaktera.

Opste preporuke za primenu prototipskog pristupa su sledece:1. Pre pocetka primene prototipskog pristupa, treba precizno definisati standarde za izgled

korisnickog interfejsa, projektovanje i programiranje. Standarde treba usaglasiti s mo-gucnostima odabranog CASE proizvoda, a generator koda upotrebljenog CASE proizvo-da treba prilagoditi, u cilju postizanja bolje podrske standarda za programiranje i izgledkorisnickog interfejsa.

2. U cilju uspesne primene prototipskog pristupa, preporucuje se dekomponovanje celineinformacionog sistema na manje projekte, a zatim definisanje nizeg stepena medjusobneintegracije informacionih podsistema, nego u slucaju klasicne primene metodologije zi-votnog ciklusa.

3. Prilikom davanja korisniku prototipa aplikacije, obavezno ga upoznati s cinjenicom da jeu pitanju prototip, a ne konacno resenje, kako korisnik ne bi bio doveden u zabludu. Pritome, treba precizirati nacin upotrebe prototipa od strane korisnika.

4. Ako je moguce, ne treba praviti vise od tri prototipa jedne aplikacije, kako se ne bi pro-duzilo ukupno vreme izrade aplikacije i doslo do zamora krajnjih korisnika i projektant-skog tima.

5. Ukoliko se zeli postici sto krace vreme dolaska do prototipa, treba se orijentisati pre-tezno ka odbacivim prototipovima aplikacija, jer se time izrada samog prototipa pojed-nostavljuje.

6. Korisnik, radeci s prototipom aplikacije, treba da upotrebljava iskljucivo test podatke.On mora biti prethodno "pripremljen" na cinjenicu da, ukoliko u medjuvremenu dodje doprestrukturiranja seme baze podataka, uneseni test podaci mogu biti izgubljeni. Do gu-bitka test podataka moze doci u situaciji kada je za njihovo prestrukturiranje potrebnouloziti jako veliki napor, pa se od prestrukturiranja svesno odustaje, ili kada je takvoprestrukturiranje, zbog izmena u semi baze podataka, nemoguce izvrsiti.

7. Prototipom aplikacije se moze smatrati resenje koje je dobijeno putem generatora kodanekog CASE proizvoda, prvenstveno na osnovu specifikacija konceptualnog nivoa. Toznaci da se detalji, koji se definisu tek u implementacionom projektu, a nisu podrzaniodgovarajucim generatorom, ne realizuju u okviru prototipa aplikacije, kako sledecagenerisanja ne bi unistila tako isprogramirane celine. Na taj nacin, postize se kratkovreme izrade prototipskog resenja, ali ne i njegova potpuna funkcionalnost.

8. U prototip aplikacije treba, ako je moguce, ukljuciti i odgovarajuce izvestaje, jer tadakorisnik lakse sagledava upotrebljivost aplikacije.

9. Prethodna resenja informacionih sistema (iz drugih - slicnih, ili istog realnog sistema)mogu biti dobre podloge u funkciji prototipskog pristupa.

Problemi koji se mogu javiti prilikom primene prototipskog pristupa, a koji semogu izbeci primenom prethodno opisanih preporuka, su sledeci:


• Iterativni pristup moze dovesti do zamora krajnjih korisnika i projektanata. U ciljuizbegavanja problema, posebno treba obratiti paznju na preporuke 3. i 4.

• Upotreba generatora koda je moguca tek kada je formiran odgovarajuci deo seme bazepodataka, a prototip aplikacije treba, s druge strane, koristiti upravo da bi se pribavilesve relevantne informacije za strukturiranje seme baze podataka, sto znaci da su ova dvazahteva medjusobno konfliktna. Primena preporuka 5., 7. i 9. vodi ublazavanju ovogkonflikta.

• Ako se radi o neodbacivim prototipovima, dorada izgenerisanih aplikacija moze bitizamoran i vremenski zahtevan posao. U cilju "priblizavanja" korisnickog interfejsa ifunkcionalnosti generisane aplikacije konacnom resenju, odnosno olaksavanja postupkadorade izgenerisanih aplikacija, vazno je preduzeti mere, predvidjene preporukom 1.

• Usaglasavanje podataka, unesenih putem neodbacivog prototipa, s bitno prestrukturi-ranom semom baze podataka je, cesto, vremenski zahtevan i neizvesan posao. U ciljuizbegavanja problema, posebno treba obratiti paznju na preporuke 5. i 6.

• Intervencije na prototipu kod korisnika, na licu mesta, mogu stvoriti lazni utisak da jeprojektovanje informacionog sistema trivijalan posao. Da bi se problem izbegao, poseb-no treba obratiti paznju na preporuku 3. Primena preporuke 9., ako za nju postoje uslovi,moze biti i u funkciji ublazavanja ovog problema.

• Ako je rec o manje iskusnim korisnicima ili projektantima, moze se dogoditi da primenaprototipskog pristupa ne ostvari jedan od osnovnih ciljeva - pravovremeno identifikova-nje informacionih zahteva, a da, pri tome, projektant ne spozna takav "promasaj" navreme. Na ublazavanje ili izbegavanje ovog problema pozitivno moze uticati primenapreporuka 8. i 9.

Praksa primene prototipskog pristupa je pokazala da on nije primeren razvoju inte-grisanih informacionih sistema, jer insistiranje na brzom uvodjenju aplikacija u funkcijudovodi do parcijalizacije informacionog sistema. U tom smislu, vazno je obratiti paznju napreporuku 2. Aplikacije koje se razvijaju samo primenom prototipskog pristupa, medjutim,mogu postati "izolovana ostrva". S obzirom na tu cinjenicu, direktna primena iskljucivoprototipskog pristupa je moguca u slucaju da treba razvijati gotovo izolovane podsisteme sniskim stepenom medjusobne integracije.

S druge strane, ocekuje se da prototipski pristup dozivi svoju punu afirmaciju uko-liko se primenjuje u kombinaciji s nekim od modela primene metodologije zivotnog ciklusa.Posebno vaznu ulogu, u tom pogledu, ima evolutivni pristup.

13.4.4. Koncepcija primene evolutivnog pristupa

Jedan od osnovnih principa, na kojem se zasniva primena sekvencijalnog modelametodologije zivotnog ciklusa, jeste da realizacija naredne faze ne zapocinje, dok se tekucafaza ne zavrsi. Pokazuje se, medjutim, da upravo primena ovog principa kod nekih proje-kata moze intenzivirati negativne efekte primene metodologije zivotnog ciklusa, nabrojaneu okviru tacke 13.4.1. Evolutivni model primene metodologije zivotnog ciklusa, nasuprotsekvencijalnom, predvidja da je za odredjene faze zivotnog ciklusa programskog proizvodamoguce da naredna faza zapocne pre nego sto se prethodna zavrsi, sto dovodi do odredje-


nog stepena paralelizma u realizaciji tih faza. Na taj nacin, te faze zivotnog ciklusa pocinjuda se sprovode iterativno. Do ovakve ideje primene metodologije zivotnog ciklusa se dolazina osnovu pretpostavke da ne treba odjedanput realizovati kompletnu fazu i utrositi za toveliku kolicinu vremena i novca, u situaciji kada se projektantske aktivnosti izvode na os-novu nedovoljno precizno identifikovanih informacionih zahteva. Brzi prelazak u narednufazu, pri tome, treba da obezbedi bolje osnove za kasnije uspesno okoncavanje prethodnefaze.

Posto je jedan od bitnih motiva za nastanak evolutivnog pristupa problem nedo-voljno precizno identifikovanih informacionih zahteva, smatra se da njegova prakticna pri-mena ima smisla, ukoliko se on kombinuje s prototipskim pristupom, kao metodom za pre-cizno utvrdjivanje informacionih zahteva. Na taj nacin, za utvrdjivanje informacionihzahteva se pretezno primenjuju odbacivi prototipovi.

Na pocetku primene evolutivnog pristupa, izvrsavaju se aktivnosti faze strategijemetodologije zivotnog ciklusa. Faza strategije se, kao i u slucaju sekvencijalnog modelaprimene metodologije zivotnog ciklusa, mora kompletno sprovesti, tako da do razlika usprovodjenju sekvencijalnog i evolutivnog pristupa dolazi tek pri prelasku na ostale fazezivotnog ciklusa. U cilju primene prototipskog pristupa, projekat informacionog sistema sedeli na niz manjih potprojekata, koji pokrivaju pojedinacne podsisteme. Radi se nekolikoverzija prototipova, tako da svaki naredni predstavlja bolje resenje, dobijeno evolucijomprethodnog. Paralelno s izradom prototipova, rade se i verzije konceptualnog i implemen-tacionog projekta podsistema. Na taj nacin su prototipskim pristupom obuhvacene sledecefaze zivotnog ciklusa: snimanja i analize, projektovanja, programiranja, a delom i uvodjenjau upotrebu.

Postoje dve varijante evolutivnog pristupa. Prema jednoj, nakon utvrdjivanja pre-ciznih informacionih zahteva, rezultati konceptualnog i implementacionog projektovanjabaze podataka se integrisu, a projekti podsistema se usaglasavaju sa semom integrisane bazepodataka. Drugim recima, potprojekti se ponovo posmatraju kao celina i na njih se prime-njuju, nesto izmenjeni, koraci konceptualnog i implementacionog projektovanja, kao priprimeni sekvencijalnog modela metodologije zivotnog ciklusa. Ova varijanta evolutivnogpristupa kombinuje mnoge dobre strane sekvencijalnog modela metodologije zivotnog cik-lusa i prototipskog pristupa, ali ne resava probleme dugog vremenskog intervala od pocetkaprojekta do pojave prvih, operativno primenljivih rezultata kod korisnika i potrebe ulaganjafinansijskih sredstva odjedanput, a ne postupno.

Prema drugoj varijanti, potprojekti se realizuju medjusobno nezavisno i mogu bitifazno pomereni u vremenu. Na taj nacin se resavaju problemi dugog vremenskog intervalaod pocetka projekta do pojave prvih rezultata i potrebe ulaganja finansijskih sredstava od-jedanput. Ovakav nezavisan rad, medjutim, moze dovesti do nizeg stepena integrisanostiinformacionog sistema.

13.4.5. Koncepcija primene inkrementalnog pristupa

Inkrementalni model se moze posmatrati kao posebna varijanta evolutivnogmodela primene zivotnog ciklusa. Na pocetku primene inkrementalnog modela, kao i u slu-


caju evolutivnog, kompletno se sprovodi faza strategije metodologije zivotnog ciklusa. Na-kon toga, formiraju se relativno manji potprojekti, s nizim stepenom medjusobne integracijei fiksiraju se sledeci parametri potprojekta: ciljevi, resursi i rok predaje u upotrebu. Ciljevii resursi, pri tome, predstavljaju varijabilne parametre, koji se po potrebi dinamicki mogumenjati u toku samog projekta, dok je rok predaje u upotrebu programskog proizvodaobavezno fiksan parametar. Potprojekti se realizuju medjusobno nezavisno i mogu bitifazno pomereni u vremenu.

13.4.6. Napomene o izboru odgovarajuceg pristupa

Tokom ustanovljavanja projekta razvoja programskog proizvoda, vrsi se izboropste metodologije po kojoj ce programski proizvod biti razvijen. Ukoliko je izabrana me-todologija zivotnog ciklusa, tada najkasnije do zavrsetka faze strategije, rukovodeci timprojekta mora da se opredeli za odgovarajuci model primene metodologije zivotnog ciklusai izvrsi dodatna prilagodjavanja izabranog modela potrebama projekta. Ne postoje formalnapravila, na osnovu kojih ovaj izbor treba napraviti, vec se moze govoriti samo o preporu-kama. Cilj ovog teksta nije da se bavi pitanjima izbora metodologije razvoja programskogproizvoda. Treba, medjutim, napomenuti da dosta preporuka za izbor odgovarajucegmodela primene metodologije zivotnog ciklusa proizilazi iz razmatranja, datih u okvirutacke 13.4. Na kraju, bitno je navesti i parametre, koji uticu na izbor modela primenemetodologije. U neke od tih parametara spadaju sledeci:• Koliko je realni sistem slozen sa stanovista funkcija koje se u njemu obavljaju.• Kakav je stepen uredjenosti poslovanja u samom realnom sistemu.• Da li je generalna ekonomska i politicka situacija u okruzenju realnog sistema stabilna,

ili ne.• Koji se ciljevi projekta smatraju prioritetnim i u kojoj meri su ciljevi ambiciozno

postavljeni.• Sa kolikim finansijskim sredstvima za realizaciju projekta se raspolaze i kakva je di-

namika obezbedjenja tih sredstava.• Kakve informacione tehnologije stoje na raspolaganju za realizaciju projekta.• Da li je rukovodeci i izvodjacki tim projekta iskusan u primeni odgovarajucih informa-

cionih tehnologija.• Da li je vecina korisnika buduceg programskog proizvoda iskusna u upotrebi resenja,

vezanih za informacione tehnologije, ili ne.• Da li su rukovodece strukture iz realnog sistema, a delom i buduci korisnici, zaintere-

sovani i stimulisani za uvodjenje novog programskog proizvoda.• Da li su, generalno, mogucnosti za obezbedjenje komunikacija otezane, ili ne.


13.4.7. Reverzno inzenjerstvo

Pojam reverznog inzenjerstva u razvoju programskih proizvoda se vezuje za pos-tupak rucnog, ili automatizovanog generisanja projektnih i programskih specifikacija, naosnovu prethodno realizovanog programskog proizvoda. Nastanak pojma i tehnika reverz-nog inzenjerstva je motivisan sledecom situacijom. U mnogim organizacijama ulozena jevelika kolicina materijalnih, finansijskih i ljudskih resursa u razvoj i eksploataciju informa-cionih sistema. Jedan od zahteva, koji se postavlja prilikom prelaska na nove informacionetehnologije, jeste da se u razvoj inovirane verzije informacionog sistema ne krece ispocetka,vec da se sav ulozeni napor, iskustvo, postojeca resenja i resursi sto bolje iskoriste, jer je todaleko ekonomicnije od ponovnog projektovanja informacionog sistema.

Tehnike reverznog inzenjerstva se koriste za ostvarivanje sledecih ciljeva:• generisanje projektne i programerske dokumentacije za aktuelnu verziju programskog

proizvoda, za koju prethodno takva dokumentacija nije uradjena, u cilju stvaranja osnovaza odrzavanje tekuce verzije tog programskog proizvoda ili

• generisanje projektnih i programskih specifikacija programskog proizvoda u formatu"razumljivom" CASE proizvodu, pomocu kojeg se zeli razviti nova verzija tog program-skog proizvoda.

U domenu informacionih sistema, tehnike reverznog inzenjerstva se primenjuju zaostvarenje sledecih zadataka:• generisanje implementacionog opisa seme baze podataka, na osnovu nekih od sledecih

parametara:• realnih podataka koji postoje u bazi,• stanja recnika podataka konkretnog sistema za upravljanje bazama podataka, pod

kojim je posmatrana baza podataka realizovana, ili• opisa datoteka i formata slogova u programskom kodu aplikacija tekuce verzije in-

formacionog sistema,• generisanje konceptualne seme baze podataka, na osnovu implementacione seme baze

podataka i• generisanje programskih specifikacija (struktura menija, ekranskih formi ili formi za iz-

vestaje, podsema i procedurne logike) na osnovu programskih kodova aplikacija tekuceverzije informacionog sistema.

Moze se zakljuciti da izbor tehnike reverznog inzenjerstva i njena automatizovanaprimena u velikoj meri zavisi kako od prirode konkretnog zadataka koji se resava, tako i odkvaliteta, tj. "informativnosti" ulazne specifikacije, na koju se tehnika reverznog inzenjers-tva primenjuje. Na taj nacin, i kvalitet generisanog rezultata je u reverznom inzenjerstvubitno odredjen kvalitetom ulazne specifikacije. Ukoliko se, na primer, tehnika reverznoginzenjerstva primenjuje za generisanje implementacione seme baze podataka, najbolji re-zultat se, u opstem slucaju, moze ocekivati ukoliko se kao ulazna specifikacija iskoristepodaci iz recnika podataka sistema za upravljanje bazama podataka, a najlosiji ako se kaoulazna specifikacija koriste samo realni podaci iz baze. Ova konstatacija, medjutim, nemora biti uvek tacna. Ukoliko recnik podataka konkretnog sistema za upravljanje bazamapodataka sam po sebi nije dovoljno informativan, ili se u tom recniku, iz nekog razloga, ne


nalaze svi potrebni podaci, tada ni izlazni rezultat reverznog inzenjerstva ne moze bitizadovoljavajuci.

13.5. Prikaz CASE proizvoda ORACLE / Designer2000

Programski proizvod korporacije ORACLE, pod nazivom ORACLE / Designer2000, predstavlja komercijalni CASE proizvod, iz klase integrisanih CASE proizvoda, na-menjen za podrsku sledecih faza zivotnog ciklusa: snimanje i analiza, projektovanje, pro-gramiranje, uvodjenje u upotrebu i eksploatacija i odrzavanje informacionog sistema.Razlozi da upravo ovaj CASE proizvod bude izabran za prezentaciju u ovoj glavi leze ucinjenici da je rec o vrlo sveobuhvatnom programskom proizvodu, sa znacajnom prisut-noscu na trzistu u trenutku pisanja ove glave. Kraci prikaz Designer-a 2000 u ovom tekstuse, najvecim delom, odnosi na verziju 2.1. U daljem tekstu su zadrzana originalna engleskaimena za nazive alata i nekih pojmova koje Designer 2000 koristi, pri cemu su data i detalj-nija objasnjenja tih pojmova.

Designer 2000 je organizovan tako da radi nad jedinstvenim recnikom*) podataka,implementiranim u okviru ORACLE baze podataka. Ovaj CASE proizvod mogu koristitisamo za to prethodno ovlasceni korisnici date instalacije sistema za upravljanje bazamapodataka ORACLE.

Sve projektantsko-programerske aktivnosti u okviru Designer-a 2000 se obavljajuu celinama koje se nazivaju aplikacioni sistemi. Aplikacioni sistem moze predstavljatijednu zaokruzenu celinu (podsistem) informacionog sistema. Pri takvom nacinu rada, in-formacioni sistem se razvija radom na vise aplikacionih sistema istovremeno. Organizacijarazvoja informacionog sistema putem vise aplikacionih sistema omogucava visi stepen flek-sibilnosti pri radu, u smislu:• lakseg trazenja podataka i sprovodjenja izmena u okviru projekta,• odrzavanja razlicitih verzija projektne dokumentacije, kao i• zastite sadrzaja recnika podataka od unistenja, nehoticnih izmena i neovlascenog pristu-

pa.Bitno je naglasiti da ovakva organizacija ne uvodi ogranicenja koja bi negativno uticala naintegrisanost informacionog sistema. Postoji, svakako, i mogucnost da se celokupan infor-macioni sistem razvija putem samo jednog aplikacionog sistema. Prilikom prijavljivanja zarad s Designer-om 2000, korisnik se odlucuje za aplikacioni sistem nad kojim ce realizovatisvoje projektantsko-programerske zadatke. Prethodno, korisniku treba da budu dodeljenaodgovarajuca prava pristupa za rad s izabranim aplikacionim sistemom.

*) Recnik podataka proizvoda Designer 2000 se na engleskom jeziku naziva Repository.


13.5.1. Osnovna struktura CASE proizvoda Designer 2000

Metodologija upotrebe Designer-a 2000 moze biti zasnovana kako na klasicnommodelu primene metodologije zivotnog ciklusa, tako i na bilo kojoj od kombinacija, kojaukljucuje evolutivni, inkrementalni ili zvezdasti model primene metodologije zivotnog cik-lusa, kao i prototipski pristup. Designer 2000 omogucuje, takodje, i primenu tehnika reverz-nog inzenjerstva baze podataka i aplikacija informacionog sistema. Designer 2000 funkcio-nise kao integrisani skup programskih alata, razlicite namene (videti sliku 13.8).

Slika 13.1.

U domenu dela faze strategije, kao i faze snimanja i analize, Designer 2000 pred-vidja upotrebu sledecih alata:• Process Modeller, koji je namenjen za dijagramski prikaz procesa i tokova u realnom

sistemu i podrsku njihovog eventualnog reinzenjeringa,• Function Hierarchy Diagramer - alat za modeliranje funkcionalne dekompozicije real-

nog sistema i strukture programske podrske informacionog sistema,• Dataflow Diagramer - alat za modeliranje tokova podataka unutar realnog i informa-

cionog sistema, putem dijagrama tokova podataka i• Entity Relationship Diagramer - alat za konceptualno modeliranje seme baze podataka,

putem dijagrama tipova entiteta i poveznika.Za fazu projektovanja informacionog sistema su namenjeni sledeci alati:

• Database Design Transformer, za prevodjenje ER konceptualne seme baze podataka urelacionu semu baze podataka,

• Design Editor / Server Model, za projektovanje relacione, implementacione seme bazepodataka (oblikovanje sema relacija - tabela, programiranje procedura, funkcija, paketaprocedura i funkcija i trigera baze podataka),


• Application Design Transformer, za inicijalno generisanje programskih specifikacija(opisa programskih modula, podsema i strukture menija),

• Design Editor / Modules, za implementaciono projektovanje programskih modula (tj.programa za interaktivno azuriranje baze podataka, generisanje izvestaja, graficki prikazpodataka i biblioteka procedura i funkcija), kao i struktura programskih modula (menijaaplikacija),

• Design Editor / DB Admin, za projektovanje interne seme baze podataka (zadavanjeparametara fizicke organizacije podataka) i

• Design Editor / Distribution, za projektovanje distribuirane seme baze podataka.Kada su u pitanju faze programiranja, uvodjenja u upotrebu i eksploatacije i odr-

zavanja informacionog sistema, Designer 2000 je opremljen sledecim generatorima koda:• Generate Database From Server Model, za generisanje SQL opisa implementacione

seme baze podataka,• Generate Database Administration Objects - generisanje SQL opisa interne seme baze

podataka,• Generate Module / Forms, za generisanje programskih modula za interaktivan pristup

bazi podataka, zasnovanih na jeziku IV generacije Developer 2000 / Forms,• Generate Module / Reports, za generisanje programskih modula za formiranje izvestaja,

zasnovanih na jeziku IV generacije Developer 2000 / Reports,• Generate Module / Graphics, za generisanje programskih modula za graficki prikaz po-

dataka, zasnovanih na jeziku IV generacije Developer 2000 / Graphics,• Generate Module / Visual Basic, za generisanje programskih modula za interaktivan

pristup bazi podataka, zasnovanih na programskom jeziku Visual Basic,• Generate Module / Web Server, za generisanje ORACLE WebServer programskih

modula, za pristup bazi podataka preko Internet/Web servera, zasnovanih na HTMLformatu i

• Generate Module / Help System, za generisanje programskih modula za prezentovanjeuputstava i ostalih tekstualnih informacija, zasnovanih na Forms ili Microsoft Help kori-snickom interfejsu.

Moze se konstatovati da je Designer 2000, u delu koji se odnosi na generatorekoda, dosta cvrsto povezan i sa ORACLE-ovim okruzenjem IV generacije Developer 2000,u koje, izmedju ostalih, spadaju alati: Form Builder, za kreiranje interaktivnih programskihmodula (koji se jos nazivaju i "forme"), Report Builder, za kreiranje programskih modulaza izvestavanje (koji se nazivaju i "izvestaji") i Graphics Builder, za kreiranje programskihmodula za graficki prikaz podataka ("grafikona").

Pored nabrojanih, Designer 2000 poseduje i sledece programe, koji se svrstavaju uoblast reverznog inzenjerstva:• Capture Design of Database, namenjen za reverzni inzenjering implementacione ili in-

terne seme baze podataka, na osnovu stanja recnika ORACLE baze podataka, kao iutvrdjivanje i eliminisanje razlika izmedju stanja recnika ciljne baze podataka i recnikaDesigner-a 2000,


• Table To Entity Retrofit, namenjen za prevodjenje implementacione seme baze podatakau konceptualnu semu baze podataka, prikazanu putem dijagrama tipova entiteta ipoveznika,

• Capture Design of Form, namenjen za reverzni inzenjering interaktivnih programskihmodula, kreiranih u okviru alata Developer 2000/Forms,

• Capture Design of Report, namenjen za reverzni inzenjering programskih modula zaizvestaje, kreiranih u okviru alata Developer 2000/Reports,

• Capture Design of Library, namenjen za reverzni inzenjering biblioteckih modula, krei-ranih u okviru paketa Developer 2000,

• Capture Design of Visual Basic, namenjen za reverzni inzenjering interaktivnih pro-gramskih modula, kreiranih pomocu alata Visual Basic i

• Capture Applicatoin Logic, namenjen za usaglasavanje implementacione specifikacijeForms modula iz Designer-a 2000 i postojeceg Forms modula iz Developer-a 2000.

U skupu alata opste namene, Designer 2000 poseduje sledece:• Repository Object Navigator, namenjen za direktan pristup objektima u recniku podata-

ka Designer-a 2000, putem hijerarhijski organizovanog navigatora objekata,• Matrix Diagramer, namenjen za izgradnju razlicitih tipova matricnih dijagrama,• Repository Reports, za generisanje velikog broja razlicitih tipova izvestaja, na osnovu

stanja recnika podataka Designer-a 2000, pri cemu ti izvestaji sluze za sprovodjenjeodredjenih kontrola i analiza kvaliteta projekta, ili samo kao "papirna" projektna doku-mentacija,

• Repository Administration Utility, pomocu kojeg se obavljaju administrativni zadaci nadDesigner-om 2000, kao sto su: instalacija i deinstalacija recnika podataka, dodela pravapristupa korisnicima, arhiviranje i dearhiviranje recnika podataka, obavljanje odredjenihformalnih kontrola, itd,

• Online Help, kao alat za prezentovanje uputstava za koriscenje Designer-a 2000 i• SQL Plus, za interaktivno izvrsavanje SQL naredbi nad ORACLE bazom podataka.

Kada je u pitanju objektno orijentisani pristup razvoju informacionog sistema, uokviru Designer-a 2000 se pojavljuje alat pod nazivom:• Object Database Designer, namenjen za projektovanje dijagrama klasa objekata,

prevodjenje dijagrama klasa objekata u implementacionu semu baze podataka i imple-mentaciono i fizicko projektovanje seme baze podataka.

U nastavku, bice ukratko prezentovane osnovne osobine i mogucnosti nekih odalata Designer-a 2000.

13.5.2. Modeliranje funkcionalne, organizacione i prostornestrukture realnog sistema

Funkcionalna dekompozicija realnog sistema se prikazuje putem hijerarhijskihdijagrama, koristeci alat Function Hierarchy Diagramer. Putem istog alata, koriscenjemistih, ili razlicitih dijagrama, iskazuje se i struktura programske podrske informacionog sis-tema. Na slici 13.9 je prikazan izgled korisnickog interfejsa ovog alata, zajedno s izvodom


iz jednog hijerarhijskog dijagrama funkcija sistema.*) Svaka funkcija, koja se kreira putemnavedenog alata, istovremeno predstavlja i proces u buducim dijagramima toka podataka.Zato pojam procesa i funkcije, ili poslovne funkcije, u terminologiji Designer-a 2000, pred-stavljaju sinonime.

Slika 13.1.

Za svaku funkciju se, pored osnovnih podataka, specificira da li je rec o elemen-tarnoj funkciji, ili ne. Za funkciju se kaze da je elementarna, ukoliko njeno zapocinjanjepodrazumeva da ce se ona u celosti izvrsiti, ili ce efekti njenog izvrsavanja u celosti bitiponisteni. Elementarne funkcije se, u principu, ne moraju dalje dekomponovati i tada onepredstavljaju listove u hijerarhijskoj strukturi funkcija. Postoji mogucnost da se elementarnafunkcija, u cilju njenog preciznijeg specificiranja, dalje dekomponuje na atomarne(atomicne) funkcije, koje u tom slucaju predstavljaju listove u hijerarhijskoj strukturi.

Designer 2000 omogucava da se za neku funkciju, po potrebi, specificiraju svefunkcije cije zapocinjanje inicira zavrsetak izvodjenja posmatrane funkcije. Pored toga, sva-koj funkciji se mogu pridruziti razliciti tekstualni opisi u slobodnom formatu, kojima sedetaljnije opisuju priroda funkcije, pravila i ogranicenja pri njenom izvrsavanju, diskutujeznacaj funkcije za postizanje utvrdjenog cilja poslovanja, itd.

Nakon oblikovanja konceptualne seme baze podataka putem dijagrama tipova en-titeta i poveznika, projektant ima mogucnost da za svaku funkciju zada sledece podatke:• tipove entiteta cije podatke funkcija prilikom svog izvodjenja koristi, *) Manji krug pored simbola za funkciju (na dijagramu je to crveni krug) ukazuje na

cinjenicu da je posmatrana funkcija dalje dekomponovana, pri cemu se korisnik mozeopredeliti da li ce podstablo od date funkcije na dijagramu biti prikazano, ili ne.


• za svaki tip entiteta, nacine njegove upotrebe, koji mogu biti: selekcija, dodavanje, modi-fikacija, brisanje, arhiviranje i ostali nacini upotrebe podataka,

• za svaki tip entiteta, atribute koje funkcija prilikom svog izvodjenja koristi i• za svaki atribut, nacine njegove upotrebe, koji mogu biti: selekcija, zadavanje, modifi-

kacija, ukidanje, arhiviranje i ostali nacini upotrebe vrednosti atributa.Na ovaj nacin, projektant implicitno definise matrice "elementarne funkcije / tipovi entiteta"i "elementarne funkcije / atributi".

Za definisanje organizacione strukture sistema se moze upotrebiti dijagramski ori-jentisani alat Process Modeller, ili se to moze uciniti direktnim pristupom recniku podataka,pomocu hijerarhijskog navigatora objekata, odnosno alata ciji je originalni naziv RepositoryObject Navigator. Na slici 13.10 je prikazan izgled ovog alata. Prozor na levoj strani slikereprezentuje hijerarhijski navigator objekata recnika. Ukoliko se za definisanje organi-zacione strukture koristi hijerarhijski navigator objekata, tada se elementi organizacionestrukture definisu kreiranjem pojava tipa objekta pod nazivom Business Units, tj. poslovne,ili organizacione celine. Navodjenjem oznake direktno nadredjene organizacione celine,prilikom kreiranja nove organizacione celine, uspostavlja se hijerarhijska struktura organi-zacionih celina (videti desnu stranu slike 13.10).

Slika 13.2.


Za definisanje prostorne (lokacijske) strukture sistema ne postoji poseban alatdijagramskog tipa. U te svrhe se koristi direktan pristup recniku podataka putem RepositoryObject Navigator-a. Pri tome ce svaki element prostorne strukture predstavljati jednu poja-vu tipa objekta pod nazivom Locations. Prostorna struktura se, takodje, u delovima, ili ucelini, moze hijerarhijski organizovati, tako sto ce se za posmatranu lokaciju navesti oznakanjene direktno nadredjene lokacije.

Koriscenjem alata Matrix Diagramer, postoji mogucnost definisanja razlicitihtipova matrica zavisnosti, od kojih su za fazu snimanja i analize karakteristicne sledece:• matrica "organizacione jedinice / funkcije", kojom se iskazuju informacije o tome koji

procesi (funkcije) se obavljaju u posmatranim organizacionim celinama,• matrica "organizacione jedinice / lokacije", kojom se iskazuje prostorni raspored organi-

zacionih celina realnog sistema,• matrica "elementarne funkcije / tipovi entiteta", kojom se iskazuje nacin upotrebe pojava

odgovarajucih tipova entiteta u posmatranim procesima i• matrica "elementarne funkcije / atributi", kojom se iskazuje nacin upotrebe pojedinacnih

vrednosti atributa u posmatranim procesima.

13.5.3. Modeliranje dijagrama procesa

Dijagrami procesa sluze za vizuelni prikaz scenarija odvijanja procesa u realnomsistemu. Oblikuju se putem alata pod nazivom Process Modeller. Izgled korisnickog in-terfejsa ovog alata, zajedno s izvodom iz jednog dijagrama je prikazan na slici 13.11.

Process Modeller je zasnovan na sledecim konceptima: organizaciona jedinica,proces (funkcija), depozit, tok, okidac (triger) i ciljni rezultat*). Organizacija dijagramaprocesa prati funkcionalnu dekompoziciju informacionog sistema. Svaki dijagram se for-mira za jedan proces u hijerarhiji dekompozicije. Prilikom otvaranja novog dijagrama, birase proces za koji se dijagram crta. On se naziva kontekstni proces. Procesi, koji se na sa-mom dijagramu prikazuju, su prevashodno direktno podredjeni procesi kontekstnomprocesu, ali to moze biti i bilo koji drugi proces iz funkcionalne dekompozicije. Procesi nadijagramu se, u terminologiji ovog alata, nazivaju koracima, ili aktivnostima*). Predefini-sana klasifikacija, omogucava da se aktivnost deklarise kao: aktivnost obuhvata podataka,tacka odluke, aktivnost izvestavanja, interna aktivnost, eksterna aktivnost, ili da se vrstaaktivnosti posebno ne specificira. Slicno, svaki depozit se moze deklarisati kao skladistematerijala, depozit podataka, ili ostati nespecificiran, dok tok moze biti oznacen kao tokpodataka, tok materijala, privremeni tok, ili ostati nespecificiran.

Alat omogucava oblikovanje i prikaz organizacione strukture realnog sistema, pricemu se celokupna hijerarhija organizacionih jedinica, ili neki njen deo, prikazuje nakrajnjem levom delu dijagrama (videti sliku 13.11). Svaka organizaciona jedinica, prika-zana na dijagramu, ima svoju oblast ingerencije u pogledu izvodjenja pojedinih aktivnosti.

*) Na engleskom: Outcome.*) Na engleskom: Process Step.


Oblast ingerencije je na dijagramu prikazana u obliku horizontalne trake*), koja se proteze uvisini odgovarajuce organizacione jedinice. To znaci da je za sve procese u datoj oblasti,zaduzena naznacena organizaciona jedinica. Na taj nacin se, putem dijagrama procesa, defi-nise i matrica "organizacione jedinice / procesi".

Slika 13.1.

Za svaku aktivnost, depozit (osim depozita podataka) i tok (osim toka podataka)mogu se:• definisati pripremno, radno i zavrsno vreme trajanja aktivnosti i toka, ili pristupa depo-

zitu, kao i vreme kontrole kvaliteta,• izracunati ukupno vreme trajanja aktivnosti i toka, ili pristupa depozitu,• odrediti cena upotrebe materijalnih, ljudskih, ukupnih i ostalih resursa, pri izvodjenju

aktivnosti i toka, ili pristupu depozitu,• notirati potrebni resursi za izvodjenje aktivnosti i toka, ili pristup depozitu i• definisati multimedijalni elementi prezentacije na dijagramu.

Saglasno ovim podacima, omoguceno je automatsko izracunavanje vremena po-cetka i zavrsetka svake aktivnosti i odredjivanje kriticnog (vremenski najduzeg) puta nadijagramu. Omogucena je, takodje, i multimedijalna animacija dijagrama, odnosno vizuelnasimulacija izvodjenja aktivnosti dijagrama.

*) Na engleskom: Swim Lane.


Potrebno je naglasiti da ovaj alat omogucava zadavanje citavog niza podataka, presvega o organizacionim jedinicama i aktivnostima, ali i o drugim ciniocima, koji su rele-vantni i za dokumentaciju sistema kvaliteta generalno, a ne samo za dokumentaciju infor-macionog sistema.

13.5.4. Modeliranje dijagrama toka podataka

Dijagrami toka podataka se oblikuju putem alata Dataflow Diagramer. Izgled ko-risnickog interfejsa ovog alata, zajedno s izvodom iz jednog dijagrama je prikazan na slici13.12. Dataflow Diagramer je zasnovan na uobicajenim konceptima tehnike dijagrama tokapodataka: proces (funkcija), depozit podataka, spoljni entitet i tok podataka.

Slika 13.1.

Organizacija dijagrama toka podataka prati funkcionalnu dekompoziciju informa-cionog sistema. Procesi se automatski numerisu, saglasno uvedenoj hijerarhiji. Prilikomotvaranja svakog novog dijagrama, mora se odrediti proces za koji se dijagram toka poda-taka crta. Taj proces se u terminologiji Designer-a 2000 naziva kontekstni proces*) (na slici13.12. to je proces numerisan kao 1.1). U okviru tog procesa, na dijagramu se mogu prika-zati samo njemu direktno podredjeni procesi u hijerarhiji. Dataflow Diagramer omogucava

*) Na engleskom: Frame Process.


preuzimanje iz recnika podataka procesa koji su vec kreirani putem drugih alata, ili direktnokreiranje novih procesa, koji ce, potom, biti vidljivi u hijerarhijskoj dekompoziciji funkcija.

Prilikom otvaranja novog dijagrama na sledecem nivou dekompozicije, jedan odpodredjenih procesa se bira za kontekstni proces novog dijagrama, a alat ce automatski, uztaj proces, preneti na novi dijagram i sve s njim povezane spoljne entitete, depozite poda-taka i odgovarajuce tokove podataka. Treba napomenuti da postoje posebne tehnike zaobezbedjenje balansiranosti tokova podataka po nivoima dekompozicije.*)

Jedno od bitnih logickih ogranicenja prilikom crtanja dijagrama toka podatakajeste da svaki tok podataka (kao i spoljni entitet i depozit podataka) mora imati svoj naziv.Pored toga, svaki tok, makar s jedne strane, mora biti povezan s nekim procesom. Pri tome,postoji mogucnost direktnog povezivanja dva procesa tokom podataka.

Designer 2000 obezbedjuje mogucnost da se definise "sadrzaj" svakog toka poda-taka i svakog depozita podataka, tako sto ce se navesti tipovi entiteta i njihovi atributi kojeposmatrani tok, ili depozit podataka sadrzi. Za svaki spoljni entitet, ako je to potrebno,moze se definisati organizaciona celina kojoj pripada, ili tip entiteta na koji se odnosi. Kao ikod procesa, uz svaki tok podataka, spoljni entitet ili depozit podataka, mogu se, slobodnimtekstom, dodati sve potrebne napomene ili opisi.

13.5.5. Modeliranje konceptualne seme baze podataka

Za konceptualno modeliranje seme baze podataka se koristi tehnika dijagramatipova entiteta i poveznika (ER dijagrama) i alat Entity Relationship Diagramer, koji ovutehniku podrzava. Izgled korisnickog interfejsa ovog alata, zajedno s izvodom iz jednogdijagrama je prikazan na slici 13.13.

Opsti koncepti tehnike ER dijagrama, koji su neposredno, ili posredno podrzaniovim alatom su: regularni i slabi tip entiteta, tip poveznika, kardinaliteti tipa poveznika,domen, atribut tipa entiteta, kljuc tipa entiteta, gerund, IS-A hijerarhija i kategorizacija(koja se ovde predstavlja ekskluzivnim tipom poveznika*)).

ER dijagrami se oblikuju tako sto se novi tipovi entiteta i tipovi poveznika direkt-no kreiraju u okviru izabranog aplikacionog sistema, dok se prethodno kreirani tipovi en-titeta i poveznika, po potrebi, preuzimaju iz recnika, bilo da pripadaju izabranom, ili nekomdrugom aplikacionom sistemu. Na taj nacin, obezbedjuje se mehanizam za oblikovanjejedinstvene konceptualne seme baze podataka informacionog sistema.

*) Rec je o ukljucivanju u dijagram na visem nivou dekompozicije "resolved" tokova

podataka (prikazanih isprekidanim linijama), koji nastaju generalizacijom jednog ili visetokova podataka na prvom nizem nivou dekompozicije.

*) Na engleskom: exclusive arc.


Slika 13.1.

Notacija za prikaz ER dijagrama u Designer-u 2000 se razlikuje od notacije, pri-menjene u prethodnim delovima ove knjige i u knjizi [ML]. Najbitnija razlika je u tome dase tipovi poveznika ovde ne prikazuju simbolom za romb i linijama, vec samo pomocujedne linije koja povezuje dva tipa entiteta, a moze biti puna, isprekidana, ili delimicno is-prekidana i na sebi moze imati dodatne oznake, u zavisnosti od parametara tipa poveznika.Parametri tipa poveznika su:• maksimalni kardinaliteti (ili samo kardinaliteti) polaznog i zavrsnog kraja tipa poveznika,• minimalni kardinaliteti (ili obaveznost/opcionalnost) polaznog i zavrsnog kraja tipa

poveznika,• vrsta tipa poveznika (da li je identifikacioni, ili regularan) na polaznom i zavrsnom kraju

tipa poveznika i• dozvola/zabrana prevezivanja ("transferabilnosti") pojave povezanog tipa entiteta s jedne

na drugu pojavu povezujuceg tipa entiteta, na polaznom i zavrsnom kraju tipa poveznika.U cilju objasnjenja logike notacije, koju za prikaz ER dijagrama koristi Designer

2000, na slikama 13.14 i 13.15 su prikazani primeri ER dijagrama, pri cemu su korisceneobe notacije, paralelno. Na slici 13.14, strelicama su povezani odgovarajuci prikazi kardi-naliteta u jednoj i drugoj notaciji. Moze se zapaziti da, usled razlike u notaciji za tipovepoveznika, n-arni tipovi poveznika, gde je n > 2, gerundi, i u najvecem broju situacija bi-narni tipovi poveznika s maksimalnim kardinalitetima M : N, u Designer-u 2000 se, posred-no, prikazuju putem simbola za tip entiteta.


(1, 1) (0, N )

MBR PRZIME ORM BRBNRM

RADNO_MESTO

# ORM* NRM* BRB

AngažujeRadi_na

• ER dijagram koji prikazuje tip poveznika s maksimalnim kardinalitetima N : 1:

• Ekvivalentna ORACLE / Designer 2000 notacija:

Radnik Rasporeðen Radno_Mesto

RADNIK

# MBR* IME* PRZ

Slika 13.2.

(0, M ) (0, N )

BRCPRZIME OZP NARNAZ

• ER dijagram koji prikazuje tip poveznika s maksimalnim kardinalitetima N : M:

• Ekvivalentna ORACLE / Designer 2000 notacija:

PROJEKAT

# OZP* NAZ* NAR

Angažovan Angažuje

Za Za

Radnik Radi_Na Projekat

MBR

RADI_NA

* BRC

RADNIK

# MBR* IME* PRZ

Slika 13.3.

Uz nazive atributa i domena, u Designer-u 2000 se zadaje citav niz podataka, kojije vazan kako sa stanovista izrade konceptualne seme baze podataka, tako i sa stanovistaimplementacionog projektovanja seme baze podataka i aplikacija informacionog sistema. Uneke od tih podataka spadaju: specifikacija obaveznosti unosa vrednosti, kratak opis se-mantike, tip podatka, maksimalna i srednja duzina unetih podataka, opsezi ili liste dozvolje-


nih vrednosti, itd. Pored toga, za domene je podrzan i koncept nasledjivanja, po kojem do-men moze preuzeti osobine nekog drugog, njemu nadredjenog domena.

Svakom tipu entiteta i atributu se, u cilju prezentacije dodatnih informacija, mozepridruziti tekstualni opis, koji se, kasnije, automatski preuzima prilikom generisanja ekranas pomocnim informacijama u programima aplikacija.

13.5.6. Modeliranje implementacione i interne seme baze po-dataka

Implementaciona sema baze podataka u Designer-u 2000 se oblikuje pomocu rela-cionog modela podataka, koriscenjem alata Design Editor / Server Model. Alat DesignEditor / DB Admin, ili alat za direktan pristup recniku Repository Object Navigator, koristise za formiranje interne seme baze podataka. Implementaciono projektovanje seme bazepodataka moze zapoceti prevodjenjem ER dijagrama konceptualne seme baze podataka urelacioni model podataka. Za ovo prevodjenje se koristi alat pod nazivom Database DesignTransformer, koji na osnovu konceptualne seme baze podataka, opisane u recniku, generiseprvu verziju relacione seme baze podataka, ciji opis ce se takodje nalaziti u recniku Desig-ner-a 2000. Tako izgenerisana relaciona sema se nadalje doradjuje putem Design Editor-a.Postoji, naravno, i mogucnost direktnog oblikovanja implementacione seme baze podataka,bez prethodnog modeliranja ER dijagrama i njihovog prevodjenja u relacioni model. Izgledkorisnickog interfejsa za Design Editor / Server Model, zajedno s izvodom iz jednogdijagrama relacione seme je prikazan na slici 13.16.

Polazni koncept u okviru alata Design Editor / Server Model je definicija tabele, ilikrace tabela*). Tabela, u ovom slucaju, reprezentuje pojam seme relacije. Svaka tabela, kaosema relacije, poseduje svoj skup obelezja i skup ogranicenja.

Obelezja se, u ovoj terminologiji, nazivaju kolonama. Za svaku kolonu se, porednaziva, definise, ili preuzima iz konceptualnog modela, citav niz implementacionih karakte-ristika. Te karakteristike se mogu svrstati u tri kategorije:• definicioni podaci kolone (domen, tip podatka, srednja i maksimalna duzina podatka,

dozvola/zabrana nula vrednosti, inicijalna vrednost, specifikacija generatora sekvencevrednosti, itd),

• prezentacioni podaci kolone (nacin, duzina i format prikaza kolone, naslov kolone,kratka poruka o semantici kolone, itd),

• validacioni podaci kolone (opseg ili lista dozvoljenih vrednosti, poruka u slucajunarusavanja validacionog ogranicenja),

• specifikacija nacina izracunavanja, ili dodeljivanja vrednosti kolone,• informacije o izvrsenoj denormalizaciji i• dodatni podaci kolone, u koje se mogu ubrojati razlicite vrste tekstualnih polja. Jedno od

bitnih tekstualnih polja jeste polje za definisanje pomocnih informacija o koloni, na os-novu kojih ce u programima automatski biti izgenerisana opcija "pomoc".

*) Na engleskom: Relational Table Definition.


Slika 13.1.

Karakteristike kolona se koriste pri automatizovanom generisanju SQL opisa seme bazepodataka i pri generisanju programskih specifikacija modula, koji u svojoj podsemi sadrzeposmatrane seme relacija (tabele) i obelezja (kolone).

Sva ogranicenja relacione seme baze podataka se, u ovom alatu, tehnicki vezuju zaodgovarajucu tabelu, bez obzira da li je rec o jednorelacionom ili medjurelacionom ograni-cenju. Za svaku tabelu je moguce definisati sledece tipove ogranicenja:• ogranicenje primarnog kljuca, pri cemu se navodi niz obelezja koja primarni kljuc sadrze

i informacija da li je zabranjena ili dozvoljena modifikacija kljuca,• ogranicenje ekvivalentnog kljuca, pri cemu se navodi niz obelezja koja ekvivalentni kljuc

sadrzi i informacija da li je zabranjena ili dozvoljena modifikacija kljuca,• ogranicenje jedinstvene vrednosti, pri cemu se navodi niz obelezja za koja se zahteva da,

ako su sve vrednosti datih obelezja razlicite od nula vrednosti, tada kombinacija vredno-sti bude jedinstvena,

• ogranicenje stranog kljuca, pri cemu se navodi:• niz obelezja koja strani kljuc sadrzi,• naziv referencirane tabele u kojoj se nalazi odgovarajuci primarni kljuc,• za svako obelezje stranog kljuca, njemu korespondentno obelezje primarnog kljuca

referencirane tabele i• aktivnost, koja se sprovodi u slucaju narusavanja referencijalnog integriteta pri bri-

sanju, ili modifikaciji podataka i


• ogranicenje torke, pri cemu se navodi ili logicki izraz koji mora biti zadovoljen, ili imelogicke funkcije koja ce sprovesti kontrolu na dozvoljene vrednosti torke tabele.

Za svako ogranicenje se, pored toga, navodi poruka koja ce se prikazati u slucaju njegovognarusavanja i mesto realizacije ogranicenja, koje moze biti: "na serveru", "na klijentu" (stoznaci u okviru programa aplikacije), ili "i na serveru i na klijentu".

Alat Design Editor / DB Admin omogucava projektovanje interne seme baze po-dataka, odnosno definisanje elemenata fizicke organizacije seme baze podataka. U tomsmislu se, pomocu ovog alata, za svaku tabelu, u okviru jedne baze podataka i jednog ko-risnickog imena, formira implementacija tabele*). Na nivou implementacije tabele se mogudefinisati odredjeni parametri njene fizicke organizacije i prava pristupa za odredjene koris-nike, ili grupe korisnika. U bitne karakteristike fizicke organizacije se ubraja mogucnostkreiranja indeksa nad samom tabelom.

Koncept trigera (okidaca) baze podataka je direktno podredjen konceptu tabele,sto znaci da se svaki triger definise u okviru neke tabele. Proceduralni deo (telo) trigera seopisuje putem proceduralno orijentisanog jezika PL/SQL, koristeci alat pod nazivom LogicEditor.

Nad tabelom se, takodje, mogu zadati ili automatski preuzeti razlicite pomocneinformacije, prezentovane u slobodnom formatu. Na osnovu tih informacija, moze seobezbediti automatsko generisanje opcije "pomoc" u buducim programima aplikacija.Pored toga, moze se obezbediti i automatsko vodjenje dnevnika promena*) nad tabelom,realizovanog putem posebne tabele promena.

Osim tabela, putem alata Design Editor / Server Model i opcije PL/SQL Definition,mogu se definisati procedure, funkcije i paketi procedura i funkcija, a mogu se deklarisati ikursori (kursorska podrucja). Svi nabrojani objekti se specificiraju upotrebom proceduralnoorijentisanog jezika PL/SQL, pomocu Logic Editor-a, a namenjeni su za implementiranje uokviru recnika baze podataka i izvrsavanje od strane servera baze podataka. Vazno je na-glasiti da se kompletan programski kod ovakvih objekata smesta u recnik Designer-a 2000.

Pored navedenih, Design Editor poseduje koncept pogleda i koncept replikacioneslike*). Koncept pogleda odgovara pojmu SQL pogleda, dok se koncept replikacione slikekoristi za definisanje replikacione seme distribuirane baze podataka. Replikaciona slika, pritome, predstavlja replicirani deo tabele na drugom ORACLE serveru.

Na osnovu implementacione, odnosno interne seme baze podataka se automatskigenerise ORACLE/SQL, ili Ansi/SQL opis seme baze podataka, koju treba implementiratina odgovarajucem serveru baze podataka. Implementaciona sema sluzi, takodje, kao osnovza modeliranje programske specifikacije modula i samo generisanje programskih modula.

*) Na engleskom: Table Implementation.*) Na engleskom: journaling.*) Na engleskom: snapshot.


13.5.7. Modeliranje programske specifikacije modula

Programska specifikacija modula za interaktivan rad s bazom podataka, kreiranjeizvestaja, grafikonski prikaz podataka, ili biblioteckog modula se oblikuje putem alata De-sign Editor / Modules. Putem istog alata se formira struktura menija aplikacije iobezbedjuje medjusobno povezivanje programskih modula, s mogucnoscu prenosapodataka izmedju modula putem parametara.

Koristeci ovaj alat, projektant za svaki programski modul prvo definise podsemu(videti sliku 13.17), koristeci se prethodno oblikovanom implementacionom semom bazepodataka. Podsemu cini skup izabranih sema relacija*) iz seme baze podataka, zajedno savezama koje oznacavaju prostiranje kljuceva. Za svaku semu relacije iz podseme seodredjuje potreban skup obelezja*). Za svako obelezje podseme se, u okviru modula, pravijedno vezano polje.*)

Struktura ekranske forme buduceg programskog modula zavisi od medjusobnogodnosa sema relacija podseme, definisanog njihovim fizickim pozicioniranjem na dijag-ramu. Svaka sema relacije u podsemi moze imati ulogu:• bazne seme, ukoliko je namenjena za manipulaciju podacima, ili• liste izbora, ukoliko je namenjena za prikaz liste izbora dozvoljenih vrednosti i dodatnih

podataka na samoj ekranskoj formi.Seme relacija podseme se grupisu u komponente programskog modula. Jedna

komponenta programskog modula treba da predstavlja jednu logicku celinu za prezentacijupodataka i moze sadrzati vise sema relacija podseme. Na primer, ekranski modul koji prika-zuje podatke u formi "zaglavlje/stavke" treba, u principu, da ima dve komponente - jednu zaprikaz podataka zaglavlja, a drugu za prikaz podataka koji odgovaraju stavkama.

Komponenta, a samim tim i pripadajuca bazna sema relacije, koja se na dijagramunalazi iznad neke druge komponente, tj. odgovarajuce bazne seme relacije, predstavljacezaglavlje buduce ekranske forme, dok ce podredjena komponenta reprezentovati stavke da-tog zaglavlja. Sema relacije, koja se nalazi desno od neke druge seme relacije, predstavljalistu izbora za datu semu relacije (videti sliku 13.17). Treba napomenuti da alat DesignEditor / Modules dopusta formiranje znatno slozenijih struktura, nego sto je strukturadijagrama, prikazana na slici 13.17.

Definisanje proceduralne logike programskog modula pre svega podrazumevaizbor mogucih standardnih operacija azuriranja (unos, modifikacija, brisanje) ilipostavljanja upita (selekcija podataka), koje putem programskog modula treba dozvoliti*)

nad delom baze podataka, odnosno baznim semama relacija podseme. Pri tome, u osnovneoperacije nad komponentom programskog modula ubrajaju se: selekcija, dodavanje, modi-

*) U terminologiji Designer-a 2000, sema relacije u podsemi se na engleskom naziva Table

Usage.*) U terminologiji Designer-a 2000, obelezje u semi relacije iz podseme se na engleskom

naziva Column Usage.*) U terminologiji Designer-a 2000, vezano polje se na engleskom naziva Bound Item.*) Pri tome, kod modula za kreiranje izvestaja jedina osnovna operacija je selekcija.


fikacija i brisanje, dok su osnovne operacije nad vrednostima obelezja, izmedju ostalih, sle-dece: prikaz, selekcija, zadavanje i modifikacija vrednosti obelezja. Za svako obelezje se,pored navedenih osnovnih operacija, moze zadati, ili preuzeti iz implementacionog opisaseme baze podataka, niz drugih podataka, koji se odnose na nacin prikaza i manipulacijevrednostima obelezja na ekranskoj ili stampanoj formi, kao sto su: obaveznost unosa poda-taka, dimenzije i format prikaza, nacin pozicioniranja vrednosti obelezja, propratni tekst iuputstvo, itd.

Slika 13.1.

Dalje mogucnosti, kada je u pitanju opisivanje proceduralne logike programskogmodula, odnose se na to da programer ima mogucnosti za definisanje specijalnih (nestan-dardnih) postupaka obrade podataka putem posebnih procedura i funkcija. Takve procedurei funkcije mogu biti definisane u okviru samog programskog modula i tada su one lokalnogkaraktera, a mogu biti definisane u okviru posebnog, biblioteckog modula, namenjenog zaskladistenje procedura, funkcija i paketa, smestenih na klijentu. Bibliotecki moduli (ilikrace biblioteke) se, zatim, po potrebi mogu referencirati od strane drugih programskihmodula. Treca mogucnost je da se, u okviru programskih modula, mogu referencirati proce-dure i funkcije, namenjene za implementiranje na serveru baze podataka, koje su definisaneputem alata Design Editor / Server Model i opcije PL/SQL Definition.


Programeru je data mogucnost da definise dogadjaje (odnosno, drugim recima, lo-kalne trigere) korisnickog interfejsa, u okviru ekranskog modula. Takav dogadjaj moze bitidefinisan na nivou samog ekranskog modula, komponente modula ili vezanog polja. Zadogadjaj se vezuje proceduralna logika koju treba izvrsiti i, po pravilu, ona se svodi napoziv prethodno definisanih procedura i funkcija. Osim toga, moguce je kreirati i nevezanapolja*) i komandna polja*). Nevezano polje nije u direktnoj vezi ni s jednim obelezjemseme baze podataka, vec sluzi za prikaz agregiranih (sumarnih) vrednosti, ili vrednosti kojese izracunavaju putem prethodno definisane funkcije. Komandno polje reprezentujedugme*) - element korisnickog interfejsa, cijim aktiviranjem se izvrsava specificirana pro-cedura.

Alat Design Editor / Modules omogucava dijagramski nacin oblikovanja struktureprogramskih modula, odnosno vizuelni prikaz veza izmedju specifikacija modula kojereprezentuju poziv jednog od strane drugog modula, sto je, takodje, ilustrovano na slici13.17. Pored toga, moguce je i vizuelno oblikovanje izgleda ekranske forme modula, de-finisanjem prozora i stranica za prikaz podataka.

Bitno je naglasiti da se specifikacije programskih modula mogu automatski gene-risati koristeci alat Application Design Transformer, na osnovu prethodno izradjenih dija-grama tipova entiteta i poveznika, matrica koje povezuju: funkcije s tipovima entiteta ifunkcije s atributima tipova entiteta, kao i tokova podataka koji mogu nositi informacije oulaznim i izlaznim parametrima programskog modula.

Na kraju, saglasno cinjenicama da Designer 2000:• sav proceduralni programski kod smesta u svoj recnik,• sadrzi citav niz koncepata, putem kojih se do najsitnijih detalja mogu oblikovati

aplikacije informacionog sistema i• omogucava prilagodjenje sopstvenih alata potrebama korisnika,moze se zakljuciti da ovaj CASE proizvod obezbedjuje generisanje takvih aplikacija koje upotpunosti, ili gotovo u potpunosti zadovoljavaju predvidjene standarde i mogu biti prime-njene kao konacan programski proizvod.

U okviru priloga P6, prezentovani su rezultati projektovanja i implementacije semebaze podataka studije slucaja "Komercijalna funkcija", uvedene u okviru glava 11 i 12.Prezentovan je, takodje, i postupak realizacije transakcionog programa za formiranje nalogaza otpremu, koji pripada istoj studiji slucaja. Projektovanje i implementacija su obavljeni uzpomoc CASE proizvoda Designer 2000 V.2.1, tako da se citalac, u cilju sticanja potpunijeslike o mogucnostima ovog CASE proizvoda, upucuje i na prilog P6.

*) Na engleskom: Unbound Item.*) Na engleskom: Action Item.*) Na engleskom: Button.


13.6. Prikaz proizvoda IIS*CASE

Programski proizvod pod nazivom IIS*CASE predstavlja laboratorijski, prakticnoupotrebljiv CASE proizvod, koji se duzi niz godina razvija i koristi na Institutu za industrij-ske sisteme, Fakulteta tehnickih nauka u Novom Sadu. IIS*CASE je osmisljen tako dapripada klasi integrisanih CASE proizvoda. Namenjen je za podrsku jednog dela faze sni-manja i analize, kao i faza projektovanja i programiranja u zivotnom ciklusu informacionogsistema. Razlozi da principi i ideje, na kojima je ovaj CASE proizvod zasnovan, buduprezentovane u knjizi, povezani su s cinjenicom da je rec o originalnom pristupu i da je upitanju jedan od domacih proizvoda te vrste, na cijem razvoju su se poslednjih godinaautori knjige intenzivno angazovali. U ovom poglavlju ce biti predstavljeni koncepti koji suvec u potpunosti, ili delom, implementirani u neku od postojecih verzija IIS*CASE, kao ikoncepti za koje ce implementacija tek uslediti. Teoretske osnove tih koncepata su date uprethodnim delovima ove knjige.

IIS*CASE je namenjen za:• konceptualno modeliranje seme baze podataka,• automatizovano projektovanje seme relacione baze podataka u trecoj normalnoj formi i• generisanje prototipova aplikacija.

IIS*CASE ima svoj recnik podataka, a osmisljen je tako da funkcionise kao klijentaplikacija, pri cemu se recnik podataka realizuje na serveru, uz pomoc nekog od postojecihrelacionih sistema za upravljanje bazama podataka. Komunikacija klijent aplikacije s recni-kom podataka se obavlja putem ODBC protokola, tako da upotreba IIS*CASE-a nijeogranicena na bilo koji konkretan sistem za upravljanje bazama podataka.

Jedan od vaznih motiva razvoja IIS*CASE je bio prevazilazenje problema defini-sanja ogranicenja baze podataka. Osnovna ideja je bila da projektant treba samo pazljivo daspecificira pravila koriscenja podataka u realnom sistemu. Izvodjenje zakljucaka o postoja-nju ogranicenja treba da bude zadatak IIS*CASE-a. Njegov je zadatak i da, uz neophodnuinterakciju sa projektantom, automatski generise semu baze podataka. Postupak definisanjaogranicenja je u IIS*CASE resen uvodjenjem koncepta tipa forme. Taj koncept je nastaogeneralizacijom i uvodjenjem odredjenih pravila za strukturiranje ekranskih i stampanihformi, putem kojih korisnik komunicira s informacionim sistemom.

IIS*CASE, izmedju ostalih, sadrzi sledece alate:• Osnovni koncepti, za definisanje domena i obelezja,• Editor tipova formi, za definisanje tipova formi, odnosno konceptualno modeliranje

seme baze podataka,• Normalizator, za generisanje podseme relacione baze podataka,• Integrator, za integraciju podsema u jedinstvenu semu relacione baze podataka i• Skup generatora, za generisanje implementacionog opisa seme relacione baze podataka i

prototipova aplikacija.Koncepciji svakog od navedenih alata je, u narednom tekstu, posvecena po jedna tacka.


13.6.1. Zadavanje domena i obelezja putem IIS*CASE

Neka ogranicenja buduce seme baze podataka slede iz specifikacije domena iobelezja, kao primitivnih koncepata IIS*CASE-a. U ovom delu ce biti opisan nacinzadavanja domena i obelezja, odnosno bice prikazani tipovi ogranicenja koji proizilaze izspecifikacije domena i obelezja. Za zadavanje domena i obelezja koristi se alat Osnovnikoncepti.

13.6.1.1. Specifikacija domena

Svakom obelezju iz univerzalnog skupa obelezja se pridruzuje tacno jedan domen,kojim se zadaje skup mogucih vrednosti. Skup mogucih vrednosti koji sacinjavaju domen sezadaje putem koncepata:• Tip - tip podatka,• Duzina - duzina tipa podatka,• RegIzr - regularni izraz, kojim se specificiraju dozvoljene (ili nedozvoljene) vrednosti

nad datim tipom podataka i• Dozvola - specifikacija da li RegIzr definise dozvoljene, ili nedozvoljene vrednosti do-

mena (dom(Dozvola) = {D, N }).

Slika 13.1.


Koncepti Tip, Duzina, RegIzr i Dozvola predstavljaju ogranicenja domena. Specifikacijadomena se, prema tome, posmatra kao imenovana cetvorka:

Domen(Tip, Duzina, RegIzr, Dozvola).

Na slici 13.18 je prikazan deo ekranske forme proizvoda IIS*CASE za zadavanjedomena, zajedno s prozorom za prikaz hijerarhije objekata.

Primer 13.1. Specifikacija domena Ocena moze imati sledeci oblik:

Ocena(Number, 2, [5..10], D),

cime se iskazuje cinjenica da se za domen Ocena koriste samo celi brojevi, u intervalu doz-voljenih vrednosti od 5 do 10. ÿ

13.6.1.2. Specifikacija obelezja

Filozofija primene proizvoda IIS*CASE je bazirana na pretpostavci o postojanjuseme univerzalne relacije. Saglasno tome, obelezja iz univerzalnog skupa se definisu neza-visno od toga kojoj ce semi relacije kasnije pripadati.

Obelezje nasledjuje ogranicenja na skup dozvoljenih vrednosti, koja su zadata do-menom, koji je tom obelezju pridruzen. Pored toga, iz specifikacije obelezja se mogu iz-vesti dodatna ogranicenja. Specifikacija obelezja se moze posmatrati kao imenovana sestor-ka:

Obelezje(Domen, Pripad_bp, Zavis, ObPreim, F_izv, F_Valid)

pri cemu je znacenje elemenata sledece:•• Domen : oznaka domena koji se pridruzuje obelezju.•• Pripad_bp: ukazuje na to da li obelezje pripada skupu obelezja buduce seme baze po-

dataka (dom(Pripad_bp) = {D, N }).•• Zavis: ukazuje na to da li je obelezje nezavisno, preimenovano ili izvedeno iz

drugih obelezja, s obzirom na semantiku koju sa sobom nosi (dom(Zavis) ={N, P, I }).

•• ObPreim: zadaje se iskljucivo i obavezno za preimenovana obelezja i predstavljamnemonik obelezja na osnovu kojeg se vrsi preimenovanje. Preimenovanjepredstavlja nacin za izbegavanje pojave homonima u univerzalnom skupuobelezja.

•• F_izv: oznaka rekurzivne funkcije, koja se zadaje iskljucivo i obavezno za izve-dena obelezja. Koristi se za izrazavanje semantickog koncepta izvodjenjauloge datog obelezja iz uloga drugih obelezja. Nakon konacno mnogo(rekurzivnih) primena funkcije F_izv, mora se doci do nezavisnih obelezja.Funkcija F_izv definise, nad univerzalnim skupom obelezja, aciklicki us-mereni graf.

•• F_Valid: oznaka validacione funkcije, koja se zadaje samo za izvedena obelezja.Sluzi za specifikaciju nacina izracunavanja vrednosti obelezja ili za specifi-kaciju ogranicenja na moguce vrednosti izvedenog obelezja, s obzirom na


vrednosti onih obelezja koja ucestvuju u izvodjenju datog obelezja. Funk-cija u alatu IIS*CASE predstavlja poseban koncept, koji se specificira poprecizno utvrdjenoj sintaksi.

Primer 13.2. Specifikacija obelezja sa semantikom "Komponenta u sastavniciproizvoda" ima oblik:

COMPNO(D_Proizid, D, P, PROIZID, Null, Null ),

sto znaci da je rec o obelezju zasnovanom na domenu D_Proizid (sa znacenjem "domen zaidentifikacioni broj proizvoda"), koje treba da bude ukljuceno u skup obelezja seme bazepodataka. Pri tome, COMPNO predstavlja preimenovano obelezje PROIZID, cije je znace-nje "identifikacioni broj proizvoda". ÿ

Na osnovu funkcije ObPreim se mogu identifikovati svi referencijalni integriteti,koji su posledica preimenovanja obelezja, odnosno postojanja netrivijalnih zavisnosti sadr-zavanja u semi univerzalne relacije. Funkcije F_izv i F_Valid predstavljaju osnov za for-malizaciju slozenijih pravila poslovanja buduce seme baze podataka.

13.6.2. Tip forme i konceptualno modeliranje podseme bazepodataka

Tip forme predstavlja polazni koncept proizvoda IIS*CASE. Pomocu tipa formese, implicitno, zadaju ogranicenja na osnovu kojih ce se projektovati podseme relacionebaze podataka, a potom integrisati jedinstvena sema baze podataka informacionog sistema.Saglasno tome, pojam tipa forme pripada konceptualnom modelu podataka. Tipovi formise, u IIS*CASE-u, oblikuju putem alata Editor tipova formi.

13.6.2.1. Koncept tipa forme

Komunikacija izmedju korisnika i automatizovanog informacionog sistema serealizuje putem ekranskih i stampanih formi. Te forme mogu predstavljati izvor ne samo zadefinisanje skupa obelezja seme baze podataka, vec i skupa ogranicenja. Da bi forme preds-tavljale izvor za definisanje skupa ogranicenja, potrebno je uvesti precizna pravila za njiho-vo struktuiranje i pravila za izvodjenje zakljucaka o egzistenziji ogranicenja.

Primer 13.3. Na slici 13.19 je prikazan pojednostavljeni oblik ekranske i stampaneforme pod nazivom FAKTURA. U prazna polja se upisuju podaci. Semantiku tih podatakadefinisu nazivi ispisani ispred, ili iznad polja. Podaci sa ove forme se mogu grupisati u dvelogicke celine. Jednu cine podaci o: samoj fakturi sa zbirom, porezom i ukupnim iznosom,kao i podaci o kupcu. Ta celina se moze nazvati "zaglavljem fakture". Drugu celinu preds-tavljaju podaci o stavkama fakture, pri cemu se u okviru konkretnog zaglavlja moze defini-sati vise od jedne stavke. Ovakve logicke celine podataka se mogu nazvati objektima forme.


Faktura broj: Datum: Po porudžbenici:

Kupac:Naziv:Adresa:

Rbr. Mat. ID Naziv materijala Jed. cena Kolièina Cena

Iznos:Porez:Ukupno:

Ident.br:

Slika 13.1.

U principu, svaki podatak u objektu forme predstavlja jednu vrednost odgovaraju-ceg obelezja buduce seme baze podataka. Nazivi tih obelezja se, u opstem slucaju, mogurazlikovati od naziva polja na formi. ÿ

Generalizacijom sadrzaja ekranskih i stampanih formi dolazi se do pojma tipaforme. Tip forme je struktura stabla cije cvorove predstavljaju tipovi objekata. Neka jeW(F ) skup obelezja tipa forme sa nazivom F, pri cemu svakom obelezju iz W(F ) odgovarajedno polje za unos, ili prikaz podataka na ekranskoj formi. Svaki tip objekta tipa forme Fje imenovana dvojka N(Q, K), gde je N naziv tipa objekta, Q = {A1,..., Ak} ⊆ W(F ), a Kskup kljuceva tipa objekta.

Primer 13.4. Na slici 13.20 je prikazana geometrijska reprezentacija tipa forme,dobijenog generalizacijom forme sa slike 13.19. Tipovi objekata su prikazani pravougao-nicima, a obelezja kljuca svakog tipa objekta su podvucena.

FAKTURAZAGLAVLJE FAKTURE

STAVKE FAKTURE

FakIdb, FakDat, PorIdb, PPIdb, PPNaz, PPAdr, Iznos, Porez, Ukupno

StRbr, MatIdb, MatNaz, JedCen, StKol, StIznos

Slika 13.2.


Znacenja obelezja iz skupa W(FAKTURA) su sledeca: FakIdb - identifikacioni brojfakture, FakDat - datum fakturisanja, PorIdb - identifikacioni broj porudzbenice za koju jefaktura vezana, PPIdb - identifikacioni broj poslovnog partnera, PPNaz - naziv poslovnogpartnera, PPAdr - adresa poslovnog partnera, Iznos - iznos fakture, Porez - porez po fakturi,Ukupno - ukupan iznos za placanje po fakturi, StRbr - redni broj stavke, MatIdb - identifi-kacioni broj materijala, MatNaz - naziv materijala, JedCen - jedinicna cena, StKol - kolicinamaterijala na stavci i StIznos - iznos po stavci (StIznos = JedCen ∗ StKol ). �

Uvodjenje pojma tipa forme zahteva da se definise i pojam pojave tipa forme. Po-java tipa forme je struktura stabla, ciji koren sadrzi jednu pojavu tipa objekta u korenustabla tipa forme, a cvorove na svakom nizem nivou hijerarhije cini nula ili vise pojava sva-kog tipa objekta na odgovarajucem nivou hijerarhije stabla tipa forme.

Neka je O = {Ni(Qi, Ki) | i = 1,..., m} skup tipova objekata tipa forme F. Neka jeN1(Q1, K1), Q1 = {A11

,.., A1k}, tip objekta u korenu stabla tipa forme F. Jedna pojava p(N1)

tipa objekta N1(Q1, K1) je funkcija:

p(N1): Q1 → dom(A11) × ... × dom(A1k

),

pri cemu vazi (∀Ai∈Q1)(p(N1)(Ai)∈dom(Ai)).Neka je Ni direktno nadredjeni objekat objekta Nj u stablu tipa forme F, a P(Ni) =

{pl(Ni) | l = 1,..., n} skup pojava tipa objekta Ni(Qi, Ki), na jednoj pojavi tipa forme F. Jednapojava tipa objekta Nj(Qj, Kj), Qj = {Aj1

,.., Ajk}, u okviru jedne pojave pl(Ni)∈P(Ni) tipa

objekta Ni je funkcija:

p(Nj, pl(Ni)): Qj → dom(Aj1) × ... × dom(Ajk

),

pri cemu vazi da (∀Ar∈Qj)(p(Nj, pl(Ni)))(Ar)∈dom(Ar)).Ako se posmatra tip objekta u korenu stabla N1(Q1, K1), tada svaki kljuc iz K1 ima

svojstvo jedinstvene identifikacije bilo koje pojave nad N1, a samim tim i pojave odgovara-juceg tipa forme F. Slicno, za bilo koji podredjeni tip objekta Nj(Qj, Kj) vazi da svaki kljuciz Kj ima svojstvo jedinstvene identifikacije svake pojave nad Nj, ali u okviru tacno jednepojave direktno nadredjenog objekta Ni.

Definicija 13.1. Tip forme je imenovana cetvorka F(O, ϕ, C, AF(x)), nad skupomobelezja W(F ), gde su:

• O = {Ni(Qi, Ki) | i = 1,..., m} - skup tipova objekata, pri cemu je Qi ⊆ W(F ) skup obe-lezja tipa objekta, a Ki = {Xj ⊆ Qi j ∈ {1,..., q}} skup kljuceva tipa objekta.

• ϕ ⊆ O × O je relacija koja nad skupom O definise strukturu stabla. Vazi da je (Ni,Nj)∈ϕ, ako i samo ako na bar jednoj pojavi tipa forme F postoji bar jedna pojava tipaobjekta Ni kojoj je pridruzeno vise od jedne pojave objekta Nj.

• C je skup ogranicenja, odredjen uslovima:

(13.1) Q Wii

m

==

1U ( ),F

(13.2) (∀Ni, Nj ∈ O)(i ≠ j ⇔ Qi ∩ Qj = ∅)


(13.3) (∀Ni∈O)(∀A, B∈W(F ))((A, B∈Ni) ⇔ Ibp(F, A, B)),

gde predikat "Ibp" znaci da je broj pojava obelezja A i B na svim mogucim pojavamatipa forme F uvek isti,

(13.4) (∀Ni, Nj∈O)(((Ni, Nj)∈ϕ ∧ X∈Kj) ⇒ Joo(Ni, Nj, X )),

gde predikat "Joo" oznacava da kljuc X jedinstveno odredjuje pojavu objekta Nj uokviru jedne pojave objekta Ni i da ne postoji pravi podskup od X, sa tom osobinom,

(13.5) (∀X∈K1)(Jof(N1, X ))),

gde predikat "Jof " znaci da kljuc X jedinstveno odredjuje jednu pojavu tipa objekta N1,u korenu stabla tipa forme F, kao i da ne postoji pravi podskup od X, sa tom osobinom.

• AF(x) je predikat sa dom(x) = {u, r}. Putem predikata AF(x) je definisan nacin upotrebetipa forme F. Interpretacija AF(u) znaci da se tip forme F moze koristiti i za azuriranjebaze podataka i za prikazivanje njenog sadrzaja. Tip forme F pripada klasi AF(u), ako cese putem tog tipa forme menjati vrednosti bar jednog obelezja u semi baze podataka. In-terpretacija AF(r) znaci da se dati tip forme moze koristiti jedino za prikazivanje sadrzajabaze podataka, pomocu upita i izvestaja. ÿ

Predikat "Ibp" ukazuje na nacin rasporedjivanja obelezja iz W(F ) po tipovima ob-jekata. Dva obelezja A, B ∈ W(F ) pripadaju istom tipu objekta N(Q, K) ako vazi da je nasvakoj pojavi tipa forme F, broj A vrednosti jednak broju B vrednosti.

Motivacija za definisanje predikata AF(x) je sledeca. Svaki podatak na nekom iz-vestaju se izvodi na osnovu sadrzaja baze podataka. Svi potrebni podaci se moraju uneti ubazu podataka i strukturirati saglasno ogranicenjima u realnom sistemu. Unos podataka sevrsi putem formi za azuriranje. Saglasno tome, putem tipova formi za azuriranje se definisei skup obelezja i skup ogranicenja seme baze podataka, te se putem IIS*CASE, sema bazepodataka i projektuje samo na osnovu tipova formi za azuriranje. To dalje znaci i da semoraju strogo kontrolisati eventualne kolizije u definicijama tipova formi iz klase AF(u).Takve kontrole nisu potrebne kada su u pitanju tipovi formi iz klase AF(r). Skup tipovaformi iz klase za azuriranje ce biti oznacen sa SFu, a skup tipova formi iz klase za upite saSFr.

Unija skupova obelezja svih tipova formi jednog informacionog sistema predstav-lja univerzalni skup obelezja U. Skup obelezja seme baze podataka je UBP ⊆ U. Ne mora sesvako obelezje iz U nalaziti i u UBP. Moguci primer predstavljaju ona obelezja cije sevrednosti izvode na osnovu vrednosti drugih obelezja. Vec je prethodno naglaseno da se zasvako obelezje iz U, u recniku IIS*CASE, specificira da li pripada UBP. Naravno, primarnaobelezja moraju pripadati UBP.

13.6.2.2. Ogranicenja koja se specificiraju putem tipova formi

Na osnovu isprojektovanih tipova formi, u koje su ugradjena ogranicenja, uocena urealnom sistemu, automatski se izvode zakljucci o egzistenciji sledecih tipova ogranicenja:• funkcionalne zavisnosti,• nefunkcionalni odnosi i


• ugradjene zavisnosti spoja.

Identifikacija funkcionalnih zavisnosti

Kljucevi tipova objekata i struktura stabla tipova objekata nose informaciju oskupu funkcionalnih zavisnosti F(F ), definisanog putem tipa forme F. Drugim recima,obelezja svakog tipa objekta su funkcionalno zavisna od unije po jednog od kljuceva tipovaobjekata koji se nalaze na putu od korenskog do datog tipa objekta.

Neka je sa F(W ) oznacen skup svih funkcionalnih zavisnosti nad skupom W. SaX(Ni), gde je Ni ∈ O(F ), bice oznacen skup svih unija po jednog kljuca od korenskog doobjekta Ni. Skup funkcionalnih zavisnosti, definisan tipom forme F, je skup:

(13.1) F(F ) = {X→A∈F(W ) | (∃Nj∈O(F ))(A∈Q(Nj) ∧ X∈X(Nj))}.

Primer 13.5. Na slici 13.21 je prikazan tip forme F. Skup netrivijalnih funkcio-nalnih zavisnosti, odredjen ovim tipom forme je:

F(F ) = {A→B, AC→D, AC→E, AD→C, AD→E}. ÿ

FN1({A, B}, {A})

N2({C, D, E}, {C, D}) N3({F, G}, {FG})

Slika 13.1.

Identifikacija nefunkcionalnih odnosa

Pojam nefunkcionalnog odnosa je u ovoj knjizi vec uveden u okviru glave 2. Kadaje u pitanju neki tip forme F, tada svaki put duzine jedan, ili vece od jedan, koji pocinje ukorenu stabla, a zavrsava se u listu, definise jedan nefunkcionalni odnos. Skup nefunkcio-nalnih odnosa, definisan tipom forme F je skup:

(13.2) NF(F ) = {X→θi | (∃Nj∈LO(F ))(X∈X(Nj)) ∧ |X | > 1},

pri cemu θi∈Θ = {θ1,..., θn} predstavlja neinterpretirano, oznaceno obelezje*), a LO(F ) skuptipova objekata koji predstavljaju listove u strukturi stabla. Ukoliko se, putem dva razlicitatipa forme definise isti nefunkcionalni odnos, onda ce desne strane tog nefunkcionalnogodnosa biti razlicito oznacena neinterpretirana obelezja.

*) Pojam neinterpretiranog oznacenog obelezja je uveden u glavi 2.


Primer 13.6. Skup nefunkcionalnih odnosa, iskazan tipom forme F sa slike 13.21je NF(F ) = {AC→θ1, AD→θ2, AFG→θ3}. ÿ

Identifikacija ugradjenih zavisnosti spoja

Odgovarajuca struktura tipa forme nosi informaciju o ugradjenoj zavisnosti spoja,koja vazi u realnom sistemu. Insistira se na pojmu "ugradjena" jer se putem tipa forme iska-zuju odnosi izmedju podataka samo jednog dela realnog sistema.

Neka je dat skup listova strukture stabla tipa forme:

LO(F ) = {N1,..., Nk} ⊆ O(F ).

Tipom forme F je izrazena zavisnost spoja:

(13.3) J(F ) = ><(X1,..., Xk),

takva da se za svaki Ni∈LO(F ), i∈{1,..., k}, bira tacno jedan Xi∈X(Ni).

Primer 13.7. Ugradjena zavisnost spoja, iskazana tipom forme F sa slike 13.21 jeJ1(F ) = ><(AC, AFG), sto je, s obzirom na skup funkcionalnih zavisnosti F(F ), ekviva-lentno zavisnosti spoja J2(F ) = ><(AD, AFG). ÿ

13.6.2.3. Koncepcija upotrebe editora tipova formi

Aktivnost oblikovanja tipova formi zapocinje izborom aplikacionog sistema, ukojem ce se raditi. Aplikacioni sistem predstavlja jednu celinu (podsistem) buduceg infor-macionog sistema. Informacioni sistem je, pri tome, predstavljen pomocu hijerarhijskestrukture aplikacionih sistema. Prava pristupa korisnika IIS*CASE-a se definisu na nivouaplikacionih sistema.

U okviru jednog aplikacionog sistema, korisnik IIS*CASE-a je u mogucnosti daoblikuje nove, ili modifikuje i brise postojece tipove formi. Novi tip forme se moze kreiratiispocetka, ili preuzimanjem ("kopiranjem") drugog, postojeceg tipa forme koji pripada is-tom, ili nekom drugom aplikacionom sistemu. Pored toga, korisnik moze preuzeti ("refe-rencirati") u svoj aplikacioni sistem bilo koji tip forme, koji je kreiran u okviru nekog dru-gog aplikacionog sistema, bez prava da taj tip forme modifikuje, ili brise.

Tipovi formi se ukljucuju u hijerarhijski organizovane strukture, koje predstavljajuaplikacije informacionog sistema. Da bi se ovakva struktura aplikacije (tj. struktura menijaaplikacije) mogla kreirati, pored tipova formi za azuriranje i upite, uvodi se poseban tipforme, koji se naziva meni tip forme. Bilo koji tip forme moze biti istovremeno ukljucen ustrukture menija razlicitih aplikacija.


Slika 13.1.

Slika 13.2.


Slika 13.3.

Editor tipova formi ima sledece celine:• Deklarator tipa forme,• Generator izgleda forme,• Editor izgleda forme i• Alat za proveru konzistentnosti.

Deklarator tipa forme se koristi za formalno zadavanje tipa forme. Pomocu njegase zadaju osnovni podaci o tipu forme, tipovi objekata, hijerarhijska struktura tipova obje-kata, atributi i kljucevi tipova objekata. Na slici 13.22 je prikazana ekranska forma za dek-larisanje novog tipa forme, zajedno s prozorom za prikaz hijerarhije svih IIS*CASE ob-jekata. Na slici 13.23. je prikazan izgled ekranske forme za zadavanje osnovnih podataka otipu forme, dok slika 13.24 daje prikaz ekranske forme za zadavanje skupa obelezja i skupakljuceva tipova objekata, hijerarhijske strukture tipova objekata i podataka o nacinu upo-trebe obelezja na tipu forme.

Na osnovu formalne deklaracije tipa forme, automatski se moze izgenerisati izgledekranske/stampane forme, pomocu generatora izgleda forme. Zatim se, pomocu editora iz-gleda forme, on moze modifikovati i prilagoditi potrebama korisnika.

Upotrebom editora izgleda forme, moze doci do formalne neusaglasenosti dekla-racije tipa forme i izgleda forme. Zbog toga se, nakon povratka iz editora izgleda forme,


automatski aktivira alat za proveru konzistentnosti izgleda forme i deklaracije tipa forme,koji, u interakciji s korisnikom, razresava eventualno otkrivene kolizije.

13.6.3. Oblikovanje polaznog skupa ogranicenja i generisanjepodseme relacione baze podataka

Za generisanje podseme relacione baze podataka koristi se IIS*CASE alat Nor-malizator. Podsema relacione baze podataka se generise na osnovu automatski formiranogpolaznog skupa ogranicenja. Ovaj skup ogranicenja se formira na osnovu prethodno obli-kovanih tipova formi za azuriranje.

Inicijalni skup tipova formi, na osnovu kojeg se formira polazni skup ogranicenja,a zatim generise podsema relacione baze podataka Nm(Sm, Im), predstavlja bilo koji nepra-zan, imenovani podskup skupa tipova formi iz klase AF(u), koje pripadaju tekucemaplikacionom sistemu. Pri tome, u takav skup mogu biti ukljuceni ne samo tipovi formi kojisu kreirani u okviru tekuceg aplikacionog sistema, vec se u njega mogu ukljuciti i referenci-rani tipovi formi iz drugih aplikacionih sistema.

13.6.3.1. Oblikovanje polaznog skupa ogranicenja

Tipovi formi za azuriranje nose informaciju o potrebnoj strukturi seme baze po-dataka pa se putem njih moraju definisati sva potrebna obelezja i sva ogranicenja seme bazepodataka. Polazni skup ogranicenja, na osnovu kojeg se vrsi projektovanje podseme relaci-one baze podataka predstavlja uniju:

(13.1) F ∪ NF ∪ JF,

pri cemu je F skup funkcionalnih zavisnosti, izveden na osnovu tipova formi iz klase zaazuriranje:

( )F F UF SF u

=∈

F i BPi

( )| ,U

NF je skup nefunkcionalnih zavisnosti, izveden na osnovu tipova formi iz klase za azuri-ranje:

( )N F FF SF u

=∈

NF ii

( ) ,U

a JF je skup zavisnosti spoja, izveden na osnovu tipova formi iz klase za azuriranje:

{ }JF FF SF u

=∈

J ii

( ) .U

F(Fi)|UBP je projekcija skupa funkcionalnih zavisnosti tipa forme na skup obelezja seme

baze podataka. Ova projekcija skupa je vazna zbog toga sto se na tipu forme mogu pojaviti


izvedena obelezja iz skupa U \ UBP, koja, prilikom projektovanja podseme, ne treba uzimatiu obzir.

13.6.3.2. Generisanje podseme relacione baze podataka

Postupak generisanja podseme relacione baze podataka Nm(Sm, Im), na osnovuskupa ogranicenja F ∪ NF, obuhvata izvodjenje sledecih aktivnosti:• generisanje skupa sema relacija u trecoj normalnoj formi Sm,• odredjivanje kandidata za primarne kljuceve i prostiranje primarnih kljuceva u skupu

sema relacija Sm,• test nezavisnosti skupa sema relacija Sm i• generisanje skupa ogranicenja seme baze podataka Im.

Skup sema relacija seme baze podataka se generise algoritmom sinteze, koji jeopisan u tacki 2.4. Pri tome, koriste se prosirenja ovog algoritma, koja se odnose na tretmannefunkcionalnih odnosa, opisana u tacki 2.4.1.

Odredjivanje kandidata za primarne kljuceve i prostiranje primarnih kljuceva seobavlja uz pomoc istoimenih algoritama, prikazanih u okviru tacke 3.5.

Test nezavisnosti skupa sema relacija se obavlja putem algoritma za proveru neza-visnosti skupa sema relacija, prikazanom u tacki 4.4.

Postupci za generisanje skupa ogranicenja Im su opisani u glavi 7. Za generisanjereferencijalnih integriteta koji su posledica prostiranja kluceva i koji su posledica postojanjanetrivijalnih zavisnosti sadrzavanja u univerzalnoj semi relacije, koriste se: "Algoritam zaodredjivanje skupa referencijalnih integriteta" i "Algoritam za projektovanje referencijalnihintegriteta, zasnovanih na netrivijalnim zavisnostima sadrzavanja", dati u tacki 7.2.5. Pritome, zakljucak o postojanju neke netrivijalne zavisnosti sadrzavanja u semi univerzalnerelacije sledi iz specifikacije obelezja, na osnovu koncepta preimenovanja, koji je u tacki13.6.1.2 oznacen kao ObPreim. Nakon generisanja referencijalnih integriteta, korisnik je umogucnosti da, u interakciji s IIS*CASE-om, definise skup inverznih referencijalnih integ-riteta.

13.6.4. Integracija seme baze podataka informacionogsistema

Prilikom konceptualnog projektovanja seme baze podataka putem tipova formi,moze doci do kolizija u izrazavanju semantike ogranicenja, koja vaze u realnom sistemu.Do takvih kolizija moze doci kako usled neusaglasenosti dobijenih rezultata rada od stranevise projektanata, tako i usled neusaglasenosti rezultata projektovanja samo jednog pro-jektanta. Jedan primer moguce kolizije, izazvane razlicito definisanim tipovima formi zaazuriranje, jeste istovremena egzistencija funkcionalne zavisnosti i nefunkcionalnog odnosanad istim skupom obelezja. Takva kolizija bi mogla dovesti do problema lose definisanogkljuca rezultujuce seme relacije.


Navedene neusaglasenosti su, cesto, posledica nedovoljno dobrog sagledavanja in-formacionih zahteva korisnika i pravila poslovanja koja vaze u realnom sistemu, ali i cinje-nice da se projektanti u svom radu bave kompleksnom problematikom, koja moze prevazicimoci ljudske percepcije. Jedan od nacina da se navedeni problemi ublaze, ili rese, jestepostupno projektovanje integrisane seme baze podataka informacionog sistema, deo po deo.Ti delovi, iz kojih se formira jedinstvena sema baze podataka, predstavljaju prethodno is-projektovane podseme. Formiranje seme baze podataka informacionog sistema, saglasnocinjenici da su moguce kolizije, izvodi se postupkom integracije, a ne jednostavnim"uniranjem" generisanih podsema.

Opstim postupkom integracije eksternih sema u konceptualnu semu baze podatakabavi se glava 11 ove knjige, a posebno tacka 11.4.3, dok glava 5 daje teoretske osnove zaoblikovanje postupka integracije podsema u integrisanu, relacionu semu baze podataka.Stoga, na ovom mestu integraciji seme baze podataka nece biti posvecena veca paznja. Sobzirom na prethodno izlozenu materiju, na ovom mestu treba naglasiti da eventualnootkrivene kolizije u postupku integracije dve podseme u novu semu relacione baze podata-ka, iniciraju potrebu da se neki od tipova formi, koji su koliziju prouzrokovali, preprojek-tuju, u cilju usaglasavanja s tekucom verzijom seme baze podataka. Na taj nacin, postupakprojektovanja tipova formi, generisanja podsema i njihove integracije je cesto iterativan, iokoncava dolaskom do usaglasenog resenja sa tekucom verzijom seme baze podataka.

13.6.5. Generisanje programskog koda

Predvidja se da proizvod IIS*CASE bude opremljen skupom generatora, razlicitenamene. Jedan od njih, SQL generator, namenjen je za generisanje implementacionog opisaseme baze podataka po standardnoj sintaksi jezika SQL. Na osnovu stanja dela recnika po-dataka, koji pokriva opis tekuce seme baze podataka i parametara koje zadaje korisnikIIS*CASE-a, SQL generator produkuje datoteke koje sadrze naredbe za:• kreiranje tabela,• deklarisanje ogranicenja primarnog i ekvivalentnih kljuceva,• deklarisanje ogranicenja domena i zabrane, odnosno dozvole nula vrednosti za obelezje,• deklarisanje ogranicenja referencijalnog integriteta, sa specifikacijom nacina dovodjenja

baze podataka u konzistentno stanje u slucaju njegovog narusavanja i• kreiranje trigera i procedura za kontrolu medjurelacionih ogranicenja, u situacijama kada

je takva ogranicenja nemoguce zadati deklarativno.Principi rada SQL generatora su bazirani na materiji, izlozenoj u glavama 8 i 9, ove knjige.

Kada su u pitanju generatori prototipova aplikacija, jedan od njih treba da bude umogucnosti da izgenerise izvorni kod prototipa aplikacije u objektno-orijentisanom jezikuC++. Takav prototip treba da predstavlja klijent aplikaciju, koja putem ODBC protokolakomunicira sa serverom relacione baze podataka. Prototip aplikacije se generise na osnovudela stanja recnika podataka, koji pokriva definicije:• tipova formi aplikacije, namenjenih za upite ili azuriranje baze podataka (sa izgledima

ekranskih ili stampanih formi),


• hijerarhijske strukture menija aplikacije,• podsema za svaki tip forme iz klase za azuriranje ili upite. Svaka podsema sadrzi samo

potreban skup sema relacija seme baze podataka, s potrebnim (ne nuzno svim) obelezji-ma, kao i potreban skup ogranicenja, da bi se tip forme upotrebio za azuriranje ili upit,saglasno svojoj nameni i

• za svaki tip forme i svaku semu relacije pripadajuce podseme, uloge i nacine upotrebesame seme relacije i svih njenih obelezja.

case proizvodistroga.anonima.free.fr/pdf/glava13.pdf · bolje performanse racunarskih i...

Documents