Objektno – orijentisani model podataka

 

Tokom osamdesetih godina je došlo do primjene računara u jednom broju novih oblasti. U te nove oblasti primjene spadaju:

·        računarom podržano projektovanje u mašinstvu, elektrotehnici, arhitekturi, građevinarstvu i informatici,

·        multimedijalni sistemi i

·        baze znanja.

Sve ove nove oblasti primjene zahtjevaju manipulisanje velikim količinama podataka i mogle bi imati koristi od primjene SUBP. Međutim, priroda podataka u tim primjenama se teško uklapa u relacione okvire. Na primjer, sistemi za računarom podržano projektovanje treba da omoguće izgradnju modijela kompleksnih objekata i održavanje različitih verzija istog objekta. Multimedijalni sistemi sadrže tekstove varijabilne dužine, grafiku, slike, audio i vidio podatke, što rezultuje u zahtjevu za efikasnim memorisanjem i manipulisanjem nizovima velike i promjenljive dužine. Konačno, sistemi zasnovani na znanju zahtjevaju semantički bogate podatke i kompleksne operacije. Sve ove nove oblasti primjene stavljaju akcenat na još dva zahtjeva. To su: produktivnost programera i performanse obrade.

Opisani zahtjevi su doveli i do razvoja novog modijela podataka, koji bi trebalo da ih zadovolji. Taj novi model podataka se naziva objektno - orijentisanim. Razvija se na idejama objektno - orijentisanih programskih jezika i semantičkih modijela podataka. Cio pristup se, često, naziva objektno - orijentisanom paradigmom. Termin paradigma se odnosi na određeni način mišljenja o nečem. Kada je riječ o objektno - orijentisanoj paradigmi, riječ je o softverskom predstavljanju realnih entiteta putem parova (struktura poda-taka, ponašanje). Ti parovi predstavljaju nedjeljivu cjelinu, a nazivaju se objektima. Pri tome, ponašanje se odnosi na programsku realizaciju postupaka, putem kojih objekti mijenjaju stanje ili samo daju informaciju o svom stanju. Stanje objekta je definisano strukturom podataka, putem koje je realni entitet predstavljen.

Objektno - orijentisani model podataka je još u razvoju. Ne postoji opšte prihvaćen stav koji od, međusobno različitih, objektno - orijentisanih jezika treba da predstavlja osnovu za njegovu operacijsku komponentu. Model nije unificiran jer oslanjanje na različite programske jezike dovodi do daljih razlika u verzijama modijela podataka. Cilj ovog poglavlja je da ukaže na stanje razvoja objektno - orijentisanog modijela podataka. Samo poglavlje je podeljeno u pet dijelova. U prvom su nešto opširnije opisani zahtjevi novih oblasti primjena u odnosu na baze podataka, kao i osnovni razlozi nepogodnosti relacionog modijela da tim zahtjevima udovolji. Mada su strukturalna i operacijska komponenta kod objektno - orijentisanog modijela podataka međusobno čvrsto povezane, drugi, treći i četvrti dio poglavlja je posvećen detaljnom opisu strukturalne komponente modijela sa samo neophodnim refleksijama na operacijsku komponentu. Peti dio je posvećen integritetnoj komponenti. Kao operacijska komponenta modijela podataka, u šestom dijelu je opisan programski jezik C++. Konačno, sedmi dio je posvećen komparaciji potencijala objektno - orijentisanog i stvarnih mogućnosti relacionog modijela podataka.

 

 

Nove oblasti primjene baza podataka

Računarom podržano projektovanje, baze znanja i multimedijalni sistemi predstavljaju potencijalno nove oblasti primjene baza podataka. Redoslijed nabrajanja ovih oblasti primjene, ukazuje i na redoslijed uvođenja odgovarajućih softverskih sistema u praksu. Softverski sistemi za računarom podržano projektovanje (Computer Aided Design (CAD), Computer Aided Manufacturing (CAM), Computer Aided Software Engineering (CASE)) su se pojavili prvi, te će naredna analiza zahtjeva u odnosu na sisteme baza podataka biti, pretežno, zasnovana na potrebama tih sistema.

Softverski sistemi za računarom podržano projektovanje se koriste za rešavanje kompleksnih zadataka inženjerske prakse. U takve zadatke spadaju izrade projekata: mašinskih proizvoda, proizvodnih linija, kompletnih fabrika, brodova, aviona, zgrada, mostova, integrisanih kola velike gustine, računara ili informacionih sistema. Inženjersko projektovanje postavlja jedan broj novih zahtjeva u odnosu na model podataka i sistem za upravljanje bazom podataka. Ti zahtjevi su posledica sljedećih specifičnosti primjene računara u inženjerskom projektovanju:

·        Nehomogenost podataka. Inženjerski projekti sadrže heterogen skup objekata. Za te projektne objekte je karakterističan veliki broj različitih tipova, svaki sa malim brojem pojava.

·        Nizovi promjenljive i nizovi velike dužine. Digitalizovani crteži predstavljaju, često, sastavni dio inženjerskih projekata. U digitalizovanom obliku, cio crtež je predstavljen kao veoma dug niz bajtova, od kojih svaki nosi informaciju o nivou sivila jedne tačke, izuzetno malih dimenzija, na crtežu. Pored toga, oni posjeduju i zapise promjenljive dužine sa tekstualnim podacima.

·        Kompleksni objekti. Inženjerski projekti, po pravilu, sadrže kompleksne objekte, koji se mogu rekurzivno deliti u manje objekte. Kompleksan objekat ima hijerarhijsku strukturu podataka. Bez obzira na to, korisnik mora moći da manipuliše tim objektom kao da je jedinstven.

·        Upravljanje verzijama. U inženjerskim projektima je neophodno voditi zapise o soluciji rješenja. Projektanti često eksperimentišu sa više verzija jednog objekta, pre nego što izaberu onu, koja najbolje zadovoljava postavljene zahtjeve. U principu, jadan objekat može imati samo jednu prethodnu verziju i više paralelnih narednih verzija. Svaka od narednih verzija se naziva alternativom. Verzije jednog objekta formiraju strukturu stabla.

·        Evolucija šeme. Inženjerski projekti, obično, prolaze dug evolutivni period. Tokom tog perioda, intenzivno se mijenja statička struktura projekta. Te promjene se reflektuju kroz potrebu da se dinamički mijenja i šema baze podataka.

·        Ekvivalentni objekti. Postoji više mogućih pogleda na isti objekat projektovanja. Na primer, jedan VLSI čip se može predstaviti na nivou logičkih kola, u cilju provjere logičke funkcionalnosti, na nivou tranzistora, u cilju analize brzine rada, ili na nivou šeme povezivanja, u cilju provjere primjenjenih pravila projektovanja. Mada se reprezentacije znatno razlikuju, riječ je o samo različitim reprezentacijama istog objekta. Te reprezentacije se nazivaju ekvivalentnim objektima. Prava svrha ekvivalentnih objekata je da uvedu ograničenja na bazu podataka. Naime. ako se dio projekta izmeni u jednoj  reprezentaciji,  sistem  treba   ili  da  tu  promenu  sprovede  i  u drugim reprezentacijama, ili da barem isti dio, u drugim reprezentacijama, označi kao nevažeći.

·        Modularnost. Velika složenost projekta nameće potrebu paralelnog rada većeg broja projektanata na njegovim dijelovima - modulima. Moduli projekta nisu međusobno nezavisni. Pri tome, svaki modul smije da mijenja samo njegov projektant, a drugim projektantima treba da budu poznate njegove ulazno - izlazne karakteristike, da bi sa njime povezali svoj modul.

·        Dugačke transakcije. Transakcije u inženjerskom projektovanju uz primjenu računara traju veoma dugo. Projektant započinje transakciju, putem koje mijenja neki objekat i radi na njemu nedjeljama, pre nego što, završivši transakciju, stavlja rezultate svog rada na uvid i drugim korisnicima baze podataka.

 

Multimedijalne baze podataka. U modernom kancelarijskom informacionom ili drugom multimedijalnom sistemu, podaci uključuju ne samo tekstove i brojeve, već i slike, grafiku i digitalizovane zvučne i vidio zapise. Takvi multimedijalni podaci se memorišu kao nizovi bajtova promjenljive dužine, a dijelovi tih nizova su međusobno spregnuti, radi lakšeg povezivanja tekstova, slika, zvuka i vidio zapisa.

Baze znanja. Vještačka inteligencija i ekspertni sistemi predstavljaju informacije kao činjenice i pravila, koje se mogu zajedno posmatrati kao baza znanja. U tipičnim primjenama veštačke inteligencije, predstavljanje znanja zahtjeva strukture podataka sa bogatom semantikom. Operacije u bazi znanja su kompleksnije nego u tradicionalnim bazama podataka. Na primer, kada se želi dodati neko novo pravilo, sistem mora proveriti da li je ono suvišno ili u kontradikciji sa dotadašnjim pravilima. Kompleksnost takvih provera raste veoma brzo sa porastom baze znanja.

Ograničenja relacionog modijela podataka

Relacijom sistemi za upravljanje bazama podataka nisu u stanju da zadovolje zahtjeve ovih novih oblasti primjene računara. Za to postoje dva razloga. Jedan je posledica činjenice da se, pri projektovanju relacionih sistema za upravljanje bazama podataka, jednostavno nije vodilo računa o tim novim oblastima primjene. Drugi razlog leži u činjenici da sam relacioni model podataka ne posjeduje mogućnosti za efikasno zadovoljenje zahtjeva, koje postavljaju nove oblasti primjene.

Relacioni sistemi za upravljanje bazama podataka nisu razvijani tako da bi efikasno podržavali:

·        Rad sa nehomogenim skupovima podataka, jer su projektovani za efikasno upravljanje bazama podataka, kod kojih broj pojava (torki) daleko premašuju broj tipova entiteta (šema relacija).

·        Intenzivne izmjene šeme baze podataka, jer su razvijani pod pretpostavkom da se šema baze podataka retko mijenja, pa su u njih ugrađeni i, relativno, skromni mehanizmi za izmjenu šeme.

·        Upravljanje različitim verzijama jednog objekta. Modifikacijom se, u relacionoj bazi podataka, gube prethodne vrijednosti određenih podataka. Ne postoje ugrađeni mehanizmi za efikasno vođenje evidencije o promenama stanja objekata. S druge strane. to su prirodni zahtjevi primjena, kao što su: planiranje, simulacija i podrška odlučivanju.

·        Upravljanje ekvivalentnim objektima, posebno kada je riječ o evidentiranju potrebe izmjene jednog objekta, na osnovu izmena u njemu ekvivalentnom objektu.

·        Upravljanje dugačkim transakcijama. Transakcija je takav niz akcija čitanja i pisanja u bazu podataka, koji ostavlja bazu podataka u konzistentnom stanju. Nakon završetka transakcije, sve promjene, koje je ona izazvala u bazi podataka, postaju vidljive odjednom, ili, ako je došlo do bilo kakve neregularne situacije, upravljač transakcijama poništava sve promjene u bazi podataka, kao da transakcija nije ni izvršavana. Upravljači transakcijama relacionih sistema su razvijani za transakcije, koje kratko traju. Ako dođe do pada sistema tokom izvršavanja dugačke transakcije, putem koje se modifikuje neki projektantski objekti, strategija rekonstrukcije stanja baze podataka na osnovu kopije nekog prethodnog stanja i sadržaja žurnal datoteke, rezultovala bi u gubitku nedjelja rada, jer bi se rekonstrukcija baze podataka izvršila saglasno stanju pre početka posmatrane transakcije. Primjena računara u inženjerskom projektovanju traži od sistema za upravljanje bazom podataka da i parcijalni rezultali neke transakcije budu vidljivi i da omogući takvu rekonstrukciju baze podataka da i  parcijalni rezultati projektantskih transakcija budu spašeni, a ne da rekonstrukcija znači vraćanje u stanje nakon poslednje uspješno  završene transakcije.

Mada jednostavan i zasnovan na strogim teorijskim osnovama, relacioni model nameće određena ograničenja na reprezentovanje realnih entiteta u bazama podataka. Organizovanjem podataka u relacije (tabele), relacioni model pretpostavlja horizontalnu i vertikalnu homogenost podataka. Horizontalno, svaka torka date relacije posjeduje istu definiciju za obilježja. Vertikalno, dato obilježje uzima vrijednosti iz istog domena u svakoj torci. Pri tome, domeni su ograničeni na primitivne tipove podataka, kao što su: cijeli i realni brojevi, karakteri i slično, ograničene dužine. Svakoj torci odgovara samo jedna Vrijednost iz domena svakog obilježja. Potreba da se reprezentacijama entiteta jedne klase pridruži skup vrijednosti iz nekog domena, dovodi ili do pojave većeg broja torki sa pretežno (ali ne potpuno) istim sadržajem, ili do dekompozicije šeme relacije, kao modijela klase realnih entiteta, na nekoliko novih šema relacija. Broj torki sa pretežno istim sadržajem jednak je kardinalnom broju skupa vrijednosti iz domena, koji treba pridružiti jednom entitetu. Takvo predstavljanje podataka o entitetima dovodi do nepoželjne redundanse podataka.

Ako se šema relacije rastavi (dekomponuje) na više šema relacija, tada se kompleksan objekat memoriše putem zapisa, rasutih po različitim relacijama. Međutim, za korisnika taj kompleksni objekat i dalje predstavlja jednu logičku cjelinu i jedinicu posmatranja. Dekompozicija značajno smanjuje performanse računarske obrade podataka, jer uvodi potrebu čestog korišćenja operatora prirodnog spajanja, u cilju rekonstruisanja kompleksnih objekata.

Dalje, relacioni model eksplicitno ne uključuje semantiku, kao dio reprezentacije realnih entiteta. Umjesto toga, aplikacioni programi interpretiraju semantiku podataka. Kada se primjeni dekompozicija, ne samo što se smanjuje efikasnost obrade, već se povećava i verovatnoća gubljenja semantike povezane sa podacima. S druge strane, jezik podataka relacionog modijela se ne može sam koristiti za izvođenje operacija, potrebnih u bazama znanja.

Može se zaključiti da relacioni model podataka, sam po sebi, nije pogodan za:

·        izgradnju struktura sa podacima promjenljive i velike dužine,

·        predstavljanje kompleksnih objekata,

·        izvršavanje operacija takve kompleksnosti, kakvu zahtjevaju primjene u bazama znanja.

Primer 1.1. U relacionoj bazi podataka se, često, podaci o radniku nalaze u relacijama nad šemama Radnik, Odjelenje, Radno_Mesto, Radnik_Projekat. U objektno -orijentisanom sistemu, objekti realnog sveta predstavljeni su kao jedan objekat baze podataka. Jedan od osnovnih ciljeva objektno - orijentisanog modijela podataka je da verno preslika objekat realnog sveta u njegovu softversku reprezentaciju. Drugim riječima, Odjelenje, Radno_Mesto, Projekat mogu biti tipovi objekata baze podataka, ako je to potrebno, ali Radnik postaje kompleksni tip objekat, a njegova pojava sadrži sve podatke o samom radniku, o odijelenju u kojem radi, o radnom mestu na koje je raspoređen i o projektima na kojima je angažovan.

Potreba intenzivne primjene operatora prirodnog spajanja za rekonstrukciju kompleksnih objekata od torki, rasutih po raznim relacijama, pokazuje da relacioni sistemi nemaju odgovarajuće performanse, za primjenu u novim oblastima. Zbog toga su, mnogi današnji sistemi, namenjeni za inženjersko projektovanje, izgrađeni na sistemu datoteka. Jedna studija [CH] pokazuje da realizacija CAD sistema putem relacionog SUBP dovodi do petostrukog povećanja vremena pretraživanja podataka u poređenju sa implementacijom putem datoteka. Međutim, izgradnja putem sistema datoteka dovodi do poznatih problema zavisnosti programa i podataka, nekompatibilnosti i nekonzistentnosti podataka.

S druge strane, za relacione SUBP su razvijeni principi izgradnje čitavog niza važnih mehanizama, kao što su:

·         neproceduralni jezik podataka,

·         automatska optimizacija upita,

·         uslovi integriteta,

·         upravljač transakcijama,

·         zaštita od neovlašćenog korišćenja,

·         zaštita od uništenja,

·         distribucija baze podataka i distribucija njene obrade,

koje će i novi, objektno - orijentisani SUBP morati da koriste. Relacioni sistemi će se i dalje koristiti u oblastima gde su zahtjevi u odnosu na tipove podataka i na koncepte za izgradnju modijela realnih entiteta primjereni mogućnostima modijela. Međutim, za određene primjene su relacioni SUBP jednostavno nepogodni.

 

Porijeklo objektno - orijentisanog modijela podataka

Objektno - orijentisani model podataka (dalje OOMP) je razvijan na drugi način nego relacioni model podataka. Umjesto da se podje od jednostavne definicije i snažnog matematičkog aparata, razvoj OOMP je zasnovan na tradicijama:

Slika 0.1.

·         objektno - orijentisanih programskih jezika i

·         semantičkih modijela podataka.

Objektno - orijentisani SUBP se razvijaju na tradicijama SUBP, zasnovanih na drugim modelima podataka. Slika 7.1 pokazuje koji koncepti iz različitih oblasti su korišćeni za razvoj objektno - orijentisanog modijela podataka i SUBP.

Prva pojava objekta, kao koncepta, javlja se u Simuli, simulacionom jeziku razvijenom u ranim sedamdesetim godinama. Međutim, istraživači su počeli pokazivati interes za objektno - orijentisane jezike tek nakon pojave Smalltalk - a [GR]. Od onda, u literaturi je opisan veći broj takvih jezika. Danas, pored Smalltalk‑a, intenzivno se koriste objektni Pascal i C++ Interes za primjenu objektno - orijentisanih jezika u inženjerskim primjenama je posledica:

·         njihove sposobnosti da efikasno koriste strukture sa praktično proizvoljnim tipovima podataka,

·         postojanja bogatih biblioteka sa gotovim klasama (pojam klase je objašnjen u daljem tekstu) i

·         mogućnosti ponovnog korišćenja već provjerenog programskog koda.

 

Razlika između objektno - orijentisanog programskog jezika i objektno - orijentisane baze podataka je da baza podataka podrazumijeva postojanje permanentno memorisanih objekata na medijumu eksterne memorije, dok objekti u objektno - orijentisanom programskom jeziku postoje samo tokom izvršavanja programa. Dodavanje mogućnosti trajnog memorisanja podataka programskom okruženju, dovelo je do pojave objektno - orijentisanih SUBP.

Semantički modeli podataka su druga od tri oblasti, koje su uticale na razvoj objektno - orijentisanog modijela podataka. U semantičke modijele podataka spadaju: prošireni ER model, funkcionalni model i semantički model podataka. Semantički modeli podataka imaju dva moćna koncepta. To su: agregacija i specijalizacija.

Agregacija je postupak izgradnje složenih objekata - agregata, od objekata - komponenata. Postoje dva slučaja sličnosti između agregata i koncepata ER modijela podataka. Prvi je kada se agregacijom obilježja dobija tip entiteta - agregirani objekat. Drugi je slučaj kada se kombinuju međusobno povezani tipovi entiteta u agregirani tip entiteta na višem nivou apstrakcije. Odnos između tipa entiteta - komponente i agregata se naziva vezom tipa "je dio". Pojava agregata je egzistencijalno zavisna od pojava svojih komponenata. Na slici 7.2 je prikazana reprezentacija agregata i komponenata putem koncepata ER modijela podataka. Treba naglasiti da i komponenta može predstavljati agregat. Agregacija je jedan od postupaka za predstavljanje hijerarhijskog odnosa između entiteta različitih realnih klasa.

Međutim, agregat je jedna cjelina, te je, sa te tačke gledišta, adekvatnija njegova geometrijska reprezentacija prema slici 7.3. U svakom slučaju, agregat je apstraktni tip entiteta, koji sadrži heterogene komponente.

Korišćenjem termina relacionog modijela podataka, pojam agregata se može objasniti na sljedeći način: šema relacije, reprezent agregata ima obilježja, koja i sama mogu biti šeme relacija, tako da vrijednosti obilježja u torci mogu predstavljati torke nekih drugih relacija. Pojava šeme relacije u ulozi obilježja neke druge šeme relacije, naziva se "ugnježdavanjem". Ugnježdavanje može imati proizvoljnu dubinu.

Slika 0.2.

Slika 0.3.

Specijalizacija je apstrakcija proširenog ER modijela podataka, te je detaljno obrađena u glavi 2 ove knjige. Ukratko, elementi neke klase se mogu specijalizovati i grupisati u potklase. Jedna potklasa nasljeđuje sve osobine svojih superklasa. Elementi potklase pripadaju i superklasi. Element potklase nasljeđuje osobine odgovarajućeg elementa člana superklase, ali posjeduju i svoje, specifične osobine.

 

Osnovni koncepti objektno - orijentisanog modijela podataka

Objektno - orijentisana paradigma donosi čitav niz novih pojmova i mehanizama za predstavljanje realnih entiteta. Ti pojmovi i mehanizmi predstavljaju koncepte objektno - orijentisanog modijela podataka. U nove pojmove i mehanizme spadaju:

• objekat,
• metoda,
• poruka,
• inkapsulacija (učaurenje),
• klasa,
• nasljeđivanje i
• identitet objekta.

Svi ovi koncepti su opisani i ilustrovani u ovoj tački. Zbog kompleksnosti i važnosti uloge, koju igraju u objektno - orijentisanom modijelu podataka, mehanizam nasleđivanja i pojam identiteta objekta opisani su i u posebnim tačkama ovog poglavlja.

Osnovni tipovi podataka

Svaki programski jezik podržava neki skup tipova podataka. Kada je riječ o konvencionalnim programskim jezicima, kao što je Pascal ili, kada je riječ o jezicima podataka mrežnog ili relacionog sistema za upravljanje bazama podataka, oni podržavaju osnovne tipove podataka, kao što su: cijeli (int) i realni (real) brojevi, karakteri (chr), datum (date), novac (money) i logički podaci, koji uzimaju vrijednosti iz skupa {true, false}. Takođe, podržavaju tipske konstruktore za izgradnju složenijih tipova podataka, kao što su: nizovi, liste, slogovi i skupovi. Elementi domena, pridruženog obeležju, predstavljaju se putem nekog od osnovnih tipova podataka. Za svaki osnovni tip podataka, karakterističan je jedan broj operacija. Te operacije su ugrađene u razne programe.

Primer 1.2. Elementi domena, pridruženog obeležju IME, predstavljaju se putem karaktera ili niza karaktera, a elementi domena, pridruženog obeležju KOL (količina materijala), predstavljaju se putem cijelih ili realnih brojeva. Primjeri operacija nad ovim tipovima podataka su, redom: povezivanje nizova karaktera, primjena aritmetičkih operacija na cele ili realne brojeve.

Pojam objekta

Objekat je jedan od mogućih modijela realnog entiteta. Taj model ima dvije komponente. To su: stanje i ponašanje. Stanje objekta se reprezentuje putem strukture nad skupom podataka o realnom entitetu. Ponašanje objekta je skup procedura, koji se nazivaju metodama ili operacijama. Ti programi služe za izmjenu stanja objekta (ažuriranje strukture podataka) ili samo za davanje informacije o njegovom stanju. Bez insistiranja na preciznosti, metode se mogu posmatrati i kao programi, koji opisuju ponašanje realnog entiteta.

Primer 1.3. Ako je Ivo Ban programer sa platom od VOO dinara, tada bi sledeća semantički određena linearna struktura podataka mogla predstavljati strukturalni dio odgovarajućeg objekta

((IME, Ivo), (PRZ, Ban), (ZAN, programer), (PLT, 400)), a skup

{zaposli, povećaj_platu, prikaži_platu,prikaži_podatke, penzioniši}

bi sadržao nazive metoda, koji se mogu primjeniti na tu strukturu podataka.

Mada je objekat dvojka (stanje, ponašanje), često se eksplicitno naglašava samo njegova strukturalna komponenta, dok se postojanje skupa metoda implicitno podrazumijeva. Opravdanje za takvu nepreciznost, može se tražiti u činjenici da svi objekti, modeli realnih entiteta jedne klase, dijele iste metode, a da struktura, u određenoj mjeri, odražava individualnost objekta. Naredna definicija opisuje mogućne strukture objekta, koristeći termin objekat u smislu struktura podataka objekta.

Definicija 1.1. Neka je U skup obilježja, a D = {cio broj, realan broj, niz karaktera fiksne ili promjenljive dužine, datum, novac,...} skup osnovnih tipova podataka. Tada važi:

1°  Svaki elemenat svakog osnovnog tipa podataka je primitivni objekat.
2°  Ako su: X₁,...,X_n različita obilježja u U, a o₁,...,o_n objekti, tada je

o = ((X₁, o₁),..., (X_n, o_n))

jedan objekat - torka. Objekat o_i je Vrijednost obilježja X_i, u oznaci o, = o_i=oX_i.

3°   Ako su o₁,.... o_n različiti objekti, tada je

o = [o₁,...,o_n}

 jedan objekat - skup i važi o_iÎ0.

Definicija 7.1 ukazuje na veoma širok dijapazon mogućnih struktura podataka objekta. Objekat može imati tako jednostavnu strukturu, kakvu ima jedan cio broj, ili kompleksniju, kakva je relaciona torka ili skup objekata, do veoma kompleksne strukture, kakva je struktura stabla nad skupom objekata. Bitno je zapaziti da obilježja iz U mogu uzimati vrijednosti iz proizvoljnog domena. Vrijednost obilježja može biti cio broj ili niz karaktera, ali i torka, skup, ili neka kompleksna struktura podataka.

Primer 1.4. Pošto broj 5 pripada skupu cijelih brojeva, broj 5 je jedan primitivni objekat Slično, pošto "Ana" pripada skupu nizova karaktera, i "Ana" je primitivni objekat.

 

Objekat ((IME, Ana), (PRZ, Ban))je objekat - torka, koji sadrži dva primitivna objekta, a objekat {((PRED, Matematika), (OCE, 8)), ((PRED, Fizika), (OCE, 9))} je objekat skup. Objekat

((IME_I_ PREZIME(IME,Ana), (PRZ, Ban)), (SEM, 2), (ISPIT, {((PRED, Matematika), (OCE, 8)), ((PRED, Fizika), (OCE, 9))})).

reprezentuje realni entitet - studenta Anu Ban, putem jednog složenog objekta - torke. Objekat je složen, jer sadrži:

·       jedan objekat - torku tipa Ime_i_Prezime (koji, sa svoje strane sadrži dva primitivna objekta),

·       jedan primitivni objekat tipa cio broj, (koji reprezentuje upisani semestar) i

·       jedan objekat - skup, čiji elementi, objekti - torke reprezentuju položene predmete sa ocenama.

 

Na slici 7.4 je ovaj objekat prikazan kao struktura stabla nad skupom objekata. Pri tome, listovi stabla sadrže primitivne objekte, dok drugi čvorovi predstavljaju agregate. Agregati su, na slici 7.4, samo naznačeni putem svojih naziva, mada i sami sadrže podatke.

 

 

Slika 0.4.

Putem definicije 7.1 je opisana logička struktura podataka objekta, koja se može značajno razlikovati od njegove memorijske reprezentacije - fizičke strukture. Mogućim fizičkim realizacijama logičke strukture podataka objekta, više prostora je posvećeno u dijelu 7.4 ovog poglavlja.

 

Poruka

Jedino metode, pridružene posmatranom objektu, imaju pravo da pristupaju njegovoj strukturi podataka, bilo u cilju ažuriranja stanja objekta, ili satno davanja informacije o nekoj komponenti njegovog stanja. Metode se pozivaju putem poruka. Poruka je zahtjev, upućen objektu, da izvrši neku od svojih metoda. Objekti međusobno komuniciraju putem poruka.

Slika 0.5.

Osnovni oblik poruke je (<prijemnik>, <naziv metode>). Dio poruke, označen sa <prijemnik>, predstavlja adresu objekta, koji treba da primi i protumači poruku. Ta adresa je ili identifikator objekta, ili neki izraz, putem kojeg se objekat označava. Naime, svaki objekat ima jedan identifikator, koji ga jednoznačno identifikuje. Drugi objekti se obraćaju posmatranom objektu navođenjem tog identifikatora u okviru poruke. Za svaku poruku, koju objekat razumije, postoji odgovarajuća metoda, koja izvršava poruku. Dio poruke, označen sa <naziv metode>, ukazuje o kojoj metodi je riječ. Na osnovu naziva, objekat poziva odgovarajuću metodu. Poruka može sadržati i parametre, neophodne za izvršavanje metode. Objekat vrača pošiljaocu rezultat izvršenja metode, pozvane porukom. Rezultat je obično neki drugi objekat. Na slici 7.5 je prikazan princip komunikacije između objekata. Prema slici 7.5, objekat o₁ prima poruku p¹₄ i, da bi na nju odgovorio, odlučuje da uputi poruku p²₁ objektu o₂. Objekat o₂, sa svoje strane, šalje poruku p³₁ objektu o₃.

Paradigma objekat / poruka pretpostavlja:

•        da svi podaci predstavljaju objekte,

•        da svaki objekat posjeduje skup metoda,

•        da su nazivi tih metoda poznati drugim objektima,

•        da svaki objekat odgovara samo na svoje poruke i

•        da objekti međusobno komuniciraju samo putem poruka.

Metoda je entitet sličan programskoj proceduri. Opisuje redoslijed akcija, koje treba izvršiti po prijemu poruke. Više prostora opisu postupaka za izgradnju metoda, dato je u dijelu 7.6 ovog poglavlja.

Inkapsulacija

Svaki objekat ima svoj privatni i svoj javni dio. Privatni dio objekta čine: struk-tura podataka i skup metoda za tu strukturu podataka. Taj dio objekta se naziva i implementacijom. Javni dio objekta čine: identifikator i nazivi metoda. To je njegov interfejs (sprega sa okolinom). Poruke pristupaju interfejsu i specificiraju koje metode bi, na objektu, trebalo da se izvrše, ali ne i kako da se te metode izvrše. Objekat, koji primi poruku, određuje kako će se izvršiti tražena metoda. Na slici 7.6, ilustrovani su pojmovi privatnog i javnog dijela objekta.

Slika 0.6.

Uvođenjem privatnog dijela objekta, uvodi do princip skrivanja informacija. To znači da su detalji realizacije objekta skriveni od svih programa izvan objekta. Često se kaže da objekat inkapsulira podatke i programe. To znači da jedan objekat ne može da vidi unutrašnjost "kapsule" drugog objekta, ali može da ga koristi, pozivajući, puteni poruka, njegov programski dio. To je slično pozivima procedura u konvencionalnim programskim jezicima. Inkapsulaciju treba shvatiti i kao ograničenje da se svi pristupi objektima mogu vršiti jedino primenom njihovih metoda.

Klasa

Mnogi objekti u realnom svetu posjeduju slične karakteristike i izvršavaju slične operacije. U proizvodnom pogonu metalskog kompleksa, nalaze se glodalice, rendisaljke, bušilice. Mada je svaki od ovih objekata različit, svi pripadaju klasi mašina za obradu metala rezanjem. Svi objekti u klasi mašina za obradu metala rezanjem posjeduju zajednička obilježja (električni motor, glavno vreteno, na primer) i izvršavaju zajedničke operacije (obrada metala). Prema tome, kategorizacijom jednog struga, kao člana klase mašina za obradu rezanjem, zna se nešto o njegovim obeležjima i operacijama, čak i kada se ne poznaju njegove precizne funkcije.

Objektno - orijentisani model podataka se ne svodi samo na pojam objekta. Osnovni pojam objektno - orijentisanog modijela podataka je klasa. Klasa je dvojka. Jedna komponenta te dvojke je tip objekta, koji nosi informaciju o strukturi podataka. Druga komponenta je skup metoda. To su operacije, koje se primjenjuju na sve objekte, čija struk-tura je definisana putem tipa objekta. Klasa je skup takvih objekata, koji imaju iste karakteristike (tip strukture i metode). Svaki individualni objekat je pojava neke klase.

Definicija 1.2. Neka je U skup obilježja, XÌU, AÎU,a D = {cio broj, realan broj, niz karaktera fiksne ili promjenljive dužine, datum, novac,...} skup osnovnih tipova podataka. Tada važi:

1 °   Dvojka (A, d), gde je dÎD, je tip objekta.

2°   Ako su T₁,...,T_k tipovi objekata, tada je i((X₁,T₁),...,(X_k,T_k)) tip objekta torka.

3°   Ako je T tip objekta, tada je i {T} tip objekta skup. Objekat tipa {T} je skup objekata tipa T.

Komponenta tipa objekta je dvojka (obilježje, tip podataka). Putem obilježja je definisana semantika komponente tipa objekta. Tip podataka je domen obilježja, ali elementi tog domena mogu biti veoma složeni. Elementi domena mogu uzimati vrijednosti iz skupa vrijednosti nekog osnovnog lipa podataka, ali i iz skupa objekata tipa torka ili skup. Pošto su i elementi osnovnih tipova podataka objekti, sa svojom strukturom i ponašanjem, dolazi se do zaključka da domen predstavlja klasu. Domen se, neki put naziva i interpretacijom. Interpretacija je skup, iz kojeg neki semantički koncept uzima vrijednosti. Treba zapaziti da je definicija pojma tipa objekta rekurzivna. Tip objekta se definiše kao struktura nad skupom tipova objekata.

 

Primer 1.5. Tip objekta, pod nazivom TipArtikla se, koristeći uvedenu notaciju, može definisati na sljedeći način

TipArtikla = ((NAZIV, Chr), (IDA, Int))

gde je IDA identifikacioni broj artikla. Nazivi domena obilježja NAZIV i IDA pisani su velikim početnim slovima, da bi se ukazalo da je riječ o tipovima, odnosno klasama. Tip objekta StavkaNrudžbine je

StavkaNarudžbine = ((ARTIKAL, TipArtikla), (KOLIČINA, Int)).

U komponenti (ARTIKAL, TipArtikla) tipa objekta StavkaNarudžbine, ARTIKAL je obilježje, a TipArtikla je klasa. Vrijednosti obilježja ARTIKAL su pojave klase TipArtikla. Sada se može definisati tip objekta TipPorudžbine, kao

TipPorudžbine  ((BRP, Int), (SADRŽI, {StavkaNarudžbine}),

gde je BRP broj porudžbine i gde je obeležju SADRŽI pridružen tip podatka - domen, čiji elementi su skupovi objekata tipa StavkaNarudžbine. Kupci se mogu predstaviti putem sledećeg tipa objekta

TipKupca = ((NAZIV, Chr), (ADRESA, Chr), (STANJE_RAČ, Int), (PORUDŽBINE,

{TipPorudžbine})).

Da bi se uspostavila veza između narudžbina i kupaca, tip objekta TipPorudžbine se može modifikovati na sljedeći način

TipPorudžbine = ((BRP, Int), (KUPAC, TipKupca), (SADRŽI,{StavkaNarudžbine})

Slika 0.7.

Treba zapaziti da tip objekta TipKupca sadrži, kao svoju komponentu, skup pojava klase TipPorudžbine, a da tip objekta TipPorudžbine, kao svoju komponentu, sadrži

 

jednu pojavu klase TipKupca. Na slici 7.7 su prikazane dvije pojave klase Kupac, svaka sadrži određeni broj odgovarajućih pojava klase Porudžbina.

Klasa se opisuje putem naredbi objektno - orijentisanog jezika. To opisivanje klase se naziva deklaracijom klase. U okviru deklaracije klase se navode:

•        nazivi njenih obilježja sa pripadajućim domenima i

•        nazivi metoda sa odgovarajućim programskim kodom.

Putem naziva obilježja i domena se definiše tip objekta, a nazivi obilježja i metoda čine interfejs klase. Primjeri deklaracija klasa u sintaksi objektno - orijentisanog jezika C++ su dati u tački 7.6.

Klasa je generator svojih pojava (objekata istog tipa). Skupu aktuelnih objekata, odgovara pojam ekstenzije u klasičnim modelima podataka. U svakom objekt-no - orijentisanom sistemu postoji mehanizam za generisanje pojava klase. Pošto je i sama klasa vrsta objekta, ona bi mogla da vodi računa o svim objektima, koje je generisala, te i da upravlja svojom ekstenzijom. Međutim, objektno - orijentisani jezici, kakvi su Smalltalk i C++, eksplicitno ne podržavaju pojam ekstenzije klase. Ne postoji eksplicitna mogućnost za uvid i manipulisanje svim aktuelnim pojavama klase. Svakoj pojavi klase se pristupa samo na osnovu poznavanja njenog identifikatora. Ne postoji naredba sa efektom SQL naredbe SELECT *. S druge strane, pojam ekstenzije je izuzetno važan za sisteme baza podataka. Jedan od njihovih osnovnih zadataka je da obezbede efikasnu obradu velikog broja objekata istog tipa. Relacioni sistemi za upravljanje bazom podataka obezbjeđuju upravljanje ekstenzijom, jer je sam model podataka građen tako, da se definisanjem šeme relacije (tipa) obezbjeđuje pristup svim aktuelnim pojavama.

U većini objektno - orijentisanih jezika rad sa ekstenzijom klase se postiže putem objekata tipa kolekcija. Kolekcije su klase, ugrađene u sam jezik. lako da nije potrebno posebno ih definisati. Postoji više vrsta kolekcija. U njih spadaju: skup i torbu. Torba je kolekcija u kojoj se može nalaziti više jednakih objekata. Objekat lipa kolekcija se može upotrebiti u cilju postizanja efekta upravljanja ekstenzijom. Objekti lipa kolekcija sadrže druge objekte. Postupak rada sa kolekcijom u ulozi ekstenzije je sljedeći. Prvo se definiše jedna pojava (objekat) klase kolekcija. Toj pojavi se pridružuje ime (semantika) ekstenzije neke klase. Pošto je riječ o objektu tipa skup objekata, on će sadržati sve one pojave (elemente ekstenzije), koji se u njega eksplicitno upišu.

Primer 1.6. Neka je kreirana klasa Zaposleni i neka je potrebno omogućiti upravljanje njenom ekstenzijom. Tada se prvo definiše nova pojava ugrađene klase tipa kolekcija. Ako je Radnici naziv ekstenzije klase Zaposleni. tada bi se Radnici deklarisali kao nova pojava ugrađene klase, recimo, klase Skup. Svaki objekat klase Zaposleni, nakon svog kreiranja u okviru klase Zaposleni, mora se eksplicitnom naredbom uvrstiti i u objekat - skup sa identifikatorom Radnici. Metode ugrađene klase Skup, omogućavaju upravljanje ekstenzijom klase Zaposleni, pošto je objekat sa identifikatorom Radnici pojava klase Skup.

 

Apstraktni tipovi podataka

Apstraktni tipovi podataka predstavljaju uopštenje pojma osnovnog tipa podatka. Koncepti:

·         inkapsulacije,

·         javnog i privatnog dijela,

·         poruke i metode,

u osnovi su vezani za pojam apstraktnih tipova podataka. U objektno - orijentisanom pristupu, ovi koncepti se realizuju putem klasa. Saglasno tome, i apstraktni tip podatka se može posmatrati kao dvojka (s,m), gde je s struktura, a m skup metoda. Međutim, između pojmova apstraktni tip podatka i klasa, postoji i određena razlika. Apstraktni tip podataka opisuje skup svih mogućih objekata sa datom strukturom i datim ponašanjem. Taj skup može biti neograničen. Nasuprot apstraktnom tipu podataka, klasa opisuje objekte svoje ekstenzije, koja sadrži konačan broj pojava klase.

Nasljeđivanje

Objekti nasleđuju osobine (tip strukture i metode) od svoje klase. Međutim, i klasa može nasleđivati osobine od drugih klasa. Klasa, koja nasljeđuje osobine od druge klase, naziva se potklasom. Klasa, čije osobine nasljeđuje jedna ili više drugih klasa, naziva se superklasom. U literaturi se, za potklasu, sreću i nazivi: potomak ili dete, a za superklasu: predak ili roditelj. Svaka potklasa nasljeđuje sve ili samo dio osobina svoje superklase. Nasleđene osobine nije potrebno ponovo definisati u potklasi. Međutim, nove osobine se mogu dodati potklasama, ako je to potrebno. Potklasa nasljeđuje strukturu tako da sva obilježja superklase postaju obilježja potklase. Potklasa nasljeđuje metode, tako da njeni objekti mogu da koriste sve metode superklase. Međutim, potklasa može imati i svoje metode, neke od metoda superklase mogu biti zabranjene za objekte potklase, a neka od nasleđenih metoda se može i prilagoditi za potklasu. Pošto potklasa može imati svoje potklase, dolazi se do pojma hijerarhije klasa. Hijerarhija klasa definiše "je podvrsta" odnos između klasa. Koncept nasleđivanja kaže da osobine, definisane za neku klasu, mogu naslediti sve potklase te klase. To je slično konceptu specijalizacije u semantičkim modelima podataka.

Korišćenje klasa i nasleđivanja je veoma bitno za savremeno softversko inženjerstvo. Ponovno korišćenje programa se postiže kreiranjem novih klasa, zasnovanih na obeležjima i metodama postojećih klasa. Tada treba samo da se specificira kako se nova potklasa razlikuje od svoje superklase, a ne i da se defniše kompletno nova klasa. Nova klasa nasljeđuje već provjerene metode od svojih superklasa i te metode ne treba ponovo programirati.

Identitet objekta

U objektno orjentisanom modijelu podataka, svakom objektu, osim primitivnom, pridružuje se jedinstveni identifikator. Primitivnom objektu se identifikator ne pridružuje, jer primitivni objekti imaju jedinstvene vrijednosti, koje ih samoidentifikuju. U svojstvu identifikatora se može koristiti adresa memorijske lokacije, u koju je objekat smješten, ali postoje i druga rješenja. Važno je da je identifikator nezavisan od bilo kojeg obilježja tipa objekta, pa i ključa. Na taj način se omogućava ažuriranje svakog obilježja (promena stanja) objekta bez opasnosti da se naruši identitet objekta. Identifikator ostaje nepromenjen dok se objekat ne izbriše iz baze podataka. Identifikator se koristi kao referenca na objekat, kao surogat - zamena za objekat. Identifikator obezbjeđuje jedinstvenost identiteta objekta, ali, ako je to memorijska adresa, nju korisnik ne može poznavati. Postoje i druga rješenja za realizaciju identiteta objekta. Ta rješenja su opisana u tački 7.4.

Paralela između termina objektno - orijentisanog i drugih modijela podataka

Smatra se da objektna - orjentacija predstavlja ne evolutivni, već revolutivni skok u razvoju ne samo baza podataka već kompletnog softvera. Revolucionarnost objektnog modijela podataka u odnosu na druge, ogleda se, pre svega, u načinu izgradnje softverske reprezentacije realnih entiteta. Novi model sadrži i čitav niz novih pojmova sa specifičnim nazivima. Za lakše shvatanje sličnosti, ali i razlika između koncepata objektnog i drugih modijela podataka, pogodno je povući paralelu između sličnih, ali nikako identičnih pojmova i njihovih naziva.

Terminologija

o-o model	tumačenje	drugi modeli podataka
Objekat	apstraktna predstava nekog realnog entiteta	pojava tipa entiteta, torka
Klasa	dvojka (tip objekta, skup metoda), koja generiše objekte sa zajedničkim osobinama	tip entiteta, šema relacije
Apstraktni tip podataka	opis skupa objekata sa istim tipom strukture i ponašanjem
Hijerarhija klasa	struktura, dobijena izvođenjem relacije "je podvrsta" u skup klasa	šema baze podataka
Osobina	neka rutina, aktivnost ili obilježje, koje služi kao dio definicije klase	obilježje
Metoda	osobina, koja obavlja neku operaciju na objektu		telo procedure
Promenljiva pojave	obilježje, kao osobina objekta		polje
Pojava klase	objekat		pojava tipa entiteta, torka
Poruka	protokol, koji se sastoji od metode ili rutine i identifikatora (ili adrese) jednog objekta		poziv procedure
Skrivanje informacija	odvajanje javnog od privatnog dijela objekta ili klase
Inkapsulacija	sakrivanje informacija
o-o model	tumačenje		drugi modeli podataka
Nasljeđivanje	takva relacija između dvije klase, kod koje jedna klasa, dete, preuzima sve relevantne osobine druge klase, roditelja		ISA hijerarhija

Nasljeđivanje

Objektna orijentacija ima dva cilja. To su:

•      izgradnja što je moguće vernijeg modijela realnog sveta i

•      obezbeđenje uslova za proširljivost i ponovno korišćenje softvera.

Oba cilja se postižu putem koncepta nasleđivanja. Naime, hijerarhije nasleđivanja pred-stavljaju prirodan mehanizam za izgradnju taksonomijske strukture realnog sistema. (Taksonomijska struktura predstavlja sistematizaciju dijelova realnog sistema.) Takođe, putem nasleđivanja grade se nove klase na osnovu postojećih. Time se izbegava projektovanje struktura i programiranje metoda novih klasa uvek iz početka. Nove klase nasleđuju ponašanje i obilježja od postojećih. Nasljeđivanjem ponašanja postiže se deljeno korišćenje programskog koda, a time ponovno korišćenje softvera.

Nasljeđivanje vuče korene od postupaka predstavljanja znanja u veštačkoj inteligenciji. U veštačkoj inteligenciji se nasljeđivanje predstavlja putem IS_A (je) relacije i ograničeno je na nasljeđivanje strukture, kako na nivou intenzije, tako i na nivou ekstenzije. Specijalizacija predstavlja najčešće korišćeni postupak za realizaciju nasleđivanja.

U objektno - orijentisanim jezicima, nasljeđivanje se odnosi, pre svega, na klase, znači intenziju. Potklasa nasljeđuje osobine (tip strukture i metode) od svoje superklase. tako da potklasa predstavlja intenzionalnu specijalizaciju svoje superklase. Pojava potklase se može posmatrati kao ekstenzionalna specijalizacija svoje klase, međutim, pojava potklase nije specijalizacija odgovarajuće pojave superklase. Šta vise, ta odgovarajuća pojava superklase ne mora ni postojati.

Relacije "je potklasa" i "je superklasa" su tranzitivne. Saglasno tome, ako je X potklasa klase K, a Y potklasa klase Z, tada je X potklasa klase Z. Pošto potklasa može imati svoje potklase, dolazi se do pojma hijerarhije klasa. Hijerarhija klasa definiše "je vrsta" odnos između klasa. Koncept nasleđivanja kaže da osobine, definisane za neku klasu, nasleđuju sve potklase te klase u hijerarhiji. To je slično konceptu specijalizacije u semantičkim modelima podataka.

Primer 1.7. Neka je klasa Osoba definisana kao sljedeći tip objekta

((IME, Chr), (PRZ, Chr), (DAT_ROD, Date)), i sljedeći skup metoda

[prikaži_ime,prikaži_prezime, prikaži_godine, izmeni_prezime}

Ako se žele imati i objekti, koji reprezentuju zaposlene, potrebno je kreirati klasu Zaposleni, kao potklasu klase Osoba. Objekti klase Zaposleni će, automatski naslediti obilježja IME, PRZ i DAT_ROD. Tipu objekta klase Zaposleni se može dodati obilježje PLATA sa domenom Mone. Nasleđeni skup metoda se može proširiti metodama: zaposli, otpusti, povećaj_platu, prikaži_platu. Ako neki objekat klase Zaposleni primi poruku prikaži_ime, odgovoriće na nju pozajmljujući odgovarajuću metodu od klase Osoba. Poruka prikaži_godine se može zabraniti za klasu Zaposleni.

Postupak definisanja novih klasa, kao potklasa već postojećih, može se produžiti definisanjem klase Programer kao potklase klase Zaposleni. Sada se novoj klasi može pridružiti obilježje PROG_JEZ sa domenom {Prog_jez}, gde je Prog_jez: tip objekta klase sa istim imenom. 0

Postoji sedam aspekata nasleđivanja. To su:

• Nasljeđivanje i podtip: U mnogim objektno - orijentisanim jezicima  se pojmovi nasleđivanja i podtipa posmatraju kao sinonimi. Ipak, korisno ih je posmatrali kao posebne koncepte. Podtip je logička kategorija. Nasljeđivanje je samo mehanizam za programsku realizaciju tog logičkog koncepta.
• Vidljivost nasleđenih obilježja i metoda. Obilježja superklase mogu biti javna i privatna. Privatna obilježja su nevidljiva za potklasu, te ih ne može ni naslediti.
• Nasljeđivanje i inkapsulacija. Vidljivost obilježja narušava Inkapsulaciju. U stvari, postoji konflikt između nasleđivanja i inkapsulacije, jer objekat - pojava potklase, koristi metode superklase, koja za njega predstavlja tuđu klasu. U svakom slučaju, nasljeđivanje je, pre svega, mehanizam za deljenje programskog koda i tipa strukture.
• Postupci specijalizacije. Nasljeđivanje se ostvaruje specijalizacijom postojećih klasa. Klase se specijalizuju proširenjem njihove strukture ili ponašanja. Alternativno, klase se mogu specijalizovati i ograničavanjem skupa obilježja ili skupa metoda postojećih klasa.
• Metaklase. Uvođenjem koncepta metaklase, kao klase, koja opisuje skup klasa, klase tog skupa postaju objekti, pojave metaklase.
• Nasljeđivanje objekata. Većina objektno - orijentisanih jezika podržava nasljeđivanje samo na nivou intenzije, a ne i na nivou ekstenzije. Kod takozvanih prototipskih sistema, objekat, kao pojava potklase, nasljeđuje objekat, pojavu superklase.
• Višestruko nasljeđivanje. U mnogim situacijama je poželjno da jedna potklasa nasledi osobine od više superklasa. To se naziva višestrukim nasljeđivanjem.

Korišćenje klasa i nasleđivanja je veoma bitno za savremeno softversko inženjerstvo. Ponovno korišćenje programa se postiže kreiranjem novih klasa, zasnovanih na obeležjima i metodama postojećih klasa. Treba samo da se specificira kako se nova potklasa razlikuje od svoje superklase, a ne da se definiše kompletno nova klasa. Potklasa nasljeđuje već provjerene metode od svojih superklasa i te metode ne treba ponovo programirati.

Podtipovi

Tip - podtip je semantički odnos između dva tipa objekata. Nasljeđivanje je programski mehanizam, putem kojeg se u objektno - orijentisanim jezicima realizuje semantički koncept podtipa.

Definicija 1.3. Tip T₁ je podtip tipa T₂ ako svaka pojava tipa T₁ predstavlja pojavu i tipa T₂. Tada je i tip T₂ supertip za tip T₁.

Definicija koncepta podtipa ukazuje da se pojava podtipa može koristiti kadgod se u nekoj operaciji, ili u nekoj konstrukciji očekuje pojava supertipa. Ovaj fenomen se naziva principom zamenljivosti.

Primer 1.8. Skup prostih brojeva je podtip skupa prirodnih brojeva. Svaka operacija, definisana za elemente skupa prirodnih brojeva, primenljiva je i na elemente skupa prostih brojeva.

Relacija "je podtip" je:

• po definiciji, refleksivna (svaki tip je sam sebi podtip),

• antisimetrična (ako je tip T₁ podtip tipa T₂ a Tip T₂ podtip tipa T₁ tada je T₁= T₂ ) i
• tranzitivna (ako je T₁ podtip tipa T₂, a T₂  podtip tipa T₃, tada je i T₁ podtip tipa T3). Parcijalni poredak, koji ova relacija uvodi u skup tipova posmatranog sistema, u objektno - orijentisanim jezicima se realizuje putem hijerarhije nasleđivanja. U opštem slučaju, hijerarhija nasleđivanja je usmijereni aciklički graf - latisa.

Odnos tip - podtip se može uspostaviti između:

• skupova,
• strukturiranih tipova i
• metoda.

 

Podskupovi kao podtipovi

Tip je reprezent skupa objekata sa istim osobinama. Saglasno tome, prirodni kandidati za podtipove su podskupovi. Pri tome, tip predstavlja ne samo skup objekata, već i skup operacija nad tim objektima. Naravno, operacije se realizuju putem metoda. Kada je riječ o primjeni operacija na objekte podskupa, mogu se javiti dva slučaja. Jedan je, kada se operacije na objektima podskupa ponašaju na isti način kao te iste operacije (metode) na objektima skupa. Za tip T₁ se kaže da je kompletan podtip tipa T₂, ako je ponašanje operacija isto bilo da je riječ o objektima tipa ili podtipa.

Drugi je slučaj, kada se operacije ponašaju različito pri primjeni na objekte skupa i podskupa. Različito ponašanje se ogleda u činjenici da određena ograničenja, koja se postavljaju na rezultate primjene operacija na objekte tipa nisu zadovoljena pri primjeni istih metoda na objekte podtipa. Rešenje ovog problema se traži u relaksaciji ograničenja pri primjeni metoda na objekte podtipa.

Primer 1.9. Neka je C skup cijelih brojeva, P skup prostih brojeva, u E skup parnih brojeva. Uobičajene aritmetičke operacije u skupu C su: sabiranje, oduzimanje i množenje. Sa formalno - algebarske tačke gledišta, pri opisivanju metoda za ove operacije, treba voditi računa o:

1^o signaturi operatora (nazivu, tipovima podataka operanada i rezultata) i

2^o aksiomama, koje definišu semantiku operacija.

U aksiome spadaju: asocijativnost i komutativnost sabiranja i množenja, distributivnost množenja u odnosu na sabiranje, na primer. Pored ovih algebarskih osobina, operacije sabiranja, oduzimanja i množenja u skupu C posjeduju i važnu osobinu zatvaranja. Ove operacije preslikavaju parove cijelih brojeva u skup cijelih brojeva. Pri primjeni operacija sabiranja, oduzimanja i množenja na objekte skupa P, dolazi do narušavanja ograničenja, koje nameće osobina zatvaranja. Skup P nije kompletan podtip tipa C. Za razliku od njega, skup E je kompletan podtip tipa C.

Rešenje opisanog problema se postiže takvim redefinisanjem metoda u skupu P, da se ograničenje, koje nameće zatvaranje, izostavlja, a signature operacija se definišu kao preslikavanje sa skupa parova prostih brojeva u skup cijelih brojeva.

 

Strukturirani tipovi kao podtipovi

 

Neka su T₁,..., T_n, tipovi, a X₁,..., X_n obilježja. Interpretacija svakog tipa T je njegov domen, u oznaci dom(T). (Interpretacija je skup iz kojeg tip uzima vrijednosti.) Tada je:

((X₁,T₁),...,(X_n,T_n))

tip torka, čiju interpretaciju predstavlja skup torki takvih, da svaka ima, barem za obilježja X₁,...,X_n vrijednosti, redom, iz domena dom(T₁),...,dom(T_n). Treba zapaziti da u interpretaciji tipa mogu postojati i takve torke, koje pored vrijednosti za obilježja X₁,...,X_n posjeduju

i vrijednosti za neka druga obilježja.

 

Primer 1.10. Posmatra se tip Osoba((lME,Niz_chr),(PRZ,Niz_chr),(STAR,Int)). Domen tipa Niz_chr je skup svih nizova karaktera, a domen tipa Int je skup cijelih brojeva. U domen tipa Osoba spadaju i ((lME,Ana),(PRZ,Car),(STAR,23)) i ((IME,Eva),(PRZ,Tot),(STAR,48),(PLT,400)).

 

Definicija 1.4. Neka je "£" relacija "je podtip".

1^o Ako za svako i = 1,...,n, važi T_i£ S_i, tada, za n£ m, važi i

((X₁, T₁,),...,(X_n,T_n,),...,(X_m,T_m))£ ((X₁,S₁),...,(X_n,S_n)).

2^o Ako su S₁={T₁} i S₂={T₂} tipovi i važi T₁£T_2, tada važi i S₁£S₂.

 

Primer 1.11. Saglasno definiciji 7.4. važi

((IME,Niz_chr),(PRZ,Niz_chr),(PLT,{1,...,400})) £ ((IME,Niz_chr),(PLT,Int)).

 

 

Nasljeđivanje i podtipovi

Nasljeđivanje je mehanizam objektno - orijentisanih programskih jezika, putem kojeg se realizuje relacija "je podtip". Međutim, relacija "je podtip" je semantička kategorija. Ona snabdeva skup tipova hijerarhijom ponašanja, a ne vodi računa o implementaciji (tip strukture podataka i metode). Nasljeđivanje je implementaciona kategorija. Potklasa nasljeđuje i tip strukture i metode od svoje superklase. Saglasno tome, nasljeđivanje je uži pojam, pojam sa strožim ograničenjima od relacije "je podtip".

Slika 0.8.

Primer 1.12. Skup, kao tip, je podtip Torbe. Torba je kolekcija, koja može sadržati više jednakih objekata. Međutim, ta dva tipa mogu imati potpuno različite implementacije. Na primer, Skup može imati strukturu niza, a Torba strukturu spregnute liste, slika 7.8.

Zbog različite implementacije struktura podataka, po nazivu iste metode (unija, presek, razlika, upiši, briši, nađi), takođe moraju biti potpuno različito realizovane.

Da je riječ o nasleđivanju, Skup, kao potklasa Torbe, nasledio bi i strukturu i metode od Torbe.

Odnos između relacije nasleđivanja i relacije "je podtip", sličan je odnosu između klase i apstraktnog tipa podataka, slika 7.9. Kao što se apstraktni tipovi podataka realizuju putem klasa, tako se strukture tip - podtip realizuju putem nasleđivanja. Samo nasljeđivanje može biti i selektivno, u smislu da se za potklasu neke osobine superklase mogu zabraniti.

Slika 0.9.

Nasljeđivanje klasa

U objektno - orijentisanim jezicima, nasljeđivanje klasa se eksplicitno deklariše. Putem odgovarajuće sintakse, nova klasa se deklariše kao potklasa neke postojeće klase. Pri tome, ako objektno - orijentisani jezik podržava višestruko nasljeđivanje, jedna klasa može biti deklarisana kao potklasa više superklasa.

Potklasa može naslediti od svojih superklasa:

• obilježja sa njihovom fizičkom strukturom,

• metode, što vodi deljenju i ponovnoj upotrebi programskog koda i

• interface, što znači da objekti potklase mogu pozivati metode superklase.

 

Nasljeđivanje obilježja i metoda donosi određene probleme. U njih spadaju:

• narušavanje inkapsulacije,

• potreba da se nasleđene metode modifikuju u cilju prilagođavanja zahtjevima potklase i

• potreba selektivnog nasleđivanja obilježja i metoda.

Ovim problemima će biti posvećena određena pažnja u narednim tačkama.

 

Nasljeđivanje obilježja

 

Klase opisuju strukturu svojih objekata putem obilježja. U svim objektno - orijentisanim jezicima pojave potklase moraju, za nasleđena obilježja, zadržati isti tip podataka kao i pojave njihovih superklasa.

Neka su za klasu K_n deklarisane komponente (X₁,T₁),...,(X_n,T_n), gde su X₁,...,X_n obilježja, a T₁,...,T_n tipovi podataka. Ako se klasa K_m, sa komponentama (X_n+1,T_n+1),...,(X_m,T_m), deklariše kao potklasa klase K_n objekti klase K_m će sadržati vrijednosti za obilježja X₁,...,X_n, X_n+1,...,X_m. Činjenica da objekat klase K_m sadrži vrijednosti za obilježja klase K_n

ne znači da on te vrijednosti nasljeđuje od nekog objekta klase K_n već da mu se te vrijednosti eksplicitno dodeljuju, prilikom njegovog konstruisanja.

Slika 0.10.

Primer 1.13. Na slici 7.10 su prikazana obilježja klase Osoba, njene potklase Zaposleni i jedan objekat klase Zaposleni.

 

Nasljeđivanje obilježja i metoda dovodi do narušavanja inkapsulacije, jer objekti potklase koriste tuđe metode (metode svoje superklase) za obradu poruka, koje se odnose na nasleđena obilježja. Ova činjenica ima određene negativne posledice. Struktura objekta je definisana putem obilježja klase. Međutim, i obilježja se u implementaciji mogu realizovati putem različitih struktura. Metode striktno zavise od implementacije strukture obilježja. Pojam implementacije strukture obilježja se odnosi na način realizacije fizičke strukture podataka posmatranog obilježja. Izmena implementacione strukture obilježja, povlači izmjenu programskog koda odgovarajućih metoda i modifikaciju svih objekata klase.

Primer 1.14. Domen obilježja može biti, izmešu ostalog i neka klasa tipa skup. U implementaciji, tip objekta klase skup može imati strukturu bilo niza bilo spregnute liste. Programski kod svih metoda za to obilježje značajno zavisi od izbora implementacione strukture. Metoda za traženje elementa u nizu, ne može se primjeniti za traženje tog istog elementa u spregnutoj listi.

 

Potklasa nasljeđuje obilježja sa njihovom implementacionom strukturom od superklase. Pri tome, da bi se postiglo deljenje i ponovno korišćenje programskog koda, objekti potklase pozivaju metode superklase, za obradu poruka, koje se odnose na nasleđena obilježja. Ako se implementaciona struktura nekog obilježja superklase izmeni, moraju se, na odgovarajući način, modifikovati strukture svih objekata potklase, kako bi se na njih mogle primenjivati izmenjene metode superklase. Ovakvim povezivanjem potklase sa superklasom, gubi se i osobina lokalnosti. Promjene u superklasi izazivaju promjene u svim njenim potklasama.

 

Nasljeđivanje metoda

 

U hijerarhiji nasleđivanja, potklase nasleđuju metode, definisane u njihovim superklasama. Pri tome, nasleđene metode postaju dio interfejsa objekata potklase, tako da ih objekti potklase mogu pozivati. Čak i ako metoda pripada superklasi, izvršava se na objektu, koji je poruku primio, a ne na nekom objektu superklase.

 

ALGORITAM IZVRŠENJA PORUKE

 

POSTAVI K←P                   (* inicijalizacija tekuće klase *)

POSTAVl i←0

RADI traženje_M DOK JE i = 0

   AKO JE MÎM_k TADA

      IZVRŠI M

   INAČE

      AKO JE K je koren hijerarhije klasa TADA

         POSTAVI i←1       (*greška, metoda M ne postoji*)

      INAČE

         POSTAVI K←S

      KRAJ AKO

   KRAJ AKO                                          

KRAJ RADI traženje_M

Slika 0.11.

Opšti algoritam izvršenja poruke, poslate objektu potklase, zasnovan je na traženju odgovarajuće metode u hijerarhiji klasa. Traženje počinje od potklase, čijem objektu je poruka upućena. Ako ta klasa ne sadrži traženu metodu, traženje se nastavlja u direktno nadređenoj superklasi. Neka je P potklasa objekta, koji je primio poruku sa nazivom metode M, K tekuća klasa hijerarhije, M_k skup metoda klase K, a S direktno nadređena superklasa tekuće klase K. Na slici 7.11. je prikazan pseudokod algoritma traženja metode M.

 

Nasleđena metoda se, za potrebe potklase, može i modifikovati (redefinisati). Modifikovana metoda superklase postaje dio implementacije potklase, tako da, saglasno algoritmu sa slike 7.11, objekti potklase izvršavaju modifikovanu metodu, čak i ako originalna i modifikovana metoda imaju iste nazive.

 

Primer 1.15. Klasa Skup je potklasa klase Torba. Klasa Torba može, a klasa Skup ne smije sadržati dva jednaka objekta. Metoda upiši_novi_elemenat klase Torba se, za potrebe klase Skup, mora modifikovati tako da se, pre upisa novog elementa, proveri da li takav element već postoji.

 

Neki put je potrebno izvršiti originalnu, a ne modifikovanu metodu. U cilju izbegavanja nejednoznačnosti, zbog istih naziva metoda, u objektno - orijentisanim jezicima se koristi jedan od sledeća dva postupka:

• korišćenje pseudopromjenljive super i

• kvalifikacija metode putem imena klase.

U slučaju korišćenja pseudopromjenljive super, poruka sa frazom super M ukazuje da traženje metode M treba započeti od klase, direktno nadređene klasi, čijem objektu je poruka upućena. Ako se koristi kvalifikacija metode, tada fraza S.M ukazuje da traženje treba započeti od klase S.

 

Preklapanje naziva metoda

 

Jedan od važnih koncepata objektne orijentacije je preklapanje naziva metoda. Preklapanje naziva omogućava da se metode sa istim imenom, ali različitom semantikom i implementacijom primjene na objekte različitog tipa. Međutim, preklapanje naziva nije karakteristično samo za objektno - orijentisane programske jezike.

 

Primer 1.16. U skoro svim programskim jezicima, aritmetičke operacije se koriste za sabiranje, oduzimanje, množenje i deljenje bilo cijelih bilo brojeva u pokretnom zarezu, mada su implementacije tih operacija za cele brojeve i brojeve u pokretnom zarezu potpuno različite. U Pascalu, na primer, "+" znači: sabiranje, povezivanje nizova i uniju skupova.

Kao dalja ilustracija višestruke upotrebe, može poslužiti činjenica da, iako su aritmetičke operacije binarne, one mogu lako da se primjene i kao operacije nad nizovima brojeva. Neka su N₁ i N₂ dva niza od n cijelih brojeva. Tada se može definisati procedura

 

RADI sabiranje "i Î{1,...,n}

   POSTAVI N[i] = N₁[i] + N₂[i]

KRAJRADI sabiranje.

 

Kao rezultat se dobija niz N, čiji elementi predstavljaju zbir odgovarajućih elemenata nizova N₁ i N₂.

 

U konvencionalnim programskim jezicima je preklapanje naziva dozvoljeno samo za neke operacije i to na osnovnim tipovima podataka. U objektno - orijentisanim programskim jezicima se preklapanje naziva dozvoljava za svaku metodu i za proizvoljne tipove podataka. Preklopljene metode treba da se razlikuju bilo po broju bilo po tipovima svojih argumenata. Kada se metoda sa preklopljenim nazivom pozove, objektno - orijentisani sistem bira odgovarajuću implementaciju upoređujući tipove argumenata u poruci sa tipovima argumenata, deklarisanim za metodu. Povezivanje naziva metode sa specifičnom implementacijom se vrši ili statički, prilikom prevođenja, ili dinamički, prilikom izvršavanja programa, što zavisi od objektno - orijentisanog programskog jezika.

 

Dinamičko povezivanje

 

Dinamičko ili kasno povezivanje znači da objektno - orijentisani sistemi povezuje naziv sa kodom metode u trenutku izvršavanja programa, a ne prilikom njegovog prevođenja. Naime, od klase, kojoj pripada objekat - primalac poruke, zavisi i koji od programskih kodova sa istim nazivom će biti pozvan za izvršavanje.

 

Primer 1.17. Posmatra se poruka c + c₁ upućena objektno - orijentisanom sistemu. Da bi utvrdio koja metoda stvarno treba da se primjeni, objektno - orijentisani sistem šalje poruku "+ c₁" objektu c. Objekat c proverava da li se u njegovom interfejsu nalazi metoda sa nazivom "+" i izvršava je. Pri tome, u proceduru te metode je ugrađena specifičnost postupka sabiranja, karakteristična za tip podataka objekta c.

 

Dobra strana dinamičkog povezivanju je da se njegovom primenom izbegava upotreba naredbi uslovnog skoka (tipa AKO ... TADA ... INAČE) u cilju: ispitivanja tipa podataka objekta - primaoca poruke i pozivanja odgovarajućeg programskog koda. Međutim, primjena mehanizama preklapanja naziva i kasnog povezivanja dovodi do degradacije performansi izvršavanja programa.

 

Parametarski polimorfizam

 

Polimorfizam je sposobnost poprimanja različitih oblika. Kada je riječ o programskim jezicima, polimorfizam ukazuje da iste (ne samo po imenu) operacije mogu da se primjene na objekte različitog tipa. Saglasno tome, preklapanje naziva metoda predstavlja jedan oblik polimorfizma. Parametarski polimorfizam je mnogo stroži pojam od preklapanja naziva. Koristi tipove podataka kao parametre, koji se prosleđuju metodi. Ti parametri informišu metodu nad kojim od generičkih tipova podataka ona treba da se izvrši. To dalje znači:

•      da se procedura metode definiše s obzirom na proizvoljan tip podataka T, te da, saglasno tome, može da se primjeni na različite tipove podataka i

•      da se poruka objektu upućuje navođenjem trojke m[T](i), gde je m ime metode, T tip podataka objekta - primaoca poruke, a i njegov identifikator.

U poruci se metodi prosleđuje stvarni tip podataka objekta - primaoca poruke kao parametar. Taj stvarni tip podataka se posmatra kao generički tip podataka, nastao od proizvoljnog tipa podataka T.

 

Primer 1.18. Neka je m ime metode za sabiranje elemenata liste, a cl identifikator objekta - liste sa cijelim brojevima, kao elementima. Sabiranje elemenata liste cl se vrši upućivanjem poruke sa parametrom Int, kao specijalizacijom za tip podataka T

 

m[Int](cl)

 

Ako su elementi liste rl realni brojevi, poruka glasi

 

m[Real](rl)

 

Procedura metode m je pisana za sabiranje elemenata liste, bez obzira na tip podataka tih elemenata. Liste sa cijelim ili realnim brojevima su generički podtipovi liste sa proizvoljnim tipom podataka.

 

Osnovni efekat korišćenja parametarskog polimorfizma je stvarno deljenje programskog koda. U slučaju preklapanja naziva, samo je ime isto za, u suštini, različite procedure.

 

Jedan pristup selektivnom nasleđivanju

 

Najopštiji pristup selektivnom nasleđivanju se realizuje uvođenjem pojmova: javne, privatne i zaštićene osobine (obilježja, metode). Ukratko i bez pretenzija na strogu preciznost, ako je osobina deklarisana kao:

• javna, tada objekat bilo koje klase može da joj direktno: pristupi, da njome manipuliše ili da je pozove,

• privatna, tada samo objekti posmatrane klase mogu da joj direktno: pristupe, da njome manipulišu ili da je pozovu,

• zaštićena, tada samo objekti posmatrane klase i njenih potklasa mogu direktno: da joj pristupe, da njome manipulišu ili da je pozovu.

 

Pri tome. direktno korišćenje osobine se odnosi na pristupanje. manipulisanje i pozivanje samo putem metoda klase, u kojoj je osobina inicijalno deklarisana.

I nasljeđivanje može biti javno, privatno ili zaštićeno. Pri tome, ako je nasljeđivanje:

• javno, javne osobine superklase postaju javne osobine potklase, a zaštićene osobine superklase postaju zaštićene osobine potklase,

• zaštićeno, javne i zaštićene osobine superklase postaju zaštićene osobine potklase,

• privatno, javne i zaštićene osobine superklase postaju privatne osobine potklase. Privatne osobine superklase se ne nasleđuju.

 

Opisani mehanizmi selektivnog nasleđivanja su preciznije razrađeni i ilustrovani u tački 7.6, posvećenoj operacijskoj komponenti objektno - orijentisanog modijela podataka.

 

Nasljeđivanje interfejsa

 

Nasljeđivanjem, metode superklase postaju pristupačne objektima potklase. U suštini, nasljeđivanje metoda znači širenje interfejsa objekata potklase nazivima metoda superklasa.

Nasljeđivanje se koristi za specijalizaciju, za opisivanje specifičnih osobina nekog skupa objekata. Objekti tog skupa predstavljaju modijele takvih entiteta, koji u realnom sistemu predstavljaju podskup nekog drugog skupa entiteta. Modeli entiteta tog drugog skupa predstavljaju objekte superklase. Između skupova entiteta superklase i potklase važi relacija sadržavanja. Kardinalni broj skupa entiteta potklase je manji od kardinalnog broja skupa entiteta superklase. Međutim, nasljeđivanjem, interfejs objekata potklase postaje nadskup interfejsa objekata superklase. Isto važi i za skupove obilježja potklase i superklase. Saglasno tome, nasljeđivanje se može posmatrati ne samo kao specijalizacija, već i kao proširenje.

 

Nasljeđivanje objekata

 

Nasljeđivanje se odnosi samo na klase, ne i na objekte. Između skupova objekata potklase i superklase ne mora važiti relacija sadržavanja, mada je u realnom sistemu svaki entitet potklase i entitet superklase. Objektno - orijentisani jezici ne podržavaju automatski relaciju sadržavanja između skupova objekata superklase i potklase, već zahtjevaju da se o tome eksplicitno vodi računa pri pisanju programa. Slika 7.12 ukazuje da između objekta o_p potklase P i objekta o_s superklase S ne postoji nasljeđivanje.

Slika 0.12.    

 

                                                  

Slika 0.13.

Kada bi nasljeđivanje objekata bilo dozvoljeno, tada bi objekat o_p nasleđivao stanje objekta o_s za sva ona obilježja, koja klasa P nasljeđuje od klase S. Tada bi za svaki objckat o_p klase P postojao jedan objekat o_s klase S, od kojeg bi o_p nasleđivao stanje, slika 7.13. Pri tome, o_p ne bi sadržao podatke, koje sadrži objekat o_s.

 

Primer 1.19. Na slici 7.14 je predstavljena ideja nasleđivanja objekata za slučaj hijerarhije Osoba - Zaposleni - Programer.

Slika 0.14.

Sistemi, koji podržavaju nasljeđivanje objekata, nazivaju se prototipskim sistemima. Osnovna ideja prototipskih sistema je da se, pri projektovanju modijela realnog sistema, prvo definišu prototipski objekti, kao individualni slučajevi, a da se prototipski objekti potom specijalizuju i generalizuju.

 

Višestruko nasljeđivanje

 

Ako svaka klasa ima najviše jednu superklasu, tada je hijerarhija klasa struktura stabla. Neki put je korisno za neku klasu da ima više superklasa. Tako se dolazi do generalizacije hijerarhije klasa, koja se naziva usmijerenim acikličnim grafom. Taj graf se naziva i latisom. U latisi klasa, jedna klasa može nasleđivati osobine od više superklasa. To se naziva višestrukim nasljeđivanjem. Na slici 7.15 je nacrtana jedna latisa klasa. Da je riječ o latisi, a ne o stablu klasa, govori činjenica da klasa R ima dvije superklase P i O.

Slika 0.15.

Primer 1.20. Posmatraju se klase: Stanovnik, Zaposleni, Student i Zaposleni_Student. Klasa Zaposleni_student ima dvije direktno nadređene i jednu tranzitivnu superklasu. Direktno nadređene klase su: Zaposleni i Student. Zaposleni_Student nasljeđuje osobine od sve tri klase. Na slici 7.16 je prikazana ova hijerarhija klasa i jedna pojava klase Zaposleni_Student.

 

 

Slika 0.16.

Identitet objekta

 

U objektno - orijentisanom modijelu podataka, svaki objekat dobija identitet, koji mu je permanentno pridružen i ostaje nepromenjen, bez obzira na promjene stanja objekta. Identitet je interna osobina objekta. Namena mu je da reprezentuje objekat, bez obzira na to kako se objektu pristupa, šta sadrži ili gde se nalazi. Identitet objekta je pojam, koji ne zavisi od hardvijersko - softverskog okruženja i načina realizacije objekta.

Kada se kaže da je namena identiteta da reprezentuje objekat, želi se ukazati da je cilj uvođenja identiteta objekta uvođenje takve karakteristike, koja odražava onu bitnost objekta, kakvu posjeduju i realni entiteti.

 

Primer 1.21. Svaka osoba, tokom vremena prolazi kroz niz strukturalnih promena. Rađa se, završava školu, zapošljava se. Stiče nove osobine, kao što su: supružnik, deca, položaj na poslu. Može doći do promjene imena, prezimena, broja zdravstvene knjižice. Ipak, pri svim tim promenama, ostaje nešto što je jedinstveno, karakteristično za svaku osobu, njen identitet, njena bitnost.

 

Identitet objekta pridružuje objektu, kao modijelu realnog entiteta, osobinu bitnosti. Pored ovog, semantičkog značenja, identitet predstavlja i mehanizam za povezivanje objekta sa drugim objektima. Jedan objekat postaje komponenta drugih objekata tako, što se njegov identitet javlja kao Vrijednost određenog obilježja tih drugih objekata.

Ako bi se želeli koristiti samo osnovni tipovi podataka za vrijednosti obilježja objekta, a ne i identitet objekta, tada postoje dva rješenja. To su:

• replikacija podataka i

• strani ključ, kao u relacionom modijelu.

Oba rješenja imaju određene nedostatke. Korišćenje replikacije podataka značajno komplikuje ažuriranje, jer predstavlja potencijalni izvor nekonzistentnosti podataka. Neka su o₁ i o₂ objekti klase, čiji tip objekta sadrži komponentu (X,T). T je tip objekta neke druge klase. Neka je, dalje, t objekat tipa T i nekn važi da objekti o₁ i o₂ imaju i treba da imaju iste X vrijednosti (o₁X=t Ù o₂X=t). Ako se ažuriranjem izmeni X Vrijednost, recimo, objekta o₁, mora se, na isti način, izmeniti i X Vrijednost objekta o₂. Ako se ta izmena ne izvrši, baza podataka će ostati nekonzistentna. Ovakva, višestruka ažuriranja predstavljaju ozbiljan problem u praksi.

 

Primer 1.22. Neka je Zaposleni = ((Ime,Chr),(PRZ,Chr),(RAD_MES,Radno_Mesto)) tip objekta, čije obilježje RAD_MES ima, kao domen, klasu RadnoMesto. Komponente tipa objekta Radno_Mesto su (NAZRM,Chr) i (BRBOD,Int). Ako bi se koristila replikacija, tada bi dva objekta klase Zaposleni imala sledeću strukturu:

 

((IME,Ana),(PRZ,Tot),(NAZRM,programer),(BRBOD,400)) i

((IME,Aca),(PRZ,Zec),(NAZRM,programer),(BRBOD,400)).

 

Ako, u realnom sistemu dođe do izmjene broja bodova za radno mesto programer, tu izmjenu treba sprovesti u svim objektima klase Zaposleni, za koje važi NAZRM = programer.

 

Rešenje, zasnovano na korišćenju stranog ključa, donosi sledeća dva problema. Jedan je posledica činjenice da se sada podaci o jednom realnom entitetu nalaze u više objekata. Povezivanje tih podataka zahtjeva primjenu operatora prirodnog spajanja, a prirodni spoj je operacija, čije izvršavanje zahtjeva dosta vremena. Drugi problem leži u činjenici da se vrijednosti ključa ne smijeju modifikovati. To dalje eliminiše mogućnost korišćenja prirodnih obilježja klase entiteta u ulozi ključa.

 

Primer 1.23. Obilježje NAZRM se ne bi smijelo proglasiti ključem tipa objekta Radno_Mesto, jer se nazivi konkretnih radnih mesta u realnom sistemu mogu, tokom vremena mijenjati. Te izmjene bi dovele do značajnih intervencija u bazi podataka.

 

Uvođenjem identiteta objekta, ovi problemi se eliminišu. Prednosti identitetu objekta i direktne reprezentacije kompleksnih objekata, opisani su u narednom tekstu. Modeli, koji podržavaju identitet objekta. nazivaju se "objektno - orijentisanim", mada se taj termin, strogo govoreći, odnosi samo na one modijele koji podržavaju kompleksne objekte i inkapsulaciju. Modeli, koji ne podržavaju identitet objekta, nazivaju se orijentisanim na vrijednosti.

 

Pojam identiteta objekta

 

Objekti se grade od objekata. Primitivni objekti, kao elementi osnovnih tipova podataka. predstavljaju polazne gradivne elemente za formiranje kompleksnijih objekata. Klase osnovnih tipova podataka su, po pravilu, ugrađene u objektno - orijentisane programske jezike i druge objektno - orijentisane sisteme, što znači da ih ne treba posebno deklarisati. Te klase, po pravilu, nemaju svojih obilježja. Primitivnim objektima se ne pridružuju identiteti. Smatra se da primitivni objekti identifikuju sami sebe, putem svoje vrijednosti. Identitet neprimitivnog objekta se realizuje pridruživanjem jedinstvenog identifikatora.

 

Za operacije sa identitetima objekata, uvode se dva osnovna predikata. To su:

• predikat x==y, za proveru identičnosti objekata x i y i

• predikat x=y, za proveru jednakosti stanja objekata x i v.

 

Pri tome, identičnost dva objekta znači da imaju isti identitet i isto stanje, a jednakost stanja ne implicira jednakost identiteta.

 

Primer 1.24. Broju 3, kao elementu klase Int, se identitet ne dodeljuje, jer ne mogu postojati dva primitivna objekta 3. Oba suda, 3==3 i 3=3, su istinita.

Međutim, ako se objektu o₁ = ((IME,Aca),(PRZ,Zec)) dodeli identifikator i₁, a objektu o₂ = ((IME,Aca),(PRZ,Zec)) dodeli identifikator i₂, tada je o₁==o₂ neistinit sud, a o₁=o₂ istinit sud.

 

Jedna od osnovnih pretpostavki objektno - orijentisanog modijela podataka je da postoji neograničen skup identifikatora I={i₁,i₂,...}, takav da važi:

1° Samo jedan identifikator iÎI se pridružuje svakom neprimitivnom objektu, 2° Identifikator iÎI se generiše i pridružuje objektu u trenutku njegovog nastanka i ostaje mu pridružen bez obzira na izmjene njegovog stanja.

3° Svaki identifikator se može pridružiti jednom i samo jednom objektu. Ako je identifikator generisan, on mora biti pridružen nekom objektu. Objekat i njegov identifikator se ne mogu posmatrati odvojeno. Identifikator jedinstveno identifikuje objekat i ostaje mu pridružen i traje dok objekat postoji.

 

Svaki objekat posjeduje sledeće tri osobine:

• objekat je pojava neke klase, čime je određen njegov tip,

• objektu je pridružen identifikator, putem kojeg se realizuje pojam identiteta objekta i

• objekat posjeduje stanje, u notaciji (X₁,i₁),...,(X_n,i_n)), gde je X obilježje klase, a i ili identifikator ili primitivni objekat. Ako je o objekat tipa kolekcija, njegovo stanje je {i₁,i₂,...,i_m}, gde je i identifikator objekta u kolekciji.

 

Postoji više tehnika za grafičku reprezentaciju fizičke strukture objekta. U ovom tekstu će se koristiti tehnika usmijerenih acikličnih grafova. Svaki objekat predstavlja se kao čvor sa pridruženim identifikatorom, ili pridruženom vrednošću primitivnog objekta. Potezima se pridružuju nazivi obilježja.

 

Primer 1.25. Neka je objektu ((IME,Ana),(PRZ,Ban)) pridružen identifikator i₁, objektu ((PRED,Matematika),(OCE,8)) identifikator i₂, ((PRED,Fizika),(OCE,9)) i₃, a objektu - skupu {i₂,i₃}, identifikator i₄. Objekat sa podacima o studentu Ani, upisanoj u drugi semestar i o njenim ispitima, ima oblik

i₅((IME_I_PRZ,i₁),(SEM,2),(ISPIT, i₄)).

 

Posmatranom složenom objektu je pridružen identifikator i₅. Identifikatori predstavljaju vrijednosti svih onih obilježja, čiji domeni sadrže neprimitivne objekte. Na slici 7.17 prikazana je moguća geometrijska predstava fizičke strukture objekta Ana.

Slika 0.17.

Zahvaljujući postojanju identifikatora objekta, dozvoljeno je definisati dva objekta, koji uzajamno sadrže jedan drugog kao komponente.

 

Primer 1.26. U primeru 7.5 definisani su tipovi objekata:

TipKupca=((NAZIV,Chr),(ADRESA,Chr),(STANJE_RAC,Int),(PORUDŽBINE, {TipPorudžbine})) i

TipPorudžbine=((BRP,Int),(KUPAC,TipKupca),(SADRŽI,{StavkaPorudžbine}).

 

Na prvi pogled, ova cirkularna veza izmeću pojava dva tipa objekta je nedozvoljena, jer jedan objekat treba da predstavlja sam svoju komponentu. Međutim, zahvaljujući postojanju identifikatora objekt, i takve strukture su regularne. Pojava tipa objekta TipKupca sadrži, uz obilježje PORUDŽBINE, identifikator - pokazivač na jedan objekat tipa kolekcija. Taj objekat tipa kolekcija sadrži identifikatore - pokazivače na one pojave klase TipPorudžbine, koje je izvršio posmatrani kupac. Svaka od ovih pojava klase TipPorudžbine, sadrži, uz obilježje KUPAC, identifikator posmatrane pojave tipa objekta TipKupca.

 

U objektno - orijentisanim programskim jezicima, identifikator je pokazivač -memorijska adresa lokacije, u kojoj se objekat nalazi. Pokazivač je jedna od mogućih implementacija identiteta. Treba naglasiti da između pojma identiteta objekta i njegove implementacije, postoji fundamentalna razlika. Identitet je semantički koncept.

 

Postupci za implementaciju identiteta objekta

 

Postoji više postupaka za realizaciju identiteta objekta. U njih spadaju:

• virtuelne i fizičke adrese,

• korisnički nazivi i

• surogati.

 

Identifikator u obliku virtuelne ili fizičke adrese predstavlja brzo, ali nefleksibilno rešenje. Brzo, jer se na osnovu adrese brzo dolazi do objekta. Nefleksibilno, jer svaka promena lokacije za smiještaj objekta, zahtjeva i promenu identifikatora. Sve ostale tehnike zahtjevaju primjenu indirektnog pristupa objektu. Indirektni pristup objektu je posledica potrebe postojanja:

• tabele sa parovima (identifikator,adresa), za objekte u operativnoj memoriji i

• indeksa (stabla traženja) sa parovima (identifikator,adresa), za objekte na eksternoj memoriji.

Postupci, koji traže indirektni pristup su fleksibilniji, jer promena lokacije ne dovodi do promjene identifikatora, ali zahtjevaju najmanje dva pristupa pri traženju objekta. Najmanje jedan pristup tabeli ili stablu traženja i jedan pristup samom objektu.

Pobrojana rješenja za realizaciju identiteta objekta se razlikuju još i po tome što adrese i korisnički nazivi predstavljaju identifikatore, spolja pridružene objektu. Nisu sastavni dio objekta. Surogat predstavlja sastavni dio objekta, ali je to sistemski generisan identifikator, koji je nezavisan od stanja objekta. Surogat ne treba poistovetiti sa ključem u relacionom modijelu podataka.

 

Adresa kao identifikator

 

Korišćenje adrese u svojstvu identifikatora predstavlja, verovatno, najjednostavniji postupak realizacije identiteta objekta. Generisanje novih objekata se vrši dinamički u operativnoj memoriji, pri izvršavanju objektno - orijentisanog programa. Kada neka klasa dobije naredbu da generiše novi objekat, ona prvo rezerviše memorijski prostor - lokaciju za smiještaj tog objekta, a adresu početka te lokacije proglasi za identifikator objekta. Nakon toga, objekat se može preneti na eksternu memoriju, gde ostaje trajno memorisan. Na eksternoj memoriji, objekat dobija drugi identifikator. Taj identifikator je relativna ili apsolutna adresa lokacije na eksternoj memoriji. Prilikom učitavanja objekta u operativnu memoriju, vrši se njegova transformacija iz jedne u drugu reprezentaciju. Ta transformacija znači i učitavanje i transformaciju svake komponente složenog objekta. Ne treba ispustiti iz vida da objekat, kao direktne komponente, sadrži samo primitivne objekte, a umjesto neprimitivnih objekata, sadrži njihove identifikatore.

 

Korisnički nazivi kao identifikatori

 

Dodijela korisničkih naziva je najčešći postupak pridruživanja identifikatora objektima. Jedno rešenje ovog postupka je da se svakom objektu dodeli jedinstveni naziv i da taj naziv bude jedinstven, bez obzira na klasu objekta. Taj naziv postaje identifikator objekta. Ovakav postupak dodijele identifikatora je fleksibilniji od postupka sa korišćenjem adrese, ali uvodi potrebu indirektnog pristupa. Indirektni pristup se vrši putem takozvane tabele objekata, koja sadrži parove (identifikator, adresa).

Slika 0.18.

Primer 1.27. Neka je Zaposleni = ((IME_I_PRZ,Ime_i_prz),(PLT,400),(ADR, Adresa)) tip objekta klase Zaposleni, gde su Ime_i_prz i Adresa, takođe klase. Neka je, pri generisanju objekta sa podacima o zaposlenom Aci Caru, dodeljen identifikator:

• Aca odgovarajućem objektu klase Zaposleni,

• iAca odgovarajućem objektu klase Ime_i_prz i

• aAca odgovarajućem objektu klase Adresa.

 

Tada bi tabela objekata i sadržaji odgovarajućih lokacija u operativnoj memoriji, mogli da se predstave kao na slici 7.18. Na slici su adrese predstavljene kao potezi ka početku lokacije.

 

Neki objektno - orijentisani jezici, kao C++, koriste i adrese i korisničke nazive za realizaciju identiteta objekta. Nazivi se koriste pri generisanju objekata, a njihove adrese pri izgradnji kompleksnih objekata. Ako je objekat komponenta nekog drugog objekta, tada taj drugi objekat sadrži njegovu adresu, kao referencu na svoju komponentu.

Korišćenje naziva u svojstvu identifikatora, može dovesti do dodijele dva različita naziva istom objektu. Do takve situacije može doći u slučajevima kada isti objekat ima više uloga. Sama dodijela različitih naziva se realizuje putem odgovarajuće naredbe programskog jezika. Jedini način da se kasnije ustanovi da je riječ o istom objektu je primjena predikata za proveru identičnosti i jednakosti.

 

Primer 1.28. Objektu sa podacima o jednom studentu može biti dodeljen naziv s₁, kada se on posmatra kao najbolji student na drugoj godini, a naziv s₂, kao studentu koji se prijavio na konkurs za dodijelu stipendija. Primjena testa jednakosti, s₁=s_2, je jedini način da se utvrdi da je riječ o istom realnom entitetu.

 

Surogati

Surogati su globalno jedinstveni identifikatori. Za njih je karakteristično:

• da ih generiše objektno - orijentisani sistem,

• da su potpuno nezavisni bilo od stanja bilo od adrese objekta,

• da predstavljaju integralni dio objekta,

• da se mogu koristiti za pristup objektima na eksternom memorijskom uređaju.

Surogat se uključuje u objekat kao Vrijednost specijalnog obilježja. Pošto se surogat memoriše zajedno sa objektom, objekat se može premeštati iz jedne lokacije u drugu, kopirati i replicirati, a da se njegov identifikator ne promeni. Međutim, i korišćenje surogata dovodi do potrebe indirekcije u adresiranju.

Primer 1.29. Na slici 7.19 je data geometrijska reprezentacija tabele objekata i sadržaja lokacija u operativnoj memoriji, za slučaj primjene surogata kao identifikatora objekta klase Zaposleni iz primera 7.23.

 

Pojam surogata ne treba poistovećivati sa pojmom ključa relacionog modijela podataka, mada postoje određene sličnosti. Razlike su u sledećem:

• Vrijednost ključa određuje korisnik i može joj pristupiti,

• Vrijednost ključa je jedinstvena samo u okviru jedne relacije - tabele,

• Vrijednost surogata generiše objektno - orijentisani sistem, krajnji korisnik tu Vrijednost ne može videti i

• Vrijednost surogata je globalno, a ne lokalno jedinstvena.

 

Smatra se [KA] da primjena surogata, kao identifikatora, predstavlja najbolje rešenje za realizaciju pojma identiteta objekta.

Slika 0.19.

Integritetna komponenta objektno-orijentisanog modijela podataka

 

Putem transakcija, sistem za upravljanje bazom podataka preslikava jedno konzistentno stanje baze podataka u drugo. Uslovi konzistentnosti baze podataka se obično izražavaju putem predikata, koje treba da zadovolji tekuće stanje baze podataka. Predikati se definišu i za objekte i za obilježja. Svi uslovi integriteta baze podataka relacionog modijela podataka, kao što su:

• nula Vrijednost,

• integritet entiteta,

• referencijalni integritet i

• integritet domena

treba da budu zadovoljeni i u objektno - orijentisanoj bazi podataka.

 

Nula Vrijednost

Ograničenje posedovanja nula vrijednosti za određena obilježja se, u objektno -orijentisanim sistemima:

• ili navodi eksplicitno u deklaraciji strukture tipa objekta klase,

• ili rešava u okviru metoda za konstruisanje objekata klase.

 

Deklarisanje u okviru strukture tipa objekta klase se vrši, ako objektno - orijentisani jezik takvo deklarisanje podržava. Sintaksa te deklaracije zavisi od objektno - orijentisanog programskog jezika. Koriste se fraze tipa "required" ili "not null".

Ako se pitanje nula vrijednosti rešava u okviru metoda za konstruisanje objekata klase, tada se za konstruisanje objekata uvodi više metoda. Jedna od njih generiše objekte sa vrijednostima svih obilježja klase, a druge generišu objekte sa vrijednostima samo nekog pravog podskupa skupa obilježja klase. Samo obilježja, koja se inicijalizuju navođenjem nekih vrijednosti u svim metodama za konstruisanje objekata klase, ne mogu imati nula vrijednosti.

 

Primer 1.30. Metode za konstruisanje objekata su precizno i detaljno obrađene u tačkama 7.6.1 i 7.6.3. Na ovom mestu se samo neformalno ilustruje postupak za konstituisanje objekata sa nula vrijednostima nekih obilježja.

Posmatra se tip objekta Osoba =((MBR,Int),(IME,Chr),(PRZ,Chr),(KTL,Int)), gde jedino obilježje KTL (broj kućnog telefona) može imati nula Vrijednost. Tada bi postojale dvije metode za konstruisanje objekata tipa Osoba. Jedna, oblika Osoba(int, chr, chr, int), bi zahtjevala inicijalizaciju svih obilježja klase. Druga, oblika Osoba(int, chr, chr), bi zahtjevala inicijalizaciju samo obilježja MBR, IME i PRZ, pri konstruisanju objekta. U telu druge metode bi se moralo precizno definisati kakav tip podataka i koju Vrijednost treba objektno - orijentisani sistem da upiše kao nula Vrijednost za obilježje KTL. Pošto se objekti klase Osoba mogu konstruisati samo primenom jedne od ovih metoda, svaki od objekata bi imao ne nula vrijednosti za obilježja MBR, IME i PRZ.

 

Integritet entiteta

 

Identitet objekta je jedinstven, ali, po pravilu, nije pod kontrolom korisnika. Identifikator, kao implementacija identiteta objekta, ne nosi nikakvu dodatnu semantiku o objektu. Ne predstavlja ni uobičajeno sredstvo za traženje određenog objekta u velikoj bazi podataka. Za korisnika je mnogo pogodnije da vrši traženje na osnovu vrijednosti ključa.

Identitet objekta ne predstavlja zamenu za ključ, koji definiše korisnik. Zbog toga, bez obzira na postojanje identiteta objekta, često je potrebno obezbediti da vrijednosti nekog obilježja, recimo X, imaju jedinstvene i ne nula vrijednosti u ekstenziji klase.

Postoje barem dva pristupa rešavanju problema integriteta entiteta u objektno-orijentisanim sistemima. Prema jednom, definisanje integriteta entiteta, kao ograničenja, vrši se navođenjem fraza tipa "unique" i "required" pri opisivanju domena obilježja. Međutim, objektno - orijentisani jezici, često, ne podržavaju takve fraze, tako da se definisanje integriteta entiteta rešava u okviru metoda za konstruisanje objekata klasa.

Pošto klasa nema mehanizam za upravljanje svojom ekstenzijom, kontrola integriteta entiteta, prema drugom postupku, zahtjeva generisanje odgovarajućeg objekta tipa kolekcija, koji sadrži informaciju o ekstenziji posmatrane klase i omogućava pristupanje svakom objektu klase. Pristupanje svakom objektu klase je potrebno da bi se, pri generisanju novog objekta, moglo proveriti da li već postoji objekat, koji ima istu X Vrijednost.

Pošto se u objektno - orijentisanom modijelu podataka ne postavljaju tako stroga ograničenja u odnosu na obilježje, koje bi igralo ulogu ključa u nekom drugom modijelu podataka, vrijednosti tog obilježja se mogu modifikovati. U relacionom modijelu podataka, jedan razlog zabrane modifikovanja vrijednosti ključa leži u činjenici da Vrijednost ključa igra ulogu identiteta objekta (torke). Drugi razlog predstavlja potreba očuvanja važnosti referencijalnog integriteta. Kao što je pokazano u narednoj tački, u objektno - orijentisanom modijelu podataka se referencijalni integritet rešava putem identiteta objekta, tako da ni uslov referencijalnog integriteta ne predstavlja razlog za zabranu izmjene vrijednosti obilježja, koje igra ulogu ključa.

 

Referencijalni integritet

 

Kada je riječ o kompleksnim objektima, identitet objekta obezbjeđuje uslov referencijalnog integriteta. Komponente neprimitivnog objekta sadrže ili primitivne objekte ili identifikatore drugih objekata. Identifikatori drugih objekata predstavljaju direktnu realizaciju referencijalnog integriteta. U ovom slučaju. referencijalni integritet je posledica same strukture objekta, tako da nema potrebe da se definiše poseban mehanizam za njegovu kontrolu.                                                                      

 

Da bi se izbegli problemi pri brisanju objekta - komponente ili takva promena stanja neprimitivnog objekta, pri kojoj Vrijednost referentnog obilježja dobija nedefinisanu Vrijednost, potrebno je predvideti da referentno obilježje može imati i nula Vrijednost.

 

Primer 1.31. Neka je dat tip objekta Zaposleni =((IME_I_PRZ, Ime_i_prz), (PLT,Int),(RAD_MES,Radno_Mesto)). Da bi se izbegli problemi sa neraspoređenim radnicima, pri deklarisanju obilježja RAD_MES, ne treba zabraniti nula vrijednosti.

 

Kontrola referencijalnog integriteta između objekata potklase i objekata superklase, u objektno - orijentisanom modijelu podataka predstavlja otvoreno pitanje. Nasljeđivanje objekata ne postoji, te nije podržano ni preslikavanje sa skupa objekata potklase u skup objekata superklase. Čak i ako postoji objekat superklase, koji bi prema svom stanju

 

mogao biti slika posmatranog objekta potklase, to su dva objekta sa različitim identifikatorima. Jednakost stanja objekta superklase i dijela stanja objekta potklase se može proveriti, ali obezbediti modifikaciju jednog pri promeni drugog, nije jednostavan zadatak.

Sljedeći postupak predstavlja mogućno rešenje problema kontrole referencijalnog integriteta između objekata potklase i objekata superklase. Neka je Sup superklasa, Pot potklasa, a Ekst_Sup objekat tipa kolekcija, koji sadrži objekte superklase. Neka je XZ skup obilježja klase Sup, YZ skup obilježja klase Pot, gde je Z skup zajedničkih obilježja. U cilju sprovođenja kontrole integriteta, uvodi se nova klasa Veza sa tipom objekta ((SUP,Sup), (POT,Pot)), čiji objekti o zadovoljavaju uslov o.SUP[Z] = o.POT[Z]. Drugim riječima, jedan objekat klase Veza sadrži identifikatore po jednog objekta klase Pot i jednog, njemu odgovarajućeg, objekta klase Sup. Takođe se uvodi novi objekat Ekst_Veza tipa kolekcija, koji sadrži identifikatore objekata tipa Veza. Pri generisanju svakog novog objekta o_p klase Pot, proverava se da li objekat Ekst_Sup već sadži identifikator objekta o_s, takvog da važi O_p.Z = o_s.Z. U slučaju potvrdnog odgovora, generiše se odgovarajući objekat klase Veza, a identifikator tog objekta se uključuje i u objekat Ekst_Veza. Inače, prvo se generiše novi objekat klase Sup, pa objekat klase Veza. Objekat Ekst_Veza obezbjeđuje preslikavanje sa skupa objekata potklase u skup objekata superklase, a koristi se:

• pri modifikaciji nekog obilježja iz Z, bilo u o_p, bilo u o_s da bi se ista izmena izvršila i u onom drugom i

• pri brisanju objekta o_s klase Sup, da bi se izbrisao i odgovarajući objekat o_p klase Pot, kada se briše i objekat (i_os,i_op) u klasi Veza.

                                      

Slika 0.20.

Objekti Ekst_Sup i Ekst_Veza su potrebni kao mehanizmi za upravljanje ekstenzijama klasa Sup i Veza. Na slici 7.20 je prikazana ideja opisane realizacije kontrole referencijalnog integriteta, a na slici 7.21 je dat pseudokod opisanog postupka obezbeđenja uslova za kontrolu referencijalnog integriteta. Pri tome, pretpostavka je da metoda za konstruisanje

objekata klase Sup upisuje identifikator novog objekta u objekat Ekst_Sup, a metoda za generisanje objekata klase Veza, upisuje identifikator novog objekta u objekat Ekst_Veza.

 

POSTUPAK OBEZBEĐENJA REFERENCIJALNOG INTEGRITETA

 

KONSTRUIŠI novi objekat (y, z) klase Pot

POSTAVI idpot = identifikator novog objekta

POSTAVI int <- 0 (*int je indikator uspješnosti traženja*)

RADI traženje_objekta_tipa_Sup "iÎEkst_Sup DOK JE int = 0

   AKOJE O_idpot.Z = O_i.Z TADA (*o_i je objekat klase Sup sa identifikatorom i*)

      POSTAVI int <- 1

      POSTAVI idsup = i

   INAČE

   KRAJ AKO

KRAJ RADI traženje_objekta_tipa_Sup

AKO JE int = 0 TADA

   KOSTRUIŠI novi objekat (x, z) klase SUP

   POSTAVI idsup = identifikator novog objekta

INAČE

KRAJ AKO

KONSTRUIŠI novi objekat (idpot, idsup) klase Veza

 

Slika 0.21.

Integritet domena

 

Integritet domena je specifikacija određenih ograničenja, koja vrijednosti obilježja treba da zadovolje. Ta ograničenja mogu bili kompleksnija od onih, opisanih u drugoj glavi ove knjige, jer domen u objektno - orijentisanom modijelu podataka može biti klasa sa proizvoljno kompleksnom strukturom objekata.

Jedan od načina za kontrolu integriteta domena u objektno - orijentisanom modijelu podataka je da se definiše takva potklasa neke postojeće klase, čiji objekti će uzimati samo dozvoljene vrijednosti, pa da se ta potklasa proglasi za domen obilježja.

 

Primer 1.32. Neka je dato obilježje OCE i ograničenje 5£OCE£10. Tada se može definisati klasa Ocena, kao potklasa klase Int, tako da objekti iz klase Ocena uzimaju vrijednosti iz segmenta [5,10].

 

Operacijska komponenta objektno - orijentisanog modijela podataka

 

U prvoj polovini devedesetih godina, veći broj objektno - orijentisanih programskih jezika je ušao u svakodnevnu upotrebu. U te jezike svakako spadaju: Smalltalk, C++, Visual Basic,... Svi ti jezici se, u preovlađujućem obimu, koriste baš kao programski jezici, a ne kao jezici podataka za deklarisanje struktura i za manipulisanje objektno - orijentisanim bazama podataka. Za takve primjene, koje zahtjevaju formiranje i korišćenje baze podataka na eksternom memorijskom uređaju, potrebno je uvesti određena proširenja, koja se, pre svega odnose na mehanizme za razmenu podataka između programa i baze podataka. U trenutku pisanja ove knjige, ta proširenja se, još uvek nalaze u eksperimentalnoj ili razvojnoj fazi.

Od pomenutih programskih jezika, C++ se nameće kao jedan od ozbiljnih kandidata, koji će poslužiti za realizaciju operacijske komponente objektno - orijentisanih baza podataka. Zbog toga je izvršeno opredijelenje da se putem njegove sintakse ilustruju postupak za deklarisanje i realizaciju koncepata objektno - orijentisanog modijela podataka.

Jezik C++ je danas svakako najpopularniji objektno-orijentisani jezik opšte namene. To je veoma moćan, fleksibilan jezik, udoban za programiranje. Programjeri su ga veoma rado i brzo prihvatili, baš kao i njegovog prethodnika - jezik C. Nažalost, C++ nije nimalo jednostavan jezik. Ponekad se čoveku učini da je to jezik bez granica i da ga ne može lako sagledati u cijelini. Jezik C++ nije čisti objektno-orijentisani programski jezik koji bi korisnika "naterao" da ga koristi na objektno-orijentisani način. Može se koristiti i kao "malo bolji C". Treba ga koristiti kao sredstvo za implementaciju objektno-orijentisanog modijela i kao smijernice za razmišljanje o problemu.

U cilju ilustracije operacijske komponente objektno-orijentisanog modijela podataka nije neophodno poznavati sve detalje jednog tako složenog jezika kao što je C++, već je potrebno pravilno upotrebljavati one delove koji su u datom trenutku potrebni. Potrebno je da čitalac uoči šta se sve može uraditi u jeziku C++ i kako se to radi, bez insistiranja na sintaksi, kada za to ne postoji potreba. Cilj ove tačke nije programiranje u jeziku C++, pa se, u skladu sa tim, neće detaljno razmatrati organizacija programa, povezivanje i osnovni koncepti jezika C++, a posebno oni nasleđeni iz jezika C. Ta pitanja se razmatraju u literaturi, na primjer[Str,Mi]. Razmatranja će se ograničiti samo na objektno-orijentisane koncepte jezika C++, kao primjeroperacijske komponente objektno - orijentisanog modijela.

Najvažniji objektno-orijentisani koncepti jezika C++ opisani i ilustrovani u ovoj tački su:

• klase,

• preklapanje operatora,

• nasljeđivanje i

• generički mehanizam.

 

U primjerima, neki dijelovi programskog teksta su samo skicirani i ispisani na srpskom jeziku (kurzivom) tako da se mogu lako razlikovati od ostalog teksta na engleskom jeziku, koji predstavlja gotov programski kod. Ključne riječi jezika C++ su, u primjerima, pisane masnim slovima.

 

Klase

 

Klasa je osnovna organizaciona jedinica programa u objektno-orijentisanom jeziku C++. Konceptom klase se u jeziku C++ realizuju principi apstrakcije i inkapsulacije. Klasom se definiše tip u programu. Klasa se definiše navođenjem deklaracije klase, kojom se u program uvodi ime klase kao ime novog, korisničkog tipa. Grupisanjem podataka i funkcija u jedinstvenu strukturi koja realizuje novi tip, podržava se princip apstrakcije tipa, kao jedinstvene strukture podataka i operacija nad njom.

 

Primer 1.33. U primeru 7.5 uvedena je klasa Osoba, čije pojave imaju svojstva: ime, prezime, zanimanje i platu i koja se mogu predstaviti obeležjima IME, PRZ, ZAN, PLT. Svaka pojava klase treba da odgovori na akciju, koja traži da se osoba zaposli, da se osobi poveća plata, da se osobi prikaže plata, da se osoba predstavi (prikaže osnovne podatke o sebi) ili da se osoba penzioniše. Ove akcije se mogu predstaviti funkcijama Zaposli, Povećaj_platu, Prikaži_platu, Prikaži_podatke i Penzioniši. U jeziku C++ ova klasa može se predstaviti na sljedeći način:

 

// Deklaracija klase

class Osoba {

   tip_podataka_koji_sadrži_ime_Osobe IME;

   tip_podataka_koji_sadrži_prezime_Osobe PRZ;

   tip_podataka_koji_sadrži_zanimanje_Osobe ZAN;

   tip_podataka_koji_sadrži_platu_Osobe PLT:

public:

   funkcija Zaposli();

   funkcija Povecaj_platu():

   funkcija Prikazi_platu();

   funkcija Prikazi_podatke();

   funkcija Penzionisi();

};

 

U narednom dijelu teksta objašnjavaju se koncepti i ključne riječi jezika C++, koji su uvedeni u prethodnom primeru. Na samom početku primera prikazana je upotreba komentara u jeziku C++. Svi znaci iza duple kose crte (//), pa do kraja ređa predstavljaju komentare programera i ne utiču na rad programa.

Ključna riječ class jezika C++ označava da se počinje sa deklaracijom klase. Deklaracija u jeziku C++ predstavlja iskaz kojim se neko ime uvodi u program. Time se prevodiocu "objašnjava" šta predstavlja ime koje se njime uvodi i omogućava mir se da zna kako se to ime može koristiti u programu. Deklaracija klase uvodi ime - identifikator klase u program pomoću riječi koja sledi iza ključne riječi class. Sama deklaracija klase nalazi se izmedu para vitičastih zagrada ({}) i obuhvata obilježja i metode. Deklaracija obuhvata "spoljni" izgled klase odnosno interfejs klase. Elementi, navedeni u deklaraciji klase, nazivaju se članovima klase. Metode se u jeziku C++ realizuju funkcijama. Funkcija, koja je dio klase, naziva se funkcija članica. Deklaracija klase završava se znakom tačka-zarez (;). Ova deklaracija ne obuhvata specifikaciju šta treba da uradi svaka od funkcija. Deklaracija sadrži informaciju da klasa posjeduje funkciju i da se ona može izvršiti za svaki objekat klase. Telo funkcije je programski kod, koji se posebno definiše, van deklaracije klase, iskazom koji se naziva definicija funkcije. Definicija, generalno, predstavlja iskaz, kojim se stvarno rezerviše memorijski prostor za neku promenljivu ili daje telo funkcije.

 

Primer 1.34.  

// Definicija funkcije

//...

funkcija Osoba::Prikazi_platu() {

   ispiši platu osobe u riječenici "Osoba... ima platu... din".

}

//...

 

Izraz "Osoba::" u definiciji funkcije u prethodnom primeru označava da funkcija Prikazi_platu pripada klasi Osoba. Telo funkcije je, u ovom primeru, opisano tekstom, a nalazi se između para vitičastih zagrada ({}). Svaka funkcija vraća rezultat, koji je određeni tip podataka. Tip podatka rezultata funkcije navodi se ispred identifikatora funkcije i u konkretnim primjerima, umjesto riječi "funkcija", treba da stoji tip podatka. U prethodnom primeru, izraz "Osoba::Prikazi_platu()", predstavlja identifikator funkcije.

Niz znakova "// ...", korišćen u prethodnom primeru, označava postojanje određenog programskog teksta koji, s obzirom na cilj uvođenja primera, nema neku posebnu ulogu, ali je njegovo postojanje neophodno zbog kompletnosti primera. Ista notacija primenjivaće se i u narednim primjerima.

U cilju obezbeđenja inkapsulacije, pristup članovima klase kontroliše se deklaracijom javnih, privatnih i zaštićenih članova. Javnim članovima mogu pristupiti svi korisnici klase. Privatnim članovima mogu pristupiti samo funkcije članice klase. Zaštićenim članovima mogu pristupiti i članovi nasleđene klase. Upotrebom ključnih riječi public, private i protected unutar deklaracije klase članovi klase se deklarišu, redom, kao javni, privatni ili zaštićeni.

Tipovi podataka koje podržava jezik C++ mogu se klasifikovati u dvije grupe: ugrađeni i korisnički. Ugrađeni tipovi su tipovi podataka koji postoje u samom jeziku i obuhvataju osnovne tipove podataka (char, int, float, double, enum, void) i dio izvedenih tipova (nizovi, reference, pokazivači, konstante, funkcije). Korisnički tipovi su tipovi podataka koje definiše programer. Grupa korisničkih tipova obuhvata drugi dio izvedenih tipova (klase, strukture, unije). Većina osobina tipova podataka nasleđena je iz jezika C, pa se u ovom tekstu neće detaljnije objašnjavati. Objašnjenja će se ograničiti samo na tipove podataka koji se koriste u primjerima.

Klasa predstavlja tip za koji se mogu kreirati pojave. Ako je klasa tip, objekat se može smatrati promenljivom tog tipa u programu. Objekti date klase se u programu kreiraju i koriste na način prikazan u sledećem primeru.

 

Primer 1.35.  

// U programu se deklarišu promjenljive tipa Osoba:

Osoba Ivo;

// a zatim se koriste poruke:

Ivo.Zaposli();               // poziv funkcije Zaposli objekta Ivo;

Ivo.Povecaj_platu():         // poziv funkcije Povecaj_platu objekta Ivo;

Ivo.Prikazi_platu();         // poziv funkcije Prikazi_platu objekta Ivo;

Ivo.Prikazi _podatke();      // poziv funkcije Prikazi podatke objekta Ivo;

Ivo.Penzionisi();            // poziv funkcije Penzionisi objckta Ivo.

Pošto objekat ima neko svoje unutrašnje stanje, koje treba uspostaviti na određen način na početku života objekta, potrebno je obezbediti mehanizam da se objekat, automatski, po nastanku dovede u ispravno početno stanje. Proces kreiranja objekta u vreme izvršavanja programa i njegovo dovođenje u ispravno stanje predstavlja njegovu inicijalizaciju.

Funkcije klase koje obezbjeđuju inicijalizaciju objekata klase nazivaju se konstruktorima. Konstruktor je specijalna funkcija članica klase koja se implicitno poziva pri kreiranju objekata klase. Konstruktor ima isto ime kao i klasa, nema tip koji vraća, može imati argumente i može se preklopiti, što znači da klasa može posedovati više konstruktora sa različitim tipovima argumenata. U jeziku C++ postoji mogućnost da se za jedno ime funkcije navede više različitih deklaracija i tada se za to ime kaže da je preklopljeno. To praktično znači da je moguće deklarisati i definisati više različitih funkcija sa istim identifikatorom.

Primer 1.36. Konstruktor u klasi Osoba iz primera 7.32. može se deklarisati na sljedeći način:

 

// Deklaracija klase

class Osoba {

   tip_podataka_koji_sadrži_ime_Osobe IME;

   tip_podataka_koji_sadrži_prezime_Osobe PRZ;

   tip_podataka_koji_sadrži_zanimanje_Osobe ZAN;

   tip_podataka_koji_sadrži_platu_Osobe PLT:

public:

   //konstruktor

   funkcija Osoba(argumenti: za ime, prezime, zanimanje i platu);

 

   funkcija Zaposli();

   funkcija Povecaj_platu():

   funkcija Prikazi_platu();

   funkcija Prikazi_podatke();

   funkcija Penzionisi();

};

 

// Definicija konstruktora

//...

funkcija Osoba::Osoba(argumenti: za ime, prezime, zanimanje i platu) {

smijesti argumente za ime, prezime, zanimanje i platu u obilježja IME, PRZ, ZAN, PLT;}

//...

Objekti date klase se u programu kreiraju i koriste na sledeči način:

 

// U programu se inicijalizuju promjenljive tipa Osoba:

Osoba Ivo ("Ivo","Ban","programer",4OO);

 

// a zatim se koriste poruke:

 

Ivo.Zaposli();               // poziv funkcije Zaposli objekta Ivo;

Ivo.Povecaj_platu();         // poziv funkcije Povecaj_platu objekta Ivo;

Ivo.Prikazi_platu();         // poziv funkcije Prikazi_platu objekta Ivo;

Ivo.Prikazi_podatke();       // poziv funkcije Prikazi_podatke objekta Ivo;

Ivo.Penzionisi();            // poziv funkcije Penzionisi objekta Ivo.

Moguće je definisati i funkciju članicu klase, koja će se automatski pozivati kada objekat prestaje da postoji. Ova funkcija naziva se destruktor. Konstruktora za jednu klasu može biti više, dok je destruktor samo jedan i funkcija destruktora se ne može eksplicitno pozvati. Destruktor se takođe zove isto kao i klasa, ali ispred njega dolazi poseban znak "~". Destruktor nema tip koji vraća, nema argumente i ne može se preklopiti. Redoslijed poziva destruktora je obrnut od redoslijeda poziva konstruktora.

Primer 1.37. Destruktor u Klasi Osoba iz primera 7.35. se deklariše na sljedeći način:

 

// Deklaracija klase

class Osoba {

   tip_podataka_koji_sadrži_ime_Osobe IME;

   tip_podataka_koji_sadrži_prezime_Osobe PRZ;

   tip_podataka_koji_sadrži_zanimanje_Osobe ZAN;

   tip_podataka_koji_sadrži_platu_Osobe PLT:

public:

   //konstruktor

   funkcija Osoba(argumenti: za ime, prezime, zanimanje i platu);

 

   //destruktor

   funkcija ~Osoba();

 

   funkcija Zaposli();

   funkcija Povecaj_platu():

   funkcija Prikazi_platu();

   funkcija Prikazi_podatke();

   funkcija Penzionisi();

};

 

Nakon ovog početnog upoznavanja sa strukturom jezika C++ i objašnjenja za određene ključne riječi, u sledećem primeru klase će se deklarisati bez navođenja programskog teksta na srpskom jeziku.

Primer 1.38. Klase iz primera 7.5

 

TipArtikla = ((NAZIV, Chr), (IDA , Int))

StavkaNarudžbine = ((ARTIKAL, TipArtikla), (KOLIČINA, Int)).

TipKupca = ((NAZIV, Chr), (ADRESA, Chr), (STANJE_RAČ, Int), PORUDŽBINE,

{TipPorudžbine})).

TipPorudžbine = ((BRP, Int), (KUPAC, TipKupca), (SADRŽI, StavkaNarudžbine}).

 

mogu se deklarisati u jeziku C++ na sljedeći način:

 

class TipArtikla {

char NAZIV[35];

int IDA;

public:

TipArtikla ();

~TipArtikla();

//...

class StavkaNarudzbine {

TipArtikla ARTIKAL;

int KOLICINA;

public:

StavkaNarudzbine ();

~StavkaNarudzbine();

//...

};

class TipKupca {

char NAZIV[35];

char ADRESA[20];

int STANJE_RAC;

TipPorudzbine PORUDZBINE;

public:

TipKupca ();

~TipKupca();

//...

class TipPorudzbine {

int BRP;

TipKupca KUPAC;

StavkaNarudzbine SADRZI;

public:

TipPorudzbine ();

~TipPorudzbine();

 

//...

};.

 

U prethodnom primeru ključne riječi char i int označavaju osnovne tipove podataka. U programskom jeziku C++ niz znakova se smiješta u memoriju kao jednodimenziona tabela tipa char kojoj se na kraju dodaje nula-znak "\0". Pošto u jeziku ne postoje operatori za operacije nad nizovima znakova, da bi se taj niz znakova mogao obrađivati, potrebno mu je dodeliti pokazivač, koji pokazuje na početak niza. Deklaracija tipa char * označava izvedeni tip pokazivača na promjenljive tipa char. U primeru 7.37, deklaracija char *NAZIV deklarisala bi promenljivu NAZIV kao pokazivač. Ovaj podatak pokazuje na adresu u memoriji, u kojoj je smiještena neka promenljiva tipa char. U praktičnom radu se, deklaracija promenljivih tipa char pomoću pokazivača, često koristi. Deklaracija pomoću nizova znakova je preglednija i jednostavnija sa stanovišta primera u tekstu.

 

Preklapanje operatora

 

Operatori ugrađeni u jezik C++ mogu se definisati za korisničke tipove (klase). Preklapanje operatora je definisanje novog značenja za neki operator u programu. Preklopljeni operator se definiše kao funkcija čije je ime taj operator, iza čega sledi spisak parametara i telo same funkcije.

 

Primer 1.39. Preklapanje operatora se može ilustrovati na klasi Datum:

 

class Datum {

int DAN,MESEC,GODINA;

public:

Datum(int, int, int);

Datum operator + (int);

                   //...

};

Datum:: Datum (int D, int M, int G) {

DAN = D;

MESEC = M;

GODINA = G;

}

Datum Datum::operator + (int n) {

// Programski kod za preklopljeni operator +

// n - broj dana

// Aproksimativni algoritam

int D,M,G;

G = n/365;

M = (n-G*365)/30;

D = n - G * 365 - M * 30;

GODINA = GODINA + G;

MESEC = MESEC + M;

                   DAN= DAN + D;

}

           

void main (){

Datum Danas (6,11,1995);            // poziv konstruktora;

Danas = Danas + 10;                            // Danas je 16. 11. 1995

Danas.operator+ (5);                             // Danas je 21.11.1995

//...

}.

 

U prethodnom primeru preklopljen je ugrađeni operator + za korisnički tip Datum. Ovaj primjerobezbjeđuje vršenje operacije sabiranja celog broja sa korisničkim tipom Datum. Primjerje namenjen za ilustraciju preklapanja operatora, pa je u tom cilju i u cilju jednostavnosti implementacije, primenjen aproksimativni algoritam, koji pretpostavlja da sve godine imaju 365 dana i da svi meseci imaju po 30 dana. U primeru su uvedene i dvije nove ključne riječi void i main. Tip void je poseban ugrađeni tip koji predstavlja prazan skup vrijednosti. Ne postoje objekti ovog tipa već se on koristi za formiranje izvedenih tipova. Upotrebljava se kao tip rezultata funkcije koje ne vraćaju nikakvu Vrijednost ili kao tip pokazivača koji mogu da ukazuju na bilo koji objekat u memoriji. Obavezna funkcija main predstavlja glavni program. Program počinje izvršavanje pozivom funkcije sa identifikatorom main.

 

Nasljeđivanje

 

Nasljeđivanje u jeziku C++ realizuje se konceptom izvedenih klasa. Izvođenje klasa je koncept jezika C++ koji definiše izvedenu klasu K1 (potklasu) iz klase K2 (superklase), kao klasu čiji objekti imaju sve članove superklase i one članove koji su eksplicitno deklarisani u potklasi.

 

Primer 1.40. Klase iz primera 7.7 se, korišćenjem koncepta izvođenja, mogu deklarisati na sljedeći način:

 

class Date {

//... Deklaracija tipa Date

}

class Money {

//... Deklaracija tipa Money }

class Progjez {

//... Deklaracija tipa Progjez }

class Osoba {

char IME[15];

char PRZ[20];

Date DAT_ROD;

void Prikazi_godine();

 

public:

Osoba();

~Osoba();

void Prikazi_ime();

void Prikazi_prezime();

void Izmeni_prezime();

};

class Zaposleni : public Osoba {

Money PLATA;

public:

Zaposleni();   // Preuzima ulogu metode zaposli iz primera 7.7;

~Zaposleni(); // Preuzima ulogu metode otpusti iz primera 7.7

void Povecaj_platu();

void Prikazi_platu();

};

class Programer : public Zaposleni {

Prog_jez PROGJEZ;

public:

Programer();

-Programer();\

//..

};.

 

Potklasa se deklariše neobaveznim navođenjem jedne od ključnih riječi public, protected ili private i obaveznim navođenjem naziva superklase iza znaka ":" u zaglavlju deklaracije klase. Upotrebom ključnih riječi public, protected i private deklariše se javno, zaštićeno i privatno izvođenje. Ključna riječ public u zaglavlju deklaracije potklase znači da javni i zaštićeni članovi superklase ostaju javni i zaštićeni članovi potklase. Javnim i zaštićenim članovima superklase se iz funkcija potklase pristupa neposredno kao i sopstvenim članovima. Zaštićenim izvođenjem, javni i zaštićeni članovi superklase postaju zaštićeni članovi potklase, a privatnim izvođenjem javni i zaštićeni članovi superklase postaju privatni članovi potklase.

Objekti potklase nasleđuju sva obilježja superklase, bez obzira na način izvođenja i posjeduju svoje posebne članove koji su navedeni u deklaraciji potklase. U zavisnosti od načina izvođenja, pristup određenim nasleđenim članovima potklase je na nekim mestima u programu dozvoljen ili ne. Potklasa ne nasljeđuje konstruktore, destruktore i, ako postoji, funkciju članicu operator= superklase.

U prethodnom primeru većina funkcija članica je zbog jednostavnosti deklarisana kao funkcije bez argumenata koje ne vraćaju nikakvu Vrijednost.

 

Primer 1.41. Na slici 7.10 su prikazana obilježja klase Osoba, njene potklase Zaposleni i jedan objekat klase Zaposleni. Objekat potklase Zaposleni se kreira na sljedeći način:

class Money {

 

//.. Deklaracija tipa Money

}

class Osoba {

char IME[15];

char PRZ[20|;

int STAROST;

public:

Osoba(char,char,int);

~Osoba();

};

class Zaposleni : public Osoba {

Money PLT;

Char RAD_MES[20];

Char ODEL[20];

public:

Zaposleni(char,char,int,int,char,char);

~Zaposleni();

};

void main () {

//...

// Negde u programu

 

Zaposleni Ana ("Ana", "Car", 23, 400, "progr.". "AOP");

//...

}.

 

Objekat Ana se kreira pozivom konstruktora Zaposleni. Pri kreiranju objekta potklase, prvo se bira jedan od konstruktora potklase, koji će se pozvati. Pre izvršenja tog konstruktora, poziva se konstruktor superklase. Konstruktor superklase se bira prema argumentima navedenim u zaglavlju konstruktora potklase iza znaka ":". Izraz iza ":" se naziva inicijalizatorom. Konstruktor superklase inicijalizuje onaj dio objekta potklase, koji sadrži vrijednosti obilježja superklase. Zatim se inicijalizuju obilježja potklase redoslijedom kojim su deklarisana. Na kraju se izvršava telo konstruktora potklase. Definicija konstruktora klase Zaposleni prikazana je u sledećem primeru.

 

 

Primer 1.42.  

// DEfinicija konstruktora

//...

void Zaposleni::Zaposleni( char IME[15], char PRZ[20], int STAROST[20], int PLT, char RAD_MES[20], char ODEL[20]) : Osoba (IME[S], PRZ[20], STAROST[20]) {

//... Telo konstruktora

}

// ...

 

Redoslijed izvršavanja destruktora je suprotan redoslijedu izvršavanja konstruktora. Prvo se izvršava destruktor potklase, zatim se ukidaju članovi suprotno redoslijedu inicijalizacije i na kraju se poziva destruktor superklase.

Jezik C++ omogućava da neka klasa u isto vreme bude izvedena iz više klasa. Tada svaki objekat potklase nasljeđuje sve članove svih svojih superklasa. Višestruko nasljeđivanje se, slično kao i jednostruko, realizuje konceptom višestrukog izvođenja. Klasa se može izvesti iz više superklasa. Potklasa se višestruko izvodi tako što se u zaglavlju njene deklaracije navode imena njenih superklasa, razdvojene zarezom. Značenje ključnih riječi public, protected i private je isto kao i kod jednostrukog izvođenja.

 

Primer 1.43. Posmatraju se klase: Stanovnik, Zaposleni, Student i Zaposleni_Student. Klasa Zaposleni_student ima dvije direktno nadređene i jednu tranzitivnu superklasu. Direktno nadređene klase su: Zaposleni i Student. Zaposleni_Student nasljeđuje osobine od sve tri klase. Na slici 7. 16 je prikazana ova hijerarhija klasa i jedna pojava klase Zaposleni _Student.

 

class Stanovnik {

//...

};

class Zaposleni : public Stanovnik {

//...

};

class Student : public Stanovnik {

//...

};

class Zaposleni_Student : public Zaposleni, public Student {

//...

};.

 

Generički mehanizam

 

Generički mehanizam u jeziku C++ omogućava generisanje klasa i funkcija. Ovaj mehanizam realizuje se pomoću šablona (template). Šabloni klasa uvode u program parametrizovane tipove. Generički mehanizam omogućava da se u programu automatski generišu klase i funkcije prema datom šablonu. Šablon predstavlja definiciju klase ili funkcije, koja u sebi sadrži kao formalne argumente tipove podataka. Te tipove podataka će, u fazi generisanja konkretne klase ili funkcije, zameniti konkretni tipovi. Klase i funkcije generisane iz istog šablona imaju istu realizaciju, ali manipulišu različitim tipovima.

 

Primer 1.44. Neka je kreirana klasa Zaposleni i neka je potrebno omogućiti upravljanje njenom ekstenzijom. Tada se prvo definiše nova pojava ugrađene klase tipa kolekcija. Ako je Radnici naziv ekstenzije klase Zaposleni, tada bi se Radnici deklarisali kao nova pojava ugrađene klase, recimo, klase Skup. Svaki objekat klase Zaposleni, nakon svog kreiranja u okviru klase Zaposleni, mora se eksplicitnom naredbom uvrstiti i u objekat-skup sa identifikatorom Radnici. Metode ugrađene klase Skup, omogućavaju upravljanje ekstenzijom klase Zaposleni, pošto je objekat sa identifikatorom Radnici pojava klase Skup. Moguća realizacija korišćenjem C++ generičkog mehanizma je sledeća:

 

template <class T>

class Skup {

T*Niz[100];

static i;

public:

Skup(){};

void UpisiClan (T *ut) {

i++;

niz [i] = ut;

};

}

class Zaposleni {

// obilježja klase Zaposleni

public:

Zaposleni();

~Zaposleni();

//funkcije klase Zaposleni...

};

//...

void main () {

//...

Skup<Zaposleni> Radnici;

Zaposleni Ivo;

Radnici.UpisiClan (&Ivo);

//...

}.

 

Deklaracija šablona u potpunosti odgovara deklaraciji obične klase, samo što ispred nje stoji ključna riječ template <...>, koji označava da se radi o deklaraciji šablona, čiji je formalni argument tip T naveden između znakova " < " i " > ".

U prethodnom primeru uvedeno je i nekoliko novih ključnih riječi jezika C++. Konstrukcija tipa "T *Niz[100]" deklariše niz pokazivača na tip T. Ključna riječ static deklariše, a ujedno i definiše promenljivu i kao statički objekat. Statički objekat ima životni vek do kraja izvršavanja celog programa. Inicijalizuju se samo jednom. U primeru, i se koristi kao brojač članova niza. Jezik C++ podržava inicijalizaciju funkcija u okviru deklaracije klase, pa je na takav način izvršena inicijalizacija funkcije UpisiClan. Poziv funkcije UpisiClan kao parametar prenosi adresu objekta.

Komparacija relacionog i objektno – orijentisanog modijela podataka

Objektno - orijentisani model podataka, kao novija paradigma, posjeduje niz prednosti u odnosu na relacionu i druge klasične paradigme. U prednosti objektno-orijentisanog pristupa se ubrajaju: predstavljanje kompleksnih objekata, produktivnost programiranja, jedinstven jezik podataka, potencijalno bolje performanse, pogodnost za zadovoljenje zahtjeva novih oblasti primjene, fleksibilnost, ograničenost ponašanja i snaga semantičke izražajnosti. Produktivnost programiranja, jedinstven jezik podataka, potencijalno bolje performanse i pogodnost za zadovoljenje zahtjeva novih primjena, detaljnije su obrazloženi u posebnim tačkama ovog dijela knjige. Fleksibilnost, ograničenost ponašanja i snaga semantičke izražajnosti se samo kratko komentarišu u nastavku teksta.

Fleksibilnost je posledica činjenice da su izmjene tipova objekata i njihovih metoda lokalnog karaktera. Te izmjene u relacionom modijelu su kompleksnije. jer jednoj klasi objektno - orijentisanog modijela odgovara (po pravilu) veći broj šema relacija.

Inkapsulacija ograničava ponašanje svakog objekta na prethodno definisane metode. Saglasno tome, lakše se otkrivaju i rešavaju problemi, nastali zbog greške u nekoj metodi. Takođe, manja je verovatnoća da dođe do nekontrolisanog prostiranja efekata te greške u bazi podataka.

Korišćenje svih postupaka (osim asocijacije) semantičkih modijela podataka daje snagu objektno - orijentisanom modijelu za verno modeliranje realnog sveta. Apstrakcija asocijacija, koju u semantičkim modelima predstavlja tip poveznika, u objektno - orijentisanom modijelu se postiže indirektno, razmenom poruka između objekata. Ne postoji mogućnost da se u objektno - orijentisanom modijelu direktno izrazi povezanost između dva objekta, jer se svaki objekat posmatra kao samostalan pojam.

U literaturi se neki put navodi da objektno - orijentisani model može, a relacioni ne može da podrži verzije istog objekta i duge transakcije. lako objektno - orijentisana paradigma otklanja određene nedostatke relacionog modijela, sam objektno - orijentisani model ne spominje verzije i duge transakcije, kao ni relacioni. Verzije i duge transakcije se povezuju sa objektno - orijentisanim modelom, jer su to mogućnosti, koje nedostaju relacionim SUBP, a bitne su za one aplikacije, za koje je objektno - orijentisani model pogodniji od relacionog, te se i očekuje da će objektno - orijentisani SUBP moći da zadovolje te zahtjeve.

 

Produktivnost programiranja

 

Činjenica da postojeći programski kod može skoro, ali ne u potpunosti da zadovolji zahtjeve nove aplikacije, verovatno predstavlja izvor najvećih frustracija korisnika relacionog i drugih klasičnih pristupa, pri pokušaju da se neki od postojećih programa ponovo upotrebi.

 

Organizovanjem objekata u klase, koje inkapsuliraju ponašanje objekata na način sličan apstraktnim tipovima podataka i organizujući klase u hijerarhiju nasleđivanja, objektno - orijentisano programiranje može obezbediti i dugo traženo dijelenje i ponovno korišćenje programskog koda. Programski kod, koji strukturi podataka daje smisao, više nije rasut po aplikativnim programima. U objektno - orijentisanom jeziku, nova klasa se može kreirati od već postojeće, navođenjem samo razlika u odnosu na neku već postojeću klasu. Sve ostalo nova klasa nasljeđuje od stare. Obilježja i metodi ne treba da se definišu i pišu ispočetka, što smanjuje mogućnost unošenja novih grešaka. Nasljeđivanje omogućava da se isti program može primjeniti na objekte, koji pripadaju različitim klasama. U slučaju velikog broja klasa sa velikim brojem obilježja i metoda, koristi od dijelenja obilježja i metoda mogu biti velike.

 

Jedinstven jezik

 

Relacioni sistemi baza podataka su projektovani za realizaciju važne ali ograničene klase primjena. Te primjene se odnose na slučajeve kada treba memorisati velike količine dobro strukturiranih podataka i na njima izvršavati relativno jednostavne operacije. Primere predstavljaju baze poslovnih podataka preduzeća, rezervacije karata u avio-saobraćaju ili baze podataka u društveno političkim zajednicama. U takvim bazama podataka dominiraju:

•        operacije pretraživanja na osnovu relativno malog i prethodno definisanog broja kriterijuma,

•        ažuriranje podataka i

•        takozvana navigacija između relativno malog broja datoteka ili relacija.

Posledica takvih primjena je i razdvojenost programskog jezika za definisanje. selekciju i manipulisanje podacima, kakav je SQL jezik podataka, od programskog jezika opšte namene, kakvi su programski jezici treće generacije i proceduralni jezici četvrte generacije. Naredbe jezika podataka (za selekciju i manipulisanje podacima) se ugrađuju u programe. pisane u programskom jeziku opšte namene. Jezik podataka ima zadatak da obezbedi efikasan pristup bazi podataka, ali su njegove mogućnosti za izražavanje kompleksnih upita ograničene. Po pravilu, ne podržava definisanje rekurzivnih upita.

 

Primer 1.45. U svakom jeziku za selekciju i manipulisanje bazom podataka, može se definisati upit tipa "Ko je rukovodilac radnika x", ali retko kada i upit "Ko su sve rukovodioci radnika x". Poslednji upit podrazumijeva da se kao odgovor dobije kompletna rukovodna hijerarhija za radnika x. Pošto to znači da treba tražiti rukovodiočevog rukovodioca dok takav postoji, ovakav upit se naziva rekurzivnim.

 

Programski jezici opšte namene su, po pravilu, pogodni za definisanje proizvoljnih procedura pa često i rekurzivnih. Međutim, nisu predviđeni za efikasno pretraživanje baze podataka. S druge strane, u primjenama vezanim za baze podataka u inženjerskom projektovanju, grafici, geografskim informacionim sistemima i softverskom inženjerstvu, javlja se potreba integracije jezika podataka i jezika opšte namene u jedan jezik. Naime, programski jezik opšte namene i jezik podataka, po pravilu se značajno razlikuju po sintaksi i modijelu podataka, što značajno otežava njihovo zajedničko korišćenje.

Objektno - orijentisani jezici su proceduralni jezici. Posjeduju osobine jezika opšte namene za obavljanje operacija u operativnoj memoriji. Posjeduju i sintaksu za definisanje klasa i hijerarhije klasa (tj. za definisanje šeme baze podataka). Ti jezici predstavljaju dobru osnovu za izgradnju jedinstvenog jezika za rad sa bazom podataka. Potrebno ih je proširiti:

•        metodama za smiještanje podataka na medijum eksternog memorijskog uređaja i

•        deklarativnim upitnim jezikom.

 

Bolje performanse

 

Povezivanje objekata putem identifikatora predstavlja potencijalni izvor boljih performansi objektno - orijentisane u odnosu na relacionu bazu podataka. U objektno - orijentisanoj bazi podataka, Vrijednost obilježja X objekta o₁ je identifikator i₂, objekta o₂. Ako je neki aplikativni program već učitao objekat o₁ i sada treba da učita objekat o₂, SUBP to realizuje koristeći njegov identifikator i₂. Pristup objektu o₂ je direktan, na osnovu adrese. U relacionoj bazi podataka, X Vrijednost torke t₁ je Vrijednost ključa x torke t₂. Da bi se učitala torka t₂ u operativnu memoriju, potrebno je, prvo izvršiti traženje u indeksu ključa X, pa onda preneti torku t₂ u operativnu memoriju, što, u opštem slučaju, zahtjeva više od jednog pristupa.

 

Slika 0.22.

 

Primer 1.46. Na slici 7.22 su prikazane dvije pojave klase Zaposleni i dvije pojave klase Radno_Mesto. Klasa Radno_Mesto je domen obilježja RAD_MES u klasi Zaposleni. Vrijednost, memorisana u polju RAD_MES je identifikator jednog objekta klase Radno_Mesto. Pristup tom objektu klase Radno_Mesto se vrši putem identifikatora, a to znači direktno, na osnovu adrese na disku.

Postojeće relacione baze podataka dozvoljavaju korišćenje samo osnovnih tipova podataka u svojstvu domena obilježja. Povezivanje torki dvije relacije se vrši putem stranog ključa. Ako je neki aplikacioni program pročitao torku (159, Ivo, Ban, programer) i treba sada da pristupi torci (programer, 450, visoka, 2), sistem mora izvršiti upit koji prolazi kroz torke relacije Radno_Mesto tražeći torku sa vrednošću obilježja NAZ_RM = programer. To traženje zahtjeva, u opštem slučaju više pristupa disku nego direktni pristup, na osnovu adrese, kao u slučaju objektno - orijentisane baze podataka. Slika 7.23 prikazuje relacionu reprezentaciju objektno - orijentisane baze podataka sa slike 7.22.

 

Slika 0.23.

 

Drugi aspekt doprinosa identifikatora boljim performansama objektno - orijentisanih baza podataka u poređenju sa relacionim je da se, pri prenosu objekata u operativnu memoriju, identifikatori, memorisani zajedno sa objektima, pretvaraju u memorijske pokazivače (virtuelne adrese). Pošto relacione baze podataka ne poznaju pojam identifikatora, one ne mogu ni memorisati memorijske pokazivače u torkama. Pristup relacionoj torci, koja je u operativnoj memoriji, vrši se indirektno, korišćenjem stranog ključa i odgovarajućeg indeksa. Mogućnost navigacije kroz memorijski rezidentne objekte je potpuno strana relacionom modijelu, a pad performansi se ne može neutralisati jednostavnim obezbeđenjem velikog prostora za bafere u operativnoj memoriji. U aplikacijama, koje zahtjevaju repetitivnu navigaciju kroz spregnute objekte u operativnoj memoriji, objektno - orijentisana baza podataka može biti znatno brža od relacione.

Slika 0.24.

Primer 1.47. Na slici 7.24 je prikazana memorijska reprezentacija objekata sa slike 7.23. Usmijereni potezi ukazuju na povezanost objekata različitih klasa putem rnemorijskih adresa.

 

Objektno - orijentisani model podataka i zahtjevi novih primjena

 

Objektno - orijentisani model podataka obezbjeđuje mogućnosti za predstavljanje identiteta objekta, apstraktne podatke i odnose između objekata. Daje korisniku fleksibilnost i mogućnost širenja pri radu sa kompleksnim podacima. Sada će biti pokazano kako OOMP može da ukloni nedostatke relacionog modijela u primjeni na projektne baze podataka.

Nehomogeni podaci. Relacioni model postavlja homogene torke u relaciju, analogno, u objektno - orijentisanom modijelu, klasa generiše slične objekte. Međutim, struktura podataka klase nije dvodimenzionalna. Može da sadrži višeznačna obilježja, što znači da se jednom objektu može pridružiti više vrijednosti iz jednog domena. U relacionom modijelu, ovakvi zahtjevi dovode ili do redundanse podataka ili do dekomponovanja šeme relacije. Zajedničke osobine klasa se mogu izvući u cilju formiranja superklase. Hijerarhija klasa (latisa) obezbjeđuje organizovan način upravljanja tipovima podataka.

Ekvivalentni objekti. Objektno - orijentisani model koristi generičke objekte za predstavljanje semantike ekvivalentnih objekata. Generički objekat posjeduje obilježja koja identifikuju različite reprezentacije istog objekta. Definicijama generičkih objekata se mogu dodati ograničenja, tako da se modifikacije jedne reprezentacije reflektuju u drugim.

Razvoj šeme. Konvencionalni SUBP ne podržavaju efikasne mehanizme za evoluciju šeme najviše zbog toga što poslovne primjene baze podataka ne zahtjevaju česte izmjene šeme. Dok je dodavanje takvih mehanizama tradicionalnim SUBP teško, objektno - orijentisani model dozvoljava definisanje korisničkih operacija, što olakšava širenje šeme. Evolucija šeme uključuje promjene definicija unutar jedne klase, kao i definicije latise klasa. Može se definisati skup invarijanti i pravila, tako da šema ostane konzistentna kako evoluira.

Multimedija. Objektno - orijentisani model podataka predstavlja mnogo prirodniju osnovu za implementaciju funkcija, neophodnih za upravljanje multimedijskim podacima. Multimedijski podaci se definišu kao podaci proizvoljnog tipa (brojevi, nizovi karaktera, Zaposleni, Preduzeće, slika, tekst, zvuk, grafika, film, dokument sa slikama, tekstom i tako dalje). Pri tome, to su nizovi velike i promjenljive dužine. Objektno - orijentisani model podataka stvarno omogućava definisanje proizvoljnih tipova podataka, pa i nizova proizvoljne i promjenljive dužine. Definišu se kao nov tip podataka (klasa). Saglasno tome, niz nije ništa drugo nego objekat sa jedinstvenim identifikatorom. Nizu se može pristupiti putem njegovog identifikatora, ili na osnovu sadržaja. Međutim, objektno orijentisana paradigma, sama po sebi, ne rešava probleme efikasnog memorisanja, čitanja i ažuriranja multimedijskih podataka. To su ozbiljni problemi, koji treba da se reše u izgradnji objektno - orijentisanog SUBP.