Igor Dejanović

METAMODEL, EDITOR MODELA I GENERATOR POSLOVNIH APLIKACIJA

- MAGISTARSKA TEZA -

Novi Sad, 2008.

Sadržaj

1. Uvodna razmatranja...................................................................................................................11.1. Razvoj softverskog inženjerstva........................................................................................1

1.1.1. Podizanje nivoa apstrakcije...................................................................................................11.1.2. CASE alati.............................................................................................................................31.1.3. Jezici četvrte i pete generacije...............................................................................................41.1.4. Napori na polju standardizacije.............................................................................................5

1.2. Osnovni pojmovi, koncepti i tehnike.................................................................................51.2.1. Sistem....................................................................................................................................51.2.2. Model....................................................................................................................................61.2.3. Platforma...............................................................................................................................61.2.4. Poslovna aplikacija................................................................................................................81.2.5. Metamodelovanje..................................................................................................................8

1.2.5.1. Četvoroslojna arhitektura – metanivoi..............................................................101.2.5.2. Apstrakcija, klasifikacija, instanciranje i generalizacija...................................12

1.2.6. Reprezentacija modela ­ konkretne vizuelne i teksutalne sintakse.......................................161.2.7. Formalne tehnike definisanja semantike..............................................................................18

1.2.7.1. Ontologije.........................................................................................................181.2.7.2. Predikatska logika prvog reda..........................................................................201.2.7.3. Konceptualni grafovi........................................................................................21

1.2.8. Formalna definicija steka za metamodelovanje...................................................................211.2.9. Jezici specifični za domen...................................................................................................26

1.3. Inženjering upravljan modelima (Model­Driven Engineering).......................................281.3.1. Najvažniji predstavnici........................................................................................................291.3.2. MDA...................................................................................................................................34

1.3.2.1. Stanovište – viewpoint......................................................................................351.3.2.2. Vrste modela.....................................................................................................351.3.2.3. Inženjerstvo unapred, reverzno i kružno inženjerstvo......................................361.3.2.4. MOF – Meta­Object Facility............................................................................371.3.2.5. UML – Unified Modeling Language................................................................391.3.2.6. Transformacije modela.....................................................................................401.3.2.7. OCL – Object Constraint Language.................................................................411.3.2.8. XMI  ­ XML Metadata Interchange..................................................................421.3.2.9. HUTN – Human­Usable Textual Notation.......................................................43

1.3.3. MDSD.................................................................................................................................44

1.3.3.1. Domenska arhitektura.......................................................................................441.3.3.2. Razvoj softvera upravljan modelima baziran na arhitekturi (Architecture­Centric MDSD)..............................................................................................................451.3.3.3. Tehnike generisanja koda.................................................................................461.3.3.4. Integracija ručno pisanog i generisanog koda..................................................481.3.3.5. Kružno inženjerstvo..........................................................................................50

1.3.4. Pregled vodećih MDA/MDSD alata ...................................................................................511.3.4.1. AndroMDA.......................................................................................................511.3.4.2. openArchitectureWare......................................................................................531.3.4.3. OptimalJ............................................................................................................561.3.4.4. GME.................................................................................................................561.3.4.5. GEMS...............................................................................................................581.3.4.6. MetaEdit+.........................................................................................................581.3.4.7. AMMA.............................................................................................................591.3.4.8. Sculptor.............................................................................................................60

1.4. Osnovne postavke............................................................................................................612. Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema.............62

2.1. Osnovne komponente DOMMLite alata..........................................................................632.2. Korišćeni dizajn obrasci...................................................................................................63

2.2.1. MVC – MTV.......................................................................................................................632.2.2. Entity – entiteti....................................................................................................................652.2.3. ValueObject – vrednosni objekti.........................................................................................652.2.4. Service – servisi...................................................................................................................66

2.3. DOMMLite meta­model..................................................................................................662.3.1. DOMMLite model (metaklasa DOMMLiteModel).............................................................662.3.2. Prosti i primitivni tipovi (metaklasa DataType)...................................................................672.3.3. Imenovani element (metaklasa NamedElement)..................................................................682.3.4. Enumeracije (metaklase Enumeration, EnumerationLiteral)...............................................692.3.5. Paketi (metaklase Package, PackageElement).....................................................................702.3.6. Tipizirani elementi (metaklasa TypedElement)...................................................................70

2.3.6.1. Kardinalitet tipiziranih elemenata.....................................................................712.3.7. Klasifiktori (Classifier)........................................................................................................722.3.8. Osobine (Feature)................................................................................................................732.3.9. Strukturne osobine (Property)..............................................................................................73

2.3.9.1. Vrste referenci..................................................................................................742.3.10. Operacije (Operation)........................................................................................................752.3.11. Parametri (Parameter)........................................................................................................762.3.12. Odeljci osobina (FeatureCompartment).............................................................................762.3.13. Odeljci operacija (OperationCompartment).......................................................................772.3.14. Entiteti (Entity)..................................................................................................................78

2.3.14.1. Jedinstveni identifikatori................................................................................792.3.14.2. Globalni i lokalni semantički identifikatori....................................................802.3.14.3. Zavisnost sa servisima....................................................................................80

2.3.15. Vrednosni objekti (ValueObject).......................................................................................812.3.15.1. Strukturne osobine vrednosnih objekata.........................................................812.3.15.2. Definisanje veze zavisnosnti sa entitetima i podrazumevane strukturne osobine...........................................................................................................................82

2.3.16. Servisi (Service)................................................................................................................822.3.17. Izuzeci (Exception)............................................................................................................832.3.18. Ograničenja (Constraints)..................................................................................................83

2.3.18.1. Oznake (TagType)..........................................................................................862.3.18.2. Validatori (ValidatorType).............................................................................88

2.4. Tekstualna notacija DOMMLite jezika............................................................................912.4.1. Model..................................................................................................................................912.4.2. Paketi...................................................................................................................................922.4.3. Korisnički definisani primitivni tipovi.................................................................................932.4.4. Enumeracije.........................................................................................................................932.4.5. Strukturne osobine...............................................................................................................94

2.4.5.1. Atributi..............................................................................................................952.4.5.2. Reference..........................................................................................................96

2.4.6. Operacije.............................................................................................................................972.4.7. Parametri.............................................................................................................................982.4.8. Odeljci.................................................................................................................................992.4.9. Entiteti...............................................................................................................................100

2.4.9.1. Semantički ključ entiteta.................................................................................1022.4.9.2. Zavisnost sa servisima....................................................................................102

2.4.10. Servisi..............................................................................................................................1032.4.11. Vrednosni objekti............................................................................................................1032.4.12. Izuzeci.............................................................................................................................1042.4.13. Ograničenja......................................................................................................................105

2.4.13.1. Oznake..........................................................................................................1062.4.13.2. Validatori......................................................................................................107

3. Implementacija editora modela i generatora poslovnih aplikacija........................................1093.1. Implementacija DOMMLite metamodela korišćenjema ECore metametamodela........1093.2. Tekstualni editor za zadavanje modela..........................................................................111

3.2.1. Definisanje gramatike DOMMLite jezika..........................................................................1113.2.2. Generisanje editora DOMMLite tekstualne notacije .........................................................1113.2.3. Prilagođavanje generisanog editora...................................................................................112

3.2.3.1. Ugrađeni tipovi, validatori i oznake...............................................................1133.2.3.2. Ograničenja modela........................................................................................1153.2.3.3. Strukturni pogled generisanog editora (outline).............................................1153.2.3.4. Dopuna koda...................................................................................................117

3.3. Implementacija generatora koda za Django okvir za razvoj..........................................1193.3.1. Django arhitektura.............................................................................................................119

3.3.2. Generisanje Django aplikacije...........................................................................................1213.3.3. Generisanje Django modela...............................................................................................1223.3.4. Generisanje Validatora......................................................................................................1253.3.5. Generisanje Servisa...........................................................................................................1293.3.6. Proširenja DOMMLite jezika koja koristi django generator..............................................1313.3.7. Jedinstvenost lokalnog poslovnog ključa...........................................................................132

4. Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata. 1334.1. Postavka problema.........................................................................................................1334.2. Analiza zahteva..............................................................................................................134

4.2.1. Slučajevi korišćenja...........................................................................................................1344.2.1.1. Prijava na konkurs..........................................................................................1344.2.1.2. Rangiranje kandidata i izrada rang lista..........................................................1354.2.1.3. Kreiranje rasporeda polaganja........................................................................1364.2.1.4. Upis kandidata................................................................................................137

4.3. Specifikacija dizajna......................................................................................................1374.3.1. DOMMLite model.............................................................................................................137

4.3.1.1. Entitet Drzava.................................................................................................1374.3.1.2. Entitet Skola....................................................................................................1384.3.1.3. Entitet StudijskiProgram.................................................................................1394.3.1.4. Entitet Kandidat..............................................................................................1404.3.1.5. Entitet UpisniRok...........................................................................................1434.3.1.6. Entitet UpisniKrug..........................................................................................1434.3.1.7. Entitet KvotaZaStudijskiProgram...................................................................1444.3.1.8. Entiteti RangLista i StavkaRangListe.............................................................1454.3.1.9. Entitet Test......................................................................................................1464.3.1.10. Entiteti SalaZaPolaganje i TerminZaPolaganje............................................1474.3.1.11. Servis Upis....................................................................................................149

4.4. Implementacija...............................................................................................................1504.4.1. Implementacija django modela..........................................................................................1504.4.2. Implementacija servisnih rutina.........................................................................................151

4.5. Validacija generisanog koda..........................................................................................1535. Zaključak i dalji pravci razvoja..............................................................................................156

5.1. Zaključak........................................................................................................................1565.2. Dalji pravci razvoja........................................................................................................157

Reference...................................................................................................................................159Definicije korišćenih skraćenica................................................................................................169Dodatak A. Gramatika DOMMLite jezika................................................................................173

Predgovor

Inherentna   osobina   poslovnih   sistema   je   njihova   složenost   koja   rezultira   složenošću aplikativnog softvera za podršku. Da bi se ova složenost uspešno kontrolisala i savladala i da bi se pojednostavio proces izgradnje i održavanja poslovnih sistema koriste se različiti pristupi i metode koji se uglavnom svode na podizanje nivoa apstrakcije i prepuštanje implementacionih detalja   specijalizovanim   alatima.   U   poslednjoj   deceniji   velika   dostignuća   nastaju   na   polju modelovanja i definisanja jezika specifičnih za domen čime se omogućava da se programeri i domenski   eksperti   fokusiraju   na   konkretne   domenske   probleme   koje   rešavaju.   Formiranje OMG­a (Object Managament Group), organizacije koja je okupila najznačajnije industrijske subjekte u cilju formiranja standarda u oblasti, doprinelo je, u velikoj meri, ubrzanju razvoja metodologija   izrade   softvera   upravljane   modelima.   Inicijativa   OMG­a   pod   nazivom   MDA (Model­Driven Architecture) danas predstavlja jedan od najznačajnijih pokreta u oblasti razvoja softvera upravljanog modelima. Prema viđenju nekih autora, MDA predstavlja specijalizaciju šireg pristupa pod nazivom MDE (Model­Driven  Engineering),  dok  je  MDE specijalizacija opšteg pristupa u razvoju jezika specifičnih za domen – DSL (Domain­Specific Languages). Jezici specifični za domen su programski jezici kreirani za rešavanje problema u određenom, jasno definisanom,  domenu.  DSL se  nalazi  na  višem nivou apstrakcije  u  odnosu  na  MDE pristup, tj. MDE predstavlja samo jednu od specijalizacija DSL ideja. Postoje i drugi pristupi koji specijalizuju DSL kao što su Grammarware, XML pristupi itd. 

Izrada  poslovnog   sistema  podrazumeva   implementaciju   više   stotina,   pa  čak   i   hiljada međusobno   povezanih  domenskih   entiteta   i   bar   toliko   ekranskih   formi.   Implementacija   na klasičan način bi podrazumevala ručno kodiranje u programskom jeziku treće generacije što dovodi do velikih problema ne samo u izgradnji takvog sistema, već i u održavanju i migraciji sistema   na   nove   platforme.   Česta   je   praksa   da   se   sistem   modeluje   upotrebom   nekog   od metamodela   opšte   namene,   pri   čemu   je   najrasprostranjeniji   UML   (Unified   Modeling  Language). S obzirom na svoju opštost i obavezu da omogući  modelovanje širokog spektra softverskih proizvoda, UML često ne uspeva da na najbolji način opiše domenski specifične elemente   sistema,  što  dovodi  do  potrebe  za  definisanjem  jezika   i   skupa  alata  prilagođenih domenu   od   interesa.   Takođe,   zbog   složenosti   UML   metamodela,   nastaju   poteškoće   u automatskoj obradi modela i generisanju programskog koda za ciljnu platformu.

Postojeća MDE rešenja se najčešće bave samom tehnologijom izrade jezika ili kao svoj bazični jezik koriste UML. 

Prilikom razvoja jezika specifičnog za domen najčešće se, u izradi prototipa,  kreće od tekstualne sintakse i  tekstualnog editora  jer  izgradnja grafičkog editora predstavlja zahtevan posao   koji   se   najčešće   obavlja   u   poslednjim   fazama   izrade   kada   se   metamodel   dovoljno stabilizuje.

Predmet izrade magistarske teze sadrži sledeće:

• specifikacija   apstraktne   sintakse   (metamodela)   jezika   za   modelovanje   statičkih osobina poslovnih sistema. Jezik je nazvan DOMMLite.

• specifikacija konkretne tekstualne sintakse datog jezika.• implementacija prototipa tekstualnog editora modela.• implementacija prototipa generatora programskog koda za jednu ciljnu platformu.

Rad sadrži 5 poglavlja.

Prvo poglavlje daje pregled i analizu postojećeg stanja u oblasti koja obuhvata predmet istraživanja  ove   teze.  Opisani   su   tekući   trendovi   i   dat   je  pregled  najznačajnijih   standarda, tehnologija i alata u oblasti.

U drugom poglavlju dati su osnovni principi izrade kao i specifikacija DOMMLite jezika za modelovanje statičkih osobina poslovnih sistema. Metamodel je implementiran upotrebom ECore   metametamodela   uz   oslonac  na  xText  jezik.   U   cilju   lakšeg   razumevanja   elemenata jezika,  svi  metaelementi  su dodatno opisani  UML dijagramima klasa.  U ovoj celini  data   je specifikacija konkretne tekstualne sintakse DOMMLite jezika. Gramatika jezika je definisana upotrebom jezika  xText.

Treće   poglavlje   se   bavi   implementacijom   editora   modela   i   generatora   poslovnih aplikacija. Editor i generator su implementirani u integrisanom okruženju za razvoj Eclipse uz oslonac   na  OpenArchitectureWare  okvir   za   razvoj   generatora.   Ciljna   platforma   generatora programskog koda je okvir za razvoj  web  aplikacija  Django  koji je baziran na programskom jeziku Python.

Četvrto poglavlje predstavlja studiju slučaja u kojoj je izvršena verifikacija DOMMLite jezika   i   propratnih   alata.   Prikazana   je   specifikacija   i   implementacija   podsistema   za   upis kandidata na Fakultet tehničkih nauka.

Peto   poglavlje   predstavlja   analizu   postignutih   rezultata,   zaključke   i   pravce   daljih istraživanja i razvoja.

Želim da se zahvalim članovima komisije na sugestijama koje su doprinele da teza bude jasnija i preglednija.

Posebnu   zahvalnost   dugujem   svom   mentoru   prof.   dr   Branku   Perišiću   na   nesebičnoj pomoći i podršci u toku izrade teze.

Zahvaljujem   se   Mirjani   i   Aleksi,   mom   neiscrpnom   izvoru   inspiracije,   na   podršci, razumevanju i ljubavi koju su mi pružili.

Novi Sad, februar 2008. Autor

1. Uvodna razmatranja

1.1. Razvoj softverskog inženjerstva

1.1.1. Podizanje nivoa apstrakcije

Od početka razvoja kompjuterskih nauka, naučnici i inženjeri su kreirali apstrakcije da bi se zaštitili od kompleksnosti platformi sa kojima su radili. U početku su apstrakcije bile niskog nivoa i  programeri su morali  da rade sa konceptima kao što su registri,  programski brojač, instrukcija,  memorijska   lokacija.   Implementacija,  čak  i  prostih  algoritama,  bila   je  zahtevan posao, ali u početku to nije predstavljalo problem s obzirom na ograničene resurse sa kojima su računari raspolagali. Razvojem hardvera počeli su da rastu i zahtevi u poslovnom domenu što je dovelo do potrebe za implementacijom sve složenijih algoritama. Tekuće apstrakcije više nisu mogle da omoguće potreban nivo kvaliteta softvera kao ni brzine izrade. Da bi se prevazišla nastala situacija bilo je potrebno učiniti sledeći evolutivni korak u razvoju načina na koji se vrši izrada softvera. 

U   toku  50tih   godina  došlo   je   do  pomaka  nastankom prvih  programskih   jezika   treće generacije (FORTRAN, COBOL). Jezici treće generacije su, pored podizanja nivoa apstrakcije omogućili  široj  populaciji  programera da se bave ovom disciplinom što  je  dodatno ubrzalo produkciju softvera. Koncepti sa kojima programeri svakodnevno rade se sve više približavaju konceptima problemskog domena. Matematički problemi se rešavaju alatima koji nude prirodne strukture i mehanizme za tu namenu kao što su polinomi, matrice, skupovi. Programeri koji razvijaju softver za telekomunikacije   rade sa konceptima kao što su filter, atenuator signala, limiter   signala,   enkoder   itd.   Koncepti   mogu   biti   implementirani   kao   skup   bibliotečkih procedura (ili klasa, funkcija itd.) za korišćenje u opštim programskim jezicima (C, C++, Java itd.) ali je sve veća tendencija ka kreiranju jezika specifičnih za domen sa specifičnom, najčešće grafičkom, notacijom.

Razvoj softvera prate ciklusi smenjivanja pritisaka, nastalih usled povećanja složenosti i obima poslovanja,   i  perioda  u kojima  pritisci  popuštaju  usled  uvođenja  novih  mehanizama apstrakcije. Prema [Frankel03], ekonomska održivost se ogleda u tome koliko smo u stanju da proizvodimo sisteme čiji  će kvalitet i  trajnost biti u skladu sa cenom proizvodnje. Izgradnja visoko kvalitetnog softvera  koji   treba dugo da  traje  mora biti   skupa što  kao posledicu   ima činjenicu da smo često primorani da pravimo kompromise i da usklađujemo kvalitet, trajnost i 

1

Uvodna razmatranja

cenu. Po Frankelu ove tri variable se nazivaju varijable održivosti (viability variables).

Slika 1.1 ­ Varijable održivosti po Frankelu

Jedini način za popravku formule održivosti i usklađivanja željenog kvaliteta i životnog veka sa isplativom cenom jeste uvođenje novih pristupa koji se ogledaju u podizanju nivoa apstrakcije u cilju lakšeg sagledavanja i savladavanja kompleksnosti.

Prelaskom sa asemblerskih jezika na jezike treće generacije, pa zatim na jezike četvrte i pete  generacije,   jezike specifične za domen i  modelovanje   je   imalo za posledicu povećanje apstrakcionog jaza [Frankel03]. Sve više se udaljavamo od hardvera na kojem softver treba da se izvršava. Ukoliko bi alati morali, direktno iz specifikacije, da generišu mašinski kod, njihov posao bi bio veoma težak. Takvi alati bi bili veoma teški za proizvodnju i kasnije održavanje. Takođe, takvi alati bi morali da generišu mašinski kod za sve hardverske platforme na kojima softver treba da se izvršava. Da bi se smanjio apstrakcioni jaz uvedene su softverske platforme kao što su operativni sistemi, srednji sloj (middleware), virtuelne mašine i dr. Ovakve platforme su   najčešće  organizovane   slojevito   (operativni   sistem   koristi   servise   hardverske  platforme, virtuelna mašina koristi servise operativnog sistema itd.). Ovakva slojevita struktura je olakšala izgradnju   produkcionih   alata   jer   je   sada   potrebno   generisti   programski   kod   za   softversku platformu koja može biti implementirana za različite hardverske platforme. Virtuelne mašine idu korak ispred definišući virtuelni hardver koji se implementira iznad operativnog sistema što omogućava portabilnost između operativnih sistema. Iz toga sledi da se problem portabilnosti koda premešta na međuslojeve i ne opterećuje izradu aplikativnog softvera, odnosno, problem portabilnosti rešava proizvođač softverske platforme, dok se alat za razvoj proizvodi tako da koristi   servise   najčešće   samo   jedne   platforme   čime   se   pojednostavljuje   proizvodnja   i održavanje.

2

Uvodna razmatranja

Prema   [Atkinson02]   podizanje   nivoa   apstrakcije   je   bitan   faktor   u   poboljšanju   tzv. kratkoročne produktivnosti programera, mada je za postizanje dugoročne produktivnosti, koja se ogleda u povećanju životnog veka softverskih artifakta,  potrebno smanjiti  uticaj promena funkcionalnih zahteva na promene u implementaciji softverskog sistema.

1.1.2. CASE alati

Podizanje   nivoa   apstrakcije   uticalo   je   pozitivno   na   produktivnost   i   razumevanje softverskog sistema, ali prvi značajniji pomaci su, prema [Schmid06], nastali uvođenjem CASE (Computer­Aided   Software   engineering)   alata   tokom   80­tih   godina.   CASE   alati   su   nudili mogućnost definisanja rešenja priblema upotrebom vizuelnih jezika opšte namene kao što su dijagrami   toka podataka,  strukturni  dijagrami   i  dijagrami  stanja­prelaza.  Jedan od osnovnih ciljeva CASE alata bio je da se omogući programerima da se fokusiraju na rešavanje problema profesionalnog domena i smanji uticaj kompleksnosti tehničkog domena i problema koji su iz toga   proizilazili   (npr.   “curenje”   memorije   i   sl.),   a   koji   su   bili   povezani   sa   klasičnim programskim  jezicima  kao  što   je,   na  primer,  C.  I   pored  velike  pažnje  koju   su  privukli  u literaturi, kao i značajnih mogućnosti za to vreme, u praksi su CASE alati doživeli neuspeh. Razlozi se uglavnom pronalaze u: 

• pokušaju alata da upotrebom jezika opšte namene rešava probleme u veoma različitim domenima primene, što ih je, za pojedine domene, činilo nepraktičnim,

• nepostojanju tehnologija srednjeg sloja (middleware) čime su mnogi servisi morali biti nadoknađeni samim alatom što ih je činilo teškim za implementaciju i održavanje, 

• teškoćama u mapiranju dizajna sistema na postojeće platforme koje su uglavnom bile jednokorisničke i izvršavale su se na jednom računaru.  Količina koda potrebna da bi se savladao   apstrakcioni   jaz   između   specifikacije   i   ciljne   implementacije   bila   je   van domašaja   transformacionih   tehnologija   toga   doba   što   je   imalo   za   posledicu komplikovanu izgradnju CASE alata, kao i debagovanje i kasnije održavanje aplikacija generisanih njihovom upotrebom,

• nepostojanju   elemenata   kvaliteta   servisa   (Quality   of   Sevice   –   QoS)   u   postojećim operativnim sistemima je zahtevalo generisanje velike količine kompleksnog koda što je bilo izvan domašaja tehnologija toga vremena,

• lošoj skalabilnosti alata  jer, generalno, alati nisu podržavali konkurentan razvoj i bili su ograničeni   na  upotrebu   od   strane   jedne  osobe   ili   tima  koji   bi   serijalizovao   pristup fajlovima korišćenih od strane alata,

• korišćenju  vlasničkih   (proprietary)   formata   i  protokola  usled  nepostojanja  otvorenih 

3

Uvodna razmatranja

standarda   je   onemogućilo   integraciju   aplikacija   razvijenih   upotrebom   CASE   alata različitih proizvođača,

• nametanje svojih jezika i notacija bez mogućnosti izmene.

Najveću penetraciju CASE alati doživeli su u oblasti telekomunikacija, pre svega u obradi poziva, jer su se dijagrami stanja­prelaza dobro mapirali na implementacionu platformu. CASE alati  su omogućavali  automatsku izradu većeg dela  aplikacije,  ali   je  preostali  deo,  najčešće specifičan   za   konkretnu   aplikaciju,   bilo   veoma   teško   ili   čak   i   nemoguće   implementirati upotrebom   alata,   dok   je   integracija   sa   ručno   kreiranim   rešenjima   bila   komplikovana. Najmasovniju  upotrebu  CASE alati  su  imali  u  domenu  inicijalnog  dizajna   i  dokumentacije sistema koja bi kasnije služila programerima za ručni razvoj sistema.  Održavanje dijagrama najčešće nije pratio razvoj programskog koda tako da bi, naročitu u kasnijim fazama razvoja softvera, primena CASE alata gubila na značaju.

1.1.3. Jezici četvrte i pete generacije

Jezici četvrte generacije (4GL) su se razvijali u periodu od 70­tih do 90­tih godina prošlog veka. Osobina ovih jezika je da koriste konstrukcije na visokom nivou apstrakcije. Najčešće se manipuliše   konceptima   iz   domena   problema.   Prema   [Heering02]   jezici   četvrte   generacije predstavljaju jezike specifične za domen čija je primena uglavnom vezana za aplikcije za rad sa bazama podataka tj. predstavljaju podskup jezika specifičnih za domen. Iako je donekle tačno da su se 4GL koristili najviše u izradi apliakcija za rad sa bazama podataka razvijeni su i 4GL za druge primene kao što su web razvoj, izrada izveštaja, analiza podataka, razvoj grafičkih korisničkih interfejsa itd. [Wiki – 4GL] 

Jezici pete generacije (5GL) su dobili na popularnosti tokom 90­tih godina prošlog veka. Osnovna ideja na kojoj se baziraju je da se program ne definiše algoritmom već se zadaje niz ograničenja   koja   definišu   problem   a   zatim   se   automatizovanim   procedurama   dedukuje algoritam   koji   problem   rešava.   Upotreba   5GL­ova   u   projektima   velikog   obima   je   otkrilo osnovne probleme koji  su sprečili  njihovo dalje  širenje.  Najveći  problem je činjenica da je izrada automatizovane procedure koja će generisati optimalan algoritam na osnovu postavke problema u vidu niza ograničenja,  sama po sebi,   teško rešiv problem. Danas se  jezici  pete generacije   najviše   koriste   u   istraživanjima   u   oblasti   veštačke   inteligencije.   Najpoznatiji predstavnik ove generacije jezika je Prolog [Colmerauer92].

4

Uvodna razmatranja

1.1.4. Napori na polju standardizacije

Uvođenje standarda u domenima inženjerskog delovanja je od krucijalnog značaja za dalji napredak. Problemi koji nastaju nepostojanjem standarda u oblasti informacionih tehnologija su jedan od osnovnih razloga neuspeha CASE alata (videti  1.1.2). Da bi omogućio brži razvoj u domenu tehnologija upravljanih modelima, najveći svetski konzorcijum u domenu softverskog inženjerstva   i   informacionih   tehnologija   –   OMG   (Object   Management   Group)[OMG],   je preduzeo značajne korake u standardizaciji bazičnih tehnologija i protokola. Između ostalih, sve tehnologije organizovane oko MDA pristupa (videti 1.3.2) su propisane standardima od strane ove organizacije. Obično su potrebne godine da bi inicijative ovoga tipa zaživele ali, kada je u pitanju OMG i MDA pristup, najveće svetske softverske firme u potpunosti podržavaju MDA i standarde koji ga čine (UML, MOF, XMI itd.). Najvažniji standardi su registrovani u okviru tradicionalnih   organizacija   za   međunarodnu   standardizaciju   kao   što   je   ISO   (International  Orgranization for Standardization).

Osim bazičnih tehnologija, značajni napori uloženi su u standardizaciji tzv. vertikalnih domena kao što su npr. zdravstvo, finansije, telekomunikacije, edukacije. U radu [Anido02] je prikazan razvoj e­learning sistema sa osvrtom na standardizaciju vertikalnog domena.

1.2. Osnovni pojmovi, koncepti i tehnike

1.2.1. Sistem

Prema [Miller95] :

“Sistem   predstavlja   skup  elemenata  u   interakciji   i   relacije   između   njih.   Reč   'skup' nagoveštava da elementi imaju neke srodne osobine koje su esencijalne da bi elementi stupali u interakciju   ili   imali  definisane relacije.  Stanje svakog elementa je ograničeno,  uslovljeno ili zavisno od stanja drugih elemenata. Elementi su spregnuti.”

Sa stanovišta analize sistema bitna je konstatacija izneta u [Checkland98]:

“... kada god imamo sistem koji opslužuje drugi sistem to je osnovni princip da sistemi shvataju da se osnovne osobine sistema koji služi mogu definisati samo na osnovu prethodnog saznanja o sistemima koji će biti služeni.  Ovo mora biti   tako jer će priroda sistema koji se opslužuje određivati šta se smatra 'servisom' i samim tim koje funkcije sistem koji pruža servis 

5

Uvodna razmatranja

mora da sadrži.”

Na osnovu ove konstatacije sledi da se sistem ne može posmatrati i analizirati u izolaciji već samo u sadejstvu sa drugim sistemima iz svoga okruženja.

1.2.2. Model

Prema   [MDAGuide]   model   predstavlja   opis,   ili   specifikaciju   sistema   i   njegovog okruženja   kreiranu   za   određenu  namenu.  Najčešće   je   model   predstavljen   kao  kombinacija crteža i teksta. Tekst može biti zadat jezikom za modelovanje ili prirodnim jezikom.

Ova definicija je dosta štura i neprecizna. U radovima ATLAS grupe [Bézivin01b], model se definiše na sledeći način:

“...Model  predstavlja  pojednostavljenje   sistema sa određenim ciljem.  Model   treba da  odgovori na pitanja umesto stvarnog sistema. Odgovori dobijeni od modela moraju da budu  isti   kao   i   oni   dobijeni   od   realnog   sistema,   pod   uslovom   da   se   pitanja   nalaze   u   domenu  definisanom ciljem modela. Da bi bio koristan model mora biti jednostavniji za upotrebu od  realnog   sistema.   Da   bi   se   ovo   postiglo   mnogi   detalji   realnog   sistema   su   apstrahovani   i  izostavljeni. Ovo pojednostavljenje je srž modelovanja...”.

Druga   definicija   preciznije   definiše   pojam   modela   ne   potencirajući   načine   njegove reprezentacije.   Model   ne   predstavljaju   samo   crteži   i   tekstualni   opisi.   Model   može   imati materijalnu   formu npr.  može  biti  model/maketa  aviona,  pojednostavljena  verzija  motora  sa unutrašnjim sagorevanjem itd. Zapravo, apstrakcija i namena, tj. skup pitanja na koje želimo da dobijemo odgovore, su osnovne karakteristike modela. Takođe, ne možemo, u opštem slučaju, očekivati da će model dati potpuno iste odgovore kao modelovani sistem ali možemo očekivati da razlike (greške) budu u projektovanim granicama.

1.2.3. Platforma

Prema MDA vodiču [MDAGuide] platforma predstavlja skup podsistema i tehnologija koji pružaju koherentan skup usluga putem interfejsa i propisanih načina upotrebe, koje sve aplikacije podržane tom platformom mogu koristiti,  bez potrebe da imaju saznanje o načinu implementacije pruženih funkcionalnosti.

Kada   se   priča   o   platformi   najvažniji   koncept,   u   okviru   tehnologija   baziranih   na modelovanju,  jeste platformska nezavisnost.  Platformska nezavisnost je relativan pojam koji 

6

Uvodna razmatranja

predstavlja kvalitativnu osobinu koju model može da poseduje iskazanu u nezavisnosti modela od osobina i funkcionalnosti koju ta platforma nudi. Prema tome, nije dovoljno reći da je model platformski nezavistan već je, na osnovu definicije, potrebno iskazati koji je to skup platformi od kojih je model nezavistan [MDAGuide, Frankel04, Frankel03].

Prema [Mellor04] postoje jezici nezavisni od softverske i jezici nezavisni od hardverske platforme.   Upotrebom   jezika   nezavisnih   od   hardverske   platforme   omogućeno   je   pisanje specifikacija koje se mogu prenositi između različitih hardverskih platformi bez promene (C, C++, Java). Upotrebom jezika nezavisnih od softverske platforme moguće je pisati specifikacije koje   se   mogu   izvršavati   na   različitim   softverskih   platformama   ili   različitim   softverskim arhitekturama   bez   promene.   Primer   bi   bio   mapiranje   i   izvršavanje   specifikacije   (modela) aplikacije   na   višeprocesorskom/višekorisničkom   CORBA   okruženju   ili   na   klijent­server arhitekturi sa relacionom bazom podataka bez promene u modelu.

S obzirom da se prilikom modelovanja mora krenuti od skupa pretpostavki o platformama na   kojima  će   se   model   izvršavati  mora  postojati   mehanizam  putem   kojeg   ćemo  postupak modelovanja ograničiti na skup osobina i funkcija dostupnih na platformama predviđenim za implementaciju.  Neki   autori   [Almeida04]  predlažu  kreiranje   apstraktne  platforme   (Pa)  koja definiše   skup   koncepata   i   servisa   dostupnim   na   svim   platformama   na   kojima   se   planira implementacija   (P1..Pn).   Kreiranje   modela   koji   bi   bili   vezani   za   ovakvu   platformu   jeste platformski  nezavisno od  konkretne  platforme na  kojoj  će   sistem biti   implementiran  ali   je model vezan za datu apstraktnu platformu. Ukoliko bismo želeli  da migriramo model M na novu platformu Pk, koja nije inicijalno uzeta u obzir, i na kojoj nema nekih od koncepata ili servisa polazne apstraktne platforme, i ne postoji jednoznačno mapiranje tih servisa i koncepata na   druge   koncepte   platforme   Pk,  morali   bismo   da   ručno   modifikujemo   model   tako   da nepostojeće   koncepte   i   servise   nadomestimo   korišćenjem   postojećih.   Ukoliko   bi   postojalo jednoznačno preslikavanje koncepata polazne platforme Pa na koncepte nove platforme tada bi ovaj postupak mogao da se automatizuje.

7

Uvodna razmatranja

1.2.4. Poslovna aplikacija

Prema [Wiki­PosAp] poslovna aplikacija predstavlja softver čija je namena merenje ili povećanje produktivnosti unutar poslovnog sistema. 

Smatramo da   je  ova  definicija  nedovoljno  precizna  pa  ćemo,  u  kontekstu  ovog rada, koristiti sledeću definiciju poslovnog sistema:

Definicija: Poslovni sistem  predstavlja softver koji podržava tehnologiju procesa rada poslovnog sistema/podsistema ili poslovne funkcije.

1.2.5. Metamodelovanje

Model  predstavlja   apstrakciju   realnog   sistema.  Metamodel   je   eksplicitna   specifikacija apstrakcije. Da bi definisao apstrakciju metamodel identifikuje relevantne koncepte i relacije između   njih.   Ovakve   specifikacija   se   još   naziva   i   terminologijom.   U   nekim   slučajevima terminologija   je  dovoljna  ali   se  često  mora  upotpuniti   nizom  logičkih   iskaza  koji  definišu ograničenja [Bézivin01b]. Metamodelovanje je proces kreiranja metamodela.

Metamodelovanje   se   u   nekim   sferama   ljudske   aktivnosti   naziva   još   i   semantičko modelovanje, kreiranje šeme ili standardizacija domena. Metamodeli se kreiraju za određeni domen imajući u vidu način primene. [metamodel.com].

Metamodeli se koriste:

• Kao šema za semantičke podatke koje je potrebno razmeniti.  Pre svega, tu su koreni metamodelovanja:  CDIF   (CASE Data   Interchange  Format)   –   za   razmenu  podataka između CASE alata (kasnije je tu ulogu preuzeo UML/XMI),  STEP (Standard for the  Exchange of Product model data) – za razmenu industrijskih dizajn podataka i XML Shema.   Takođe   i   kao   šema   za   semantičke   podatke   koje   treba   sačuvati   npr.   u repozitorijumu.

• Kao jezik za podršku određenoj metodologiji ili procesu, što je uostalom i bila prvobitna namena   UML   jezika,   ali   se   kasnije   počeo   koristiti   i   za   razmenu   i   skladištenje informacija  koji  su doveli  do određenih  problema koje   je   trebalo   razrešiti   izmenom metamodela.

• Kao jezik za opis dodatne semantike postojećih podataka. Primer bi bili pokušaji da se informacije na web­u učine razumljivijim ­ Semantički web.

8

Uvodna razmatranja

Poslednjih godina evidentni su uspesi u istraživanjima čiji   je cilj  formalno definisanje metamodela (videti 1.2.8).

Kod modelovanja pojava stvarnog sveta potrebno je definisati i smisao koje pojava ima u kontekstu metamodela.  U zavisnosti  od korišćenog metamodela   ista  stvar  iz  stvarnog sveta može imati potpuno drugačije značenje. Na primer, ukoliko posmatramo crtež koji se sastoji od prostih geometrijskih oblika: krug, pravougaonih, linija itd, za jedan metamodel koji se bavi crtanjem geometrijskih figura to će upravo imati smisao kruga, pravougaonika itd. sa svojom veličinom, pozicijom i ostalim relevantnim osobinama za dati metamodel. Ali ukoliko isti crtež posmatramo   u   kontekstu   metamodela   koji   se   bavi   opisima   poslovnih   procesa,   i   njemu pridružene   konkretne   grafičke   sintakse,   tada   elementi   crteža   mogu   imati   potpuno   drugo značenje: proces, tranzicija itd. Iz ovog primera je jasno da je od neizmerne važnosti, da bi se omogućila komunikacija, bilo osoba koje se bave modelovanjem u određenom domenu, bilo alata koji se koriste u tu svrhu, da se jednoznačno definišu korišćeni koncepti i relacije između njih odnosno da se kreira metamodel koji će svi učesnici u procesu modelovanja koristiti (tj. da se definiše korišćena ontologija domena u vidu metamodela – videti 1.2.7.1).

Neki od korisnika metamodelovanja:

• Proizvođači CASE alata – Ukoliko stigne zahtev od kupca da se u CASE alatu podrže osim klasa   i   interfejsi   tada  će  athitekta  alata  da  analizira  kakve  izmene  je  potrebno učiniti na internim strukturama podataka da bi se novi koncept podržao. U osnovi, on proširuje   meta­model,   bez   obzira   kako   on   ovu   aktivnost   naziva.   Interne   strukture podataka čine, u stvari, jedan oblik reprezentacije meta­modela.

• Proizvođači   repozitorijuma     metapodataka   o   razvoju   softvera.   Metamodel   u   ovom slučaju   predstavlja   šemu   repozitorijuma.   Najčešće   se   metamodeli   opisuju   na konceptualnom  nivou  a  ne  na   fizičkom pa   je  potrebno  uraditi   konceptualno­fizičko mapiranje   koje   zavisi   od   korišćene   tehnologije   repozitorijuma   (relacioni   model, objektno­relacioni model, objektni model, XML, itd.)

• Sistem   integratori   –   obavljaju   analizu   tipova   podataka   sistema   koji   se   integrišu   i njihovog   smisla   što   će   kao   rezultat   imati   kreiranje   semantičkog   modela,   odnosno, metamodela.

• Krajnji korisnici. Za evaluaciju softverskog proizvoda osim korisničkog interfejsa bitna osobina je i šta je sve moguće iskazati datim softverom tj. da li za naš domen od interesa softver ima mogućnost iskazivanja svih, za nas, relevantnih stvari tj. da li je podržani metamodel u skladu sa našim potrebama.

U radu [Atkinson02] autori predlažu sinergičan pristup metamodelovanju koji objedinjuje objektnu orijentaciju,  meta­nivoe i modelovanje i takav pristup naziva Objektno­orijentisano metamodelovanje (Object­oriented metamodeling)

9

Uvodna razmatranja

1.2.5.1. Četvoroslojna arhitektura – metanivoi

Većina standarda i pristupa u metamodelovanju organizuje metainformacije u slojeve koji se   nazivaju   metanivoi   (metalevels).   S   obzirom   da   je   najrašireniji   standard   u   domenu metamodelovanje MOF (videti  1.3.2.4), najčešće se u radovima na tu temu koriste podela i označavanje   definisane   ovim   standardom.   Prema   OMG­u   postoji   4   osnovna   metanivoa obeležena sa M0, M1, M2 i M3.

M0  (nivo   instanci)  definiše  konkretne   instance  objekata  u  vremenu   i  prostoru  unutar aplikacije koja se izvršava.

M1 (nivo modela) opisuje nivo M0 tj. predstavlja model instanci sa nivoa M0. Na primer, na ovom nivou, u kontekstu UML­a, možemo imati klasu “Osoba” koja ima atribute “ime”, “prezime” i “datumRodjenja” sa definisanim tipovima. Na nivou M0 ova klasa može imati više instanci   sa   konkretnim  vrednostima   atributa.  Sve   instance  koje   se   nalaze  na  nivou  M0,   u posmatranom sistemu, imaju svoj opis na nivou M1.

M2 (nivo metamodela) opisuje nivo M1. M2 nivo vrši klasifikaciju koncepata M1 nivoa. Ovaj  nivo predstavlja  metamodel   jezika  za modelovanje odnosno njegovu specifikaciju.  Na primer, na ovom nivou se opisuju UML koncepti kao što su Class, Attribute, State, Transition, Activity i dr. Svi elementi modela na nivou M1 moraju imati svoj opis na nivou M2. M2 nivo opisuje jezik za modelovanje, odnosno definiše njegovu apstraktnu sintaksu.

M3 (nivo metametamodela) najčešće je samodefinišući model koji se koristi za opis nivoa M2. Ovaj nivo postoji da bi omogućio specifikaciju više jezika za modelovanje.  Na primer, upotrebom koncepata sa M3 nivoa (npr. koncepti MOF­a) možemo definisati UML metamodel, ali isto tako možemo definisati i relacioni metamodel na nivou M2. Tako na primer instanca osobe sa nivoa M0 može biti opisana klasom “Osoba” sa nivoa M1, koja je dalje opisana UML konceptom “Class” sa nivoa M2 i na kraju UML klasa je opisana MOF konceptom “Class” sa nivoa M3.

Osobina da je M3 nivo samodefinišući je značajna, da broj nivoa ne bi bio beskonačan (bio bi potreban M4 za opis M3, M5 za opis M4 itd). Teoretski postoji beskonačno mnogo metanivoa, ali mehanizmom samodefinisanja nivoi iznad M3 jesu identični sa nivoom M3 čime je njihovo eksplicitno navođenje nepotrebno.

10

Uvodna razmatranja

Slika 1.2 ­ Metanivoi ­ paralela sa klasičnim programskim jezicima

Na   slici  1.2  prikazani   su   metanivoi   u   paraleli   sa   klasičnim   programskim   jezicima   i njihovim načinom izgradnje [Bézivin01a]. Možemo videti sa je M3 nivo na kome se nalaze metametamodeli ekvivalentan sa EBNF­om kada su klasični programski jezici u pitanju. Kao što se EBNF­om može definisati gramatika svih programskih jezika tako se metametamodelom mogu definisati svi metamodeli, odnosno apstraktne sintakse jezika za modelovanje. Ukoliko posmatramo gramatiku određenog programskog jezika (npr. Java), ona opisuje sve programe koje je moguće napisati na tom programskom jeziku. Isto tako određeni metamodel (npr. UML) opisuje   sve  moguće  modele  koji   se  mogu kreirati  upotrebom ovog  jezika  za  modelovanje. Dalje,   program   napisan   na   konkretnom   programskom   jeziku   definiše   beskonačno   mnogo konkretnih   izvršavanja   programa.   Isto   tako,   model   definiše   beskonačno   mnogo   njegovih konkretizacija, u vidu interpretiranja na virtuelnoj mašini ili prevođenja i izvršavanja na drugim izvršnim jezicima.

U knjizi [Frankel03] se diskutuje na temu da li metanivoi imaju smisla. Polazi se od česte prakse da se i metamodeli i modeli definišu istim alatom. Na primer, možemo upotrebom UML alata definisati metamodel (nivo M2) sa konceptima kao što su “Tabela”, “Kolona” itd. a zatim upotrebom istog alata kreirati UML M1 model sa klasama kao što su “Osoba”, “Racun” itd. Alat  nije  u   stanju da  razlikuje  ova dva modela  pa se postavlja  pitanje  koliko   je  apsolutno definisanje  nivoa  smisleno.  Prema autoru,  u  nekom teoretskom smislu,  apsolutna  definicija metanivoa je proizvoljna i samim tim besmislena, ali ipak u određenim praktičnim kontekstima apsolutno   definisanje   metanivoa   ima   smisla.   Pre   svega   su   apsolutni   metanivoi   bitni   u komunikaciji i razumevanju.

Drastičniji  primer  predstavlja  sam MOF (videti  1.3.2.4). MOF se nalazi  na M3 nivou pošto se koristi za opis svih jezika za modelovanje. S obzirom da je i sam jezik za modelovanje 

11

Uvodna razmatranja

(jezik za definisanje metamodela) on se istovremeno nalazi na M2 nivou. MOF sam po sebi jeste model pa se nalazi i na M1 nivou. Takođe se može reći  da se MOF nalazi i na svim nivoima iznad M3, koji nisu eksplicitno obeleženi, ali konceptualno postoje. Implementacija MOF specifikacije omogućava instanciranje MOF objekata na M0 nivou pa se MOF nalazi i na nivou instanci. Iz ovoga sledi da se MOF nalazi na svim nivoima istovremeno.

U   radu   [Atkinson03]   autori   se   osvrću   na   neke   probleme   koji   postoje   u   klasičnim arhitekturama za metamodelovane kao što je MOF. Pre svega problem je nepoznanica u kakvoj su vezi entiteti i koncepti realnog sveta sa modelima. Da li koncepti realnog sveta pripadaju steku  za  metamodelovanje   (nivou  M0)   ili   se  nalaze  van  njega?  Drugi  problem predstavlja jedinstveni tretman svih veza instanciranja što dovodi do nekonzistencije. O ovome je pisano i u [Bézivin01b, Kühne06a].

Kao rešenje problema autori, u sklopu svoje paradigme Object­Oriented Metamodeling,  predlažu novi pogled na stek za metamodelovanje. Klasične nivoe i veze instanciranja između njih   nazivaju   linvističkim   jer   su   definisane   samim   jezikom   za   (meta­)modelovanje.   Veze instanciranja koje postoje unutar samih lingvističkih nivoa nazivaju ontološkim ili logičkim i one su određenje logikom posmatranog domena (videti 1.2.5.2)

S obzirom na veliki broj različitih arhitektura za metamodelovanje dolazi do poteškoća, kako u korišćenju alata, tako i u njihovom kreiranju. U cilju jednostavnijeg izbora pristupa pri kreiranju alata kao i vrednovanja postojećih alata u radu [Atkinson05] je dat pregled koncepata i tehnika koji su danas u upotrebi.

1.2.5.2. Apstrakcija, klasifikacija, instanciranje i generalizacija

Model je pojednostavljena predstava realnog sistema kreirana sa određenim ciljem (videti 1.2.2).  Apstrakcija   je  proces  zanemarivanja  nebitnih   informacija  prilikom kreiranja  modela. Realni  sistemi  imaju  praktično beskonačno mnogo strukturnih osobina i  osobina ponašanja. Mnoge   osobine   realnih   sistema   nije   moguće   uočiti   i   formalno   ih   predstaviti.   Operacija apstrakcije   se  dešava na  prelasku  između  nivoa  M0  i  M1.  Vezu   između  nivoa  M0 (realni sistem)  i  M1 (model  sistema)  se u  literaturi  naziva  representationOf  [Bézivin06b]  u smeru M0>M1  ili  models[Kühne06a]   u   smeru   M1>M0.   Ovde   je   bitno   naglasiti   da   klasične infrastrukture za metamodelovanje (npr. MOF 1.4) ne definiše u kakvoj su vezi objekti realnog sveta   sa   modelima.   Na   nivou   M0,   se   kod   klasičnog   pristupa,   posmatraju   softverske reprezentacije objekata realnog sveta (npr, red u tabeli baze, objekat u memoriji itd.) dok se stvarni objekti kao što su ljudi, predmeti, događaji ne analiziraju eksplicitno.

12

Uvodna razmatranja

Objekti   realnih  sistema   se  mogu   grupisati   na  osnovu   zajedničkih   osobina.  Operacija grupisanja   se   naziva   klasifikacija   [Mellor04].   Klasifikacija   se   može   obavljati   u   okviru metanivoa.   Na   primer,   grupa   određenih   objekata   UML   objektnog   dijagrama   koja   opisuje konkrente   osobe   sa   imenom,   prezimenom   i   drugim   relevantnim   informacijama  definisanih apstrakcijom može  biti  klasifikovana   i  opisana  UML klasom.  Dakle,  klasifikacija   se  može obavljati unutar istog metanivoa ukoliko jezik (viši metanivo) to omogućava. Veza klasifikacije se može obavljati  i   između metanivoa,   tako se veza   elemenata  modela sa metaelementima može karakterisati  kao veza  klasifikacije.  Na primer  sve klase dijagrama klasa,  koji  koristi UML metamodel, su u vezi sa konceptom Class UML metamodela. U tom slučaju, klasifikacija je izvršena na osnovu osobina Class koncepta. Vezu možemo posmatrati i u obrnutom smeru i iskazati je kao instanciranje. Pa prema tome možemo da kažemo da je konkretna klasa UML dijagrama   instanca  Class  koncepta   definisanog   UML  metamodelom,   koji   je   dalje   instanca Class koncepta definisanog MOF metametamodelom. Ili, na primer, možemo reći da je stanje Uključen  koje   je   predstavljeno   na   dijagramu   stanja­prelaza   upotrebom   UML   metamodela, instanca State koncepta definisanog UML metamodelom, koji je dalje instanca Class koncepta definisanog MOF metametamodelom.

Koncept   koji   je   u   tesnoj   vezi   sa   klasifikacijom   jeste   generalizacija.   Generalizacija predstavlja kreiranje apstraktnih koncepata koji imaju za cilj opis zajedničkih osobina grupe koncepata. Za definisanje razlike između relacije klasifikacije i relacije generalizacije potrebno je   uvesti   pojmove   modela   tokena   i   modela   tipova   (token­model,  type­model)   koje   je   prvi definisao Čarls Sanders Pirs, a dalje se pojmovi razrađuju u kontekstu MDA u [Kühne06a, Kühne06b]. Modeli tokena predstavljaju modele konkretnih pojedinačnih pojava realnog sveta. U tom kontekstu model tokena bi, upotrebom UML­a, bio opisan dijagramom objekata. Dakle, modeli tokena nastaju isključivo procesom apstrakcije. Za razliku od njih, modeli tipova nastaju procesom   klasifikacije.   U   kontekstu   UML   dijagrama,   modeli   tipova   mogu   biti   opisani dijagramom klasa.  Proces generalizacije  se odvija unutar  modela  tipova na  taj  način  što se tipovi grupišu u apstraktne koncepte na osnovu zajedničkih osobina. Za tako kreirane koncepte kažemo da generalizuju posmatrani  skup koncepata,  odnosno posmatrani  skup koncepata se nasleđuje iz generalizovanog koncepta.  S obzirom da se generalizacija odvija u okviru jednog metanivoa,   viši   metanivo  mora   da  definiše  koncept   generalizacije.   U   okviru   MDE   većina modela su modeli tipova.

Primer naveden u [Mellor04] prikazuje postupak apstrakcije, generalizacije i klasifikacije na primeru grupe životinja. Konkretni psi i mačke se apstrakcijom predstavljaju kao objekti sa konkretnim vrednostima atributa (ime životinje, težina itd). Dalje se klasifikacijom grupišu u dve klase  Psi  i  Mačke  i zatim se procesom generalizacije kreira koncept  KućniLjubimac  koji definiše zajedničke osobine obe klase životinja. Iz tog koncepta (KućniLjubimac) se nasleđuju 

13

Uvodna razmatranja

pojedinačne klase (Psi i Mačke). Dakle generalizacija je mogućnost koja mora biti podržana od strane   jezika   za   modelovanje,   klasifikacija   je   podržana   od   strane   infrastrukture   za metamodelovanje (a može biti  podržana i od jezika za modelovanje kao što  je  to slučaj  sa UML­om), dok je apstrakcija uvek moguća, predstavlja esenciju modelovanja i ne zavisi od korišćenih jezika za (meta)modelovanje.

Problem   oko   koga   je   bilo   polemike   u   prošlosti   jeste   dualnost   entiteta   u   smislu   da predstavljaju istovremeno i tip i  instancu. Na primer,  UML  Class  koncept je instanca MOF Class koncepta, ali je istovremeno tip iz koga se instanciraju konkretne klase na nivou M1 (npr. Osoba).   Neki   istraživači   predlažu   uvođenje   koncepta   koji   to   eksplicitno   prikazuje   –   tzv. clabject [Atkinson00].

Takođe,  kao čest problem navodi  se  i  problem višestrukog instanciranja.  Da li  entitet modela može biti instanca više drugih entiteta. Primer bi bio konkretan UML objekat koji je istovremeno instanca konkretne UML klase, ali je takođe i instanca metaelementa UML:Object iz UML metamodela. Slika 1.3 daje prikaz ove situacije.

Slika 1.3: Problem dvostrukog instanciranja

Ova   situacija   se   razrešava   razlikovanjem   veze   instanciranja   između   metanivoa   od instanciranja unutar metanivoa. Prema [Bézivin01b], instanciranje unutar metanivoa naziva se lokalno   i  definisanog  je   samim  jezikom za  modelovanje.   Instanciranje  koje  prelazi  granice metanivoa naziva se globalno i podržano je samom infrastrukturom za metamodelovanje (npr. MOF). 

Drugi autori ([Atkinson03, Atkinson05]) idu korak dalje i predlažu novi pogled na stek za metamodelovanje, gde osim tzv. lingvističke podele po nivoima (M0­M3) predlažu eksplicitno uvođenje ortogonalne ontološke ili logičke podele u okviru jednog lingvističkog nivoa. Na slici 1.4 je prikazana podela na ontološke nivoe biološke klasifikacije živih bića.

14

Uvodna razmatranja

Slika 1.4: Podela na ontološke nivoe prilikom biološke klasifikacije živih bića

Uvođenjem   ovakve   podele   se   jednostavnije   definiše   razlika   između   klasifikacije­instanciranja   i  generalizacije.  Generalizacija  predstavlja  relaciju  klasifikovanja   tipova prema zajedničkim osobinama unutar  jednog ontološkog nivoa.  Važno je primetiti  da zbog razlike između generalizacije i instanciranja možemo da tvrdimo da je Marko Homo sapiens, primat, sisar itd. ali ne možemo da tvrdimo da je Marko vrsta i biološki stepen.

Na slici  1.5  je prikazan stek za metamodelovanje sa klasičnom lingvističkom podelom postavljenom   vertikalno   i   ontološkom   podelom   postavljnom   horizontalno.   Problem instanciranja   sada   se   definiše   kao   ontološko   instanciranje   (između   ontoloških   nivoa)   i lingvističko instanciranje (između lingvističkih nivoa)

15

Uvodna razmatranja

Slika 1.5: Ontološka i lingvistička klasifikacija

Takođe vidimo da se veza između M0 i M1 lingvističkog nivoa ne posmatra kao veza instanciranja već veza reprezentacije jer konceptualno ne možemo reći da je entitet ili koncept realnog sveta instanca modela.

1.2.6. Reprezentacija modela - konkretne vizuelne i teksutalne sintakse

Model predstavlja apstraktan koncept. Da bi smo mogli da ga definišemo, analiziramo, ažuriramo i   transformišemo,  potrebno  je  da  postoji  način  njegove konkretne  reprezentacije. Obično se, kada se priča o modelima, zamišljaju dijagrami tj.  vizuelna notacija sa kojom se model opisuje. Razlog možemo tražiti u činjenici da čovek jednostavnije stvari shvata vizuelno jer je takav način rada za njega prirodniji. Ipak, pored svih prednosti vizuelnih notacija, postoje i izvesni domeni u kojima su tekstualne notacije pogodnije za primenu. Možemo primetiti da su određene stvari  u grafičkim notacijama opisane tekstom. Na primer,  ako posmatramo UML dijagram klasa, nazivi klasa, atributi, nazivi asocijacija i uloga su predstavljeni tekstom. Takođe 

16

Uvodna razmatranja

su tekstom, upotrebom OCL jezika,  opisana i ograničenja modela.   Očigledno je da su neki koncepti   pogodni   za   opis   crtežima,   dok   se   drugi     ipak   jednostavnije   iskazuju   tekstualno. Najčešće  se crtežom opisuju  osnovni  koncepti   i   relacije  koji  čine  strukturu  modela  dok se koncepti  koji   intuitivno nemaju  reprezentaciju  u obliku crteža,  već   je  češća upotreba reči   i brojeva,   opisuju   tekstom.   Takođe   se   tekstom   opisuju   pravila   i   strukture   koje   su   previše kompleksne za efikasno iskazivanje upotrebom crteža (npr. OCL). 

Pored  grafičke  predstave  modela,  često   je  u  upotrebi   tekstualna  predstava  upotrebom formalno definisanog jezika. Prednosti ovakvog pristupa su najčešće tehničke prirode a to su:

• jednostavnije kreiranje i ažuriranje ­ nije potreban specijalizovan alat već običan editor teksta,

• modeli se jednostavno mogu mašinski obrađivati upotrebom klasičnih parsera za koje postoji dobro razrađena podrška u alatima,

• dobra   skalabilnost   razvoja   je   potpomognuta   mogućnošću   paralelnog   rada   jer   se integracija   modela   može   vršiti   upotrebom   standardnih,   tekst   baziranih,   sistema   za kontrolu verzija kao što su CVS i Subversion [CVS, SVN],

• pogodno za prototipski razvoj ­ editori sa podrškom za bojenje sintakse, dopunu koda i navigaciju se mogu automatski generisati.

• tekstualne   notacije,   potencijalno,   predstavljaju   pristup   koji   omogućava   jezgrovito iskazivanje kompleksnih struktura  ili  procesa,  uz potencijalnu opasnost u vidu lošije čitljivosti   u   odnosu   na   grafičke   notacije,   o   čemu   se   mora   voditi   računa   prilikom dizajniranja konkretne tekstualne sintakse.

OMG je razvio dva standarda kada su u pitanju teksutalne notacije. Prvi, koji je razvijen ranije, je XMI (XML Metadata Interchange) i predstavlja mapiranje MOF metametamodela na XML [XMI].  Drugi standard je HUTN (Human­Usable Textual Notation)   i  namenjen je za kreiranje tekst baziranih jezika za opis modela pogodnih za ljudsku upotrebu [HUTN]. Ideja XMI standarda bila je mašinska interoperabilnost između alata za modelovanje. S obzirom na namenu i činjenicu da je baziran na XML­u, XMI nije pogodan za ažuriranje od strane ljudi zbog svoje “guste” sintakse. U početku je bilo problema u interoperabilnosti usled nedovoljne definisanosti standarda što je imalo za posledicu različito tumačenje i implementacije. Danas XMI predstavlja najrašireniji standard za razmenu modela između alata za modelovanje i svi vodeći alati i proizvođači softvera ga podržavaju.

Zbog potrebe da se modeli definišu tekstualno i činjenice da XMI nije pogodan za ručno pisanje   OMG   je   definisano   HUTN   standard   koji   predstavlja   mapiranje   MOF   modela   na tekstualnu notaciju.  Kao i u slučaju UML grafičke notacije,   tekstualna notacija sa kojim se opisuju modeli kod HUTN­a je propisana. S obzirom da je HUTN, u vreme pisanja ovog teksta, 

17

Uvodna razmatranja

bio relativno nov standard nije postojala veća podrška u alatima za modelovanje.

Popularan   pristup,   kada   su   u   pitanju   jezici   specifički   za   domen,   jeste   definisanje namenske grafičke ili tekstualne sintakse. U domenu grafičkih notacija, kada su alati otvorenog koda u pitanju, najdalje se otišlo sa projektom GMF (Graphical Modeling Framework) koji predstavlja podprojekat eclipse platforme [GMF]. Upotrebom GMF­a moguće je, na osnovu metamodela   domena   i   dodatnih   konfiguracionih   modela   generisati   grafički   editor   koji   će koristiti proizvoljno zadatu grafičku notaciju. Na ovaj način, generisani editori su upotrebljivi u praksi i uz određene ručne dorade mogu se koristiti u produkcionom okruženju, ali su još uvek po kvalitetu i upotrebljivosti dosta daleko od ručno pravljenih grafičkih editora.

Kao što GMF služi za generisanje grafičkih editora tako postoje i generatori tekstualnih editora. U ovom pravcu najdalje su otišli članovi ATLAS grupe koji su definisali TCS (Textual  Concrete Syntaxes) alat sa kojim je moguće na osnovu metamodela i gramatičkih pravila, koji takođe može biti iskazan tekstualno upotrebom KM3 tekstualnog jezika za opis metamodela, generisati   funkcionalan   editor   sa   bojenjem   sintakse,   dopunom   koda   i   sl.   [Jouault06b, Jouault06c,  Bézivin06b].   Takođe   je   značajan   i   alat   xText   koji   se   razvija   kao   deo openArchitectureWare  alata   za  MDSD unutar   eclipse  platforme.  Slično  alatu  TCS  i  xText omogućava definisanje konkretne tekstualne sintakse upotrebom jezika sličnog BNF­u a zatim se generisanje editora obavlja u većoj meri automatizovano [OAW].

U vreme pisanja ovoga teksta  eclipse fondacija   je očekivala  predloge za projekat  pod nazivom TMF (Textual Modeling Framework) čiji je cilj definisanja okvira za izgradnju jezika za modelovanje upotrebom tekstualnih notacija [TMF].

1.2.7. Formalne tehnike definisanja semantike

Fundamentalni  principi  metamodelovanja  su bazirani  na  oblastima   ljudskog delovanja kao   što   su   filozofija,   matematika   i   lingvistika.   Stoga   će,   u   cilju   lakšeg   praćenja   izložene materije u nastavku teksta, u ovom odeljku biti ukratko opisani osnovni konceptualni alati i formalne tehnike definisanja semantike.

1.2.7.1. Ontologije

Otologija predstavlja nauku o biću i postojanju. Reč je grčkog porekla od   (otos –ὄντος  biće) i λογία (logija – nauka). Bavi se definisanjem osnovih kategorija i relacija postojanja u cilju opisivanja entiteta i tipova entiteta pojavnog sveta.  Može biti domenski zavisna ukoliko je 

18

Uvodna razmatranja

ograničena na određeni domen postojanja ili domenski nezavisna tj. opšta [Poli03]

U  računarskim  naukama  ontologija  predstavlja  model  podataka  koji   opisuje   domen   i koristi se za donošenje zaključaka o objektima u domenu i relacijama između njih. Koristi se u veštačkoj   inteligenciji,   semantičkom  web­u  i   arhitekturi   informacija   kao   vid   reprezentacije znanja o svetu koji nas okružuje ili nekom njegovom delu. Ontologija opisuje:

• Individue ili instance• Klase: kolekcije/skupove ili tipove objekata• Atribute: osobine, karakteristike ili parametre koje objekti mogu da imaju ili dele• Relacije: načine na koji objekti mogu biti u vezi sa drugim objektima

Instance (individue) su osnovni elementi ontologije. Mogu biti konkretni objektni kao što su osobe, životinje, planete, automobili itd. ali i apstraktne instance kao što su brojevi, reči, događaji, osećanja itd. Ontologija ne mora da sadrži ni jednu instancu jer je osnovna namena ontologije klasifikacija instanci čak iako instance same nisu deo ontologije.

Klase (koncepti) predstavljaju apstraktne skupove ili kolekcije objekata nastalih procesom klasifikacije. Mogu da sadrže individue, druge klase ili kombinaciju. Primeri: Osoba, Molekul, Broj, Klasa, Stvar itd.

Tom Gruber [Gruber95] definiše ontologiju, u kontekstu predstave i deljenja znanja, kao specifikaciju konceptualizacije. Konceptualizacija je apstraktan, dakle pojednostavljen pogled na svet (odnosno njegov određeni deo), koji želimo da prikažemo sa određenim ciljem. Dakle, ontologija je formalan opis koncepata i relacija koje mogu postojati između njih za agenta ili grupu agenata. Gruber pod agentom podrazumeva softverske agente, ali se iskaz može uopštiti na bilo  koje aktivne  učesnike  u komunikaciji  unutar  posmatranog domena.  Ontologijom se definišu pravila komunikacije između agenata u cilju razmene   znanja     unutar   posmatranog domena. Smatra se da agent “poseduje znanje” ako raspolaže informacijama i racionalno se ponaša sa stanovišta postavljenog cilja.

Ontologija   je  u   tesnoj  vezi   sa  pojmom kontrolisanog   rečnika   (controlled  vocabulary)[metamodel.com].   Kontrolisan   rečnik   predstavlja   rečnik   termina   sa   jasno   definisanim, neredundantnim značenjem svih termina koji se održava od strane posebnog registracionog tela (registration authority). Ontologija se može definisati i kao jezik, opisan jezikom za definisanje ontologija   koji   koristi   reči   iz   kontrolisanog   rečnika   i,   putem  gramatike,   definiše   šta   znači ispravan iskaz, pitanje itd. (well­formed statement, query etc.)

Prema [Đurić04], postoje napori u stvaranju sprege između istraživanja koja se izvode u domenu ontologija i domenu MDA. OMG je pokrenuo inicijativu za definisanje platforme za 

19

Uvodna razmatranja

razvoj ontologija koja bi se sastojala od metamodela za opis ontologija (Ontology Definition  Metamodel), profila za UML i skupa transformacija.

Najpoznatiji formalni jezici za definisanje ontologija su:

• OWL (Web Ontology Language) koji je nastao na bazi starijih jezika RDF i RDFS­a [RDF, OWL]

• KIF (Knowledge   Interchange Format)  koji   je  definisan  kao  sintaksa  za  predikatsku logiku prvog reda [KIF]

1.2.7.2. Predikatska logika prvog reda

Predikatska logika prvog reda (PLPR) predstavlja formalni logički sistem za formulisanje validnih argumenata, definisanje logičkih iskaza i dedukciju zaključaka. 

Rečnik PLPR se sastoji od:

• predikatskih varijabli ili relacija (npr. P, Q, R), • skupa konstanti (a, b, c), • skupa funkcija (npr. f, g, h)• beskonačnog skupa varijabli (x, y, z, ...)• logičkih operatora (  ¬ ­ ne,  ∧ ­ i,  ∨ ­ ili,   → ­ logički kondicional,  ↔ ­ 

logički bikondicional)• kvantifikatora ( ∀ ­ za svako,  ∃ ­ postoji)• otvorenih i zatvorenih zagrada

Klasičan primer upotrebe PLPR u definisanju argumenta je

∀ x Čovek x Smrtanx

Čovek Sokrat

∵Smrtan Sokrat

Gde se prva dva iskaza u klasičnoj logici nazivaju pretpostavke i prevedeno na prirodni jezik glasile bi: “Svaki čovek je smrtan”, “Sokrat je čovek”. Poslednja rečenica je zaključak i glasi “Prema tome, Sokrat je smrtan”. Ukoliko su pretpostavke tačne i ukoliko je argument validan, tada zaključak mora biti tačan [Magnus07, SEP07] 

20

Uvodna razmatranja

1.2.7.3. Konceptualni grafovi

Konceptualni grafovi [Sowa84, Bezvin01b] predstavljaju koherentan sistem za grafičku reprezentaciju logike (egzistencijalni grafovi). Definisani su početkom 20. veka od strane Čarla Sandersa  Pirsa,  poznatog  američkog  matematičara,   fizičara   i   filozofa.  Konceptualni  grafovi predstavljaju mehanizam za opis koncepata i veza između njih. 

Primer:  činjenica  da kompanija  JAT zapošljava  Marka Markovića može se opisati  na sledeći način upotrebom tekstualne sintakse za zadavanje konceptualnog grafa.

[Kompanija: JAT]  (zap) [Zaposleni: Marko Marković]

Iz primera se može uočiti da konceptualni grafovi definišu osnovne pojmove (koncepte) i relacije   između   njih.   U   ovom   slučaju   kocepti   su   “JAT”   i   “Marko   Marković”   a   relacija uspostavljena   između   njih   je   “zap”   (zapošljava).   Iz   primera   takođe   možemo   videti   da   se koncepti   klasifikuju.   Koncept   “JAT”   pripada   klasi   “Kompanija”   dok   koncept   “Marko Marković” pripada klasi “Zaposleni”. Osim tekstualne konceptualni grafovi imaju i grafičku notaciju što je prikazano na slici 1.6.

Slika 1.6: Primer konceptualnog grafa

U [Amati00] je pokazano je da postoji jednoznačno preslikavanje između konceptualnih grafova i predikatkse logike prvog reda tako da se u literaturi sreću i jedan i drugi pristup u opisivanju posmatranog domena. 

1.2.8. Formalna definicija steka za metamodelovanje

Da   bi   se   uspešno   shvatile,   savladale   i   koristile   tehnike   razvoja   softvera   upravljane modelima, pre svega procesi mašinskog tumačenja modela domena, od krucijalnog značaja je postaviti temelje u vidu formalnih, matematički preciznih, definicija.

U prethodnih 10 godina je bilo dosta polemike oko osnovne postavke definicije steka za metamodelovanje.  Često su se definicije bazirale na intuiciji   i  nije bilo uspeha u korišćenju formalnih  matematičkih  metoda   za  opis   osnovnih  pojmova.  Tek   se   u   prethodnih  nekoliko godina, pre svega u radovima ATLAS grupe [Bézivin01b, Jouault06a,  Bézivin06b], dolazi do uspeha u formalnom definisanju steka za metamodelovanje. Formalne metode koje se koriste u definisanju steka za metamodelovanje su usmereni multigrafovi i predikatska logika prvog reda 

21

Uvodna razmatranja

i glase:

Definicija 1. Usmereni multigraf  G=(NG, EG, ГG) se sastoji od skupa čvorova  NG, skupa  veza  EG i funkcije  ГG :   EG NG x NG.

Definicija 2. Model M=(G, ω, μ) je uređena trojka gde je:

• G=(NG, EG, ГG)  usmereni multigraf•    je model   (koji se naziva referentni model modela M) pridružen grafu   Gω  

ω=(Nω, Eω, Гω)• μ  :   NG ∪   EG   Nω   je funkcija koja pridružuje čvorove i veze grafa G sa 

čvorovima grafa  Gω.

Relacija između modela i referentnog modela se naziva usklađenost, kažemo je model M u skladu sa  modelom    ω (M conformsTo  ω ili M c2 ω).   Elementi modela        ω se nazivaju metaelementi. Funkcija μ nije injektivna jer više elemenata modela M (čvorova i veza grafa G) mogu biti preslikani na isti elemenat modela   ω , niti je sirjektivna tj. ne moraju svi metaelemeti da imaju elemente modela koji se na njih preslikavaju.

Na osnovu defnicija 1 i 2 se definiše stek za metamodelovanje kao:

Definicija 3. Metametamodel je model koji je sam sebi referentan tj. model koji je sam sa  sobom u vezi c2.

Definicija 4. Metamodel je model čiji referentni model je metametamodel.

Definicija 5. Terminalni model je model čiji referentni model je metamodel.

U [Jouault06a] je prikazana definicija metametamodela KM3 (Kernel metametamodel), tj. njegove pojednostavljene varijante SimpleKM3. Polazeći  od gore navedenih definicija autori definišu dva predikata u predikatskoj logici provog reda:

• Node(x,y) – predikat iskazuje vezu između čvora x koji pripada NG i čvora y koji pripada Nω

• Edge(x,y,z) – predikat iskazuje vezu između veze koja postoji između čvorova x ∈ NG  i y ∈ NG  i čvora  z ∈ Nω

22

Uvodna razmatranja

Dalje se SimpleKM3 definiše iskazima

1. Node(class, class)2. Node(reference, class)3. Node(features, reference)4. Node(type, reference)

5. Edge(class, features, features)6. Edge(features, reference, type)7. Edge(reference, type, features)8. Edge(type, class, type)

SimpleKM3 se može, upotrebom UML class dijagrama prikazati na sledeći način

Slika 1.7: Dijagram klasa SimpleKM3 metametamodela

Iz   definicije  možemo  uočiti   da,   s   obzirom da   je  SimpleKM3 metametamodel,   on   je samodefinišući što je obezbeđeno iskazom 1 koji bi neformalno mogao da se iskaže rečenicom “klasa je klasa”.

SimpleKM3 se grafom može predstaviti na sledeći način:

Slika 1.8: SimpleKM3 metametamodel – graf prikaz

Slika  1.8  prikazuje   metametamodel   SimpleKM3.   Možemo   videti   da   je   SimpleKM3 samodefinišući jer su svi elementi vezama c2 direktno ili indirektno povezani sa čvorom Class  koji ima rekurzivnu c2 vezu sa samim sobom.

23

Uvodna razmatranja

Slika 1.9: Dijagram klasa primera modela

U cilju semantičkog pojašnjenja c2 veze na slici 1.9 je prikazan dijagram klasa upotrebom UML grafičke notacije.   Ukoliko zanemarimo kardinalitet asocijacije referentni model ovoga modela  može  biti  SimpleKM3.  Na slici  1.10  je,  neformalnom graf  notacijom,  prikazan  isti model i njegova veza sa SimpleKM3 metametamodelom. U cilju jednostavnosti prikaza, veze između samih elemenata metamodela su izostavljene jer su date na slici 1.8. Neformalno bi se informacije   prikazane   na   grafu   mogle   interpretirati   kao   “Prodavnica   je   klasa”,   “naziv1   je referenca”, “Integer je klasa”, “veza između Prodavnice i naziv1 je osobina (Features)”, “veza između kolicina   i   Integer   je   tip”  ili  “kolicina  je   tipa Integer”.   Iako je  namena SimpleKM3 metametamodela (kao i KM3 metametamodela uopšte) definisanje metamodela, u cilju bolje razumljivosti   i   izbegavanja   korišćenja   istih   naziva   koncepata   na   različitim   metanivoima, prikazan   je   terminalni   model   sa   nivoa   M1.   S   obzirom   da   je   SimpleKM3   samodefinišući metametamodel on je istovremeno i metamodel (za definisanje metamodela) kao i terminalni model, tj. SimpleKM3 se konceptualno nalazi na svim metanivoima. 

24

Uvodna razmatranja

Slika 1.10: Grafički prikaz elemenata modela sa vezama prema metaelementima

Formalno se, upotrebom predikatske logike prvog reda, model može predstaviti iskazima datim u tabeli 1.1. Ukoliko opisu iz tabele dodamo opis SimpleKM3 metametamodela dobijamo samodefinišući skup iskaza u FOPL­u.

1. Node(Prodavnica, Class)2. Node(Artikl, Class)3. Node(String, Class)4. Node(Integer, Class)5. Node(artikli, Reference)6. Node(naziv1, Reference)7. Node(naziv2, Reference)8. Node(kolicina, Reference)

9. Edge(Prodavnica, naziv, features)10. Edge(Prodavnica, artikli, features)11. Edge(Artikl, naziv, features)12. Edge(Artikl, kolicina, features)13. Edge(naziv1, String, Type)14. Edge(artikli, Artikl, Type)15. Edge(naziv2, String, Type)16. Edge(kolicina, Integer, Type)

Tabela 1.1: Definicija primera modela upotrebom iskaza u predikatskoj logici prvog reda

25

Uvodna razmatranja

1.2.9. Jezici specifični za domen

Jezici   specifični   za   domen   (Domain­Specific   Languages­DSL)   su   programski   jezici kreirani za rešavanje problema u određenom, jasno definisanom, domenu. Za razliku od jezika opšte namene (General Purpose Language – GPL) koji su kreirani za rešavanje široke klase problema,  DSL­ovi   su  optimizovani   za   jasno  definisanu  klasu  problema.  Na  primer,   jezik GraphViz  se koristi za definisanje i crtanje grafova. Upotrebom ovog jezika može se opisati matematički graf i zatim kreirati slike u različitim formatima. Isti posao bi upotrebom jezika opšte namene bio daleko teži. Sa druge strane,  GraphViz  ne možemo koristiti za   obavljanje zadataka opšteg tipa kao što bi na primer bilo slanje podataka preko mreže ili manipulacija podacima u bazi itd. [Wiki­DSL]. Postoje jezici koji su inicijalno kreirani kao jezici specifični za domen ali su kasnije prošireni da bi dobili osobine jezika opšte namene. Obrnut slučaj nije zabeležen u istoriji programskih jezika [Bézivin06b].

U literaturi je prilično nejasna razlika između jezika četvrte generacije i jezika specifičnih za domen. Definicije oba jezika su slične ali se jezici četvrte generacije najviše vezuju za CASE alate  i  okruženja za rad sa bazama podataka.  Prema mnogim autorima [Bruce97, Hudak96] uspešan DSL je onaj koji   je u stanju da na pravi način  zabeleži   rečnik domena čime jezik postaje odmah razumljiv ekspertima domena. 

Osnovne osobine koje DSL poseduje su:

• apstraktna sintaksa• konkretna sintaksa (grafička ili tekstualna)• semantika, eksplicitno ili implicitno definisna

Apstraktna sintaksa definiše osnovnu strukturu jezika. Prema [Bézivin06b], u kontekstu MDE, apstraktna sintaksa je određena metamodelom. Konkretna sintaksa predstavlja prikaz, u opštem slučaju, modela upotrebom teksta ili crteža. Jedan DSL, određen metamodelom, može imati više konkretnih sintaksi. Na primer, isti UML model može biti predstavljen klasičnom grafičkom notacijom ili HUTN tekstualnom notacijom (videti 1.3.2.9). 

Poslednjih godina dolazi do promena u shvatanju šta DSL zaista predstavlja, posebno u radovima [Bézivin05,  Bézivin06b, Jounault06a, Jounault06b, Jounault06c]. Prema navedenim autorima DSL se nalazi na višem nivou apstrakcije u odnosu na MDE pristup. MDE predstavlja samo jednu od specijalizacija DSL ideja. Postoje i drugi pristupi koji specijalizuju DSL principe kao što su Grammarware [Klint], XML pristupi itd. 

26

Uvodna razmatranja

Prema [Bézivin06b] DSL je skup koordinisanih modela. Modeli koji definišu DSL su:

• Metamodel za opis domena (Domain Definition Metamodel­DDMM) – Za razliku od jezika opšte namene koncepti korišćeni u DSL­u su koncepti konkretnog domena za koji se jezik projektuje. Rečenice ovoga jezika iskazuju određena znanja o domenu tj. predstavljaju model. Konceptualizacija domena predstavlja apstraktan entitet koji opisuje   zajedničke   osobine   svih   mogućih   pojava   u   posmatranom   domenu.   Ona definiše osnovne apstrakcije domena i njihove međusobne relacije. Kada se takav apstraktan entitet  konkretizuje  u vidu modela on postaje  referentni  model za sve modele iskazane DSL­om. Takav model se naziva metamodel.  Prema [Gruber95] ovakav model predstavlja onologiju i on je od izuzetnog značaja u definisanju DSL­a. Na primer, DSL za opis usmerenih grafova će imati koncepte kao što su čvorovi i veze.

• Konkretna   sintaksa   predstavlja   model   koji   opisuje   transformaciju   DDMM   na metamodel za prikaz ili površinu za prikaz (display surface). Na primer, ukoliko želimo   da   definišemo   grafičku   notaciju   za   DSL,   metamodel   za   prikaz   može definisati koncepte kao što su krug, kvadrat, trougao, linija.

DSL može da definiše izvršnu semantiku putem definisanja transformacije na DSL jezik koji ima definisanu izvršnu semantiku ili definisanjem transformacije na GPL čija je izvršna semantika definisana izvršnom platformom (npr. virtuelna mašina) ili daljim tranformisanjem (npr. kompajliranje programskog koda). 

Prema [Fowler04] DSL­ovi se dele na:

• externe DSL­ove (External DSLs) – su DSL­ovi popularni u Unix svetu (awk, sed, bash itd.). Nazivaju se i mini jezicima (mini languages) ili “malim” jezicima (little  languages). Izradnja externih DSL­ova se bazira na kreiranju sintakse i definisanju kompajlera koji prevodi programe pisane ovim jezikom na druge programske jezike (najčešće GPL), ili se program direktno interpretira.

• interne   DSL­ove  (Internal   DSLs)   –   su   DSL­ovi   koji   nastaju   upotrebom   već postojećih jezika (Lisp, Smalltalk, Ruby itd.) čijim proširenjem se definiše sintaksa novog   jezika.  Ovo   je   standardan  način   rada  u  mnogim programskim  jezicima   ­ kreiranje   programskih   funkcija   na   takav   način   da   definišu   DSL   za   određeni problemski   domen,   ali   je   kod   dinamičkih   programskih   jezika,   kao   što   su   npr. Smalltalk   i   Ruby,   takav   pristup   prirodniji   i   jednostavniji.   Dinamički   jezici   sa dobrom   podrškom   za   kreiranje   DSL­ova   najčešće   omogućavaju   kreiranje jednostavnih i čistih sintaksi novog jezika.

27

Uvodna razmatranja

Na   osnovu   jedne   sveobuhvatne   studije   razvoja   sistema   velikih   razmera  o  učestalosti grešaka po broju izvršnih linija programskog koda, došlo do zaključka da učestalost grešaka uglavnom ne zavisi od programskog jezika koji se koristi. Iz ovoga se može zaključiti da jezici veoma visokog nivoa apstrakcije koji zahtevaju manje linija koda za obavljanje posla najčešće znače i manje programerskih grešaka [Raymond]. Ako imamo u vidu da se DSL­ovi razvijaju tako da koriste koncepte problemskog domena i ukoliko se konkretna sintaksa pažljivo kreira možemo da postignemo značajan napredak u čitljivosti programskog koda i njegovom kvalitetu smanjenjem broja linija a samim tim i smanjenjem grešaka.

1.3. Inženjering upravljan modelima (Model-Driven Engineering)

Inženjering upravljan modelima predstavlja pristup u upotrebi modela kod koga model ne predstavlja   samo   sredstvo   dokumentovanja   i   boljeg   razumevanja   sistema   već   je   deo implementacije   u   smislu  da   se   automatizovanim  postupcima   transformiše  na   jezik   koji   se direktno izvršava na ciljnoj platformi. Ovakav vid rada nije nov. Prevođenje viših programskih jezika na asemblerski jezik i  dalje na mašinski kod konceptualno predstavlja istu operaciju. Osim prevođenja,  moguće  je definisati   izvršno okruženje koje  je  u mogućnosti  da direktno izvršava   modele   bez   prethodnog   prevođenja   na   druge   jezike.   Ovakav   vid   upotrebe   je ekvivalentan tradicionalnim interpreterima viših programskih jezika.

Dosadašnji način upotrebe modela u razvoju softvera, odnosio se pre svega na inicijalnu analizu,  razumevanje i dokumentaciju sistema. U literaturi  je ovakav način upotrebe modela poznat kao razvoj baziran na modelima (model­based) [Stahl06]. Mane razvoja baziranog na modelima  ogledaju   se  u  činjenici  da,   kao  deo  dokumentacije,  modeli   imaju   tendenciju   da izgube sinhronizam sa implementacijom, što je često slučaj u kasnijim fazama razvoja kada su pritisci   na   razvojni   tim  veći.  Kao  posledica  ovoga,   verodostojnost  modela   je   sve  manja   i vremenom gubi na značaju tako da se razvoj degradira na nivo klasičnog razvoja bez upotrebe modela.

28

Uvodna razmatranja

Kod razvoja upravljanog modelima, model na predstavlja samo sredstvo dokumentovanja i   boljeg   razumevanja   sistema   već   je   deo   implementacije   u   smislu  da   se   automatizovanim postupcima   transformiše  u  oblik  koji  omogućava  direktno   izvršavanje  na  ciljnoj  platformi. Prednosti ovakvog pristupa su:

• Implementacija   uvek   odgovara   dizajnu.   Promene   u   dizajnu   se   reflektuju   na implementaciju automatizovanih transformacijama.

• Razvoj se bazira na apstrakcijama visokog nivoa koje su, idealno, deo rečnika domena.• Programeri i domenski eksperti koriste isti rečnik, čime se postiže bolje razumevanje i 

smanjuje se mogućnost semantičke neodređenosti.• Prevođenje na druge tehničke platforme je moguće u velikoj meri automatizovati.• Stalna   dostupnost   ažurnog   dizajna   sistema   omogućava   bolje   razumevanje   i 

jednostavnije održavanje.• Moguće   je   automatizovana   izgradnja   mostova   između   različitih   sistema   na   osnovu 

dizajna.

Prema   [Schmid06],   MDE   predstavlja   obećavajući   pristup   koji   treba   da   reši   problem nemogućnosti   jezika   treće   generacije   da   savladaju   kompleksnost   platformi   i   da   efektivno definišu domenske koncepte.

1.3.1. Najvažniji predstavnici

Arhitektura  vođena modelima  (Model­Driven  Arhitecture)  predstavlja  napore  OMG organizacije u standardizaciji MDE pristupa. Bazira se na MOF metametamodelu i kao osnovni jezik za modelovanje definiše UML. Akcenat je interoperabilnost između alata i standardizacija jezika za modelovanje u određenim domenima upotrebe. Trenutno je najaktivniji MDE pristup sa snažnom podrškom u industriji i akademiji.

Razvoj   softvera   upravljan   modelima  (Model­Driven   Software   Development) predstavlja skup ideja u kreiranju softvera gde, kao i kod drugih pristupa vođenih modelima, model   ne   predstavlja   samo   dokumentaciju   već   je   aktivan   učesnik   u   kreiranju   ciljne implementacije. Prema [Stahl06], MDSD se ne bazira na određenim standardima kao što je to slučaj   sa   MDA   pristupom.   Ne   propisuje   metamodele   ili   metametamodele   koji   se   moraju koristiti  kao  ni   jezike  specifične  za  domen.  Bilo  koji  metametamodel   se  može  koristiti   za MDSD   razvoj.   Cilj   MDSD   paradigme   je   pronalaženje   apstrakcija   specifičnih   za   domen   i njihova  upotreba  u   formalnom modelovanju  sa  akcentom na  alate   i   tehnike  upotrebljive  u praksi. 

29

Uvodna razmatranja

Računarstvo integrisano modelima   (Model­Integrated Computing ­ MIC)  se razvija više od decenije na Vanderbilt univerzitetu, institutu za softverski integrisane sisteme (Institute  for Software Integrated Systems – ISIS).  Koncepti  su konkretizovani u vidu GME (Generic  Modeling Environment) alata koji predstavlja proširivi sistem za metamodelovanje [Ledeczi01]. Institut   je   postigao   značajne   uspehe   upotrebom   ovog   alata   u   implementaciji   ugrađenih sistemima   u   realnom   vremenu   (real­time   embedded   systems),   a   pre   svega  u   sistemima   sa ograničenim resursima. U MIC­u modeli imaju sledeću ulogu [ISIS­MIC]:

• predstavljaju integralna znanja o sistemu kao celini uz mogućnost definisanje posebnih pogleda   (views).   Putem   modela   se   može   definisati   celokupan   sistem   sa   stanovišta dizajnera i njegovog razumevanja uključujući arhitekturu za obradu informacija, fizičku arhitekturu kao i okruženje u kome radi.

• Integrisano   modelovanje   omogućava   eksplicitnu   reprezentaciju   međuzavisnosti   i ograničenja između različitih pogleda.

• Alati  omogućavaju  analizu   različitih  međuzavisnih  karakteristika  sistema kao što   su performanse,  bezbednost,   sigurnost   itd.  Posebni   alati   prilagođeni   alatima  za  analizu transformišu informacije modela u oblik koji služi kao ulaz alatima za analizu.

• Integrisani modeli se koriste za automatizovanu sintezu softvera. • Interfejs   za   metaprogramiranje   baziran   na   UML­u   omogućava   sintezu   i   evoluciju 

okruženja  specifičnih  za domen za sintezu  programa na osnovu  integrisanih  modela (Model­Integrated Program synthesis – MIPS)

Koliko je značajan MIC govori i činjenica da se trenutno razvija kao jedan od standarda OMG konzorcijuma [OMG­MIC]

Programiranje   orijentisano   ka   jezicima  (Language   Oriented   Programming­LOP) predstavlja metodologiju razvoja kod koje se razvoj softvera organizuje oko skupa domenski specifičnih programskih jezika. Ime je definisao i ideju uobličio Martin Ward u radu [Ward94] dok   je  veliki  doprinog  sao   i  Sergej  Dmitriev   [Dmitriev]  osnivač   firme   JetBrains  čiji  LOP proizvod   nosi   naziv  Meta   Programming   System  (MPS).   LOP   metodologija   podrazumeva postojanje  alata  koji  omogućava efikasno kreiranje  DSL­ova za  pojedine  zadatke   i  njihovo koherentno korišćenje unutar integrisanog okruženja sa svim mogućnostima koje imaju tekuća integrisana okruženja u upotrebi (bojenje sintakse, navigacija, refektorisanje koda, analiza koda itd.).  Programski  kod se ne čuva u obliku  teksta  već  u obliku grafa koji  predstavlja  stablo apstraktne sintakse. Program se ne posmatra kao niz instrukcija već kao model rešenja. Program se može prikazivati i obrađivati na različite načine što definiše dizajner novog jezika (tabele, grafikoni, dijagrami itd.).

30

Uvodna razmatranja

Generativno   programiranje  (Generative   Programming)   je   u   upotrebi   već   duži   niz godina. Naročito je dobio na popularnosti objavljivanjem knjige   [Czarnecki00]. Generativno programiranje predstavlja paradigmu razvoja baziranu na modelima familije softverskih sistema tako da se, na osnovu konkrente specifikacije zahteva, može automatski izgraditi optimizovani, visoko   prilagođeni   softverski   proizvod,   iz   elemenatrnih   implementacionih   komponenti   na osnovu   konfiguracionih   informacija.   Osnovne   osobine   generativnog   programiranja   su: korišćenje paradigme industrijske proizvodnje kao što je proivodna linija, kreiranje kompletnog sistema 100% automatizovano, izgradnja konfiguracijom predefinisanih atomičkih komponenti, optimizacija  aplikacije  po  određenom aspektu  kao  što   je  npr.  brzina   ili   zauzeće  memorije. Korišćenje   paradigme   generativnog   programiranja   upotrebom   programskog   jezika   C++   je prikazano u [Eisenecker97].

Modelovanje   specifično   za   domen  (Domain­Specific   Modeling   ­   DSM)   predstavlja metodologiju   razvoja   softvera  koja   se  bazira  na  sistematskoj  upotrebi   jezika  specifičnih  za domen (DSL) sa grafičkom notacijom. Osim definisanja sistema upotrebom DSL­ova DSM uključuje   ideju  automatskog  generisanja  koda.  Za   razliku  od  pristupa  kod kojih   se  koriste prefabrikovani   jezici   bez   mogućnosti   izmene   (npr.   CASE   alati)   DSM   pristup   propagira upotrebu jezika koji su razvijeni unutar organizacije koja ga koristi. Prednosti ovakvog pristupa su korišenje jezika koji je kreiran da zadovolji potrebe organizacije, brža evolucija jezika jer nije potrebno usklađivati potrebe sa drugim organizacijama, jednostavnije učenje jezika jer su koncepti iz profesionalnog domena ljudi koji ga koriste. DSM je metodologija visokog nivoa koja   ne   propisuje   konkretne   standarde   i   alate   koji   se   moraju   koristiti   tako   da   mnoge metodologije nižeg nivoa, kao što su MIC i fabrike softvera, mogu da se smatraju DSM­om. Alati za koje se smatra da koriste DSM metodologiju su između ostalih MetaEdit+, GEMS, i Microsoft DSL Tools (videti 1.3.4)

Modelovanje specifično za ovir za razvoj  (Framework­Specific Modeling) predstavlja ideju kreiranja modela upotrebom koncepata okvira za razvoj (frameworks).  Ovaj pristup je opisan u radu  [Antkiewicz06]   i  bazira  se na  ideji  da upotreba  okvira  za  razvoj  predstavlja teškoću sa kojom se programeri svakodnevno suočavaju. Objektno orijentisani okviri za razvoj su najčešće korišćene tehnologije kada se ponovna iskoristljivost softvera u pitanju (software  reuse). Okviri za razvoj predstavjaju delimičnu implementaciju funkcionalnosti koja je prisutna u  određenoj  klasi   aplikacija.  Kreiranje   softvera  baziranog  na  okvirima  za   razvoj   se  naziva dopuna  okvira   (framework  completition)   i   predstavlja   dopunu   funkcionalne   razlike   između aplikcije i okvira. Okviri definišu skup koncepata koji se nazivaju koncepti obezbeđeni okvirom (framework­provided concepts), kao i načine njihovog instanciranja i korišćenja u kodu dopune. Iako pružaju veliku pomoć, upotreba okvira može biti zahtevan zadatak jer je potrebno znati kako   se   dati   koncepti   mogu   ispravno   kombinovati.   Često   su   elementi   interakcije   između 

31

Uvodna razmatranja

elemenata dopune i samog okvira rasute po programskom kodu i teško ih je sagledati. Okviri definišu i pravila interakcije koda dopune i okvira (rules of engagement) koja definišu  na koji način aplikativni kod dopune vrši interakciju sa okvirom i šta pri tome mora biti zadovoljeno. Problem sa upotrebom okvira za razvoj predstavlja i praćenje promena usled razvoja okvira i prilagođavanje aplikativnog koda nastalim promenama. 

Modelovanje   specifično   za  okvir   za   razvoj  pruža   tu   pogodnost   da  programeru  može omogućiti preporuke o načinima korišćenja koncepata u toku modelovanja, proveru integriteta modela na osnovu pravila interakcije itd.

Fabrike   softvera  (Software   factories)   predstavlja  metodologiju   razvoja   softvera   koju Microsoft  koristi  u   svojoj  viziji   razvoja   softvera  upravljanim modelima  pod nazviom DSL Tools [DSLTools]. Iako naziv najviše koristi Microsoft, koncept fabrike softvera postoji već duže vreme i predstavlja  pokušaj da se u proizvodnji  softvera  iskoriste znanja i  doktrine iz industrijske   manufakture   kao   što   su   standardizacija   komponenti,   specijalizacija   veština, paralelna obrada kao i predvidiva i skalabilna konzistencija kvaliteta. U tom cilju, metodologija predstavlja   nadogradnju   proizvodnih   linija   softvera   i   definiše   načine   konstrukcije   softvera upotrebom   komponenti,   dizajn   obrazaca,   okvira   za   razvoj   i   masovne   proizvodnje   putem konfigurisanja   i  prilagođavanja  već   izgrađenog  softvera  za  potrebe  novih  klijenata.  U  radu [Greenfield03] se opisuju osnovne postavke ove metodologije i predviđa se da će u budućnosti, proizvodnja softvera biti sve sličnija proizvodnji u drugim granama industrije. Kao bitnu stavku daljeg razvoja ovog pristupa autori navode da će biti potrebno kreiranje lanaca snabdevanja kao i   u   drugim   industrijama  putem  kojih   će   industrija   proizvodnje   softvera  moći   da   planira   i nabavlja prefabrikovane komponente i poluproizvode koje će se ugrađivati u finalni proizvod.

Izvršivi  UML  (Executable  UML –   xUML)  predstavlja  metodologiju   razvoja   softvera bazirana   na   proširenjima   UML   standarda   koja   mu   daju   Turingovu   kompletnost.   Modeli korišćeni u xUML­u mogu direktno da se prevode na ciljne platforme putem kompajliranja modela [Mellor02]. Metodologija se bazira na tri vrste dijagrama: 

• dijagrami  domena – opisuju različite  domene sistema koji  predstavljaju  prožimajuće zavisnosti (cross­cutting concerns) sistema kao i veze između njih (bridges),

• dijagrami klasa – opisuju klase i relacije između njih,• dijagram stanja­prelaza – opisuje prelaze stanja i životni ciklus (lifecycle) instanci klasa.

Osnova   xUML   je   profil   za   UML   koji   predstavlja   pažljivo   odabran   podskup   UML metamodela.   Pravila   modelovanja   nisu   nametnuta   konvencijom   već   izvršivošću   modela   – model se ili može kompajlirati i izvršiti ili ne može [Mellor04b]. Dijagrami koji ne poseduju osobinu izvršivosti mogu se slobodno koristiti kao pomoć pri izgradnji izvršivih modela.

32

Uvodna razmatranja

Svaki  automat  opisan dijgramom stanja­prelaza   ima definisan skup procedura koje se pozivaju   na   promenu   stanja.   Ove   procedure   su   iskazane   u   UML   jeziku   akcija   (Action  language). Prema [Mellor04b] razlika između običnog višeg programskog jezika i UML jezika akcija je slična razlici između asemblerksog jezika i višeg programskog jezika. Isti posao je moguće uraditi i u asembleru ali viši programski jezici nude viši nivo apstrakcije rasterećen od detalja hardverske platforme kao što su broj i vrsta registara. UML akcioni jezik omogućava definisanje algoritma operacije  na  još  višem nivou apstrakcije  koji  nije  opterećen detaljima softverske  platforme kao što   su  distribucija,  pozivi  udaljenim procedurama,   implementacija struktura podataka i dr.

Direktno izvršavanje modela nije nov koncept. Prema [Frankel03] sistemi za upravljanje bazama podataka predstavljaju virtuelne mašine koje izvršavaju modele podataka.

Programiranje upravljano namerama (Intentional programming ­ IP) predstavlja skup koncepata   koji   imaju   za   cilj   da   izvorni   kod   programa   sadrži   jasnu   informaciju   o   nameri programera koju je imao prilikom njegovog pisanja. Nastao je krajem 90­tih u Microsoft­ovim laboratorijama a sada je razvoj vođen od strane firme Intentional Software [Intentional]. 

Kod IP­a je potrebno prvo definisati skup osnovnih alata (toolbox) za posmatrani domen i zatim se program kreira korišćenjem posebnog integrisanog okruženja (domain workbench). Izvorni kod se ne čuva u obliku tekstualnog fajla već se za tu svrhu koristi vlasnički binarni format koji, donekle, u strukturi ima sličnosti sa XML­om. Sve varijable u programu imaju, pored  svog  simboličkog   imena,   jedinstveni   identifikator  dok  je  osnovna   reprezentacija  nad kojima   priključci   (plugins)   vrše   operacije   apstraktno   stablo   sintakse   (AST).   Ovim   je omogućeno pojednostavljeno refaktorisanje koda. Čvorovi AST­a imaju vezu sa metapodacima i mogu da iskažu osobine ponašanja tj. izvorni kod je aktivan (može da se samokompajlira, da pruži podršku u editovanju, debagovanju i vizuelnom prikazivanju koda).

Proizvodne   linije   softvera  (Software   product   lines)   predstavljaju   skup   softverski intenzivnih sistema koji imaju skup zajedničkih osobina koje zadovoljavaju potrebe određenog cilja   ili   određenog   segmenta   tržišta   i   izgrađeni   su   na   propisan   način   od   skupa   osnovnih standardizovanih resursa [CM­SEI]. Kreće se od definicije i  razvoja osnovnih resursa (core  assets) koji imaju za cilj definisanje i znanja o domenu. Osnovni resursi su: definisanje domena i njegovih granica, model domena, osnovne komponente, arhitektura. Osim osnovnih resursa potrebno je definisati i proizvodni plan (Production Plan) kojim se definiše postupak izgradnje proizvoda  upotrebom osnovnih   resursa.  Razvoj  proizvoda   se   svodi   na    upotrebu  osnovnih resursa prema unapred definisanom proizvodnom planu. Ovakav način izrade može dovesti do velikog stepena automatizacije kada se jednom definišu i implementiraju osnovni resursi.

33

Uvodna razmatranja

1.3.2. MDA

MDA predstavlja konkretizaciju MDE paradigme vođenu od strane OMG konzorcijuma. 2002. godine OMG je i zvanično objavio da je MDA njegova strateška vizija. MDA čini skup koncepata i standarda. Osnovna vizija MDA pristupa opisana je u [MDAGuide].  Akcenat je interoperabilnost između alata i standardizacija jezika za modelovanje u određenim domenima upotrebe. 

Prema [Frankel03] MDA nije radikalna promena u razvoju softvera u odnosu na način koji je korišćen godinama, već MDA predstavlja evolutivni korak koji konsoliduje trendove i metode koji su   postupno poboljšavali način na koji se softver proizvodi. Velika popularnost pristupa izazvala je pometnju usled neistinitih ili nepotpunih marketiških poruka [Frankel04] što dovodi do niza neuspeha u praksi izazvanih lošim tumačenjem ideja MDA.

Ono u čemu će MDA biti uspešna u početku su fokusirani, dobro definisani domeni, koji se sastoje od sličnih sistema koji čine proizvodnu liniju (production line) [Frankel04]. Ovakav trend je evidentan i u nekim drugim MDE pristupima kao što je npr. MDSD gde je trenutno najpopularnija varijanta tzv. Architecture­Centric MDSD (videti 1.3.3.2).

U radovima [Sewall, Booch04] daju se neki od razloga uvođenja MDA pristupa (odnosno MDE pristupa u opštem smislu).  Sewall  se posebno osvrće na ekonomsku stranu uvođenja MDA pristupa gde daje analizu smanjenja troškova u pojedinim fazama izrade softvera.  Po autoru,   u   proseku   dolazi   do   uštede   40­50%.   Smanjenje   troškova   proizvodnje   softvera predstavlja krajnji rezultat pozitivnih promena koje su izazvane usvajanjem MDA pristupa, a po Booch­u to su:

• jasna podela nadležnosti. Svako može da se bavi poslom koji najbolje zna. Podela se najčešće realizuje stanovištima (view points) – npr podela na CIM, PIM, PSM (videti 1.3.2.1),

• dobro radi u kontekstu prototipskog razvoja ali je pre svega potrebno dobro definisati arhitekturu i korišćene dizajn obrasce,

• iskustvena procena je da je u proseku potrebno oko 2 meseca da se MDA pristupi uvedu u razvojni tim što omogućava relativno brz povrat investicija (Return of Investment –  ROI),

• eksperti  za poslovnu problematiku generalno razumeju CIM i PIM modele pa mogu aktivno učestvovati u razvoju,

• MDA alati postaju dostupni velikom brzinom,• Definisanjem OCL (videti  1.3.2.7) postalo je moguće automatizovano testiranje putem 

34

Uvodna razmatranja

generisanja   testova   na   bazi   preduslova   (preconditions)   i   uslova   koji   slede (postconditions),

Jedan od velikih  problema koji  Sewall  navodi   je  činjenica  da  je  znanje  o  poslovnom sistemu rasuto  po  dokumentima   ili  često  postoji   samo u  glavama zaposlenih  koji  ga  često ljubomorno čuvaju za sebe da bi zadržali svoje pozicije unutar firme. Posledica ovoga je da je menadžment često u poziciji taoca jer nema kontrolu nad poslovnim procesima unutar firme niti potpuno  znanje  o  njima.  Sa  MDA pristupom ovakvi   rizici   se   smanjuju   jer   je  dizajn  uvek kompletan i dostupan čime se znanje o poslovnim procesima čuva na jednom mestu u obliku koji je jednostavan za razumevanje i izmene.

1.3.2.1. Stanovište – viewpoint

Stanovište u MDA predstavlja tehniku apstrakcije koja koristi arhitekturalne koncepte i strukturna  pravila   u   cilju   fokusiranja   na  određen  aspekt   sistema.  Korišćenjem  ove   tehnike dobijamo pojednostavljen model kod koga su skriveni detalji koji nisu od interesa za tekuće stanovište. MDA vodič [MDAGuide] definiše tri stanovišta:

• računski  nezavisno stanovište  (Computation Independent  Viewpoint)  se fokusira na okruženje   sistema   i   funkcionalne   zahteve   koje   je   sistem   potrebno   da   ispuni   bez definisanja načina na koji će se funkcionalnost realizovati,

• platformski  nezavisno   stanovište  (Platform  Independent  Viewpoint)   se   fokusira  na aspekte   realizacije   sistema bez  uvođenja  detalja  vezanih  za  konkretnu  platformu na kojoj   će   sistem   biti   realizovan.   Ovo   stanovište   prikazuje   one   delove   kompletne specifikacije koji se ne menjaju prilikom promene implementacione platforme,

• plaformski zavisno stanovište  (Platform Specific Viewpoint) prikazuje detalje vezane za konkretnu implementacionu platformu.

1.3.2.2. Vrste modela

Osnovna   podela   vrsta   modela   u   MDA   je   na   osnovu   nivoa   apstrakcije   definisanog stanovištem (viewpoint). Prema tome imamo tri osnovne vrste modela:

• računski nezavisan model (Computation Independent Model ­ CIM) predstavlja model najvišeg nivoa apstrakcije i definiše poslovne procese nezavisno od načina na koji će biti implementirani. CIM se nekada naziva i domenski model jer sadrži opis koncepata domena kojima vlada  domenski  ekspert.  Polazi  se  od pretpostavke da korisnik CIM 

35

Uvodna razmatranja

modela,  domenski  ekspert,  ne vlada  modelima   i  artifaktima  koji  se  koriste  da bi  se tražena funkcionalnost implementirala. CIM ima značajnu ulogu u komunikaciji između domenskog eksperta koji definiše zahteve koji sistem treba da ispuni i eksperta za dizajn i konstrukciju koji definiše dizajn koji treba da realizuje tražene zahteve. Trenutno, CIM modeli nemaju veliku ulogu u procesu automatizacije jer se nalaze na veoma visokom nivou apstrakcije i vrlo teško se na osnovu njih mogu, automatizovano, dedukovati PIM modeli.

• model nezavisan od platforme (Platform Independent Model ­ PIM) predstavlja model sistema   sa   platformski   nezavisnog   stanovišta.   Bitno   je   naglasiti   da   je   platformska nezavisnost   relativan   pojam   [Frankel04,   MDAGuide,   Frankel03].   Kada   definišemo nezavisnost  moramo definisati   i  kontekst  u kome taj   iskaz važi.  Na primer,  ukoliko imamo distribuirani objektni model on može biti nezavistan od konkretne distribucione tehnologije jer koristi koncepte koji se sreću u svim distribucionim tehnologijama od interesa ali, u kontekstu i distribuiranih i nedistribuiranih sistema, model nije nezavistan. Platformska nezavisnost predstavlja kvalitativnu osobinu koju model može da poseduje. Jedan   od   preporučenih   načina   postizanja   platformske   nezavisnosti   jeste   upotreba tehnološki  neutralnih  virtuelnih  mašina.  Modelovanje  PIM­a   se  obavlja  korišćenjem koncepata virtuelne mašine. Virtuelna mašina jeste platforma pa je model zavisan od te platforme ali je model nezavisan u kontekstu različitih platformi na kojima je virtuelna mašina implementirana [MDAGuide, Almeida] (videti 1.2.3)

• model zavisan od platforme  (Platform Specific Model ­ PSM) predstavlja model koji koristi koncepte konkretne implementacione platforme. Na primer, ukoliko modelujemo sistem koji će biti implementiran upotrebom EJB tehnologije možemo koristiti koncepte kao što su Home Interface, Remote Interface, Session Bean itd. Treba napomenuti da je, kao i u slučaju platformske nezavisnosti,  i platformska zavisnost relativan pojam. Na primer,   model   može  da   zavisi   od   EJB   tehnologije   ali,   ukoliko   ne  koristi   koncepte specifične za određeni aplikativni server, tada se model može smatrati PIM modelom pri čemu se kao platforme posmatraju svi EJB aplikativni serveri. PSM model se u većini slučajeva   ne   kreira   ručno   već   se   dobija   automatizovanom   ili   poluautomatizovanom transformacijom PIM modela.

1.3.2.3. Inženjerstvo unapred, reverzno i kružno inženjerstvo

Inženjerstvo   unapred   (forward   engineering),   u   kontekstu  MDA,  predstavlja   postupak izrade softvera kod koga se sve ručne izmene vrše na najvišem nivou apstrakcije. U kontekstu MDA to bi bio CIM model ali se, zbog nepostojanja efikasnih algoritama i tehnologija koje bi CIM automatizovano transformisale u PIM modele, polazi od PIM modela. Svi koncepti nižeg 

36

Uvodna razmatranja

nivoa, moraju se implementirati u obliku adekvatnih koncepata višeg nivoa. Ukoliko to nije moguće, kao poslednja mogućnost, primenjuje se markiranje PIM modela sa oznakama koji omogućavaju transformacionim pravilima da prepoznaju specifične koncepte nižeg nivoa u koje treba da transformišu koncepte markiranog PIM modela. Sve ručne promene nad generisanim artifaktima nižeg nivoa apstrakcije se gube prilikom novog generisanja (transformacije) ukoliko alat ne podržava kružni inženjering. Inženjering unapred se već dugi niz godina, sa uspehom, primenjuje   u   oblasti   ugrađenih   sistema   u   relanom   vremenu   (real­time   embedded   systems) [Frankel03, Schmid06].

Reverzno  inženjerstvo  (reverse engineering)  omogućava dobijanje  artifakata  na višem nivou   apstrakcije   (npr.  modela)   na   osnovu   postojeće   implementacije   sistema.   U  kontekstu MDA,   to  bi   značilo  dobijanje  PIM modela  na  osnovu   implementacije   sistema.  Dosadašnji uspesi u izradi alata za automatizaciju ovog procesa nisu veliki jer je problem sam po sebi teško rešiv. Ukoliko implementacija sistema koristi dizajn obrasce koji se mogu prepoznati i ukoliko se  obrasci  uniformno   i  konzistentno  koriste  u   implementaciji   tada   je  moguće  dobiti   dobre rezultate   u   automatizovanom   reverznom   inženjerstvu.   U   većini   slučajeva   ovaj   problem   se rešava poluautomatizovanim ili ručnim metodama. Kada se iz postojećeg sistema dobiju PIM modeli dalje se koriste tehnike kružnog inženjerstva ili inženjerstva unapred.

Kružno   inženjerstvo   (round­trip   engineering)   predstavlja   mogućnost   sinhronizacije modela i implementacije u oba smera. Na ovaj način je omogućeno da se izmene obavljaju na onom nivou apstrakcije gde je to jednostavnije uraditi sa stanovišta alata i koncepata koji se koriste. Prema [Frankel03] možemo identifikovati  dve vrste kružnog inženjerstva: potpuno i parcijalno.  Kod parcijalnog kružnog inženjerstva  generisani  artifakti  se mogu menjati  samo aditivnim operacijama koje proširuju njihove mogućnosti. Najčešće se to obavlja u posebnim fajlovima korišćenjem određenih mehanizama ciljnog jezika kao što je npr. nasleđivanje. Na ovaj način moguće je regenerisati implementaciju bez gubitka ručnih izmena ali nije moguće vršiti propagaciju izmena sa nižih nivoa na više nivoe apstrakcije. Potpuno kružno inženjerstvo predstavlja   mogućnost   pune   propagacije   izmena   u   oba   smera.   Alati   ovog   tipa   su   mnogo kompleksniji i  trenutno imaju malu zastupljenost.  U radu [Antkiewicz06] opisan je alat koji omogućava potpuno kružno inženjerstvo u kontakstu alata za modelovanje specifično za okvire za razvoj. U praksi se, u vreme pisanja ovog rada, koriste uglavnom alati koji omogućavaju parcijalno kružno inženjerstvo. 

1.3.2.4. MOF – Meta-Object Facility

MOF (Meta­Object Facility) je standard OMG­a koji predstavlja jezgro infrastrukture za podršku MDA. Iako je UML jezik velikom brzinom prihvatan od strane softverskih arhitekata 

37

Uvodna razmatranja

širom sveta,  nije bio jedini jezik za modelovanje u upotrebi. To je posebno bilo izraženo u specifičnim oblastima softverskog inženjerstva u kojima je bilo lakše iskazati rešenja posebnim jezicima   kreiranim   za   dati   domen.   OMG   je   uvideo   da   je   uzaludno   pokušavati   kreirati univerzalni opšti jezik i privoleti sve da ga koriste. Logičniji put je bio kreirati način saradnje između   različitih   domena   i   različitih   jezika   za   modelovanje.   Ovo   je   omogućeno   MOF specifikacijom koja predstavlja mehanizam za formalno definisanje jezika za modelovanje tj. metamodela čime sam MOF u osnovi predstavlja meta­meta­model. Dizajn MOF­a je bio pod velikim uticajem UML­a  tako da  se u  verziji  1.4  u  velikoj  meri  poklapa  sa metamodelom dijagrama  klasa  UML­a.  U verziji   2.0  UML­a   i  MOF­a  neke   razlike  koje   su  postojale   su eliminisane tako da je  omogućeno da se MOF metamodeli  definišu putem UML dijagrama klasa  upotrebom klasičnih  alata  za  UML modelovanje   i  zatim je   jednostavnim mapiranjem moguće takav model transformisati u MOF model.

MOF je osnovna integraciona platforma MDA arhitekture. Da bi jezik za modelovanje postao deo MDA steka nije  potrebno da menja svoju grafičku ili   tekstualnu notaciju,  ali   je potrebno da opiše svoju apstraktnu sintaksu upotrebom MOF­a tj. potrebno je definisati meta­model jezika za modelovanje [Frankel04].

MOF ima četvoroslojnu arhitekturu čiji su slojevi obeleženi sa oznakama M0, M1, M2 i M3 (videti  1.2.5.1).  MOF se  može  posmatrati  kao  apstraktna  sintaksa  DSL­a  koji   služi   za definisanje metamodela. MOF ne propisuje konkretnu sintaksu, ali je, s obzirom na poravnanje sa UML 2.0 jezikom, u najširoj upotrebi grafička notacija UML dijagrama klasa.

Osim definisanja M3 nivoa,  odnosno meta­meta­modela,  MOF definiše i niz CORBA interfejsa koji služe za pristup, kreiranje i manipulaciju modelima i metamodelima. Defnisan je i standard JMI (Java Metadata Interface  [JMI]) razvijen nezavisno od OMG­a u sklopu JCP (Java   Community   Process)   koji   definiše   Java   interfejse   za   manipulaciju   modelima   i metamodelima    čime  se omogućava   realizacija  MDA u Java  svetu.  U verziji  2.0  OMG je definisao: EMOF (Essential MOF), CMOF (Complete MOF) i SMOF (Semantic MOF).

Postoji   više   implementacija   MOF   infrastrukture   koje   u   manjoj   ili   većoj   meri   prate specifikaciju standarda. Najpopularnije implementacije su NetBeans MDR [MDR], koji je u vreme   pisanja   ovog   teksta   predstavljao   implementaciju   MOF­a   1.4.   Sledeća   popularna implementacija je  ECore  razvijen od strane Eclipse fondacije i projekta EMF koji u osnovi predstavlja   implementaciju   EMOF   2.0.   ECore   se   razvijao   putem   mehanizama   razvoja otvorenog koda i predstavlja osnovu Eclipse platforme. IBM je više godina koristio EMF u svojim   proizvodima   pre   puštanja   u   otvoreni   kod.   Akcenat   prilikom   razvoja   Ecore implementacije je bio na efikasnost i jednostavnost upotrebe tako da postoje određene razlike između EMOF specifikacije i Ecore implementacije ali te razlike nisu od velikog značaja u praksi [EMF, Frankel04].

38

Uvodna razmatranja

MOF je trenutno međunarodni standard: ISO/IEC 19502:2005 Information Tehnology – Meta Object Facility (MOF)

1.3.2.5. UML – Unified Modeling Language

UML   (Unified   Modeling   Language)   predstavlja   grafički   jezik   za   vizuelizaciju, definisanje,   konstrukciju   i   dokumetaciju   artifakta   softverski   intenzivnih   sistema.   UML omogućava standardan način opisa sistema, uključujući konceptualne stvari kao što su poslovni procesi i funkcije sistema kao i konkretne stvari kao što su iskazi programskog jezika, šeme baze podataka i softverske komponente. UML predstavlja kulminaciju praktičnog iskustva iz oblasti objektno­orijetnisanog modelovanja.

Razvoj  UML je   inicijalno  započet  u  Rational  Software  Corporation  od  strane  Grady Booch, Ivar Jacobson i  Jim Rumbaugh ali  je kasnije nastavio da se razvija  u okviru OMG organizacije   uz   participaciju   velikog   broja   organizacija   i   ljudi   iz   oblasti   informacionih tehnologija. 

U vreme pisanja UML 1.4 specifikacije OMG je definisao OMA (Object Managament Architecture) čime je hteo da definiše okvir i infrastrukturu na kojoj bi se zasnivale sve OMG specifikacije. OMA je standard organizovan uglavnom oko CORBA specifikacije. 2002 godine OMG pravi zaokret i proglašava MDA kao svoj strategijski pravac daljeg razvoja. Osnovni i najpopularniji jezik za modelovanje oko koga se MDA organizuje je upravo UML.

Najveći problemi koji su pratili verziju 1.4, osim problema sa serijalizacijom i razmenom informacija o dijagramima između alata (videti  1.2.6), bio je i problem poravnanja sa MOF standardom. S obzirom da je MOF nastao na bazi iskustava sa delom UML metamodela koji se namenjem opisu dijagrama klasa, imao je velikih sličnosti sa njim ali su postojale i određene razlike koje su dovodile do problema u praksi. Usled ovoga, jedan od glavnih ciljeva verzije 2.0 bilo je poravnanje sa MOF specifikacijom što je i postignuto. 

UML 2.0 jezik, kao i sama specifikacija je podeljena:

• UML infrastruktura [UML2Infra] – fundametalne jezičke konstrukcije nad kojima se izgrađuju ostali elementi UML­a

• UML   superstruktura   (UML   Superstructure)   [UML2Super]   –   korisničke   jezičke konstrukcije koje definišu koncepte korišćene za modelovanje. UML superstruktura je zavisna od UML infrastrukture.

U cilju jednostavnijeg učenja UML je podeljen na jezičke celine (language units) čime se 

39

Uvodna razmatranja

omogućava efikasno korišćenje jezika ukoliko se zna samo njegov deo (određeni broj jezičkih celina).  Na primer,  ukoliko korisnik želi  da savlada kreiranje  dijagrama klasa može naučiti samo tu jezičku celinu. Specifikacija je organizovana tako da omogući jednostavnije praćenje jezičkih celina.

UML  je  od  početka  kreiran   imajući   u   vidu  širok  dijapazon  domena  u  kojima  će   se koristiti.  Stoga je,  osim što definiše posebne dijagrame za opise različitih  aspekata sistema, definisao i načine proširenja što, efektivno, znači da UML definiše familiju jezika. Mehanizmi za   proširenje   koje   UML   nudi   se   dele   na   laka   (lightweight)   i   teška   (heavyweight).   Teška proširenja   se   baziraju   na   proširenju   samog   UML   metamodela,   odnosno   kreiranje   novog metamodela na bazi postojećeg. U vreme pisanja ovog teksta nisu postojali alati u široj upotrebi koji su primenjivali ovaj mehanizam. Pod lakim proširenjem se podrazumeva korišćenje samih konstrukcija jezika u cilju njegovog proširenja. Ovaj mehanizam podržavaju svi vodeći alati za modelovanje i veoma je popularan u praksi. Lako proširenje se obavlja upotrebom:

• stereotipa   (stereotypes),   koji   predstavljaju   poseban   element   koji   se   može   pridružiti ostalim elementima modela i na taj način dobiti novi element za modelovanje sa novom semantikom definisanom stereotipom,

• oznaka   (tags),   mogu   se   pridružiti   elementu   i   definišu   dodatne   informacije   koje   su najčešće specifične za platformu na kojoj će se sistem konkretizovati.  Pre verzije 2.0 oznake su mogle biti samo string tipa dok od verzije 2.0 oznake mogu imati proizvoljan tip.

• ograničenja,   najčešće   definisana   upotrebom   OCL­a,   dodatno   ograničavaju   koncepte UML­a i moguće relacije između njih.

Ovako definisana proširenja se nazivaju profili (profiles). U kontekstu definicija i ideja iznetih  u  sekciji  1.2.5.2.  možemo reći  da priširenja  bazirana  na  izmeni  metamodela  koriste lingvističke   mehanizme   dok   proširenja   bazirana   na   profilima   koriste   ontološke   ili   logičke mehanizme.

1.3.2.6. Transformacije modela

Transformacije modela se najčešće dele na transformacije modela na modele (Model­To­Model ili M2M) i transformacija modela na programski kod (Model­To­Code ili M2C). Postoji struja  među pobornicima MDE koja programski  kod posmatra  kao model  na niskom nivou apstrakcije.  U teoretskom smislu ovakvo stanovište je ispravno ali je u praksi ipak poželjno praviti distinkciju između programskog koda i modela.

40

Uvodna razmatranja

Dugo vremena nije postojao standard u oblasti transformacija modela što je dovelo do kreiranja niza tehnika, tehnologija i alata koji najčešće nisu međusobno kompatibilne. OMG je uvideo hitnu potrebu za kreiranjem standarda kako bi se u oblasti uveo red ali se, s obzirom da je domen transformacija modela kompleksan, dosta dugo čekalo da se članovi konzorcijuma usaglase   o   finalnoj   specifikaciji.   Specifikacija   nosi   naziv   QVT (Queries/Views/Transformations) [MOF­QVT] i zasnovana je na tri jezika specifična za domen:

• Core – deklarativni jezik specificiran kao proširenje EMOF i OCL­a• Relations  – deklarativni   jezik  orijentisan  ka korisnicima  koji  omogućava  definisanje 

složenih   prepoznavanja   i   mapiranja   objektnih   obrazaca   kao   i   kreiranje   objektnih šablona.

• Operational Mappings –  imperativni jezik sa standardnim konstrukcijama kao što su iteracija, uslovno grananje itd.

U vreme pisanja  ovog rada nije  postojala  potpuna  implementacija  QVT specifikacije. Zbog nepotpune definisanosti   i  velike  kompleksnosti   standarda  postoje   sumnje  da  će  puna implementacija biti dostignuta [Wiki­QVT].

Zbog vakuuma koji   je  postojao  u domenu  transformacija  modela  često su u upotrebi implementacije   koje   nisu   formalno   standardizovane   ali   imaju   korisničku   bazu.   Jedan   od poznatijih   jezika   za   M2M   transformacije   je   ATL   (Atlas   Transformation   Language) [Bézivin01b,   ATL]   koji   ima   implemenacije   u   obliku   Eclipse   priključka   i   deo   je   AMMA platforme (videti 1.3.4.7).

U domenu M2C transformacija  postoji  veliki  broj popularnih implementacija  najčešće zasnovanim na obrađivačima šablona opšteg tipa kao što su npr. Velocity, Freemaker itd. Od specijalizovanih jezika izdvaja se jezik za šablone (template language) alata OAW – xPand (videti 1.3.4.2).

1.3.2.7. OCL – Object Constraint Language

OCL predstavlja   formalni   jezik  za definisanje  ograničenja  kao  i  postaljanje  upita  nad modelima [OCL]. Tekuća verzija 2.0 je razvijana u paraleli sa MOF 2.0 i UML 2.0 i usklađena je sa njima. Osnovni deo OCL­a je definisan u obliku MOF 2.0 metamodela i koristi koncepte MOF­a tako da se može nezavisno koristiti nad svim jezicima za modelovanje koji su formalno definisani   u   obliku   MOF   metamodela.   Ostatak   specifikacije   se   bazira   na   UML   jeziku   za modelovanje i može se korisiti samo u tom kontekstu.

OCL predstavlja jezik koji se može koristiti na nivou:

41

Uvodna razmatranja

• modela da definiše semantiku modela koju nije moguće iskazati strukturno, upotrebom samih konstrukcija jezika za modelovanje

• metamodela da definiše osobine jezika za modelovanje koje nije moguće iskazati samim meta­meta­modelom.

Prema [OCL] OCL predstavlja čist specifikacioni jezik pa je, prema tome, garantovano da evaluacija   OCL   izraza   ne   dovodi   do   propratnih   efekata,   odnosno,   evaluacija   ne   može   da promeni model čak i ako se, putem post­uslova, OCL izraz koristi da definiše promenu stanja.

Određeni   MDE   alati   koriste   OCL   izraze   za   opis   poslovne   logike.   Tako,   na   primer, AndroMDA (videti 1.3.4.1) može generisati jednostavne upitne metode na osnovu OCL izraza koji je pridružen metodi klase UML modela.

1.3.2.8. XMI - XML Metadata Interchange

XMI je široko rasprostranjen standard za razmenu objekata upotrebom XML(Extensible  Markup Language) standarda. Razmena objekata upotrebom XML standarda je sveobuhvatno rešenje  koje   se  bazira  na  razmeni  podataka  upotrebom XML­a.  XMI se  može  primenti  na različite klase objekata kao što su: analiza (UML), softver (Java, C++), komponente (CORBA, EJB), baze (CWM) ali se specifikacija najviše osvrće na upotrebu XMI standarda u serijalizaciji MOF baziranih modela, a pre svega UML modela [XMI].

XMI definiše sledeće aspekte koji su važni za predstavu objekata upotrebom XML­a:

• osnovu predstavlja reprezentacija objekata upotrebom XML elemenata i atributa,• s obzirom da objekti mogu biti povezani, XMI obezbeđuje mehanizam koji omogućava 

povezivanje objekata u okviru jednog fajla ili između fajlova,• da   bi   objekti   mogli   da   se   referenciraju   obezbeđena   je   jednoznačna   identifikacija 

objekata upotrebom XML identifkatora ili UUID­a,• omogućeno je verzioniranje objekata i njihovih definicija,• moguća je validacija XMI dokumenata upotrebom XML Schema i DTD standarda

Prema [Alanen05] XMI se suočava sa sledećim problemima :

• s obzirom da je XMI nezavistan od jezika za modelovanje dolazi do problema u razmeni modela   između  alata  koji  koriste   različite  verzije   istog   jezika  za  modelovanje   (npr. UML 1.3 i 1.4)

• MOF i UML ne sadrže informacije o vizuelnim karakteristikama modela što znači da XMI   nije   u   stanju   da   serijalizuje   informacije   o   prostornom   rasporedu   i   vizuelnim 

42

Uvodna razmatranja

atributima elemenata dijagrama sa kojima je model opisan. Zbog nepostojanja standarda za razmenu informacija o dijagramima, alati za modelovanje 

su koristili  vlasnička proširenja  što   je  onemogućilo   razmenu ovih  informacija   između alata različitih proizvođača. Da bi se ovaj problem rešio OMG je definisao specifikaciju za razmenu dijagrama     ­  Dijagram   Interchange  [XMIDI].   Ova   specifikacija   definiše   proširenje   UML metamodela   za   opis   vizuelnih   karakteristika   elemenata   dijagrama   i   njihovih   prostornih rasporeda.  Proširenje   je  definisano u obliku  dodatnog paketa   i  ne narušava postojeći  UML metamodel. Da bi bila moguća komunikacija sa alatima koji nemaju koncept modela, već rade sa grafičkim konceptima kao što su linija, krug, pravougaonik i sl. definisano je mapiranje XMI dokumenta na SVG (Scalable Vector Graphics)

1.3.2.9. HUTN – Human-Usable Textual Notation

HUTN je  OMG standard   i  predstavlja  mapiranje  MOF modela  na   tekstualni   jezik  sa idejom   lakog   čitanja   i   editovanja   od   strane   čoveka   [HUTN].  Osnovne   ideje   sa   kojima   je kreirana specifikacija su:

• generičnost  – specifikacija   je generička u smislu da definiše poseban  jezik za svaki MOF model,

• puna  automatizacija  –  na  osnovu  MOF modela   jednoznačno   je  određena  gramatika tekstualne  notacije   pa,   se  potpuno   automatski  mogu  definisati   alati   za   produkciju   i parsiranje modela,

• korišćenje od strane ljudi – HUTN jezici su kreirani imajući u vidu ljudsku upotrebu

Iako je XMI standard za razmenu modela (objekata u opštem slučaju) koji je baziran na XML­u, dakle u pitanju je tekst, čitljivost XMI dokumenata je diskutabilna. Sam XML, kao standard, je često kritikovan zbog svoje “guste” sintakse i loše čitljivosti tako da se ne smatra pogodnim   za   editovanje   od   strane   čoveka.   OMG   je   uvideo   probleme   u   ovom   domenu   i definisao HUTN standard čiji je cilj da reši ove probleme.

HUTN je specifikacija koja definiše familiju jezika koji prate određeni stil često prisutan u programskim jezicima dok su detalji jezika definisani samim MOF modelom. U primeru koji je prikazan u [HUTN] se nedvosmisleno vidi da je čitkost modela predstavljenih na ovakav način  u  odnosu  na  XMI daleko veća.  U domenima u kojima nije  potrebno  ljudsko čitanje serijalizovane predstave modela, niti njihovo ažuriranje, pogodniji način za razmenu je XMI zbog velike podrške alata za generisanje, parsiranje i validaciju XML dokumenata.

U [Muller05] je dat prikaz izrade DSL­a baziranog na HUTN specifikaciji.  Na osnovu 

43

Uvodna razmatranja

metamodela domena se generiše gramatika jezika na osnovu koje se dalje generišu parser i editor. Autori navode prednosti HUTN specifikacije u izradi prototipa jezika za opis sistema u kontekstu promenjivih metamodela jer se promenom metamodela može regenerisati novi editor i parser. 

1.3.3. MDSD

Model­Driven   Software   Development  (MDSD)   predstavlja   metodologiju   razvoja popularnu poslednjih godina. Nešto neprecizniji  ali  takođe često korišćeni akronim je MDD (Model­Driven   Development).   MDSD   predstavlja   MDE   pristup   pa   samim   tim   ima   dosta sličnosti sa drugim MDE pristupima (kao što je MDA). MDSD predstavlja skup ideja i tehnika izgradnje softvera upotrebom modela i njihovih transformacija. Osnovne ideje MDSD iznesene ovde su   implementirane  u  MDSD alatima  kao što  su OpenArchitectureWare   i  AndroMDA (videti 1.3.4.2 i 1.3.4.1).

1.3.3.1. Domenska arhitektura

Prilikom primene MDSD pristupa polazi se od koncepta domenske arhitekture [Stahl06]. Da bi se definisala  domenska arhitektura  polazi  se od referentne  implementacije  aplikacije. Referentna implementacija treba da je dovoljno obimna da obuhvati sve specifičnosti koje se sreću   u   aplikacijama   istog   tipa   (videti   sliku  1.11).   Analizom   referentne   implementacije programski kod delimo na:

• generički kod – predstavlja kod koji je nezavisan od konkrente aplikacije i bez izmene se može koristiti u drugim aplikacijama istog tipa,

• individualni kod – predstavlja kod koji je specifičan za konkretnu aplikaciju,• ponavljajući kod – predstavlja kod koji je specifičan za konkretnu aplikaciju ali se može 

uočiti određeni šablon na osnovu koga se programski kod kreira.

Individualni kod predstavlja deo aplikacije koji, na osnovu korišćene analize, nije moguće generisati   iz   modela   već   je   potrebna   ručna   implementacija.   Prilikom   analize   referentne implementacije težimo da količinu ovakvog koda minimizujemo.

Generički   programski   kod   je   invarijantan   u   odnosu   na   familiju   aplikacija   za   koju kreiramo  domensku  arhitekturu   i  potrebno  ga   je  kreirati   samo  jednom.  Ovaj  kod  se  može smatrati delom platforme za koju se aplikacija kreira.

44

Uvodna razmatranja

Slika 1.11 ­  Osnovne ideje MDSD pristupa

Ponavljajući kod je deo aplikacije gde MDSD pristup dolazi do izražaja. To je programski kod kod koga se uočava određena zakonitost u njegovoj strukturi. Ovaj deo aplikacije se može generisati  u potpunosti  na osnovu apstraktnih modela.  Modeli  se definišu upotrebom jezika specifičnih za domen i koriste koncepte definisane metamodelom. Transformacije su takođe definisane   upotrebom   jezika   specifičnih   za   domen   i   mogu   koristiti   elemente   modela   i metamodela.

Domenska arhitektura predstavlja skup metamodela domena, jezika specifičnih za domen, transformacija modela i platforme.

1.3.3.2. Razvoj softvera upravljan modelima baziran na arhitekturi (Architecture-Centric MDSD)

Architecture­Centric MDSD  (AC MDSD) predstavlja posebnu varijantu MDSD pristupa kod   koje   se   ne   teži   generisanju   programskog   koda   celokupne   aplikacije,   već   onog   dela aplikacije koji predstavlja arhitekturu i vrši integraciju sa softverskom infrastrukturom. Danas je AC MDSD najčešće korišćen pristup u praksi. Prema [Stahl06] 60%­70% programskog koda modernih informacionih sistema predstavlja upravo   programski kod koji, zapravo, ne donosi novu poslovnu vrednost,  već   je njegova namena zadovoljenje  forme koju nalaže softverska infrastruktura. Upotrebom AC MDSD, može se generisati 100% ovakvog koda. Najbolji primer za infrastrukturni kod su razni artifakti prilikom upotrebe J2EE tehnologija:  home interface, remote   interface,  Beans,   deskriptori   itd.  Često   infrastrukturni  programski  kod  aplikacije,  u zavisnosti   od  programskog  modela   korišćene   tehnologije,   ima  dosta   redundanse.  Kreiranje ovakvih artifakta ručno brzo postaje zamorno i čest je izvor grešaka. Takođe je veliki problem kasnije održavanje sistema jer male promene u poslovnom domenu često iziskuju više promena 

45

Uvodna razmatranja

u programskom kodu pri čemu programer mora da pazi da uradi prave promene na pravim mestima i da nešto ne izostavi. AC MDSD rešava ovaj problem na taj način što se promena unosi u model aplikacije, a dalje se upotrebom generatora koda promena automatski propagira kroz programski kod aplikacije.

AC MDSD se u praksi najčešće implementira upotrebom UML­a sa profilima koji su bazirani  na arhitekturi  aplikacije   (npr.  koriste  koncepte  kao što  su entitet,  DAO, vrednosni objekat,   servis   itd.).   Dalje   se   ovakav   model   transformiše   u   programski   kod   upotrebom obrađivača  šablona (template engine)  pri  čemu je  struktura koda opisana samim šablonom. M2M transformacije u kontekstu AC MDSD se retko koriste. S obzirom da je fokus AC MDSD na   tehničkim   i   arhitekturalnim   aspektima,   semantički   jaz   između   samog   domena   i implementacije i dalje postoji tako da programeri moraju ručno da implementiraju poslovnu logiku.

1.3.3.3. Tehnike generisanja koda

S obzirom da su tehnologije koje bi omogućile direktno izvršavanje modela još uvek u ranim fazama razvoja, većina MDE tehnika se bazira na transformisanju modela u programski kod   i   zatim   korišćenje   klasičnih   pristupa,   kompajliranja   programskog   koda   ili   njegovog izvršavanja na virtuelnim mašinama. Zbog toga je generisanje koda veoma značajno, kako sa aspekta funkcionalnosti tako i sa aspekta performansi.

Generatori se prema mogućnosti kružnog inženjerstva (round­trip engineering) dele na pasivne   i   aktivne   [CG­OPG].  Pasivni   generatori   (npr.   čarobnjaci   –  wizards)   se   koriste   za inicijalno generisanje koda koji se kasnije ručno održava. Aktivni generatori, osim inicijalnog generisanja koda, imaju mogućnost izmene koda u skladu sa promenama specifikacije.

Prema  [Stahl06]  generatori  koda  su  metaprogrami   (programi  koji  generišu  programe) koji, kao ulazne parametre, dobijaju specifikaciju programa i generišu programski kod kao izlaz (tzv. bazni program). Metaprogrami se mogu izvršiti u različitim fazama u odnosu na vreme izvršavanja baznog programa:

• nezavisno od baznog programa tj. pre izvršenja baznog programa,• za vreme kompajliranja baznog programa,• za vreme izvršavanja baznog programa

Najveći  broj  generatora  koristi  prvi  pristup  i  obično se metaprogram i  delovi  baznog programa,  koji   se  definišu  ručno,  zadaju  u  odvojenim fajlovima.  Generisani  kod  je   takođe odvojen od ručno kreiranog i mora se integrisati od strane programera.

46

Uvodna razmatranja

Primer upotrebe drugog pristupa bio bi predprocesor i mehanizam šablona (templates) kod programskog jezika C++. U ovom slučaju metaprogram i delovi ručno pisanog koda su zadati   zajedno  unutar   istih   fajlova.  Takođe,   generisani   kod   je   pomešan   sa   ručno  pisanim. Ovakav način generisanja koda naziva se statičko metaprogramiranje (static metaprogramming) [Stahl06].

Dinamički jezici kao što su Lisp, Smalltalk, Ruby, Python i dr. omogućavaju kreiranje, odnosno modifikaciju programa u vreme izvršavanja što znači da se metaprogrami izvršavaju u vreme izvršavanja baznog programa i nadopunjuju ga ili modifikuju.

U praksi se, u kontekstu MDSD, koriste sledeće tehnike generisanja koda [Stahl06]:

• Šabloni i filtriranje (templates + filtering)

Ovo je najjednostavniji oblik generisanja. Iz specifikacije, koja je zadata tekstulano, se filtriraju   relevantne   informacije   i   zatim se putem njih   inicijalizuju  varijabilni  delovi šablona.   Problem   sa   ovim   pristupom   je   jaka   sprega   sa   sintaksom   jezika   za   opis specifikacije (npr. XML) što čini da se ovaj pristup loše skalira.

• Šabloni i metamodeli (templates + metamodels)

Ovaj pristup, za razliku od prethodnog, obradu obavlja u dva koraka. U prvom koraku specifikacija   se   parsira   i   predstavlja   kao   instanca  metamodela   u  obliku   apstraktnog sintaksnog stabla (AST­Abstract Syntax Tree). U drugoj fazi se generiše kod tako što šablon referencira elemente AST­a. Prednost pristupa je u tome što je faza generisanja koda nezavisna od konkretne sintakse specifikacije i što je moguće validaciona pravila ugraditi  u  sam metamodela  čime će parser  moći  da proveri   ispravnost  specifikacije. OpenArchitectureWare koristi ovaj pristup.

• Obrađivači okvira (frame processors)

Osnovni   elementi   ovog   pristupa   su   okviri   (frames)   koji   predstavljaju   kod   koji   se generiše i imaju varijabilne delove (slots). Okvir se može instancirati više puta pri čemu se, prilikom svakog instanciranja, vrši dodela konkretnih vrednosti za slotove. Vrednosti slotova mogu biti bilo šta, od stringova do drugih okvira čime se dobija struktura tipa stabla. Instancirani okviri, zatim, direktno generišu programski kod.

• API­bazirani generatori (API­based generators)

Kod se kreira upotrebom API specifikacije ciljne platforme ili jezika. Bazirani su na manipulaciji   AST­om.   Primer   bi   bio   upotreba   DOM   generatora   koja   omogućava dinamičko  kreiranje  XML  fajlova  putem  instanciranja  odgovarajućih  klasa   i   poziva odgovarajućih metoda DOM API­ja.

47

Uvodna razmatranja

• In­line generatori (in­line generators)

In­line   generisanje   koda   podrazumeva   situaciju   kod   koje   bazni   program   sadrži programski   kod   koji   kreira   programski   kod   u   vreme   kompajliranja   ili   neke   vrste predprocesiranja (npr. C++ predprocesor).

• Atributi koda (code attributes)

Ovaj   pristup   se   bazirna   na   metapodacima   pridruženim   elementima   koda.   Jedna   od najranijih  upotreba,  kada   je  programski   jezik   Java  u  pitanju   jeste  alat   Javadoc  koji omogućava   automatsko   generisanje   HTML   dokumentacije   programskog   koda   na osnovu   atributa   koda   kreiranih   u   obliku   posebnih   komentara.   Danas   se   u   svrhu definisanja atributa koda najčešće koriste posebne jezičke konstrukcije kao što su java anotacije.

• Tkanje koda (code weaving)

Ova   tehnika   omogućava   mešanje   razdvojenih   ali   sintaksno   potpunih   delova   koda. Potrebno je definisati na koji način se ti delovi koda spajaju putem lokacija u kodu koje se   nazivaju   tačke   spoja   (join  points).  Ovakav  vid  generisanja   je   pokrenuo  posebnu paradigmu   razvoja   softvera   pod   nazivom   programiranje   orijentisano   ka   aspektima (Aspect   Oriented  Programming)   jer   omogućava   izdvajanje   određenih   prožimajućih aspekata (npr. perzistencija, loging itd.) u nezavisne fajlove. Generator se brine o tome da  u  vreme   izvršavanja   dođe  do   spajanja   koda   aspekata   sa   baznim  programom  na osnovu definisanih pravila.

1.3.3.4. Integracija ručno pisanog i generisanog koda

S obzirom da   se   u   praksi,   još   uvek,   100% generisanje   programskog  koda  postiže  u ograničenim   oblastima   primene  potrebno   je   delove   programskog  koda   aplikacije   definisati ručno. Određene klase generatora omogućavaju da se generisani kod i ručno kreirani kod nalaze u istom fajlu. Iako ovakvi generatori imaju prednost u vidu implicitne integracije generisanog i ručno  pisanog   koda,   u   praksi   se   pristup  pokazao  kao  problematičan   jer   dolazi   do  velikih problema u konzistentnosti, upravljanju izgradnjom (build management), upravljanju verzijama (generisani  kod se  mora  voditi  u   sistemu za  kontrolu  verzija)   itd.   [Stahl06].  Zbog   toga   je preporuka da se generisani programski kod i ručno pisani programski kod čuvaju na odvojenim lokacijama i da se generisani kod nikada ručno ne menja. Generisani kod ne treba da uđe u sistem za kontrolu verzija jer je model artifakt koji treba čuvati u sistemu za kontrolu verzija. Generisani kod se u svakom trenutku može u potpunosti obrisati i ponovo generisati iz modela. Generisani  kod,   iako  predstavlja  programski  kod,  možemo posmatrati  analogno produktima 

48

Uvodna razmatranja

kompajliranja   kod   viših   programskih   jezika.   Na   primer,   objektni   i   izvršni   fajlovi   kod kompajliranja C koda ili class fajlovi kod kompajliranja java koda. 

Kod generatora kod kojih je generisani programski kod odvojen od ručno pisanog mora postojati   eksplicitan   mehanizam   integracije.   Najčešći   oblik   integracije,   kada   su   objektno orijentisani ciljni jezici u pitanju, je korišćenje tzv. troslojne implementacije. Kod ovog pristupa identifikovane su tri vrste funkcionalnosti koju komponenta treba da zadovolji:

• funkcionalnost identičnu za sve komponente istog tipa

realizuje  se  kao klasa platforme koja   implementira  zajedničku funkcionalnost   i  koju nasleđuju generisane klase.

• funkcionalnost koja je različita za svaku komponentu ali se može generisati iz modela

realizuje se kao klasa koja se generiše iz modela i nasleđuje klasu platforme.

• funkcionalnost koja se mora implementirati ručno

implementira   se   ručno   pri   čemu   se   najčešće   inicijalna   verzija   generiše   prilikom pokretanja generatora ukoliko fajl već ne postoji. Prvobitna verzija je tzv. dummy klasa. Ukoliko ručna implementacija već  postoji  generator ne sme da je na bilo koji način izmeni.

Troslojna implementacija se najčešće kombinuje sa različitim dizajn obrascima da bi se ostvarila potpuna integracija. Obrasci koji se najčešće koriste su sledeći:

• generisani programski kod poziva ručno pisani.• ručno pisani programski kod poziva generisani.• generisana  klasa  nasleđuje   i   redefiniše  metode   apstraktne,   ručno  pisane,   klase  koja 

implementira metode ručno pisanog interfejsa. Instancira se generisana klasa.• ručno pisana klasa nasleđuje i redefiniše generisanu klasu.• generisana klasa nasleđuje, modifikuje i poziva metode ručno pisane klase.• generisana klasa nasleđuje ručno pisanu, metode ručno pisane klase pozivaju metode 

generisane klase (Template Method dizajn obrazac).

49

Uvodna razmatranja

Postoje i razni drugi mehanizmi koji su najčešće specifični za određenu ciljnu platformu ili određene alate. Tako je, na primer, u .NET tehnologiji moguće definisati parcijalne klase. Putem ovog mehanizma moguće  je  deo klase napisati  ručno,  a deo generisati  u  odvojenim fajlovima. Određeni alati (npr. AndroMDA – videti  1.3.4.1) koriste mehanizme označavanja generisanog koda i zatim umetanja ručno pisanog koda na za to predviđene lokacije definisane oznakama.  Ovim se omogućava  integracija  bilo  kakvog  tekstualnog koda (programski  kod, XML,   HTML   itd.)   uz   očuvanje   separacije   ručno   pisanog   i   generisanog   koda   u   posebnim fajlovima.

1.3.3.5. Kružno inženjerstvo

Kružno inženjerstvo (roundtrip engineering­ videti 1.3.2.3) predstavlja pristup po kome je moguće  modifikovati  model  kao   i  generisani  kod pri  čemu se   alat  brine  da  održi  njihovu međusobnu sinhronizaciju. Alati koji omogućavaju ovakav pristup najčešće vrše trivijalno 1 na 1 mapiranje između modela i koda (npr. klasa UML dijagrama se mapira na java klasu) tako da su model i kod na istom nivou apstrakcije. Model u tom slučaju predstavlja samo drugačiju reprezentaciju programskog koda bez podizanja nivoa apstrakcije.

MDSD   koristi   drugačiji   pristup.   Model   je   uvek   na   višem   nivou   apstrakcije   od programskog koda čime  je   sinhronizacija  modela  pri  promeni  programskog koda praktično nemoguća. Zbog toga je MDSD pristup eksplicitno protiv potpunog kružnog inženjerstva ali u potpunosti podržava parcijalno kružno inženjerstvo prema podeli iznetoj u [Frankel03] (videti 1.3.2.3)

Da bi se nadomestila nemogućnost izmene generisanog koda u [Stahl06] su predloženi sledeći pristupi, navedeni po redosledu elegantnosti rešenja:

• apstrakcija 

podrazumeva izmenu modela na takav načina da se postigne željena izmena generisanog programskog koda. Ovo je najpoželjniji način izmene jer je namera vidljiva na najvišem nivou apstrakcije upotrebom koncepata domena.

• označavanje modela (tagging)

model   se  označava  upotrebom oznaka  koje   su  zavisne  od  ciljne  platforme.  Ovakav mehanizam   može   dovesti   do   kontaminacije   modela   konceptima   koji   nisu   bliski ekspertima domena tako da je poželjno da se prikazivanje oznaka može isključiti  po potrebi.

50

Uvodna razmatranja

• posebne, ručno pisane klase

podrazumeva   način   definisanja   domenske   arhitekture   na   taj   način   da   se   ručna modifikacija  piše  u  posebnim za   to  predviđenim klasama  (ili  drugim ekvivalentnim elementima koje definiše ciljna platforma).

• označavanje koda

podrazumeva uvođenje oznake u generisanom kodu putem kojih se kreiraju zaštićene regije koda tj. regije koje neće biti modifikovane na bilo koji način prilikom ponovnog generisanja koda.

1.3.4. Pregled vodećih MDA/MDSD alata

1.3.4.1. AndroMDA

AndroMDA  [AndroMDA]  projekat   je   jedan   od   pionira   MDA   pokreta   kada   su implementacije  otvorenog koda u pitanju.  Predstavljen  opis  je  baziran  na verziji  3.2 ovoga alata.  Pristup  koji  AndroMDA koristi   je  definisanje  modela  sistema zavisnog od platforme (PSM), za šta se koristi UML proširen odgovarajućim profilom. UML model, dakle,    putem stereotipa  i  oznaka definiše  dodatne  informacije  potrebne za sam proces generisanja.  Mada AndroMDA čita model zapisan u standardnom XMI formatu, čime je teoretski moguće koristiti bilo koji UML alat koji implementira ovaj standard, preporuka razvojnog tima je upotreba alata MagicDraw.   Generisanje   koda   se   obavlja   upotrebom   tzv.   kertridža.   Kertridž   predstavlja softverski modul koji na osnovu oznaka i stereotipa elemenata UML modela generiše kod za ciljnu platformu. Transformacija modela u kod se obavlja upotrebom šablona (templates)  za čiju obradu se koriste obrađivači šablona (template engines). Trenutno korišćeni obrađivači su Velocity i FreeMaker. 

AndroMDA   dolazi   sa   velikim   brojem   kertridža   za   standardne   platforme   (Java, EJB, .NET, Hibernate, Struts itd.) koji generišu kvalitetan kod čime se omogućava brza izrada prototipa aplikacija kao i kompletnih rešenja ukoliko je potrebno generisati  kod za neke od navedenih   standardnih   platformi.   Proširivanje   generisanog   koda   (ukoliko   je   na   objektno orijentisanom jeziku) je predviđeno uz oslonac na standarni mehanizam nasleđivanja ­ ručnim pisanjem klasa naslednica koje proširuju/redefinišu željeno ponašanje klase pretka. Generisani kod koji  nije  na objektno orijentisanom jeziku (XML i konfiguracioni  fajlovi,   itd)  se može proširivati umetanjem koda na unapred označenim mestima (tag­ovima) u okviru šablona, kao i zamenom šablona. Zamena šablona se obavlja navođenjem direktorijuma fajl sistema u kojima 

51

Uvodna razmatranja

će se obaviti traženje pre korišćenja šablona sadržanog u samom kertridžu.

Mada  je  u   samom jeziku  za  zadavanje  šablona  moguća  manipulacija  meta­objektima često   je   transformacija  modela  u  kod  previše   složena  da  bi  na   efikasan   i  čitak  način  bila definisana u samom šablonu. Zbog toga je bilo potrebno pronaći  mehanizam da sami meta­objekti mogu izvršiti transformaciju i emitovati programski kod čime bi složenije M2C (Model­To­Code) transformacije mogle biti iskazane na Java programskom jeziku a ne na jeziku za opis šablona. U to vreme korišćen repozitorijum meta­podataka MDR (Meta­Data Repository)  je instancirao meta­klase korišćenjem tehnike generisanja bajt koda. Zbog toga je bilo nemoguće redefinisati ponašanje meta­klasa upotrebom standardne OO tehnike nasleđivanja. Kao rešenje ovoga problema nametnula se upotreba Facade dizajn obrasca.

Kreiranje kertridža podrazumeva kreiranje tzv. meta­fasada (slika  1.12), odnosno klasa koje predstavljaju fasade za prave meta­klase modela. U ovim klasama se definišu metode koje će se pozivati iz šablona i čiji je zadatak da vrate string na osnovu informacija u meta­objektima modela.   Povezivanje   šablona   sa   konkretnim   meta­objektima   (instancama   meta­fasada)   se obavlja u konfiguracionim fajlovima kertdridža gde se definiše putanja do šablona i uslov koji mora da ispunjava meta­objekat (najčešće ime stereotipa) da bi se šablon primenio nad njim.

Validacija  modela   je  moguća  upotrebom OCL  izraza  koji   se  mogu  zadati  nad  meta­fasadama i vrši se neposredno pre generisanja koda.

Kao infrastruktura za meta­modelovanje u ranijim verzijama alata korišćen je Meta­Data  Repository  (MDR)  MOF  implementacija  dok   je  u  novoj  verziji   dodata  podrška   i   za  EMF odnosno ECore.

Što se tiče performansi alata, one nisu na zavidnom nivou. To je i razumljivo s obzirom da mehanizam toka poslova (workflow) ne postoji već se nad modelom primenjuju svi kertridži 

52

Slika 1.12 ­ AndroMDA metafasade

Uvodna razmatranja

koji se   detektuju u putanji  klasa (classpath) putem pronalaženja i parsiranja odgovarajućih konfiguracionih fajlova na unapred definisanim lokacijama. Takođe, koriste se, prilično spori obrađivači  šablona  opšte  namene.  Ovaj  problem  je  donekle   rešen postojanjem AndroMDA servera   koji   omogućava   da   se   jednom   uradi   inicijalizacija   alata,   otkrivanje   i   registracija kertridža, a zatim server, u slučaju detekcije promene nad modelom, vrši ponovno generisanje koda.

Za sada ne postoje mehanizmi M2M (Model­To­Model) transformacija, bilo da je reč o punoj ili inkrementalnoj transformaciji, kreiranja toka poslova (workflow), jače integracije sa ručno   pisanim   kodom,   mogućnosti   ponovnog   generisanja   programskog   koda   uz   očuvanje ručnih izmena itd.  Neke od ovih mogućnosti  će biti   implementirane u verziji  4.0 koja  je  u vreme pisanja ovog teksta bila u razvoju.

1.3.4.2. openArchitectureWare

OpenArchitectureWare [OAW] je projekat koji je inicijalno razvijan pod komercijalnom licencom, od strane firme  b+m Informatk AG, a kasnije je objavljen pod licencom otvorenog koda. Osnovne osobine OAW alata su integracija sa eclipse platformom i korišćenje EMF kao infrastrukture za meta­modelovanje.

Za   razliku  od  AndroMDA alata   koji   polazi  od  UML­a,    OAW ne  nameće  upotrebu određenog meta­modela. Moguće je koristiti klasičan pristup kod koga se modeluje sa UML­om   uz   upotrebu   odgovarajućeg   profila.   Preporučeni   alat   za   modelovanje   je,   kao   i   kod AndroMDA, MagicDraw mada mogu da se koriste svi alati koji mogu da eksportuju model u XMI format koji odgovara UML2 meta­modelu predstavljenom uz pomoć ECore meta­meta­modela.

Drugi način upotrebe alata je definisanje meta­modela specifičnog za domen (domain­specific meta­model), odgovarajuće tekstualne i/ili grafičke notacije, transformacionih pravila i šablona   za   generisanje   koda.   Na   osnovu   opisa   tekstualne   ili   grafičke   notacije   moguće   je, upotrebom OAW ili eclipse alata, generisati odgovarajuće tekstualne, odnosno grafičke editore koji omogućavaju modelovanje korišćenjem jasno definisanog, kompaktnog, jezika specifičnog za domen.

Za razliku od AndroMDA pristupa OAW definiše svoje jezike za definisanje ograničenja, definisanje šablona, definisanje transformacionih pravila i proširenja semantike meta­modela. Svi OAW jezici  koriste jedinstven jezik izraza (expression language) i  sistem tipova (type­system). Za svaki od jezika postoji editor za eclipse platformu sa standardnim mogućnostima 

53

Uvodna razmatranja

bojenja i provere sintakse. Redosled transformacija i ostalih akcija je moguće definisati putem toka poslova (workflow) koji se zadaje konfiguracionim XML fajlom.

Značajna mogućnost OAW alata je definisanje meta­modela specifičnog za domen čime se   može   izbeći   upotreba   meta­modela   opšte   namene   kakav   je   UML   i   postići   veći   nivo apstrakcije i kompaktnosti  modela.

EMF model koji odgovara zadatom meta­modelu je moguće unositi putem:

• automatski generisanog editora tipa stabla (tree­view editor) za čije generisanje imamo podršku samog EMF­a, 

• grafičkog editora, za čije delimično generisanje možemo koristiti alat GMF (Graphical  Modeling Framework)[GMF],

• tekstualnog editora čije generisanje je moguće upotrebom OAW xText komponente na osnovu gramatike tekstualne notacije,

• klasičnih UML alata za modelovanje i zatim transformacijom datog modela iz UML meta­modela u željeni meta­model za šta imamo podršku OAW­a.

OAW spada  u  klasu  okvira  za   razvoj  generatora   (generator   framework)   jer  poseduje mogućnost kreiranja namenskih generatora i alata za definisanje modela na jeziku specifičnom za domen (domain­specific language).

Za definisanje ograničenja nad modelima koristi se funkcionalni jezik  Check  koji je u velikoj meri sličan OMG standardnom jeziku OCL. Na listingu 1.1 je dat primer Check  izraza za proveru ispravnosti  elementa  modela.  Moguće je  korišćenje  i  standardnog OCL­a putem OSLO (Open­Source Library for OCL) OAW priključka.

context Entity ERROR "Osobine moraju imati jedinstveno ime!" : features.forAll(e1 | !features.exists(e2 | (e1 != e2) && (e1.name == e2.name)));

Listing 1.1 ­  Check ograničenje nad elementima modela

Za   zadavanje   semantičkih   proširenja   meta­modela,   pomoćnih   procedura   kao   i   opisa transformacije modela koristi se jezik za proširenje Extend. Korišćenjem ovog jezika mogu se na neinvazivan način proširiti meta­klase u cilju podrške šablonima za generisanje koda. Listing 1.2. prikazuje Extend iskaz.

54

Uvodna razmatranja

cached EDataType eType(Terminal this) : assignOperation==AssignOperation::BOOLASSIGN ? eBoolean() :

eType(token);

Listing 1.2 ­ Proširenje meta­klase putem Extend iskaza

Šabloni se zadaju u jeziku xPand (listing  1.3) za koji je, kao i za ostale jezike OAW­a, implementiran   editor   za   eclipse   platformu   sa   mogućnostima   bojenja   sintakse,   dinamičke provere grešaka itd. Šabloni se mogu nasleđivati, podržan je polimorfizam i mogu se primeniti tehnike aspektno orijentisanog programiranja (Aspect­Oriented Programming) sa ciljem izmene generisanog koda bez fizičke izmene šablona.

«DEFINE element FOR Service» «FILE name+"Service.java"» package «getFullyQualifiedPackage()»; import igord.utilities.services;

class «name+"Service"» extends AbstractService {

«EXPAND operation FOREACH operations» } «ENDFILE»«ENDDEFINE»

Listing 1.3 ­ xPand šablon

Integracija   sa   ručno   pisanim   kodom   je   omogućena   standardnim   mehanizmima nasleđivanja  kada   je  u  pitanju  objektno  orijentisani   jezik  ciljne  platforme  ili  mehanizmima AOP.  Dodatna   integracija   ručno  pisanog  koda  omogućena   je   upotrebom  Recipe  okvira   za razvoj  kojim je moguće definisati  pravila  koja  ručno pisan kod mora da  ispoštuje  da bi  se aplikacija   smatrala   validnom.   Na   primer,   može   se   definisati   da   se   generisana   klasa   mora naslediti ručno pisanom klasom i sl.

Za razliku od AndroMDA, podrška u vidu gotovih kertridža je u vreme pisanja ovoga rada bila slaba, mada postoje jasne indicije da će se situacija na ovom polju promeniti. Kreirana je  fornax  platforma   čiji   je   cilj   između   ostalog   i   kreiranje   kertridža   za   OAW.  Posebno   je interesantan deo fornax platforme pod imenom Sculptor (videti 1.3.4.8) koji predstavlja DSL za opis Enterprise Java rešenja uz podršku generisanja Spring i Hibernate koda.

U radu [Dejanović07]   je dat uporedni  prikaz AndroMDA i oAW alata   i  navedene su njihove prednosti i mane.

55

Uvodna razmatranja

1.3.4.3. OptimalJ

OptimalJ [OptimalJ] je popularan komercijalni alat firme Compuware. Modelovanje se vrši upotrebom UML 2.0 sa profilima pri čemu je iskorišćen alat za modelovanje MagicDraw firme NoMagic [MagicDraw]. Alat je realizovan upotrebom programskog jezika Java i koristi se za generisanje J2EE aplikacija. Moguće ga je koristiti u saradnji sa Eclipse platformom.

Modelovanje u OptimalJ se vrši na visokom nivou apstrakcije gde se definišu poslovni objektni i servisi koje aplikacija pruža. Posebno značajna mogućnost je definisanje poslovnih procesa u vidu modela koji definišu redosled i uslove pod kojima se komponente mogu izvršiti. U   terminologiji   OptimalJ­a   ovakav   vid   razvoja   naziva   se   razvoj   orijentisan   ka   procesima (Process Oriented Development – POD).

OptimalJ   dolazi   sa   velikim   brojem   gotovih   M2C   transformacija   koje   omogućavaju generisanje koda za Struts, DAO, EJB, veb servise, sisteme za upravljanje bazama podataka itd. Ovakav pristup omogućava  implementaciju  najboljih  načina  upotrebe  i  dizajn  obrazaca bez potrebe samih programera da imaju detaljno znanje o njima.

Grafički korisnički interfejsi se u OptimalJ­u kreiraju upotrebom WYSIWYG (What You  See Is What You Get) vizuelnog editora koji omogućava korisniku jednostavno postavljanje vizuelnih komponenti sa palete na formu.

Uvođenje (deployment) je automatizovano za predefinisan skup aplikativnih servera.

1.3.4.4. GME

GME (Generic Modeling Environment) [GME] je najpoznatiji alat koji promoviše MIC ideje   (videti  1.3.1).   Razvijen   je   na   Vanderbilt   univerzitetu   na   bazi   Microsoft   tehnologija. Posebno je popularan u okviru ugrađenih sistema u realnom vremenu (real­time embedded) kao i sistema sa ograničenim resursima.

GME ima sledeće bitne osobine [GME­Manual]:

• koristi se prevashodno za kreiranje modela.  Modeli imaju formu grafičkih dijagrama tipa   entitet­veza   sa   atributima,   pri   čemu   su   podržani   višestruki   aspekti.   Dinamička semantika modela nije od značaja za sami GME alat. Ona se definiše kasnije u procesu interpretacije modela,

• poseduje različite tehnike za izgradnju kompleksnih modela velikih razmera. Tehnike uključuju: hijerarhije, višestruke aspekte, skupove, reference i definisanje eksplicitnih 

56

Uvodna razmatranja

ograničenja,• poseduje jedan ili više integrisanih interpretera modela koji vrše prevođenje ili analizu 

modela koji se trenutno razvija.

Kreiranje DSL­a se odvija procesom metamodelovanja pri čemu se koristi UML notacija sa    OCL  jezikom za  ograničenja.  Kreiran  metamodel   se  koristi   za  automatsko  generisanje okruženja za razvoj prilagođenog domenu. Kreirani modeli se mogu čuvati u repozitorijumu modela (u bazi podataka) ili u obliku XML fajlova.

Opis   sintaksnih,   semantičkih   i   prezentacionih   informacija   o   domenu   naziva   se,   u terminologiji   GME   alata,   paradigma   modelovanja   (modeling   paradigm).   Paradigma modelovanja predstavlja opis koncepata koji se mogu koristiti  za konstrukciju modela, vrste veza, na koji način se koncepti mogu vizuelno predstaviti itd. Paradigma modelovanja definiše familiju modela koji se mogu kreirati upotrebom GME alata konfigurisanih datom paradigmom.

Osnovni koncepti koje alat koristi u izgradnji paradigme modelovanja su:

• model – predstavlja apstraktan koncept koji opisuje nešto iz stvarnog sveta. Može imati delove (parts) koji mogu biti takođe modeli čime dobijamo hijerarhiju modela, zatim atomi, reference, skupovi, konekcije. Delovi su u roditelj­dete vezi sa svojim modelom. Kažemo da je model roditelj (parent)  svojih delova. 

• atom – predstavlja koncept koji opisuje nešto što je nedeljivo i nema internu strukturu. Atom može imati samo atribute.

• referenca – konceptualno je slična referencama ili pointerima iz klasičnih programskih jezika. Omogućava pristup elementima modela definisanim na drugim mestima.

• konekcije  i   linkovi – predstavljaju  koncept  putem kojeg se mogu ostvarivati  relacije između elemenata modela

• skupovi (sets) – omogućavaju reprezentacije dinamike modela. Model se posmatra kao živ entitet  koji može imati  svoje stanje u vremenu i prostoru. Skupovi omogućavaju predstavu stanja modela.

• aspekti   (apspects)   –   predstavljaju   mogućnost   definisanja   elemenata   modela   koji   se skrivaju   ili   se   prikazuju   u   određenom   aspektu.   Iako   hijerarhijsko   modelovanje omogućava prikaz modela na određenom nivou hijerarhije kod kompleksnih modela to nije  dovoljno  da  bi   se  prikaz  učinio  preglednim pa  su  uvedeni  aspekti  kao  dodatni mehanizam.

• atributi   –   predstavljaju   elemente   koji   se   mogu   dodeliti   modelima,   atomima, referencama,   skupovima   i  konekcijama.  Atribut  predstavlja  osobinu  objekta  koja   se najbolje  opisuje   upotrebom  teksta.  Paradigma  modelovanja   definiše  atribute   koji   se mogu dodeliti određenim elementima, njihove moguće vrednosti itd.

57

Uvodna razmatranja

• preference (preferences) – predstavljaju osobine objekta koji ne zavise od paradigme modelovanja. Primer bi bio helpURL, boja, boja teksta itd.

GME se može proširiti  komponentama koje podržavaju MS COM (Component Object  Model) tehnologiju što znači da je proširenja moguće pisati u različitim jezicima kao što su C++, C#, Visual Basic, Python itd.

1.3.4.5. GEMS

GEMS (Generic  Eclipse  Modeling  System)[GEMS] predstavlja  projekat  čiji   je  cilj  da premosti   jaz   između   tehnologija   i   alata   organizovanih   oko   GME   i   MIC   ideja   i   onih organizovanih   oko   Eclipse   platforme   i   EMF   infrastrukture.   GEMS   u   osnovi   predstavlja implementaciju GME koncepata u Eclipse okruženju.

GEMS posebnu pažnju poklanja kompleksnoj analizi, simulaciji i zadavanju ograničenja nad modelom kao i problemima skalabilnosti  koji  postoje kod ručnog modelovanja.  GEMS poseduje komponentu Model Intelligence Guide (MIG) čija je namena automatizacija i pomoć u procesu modelovanja putem “inteligentnih” preporuka i  izmena modela u  toku editovanja u cilju   zadovoljenja   globalnih   ograničenja.   Trenutna   verzija   GEMS   se   bazira   na   kreiranju EMF/Draw2d/GEF baziranih  editora  ali   je  u   toku migracija  na GMF (Graphical  Modeling  Framework) platformu. Razvijeni su alati za import GME metamodela i modela.

1.3.4.6. MetaEdit+

MetaEdit+  [MetaEdit+]   je  komercijalni  alat   firme MetaCase.  Razvija  se  već  dugi  niz godina   i   ima  veliku   zastupljenost   u   industriji.   Paradigma  koju   alat   koristi   je  modelovanje specifično za domen (Domain Specific Modeling) (videti  1.3.1). Metamodelovanje se u alatu obavlja popunjavanjem niza dijaloga putem kojih se kreiraju:

• objekti (objects) – osnovni koncepti jezika za modelovanje• osobine (properties) – predstavljaju osobine objekata tj. njihove atribute• relacije (relationships) – opisuju veze koje je moguće kreirati između objekata• uloge   (roles)   –   opisuju   krajeve   veza   i   definišu   ulogu   objekta   povezanog   na 

posmatranom kraju,• portovi (ports) – definišu tačke povezivanja objekta sa definisanim ograničenjima,• grafovi   (graphs)   –   predstavljaju   specifikaciju   tehnike   modelovanja.   Tehnika 

58

Uvodna razmatranja

modelovanja se sastoji od objekata, relacija i uloga zajedno sa pravilima na koji način se oni mogu zajedno koristiti.

Modeli se mogu pregledati i ažurirati u obliku dijagrama, matrica, tabela i editora tipa stablo. Alat propagira promene nastale u jeziku za modelovanje kroz sve modele koji ga koriste i  ova  operacija  se  obavlja  nedestruktivno.  Omogućena   je   saradnja  članova  projektnog   tima putem   automatskih   integracija   modela.   Takođe   je   moguća   interakcija   sa   alatom   putem programabilnog interfejsa uz korišćenje standardnih i široko prihvaćenih tehnologija (SOAP, veb servisi, .NET).

1.3.4.7. AMMA

AMMA  (ATLAS   Model  Management  Architecture)  [Bézivin05,   Bézivin06b,  AMMA] predstavlja  arhitekturu za specifikaciju   i  kreiranje   jezika specifičnih za domen i  upravljanje modelima razvijenu od strane ATLAS grupe.

AMMA se sastoji od sledećih komponenti:

• ATLAS Tranformation Language  (ATL) – je DSL za transformaciju modela sa jakom korisničkom bazom.  Koriste  ga  MDA alati  kao što   su  AndroMDA i  OAW. Postoji slobodno dostupan repozitorijum ATL transformacija.

• ATLAS   Model   Weaver  (AMW)   –   je   alat   koji   omogućava   integraciju   modela predstavljenih upotrebom različitih jezika za modelovanje.

• ATLAS   MegaModel   Management  (AM3)   –   predstavlja   infrastrukturu   namenjenu registraciji   i  upravljanju  artifaktima za modelovanje  kao što  su modeli,  metamodeli, transformacije i relacijama između njih.

• Kernel Metametamodel (KM3)  je tekstualni DSL za opis metamodela.• Textual Concrete Syntax  (TCS) je tekstulani DSL za definisanje konkretne tekstualne 

sintakse.

Trenutno AMMA ne poseduje mehanizme eksplicitnog definisanja semantike DSL­ova već se to obavlja definisanjem transformacija na DSL­ove ili GPL­ove koji imaju definisanu semantiku. U toku su istraživanja koja koriste apstraktne konačne automate u cilju definisanja semantike DSL­ova [Bézivin06b].

59

Uvodna razmatranja

1.3.4.8. Sculptor

Sculptor  [Sculptor]  je  deo  fornax  platforme čiji   je  cilj  kreiranje   jezika  specifičnih  za domen   i  generatora   programskog  koda  upotrebom  openArchitectureWare  okvira   za   razvoj. Jezik   je   baziran  na   tekstualnoj   sintaksi   definisanoj   upotrebom   xText   komponente   i   dizajn obrascima definisanim u [Evans04] kao što su Servis, Modul, Entitet,  Repozitorijum itd. Za Sculptor  su razvijeni generatori za sledeće platforme:  Spring Framework,  Spring Web Flow, Hibernate, Java EE.

Mane Sculptor­a su sledeće:

• Nemogućnost proširenja jezika na nivou modela. Jezik ima fiksan skup osobina.• Jezik nema mogućnost definisanja naziva koncepata na prirodnom jeziku. Ova osobina 

je   poželjna   u   cilju   automatizovanog   generisanja   razumljivog   i   konzistentnog korisničkog interfejsa.

• Jezik je razvijen imajući u vidu Javu kao ciljnu platformu što otežava generisanje koda za  druge  ciljne  platforme.  Takođe,  vezivanje  za   java  programski   jezik   je  uslovilo   i donekle komplikovanu konkretnu sintaksu jezika.

• Jezik   nema   eksplicitnu   podršku   za   velike   entitete   i   servise   koji   broje   više desetina/stotina atributa i operacija.

60

Uvodna razmatranja

1.4. Osnovne postavke

Na osnovu analize literature u kojoj su opisani istorijski rezultati, savremeni trendovi kao i problemi i izazovi u domenu automatizacije procesa izrade softvera možemo primetiti da su pristupi koji su težili ka opštosti dali rezultate ispod očekivanih. Ova konstatacija je posebno izražena kod CASE alata gde je pokušaj kreiranja alata koji će biti u stanju da reši sve probleme u  izradi  softvera bio  jedan od osnovnih razloga njihovog neuspeha.  Pored  toga,  na osnovu obrađene literature zaključujemo da MDE pristupi u razvoju softvera postaju sve dominantniji. Pokazano  je  da  osnovne  ideje  korišćene u  izradi   jezika  specifičnih  za  domen  predstavljaju apstrakciju MDE pristupa, odnosno da je MDE samo jedan od mogućih pristupa u izradi jezika specifičnih za domen.

Domen izrade ove teze su poslovne aplikacije. S obzirom na postojeće trendove u razvoju tehnika   i   alata   za   automatizaciju   izrade   softvera   i   uočene   nedostatke   postojećih   rešenja postavljamo sledeću hipotezu:

• Moguće   je   specificirati   jednostavan,   proširljiv   jezik   za   opis   statičkih   osobina poslovnih sistema,

• Na   osnovu   definisanog   jezika   moguće   je   generisanje   značajnog   dela implementacije poslovne aplikacije za različite softverske platforme,

• Za dati   jezik  je  moguće definisati   tekstualnu  konkretnu sintaksu koja se  može koristiti za kreiranje i ažuriranje modela kao i njegovu perzistenciju,

• Za datu  konkretnu   tekstualnu  sintaksu  moguće   je  napraviti  prototip   editora   sa podskupom osobina standardnih editora.

61

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2. Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

DOMMLite  jezik predstavlja jezik za modelovanje (meta­model)  razvijen kao predmet izrade ove teze. Naziv je skraćenica od Domain Objects Meta­Model dok je sufiks Lite dobio jer je jedan od osnovnih zahteva pri konstrukciji jezika bila njegova jednostavnost.

Pored   samog   meta­modela   razvijena   je   konkretna   tekstualna   sintaksa   putem   koje   je moguće   definisati   konkretne   instance   meta­modela   tj.   modele.   Kao   podrška   modelovanju razvijen je editor sa osobinama kao što su dopuna koda, bojenje sintakse, provera ispravnosti modela u toku modelovanja, strukturni pogled tipa stabla itd.

Osnovni principi kojima smo se rukovodili u izradi DOMMLite jezika i pratećih alata su sledeći:

• Jednostavnost jezika – jezik za modelovanje treba da je jednostavan i koncizan u cilju lakšeg  učenja   i   jednostavnije   automatske  obrade.  Sintaksa   jezika   treba  da   je  bliska navikama programera.

• Izbegavanje redundantnosti u modelovanju  – ovaj princip je poznat kao  DRY  (Don't  Repeat Yourself) i predstavlja ideju da je informaciju potrebno navesti u modelu samo ukoliko ona ne može da se dedukuje na osnovu ostalih informacija.

• Skalabilnost   razvoja  –   razvoj   upotrebom  DOMMLite  treba   da   bude   skalabilan   i primenjiv u kontekstu povećanja broja članova razvojnog tima i/ili veličine modela. 

• Jednostavni alati – alati za modelovanje treba da budu što jednostavniji za upotrebu u cilju veće agilnosti u razvoju.

• Korišćenje standardnih, slobodno dostupnih alata i platformi  – alati  i  platforme za razvoj na kojima se bazira DOMMLite  treba da su u širokoj upotrebi i da su slobodno dostupni u cilju postizanja dužeg životnog veka DOMMLite jezika i alata.

• Automatizovana izrada korisničkih interfejsa – jezik treba da omogući navođenje svih potrebnih   informacija   koji   će   omogućiti   generisanje   razumljivih   i   konzistentnih korisničkih interfejsa.

• Proširljivost – jezik treba da omogući jednostavan mehanizam proširenja.

62

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.1. Osnovne komponente DOMMLite alata

DOMMLite se sastoji od sledećih komponenti:

• metamodel

Metamodel   opisan   u   sekciji  2.3    i   moguće   ga   je   implementirati   na   različitim platformama koji omogućavaju metamodelovanje korišćenjem objektnih kocepata. Tekuća implementacija  DOMMLite  alata koristi Eclipse  EMF ECore  platformu za (meta)modelovanje.

• editori modela

Editori modela omogućavaju kreiranje i ažuriranje modela. Za potrebe ovog rada je napravljen tekstualni editor modela, čija je implementacija opisana u odeljku 3.2, sa gramatikom jezika koji je definisan u odeljku 2.4 Pored tekstualnog editora model je moguće ažurirati  i  generisanim editorom tipa stabla  za koji  podršku pruža EMF. Moguće je kreirati i grafički editor modela za šta su nam na raspolaganju biblioteke za razvoj grafičkih editora ([GEF])ili okviri za razvoj editora ([GMF]).

• generatori programskog koda za ciljnu platformu

Iz modela sistema, koji predstavlja PIM, moguće je definisati  programski kod za razne platforme (Java/J2EE, .Net/COM, CORBA, Web servisi, Struts, Django itd.). Za potrebe ovog rada realizovan je generator koda za Django platformu za razvoj veb aplikacija. Generator je opisan u sekciji 3.3.

2.2. Korišćeni dizajn obrasci

2.2.1. MVC – MTV

Model­View­Controller  (MVC)  dizajn  obrazac   je   inicijalno  korišćen u  Smalltalk  GUI bibliotekama a detaljno je formulisan i opisan u [Gamma94]. Osnovna ideja ovoga obrazca je separacija podataka od načina na koji se podaci prikazuju i načina na koji se stupa sa njima u interakciju.

63

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Slika 2.1 ­ MVC dizajn obrazac

Većina   okvira   za   razvoj  veb   aplikacija  danas  koristi   neki  oblik  ovog  dizajn  obrasca [Ford04].   MVC nije   karakterističan   samo  za   razvoj   veb   aplikacija   već   se   često   sreće   i   u bibliotekama za razvoj desktop aplikacija. Primer za ovo je Swing biblioteka za razvoj grafičkih korisničkih   interfejsa   desktop   aplikacija   u   Javi   [Swing].   Kod   Swing­a   svaka   vizuelna komponenta ima razdvojene podatke (model) od prezentacije (view). To je najuočljivije kod složenijih komponenti kao što su  JTable  i  JTree  gde je potrebno da programer sam definiše klasu koja predstavlja model komponente.

Kada je razvoj Java veb aplikacija u pitanju postoje dve varijante primene MVC dizajn obrasca.   Stariji   način,   poznat   pod   nazivom  Model   1,  podrazumevao   je   da   su   za  View  i Controller deo  JSP stranice dok je model bio opisan JavaBean­ovima ili Enterprise JavaBean­ovima. JSP strana je bila zadužena za poslovnu logiku što je imalo za posledicu proliferaciju velikog broja skripleta (java koda u okviru HTML strane) i teškoće u održavanju. Kasnijom razradom je nastala tzv. Model 2 varijanta koja razdvaja Controller deo od View dela [Ford04]. Ova varijanta stiče veliku popularnost u okviru  Apache Struts  okvira za razvoj veb aplikacija [Struts]. Kod Struts­a kontroler deo je opisan akcionim servletom i poslovna logika kao i tok strana je smešten u ovim servletima. Model je, kao i kod  Model 1  varijante smešten u  Bean objektima, dok je JSP strana zadužena isključivo za prikaz tj. generisanje HTML dokumeta.

Postoje   razne   varijacije   MVC   dizajn   obrasca   koje   su   najčešće   organizovane   oko određenih  okvira  za   razvoj  aplikacija.  Na primer,  Django okvir  za   razvoj  veb  aplikacija  u programskom  jeziku  Python  koristi   varijantu  koja   se  naziva  Model­Template­View (MTV) [Holovaty07]. Kod MTV­a model je opisan Python objektom,  View  je funkcija zadužena za dopremanje podataka koji  trebaju da se prikažu, dok je način prikaza opisan tzv.  šablonom (template).

64

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.2.2. Entity – entiteti

Prema   [Evans04],   entiteti   predstavljaju   kategoriju   objekata   sa   identitetom   koji   se   ne menja   za   celokupno   vreme   života   objekta.   Softverski   objekti   u   memoriji   imaju   reference (najčešće  memorijske  adrese)  koje   ih   jednoznačno   identifikuju.  S  obzirom da  objekti  često menjaju lokaciju u memoriji, prelaze sa računara na računar putem serijalizacije itd. nemamo garanciju da će referenca ostati nepromenjena za vreme života objekta. Prema tome, nisu svi softverski objekti entiteti.

Entiteti   su   objekti   koji   žive   duže   od   vremena   pojedinačnog   izvršavanja   softverske aplikacije. Kažemo da entiteti imaju osobinu perzistencije. Najčešće je perzistencija realizovana upisom u bazu podataka.

Identitet  entiteta  predstavlja  njegov  jedinstveni   identifikator  u  okviru  sistema.  Za dva entiteta  se kaže da su jednaka ukoliko su im jednaki jedinstveni identifikatori.  Ukoliko dva entiteta   imaju   različite   identifikatore   oni   nisu   jednaki   bez   obzira   da   li   su   atributi   entiteta jednaki.

2.2.3. ValueObject – vrednosni objekti

Za razliku od entiteta, vrednosni objekti nemaju jedinstvene identifikatore i predstavljeni su samo vrednošću svojih atributa [Evans04]. Koriste se u situacijama kada nije potrebno da objekat ima sposobnost perzistencije već je privremenog karaktera. Najčešće se implementiraju kao nepromenjivi objekti koji se inicijalizuju prilikom svoje konstrukcije i u tom slučaju se mogu bezbedno deliti tj. reference se mogu više puta iskoristiti.

Vrednosni   objekti   se   u   informacionim   sistemima   većih   razmera   koriste   za   transfer podataka   o   entitetima   prema   klijentu.   Ukoliko   bi   vršili   transfer   celih   entiteta   to   bi   imalo negativne implikacije, kako sa stanovišta performansi tako i sa stanovišta bezbednosti jer bi do klijenta dolazile i informacije koje nije zahtevao kao i informacije kojima ne bi smeo da ima pristup. Imajući  ovo u vidu, sadašnja praksa, kada je razvoj  Enterprise  aplikacija u pitanju, nalaže definisanje određenog broja vrednosnih objekata koji imaju za cilj da opišu određeni entitet u različitim kontekstima.

65

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.2.4. Service – servisi

U sistemu koji se analizira često se pojavljuju određene osobine ponašanja koje logički ne pripadaju  niti   jednom entitetu  [Evans04].  Dodavanje  ovakvih osobina proizvoljnom entitetu narušava osnovne principe objektno orijentisanog dizajna. Pa ipak se ovakve osobine moraju realizovati kao metode određenog objekta/klase. Pristup koji se pokazao kao najbolji u praksi jeste kreiranje posebnih objekata koji implementiraju ovakve metode i koji nemaju stanje već im   je   namena  da  grupišu   logički  povezanu   funkcionalnost  koja   se   ne  može  pridružiti   niti jednom entitetu ili vrednosnom objektu. Ovakvi objekti nazivaju se servisi. Objekti koji koriste usluge servisa (klijenti)  sa njima stupaju u interakciju na različite načine.  Ukoliko se servis nalazi u istom adresnom prostoru sa klijentom moguće je pozvati metode servisa mehanizmima samog programskog jezika (poziv metode objekta). Ukoliko se klijent i servis ne nalaze u istom adresnom  prostoru   koriste   se  mehanizmi   međuprocesne  komunikacije   ili   srednjeg   sloja   za distribuirane objekte (middleware) kao što su npr. RMI, EJB, Web servisi i dr.

2.3. DOMMLite meta-model

Struktura DOMMLite jezika opisana je meta­modelom na apstraktan način nezavistan od konkretne reprezentacije. U ovom odeljku dat je pregled elemenata DOMMLite metamodela.

2.3.1. DOMMLite model (metaklasa DOMMLiteModel)

Predstavlja   korenski   kontejnerki   objekat   modela.   Svaki   DOMMLite   model   je   opisan ovom klasom koja, neposredno ili posredno, sadrži sve ostale elemente modela.

66

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Slika 2.2 ­ DOMMLite model

DOMMLiteModel se nasleđuje iz metaklase NamedElement što znači da svaki model ima ime, kratak i dugi opis (videti 2.3.3). Model sadrži kolekciju paketa, korisnički definisanih tipova i definiciju tipova ograničenja.

2.3.2. Prosti i primitivni tipovi (metaklasa DataType)

U purističkim objektno orijentisanim programskim jezicima koncept primitivnog tipa ne postoji.   Sve   je   objekat   i   ne   postoji   razlika   u   tretiranju   pojedinih   klasa   od   strane kompajlera/interpretera.   Mada   je   ovakav   pristup,   sa   teoretske   tačke   gledišta,   logičniji   i konzistentniji, u praksi se, u cilju postizanja boljih performansi definišu primitivni tipovi koji imaju   poseban   tretman   od   strane   kompajlera/interpretera.  DOMMLite  primitivne   tipove   i enumeracije  naziva  prostim  tipovima  (videti  2.3.4).  Primitivni   tipovi   su  instance  metaklasa UserDataType  i  BuildInDataType.  Instanca  BuildInDataType  metaklase predstavlja  ugrađeni primitivni tip koji je dostupan u svakom DOMMLite modelu. UserDataType je metaklasa koja opisuje   korisnički   definisane   primitivne   tipove   i   predstavlja  mehanizam   proširenja   sistema tipova.   Korisnički   definisan   primitivni   tip   se   može   ravnopravno   koristiti   u   modelima   sa ugrađenim primitivnim tipovima.

67

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

DOMMLite,  u   tekućoj  verziji,  definiše  9 ugrađenih  primitivnih   tipova u vidu  instanci metaklase BuildInDataType i to:

• void – predstavlja pseudotip koji opisuje odsustvo vrednosti. Npr. operacija koja vraća tip void zapravo nema povratnu vrednost. 

• bool – logički tip koji može imati dve vrednosti: true i false.• int ­  tip koji opisuje cele brojeve• real – tip koji opisuje realne brojeve• money – tip koji opisuje novčane iznose• string – tip koji opisuje niz karaktera• char – tip koji opisuje karakter• date – tip koji opisuje datum• datetime – tip koji opisuje datum i vreme

Slika 2.3 ­ Prosti tipovi

Implementacioni detalji kao što su opseg celih brojeva tipa int, preciznost realnih brojeva itd. nisu definisani DOMMLite jezikom i metamodelom već su zavisni od ciljne platforme za koju se kod generiše i  mapiranje na odgovarajuće tipove predstavlja  odluku koja se donosi prilikom kreiranja generatora koda bez uticaja na model sistema.

2.3.3. Imenovani element (metaklasa NamedElement)

Svi elementi koji imaju ime se, direktno ili indirektno, nasleđuju iz apstraktne metaklase NamedElement. Pored imena ovaj element opisuje i druge karaketeristične osobine kao što su:

68

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

• shortDesc  –   kratak   opis   elementa   modela.  Najčešće   se   u   implementaciji   koristi   da definiše natpis na labelama interfejsa.

• longDesc – dugi opis elementa modela. Može se koristiti u generisanju kontekstnog help sistema ili sistema nagoveštaja (tooltips)

Slika 2.4 ­ NamedElement metaklasa

2.3.4. Enumeracije (metaklase Enumeration, EnumerationLiteral)

Prilikom  modelovanja   imamo  čestu   potrebu  definisanja   tipa   koji   opisuje   vrednost   iz unapred poznatog i nepromenjivog skupa diskretnih vrednosti – tzv. nabrojivi tip.  DOMMLite ima  ugrađenu podršku za  nabrojivi   tip  u  vidu  metaklase  Enumeration  i  njemu pridruženih literala u vidu metaklase EnumerationLiteral. 

Slika 2.5 ­ Enumerisani tipovi

Svaka enumeracija ima jedan ili više literala koji imaju svoje ime, kratak i dug opis i definišu   vrednost   literala   što   može   biti   iskorišćeno   za   reprezenataciju   literala   u   bazama podataka.

69

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.3.5. Paketi (metaklase Package, PackageElement)

Osnovni  mehanizam organizacije  DOMMLite  modela   jeste  upotreba  paketa.  Paketi  su koncept koji je često zastupljen u programskim jezicima kao i jezicima za modelovanje. Na slici  2.6  je prikazan deo metamodela koji  opisuje paketnu organizaciju  DOMMLite  modela. Svaki  DOMMLite  model se sastoji  od niza paketa, pri čemu svaki paket ima niz elemenata paketa  (opisanih apstraktnom metaklasom  PackageElement).  S obzirom da  PackageElement nasleđuje metaklasu  NamedElement  a  Package nasleđuje metaklasu  PackageElement  to znači da paketi i elementi paketa imaju ime, kratak i dug opis.

Slika 2.6 ­ Paketna organizacija modela

PackageElement  metaklasa  predstavlja  ujedno prostor  imena što  znači  da će elementi modela unutar istog paketa imati jedinstveno ime. Isto pravilo važi za sve elemente metamodela koji nasleđuju PackageElement metaklasu.

2.3.6. Tipizirani elementi (metaklasa TypedElement)

Elementi modela koji imaju tip (npr. atributi entiteta, parametri operacija itd.) se, direktno ili indirektno, nasleđuju iz metaklase  TypedElement. Ova metaklasa se nasleđuje iz metaklase NamedElement što znači da svi elementi koji imaju tip ujedno moraju imati i ime, kratak i dug opis. Osim atributa, metaklasa TypedElement definiše i sledeće atribute:

• required  –   određuje   da   li   je   ovaj   element   obavezan,   tj.   da   li  može   imati   vrednost ekvivalentnu null vrednosti u Java programskom jeziku,

• many – određuje da li element predstavlja kolekciju ili pojedinačnu instancu.

70

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

• unique  ­     da   li   elementi  kolekcije  moraju  biti   jedinstveni.  Ukoliko   je  many  atribut podešen na laž (false) tada se ovaj atribut ne koristi, 

• ordered  – da li je redosled elemenata u kolekciji relevantan. Ukoliko je  many  atribut podešen na laž (false) tada se ovaj atribut ne koristi. Ukoliko je ovaj atribut podešen na istina   (true)   tada   je   to   indikacija  da  korišćeni   tip  na  ciljnoj  platformi   ima   indeksni pristup elementima.

• multiplicity   –  u   slučaju   da   je   meta­atribut  many  postavljen   na  true  određuje   broj elemenata kolekcije.

• type – je asocijacija prema klasifikatoru čija instanca je vrednost datog elementa ili, u slučaju kolekcije, čije instance čine vrednosti date kolekcije.

Slika 2.7 ­ TypedElement metaklasa

Svi tipizirani elementi su kontejner za kolekciju specifikacija ograničenja tako da se nad svim podklasama (atributi/reference, operacije i parametri operacija) mogu definisati oznake i validatori (videti 2.3.18) .

2.3.6.1. Kardinalitet tipiziranih elemenata

Predstavlja mogući broj elemenata tj. da li elemenat predstavlja kolekciju ili pojedinačni elemenat i da li je elemenat obavezan ukoliko je pojedinačan. Ovim se vidi da je semantika kardinaliteta DOMMLie jezika različita od jezika UML.

71

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Određen   je   meta­atributima  required,  many  i  multiplicity.   Kardinalitet   tipiziranog elementa može biti 0..1, 1,  n ili * gde je:

• 0..1 – najviše jedan. Ovo se postiže postavljanjem meta­atributa required i many na vrednost false.

• 1 – tačno jedan. Postiže se postavljanjem meta­atributa required na vrednost true a many na vrednost false.

• n  –  broj  koji   je  veći  od  jedan  i  predstavlja  broj  elemenata  kolekcije.  Postiže  se postavljanjem elementa many na true a multiplicity na n.

• *  ­ neodređeni broj koji predstavlja činjenicu da kolekcija može imati proizvoljan broj elemenata. Postiže se postavljanjem many na true i multiplicity na 0.

Tekuća verzija DOMMLite jezika ne može da iskaže kardinalitete tipa [n,m] koji definišu interval mogućeg broja elemenata kolekcije. Kardinaliteti se koriste kod definisanja referenci da bi se odredio tip veze (videti 2.3.9.1)

2.3.7. Klasifiktori (Classifier)

Classifier  predstavlja osnovnu apstraktnu metaklasu iz koje se nasleđuju sve metaklase koje opisuju tipove bilo da su u pitanju prosti ili složeni tipovi. Svi klasifikatori imaju ime, kratak i dug opis s obzirom da se nasleđuju iz metaklase NamedElement. Takođe, s obzirom da se nasleđuju i iz metaklase  PackageElement  to znači  da svi klasifikatori mogu biti elementi paketa (videti 2.3.5).

Slika 2.8 ­ Klasifikatori

72

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.3.8. Osobine (Feature)

Metaklasa  Feature  predstavlja   apstraktnu   klasu   koja   opisuje   elemente   modela   koji deklarišu osobine klasifikatora bilo da su u pitanju strukturne osobine (atributi ili reference) ili osobine ponašanja (operacije). Direktno se nasleđuje iz metaklase TypedElement što znači da za ovu meta­klasu važi sve što je navedeno za meta­klasu TypedElement (videti 2.3.6).

Slika 2.9 ­ Metaklasa Features

2.3.9. Strukturne osobine (Property)

Metaklasa  Property  opisuje  strukturne osobine klasifikatora.  Strukturne osobine mogu biti   atributi   i   reference.   Reference   predstavljaju   vezu   sa   drugim   elementima   modela   čija metaklasa je Property. S obzirom da Property indirektno nasleđuje metaklasu TypedElement to znači   da   strukturna  osobina   ima   tip.  Ukoliko   je   tip   strukturne  osobine  prost   tada   instanca Property  metaklase definiše atribut. Ukoliko tip strukturne osobine nije prost tada strukturna osobina predstavlja referencu i u tom slučaju validan je atribut  containment  kao i referenca oppositeEnd.  Containment  atribut određuje da li referenca ima semantiku sadržavanja (videti 2.3.9.1). Referenca oppositeEnd referencira instancu Property metaklase koja predstavlja drugu stranu reference. Ukoliko meta­atribut oppositeEnd ima vrednost tada je referenca bidirekciona.

73

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Slika 2.10 ­ Strukturne osobine

Strukturna osobina može imati pridružene instance metaklase ConstraintSpec (nasleđeno iz  TypedElement  metaklase)   što   znači   da   se   svakom   atributu   ili   referenci   može   pridružiti validator   koji   mora   biti   zadovoljen   ili   oznaka   koja   definiše   dodatne   informacije   o atributu/referenci (videti 2.3.18).

2.3.9.1. Vrste referenci

U zavisnosti od kardinaliteta referenca može biti:

• jedan na jedan

Ova vrsta veze je moguća ukoliko su oba kraja navigabilna i imaju kardinalitet 0..1 ili 1. Kardinalitet 1 implicira da je  required atribut  Property meta­klase postavljen na   vrednost  true.  Ovo   je   moguće   samo   za   jedan   kraj   reference.   Ukoliko   bi kardinalitet oba kraja bio postavljen na 1 ne bi bilo moguće kreiranje objekata.

• jedan na više

Ovo je najopštiji tip veze. Definiše se tako što jedan kraj veze ima kardinalitet 1 ili 0..1 a drugi, ukoliko je definisan, ima kardinalitet *.

• više na više

Ovaj tip veze se ostvaruje postavljanjem kardinaliteta na * (many  atribut  Property meta­klase se postavlja na vrednost true) na definisanom kraju ili oba kraja ukoliko je veza bidirekciona.

Referenca   može   biti   unidirekciona   ili   bidirekciona   što   je   određeno   vrednošću oppositeEnd  atributa   metaklase  Property.   Za   razliku   od   UML­a   u  DOMMLite  jeziku besmisleno   je   govoriti   o   kardinalitetu   oba   kraja   veze   kod   unidirekcionih   referenci.   Kod 

74

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

unidirekcionih veza kardinalitet  je određen samo na onom kraju koji je definisan dok se za kardinalitet kraja koji nije definisan implicitno podrazumeva 1 ukoliko je u pitanju kompozitna veza ili * ukoliko veza nije kompozitna.

Referenca može biti referenca sadržavanja (kompozitna veza ili veza celina­deo) što znači da je  containment  meta­atribut postavljen na vrednost  true. Veza sadržavanja ima semantiku sličnu vezi kompozicije kod jezika UML ali postoje izvesne razlike u mogućim kardinalitetima krajeva veze i učešću elementa koji čini deo u više kompozitnih veza.

Semantika kompozitne veze u DOMMLite jeziku je sledeća:

• Element koji predstavlja deo u kompozitnoj vezi ne može istovremeno biti deo u nekoj drugoj kompozitnoj vezi.

• Kardinalitet nekompozitnog kraja kompozitne veze je implicitno 1 za unidirekcione veze   odnosno   mora   biti   postavljen   na   1   (meta­atribut  required  postavljen   na vrednost true i meta­atribut many postavljen na vrednost false) za bidirekcione veze.

• Kardinalitet kompozitnog kraja kompozitne veze može imati proizvoljnu vrednost.• Životni ciklus elementa koji sadržava se propagira na sadržane elemente. Ukoliko se 

element koji sadržava obriše, brišu se i svi njegovi sadržani elementi. Ukoliko se element koji sadržava kopira, kopiraju se i svi sadržani elementi.

Veza kompozicije omogućava definisanje globalnog i lokalnog poslovnog (semantičkog) ključa (videti 2.3.14.2)

2.3.10. Operacije (Operation)

Operacije predstavljaju elemente metamodela koji deklarišu osobine ponašanja. Operacija ima uređenu listu parametara potrebnih za njeno izvršavanje (videti  2.3.11). Takođe operacija može da ima kolekciju  izuzetaka koja opisuju tipove izuzetaka koje ova operacija  može da generiše u toku svog izvršavanja (videti 2.3.17). Semantika izuzetaka koje operacija deklariše je analogna   semantici   tzv.  checked  izuzetaka   u   programskom   jeziku   Java.   Ukoliko   ciljna platforma nema koncept checked izuzetaka tada se informacija iz modela može ignorisati ili se može   iskoristiti   za   generisanje   šablonskih   delova   programskog   koda   operacija   i   metoda pozivaoca.   Način   korišćenja   informacija   o   izuzecima   operacije   je   dizajn   odluka   prilikom izgradnje generatora programskog koda ciljne platforme.

75

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Slika 2.11 ­ Operacije

2.3.11. Parametri (Parameter)

Metaklasa  Parameter  opisuje   parametre   operacija.   Direktno   nasleđuje   metaklasu TypedElement  pa   samim  tim parametar   ima   tip  koji  može  biti  primitivan   ili  ne,  može  biti kolekcija ili pojedinačni element. Ukoliko je kolekcija, može biti uređena i elementi mogu imati osobinu   jedinstvenosti   u   okviru   kolekcije.   Parametar   operacije   ima   semantiku   analognu parametrima kod klasičnih programskih jezika.  Semantika prenosa po vrednosti  odnosno po referenci   je  definisana  kao  kod programskog  jezika  Java.  Ukoliko   je  u  pitanju  prost   tip  sa multiplicitetom   1,   prenos   se   vrši   po   vrednosti.   Ukoliko   nije   prost   tip   ili   je   prost   tip   sa multiplicitetom većim od 1 tada se koristi semantika prenosa po referenci.

Slika 2.12 ­ Parametri

2.3.12. Odeljci osobina (FeatureCompartment)

Metaklasa  FeatureCompartment  je   namenjena   za   definisanje   tzv.   odeljaka   osobina. 

76

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Predstavlja kontejner osobina bilo da su u pitanju osobine ponašanja (operacije) ili strukturne osobine   (atributi   i   reference).  Ova metaklasa  predstavlja  osnovu za  podelu  osobina   jednog entiteta u logičke celine. Predstavlja podršku za izgradnju korisničkih interfejsa (kartice ­ Tabs) kao   i   jednostavniju   navigaciju   unutar   modela   kod   eniteta   sa   velikim   brojem   osobina. FeatureCompartment  se direktno nasleđuje iz apstraktne metaklase  NamedElement, što znači da što znači da ima ime, kratak i dug opis.

Slika 2.13 ­ Odeljci osobina

2.3.13. Odeljci operacija (OperationCompartment)

Metaklasa  OperationCompartment  definiše  odeljak koji  može  da sadrži   samo osobine ponašanja tj. operacije. Ovaj odeljak predstavlja osnovu za podelu osobina ponašanja na logičke grupe kod servisa koji imaju veliki broj operacija. Kao i kod metaklase FeatureCompartment, prednosti ovakve podele su jednostavnija navigacija  u modelu kao i  jednostavnija  izgradnja intuitivnog korisničkog interfejsa.

Slika 2.14 ­ Odeljci operacija

77

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.3.14. Entiteti (Entity)

Entiteti   predstavljaju   osnovnu  metaklasu   za   izgradnju  domenskog  modela.  Metaklasa Entity  se   nasleđuje   direktno   iz   metaklase  Classifier.   Entitet   poseduje   kolekciju   osobina (instance  metaklase  Features).  Osobine   se  mogu grupisati  unutar  odeljaka  putem kolekcije featureCompartments. Entitet može imati jedan semantički (poslovni) ključ opisan metaklasom BussinessKey koja sadrži jedan ili više atributa. Strukturne osobine ključa mogu biti atributi ali ne i reference prema drugim atributima.  repr kolekcija definiše izraz kojim se gradi tekstualna reprezentacija entiteta. Elementi tekstualne reprezentacije mogu biti string literali (metaklasa ReprParameterStr)   ili   reference   prema   atributima   entiteta   koji   imaju   string   reprezentaciju (metaklasa  ReprParameterRef). Pun tekstualni opis se gradi konkatanacijom svih parametara reprezentacije.   Koristi   se   kod   izgradnje   korisničkih   interfejsa   u   cilju   koncizne   predstave instance   entiteta.   DOMMLite   podržava   jednostruko   nasleđivanje   entiteta   putem   reference extends.  Semantika nasleđivanja entiteta nije u tekućoj verziji  definisana jezikom i može se proizvoljno koristiti prilikom izgradnje generatora za ciljnu platformu.

Slika 2.15 ­ Entiteti

78

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.3.14.1. Jedinstveni identifikatori

Jedinstveni identifikatori entiteta omogućavaju njihovu jednoznačnu identifikaciju unutar sistema.  Dva različita  entiteta  moraju imati  različite   identifikatore.  Kod izbora jedinstvenog identifikatora postoje dva osnovna pristupa:

• semantički identifikatori

Podrazumevaju   izbor   jednog   ili   više   atributa   entiteta   koji   na   jednoznačan   način identifikuju entitet u sistemu.

• nesemantički (surogat) identifikatori

Uvodi se dodatni atribut koji nema semantiku unutar domena i čija je namena isključivo definisanje jednoznačne identifikacije. Ovaj atribut je čisto tehničke prirode i često se ne navodi prilikom modelovanja domena.

Zbog problema koji mogu nastati usled potrebe da se vrednost jedinstvenog identifikatora entiteta promeni, kao i problema koji nastaju prilikom refaktorizacije šeme baza podataka često se  u   literaturi   sreće  preporuka  da   se,  kad  god   je   to  moguće,   koriste   surogat   identifikatori [Bauer05]. Sa druge strane, korišćenje semantičkih identifikatora nudi mogućnost generisanja interfejsa   za   CRUD   operacije   koji   su   jednostavni   za   upotrebu   od   strane   korisnika   jer   se povezivanje   objekata   u   sistemu   ostvaruje   domenskim   vrednostima   sa   kojima   korisnik svakodnevno radi (npr. JMBG, šifra predmeta,  konto itd.). Generatori koji koriste kompozitne semantičke   identifikatore   za   generisanje   CRUD   formi   su   opisani   u   [MilosavljevićG04, MilosavljevićB03].

DOMMLite koristi hibridni pristup. Na tehničkom nivou se koriste surogat identifikatori čime   se  omogućava   jednostavnije   refaktorizovanje  šeme baze  podataka  kao   i   jednostavniji inkrementalni i iterativni razvoj. Pored surogat identifikatora koji se automatski generišu i nisu prisutni u modelu, definišu se i složeni semantički identifikatori u samom DOMMLite modelu (instance   metaklase  BussinesKey)   koji   se   koriste   prilikom   generisanja   formi   aplikacije (povezivanje objekata, pretraga itd.) (videti 2.3.14.2). Korišćenje surogat identifikatora je dizajn odluka prilikom kreiranja genaratora za ciljnu platformu i predstavlja samo preporuku tj. nije nametnuto samim dizajnom DOMMLite jezika.

79

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.3.14.2. Globalni i lokalni semantički identifikatori

DOMMLite  definiše dve vrste identifikatora entiteta sa stanovišta konteksta u kome je identifikator   jedinstven.   Instanca   metaklase  BussinesKey  unutar   entiteta   opisuje   lokalni semantički identifikator ili lokalni poslovni ključ.

Definicija:

Lokalni   semantički   identifikator   (lokalni   poslovni   ključ)  je   identifikator   entiteta jedinstven unutar kolekcije koju sačinjavaju entiteti koji predstavljaju deo u kompozitnoj vezi i povezani su za isti entitet koji predstavlja celinu. Ukoliko entitet ne učestvuje u kompozitnoj vezi kao deo tada njegov lokalni semantički ključ predstavlja ujedno i globalni i jedinstven je u poslovnom informacionom sistemu.

Definicija:

Globalni semantički identifikator (globalni poslovni ključ) je identifikator entiteta koji je jedinstven  na  nivou celokupnog poslovnog sistema.  Čini  ga   lokalni   semantički   identfikator entiteta zajedno sa globalnim semantičkim identifikatorom entiteta  koji  sadržava posmatrani entitet tj. predstavlja celinu u kompozitnoj vezi u kojoj posmatrani entitet čini deo.

2.3.14.3. Zavisnost sa servisima

Da bi objekat stupio u interakciju sa servisom potrebno je da postoji postupak putem koga možemo   doći   do   reference   na   dati   servis.   Najčešće   je   u   upotrebi  singleton  obrazac   ili direktorijumi (kao što je npr. JNDI). Mana ovakvog pristupa je u tome što objekat koji koristi usluge   servisa   mora   aktivno   učestvovati   u   dobijanju   reference   na   servis   što   ga   čini   jako spregnutim sa korišćenim mehanizmom. Poslednjih godina sve češće je u upotrebi pristup kod koga   objekat   koji   koristi   usluge   servisa   dobija   reference   direktnim   inicijalizacijama odgovarajućih   atributa  od  strane  kontejnerskog  okruženja  u  kome živi.  Ovakav  način   rada naziva se inverzija kontrole (Inversion of Control – IoC) ili  umetanje zavisnosti (Dependency  Injection  –  DI)   [Walls05].  Kao  podrška   za  ovaj  mehanizam  DOMMLite  jezik  omogućava definisanje zavisnosti između entiteta i servisa. Ovu informaciju dalje koristi generator koda da bi generisao potrebnu infrastrukturu za implementaciju DI mehanizma.

80

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Podrška   za   DI   mehanizam   kod   entiteta   je   obezbeđena   referencom  depends  prema servisima. Na ovaj način svaki entitet može definisati više servisa od kojih zavisi a dalje će se generator  pobrinuti  da   referenca  na  dati   servis  bude dostupna  u  vreme kodiranja  poslovne logike entiteta.

2.3.15. Vrednosni objekti (ValueObject)

Slika 2.16 ­ Vrednosni objekti

Vrednosni (ili transfer) objekti se najčešće koriste u enkapsulaciji podataka iz entiteta i njihovom   prenosu   među   slojevima   aplikacije   (videti  2.2.3).   U  DOMMLite  metamodelu vrednosni   objekti   su   definisani   metaklasom  ValueObject  koja   sadrži   kolekciju   instanci strukturnih  osobina   i   specifikacija  ograničenja   (videti  2.3.18).    Vrednosni  objekti   se  mogu nasleđivati   pri   čemu   je   podržano   jednostruko   nasleđivanje.   Nasleđivanje   je   podržano referencom extends metaklase ValueObject. Semantika nasleđivanja u tekućoj verziji jezika nije definisana i može se proizvoljno korstiti prilikom izrade generatora programskog koda za ciljnu platformu.

2.3.15.1. Strukturne osobine vrednosnih objekata

Kao  i  entitet   i  vrednosni  objekat  može   imati  atribute   i   reference  pri  čemu vrednosni objekat  može   referencirati   samo  drugi   vrednosni   objekat.  S  obzirom  da   je   jedina  namena vrednosnog objekta čuvanje i prenos vrednosti nije moguće implementirati poslovnu logiku pa nije moguće definisati operacije. Zbog ovoga nije potrebno da vrednosni objekat ima reference prema servisima. Osim ovih ograničenja sve što važi za atribute i reference entiteta važi i za atribute i reference vrednosnih objekata.

81

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.3.15.2. Definisanje veze zavisnosnti sa entitetima i podrazumevane strukturne osobine

Vrednosni  objekat  može da definiše vezu zavisnosti  prema entitetima što  je podržano referencom  depends  između metaklasa  ValueObject  i  Entity.  Semantika ove veze se  tumači drugačije od veze zavisnosti između entiteta i servisa. Ukoliko vrednosni objekat ne definiše niti jedan atribut ali definiše vezu zavisnosti prema entitetu tada se koristi sledeće pravilo.

Pravilo  2.1  ­  Pravilo o podrazumevanim strukturnim osobinama vrednosnih objekata –  Ukoliko vrednosni objekat ne definiše niti   jednu strukturnu osobinu ali  ima vezu zavisnosti prema jednom ili više entiteta tada će njegove strukturne osobine činiti svi atributi entiteta dok će reference prema drugim entitetima biti transformisane u odgovarajuće globalne semantičke identifikatore. Nizovi referenci se u tekućoj verziji jezika nisu podržani.

2.3.16. Servisi (Service)

Slika 2.17 ­ Servisi

Servis   opisuje   element   modela   čija   je   namena   logičko   grupisanje   poslovne   logike (operacija) koja ne može da se realizuje kao deo entiteta (videti  2.2.4). Servisi nemaju stanje tako da se najčešće implementiraju kao jedinične instance (singleton). U DOMMLite­u servis je opisan metaklasom Service koja se direktno nasleđuje iz apstraktne metaklase Classifer. Servis poseduje kolekciju operacija. Dodatno se operacije mogu grupisati u logičke celine upotrebom odeljaka operacija. Za svaki servis se može vezati više specifikacija ograničenja (videti 2.3.18). Servisi se mogu nasleđivati,  pri čemu je podržano jednostruko nasleđivanje putem reference extends.   Semantika   nasleđivanja   servisa   nije   određena   DOMMLite   jezikom   i   može   se   na proizvoljan   način   implementirati   u   okviru   generatora   programskog   koda   ciljne   platforme. 

82

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Podrška za umetanje zavisnosti (videti 2.3.14.3) je obezbeđena referencom depends. Nadležnost generatora je da obezbedi potreban infrastrukturni kod za implementaciju DI čime će potrebne reference  prema drugim servisima  biti   dostupne  u  vreme  kodiranja   i   izvršavanja   poslovne logike.

2.3.17. Izuzeci (Exception)

Izuzeci su opisani metaklasom Exception. Semantika izuzetaka je analogna izuzecima u drugim OO jezicima. Izuzetak predstavlja situaciju koja ne spada u normalan tok izvršavanja programa (npr. deljenje sa nulom, izvođenje operacije za koje program nema dovoljno visoke privilegije  itd.).  Neki programski jezici,  kao što je Java, definišu dve vrste izuzetaka – tzv. checked  i  unckecked.  Checked  izuzeci   se  navode  kao  signatura  operacije  koja  može  da   ih generiše i klijent je dužan da izvrši obradu takvog izuzetka. Unckecked izuzeci se ne navode u signaturi   operacije   i   klijent   nije   dužan  da   izvrši   obradu   jer   su  ovi   izuzeci   najčešće  uzrok programerske greške i nije moguće na smislen način izvršiti oporavak (npr. deljenje sa nulom, pristup   objektu   preko   neinicijalizovane   reference   itd.).   Semantika   izuzetaka   u  DOMMLite jeziku   je  analogna  checked  izuzecima  u Javi.  Navođenje   izuzetaka  koje  operacije  može  da generiše koristi generator koda za generisanje signatura metoda. Izuzeci mogu imati atribute putem kojih se mogu prosleđivati dodatne informacije o izuzetku koji se desio.

Slika 2.18 ­ Izuzeci

2.3.18. Ograničenja (Constraints)

DOMMLite jezik se može proširiti upotrebom ograničenja. Ograničenja definišu dodatne metainformacije koje se mogu dodeliti elementima modela putem kojih se osnovna sematnika instanci elemenata modela može izmeniti odnosno ograničiti.

83

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

U DOMMLite­u postoje dve vrste ograničenja:

• oznake (tags) – definišu dodatnu sematniku elementa modela.• validatori (validators) – sužavaju skup mogućih instanci elemenata modela tj. definišu 

uslove koji moraju biti zadovoljeni da bi se instanca modela smatrala ispravnom.

Ograničenja se definišu kao instance metaklase ConstraintSpec i mogu se pridružiti svim tipiziranim   elementima   (atribut,   operacija,   parametar),   enitetima,   servisima   i   vrednosnim objektima.   Definicija   ograničenja   referencira   tip   ograničenja,   predstavljen   kao   instanca metaklase  ConstraintType,   koja   se   specijalizira   u  TagType  i  ValidatorType.   Instanca ConstraintType metaklase definiše appliesTo*  (videti   sliku 2.19) atribute s kojim je moguće, prilikom    definisanja   tipa  ograničenja,  odrediti   nad  kojim  elementima  modela  može  da   se primeni.  Specifikacija  ograničenja  može   imati  parametre   (instance  specijalizacija  metaklase ConstraintParameter)  čiji   redosled   i   tip   je  određen  tipom ograničenja,  odnosno kolekcijom parameters  metaklase  ConstraintType.  Metaklasa  ConstraintType  se  nasleđuje   iz  metaklase Classifier  tako da se tip ograničenja može definisati u u okviru  DOMMLite modela ili nekog njegovog paketa. 

84

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Slika 2.19 ­ Ograničenja

Tip parametra ograničenja je definisan enumeracijom ConstraintTypeParameter i može biti:• string – parametar mora biti string literal• int – parametar mora biti celobrojni literal• ref – parametar mora biti referenca prema atributu unutar elementa modela kome je 

ograničenje pridruženo.• ellipsis – broj parametara je neodređen.

Redosled i tip parametara u specifikaciji ograničenja (ConstraintSpec metaklasa) mora se 

85

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

podudarati   sa   redosledom   i   tipom   parametara   navedenih   u   deklaraciji   tipa   ograničenja (ConstraintType metaklasa). 

Ukoliko se kao tip parametra navede ellipsis tada važe sledeća pravila:

• Ellipsis mora biti prvi ili drugi u listi parametara u opisu tipa ograničenja. • Iza ellipsis parametra ne može se nalaziti drugi parametar. • Ukoliko   je  ellipsis  jedini   parametar   tada   broj   i   tip   parametara   specifikacije 

ograničenja može biti proizvoljan. Ukoliko je ellipsis naveden kao drugi parametar tada je broj parametara specifikacije ograničenja >=1 i svi parametri moraju imati tip koji je određen prvim parametrom deklaracije tipa ograničenja.

2.3.18.1. Oznake (TagType)

Oznake omogućavaju definisanje dodatne semantike elementa modela. Oznake su opisane metaklasom  TagType  koja se specijalizuje u metaklase  BuildInTagType  i  UserTagType  koje opisuju  ugrađene oznake  i  korisničke oznake respektivno.   Instance  UserTagType  metaklase predstavljaju   korisnički   definisane   oznake   koje   imaju   ravnopravan   tretman   u   jeziku   kao   i ugrađene   oznake.   S   obzirom   da   se   metaklasa  TagType  direktno   nasleđuje   iz   metaklase ConstraintType moguće je definisati elemente modela nad kojima je moguće primeniti oznaku kao i  formalne parametre oznake.  DOMMLite  jezik u  tekućoj verziji  definiše 11 ugrađenih oznaka prikazanih u tabeli 2.1.

86

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Naziv Parametri Primenjuje se na

Opis

plural stringentiteti

vrednosni objekti

Definiše pluralni oblik za naziv elementa modela. Koristi se na korisničkim 

interfejsima.

searchBy ref, ... entitetiDefiniše atribute entiteta po kojima se vrši 

pretraga.

orderBy ... entiteti

Definiše podrazumevano sortiranje eniteta. Navodi se u parovima (ref, string) gde string može imati vrednosti “asc” za 

rastući ili “desc” za opadajući redosled.

listFields ref,... entitetiDefiniše podrazumevane atribute koji se 

prikazuju kod izlistavanja entiteta.

filterFields ref,... entiteti Definiše atribute po kojima se entiteti mogu filtrirati.

uniqueTogether ref,... entitetiDefiniše atribute koji su zajedno 

jedinstveni.

finder bez parametara operacijaMarkira operaciju kao operaciju koja vrši 

pretragu i vraća entitet ili kolekciju entiteta.

greaterEqual bez parametara parametar kod finder operacija

Naznačava da vrednost stvarnog parametra mora biti >= od vrednosti atributa entiteta.

greaterThan bez parametaraparametar kod 

finder operacijaNaznačava da vrednost stvarnog parametra mora biti > od vrednosti atributa entiteta.

lessEqual bez parametara parametar kod finder operacija

Naznačava da vrednost stvarnog parametra mora biti <= od vrednosti atributa entiteta.

lessThan bez parametaraparametar kod 

finder operacijaNaznačava da vrednost stvarnog parametra mora biti < od vrednosti atributa entiteta.

Tabela 2.1 ­ Ugrađene oznake

Za finder operacije slaganje parametara operacije sa atributima entiteta nad kojima se vrši pretraga se obavlja po nazivu. Na osnovu multipliciteta povratne vrednosti se određuje da li se očekuje jedan enitet ili kolekcija entiteta. Ukoliko se prati ova konvencija proste pretrage nad entitetima je moguće automatizovano generisati.

87

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.3.18.2. Validatori (ValidatorType)

Validatori predstavljaju specijalizaciju ograničenja i omogućavaju definisanje uslova koji mora   biti   ispunjen   da   bi   se   instanca   elementa   modela   nad   kojom   je   primenjen   smatrala ispravnom.   Metaklasa  ValidatorType  se   specijalizuje   u   metaklase  BuildInValidatorType  i UserValidatorType koje definišu ugrađene i korisničke validatore respektivno. S obzirom da se metaklasa ValidatorType direktno nasleđuje iz metaklase ConstraintType moguće je definisati elemente modela nad kojima je moguće primeniti validator kao i formalne parametre validatora. Tekuća verzija DOMMLite jezika definiše 33 ugrađena validatora prikazanih u tabeli 2.2.

88

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Naziv Parametri Primenjuje se na

Opis

isAlphaNumericbez 

parametaraatribut Vrednost atributa mora biti alfanumerik

isLowerCasebez 

parametaraatribut Vrednost atributa mora biti zadata malim 

slovima

isUpperCasebez 

parametaraatribut

Vrednost atributa mora biti zadata velikim slovima

isCommaSeparatedIntegerList

bez parametara

atributVrednost atributa mora biti lista 

celobrojnih vrednosti odvojenih zarezima

isCommaSeparatedEmailList

bez parametara

atribut Vrednost atributa mora biti lista email adresa odvojenih zarezima

isOnlyDigitsbez 

parametaraatribut Vrednost atributa mora sadržati samo cifre

isNotOnlyDigitsbez 

parametaraatribut

Vrednost atributa ne sme sadržati samo cifre

isOnlyLettersbez 

parametaraatribut Vrednost atributa može sadržati samo 

slova

isValidEmailbez 

parametaraatribut

Vrednost atributa mora biti ispravna email adresa.

isValidImagebez 

parametaraatribut Vrednost atributa mora biti validna slika.

isValidImageURL

bez parametara

atribut Vrednost atributa mora biti validan URL na sliku.

isValidURLbez 

parametaraatribut Vrednost atributa mora biti validan URL

isValidHTMLbez 

parametaraatribut

Vrednost atributa mora biti validan HTML fragment

isWellFormedXML

bez parametara

atribut Vrednost atributa mora biti validan XML

isWellFormedXMLFragment

bez parametara

atribut Vrednost atributa mora biti validan XML fragment

89

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

isExistingURLbez 

parametaraatribut Vrednost atributa mora biti validna i 

postojeća URL adresa

isGreaterThanInt

integer atribut Vrednost atributa mora biti veća od zadate celobrojne vrednosti

isLessThanInt integer atribut Vrednost atributa mora biti manje od zadate celobrojne vrednosti

isGreaterOrEqualThanInt

integer atribut Vrednost atributa mora biti veća ili jednaka od zadate celobrojne vrednosti

isLessOrEqualThanInt

integer atributVrednost atributa mora biti manja ili 

jednaka od zadate celobrojne vrednosti

isBetweenIntsInclusive

integer1,integer2

atribut Vrednost atributa mora biti >=integer1 i <=integer2

isBetweenIntsExclusive

integer1,integer2

atributVrednost atributa mora biti >integer1 i 

<integer2

isGreaterThanRef

ref atribut Vrednost mora biti veća od vrednosti referenciranog atributa

isLessThanRef ref atribut Vrednost mora biti manja od vrednosti referenciranog atributa

isGreaterOrEqualThanRef

ref atribut Vrednost mora biti veća ili jednaka od vrednosti referenciranog atributa

isLessOrEqualThanRef

ref atributVrednost mora biti manja ili jednaka od 

vrednosti referenciranog atributa

isBetweenRefsInclusive

ref1,ref2 atribut Vrednost atributa mora biti >=ref1 i <=ref2

isBetweenRefsExclusive

ref1,ref2 atribut Vrednost atributa mora biti >ref1 i <ref2

notEmptyIfRefsNotEmpty

ref, ... atribut Vrednost mora biti uneta ukoliko su referencirani atributi uneti

emptyIfRefsNotEmpty

ref,... atributVrednost ne sme biti uneta ukoliko su 

referencirani atributi uneti

notEmptyIfRefsEmpty

ref,... atribut Vrednost mora biti uneta ukoliko referencirani atributi nisu uneti

90

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

emptyIfRefsEmpty

ref,... atributVrednost ne sme biti uneta ukoliko 

referencirani atributi nisu uneti

matchesRegularExpression

string atribut Vrednost je ispravna ako odgovara zadatom regularnom izrazu

Tabela 2.2 ­ Ugrađeni validatori

2.4. Tekstualna notacija DOMMLite jezika

U cilju  postizanja   jednostavnosti   implementacije   i  održavanja  alata,  kao  i  mogućnosti lakšeg skaliranja razvoja sa povećanjem broja članova razvojnog tima u vidu automatizovane integracije i praćenja verzija modela odlučeno je da se za definisanje modela inicijalno koristi tekstualna notacija. 

Da bi bilo moguće kreiranje parsera tekstualne reprezentacije DOMMLite modela bilo je potrebno definisati gramatiku jezika formalnim metodama. S obzirom da je u implementaciji parsera korišćen  openArchitectureWare  alat,  za definisanje tekstualne notacije se u nastavku koristi xText jezik koji ima dosta sličnosti sa BNF­om. 

2.4.1. Model

Svaki DOMMLite model počinje ključnom rečju model  iza koga se navodi ime modela, opciono kratak i dugi opis. U nastavku definisanja modela se navodi specifikacija korisnički definisanih primitivnih tipova, korisnički definisana ograničenja i zatim se navode paketi.

DOMMLiteModel:"model" name=ID (shortDesc=STRING)? (longDesc=STRING)?((dataTypes+=UserDataType)|(constraintTypes+=ConstraintType))*(packages+=Package)*;

Listing 2.1 ­ Gramatičko pravilo definisanja DOMMLite modela

Na listingu 2.2 dat je primer definisanja modela.

91

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

model Upis "Upis" "Upis brucoša na Fakultet tehničkih nauka"tagType decimalPlaces(_int) appliesTo _propvalidatorType isInIntValues(_int,...) appliesTo _propvalidatorType isToday appliesTo _propdataType decimal

package maticniPodaci "Matični podaci"{

....

Listing 2.2 ­ Primer definisanja DOMMLite modela

2.4.2. Paketi

Paketi   predstavljaju   osnovni   oblik   organizacije   elemenata  DOMMLite  modela   (videti 2.3.5). Paketi se zadaju ključnom rečju package iza koga sledi obavezno ime i opciono kratak i dug opis paketa. Granice paketa se demarkiraju znacima “{“ i “}”. Unutar paketa se navode elementi paketa koji mogu biti drugi paketi ili klasifikatori. xText pravilo koje formalno definiše prethodno navedeno je prikazano na listingu 2.3.

Package:"package" name=ID (shortDesc=STRING)? (longDesc=STRING)? "{"

(packageElements+=PackageElement)*"}";

Abstract PackageElement:Package|Classifier;

Listing 2.3 ­ xText gramatičko pravilo definisanja paketa

Listing  2.4  prikazuje  primer  paketa   sa  nazivom  resource  u  kome  je  definisan  entitet ResourceQuantity.

package resource {entity ResourceQuantity {

key {prop int ResourceQuantityId

}prop Resource resourceprop real quantity

}}

Listing 2.4 ­ Primer definisanja paketa u DOMMLite jeziku

92

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.4.3. Korisnički definisani primitivni tipovi

DOMMLite  jezik,  u   tekućoj  verziji,  definiše  9 ugrađenih  primitivnih   tipova podataka. Pored toga, korisniku je omogućeno definisanje dodatnih tipova koji se na ravnopravan način tretiraju od strane alata. Ključna reč za definisanje korisničkog primitivnog tipa je dataType iza koga sledi naziv tipa. Sva pravila koja važe za ugrađene primitvne tipove važe i za korisničke. S obzirom da se primitivni tipovi nasleđuju iz klasifikatora (metaklasa Classifier) sva pravila koja važe   za   klasifikatore   važe   i   za   korisničke   primitivne   tipove.   Primitivni   tipovi   se   mogu deklarisati  u zaglavlju modela ili kao element bilo kog paketa. Listing  2.5  prikazuje pravilo definisanja korisničkog primitivnog tipa.

UserDataType:"dataType" name=ID (shortDesc=STRING)? (longDesc=STRING)?;

Listing 2.5 ­ Gramatičko pravilo deklaracije korisničkog primitivnog tipa

Na listingu 2.6 je prikazan primer deklaracije primitivnog tipa decimal.

dataType decimal

Listing 2.6 ­ Deklaracija primitivnog tipa

2.4.4. Enumeracije

Enumeracije   predstavljaju   nabrojivi   tip   (videti  2.3.4).   Ključna   reč   za   definisanje nabrojivog tipa je  enum  iza koje se navodi obavezno ime i opciono kratak i dug opis.  Telo enumeracije je definisano znacima “{“ i “}” unutar koga se navode literali enumeracije koji predstavljaju moguće vrednosti koje može da ima varijabla ovog tipa. Literal enumeracije je definisan svojim imenom i stringom  value  koji predstavlja njegovu   skraćenu reprezentaciju koja se može koristiti prilikom smeštanja vrednosti enumeracije u bazu podataka. Listing  2.7 prikazuje gramatičko pravilo za definisanje enumeracije u xText jeziku.

 

93

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Enumeration:"enum" name=ID (shortDesc=STRING)? (longDesc=STRING)? "{"

(literals+=EnumerationLiteral)+"}";

EnumerationLiteral:name=ID value=STRING (shortDesc=STRING)? (longDesc=STRING)?;

Listing 2.7 ­ Gramatičko pravilo za definisanje enumeracije zadato u xText jeziku

Listing 2.8 prikazuje definisanje nabrojivog tipa Pol.

enum Pol {MUSKI "M" "Muški"ZENSKI "Z" "Ženski"

}

Listing 2.8 ­ Primer enumeracije

Enumeracija se ravnopravno može koristiti svuda gde se može koristiti prost tip.

2.4.5. Strukturne osobine

Strukturne osobine su u DOMMLite metamodelu definisane metaklasom Property (videti 2.3.9)   i   mogu   biti   atributi   ili   reference   što   je   određeno   vrednošću   atributa  type  instance metaklase  Property.  Ukoliko je tip atributa (type)  postavljen na klasifikator  koji  predstavlja prost tip (instanca metaklase DataType) tada je reč o običnom atributu. Ukoliko to nije slučaj reč je o referenci.

Listing 2.9 prikazuje xText gramatičko pravilo za definisanje strukturnih osobina. 

94

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Property:"prop"

( (ordered?="ordered") |(unique?="unique") | (readonly?="readonly") | (required?="required") )* (containment?="+")? type=[Classifier] (many?="[" (multiplicity=INT)? "]")?

name=ID ("<>" oppositeEnd=[Property])? ("[" constraints+=ConstraintSpec (","

constraints+=ConstraintSpec)* "]")?(shortDesc=STRING)? (longDesc=STRING)?

;

Listing 2.9 ­ Gramatičko pravilo za definisanje strukturnih osobina

Strukturna  osobina   je  određena  svojim  imenom koje  mora  biti   jednoznačno  u  okviru elementa modela koji ga sadrži. Strukturna osobina može imati kardinalitet 0..1 (required  je false i many je false), 1 (required je true i many je false), n (many je true i multiplicity>0) ili * (many  je  true  i  multiplicity=0). Kardinalitet se kontroliše znacima “[“ i “]” između kojih se opciono navodi kardinalitet. Ukoliko strukturna osobina ima kardinalitet koji je veći od 1 tada ključna reč  unique  određuje da li su elementi  kolekcije jedinstveni dok ključna reč  ordered određuje   da   li   elementi   kolekcije   imaju   uređenje.   Ključna   reč  readonly  naznačava   da   se vrednost ovog atributa postavlja eksternim mehanizmima i nije moguće da korisnik aplikacije promeni ovu vrednost ručno.

Svaka strukturna osobina može definisati jednu ili više instanci ograničenja koje mogu da definišu dodatnu semantiku strukturne osobine odnosno da definišu potrebne uslove da bi se vrednost strukturne osobine smatrala validnom. Ograničenja se navode unutar znakova “[“ i “]” i odvojena su zarezima.

Listing 2.10 prikazuje primer atributa sa definisanim validatorom isBetweenIntsInclusive koji obezbeđuje da će uneta vrednost biti u zadatom intervalu.

prop real prosekPrvogRazreda [isBetweenIntsInclusive(2,5)]"Prosek prvog razreda"

Listing 2.10 ­ Primer definisanja strukturne osobine

2.4.5.1. Atributi

Atributi su strukturne osobine čiji je tip prost što znači da može biti ugrađen ili korisnički 

95

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

primitivan tip ili enumeracija. 

Listing 2.11 prikazuje primer definicije prostog atributa.

prop required string brojFaksa "Broj faksa"

Listing 2.11 ­ Primer definicije prostog atributa

Sve navedeno za strukturne osobine važi i za atribute.

2.4.5.2. Reference

Reference   predstavljaju   specijalizaciju   strukturnih   osobina.   Za   referencu   važi   sve navedeno za atribute. Tip reference, za razliku od tipa atributa, ne može biti prost tip već može biti samo drugi klasifikator. Kod navođenja referenci potrebno je navesti inverzni kraj reference ukoliko je referenca dvosmerna. Ovo se obavlja sa oznakom <> iza koga se navodi ime atributa inverznog kraja. Referenca može imati semantiku sadržavanja tj. kompozicije (videti  2.3.9.1). Kompozicija se definiše navođenjem simbola + pre tipa reference. Listing 2.12 prikazuje primer definicije dvosmerne reference.

prop Fakultet pripadaFakultetu <> deliSeNaOdseke "Pripada fakultetu"

Listing 2.12 ­ Primer definicije dvosmerne reference

Da bi   referenca  bila  dvosmerna  dovoljno   je  da   jedan  kraj   reference  definiše  vezu  sa drugim,   nije   potrebno   da   je   to   definisano   na   oba   kraja.   Zbog   čitkosti   modela   ipak   se preporučuje da se suprotni krajevi definišu na oba kraja. Referenca koja se po nazivu navodi kao   referenca   drugog   kraja   biti   definisana   unutar   klasifikatora   koji   se   referencira   tj.   tipu reference.

Na listingu 2.13 je prikazan primer definisanja veze jedan­na­jedan.

prop PravaKorisnika korisnik <> prava "Korisnik" ...

prop +Korisnik prava <> korisnik "Prava" ...

Listing 2.13 ­ Primer definisanja veze jadan­na­jedan

96

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Na   listingu  2.14  je   prikazan   primer   definisanja   veze   jedan­na­više.   U   oba   primera prikazana je unidirekciona veza jedan­na­više s tom razlikom što je smer veze obrnut i što u prvom primeru imamo dodatnu semantiku sadržavanja (kompozitna veza).

entity UpisniRok "Upisni rok"{prop +Kandidat[] kandidati "Kandidati"

...

ilientity Kandidat "Kandidat"{

prop required UpisniRok upisniRok "Upisni rok"...

Listing 2.14 ­ Primeri definisanja veze jedan­na­više

Na listingu 2.15 dat je primer definisanja veze više­na­više.

entity Predmet "Predmet"{

prop Nastavnik[] nastavnici <> predmeti "Nastavnici"...entity Nastavnik "Nastavnik"{

prop Predmet[] predmeti <> nastavnici "Predaje predmete"...

Listing 2.15 ­ Primer definisanja veze više­na­više

2.4.6. Operacije

Operacije  se  u   tekućoj  verziji  DOMMLite   jezika  navode deklarativno  bez  definisanja implementacionih   detalja.   Detalji   implementacije   se   definišu   na   konkretom   jeziku   ciljne platforme.   Operacija ima povratni tip koji koji može biti prost tip ili referenca. Kardinalitet povratne vrednosti može biti * (iza imena tipa se nalazi “[]”) u kom slučaju se radi o kolekciji pa možemo primeniti ključne reči koje definišu uređenost i jedinstvenost elemenata kolekcije (ključne  reči  ordered  i  unique  respektivno).  Ove  informacije  će  biti  od  pomoći  generatoru prilikom   mapiranja     na   tipove   ciljne   platforme.   Povratna   vrednost   ne   mora   biti   obavezna (ključna reč  required  nije navedena) u kom slučaju je moguće da se vrati vrednost  null  (ili adekvatna  vrednost   ciljne  platforme).  Operacija   se   definiše  ključnom   rečju  op  iza   koje   se navode   opcioni   kvalifikatori  ordered,  unique  i  required  i   zatim   sledi   ime   tipa   povratne vrednosti. Posle navođenja imena tipa povratne vrednosti navodi se ime operacije i zatim unutar 

97

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

zagrada   slede   parametri   operacije.   Operacija   može   generisati     izuzetke   što   se   naznačava ključnom rečju  throws  iza  koje  sledi   lista  mogućih   izuzetaka.  Na kraju  se opciono navode kratak   i   dug   opis   operacije.   Operacija   može   da   ima   pridružena   ograničenja   koja   dodatno definišu semantiku operacije. Na listingu  2.16  prikazan je formalni opis sintakse operacije u xText jeziku za zadavanje gramatike.

Operation:"op" ( (ordered?="ordered") |

(unique?="unique") | (required?="required"))*type=[Classifier] (many?="[" (multiplicity=INT)? "]")? name=ID "("(parameters+=Parameter)?(","

parameters+=Parameter)* ")"("throws" exceptions+=[Exception] (","

exceptions+=[Exception])?)?("[" constraints+=ConstraintSpec (","

constraints+=ConstraintSpec)* "]")?(shortDesc=STRING)? (longDesc=STRING)?;

Listing 2.16 ­ Gramatičko pravilo jezičke konstrukcije za definisanje operacije

Na listingu 2.17 dat je primer operacije koja vraća kolekciju entiteta Kandidat. Operaciji je pridružena oznaka finder što znači da se operacija koristi za pretragu entiteta.

op Kandidat[] findbyName(string imeKandidata, string prezimeKandidata) [finder]

Listing 2.17 ­ Primer operacije zadate u DOMMLite jeziku

2.4.7. Parametri

Parametri operacije se navode unutar zagrada prilikom definisanja operacije. Definicija započinje opcionim kvalifikatorima  required,  unique  i  ordered koji imaju isto značenje kao i kod navođenja tipa atributa (videti  2.4.5), zatim sledi naziv tipa parametra iza koga se mogu navesti   uglaste   zagrade   “[]”   kao   oznaka  da   je   u   pitanju   kolekcija.  Dalje   se   navodi   naziv parametra i opcioni kratak i dug opis. Parametar može da ima pridruženo ograničenje čime se može  definisati  dodatna  semantika  parametra.  Listing  2.18  prikazuje  gramatičko  pravilo  za definisanje parametra operacije dok je primer prikazan na listingu 2.19 na primeru definisanja operacije findKandidatiByDatumPredajeDokumenata.

98

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Parameter:( (ordered?="ordered") | (unique?="unique") | (required?="required") )*type=[Classifier] (many?="[" (multiplicity=INT)? "]")? name=ID ("[" constraints+=ConstraintSpec ("," constraints+=ConstraintSpec)*

"]")?(shortDesc=STRING)? (longDesc=STRING)?

Listing 2.18 ­ Gramatičko pravilo jezičke konstrukcije za definisanje parametra operacije

op Kandidat[] findKandidatiByDatumPredajeDokumenata(date datumPredaje [greaterThan]) [finder]

Listing 2.19 ­ Primer navođenja parametra operacije

2.4.8. Odeljci

U cilju  podrške  generisanju   interfejsa  kod  objekata   sa  velikim  brojem atributa  kao   i jednostavnije navigacije unutar modela DOMMLite metamodel definiše odeljke (videti 2.3.12 i 2.3.13). Odeljci na logički način grupišu više strukturnih osobina i operacija. 

Odeljak počinje ključnom rečju  compartment  i identifikovan je svojim imenom. Unutar odeljka se nalaze jedan ili  više atributa,  referenci   ili  operacija  u zavisnosti  od tipa odeljka. Listing 2.20 prikazuje gramatička pravila za definisanja odeljaka osobina i odeljaka operacija.

FeatureCompartment:"compartment" name=ID (shortDesc=STRING)? (longDesc=STRING)?

"{"(features+=Feature)*

"}";

OperationCompartment:"compartment" name=ID (shortDesc=STRING)? (longDesc=STRING)?

"{"(operations+=Operation)*

"}";

Listing 2.20 ­ Gramatička pravila definisanja odeljaka

Na listingu  2.21  dat je primer upotrebe dva odeljka za razdvajanje osnovnih podataka entiteta i operacija pretrage.

99

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

compartment osnovniPodaci "Osnovni podaci" {prop string imeKandidata "Ime kandidata"prop string prezimeKandidata "Prezime kandidata"prop string imeJedogRoditelja "Ime jednog roditelja"prop Pol pol "Pol"

}compartment pretraga "Pretraga" {

op Kandidat[] findbyName(string imeKandidata) [finder]op Kandidat[] findStranci() [finder]

}

Listing 2.21 ­ Primer definisanja odeljaka entiteta

2.4.9. Entiteti

Entiteti   su   osnovne   gradivne   jedinice   domenskog   modela   (videti  2.3.14).   Osnovna karakteristika   entiteta   je   njihova   jednoznačna   identifikacija   u   sistemu.   Entitet   se   definiše ključnom rečju  entity  iza koga se navodi ime entiteta. Operacije entiteta mogu da zavise od jednog ili više servisa u kom slučaju se lista servisa od kojih entitet zavisi navodi iza ključne reči  depends. Entiteti se mogu nasleđivati pri čemu je podržano jednostruko nasleđivanje. Ime entiteta  koji  se nasleđuje se navodi   iza ključne reči  extends.  Telo entiteta  se navodi unutar znakova  “{“   i  “}”.  Kao prvi  element   svaki  entitet  mora  definisati   lokalni   semantički  ključ (videti  2.4.9.1).  Opciono entitet  može definisati  string reprezentaciju  svojih   instanci   i   to  se navodi   iza   ključne   reči  repr.   Navođenje   string   reprezentacije   se   obavlja   izrazom   u   kome figurišu string literali i reference prema atributima entiteta između kojih se nalazi znak “+”.

100

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Entity:"entity" name=ID

("extends" extends=[Entity])?("depends" depends+=[Service] ("," depends+=[Service])*)? (shortDesc=STRING)? (longDesc=STRING)?

"{"key=BusinessKey("repr" repr+=ReprParameter ("+" repr+=ReprParameter)*)?("[" constraints+=ConstraintSpec (","

constraints+=ConstraintSpec)* "]")?(features+=Feature)* (featureCompartments+=FeatureCompartment)*

"}";

ReprParameter:ReprParameterStr|ReprParameterRef;

ReprParameterStr:paramValue=STRING;

ReprParameterRef:paramValue=[Property];

Listing 2.22 ­ Gramatičko pravilo definisanja entiteta

Ograničenja  entiteta  se navode unutar  znakova “[“  i  “]”.  Posle  navođenja ograničenja entiteta  navode se osnovne osobine i  zatim opciono niz odeljaka osobina. Listing  2.23  daje primer definisanja entiteta StavkaRangListe.

entity StavkaRangListe "Stavka rang liste"{key {

prop readonly required int redniBroj [isGreaterOrEqualThanInt(1)]"Redni broj"

}[plural("Stavke rang liste")]

prop readonly required Kandidat kandidat "Kandidat"

}

Listing 2.23 ­ Primer deklarisanja entiteta

101

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.4.9.1. Semantički ključ entiteta

Semantički   ključ   entiteta   je   predstavljen   sa   jednim   ili   više   atributa   koji,   zajedno, jednoznačno   identifikuju  entitet  u  određenom kontekstu   (videti  2.3.14.2).  Poslovni  ključ   se definiše ključnom rečju key iza koga se navodi telo ključa sa jednim ili više prostih atributa.

Listing 2.24 prikazuje gramatičko pravilo definisanja poslovnog ključa.

BusinessKey:"key" "{"

(properties+=Property)+"}";

Listing 2.24 ­ Gramatičko pravilo definisanja poslovnog ključa

Na listingu 2.25 je dat primer poslovnog ključa.

key {prop int godinaUpisa

[isBetweenIntsInclusive(2000,2050)] "Godina upisa"

prop char[3] sifraUpisnogRoka "Šifra upisnog roka"}

Listing 2.25 ­ Primer navođenja semantičkog ključa entiteta

2.4.9.2. Zavisnost sa servisima

Ključna reč koja se koristi je  depends  iza koje se navode imena objekata sa kojima je tekući objekat u vezi zavisnosti. Definisanje veze zavisnosti sa servisima predstavlja podršku za tehniku umetanja zavisnosti (Dependency Injection  – videti  2.3.14.3). Listing  2.26  prikazuje definisanje veze zavisnosti između entiteta UpisniRok i servisa Upis.

entity UpisniRok depends Upis "Upisni rok"{...

}

Listing 2.26 ­ Primer definisanja zavisnosti između entiteta i servisa

102

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

2.4.10. Servisi

Servisi   su   elementi   objekta   koji   grupišu   logički   povezane   operacije   (videti  2.3.16). Definišu se ključnom rečju service iza koga se navodi ime servisa i opciono kratak i dugi opis. Telo  servisa  je  označeno znacima “{“  i  “}”.  Unutar   tela  servisa navode se,  u  prvom delu, operacije   koje   ne  pripadaju  niti   jednom  odeljku   a   zatim   se  opciono  navodi   jedan   ili   više odeljaka operacija. Listing 2.27 prikazuje gramatičko pravilo jezičke konstrukcije za definisanje servisa.

Service:"service" name=ID (shortDesc=STRING)? (longDesc=STRING)? "{"

(operations+=Operation)*(operationCompartmens+=OperationCompartment)*

"}";

Listing 2.27 ­ Gramatičko pravilo jezičke konstrukcije za definisanje servisa

Na listingu 2.28 je prikazan primer definisanja servisa Konkurs.

service Konkurs "Konkurs" {op void kreirajStatistiku(datetime datumOd, datetime datumDo)compartment kandidati {

op Kandidat[] findKandidatiByDatumPredajeDokumenata(date datumPredaje [greaterThan]) [finder]

}}

Listing 2.28 ­ Primer definicije servisa

2.4.11. Vrednosni objekti

Vrednosni   objekat   (ValueObject)   predstavlja   arhitekturalni   koncept   koji   se   koristi   u poslovnim sistemima za transfer vrednosti domenskog modela između arhitekturalnih slojeva aplikacije (videti 2.3.15). Vrednosni objekat se definiše ključnom rečju valueObject iza koga se navodi  ime objekta  i  opcioni kratak i dugi opis.  Unutar  tela  vrednosnog objekta se navode definicije strukturnih osobina koji čine posmatrani objekat. Reference vrednosnih objekta mogu biti samo prema drugim vrednosnim objektima. Ukoliko se navede referenca prema entitetu ona će   biti,   od   strane  DOMMLite  generatora,   tretirana   kao   referenca   prema   podrazumevanom vrednosnom   objektu   referenciranog   entiteta.   Vrednosni   objekti   podržavaju   jednostruko nasleđivanje   što   je   sintaksom   jezika   podržano   ključnom   rečju  extends.   Zavisnost   prema 

103

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

entitetima se definiše ključnom rečju depends.

ValueObject:"valueObject" name=ID("extends" extends=[ValueObject])?("depends" depends+=[Entity] ("," depends+=[Entity])*)? (shortDesc=STRING)? (longDesc=STRING)? "{"

("[" constraints+=ConstraintSpec ("," constraints+=ConstraintSpec)* "]")?(properties+=Property)*

"}";

Listing 2.29 ­ Gramatičko pravilo jezičke konstrukcije za definisanje vrednosnog objekta

a

Na listingu 2.30 je prikazan primer definisanja vrednosnog objekta OsobaVO.

valueObject OsobaVO "Osoba" {prop int sifraOsobe [isGreaterOrEqualThanInt(1)]

"Šifra osobe"prop string ime [isOnlyLetters] "Ime"prop string prezime [isOnlyLetters] "Prezime"prop AdresaVO adresa

}

Listing 2.30 ­ Primer definisanja vrednosnog objekta

2.4.12. Izuzeci

Izuzeci su objekti koji mogu biti generisani prilikom izvršavanje operacije (videti 2.3.17). Deklaracija operacije može sadržati listu izuzetaka koje je moguće generisati.  U  DOMMLite jeziku izuzetak se deklariše ključnom rečju exception iza koga se navodi ime izuzetka, opcioni kratak i dug opis i telo izuzetka koje može sadržati 0 ili više strukturnih osobina. Strukturne osobine bliže opisuju izuzetak koji se desio. 

Exception:"exception" name=ID (shortDesc=STRING)? (longDesc=STRING)?

"{"(properties+=Property)*

"}";

Listing 2.31 ­ Gramatičko pravilo jezičke konstrukcije za definisanje izuzetka

104

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

Listing 2.32 prikazuje primer definicije izuzetka.

exception ResourceNotAvailable "Resurs trenutno nije dostupan." {prop int errorCode

}

Listing 2.32 ­ Primer definicije izuzetka

2.4.13. Ograničenja

Ograničenja predstavljaju mehanizam proširenja jezika i definisanja dodatne semantike elemenata  modela   ili  vrednosti   instanci  elemenata  modela.  Ograničenja  mogu biti  oznake  i validatori (videti  2.3.18). Deklaracija ograničenja se navodi na svim mestima gde je moguće definisati klasifikator tj. element paketa što znači da se ograničenja mogu deklarisati na početku modela ali i u bilo kom paketu DOMMLite modela. Listing 2.33 prikazuje gramatičko pravilo kreiranja ograničenja.

ConstraintType:ValidatorType|TagType;

ValidatorType:UserValidatorType|BuildInValidatorType;

TagType:UserTagType|BuildInTagType;

Listing 2.33 ­ Gramatičko pravilo jezičke konstrukcije za navođenje deklaracije ograničenja

Ograničenje je moguće instancirati i povezati sa elementima modela koji su u deklaraciji navedeni kao elementi nad kojima se ograničenje može primeniti.  Prilikom deklarisanja tipa ograničenja   navodi   se   i   lista   formalnih   parametara   čiji   redosled   i   tip   se   mora   ispoštovati prilikom   instanciranja.   Listing  2.34  prikazuje   gramatičko   pravilo   jezičke   konstrukcije   za definisanje specifikacije ograničenja. 

105

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

ConstraintSpec: type=[ConstraintType] ("(" (parameters

+=ConstraintParameter)? ("," parameters+=ConstraintParameter)* ")")?

;

ConstraintParameter:ConstraintIntParameter|ConstraintRefParameter|

ConstraintStrParameter;

ConstraintStrParameter:paramValue=STRING

;

ConstraintIntParameter:paramValue=INT

;

ConstraintRefParameter:paramValue = [Property]

;

Listing 2.34 ­ Gramatičko pravilo jezičke konstrukcije za definisanje specifikacija ograničenja

2.4.13.1. Oznake

Oznake  predstavljaju  mehanizam   redefinisanja   osnovne   semantike   elemenata  modela. DOMMLite jezik definiše skup ugrađenih tipova oznaka (videti 2.3.18.1) a moguće je definisati dodatne,  korisničke  tipove oznaka.  Listing  2.35  prikazuje  gramatičko pravilo  za definisanje korisničkog  tipa  oznake.  Deklaracija  korisničke oznake počinje  ključnom rečju  tagType  iza koga se navodi ime tipa oznake i zatim se unutar zagrada navodi lista formalnih parametara (_string, _int, _ref ili ...). Iza opcione liste formalnih parametara se, opciono, navodi ključna reč appliesTo iza koje sledi lista elemenata modela nad kojima je moguće primentiti ovu oznaku. 

106

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

UserTagType:"tagType" name=ID

("("(parameters+=ConstraintTypeParameter)?(","parameters+=ConstraintTypeParameter)* ")")?

("appliesTo" ((appliesToEntity?="_entity") |(appliesToProperty?="_prop") | (appliesToParameter?="_param") | (appliesToOperation?="_op") |(appliesToService?="_service") | (appliesToValueObject?="_valueObject"))*)?

(shortDesc=STRING)? (longDesc=STRING)?;

Enum ConstraintTypeParameter:string="_string"|int="_int" | ref="_ref" | ellipsis="..."

;

Listing 2.35 ­ Gramatičko pravilo za definisanje deklaracije tipa korisničkih oznaka

Na listingu 2.36 je prikazana deklaracija tipa oznake decimalPlaces koja prima jedan celobrojni parametar i moguće je primenitit ovu znaku samo na atribute.

tagType decimalPlaces(_int) appliesTo _prop

Listing 2.36 ­ Primer deklaracije tipa oznake

2.4.13.2. Validatori

Validatori predstavljaju mehanizam definisanja uslova koji moraju biti zadovoljeni da bi se vrednosti elemenata modela smatrale ispravnim.  DOMMLite  jezik definiše skup ugrađenih validatora (videti 2.3.18.2) a moguće je definisati dodatne, korisničke tipove validatora. Listing 2.37  prikazuje   gramatičko   pravilo   za   definisanje   korisničkog   tipa   validatora.   Deklaracija korisničkog   validatora   počinje   ključnom   rečju  validatorType  iza   koga   se   navodi   ime   tipa validatora i zatim se unutar zagrada navodi lista formalnih parametara (_string, _int, _ref ili ...). Iza opcione liste formalnih parametara se, opciono, navodi ključna reč appliesTo iza koje sledi lista elemenata modela nad kojima je moguće primentiti ovaj validator. 

107

Specifikacija DOMMLite jezika za definisanje statičkih osobina poslovnih sistema

UserValidatorType:"validatorType" name=ID

("("(parameters+=ConstraintTypeParameter)?(","parameters+=ConstraintTypeParameter)* ")")?

("appliesTo" ((appliesToEntity?="_entity") |(appliesToProperty?="_prop") | (appliesToParameter?="_param") | (appliesToOperation?="_op") |(appliesToService?="_service") | (appliesToValueObject?="_valueObject"))*)?

(shortDesc=STRING)? (longDesc=STRING)?;

Enum ConstraintTypeParameter:string="_string"|int="_int" | ref="_ref" | ellipsis="..."

;

Listing 2.37 ­ Gramatičko pravilo za definisanje deklaracije tipa korisničkih validatora

Na  listingu  2.38  prikazana  je  deklaracija   tipa  validatora  isInIntValues  koja  prima kao parametar jedan ili više celobronih vrednosti i moguće ga je primeniti samo na atributima.

validatorType isInIntValues(_int,...) appliesTo _prop

Listing 2.38 ­ Primer deklaracije tipa validatora

108

3. Implementacija editora modela i generatora poslovnih aplikacija

Za   efikasno   definisanje   instanci   DOMMLite   metamodela   potrebna   je   implementacija robusnih   editora   modela   koji   će   posedovati   mogućnosti   za   brzo   i   jednostavno   kreiranje, pronalaženje i ažuriranje elemenata modela. Poželjno je da editori imaju ugrađenu podršku za validaciju modela u vreme editovanja kao i sistem pomoći korisniku kroz razne mehanizme kao što su dopune modela, predlozi konstrukcija koje su se pokazale u praksi kao najbolje (best  practice), upozoravanje o mogućim problematičnim konstrukcijama itd.

3.1. Implementacija DOMMLite metamodela korišćenjema ECore metametamodela

S obzirom da   je  celokupni   stek  DOMMLite  alata  organizovan oko Eclipse  platforme logičan   izbor   prilikom   implementacije  metamodela   bio   je  ECore  metametamodel   koji  čini okosnicu  EMF okvira   [EMF].  ECore     (meta)model   je  moguće  definisati   ručno,  upotrebom editora   tipa  stabla,  ali   je  ovakav vid kreiranja  modela  zamoran  i  nepraktičan.  Drugi,  češće korišćen   način   je   definisanje   metamodela   upotrebom   dijagrama   klasa   UML­a   i   korišćenje postojećih alata za modelovanje a zatim konvertovanje UML modela u ECore model. Ovo je moguće  ukoliko  se  prilikom  izrade  dijagrama klasa  koristi   samo podskup mogućnosti  koje pruža UML a koji su ujedno dostupni i u ECore jeziku. 

Na   slici  3.1  dat   je   prikaz  DOMMLite  metamodela   prikazanog  u  EMF ECore  model editoru tipa stabla. 

109

Implementacija editora modela i generatora poslovnih aplikacija

Slika 3.1 ­ DOMMlite metamodel u ECore editoru tipa stabla

Od  verzije   4.2  OAW alata   omogućeno   je   generisanje  ECore  metamodela   upotrebom xText gramatike za definisanje tekstualne sintakse jezika za modelovanje. Ovo je postignuto uvođenjem   sintakse   za  definisanje   referenci  čime   je   moguće   definisati   jezik   za   zadavanje modela tipa grafa (videti sekciju 7.4.3.2. ­ Cross References u [OAW4.2]).

110

Implementacija editora modela i generatora poslovnih aplikacija

3.2. Tekstualni editor za zadavanje modela

3.2.1. Definisanje gramatike DOMMLite jezika

Gramatika   DOMMLite   jezika   definisana   je   upotrebom   OAW   xText   jezika   (videti poglavlje   7   u   [OAW4.2]).   Za   definisanje   gramatike   OAW   pruža   podršku   u   vidu specijalizovanog editora za Eclipse okruženje sa bojenjem i proverom sintakse. U dodatku A je data puna definicija DOMMLite jezika za modelovanje upotrebom xText jezika.

3.2.2. Generisanje editora DOMMLite tekstualne notacije

Na osnovu xText gramatike jezika OAW generiše ECore model i eclipse tekstualni editor. Generisanje se obavlja definisanjem toka poslova (workflow). Generisani editor je delimično funkcionalan i potrebno je obaviti ručno prilagođavanje do postizanja pune funkcionalnosti.

Slika 3.2 predstavlja OAW projekat u kome su definisani gramatika jezika (.xtxt fajl), tok poslova za generisanje ECore metamodela (.oaw fajl) i editora modela (generisano kao poseban projekat).

111

Implementacija editora modela i generatora poslovnih aplikacija

Slika 3.2 ­ OAW projekat za definisanje DOMMLite metamodela i gramatike jezika

3.2.3. Prilagođavanje generisanog editora

Generisani   editor   nije   u   potpunosti   funkcionalan.  Dorada   se   obavlja   nasleđivanjem   i redefinisanjem klasa okvira za razvoj ili definisanjem, za tu namenu kreiranih, funkcija u OAW jeziku Xtend (videti 6.4. ­ Xtend  u [OAW4.2]). Elementi koje treba doraditi su sledeći:

• dopuna koda – dopuna koda automatski radi za sve definisane reference. Potrebno je suziti skup ponuđenih vrednosti na osnovu ograničenja definisana nad DOMMLite modelom.

• strukturni pogled (outline view) – potrebno je definisati na koji način se prikazuju elementi   modela   u   strukturnom   stablu.   Generisana   implementacija   ima   dobro definisan  postupak za  proširenje  čime  je  moguće  u potpunosti  kreirati  strukturni prikaz.

• ograničenja  modela  u  vreme editovanja  –  predstavlja  mogućnost  prijave  grešaka prilikom samog modelovanja.  Ograničenja  su definisana  upotrebom OAW check jezika.

• navigacija – moguće je definisati brzu navigaciju u modelu upotrebom standardnog Eclipse mehanizma kros­referenci (Ctrl + klik miša na naziv tipa).

112

Implementacija editora modela i generatora poslovnih aplikacija

3.2.3.1. Ugrađeni tipovi, validatori i oznake

DOMMLite definiše određeni broj ugrađenih tipova, validatora i oznaka (videti  2.3.2  i 2.3.18). Ugrađeni elementi jezika su implementirani kao punopravni elementi modela na M1 nivou. Svaki DOMMLite model ima implicitno ugrađen paket  buildIn  sa podpaketima  types, validators  i  tags  u kojima se nalaze ugrađeni  tipovi,  validatori   i  oznake respektivno, što  je prikazano i u strukturnom pogledu editora (slika 3.3).

Slika 3.3 ­ Ugrađeni tipovi, validatori i tagovi prikazani u strukturnom pogledu modela

Implementacija   ugrađenih   elemenata   modela   se   oslanja   na   mehanizam   instanciranja elemenata metamodela i ubacivanja instanci u model prilikom njegovog parsiranja. Kod obrade modela parsiranje se vrši u dve situacije:

1. U   vreme   editovanja   modela   upotrebom   eclipse   editora   modela   parsiranje   se   vrši konstantno   da   bi   se   obezbedilo   ažuriranje   strukturnog   pogleda   i  run­time  provera ograničenja modela.

2. Prilikom pokretanja generatora koda ciljne platforme iz opisa toka poslova (workflow).

Ubacivanje  ugrađenih  elemenata  modela   je   implementirano  kreiranjem funkcija  za   tu namenu u  jeziku  Xtend  OAW okvira.  Funkcije  su zadužene za  instanciranje  odgovarajućih paketa, tipova, oznaka i validatora, njihovo konfigurisanje i ubacivanje u model. Sve funkcije 

113

Implementacija editora modela i generatora poslovnih aplikacija

za kreiranje ugrađenih elemenata se nalaze u fajlu BuildIns.ext projekta dommlite.dsl. Funkcija injectBuildIns  vrši  proveru da  li   je  ubacivanje  već  odrađeno  i  ukoliko nije  poziva funkciju createBuildIns koja kreira buildIn paket i dodaje paket u kolekciju packages DOMMLiteModel instance. 

Listing 3.1 prikazuje funkciju injectBuildIns.

Void injectBuildIns(emf::EObject this) :this.eRootContainer.eAllContents.

typeSelect(Package).notExists(e|e.name=="buildIn") ? ((DOMMLiteModel)this.eRootContainer).

packages.add(createBuildIns()) : null;

Listing 3.1 ­ Xtend funkcija za poziv kreiranja ugrađenih elemenata modela

Problemi koji postoje sa tekućom verzijom OAW­a su ograničeni mehanizmi definisanja korisničkih akcija za vreme operacije parsiranja modela. Za parsiranje modela i prevođenje u objektni model, u fazi generisanja koda, brine se generisana klasa  ParserComponent  i njena metoda internalParse. Ovu klasu nije moguće redefinisati pa pozivanje injectBuildIns funkcije predstavlja problem. Rešenje koje DOMMLite trenutno koristi se bazira na činjenici da se u fazi   parsiranja,   neposredno   posle   samog   instanciranja   elemenata   modela,   vrši   povezivanje referenci na osnovu naziva tipova definisanih u tekstualnoj reprezentaciji modela. S obzirom da se povezivanje može redefinisati izmenom Xtend funkcija za tu namenu, moguće je u svakoj funkciji   za   povezivanje   referenci   pozvati  injectBuildIns  kao   propratni   efekat.   Listing  3.2 prikazuje   jednu  od   funkcija   za  povezivanje   u  koju   je,  na  početku,  umetnut   poziv   funkciji injectBuildIns.

Void link_type(dommlite::Property this) :injectBuildIns(this)->(let ents = this.allElements().typeSelect(dommlite::Classifier) :

this.setType(ents.select(e|e.id() ==

this.parsed_type).first()));

Listing 3.2 ­ Poziv funkcije za kreiranje ugrađenih elemenata modela

114

Implementacija editora modela i generatora poslovnih aplikacija

3.2.3.2. Ograničenja modela

Ograničenja   modela   su   implementirana   u   jeziku  Check.  Eclipse   DOMMLite   editor proverava ograničenja u vreme editovanja modela i prijavljuje greške na standardan način za Eclipse   platformu.  Pri   pozivu   generatora   koda  biće   izvršena  validacija  modela   pre   samog generisanja što obezbeđuje konzistentnost modela. 

Listing  3.3  prikazuje   ograničenje   koje   će   biti   izvršeno   za   svaku   instancu   metaklase ConstraintParameter  i   koje   proverava   da   li   se   parametar   ograničenja,   po   tipu,   slaže   sa specifikacijom ograničenja.

context ConstraintParameter ERROR "Type error for parameter " + (metaType==ConstraintIntParameter ?

((ConstraintIntParameter)this).paramValue :(metaType==ConstraintStrParameter ?

((ConstraintStrParameter)this).paramValue :(metaType==ConstraintRefParameter ?

((ConstraintRefParameter)this).paramValue.name :"!!! unknown parameter type !!!"

))) :

let constTypeParams = ((ConstraintSpec)eContainer).type.parameters :

constTypeParams.size==0 || constTypeParams.last().toString()=="ellipsis" ||

( (constTypeParams.get(((ConstraintSpec)eContainer).parameters.indexOf(this)).toString()=="int" && this.metaType==ConstraintIntParameter) ||

(constTypeParams.get(((ConstraintSpec)eContainer).parameters.indexOf(this)).toString()=="string" && this.metaType==ConstraintStrParameter) ||

(constTypeParams.get(((ConstraintSpec)eContainer).parameters.indexOf(this)).toString()=="ref" && this.metaType==ConstraintRefParameter) );

Listing 3.3 ­ Implementacija ograničenja parametra DOMMLite ograničenja po tipu

3.2.3.3. Strukturni pogled generisanog editora (outline)

Predstavlja, u eclipse terminologiji, pogled (view) oblika stabla koji prikazuje strukturu DOMMLite modela. Strukturni pogled omogućava hijerarhijski prikaz i navigaciju u modelu. Selekcijom elementa  strutkurnog pogleda vrši  se selekcija  odovarajućeg elementa  modela u tekstualnom editoru.

115

Implementacija editora modela i generatora poslovnih aplikacija

Implementacija   strukturnog  pogleda   se  bazira  na  prilagođavanju  generisanog  pogleda upotrebom Extend OAW jezika.  Za svaki element  modela prilikom prikaza poziva se  label Extend funkcija da bi se definisao tekst i image Extend funkcija da bi se definisala ikona koja će biti  prikazana kao čvor  stabla  pogleda.  Podrazumevana  implementacija  nalazi  se u  fajlu GenEditorExtensions.ext u direktorijumu src­gen editor projekta. Ručna implementacija nalazi se u fajlu EditorExtensions.ext u src folderu editor projekta.

Na listingu 3.4 dat je fragment EditorExtension.ext fajla.

import dommlite;

extension dommlite::Extensions reexport;extension dommlite::GenEditorExtensions reexport;

label(dommlite::Property this) : defaultProperty(this);

String defaultProperty(Object this):((NamedElement)this).name!=null ? ((NamedElement)this).name + multiplicityString((TypedElement)this) + " : " +((TypedElement)this).type.name + shortDesc(this) : null

String image(emf::EObject this) :metaType.name.split("::").get(1) + '.png';

String image(dommlite::ConstraintSpec this) : ValidatorType.isAssignableFrom(type.metaType) ?

'ValidatorSpec.png' :'TagSpec.png'

;

String image(dommlite::Property this) : !isReference() ? 'Property.png' :

(isBidirectionalReference() ? 'BidirectionalReference.png': 'Reference.png')

;

Listing 3.4 ­ Fragment EditorExtension.ext fajla za definisanje strukturnog pogleda

Na   konstrukciju   stabla   strukturnog   pogleda   može   se   uticati   redefinisanjem   funkcije outlineTree  fajla  GenOutline.ext.   Ova   funkcija   se   poziva   rekurzivno   prilikom   parsiranja modela,   kao   parametar   prima   model   a   potrebno   je   da   vrati   konfigurisan  UIContentNode objekat. Podrazumevana implementacija će vratiti stablo  ECore  sadržavanja pri čemu će biti uzeti u obzir samo elementi modela kod kojih label funkcija vraća vrednost različitu od null.

116

Implementacija editora modela i generatora poslovnih aplikacija

Na slici 3.4 prikazan je strukturni pogled modela.

Slika 3.4 ­ Strukturni pogled modela – Outline

3.2.3.4. Dopuna koda

Gotovo sva savremena integrisana okruženja za razvoj imaju mogućnost automatizovane dopune koda. Ova funkcionalnost predstavlja veliku pomoć prilikom kodiranja i dovodi do porasta produktivnosti programera. Predstavlja mogućnost da programer u svakom trenutku može, putem prečice na tastaturi, zatražiti pomoć od editora za dopunu identifikatora, izraza ili iskaza koji trenutno unosi. Editor će na osnovu delimično unetih informacija ponuditi programeru izbor mogućih varijanti za dopunu. OAW generisani editor dopunu koda rešava upotrebom gramatičkih pravila jezika, pre svega korišćenjem informacija o referencama između elemenata metamodela.

117

Implementacija editora modela i generatora poslovnih aplikacija

Generisana dopuna koda je u većini slučajeva zadovoljavajuća ali se javljaju situacije kada je potrebno uraditi redefinisanje. Primer kada je potrebno uraditi redefinisanje je atribut oppositeEnd metaklase Property. U ovom slučaju, standardni algoritam dopune koda će ponuditi kao mogućnost unosa imena svih instanci metaklase Property dok nama trebaju imena samo onih atributa koji pripadaju referenciranom entitetu i koji istovremeno referenciraju entitet koji sadrži posmatrani atribut.

Slika 3.5 prikazuje funkcionalnost dopune koda pre primene pravila dok slika 3.6 prikazuje funkcionalnost posle primene pravila napisanog u Extend jeziku na listingu 3.5.

Slika 3.5 ­ Dopuna koda pre primene pravila

Slika 3.6 ­ Dopuna koda nakon primene pravila

118

Implementacija editora modela i generatora poslovnih aplikacija

cached dommlite::Entity containingEntity(dommlite::Feature this) :let m = ((dommlite::DOMMLiteModel)this.eRootContainer) :m.packages.allEntities().select(e|

e.allFeatures().contains(this));

List[Proposal] completeProperty_oppositeEnd(emf::EObject ctx, String prefix) :

((Property)ctx).type.eContents.typeSelect(Property).select(e|e.type==((Property)ctx).containingEntity()).collect(x|newProposal(x.label(),x.id(),x.image()));

Listing 3.5 ­ Pravilo za dopunu koda kod bidirekcionih referenci

3.3. Implementacija generatora koda za Django okvir za razvoj

Kao   dokaz   mogućnosti   implementacije   koncepata   iznetih   u   ovom   radu   izrađen   je generator koda za Django platformu za razvoj [Django]. U daljem tekstu, DOMMLite generator za Django okvir za razvoj biće referenciran kao DOMMLite­Django.

Django predstavlja platformu za brz razvoj kompleksnih veb aplikacija. Implementiran je u celosti u programskom jeziku Python [Python] i distribuira se pod BSD licencom. 

3.3.1. Django arhitektura

Za procesiranje zahteva Django koristi varijantu MVC dizajn obrasca koju su autori, da bi naglasili razlike, nazvali MTV (Model­Template­View). Model je opisan  Python  klasom koja predstavlja domenski entitet sa svojim atributima, metodama, pravilima validacije itd. Šablon (template)  opisuje   izgled  stranice   i  definisan   je  namenskim  jezikom koji  nije  ograničen na generisanje  HTML­a već   je  moguće  generisati  bilo  kakav  tekstualni  sadržaj.  Pogled (view) predstavlja Python funkciju kojoj će poziv klijenta biti prosleđen. Ova funkcija je zadužena za poziv poslovne logike, dobavljanje podataka i poziv odgovarajućeg šablona.

Pojednostavljen opis načina rada je sledeći:

• U   konfiguracionom   fajlu  urls.py  se   nalaze   opisane   veze   između   URL­ova   i odgovarajućih  Python funkcija  kojima zahtev treba biti  prosleđen.  Za definisanje URL­ova koriste se regularni izrazi.

• Zahtev   koji   stigne   serveru   prosleđuje   se   Python   funkciji   koja   se   u   Django terminologiji   naziva  view  funkcija.   Regularnim   izrazima   u   mapiranju   se   mogu 

119

Implementacija editora modela i generatora poslovnih aplikacija

definisati   delovi   URL­a   koji   će   biti   prosleđeni   kao   parametri   poziva   funkcije pogleda (view).

• Funkcija  pogleda   (view)  vrši   poziv  poslovne   logike,  dobavljanje  podataka   itd.   i zatim poziva renderovanje odgovarajućeg šablona čiji rezultat se vraća klijentu.

Django, kao deo svoje arhitekture, definiše i objektno­relacioni maper na principu Active  Record  dizajn   obrasca   [ActiveRecord].   U   vreme   pisanja   ovog   rada   podržane   su   sledeće relacione  baze  podataka:  PostgreSQL,  MySQL,  SQLite,  Oracle  dok  je  podrška za  MS SQL Server  bila u razvoju.  Na osnovu domenskog modela opisanog  Python  kodom  Django  je u mogućnosti  da generiše šemu baze podataka.  API za operacije  dodavanja,  brisanja,   izmene, pretrage   i  dobavljanja  objekata  se generišu dinamički  u vreme  izvršavanja  aplikacije  što   je omogućeno dinamičkom prirodom Python jezika.

Django vrši dekompoziciju projekta u module koji se nazivaju aplikacijama. Aplikacija predstavlja funkcionalnu celinu koja se može izdvojiti i koristiti u drugim projektima. Tako, na primer, Django dolazi sa nizom korisnih aplikacija koje programer može na jednostavan način uključiti  u svoj projekat.  Jedna od najvažnijih  Django  aplikacija   je  admin  aplikacija  (videti sliku  3.7) koja omogućava generisanje  CRUD  (Create­Retrieve­Update­Delete)  interfejsa  za domenske  modele   u   vreme   izvršavanja   aplikacije.  Ovo  nam omogućava  da,  čim   završimo kreiranje domenskog modela za Django, imamo spreman standardni interfejs za unos, izmenu, brisanje i pretrage čime se razvoj znatno ubrzava.

120

Implementacija editora modela i generatora poslovnih aplikacija

Slika 3.7 ­ Django admin aplikacija

Django  ima ugrađenu podršku za   internacionalizaciju,  upravljanje   sesijama,  keširanje, autentifikaciju i autorizaciju itd. [Holovaty07].

3.3.2. Generisanje Django aplikacije

Django aplikacija se generiše na osnovu naziva DOMMLite modela. Naziv modela biće ujedno i naziv aplikacije. Za sada je podržana jedna DOMMLite aplikacija po projektu.

121

Implementacija editora modela i generatora poslovnih aplikacija

3.3.3. Generisanje Django modela

Django  model   predstavlja   opis   domenskog   entiteta   u   obliku  Python  klase.  Model   se opisuje navođenjem atributa klase kao instance polja (Fields). Polja su zadužena za definisanje tipa  podataka  koji  prihvataju  kao   i  ograničenja,  odnosno,  validatora.  Pored  obični   atributa domenskih   objekata,   definišu   se   i   metapodaci   putem   kojih   se   opisuje   ponašanje   API­ja generisanog objektno­relacionog mapera, interfejsa admin aplikacije i sl. Detalji se mogu naći u dokumentaciji django platforme [Django].

Sa stanovišta  MDSD tehnika,  potrebno  je  pronaći  način  za   razdvajanje  generisanog  i ručno kreiranog koda da bi se omogućilo ponovno generisanje koda po potrebi bez opasnosti od gubitka ručnih izmena. Django platforma, u tekućoj verziji, zahteva da se svi modeli nalaze u fajlu models.py u direktorijumu aplikacije i to je moguće promeniti samo izmenom koda django platforme.   Ovaj   pristup   može   biti   problematičan   jer   se   može   doći   u   koliziju   sa   budućim izmenama platforme od strane Django razvojnog tima. 

DOMMLite, da bi rešio ovaj problem koristi dinamičku prirodu Python jezika. Python poseduje  koncept  modula.  Modul  predstavlja   jedinicu  dekompozicije  Python  koda.  Ukoliko želimo da koristimo određene biblioteke funkcija, klasa itd. moramo da uključimo korišćeni modul   u   tekući   upotrebom   ključne   reči  import.   Svi   programski   objekti   nastaju   na   mestu njihovog deklarisanja. Npr. ukoliko želimo da pozovemo funkciju ona mora biti definisana pre poziva što znači da je interpreter već naišao na traženu funkciju i kreirao je u prostoru imena. Važno  je  napomenuti  da se  moduli  obrađuju  redosledom importa  po dubini.  U Pythonu  je manje­više   sve   objekat.   Ne   postoje   primitivni   tipovi.   Sve   programske   objekte   je   moguće dinamički redefinisati. Na primer, moguće je klasi dodati metodu posle njenog kreiranja i time će datu metodu imati sve novokreirane instance objekata te klase. Takođe je moguće dodati metodu   instanciranom   objektu   čime   će   samo   ta   instanca   imati   datu   metodu.   Detaljna dokumentacija Python programskog jezika je dostupna na [Python].

Imajući ove osobine  Python  jezika u vidu, DOMMLite na sledeći način strukturira kod Django modela:

• U fajlu models.py će biti generisane import klauzule koje redom uključuju:➢ fajl models_gen.py u kome se nalaze generisane klase modela i enumeracija.➢ module iz paketa <ime applikacije>.models_src koji su generisani inicijalno a zatim 

se ručno menjaju.➢ modul <ime applikacije>.models_src.post_models_load koji je namenjen dodatnim 

definicijama i akcijama po završetku učitavanja modela.

122

Implementacija editora modela i generatora poslovnih aplikacija

• U modulu/direktorijumu <ime aplikacije>.models_src  biće, za svaki entitet,  generisan modul koji importuje generisan entitet iz modula models_gen.py  i omogućava njegovu dinamičku redefiniciju. Ovi moduli se generišu samo ukoliko već ne postoje, da bi se sprečili gubitci ručno pisanog koda.

• U   modulu/direktorijumu   <ime  aplikacije>.models_src  biće   generisan   modul post_models_load u kome bi trebalo da se nalazi kod koji je potrebno interpretirati posle učitavanja modela.

Listing 3.6 prikazuje fragment generisanog models.py fajla.

# coding: UTF-8# WARRNING: This file is generated. DO NOT EDIT! # Generated on Fri Nov 02 11:16:29 CET 2007 from ModelsGen templates

from django.db import modelsfrom upis.models_gen import *

# Package maticniPodacifrom upis.models_src import drzavafrom upis.models_src import srednja_skolafrom upis.models_src import studijski_program

# Package upisfrom upis.models_src import upisni_rokfrom upis.models_src import kandidatfrom upis.models_src import rang_listafrom upis.models_src import stavka_rang_listefrom upis.models_src import kvota_za_studijski_programfrom upis.models_src import upisni_krug

...

from upis.models_src import post_models_load

Listing 3.6 ­ Fragment generisanog models.py fajla

U fajlu models_gen.py biće generisan kompletan kod Django modela bez implementacije poslovne   logike.   Za   jednostavne   metode   koje   vraćaju   skup   entiteta   na   osnovu   zadatog kriterijuma   (tzv.  finder  metode)   DOMMLite   pruža   mogućnost   automatskog   generisanja implementacije. Listing 3.7 daje prikaz fragmenta generisanog models_gen.py fajla.

123

Implementacija editora modela i generatora poslovnih aplikacija

# coding: UTF-8# WARRNING: This file is generated. DO NOT EDIT! # Generated on Thu Oct 18 20:10:25 CEST 2007 from ModelsGenBase templates

from django.db import modelsimport upis.validators

VRSTASKOLE_CHOICE = (('V','Viša'),('K','Visoka'),

)

POL_CHOICE = (('M','Muški'),('Z','Ženski'),

)

class Drzava(models.Model):# Business key ---------------------------sifraDrzave = models.CharField(verbose_name=u"Šifra države",

unique=True,max_length=3,validator_list=[upis.validators.isOnlyLetters,

upis.validators.isUpperCase])# --------------------------------------------

nazivDrzave = models.CharField(verbose_name=u"Naziv države", max_length=25)

def __unicode__(self):return self.nazivDrzave

class Meta:

verbose_name=u"Država"verbose_name_plural = u"države"custom = { "akuzativ" : u"državu" }

class Admin:search_fields = ['sifraDrzave','nazivDrzave']pass

Listing 3.7 ­ Fragment generisanog models_gen.py fajla

Za   svaki   entitet   modela   generiše   se   po   jedan   fajl/modul   u   modulu  <ime  aplikacije>.models_src.  Listing  3.8  daje   prikaz   generisanog   modula   sa   poslovnom metodom   koja   se   definiše   ručno.   Na   ovom   primeru   vidimo   mogućnost  Python  jezika   da dinamički zameni postojeću metodu drugom bez potrebe za nasleđivanjem.

124

Implementacija editora modela i generatora poslovnih aplikacija

# coding: UTF-8# This file is generated only once# Here you can override generated model.# Example: Changing model business method # form app_name.models_gen import ModelName# def some_method(self, param1):# ...implementation# ModelName.some_method = some_method## Generated on Thu Oct 18 17:19:27 CEST 2007 from ModelsSrc template

from django.db import modelsfrom upis.models_gen import Kandidat

def upisiKandidata(self, ):'''Proverava da li kandidat ima

potrebne uslove za upis i vrši upis'''raise NotImplementedError('Operation Kandidat.upisiKandidata has

not been implemented yet.')

Kandidat.upisiKandidata = upisiKandidata

Listing 3.8 ­ Primer generisanog modula za ručnu implementaciju poslovne logike

Na listingu  3.8  vidimo da podrazumevana implementacija generisane metode poslovne logike baca izuzetak  NotImplementedError  što će sprečiti  korišćene ove metode na bilo koji način  bez prethodne redefinicije.  Generisana  implementacija  u  <ime  aplikacije>.models_src modulu se bezbedno može izmeniti jer će biti očuvana prilikom sledećeg generisanja koda.

3.3.4. Generisanje Validatora

DOMMLite validatori  direktno koriste validacioni sistem  Django  platforme i mapiraju validatore   definisane   jezikom   na   odgovarajuće   validatore  Django  platforme,   ukoliko   je   to moguće.   Za   validatore   koji   nisu   podržani  Django  platformom   isti   su   implementirani   u generisanom Python kodu. 

Za   korisnički   definisane   validatore   generiše   se   podrazumevana   implementacija   koja nikada nije zadovoljena (baca izuzetak  ValidationError). Pokušaj  unosa podataka koji koriste ovaj validator neće uspeti bez prethodne implementacije validatora.

Na listingu 3.7 validatori zadati modelom (isOnlyLetters, isUpperCase) mapirali su se na Python kod koji definiše parametar konstruktora polja modela – validator_list koji predstavlja 

125

Implementacija editora modela i generatora poslovnih aplikacija

listu Python funkcija koje će Django platforma pozvati kada se ukaže potreba za validacijom. U ovom slučaju reč je o ugrađenim validatorima. Fragment generisanog koda ugrađenih validatora dat je na listingu 3.9.

# coding: UTF-8# WARRNING: This file is generated. DO NOT EDIT! # Generated on Tue Nov 27 11:42:38 CET 2007 from ValidatorsGen template

from django.core import validatorsfrom datetime import datetimeimport settings

def isCommaSeparatedEmailList(field_data, all_data):validators.isCommaSeparatedEmailList(field_data, all_data)

def isValidImageURL(field_data, all_data):validators.isValidImageURL(field_data, all_data)

def isLowerCase(field_data, all_data):validators.isLowerCase(field_data, all_data)

def isGreaterThanRef (other_labels=None, other_fields=None):def _isGreaterThanRef(field_data, all_data):

ref_value_str=all_data.get(other_fields[0],'')try:

ref_value = float(ref_value_str)field_value = float(field_data)

except ValueError:# Ref value is not entered or types are not float# Try datestry:

ref_value = get_date_from_string(ref_value_str)field_value = get_date_from_string(field_data)

except ValueError:# Ref value is not entered or types are not datesreturn

if not (field_value > ref_value):raise validators.ValidationError(

'Vrednost mora biti veća od vrednosti u polju "%s"' %

(other_labels and other_labels or other_fields[0]))

return _isGreaterThanRef

Listing 3.9 ­ Fragment generisanog programskog koda ugrađenih validatora

Za razliku od Django modela, kod kojih postoji problem u lokaciji i nazivu fajla u kome se  nalaze,   svi  ostali   elementi  DOMMLite  modela,  koji   se  generišu  pri   svakom pokretanju 

126

Implementacija editora modela i generatora poslovnih aplikacija

generatora,   se   smeštaju   u   direktorijum    <ime  applikacije>_gen.  U   svakom   trenutku   ovaj direktorijum se može obrisati i ponovo generisati iz modela. Generisani validatori nalaze se u modulu <ime  applikacije>_gen.validators. U ovom modulu su generisani ugrađeni validatori kao i podrazumevane implementacije korisničkih validatora. Validatori se redefinišu u modulu <ime  applikacije>.validators.   Ovaj   modul   je   generisan   jednom   i   biće   očuvan   prilikom ponovnog generisanja koda. Na početku ovog modula se vrši import generisanih validatora i zatim je potrebno da se validatori redefinišu kreiranjem funkcija validatora sa istom signaturom i odgovarajućom implementacijom. Prilikom prvog generisanja,  za sve korisničke validatore biće   generisana   podrazumevana   implementacija   koja   je   identična   sa   generisanom implementacijom u modulu <ime applikacije>_gen.validators.

Listing 3.10 prikazuje primer <ime applikacije>.validators fajla.

# coding: UTF-8# This file is generated only once. You shoud manualy define user validator implementations

from django.core import validatorsfrom upis_gen.validators import *

def isInIntValues (*params):def _isInIntValues(field_data, all_data):

raise validators.ValidationError('Validator "%s" has been applied to this field but was never defined.'% 'isInIntValues')

return _isInIntValues

Listing 3.10 ­ Fragment generisanog programskog koda korisničkih validatora validatora

Slika  3.8  prikazuje   validatore   definisane   nad   elementima  DOMMLite   modela.   Pored validatora označenih na slici, validacija se obavlja i za druga ograničenja elemenata modela ­ npr. ključna reč required kod atributa entiteta. 

127

Implementacija editora modela i generatora poslovnih aplikacija

Slika 3.8 ­ Validatori elementata modela u kodu i strukturnom pogledu DOMMLite editora

Na slici  3.9  je prikazano delovanje validatora označenih na slici  3.8  (isOnlyLetters  za atribut   Ime   i  IsBetweenIntsInclusive  za   prosek   prvog   razreda)   na   admin   formi.  Takođe   je prikazano i  dejstvo ključne reči  required  (polje  Ime jednog roditelja).  Na primeru možemo videti da je na formi jasno naznačeno koja polja nisu zadovoljila zadata ograničenja.

128

Implementacija editora modela i generatora poslovnih aplikacija

Slika 3.9 ­ Dejstvo validatora na formama admin aplikacije

3.3.5. Generisanje Servisa

Podrazumevana   implementacija   servisa   se   generiše   u   modulu  <ime applikacije>_gen.services. DOMMLite servisi se mapiraju na Python module dok se servisne metode mapiraju na funkcije unutar tog modula. Svaki servis se generiše u posebnom modulu tj. fajlu. Podrazumevana implementacija servisne metode baca izuzetak NotImplementedError i potrebno je redefinisati. Redefinisanje se obavlja u modulu <ime applikacije>.services gde se nalaze ručne implementacije servisnih modula. Ovaj modul preslikava generisani modul, svaki servis se redefiniše u posebnom modulu (fajlu) koji je nazvan kao servis u DOMMLite modelu pri čemu su sva slova u nazivu mala. Ručna implementacija servisa vrši import generisanog servisa i zatim se u nastavku definišu funkcije sa istom signaturom kao i generisane čime se efektivno redefinišu.

129

Implementacija editora modela i generatora poslovnih aplikacija

Na slici  3.10  dat  je primer  DOMMLite servisa u editoru modela.  Na listingu  3.11  je prikazana   prvobitna   verzija   ručne   implementacije,   koja   je   generisana   jednom   i   zatim   je potrebno da se redefiniše.

Slika 3.10 ­ Servis u DOMMLite editoru

# coding: UTF-8# This file is generated only once. Here you should define your service methods manualy.# Service Konkurs# Generated on Fri Nov 30 23:40:52 CET 2007 from ServicesSrc templates

from upis_gen.services import konkurs# ------------------- Service Konkurs ---------------------------def kreirajStatistiku(datumOd, datumDo):

raise NotImplementedError('Operation Konkurs.kreirajStatistiku has not been implemented yet.')

# -------------- Start of operation compartment kandidati -----------------------------------def findKandidatiByDatumPredajeDokumenata(datumPredaje):

return Kandidat.objects.filter(datumPredaje__gt=datumPredaje)

# -------------- End of operation compartment kandidati -----------------------------------

Listing 3.11 ­ Generisana implementacija servisnih metoda za ručnu doradu

DOMMLite   generator   omogućava   automatsku   implementaciju   jednostavnih   servisnih metoda za pretragu. Ukoliko je metoda markirana sa oznakom finder i ukoliko vraća entitet ili kolekciju entiteta i ukoliko se svi parametri metode po nazivu slažu sa atributima entiteta koji 

130

Implementacija editora modela i generatora poslovnih aplikacija

se vraća  kao  povratna  vrednost   tada  će  biti  generisana  podrazumevana   implementacija.  Pri generisanju  finder  metoda   možemo   koristiti   oznake   parametara   da   bi   definisali   operatore poređenja koji će biti korišćeni u generisanoj pretrazi.  Na slici  3.10  vidimo da je parametar datumPredaje  servisne metode  findKandidatiByDatumPredajeDokumenata obeležen oznakom greaterThan što znači da će biti pronađeni oni kandidati čiji je datum predaje veći od zadatog datuma.

3.3.6. Proširenja DOMMLite jezika koja koristi django generator

Prilikom izrade django generatora iskorišćena je mogućnost proširenja DOMMLite jezika korišćenjem oznaka (tags  – videti  2.4.13.1). Oznake koje se koriste u django generatoru su dj_thisSide koja se koristi kod bidirekcionih veza više na više  i  akuzativ kao podška za srpski jezik.

Django prihvata deklarisanje veza više na više u django modelu samo na jednoj strani. Iz DOMMLite modela nije moguće, bez dodatnih informacija, odrediti na kojoj strani u django modelu definisati vezu. Stoga se u DOMMLite modelu navodi oznaka dj_thisSide na onoj strani veze gde želimo da se generiše definicija u django modelu.

Django generator ima ugrađenu podršku za srpski jezik. Generator će prepoznati oznaku akuzativ koja definiše naziv elementa modela u akuzativ padeškom obliku i generisaće dodatak unutar klase  Meta django modela što se u vreme izvršavanja aplikacije koristi za generisanje natpisa   na   korisničkom   interfejsu   u   ispravnom   padeškom  obliku.   S   obzirom  da  u   tekućoj implementaciji django okvira nije podržano dodavanje korisničkih metapodataka u klasi Meta  django  modela   bilo   je   potrebno   izvršiti   manju   izmenu   jezgra   django   okvira   da   bi   se   to omogućilo.  Generator  će koristiti  ovo proširenje   tako  što  će generisati  custom  atribut  klase Meta.  custom  atribut   je   rečnik   (mapa)   čiji   ključevi   predstavljaju   nazive   dok   pridružene vrednosti jesu vrednosti korisničkih metapodataka. Proširena django admin aplikacija će ove metapodatke iskoristiti da bi na ispravan način generisala natpise na korisničkom interfejsu. Na slici  3.11 su prikazani oznaka akuzativ nad entitetom Kandidat, generisan Python programski kod i natpisi nad određenim delovima korisničkog interfejsa.

131

Implementacija editora modela i generatora poslovnih aplikacija

Slika 3.11 ­ Mapiranje oznake akuzativ na generisani programski kod i korisnički interfejs

3.3.7. Jedinstvenost lokalnog poslovnog ključa

U skladu sa definicijama iznetim u 2.3.14.2 u klasi Meta django modela će biti definisano ograničenje jedinstvenosti grupe polja django modela na sledeći način:

a) ukoliko su globalni i lokalni poslovni ključevi isti i poslovni ključ se sastoji samo od jednog   polja   tada   će   django   polju   koji   predstavlja   poslovni   ključ   biti   dodat imenovani parametar unique postavljen na vrednost True.

b) ukoliko  su globalni   i   lokalni  poslovni  ključevi   isti   (ne postoji  model  koji  sadrži posmatrani model) i ključ se sastoji od više atributa/polja tada će, u klasi Meta, biti generisan atribut  unique_together čija vrednost će biti n­torka (tuple) naziva polja koji čine poslovni ključ.

c) ukoliko  globalni   i   lokalni   poslovni   ključevi   nisu   isti   (postoji  model   koji   sadrži posmatrani model) tada će biti u klasi  Meta generisan atribut  unique_together čija vrednost će biti n­torka polja koja čine lokalni poslovni ključ zajedno sa poljem koje predstavlja strani ključ prema modelu koji sadrži posmatrani model i definiše vezu sadržavanja.  Lokalni  poslovni  ključ   je   jedinstven  u okviru   instance  modela  koja sadržava.

Listing 3.7 prikazuje django model za slučaj iznet pod  stavkom a. Listing 4.13 prikazuje django model za slučaj iznet pod stavkom c. 

132

4. Studija slučaja - implementacija informacionog podsistema upotrebom DOMMLite alata

Dokaz funkcionalnosti DOMMLite skupa alata se, bez umanjenja opštosti, verifikuje na podsistemu za upis na Fakultet tehničkih nauka. S obzirom na strukturu fakulteta, broj odseka i broj kandidata koji se prijavljuju, kao i samog postupka prijema, primer je dovoljno složen da prikaže sve karakteristike alata i pokaže prednosti u odnosu na klasičan način izrade aplikacije.

4.1. Postavka problema

Potrebno   je   implementirati   aplikativnu   podšku   za   upis   na   Fakultet   tehničkih   nauka. Fakultet vrši upis kandidata po studijskim programima. Za svaki studijski program se definiše kvota za upis na državni budžet kao i kvota za upis na samofinansiranje. Kandidati se rangiraju na osnovu uspeha iz srednje škole i rezultata testova koji  se obavljaju kao aktivnost u toku upisa.  Kao dokaz o postignutom uspehu u toku srednje škole kandidat   je dužan da dostavi potrebnu   dokumentaciju/svedočanstva.   Prilikom   upisa   kandidat   može   da   izabere   više potencijalnih   želja/studijskih   programa   na   koje   želi   da   konkuriše   pri   čemu   je   jedna   želja osnovna. Za svaki studijski program se definišu potrebni testovi koje kandidat mora da uradi. Test može imati minimalan broj bodova koje kandidat mora da ostvari da bi imao pravo učešća u daljem procesu upisa na željeni studijski program. 

Proces upisa kandidata se obavlja na sledeći način:

• Kandidati u određenom periodu podnose prijave na konkurs sa potrebnom konkursnom dokumentacijom.

• Vrši se inicijalno rangiranje kandidata na osnovu uspeha u srednjoj školi.• Na   osnovu   želja   kandidata,   testova   i   raspoloživih   prostorija   se   formira   raspored 

polaganja testova.• Kandidati pristupaju rešavanju testova.• Posle završetka svih testova kandidati se rangiraju po studijskim programima. Ovaj put 

se uzimaju u obzir i rezultati na testu.• U više ciklusa se vrši upis. • Poslednji ciklus upisa obavlja se na licu mesta, prozivkom.

Ciklus upisa kandidata se obavlja na sledeći način:

• Oni kandidati  koji  se na rang listi  nalaze unutar propisane kvote budžetskih mesta  i 

133

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

mesta za samofinansiranje imaju mogućnost upisa u toku trajanja ciklusa. • Ukoliko kandidati koji su na budžetu svoje osnovne želje ne izvrše upis smatra se da su 

odustali od osnovne želje. Uklanjaju se sa liste osnovne želje.• Kandidati koji se upišu uklanjaju se sa svih ostalih rang lista.

4.2. Analiza zahteva

Za   analizu   funkcionalnih   zahteva   korišćeni   su   slučajevi   korišćenja   (Use   Cases)   i preporuke za njihovo pisanje iz [Cockburn01].

4.2.1. Slučajevi korišćenja

4.2.1.1. Prijava na konkurs

Slučaj korišćenja Prijava kandidata na konkurs

Glavni učesnici 1. Kandidat2. Referent studentske službe

Glavni scenario uspeha

1. Kandidat referentu predaje prijavu za konkurs i potrebnu konkursnu dokumentaciju.2. Referent unosi podatke o kandidatu.3. Kandidat dobija broj konkursne prijave.

Proširenja:

1a. Kandidat nema svu potrebnu dokumentaciju.    1a1. Referent obaveštava kandidata o nedostajućoj dokumentaciji.    1a2. Kandidat dobavlja potrebnu dokumentaciju.

1b. Kandidat ne ispunjava uslove definisane konkursom.     1b1. Referent obaveštava kandidata da ne ispunjava uslove predviđene konkursom.

134

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

4.2.1.2. Rangiranje kandidata i izrada rang lista

Slučaj korišćenja Rangiranje kandidata i izrada rang lista

Glavni učesnik Referent studentske službeKontrolor upisa

PredusloviSvi podaci su ispravno uneti (kandidati, studijski programi, kvote). Ne postoje objavljene rang liste za tekući upisni krug.

Glavni scenario uspeha

1. Referent izvršava operaciju rangiranja kandidata. Kreiraju se rang liste koje nisu javno objavljene.2. Kontrolor vrši proveru rang lista i izdaje odobrenje za javno objavljivanje.3. Referent proglašava liste javnim.

Proširenja:

2a. Kontrolor upisa ima primedbe na rang liste.    2a1. Kontrolor dostavlja primedbe referentu studentske službe.    2a2. Referent studentske službe vrši korekcije.    2a3. Kontrolor vrši reviziju korekcije i izdaje odobrenje za objavljivanje ili se u slučaju da kontrolor ima dodatne primedbe izvršava korak 2a1.

135

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

4.2.1.3. Kreiranje rasporeda polaganja

Slučaj korišćenja Kreiranje rasporeda polaganja

Glavni učesnici Referent studentske službeKontrolor upisa

Preduslovi Potrebni podaci su uneti (kandidati, želje, testovi po studijskim programima, prostorije i njihov kapacitet).

Glavni scenario uspeha

1. Referent izvršava operaciju kreiranja rasporeda polaganja ispita. Raspored nije javno objavljen.2. Kontrolor upisa vrši proveru rasporeda i daje odobrenje za objavljivanje.3. Referent vrši objavljivanje rasporeda.

Proširenja:

2a. Kontrolor upisa ima primedbe na raspored polaganja testova    2a1. Kontrolor dostavlja primedbe referentu studentske službe.    2a2. Referent studentske službe vrši potrebne korekcije.    2a3. Kontrolor vrši reviziju korekcije i izdaje odobrenje za objavljivanje ili se u slučaju da kontrolor ima dodatne primedbe izvršava korak 2a1.

136

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

4.2.1.4. Upis kandidata

Slučaj korišćenja Upis kandidata

Glavni učesnici KandidatReferent studentske službe

Preduslovi Kandidat je stekao potrebne uslove za upis

Glavni scenario uspeha

1. Kandidat podnosi popunjen obrazac i potrebne dokaze o uplati referentu studentske službe.2. Referent pronalazi kandidata u sistemu i vrši akciju upisa.3. Sistem vrši upis kandidata, alocira broj indeksa i kreira elektronski dosije studenta.4. Referent izdaje indeks.

Proširenja:

1a. Kandidat nema svu potrebnu dokumentaciju.    1a1. Referent obaveštava kandidata o nedostajućoj dokumentciji.    1a2. Kandidat dobavlja potrebnu dokumentaciju.

4.3. Specifikacija dizajna

4.3.1. DOMMLite model

4.3.1.1. Entitet Drzava

Osnovni matični podaci koji se koriste prilikom upisa su države, srednje škole i studijski programi. Na listingu 4.1 definisan je entitet Drzava. Poslovni ključ je sifraDrzave. Šifra države mora biti  maksimalne dužine 3 karaktera,  zadata velikim slovima (validatori  isUpperCase  i isOnlyLetters). Naziv države je maksimalne dužine 25 karaktera i obavezan je.

137

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

entity Drzava "Država"{key {

prop char[3] sifraDrzave [isOnlyLetters,isUpperCase] "Šifra države"

}

[plural("Države"), akuzativ("Državu")]

prop required char[25] nazivDrzave "Naziv države"

}

Listing 4.1 ­ Entitet Drzava

4.3.1.2. Entitet Skola

Na   listingu  4.2  definisan   je   entitet  Skola.   Poslovni   ključ   škole   je  sifraSkole. Podrazumevano sortiranje škola u tabelarnim pregledima je po nazivu u rastućem redosledu i po oznaci da li je stručna u opadajućem redosledu. Vrsta škole je opisana enumeracijom i može biti srednja, viša i visoka.

138

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

entity Skola "Škola"{key {

prop char[3] sifraSkole "Šifra škole"

}

[plural("Škole"), akuzativ("Školu"), orderBy(nazivSkole,"asc",strucna,"desc")] prop char[30] nazivSkole

"Naziv škole"

prop char[30] adresaSkole "Adresa škole"

prop bool strucna "Stručna?"

prop VrstaSkole vrsta "Vrsta"

}

enum VrstaSkole {SREDNJA "S" "Srednja"VISA "V" "Viša"VISOKA "K" "Visoka"

}

Listing 4.2 ­ Entitet SrednjaSkola

4.3.1.3. Entitet StudijskiProgram

Na listingu 4.3 data je definicija entiteta StudijskiProgram. Šifra je alfa­numerik napisan velikim slovima i maksimalna dužina šifre je 3. U tabelarnim pregledima biće prikazane kolone sifraStudijskogPrograma i naziv.  Ukoliko je atribut vazeci postavljen na true tada je studijski program aktivan i moguće je vršiti njegovo ažuriranje.

139

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

entity StudijskiProgram "Studijski program" {key {

prop char[3] sifraStudijaskogPrograma [isAlphaNumeric, isUpperCase] "Šifra studijskog programa"

}

[plural("Studijski programi"), akuzativ("Studijski program"),

listFields(sifraStudijaskogPrograma, naziv)]

prop required char[30] naziv "Naziv studijskog programa"

prop Test[] polazuSeTestovi <> polazeSeZaProgram[dj_thisSide]"Testovi koji se polažu"

prop bool vazeci "Važeći?"

}

Listing 4.3 ­ Entitet StudijskiProgram

4.3.1.4. Entitet Kandidat

Na sledećem listingu prikazan je entitet  Kandidat.   Lokalni poslovni ključ kandidata je njegov   konkursni   broj.   Konkursni   broj   mora   biti   pozitivan   što   je   definisano   validatorom isGreaterThanInt(0).  repr  izraz defniše način prikaza kandidata na listama. Kandidat će biti prikazan sa svojim imenom i prezimenom. Prezime, ime i ime roditelja se sastoji samo od slova (validator  isOnlyLetters).  Datum preuzimanja  dokumenata  mora biti  veći   ili   jednak datumu predaje (validator  isGreaterOrEqualThanRef). Kandidat se može nalaziti  na više stavki rang lista. Odeljak Podaci o srednjoj školi definiše informacije o uspehu u srednjoj školi. Poslovna metoda upisiKandidata() obavlja proveru da li kandidat zadovoljava uslove za upis i vrši upis kandidata na zadati studijski program. Kandidat može biti upisan ili neupisan što je definisano atributom  status  tipa  StatusKandidata. Oznakama su definisana polja za pretragu, sortiranje, filtriranje, kolone koje se prikazuju u listama kao i pluralni oblik naziva entiteta i naziv entiteta u akuzativu.

entity Kandidat "Kandidat" "Podaci o kandidatima, njihovom uspehu u srednjoj školi" {key {

prop int konkursniBroj[isGreaterThanInt(0)] "Konkursni broj"

140

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

}repr ime + " " + prezime

[plural("Kandidati"), akuzativ("Kandidata"), searchBy(prezime, ime, imeRoditelja), filterFields(status,datumPredaje,pol), orderBy(konkursniBroj, "asc"), listFields(konkursniBroj,prezime, ime, prosekPrvogRazreda,

prosekDrugogRazreda, prosekTrecegRazreda,prosekCetvrtogRazreda, test1Bodovi,test2Bodovi, test3Bodovi)]

prop required char[20] prezime [isOnlyLetters] "Prezime"

prop required char[15] ime [isOnlyLetters] "Ime"

prop required char[15] imeRoditelja [isOnlyLetters] "Ime jednog roditelja"

prop required Pol pol "Pol"

prop required date datumPredaje"Datum predaje dokumenata"

prop date datumPreuzimanjaDokumenata [isGreaterOrEqualThanRef(datumPredaje)]"Datum preuzimanja dokumenata"

prop bool originalniDokumenti "Originalni dokumenti?"

prop required StudijskiProgram zelja1 "Osnovna želja"

prop readonly real zelja1Bodova"Bodovi za osnovnu želju"

prop StudijskiProgram zelja2 "Druga želja"

prop readonly real zelja2Bodova"Bodovi za drugu želju"

prop StudijskiProgram zelja3 "Treća želja"

prop readonly real zelja3Bodova"Bodovi za treću želju"

prop TerminZaPolaganje[] termini <> kandidati"Termini prijemnih testova"

prop readonly StatusKandidata status "Status"

prop readonly date datumUpisa"Datum upisa"

141

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

prop readonly StavkaRangListe[] stavkeRangListe <> kandidat

op void upisiKandidata(StudijskiProgram program) throws KandidatNemaUsloveZaUpis"Upis kandidata" "Proverava da li kandidat ima potrebne uslove za upis i vrši upis"

compartment podaciSrednjaSkola "Podaci o srednjoj školi"{prop real prosekPrvogRazreda

[isBetweenIntsInclusive(2,5)] "Prosek prvog razreda"

prop real prosekDrugogRazreda [isBetweenIntsInclusive(2,5)] "Prosek drugog razreda"

prop real prosekTrecegRazreda [isBetweenIntsInclusive(2,5)] "Prosek treceg razreda"

prop real prosekCetvrtogRazreda [isBetweenIntsInclusive(2,5)] "Prosek četvrtog razreda"

prop readonly real bodoviZaUspeh "Bodovi za uspeh"

prop Skola skola "Završena škola"

prop int godinaMaturiranja "Godina maturiranja"

}compartment dodatniPodaci "Dodatni podaci"

"Specifični, ređe korišćeni podaci" {prop bool stranac "Stranac?"prop bool poOdluci "Upisuje se po odluci?"prop bool prelazak "Prelazak sa drugog fakulteta?"prop bool menjaStruku "Menja struku?"

}compartment rezultatiTestova "Rezultati testova" {

prop real test1Bodovi "Bodovi za test 1"prop readonly Test test1 "Test 1"prop real test2Bodovi "Bodovi za test 2"prop readonly Test test2 "Test 2"prop real test3Bodovi "Bodovi za test 3"prop readonly Test test3 "Test 3"

}}

enum StatusKandidata {UPISAN "U" "Upisan"NIJE_UPISAN "N" "Nije upisan"

}

exception KandidatNemaUsloveZaUpis "Kandidat nema uslove za upis."{prop string razlog

}

Listing 4.4 ­ Entitet Kandidat

142

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

Operacija  upisiKandidata  baca   izuzetak  KandidaNemaUsloveZaUpis  ukoliko  kandidat nije zadovoljio sve uslove upisa.

4.3.1.5. Entitet UpisniRok

Entitet  UpisniRok  je   jednoznačno   identifikovan   složenim   poslovnim   ključem   koji   se sastoji   od   atributa  godinaUpisa  i  sifraUpisnogRoka.  godinaUpisa  mora   biti   u   intervalu 2000­2050. sifraUpisnogRoka je niz od maksimalno 3 karaktera. repr izraz definiše da će string reprezentacija upisnog roka biti šifra i godina upisa spojeni znakom “­”. Upisni rok sadrži listu kandidata, listu upisnih krugova, listu kvota za studijske programe i listu termina za polaganje. 

entity UpisniRok "Upisni rok"{key {

prop int godinaUpisa[isBetweenIntsInclusive(2000,2050)]

"Godina upisa" prop char[3] sifraUpisnogRoka "Šifra upisnog roka"

}repr sifraUpisnogRoka + "-" + godinaUpisa[plural("Upisni rokovi"), akuzativ("Upisni rok")]

prop +Kandidat[] kandidati "Kandidati"

prop +UpisniKrug[] upisniKrugovi "Upisni krugovi"

prop +KvotaZaStudijskiProgram[] kvoteZaPrograme "Kvote za studijske programe"

prop +TerminZaPolaganje[] terminiPolaganja"Termini za polaganje"

}

Listing 4.5 ­ Entitet UpisniRok

4.3.1.6. Entitet UpisniKrug

Upisni krug je određen šifrom upisnog kruga tipa  int. Upisni krug sadrži rang liste po studijskim programima. Određeni su datumi početka i završetka upisnog kruga pri čemu datum početka   mora   biti   manji   ili   jednak   datumu   završetka   (validator  isLessOrEquealThanRef). Indikator da li su rang liste objavljene nije moguće postavljati ručno (ključna reč readonly) već se to obavlja  putem poslovne procedure.

143

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

entity UpisniKrug "Upisni krug" {key {

prop int sifraUpisnogKruga "Šifra upisnog kruga"}repr sifraUpisnogKruga + "- od " +

datumPocetka + " do " + datumZavrsetka

[plural("Upisni krugovi"), akuzativ("Upisni krug")]

prop +RangLista[] rangListe "Rang liste"

prop date datumPocetka [isLessOrEquealThanRef(datumZavrsetka)] "Datum početka"

prop date datumZavrsetka "Datum završetka"

prop readonly bool ranglisteObjavljene "Da li su rang liste objavljene"

}

Listing 4.6 ­ Entitet UpisniKrug

4.3.1.7. Entitet KvotaZaStudijskiProgram

KvotaZaStudijskiProgram  određuje   upisne   kvote   za   budžet   i   samofinansiranje   po studijskom programu.  Lokalni poslovni ključ je  sifraKvote.   Kvote moraju biti pozitivni celi brojevi (validator isGreaterOrEqualThanInt(0)).

144

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

entity KvotaZaStudijskiProgram "Kvota za studijski program" {

key {prop int sifraKvote "Šifra kvote"

}

[plural("Kvote za studijski program"), akuzativ("Kvotu za studijski program")]

prop required StudijskiProgram program "Za studijski program"

prop required int kvotaBudzet [isGreaterOrEqualThanInt(0)]

"Kvota za budžet"

prop required int kvotaSamofinansiranje [isGreaterOrEqualThanInt(0)]"Kvota za samofinansiranje"

}

Listing 4.7 ­ Entitet KvotaZaStudijskiProgram 

4.3.1.8. Entiteti RangLista i StavkaRangListe

Rang   liste   su   predstavljene   entitetima  RangLista  i  StavkaRangListe.   Rang   liste   se generišu automatizovano kao proces rada poslovne procedure za rangiranje kandidata.  Rang lista je vezana za studijski program i sadrži stavke rang liste. Stavke rang liste su jednoznačno određene   sa   rednim   brojem   koji   mora   biti   veći   ili   jednak   1   (validator isGreaterOrEqualThanInt). Stavka rang liste je povezana za odgovarajućeg kandidata i sadrži rezultate sa testova kao i uspeh u srednjoj školi u cilju jednostavnijeg listanja rang liste.

entity RangLista "Rang lista"{key {

prop readonly int sifraRangListe "Šifra rang liste"}

repr "Rang lista - " + program

[plural("Rang liste"), akuzativ("Rang listu")]

prop readonly StudijskiProgram program "Za studijski program"prop readonly +StavkaRangListe[] stavke "Stavke rang liste"

}

entity StavkaRangListe "Stavka rang liste"{key {

145

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

prop readonly required int redniBroj [isGreaterOrEqualThanInt(1)]"Redni broj"

}

[plural("Stavke rang liste"), akuzativ("Stavku rang liste"), orderBy(redniBroj,"asc"), listFields(redniBroj, kandidat, ukupnoSkola,

ukupnoTestovi, ukupnoBodova)]

prop readonly required Kandidat kandidat "Kandidat"

prop readonly required real ukupnoBodova "Ukupan broj bodova"

compartment srednjaSkola "Uspeh u srednjoj školi" {prop readonly real razred1 "Prvi razred"prop readonly real razred2 "Drugi razred"prop readonly real razred3 "Treći razred"prop readonly real razred4 "Četvrti razred"prop readonly real ukupnoSkola

"Ukupno bodova za uspeh u srednjoj školi"}

compartment testovi "Uspeh na testovima" {prop readonly real test1Bodovi "Bodovi za test 1"prop readonly real test2Bodovi "Bodovi za test 2"prop readonly real test3Bodovi "Bodovi za test 3"prop readonly real ukupnoTestovi "Ukupno bodova za testove"

}

}

Listing 4.8 ­ Entiteti RangLista i StavkaRangListe

4.3.1.9. Entitet Test

Testovi su opisani entitetom Test. Lokalni poslovni ključ je alfa­numerik sifraTesta. Test ima svoj naziv, maksimalan kao i minimalan broj poena koji se mora osvojiti da bi kandidat stekao uslov za rangiranje. Test je u  više na više vezi sa studijskim programima – isti test se može zahtevati na više različitih studijskih programa i jedan studijski program može zahtevati polaganje više testova.

146

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

entity Test "Test" {key {

prop char[5] sifraTesta[isAlphaNumeric] "Šifra testa"

}[plural("Testovi"), akuzativ("Test")]

prop required char[50] nazivTesta"Naziv testa"

prop required int maxBrojPoena [isGreaterThanInt(0)]"Maksimalan broj poena"

prop required int minBrojPoena [isGreaterOrEqualThanInt(0)]"Minimalan broj bodova za prolaz"

prop StudijskiProgram[] polazeSeZaProgram <> polazuSeTestovi"Polaže se za studijski program"

}

Listing 4.9 ­ Entitet SalaZaPolaganje 

4.3.1.10. Entiteti SalaZaPolaganje i TerminZaPolaganje

SalaZaPolaganje  opisuje   prostorije   u   kojima   se   polažu   testovi.   Identifikator   je oznakaSale  maksimalne   dužine   4   karaktera   koji   moraju   biti   alfa­numerici   (validator isAlphaNumeric) zadati velikim slovima (validator  isUpperCase). Obavezan unos predstavlja kapacitet jer se na osnovu kapaciteta vrši alokacija mesta za kandidate.

147

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

entity SalaZaPolaganje "Sala za polaganje" {key {

prop char[4] oznakaSale[isAlphaNumeric, isUpperCase] "Oznaka sale"

}

repr oznakaSale + " - " + kapacitet + " mesta"

[plural("Sale za polaganje"), akuzativ("Salu za polaganje"), listFields(oznakaSale,kapacitet,nazivSale)]

prop char[50] nazivSale "Naziv sale"

prop required int kapacitet[isGreaterThanInt(0)] "Kapacitet"

}

Listing 4.10 ­ Entitet SalaZaPolaganje

TerminZaPolaganje  je jednoznačno identifikovan svojom šifrom (sifraTermina). Termin polaganja određuje salu u kojoj se polaže, termin, test koji se polaže kao i listu kandidata koji polažu.

entity TerminZaPolaganje "Termin za polaganje" {key {

prop readonly int sifraTermina}

[plural("Termini za polaganje"), akuzativ("Termin za polaganje")]

prop required readonly SalaZaPolaganje sala"Sala za polaganje"

prop required readonly datetime terminPolaganja"Termin"

prop required readonly Test test "Test koji se polaže"

prop readonly Kandidat[] kandidati <> termini[dj_thisSide]"Kandidati"

}

Listing 4.11 ­ Entitet TerminZaPolaganje 

148

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

4.3.1.11. Servis Upis

DOMMLite model Upis definiše servis Upis koji se sastoji od 5 servisnih metoda:

• kreiranjeRasporedaPolaganja  –   za   zadati   upisni   rok,   na   osnovu   raspoloživih prostorija i prijavljenih kandidata će formirati raspored polaganja kandidata.  Biće generisane instance entiteta TerminZaPolaganje.

• racunanjeUkupnogBrojaPoena  –   za   upisni   rok  će  na  osnovu  unetih  podataka  o uspehu u srednjoj školi kao i broju osvojenih poena na testovima izračunati ukupan broj poena po željama/studijskim programima.

• kreiranjeRangLista  – za upisni krug će kreirati rang liste kandidata po studijskim programima na koje su se prijavili. Ovu operaciju je moguće izvesti samo ukoliko rang   liste   nisu   objavljene,   u   protivnom   biće   generisan   izuzetak RangListeSuObjavljene.   Uspešnim   izvođenjem   ove   operacije   biće   generisane instance entiteta RangLista i StavkeRangListe.

• objavljivanjeRangLista – objavljuje rang liste zadatog upisnog kruga. Ova operacija menja vrednost boolean atributa ranglisteObjavljene entiteta UpisniKrug čime rang liste postaju javno dostupne.

service Upis "Upis" "Servis za upis" {op void kreiranjeRasporedaPolaganja(UpisniRok upisniRok)

"Kreiranje rasporeda polaganja testova""Na osnovu unetih podataka o salama za polaganje i željama

kandidata kreira raspored za polaganje"op void racunanjeUkupnogBrojaPoena(UpisniRok upisniRok)

"Izračunavanje ukupnog broja poena kandidata.""Na osnovu uspeha u srednjoj školi i na testovima računa se i ažurira ukupan broj poena kandidata."

op void kreiranjeRangLista(UpisniKrug upisniKrug "Upisni krug" )throws RangListeSuObjavljene"Kreiranje rang lista""Kreiranje rang lista po studijskim programima na osnovu podataka o kandidatima."

op void upisKandidata(UpisniKrug upisniKrug "Upisni krug") "Upis kandidata""Upis svih kandidata sa rang lista koji su rangirani na budžet na studijskom programu osnovne želje."

op void objavljivanjeRangLista(UpisniKrug upisniKrug "Upisni krug")

"Objavljivanje rang lista""Rang liste postaju javno dostupne. Posle ove operacije nije moguće menjati rang liste."

}

Listing 4.12 ­ Servis Upis

149

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

4.4. Implementacija

Implementacija aplikacije se svodi na generisanje koda, definisanju poslovnih metoda i izrade   ručno   definisanih   formi.   DOMMLite   model  Upis  ne  definiše,   dodatne,   korisničke validatore.

4.4.1. Implementacija django modela

Django modeli se generišu DOMMLite­django generatorom unutar fajla models_gen.py. Listing 4.13 daje prikaz generisanog django modela (Python klase) RangLista.

class RangLista(models.Model):# Business key -------------------------------sifraRangListe = models.IntegerField(verbose_name=u"Šifra rang

liste")# --------------------------------------------

# This side Reference StudijskiProgram.program program = models.ForeignKey('StudijskiProgram',

verbose_name=u"Za studijski program",related_name="rangLista_program_set", null=True, blank=True)

# Other side Reference UpisniKrug.rangListe upisniKrug_rangListe = models.ForeignKey('UpisniKrug',

verbose_name='upisni krug', related_name='rangListe')

def __unicode__(self):return u"Rang lista - %s" % (self.program,)

class Meta:

verbose_name=u"Rang lista"verbose_name_plural = u"rang liste"unique_together = ('sifraRangListe','upisniKrug_rangListe', )custom = { "akuzativ" : u"rang listu" }

class Admin:pass

Listing 4.13 ­ Django model generisan DOMMLite­django generatorom

Ručna izmena generisanih django modela je moguća u za to predviđenim, generisanim fajlovima. Dorada je potrebna u slučaju postojanja poslovnih metoda entiteta dok je u ostalim slučajevima dorada retko potrebna.

150

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

4.4.2. Implementacija servisnih rutina

Servisne rutine se generišu u paketu  upis.services.upis  i potrebno ih je implementirati u programskom jeziku  Python uz oslonac na django okvir  za razvoj.  Na sledećem listingu je prikazana implementacija servisne metode kreiranjeRangLista. Funkcija  sledecaSifra za zadat django model i polje koje predstavlja numeričku šifru vraća sledeću šifru tj. najveću postojeću vrednost šifre uvećanu za 1 ili inicijalna_vrednost ukoliko ne postoji ni jedna instanca zadatog modela.

def sledecaSifra(model, naziv_polja, inicijalna_vrednost=1):''' Vraća sledeću celobrojnu vrednost za zadat model i polje.

Koristi se kod šifri objekata koje se inkrementiraju. '''return (model.objects.count()==0) and

inicijalna_vrednost or getattr(model.objects.order_by("-%s" % naziv_polja)[0],

naziv_polja) + 1

def kreiranjeRangLista(upisniRok, upisniKrug):'''Kreiranje rang lista po smerovima na osnovu podataka o kandidatima. upisniRok - šifra upisnog roka. upisniKrug - šifra upisnog kruga.'''# upisniKrug je sifra upisnog kruga

from dommlite_django_studsluz.upis.models import StudijskiProgram, \UpisniRok, UpisniKrug, Kandidat, RangLista, StavkaRangListe

from django.db.models import Q

upisni_rok = UpisniRok.objects.get(sifraUpisnogRoka=upisniRok)upisni_krug = UpisniKrug.objects.get(sifraUpisnogKruga=upisniKrug, \

upisniRok_upisniKrugovi=upisni_rok) # baca izuzatak DoesNotExists # ukoliko objekat ne postoji

# Ako su rang liste objavljene nije moguće vršiti novo kreiranje.if upisni_krug.ranglisteObjavljene:

raise RangListeSuObjavljene

# Brisanje postojećih rang listiupisni_krug.rangListe.all().delete()

racunanjeUkupnogBrojaPoena(upisni_rok.id)

for studijski_program in StudijskiProgram.objects.all():# Filtriramo samo one kandidate koji su konkurisali za tekući # studijski program u tekućem upisnom rokukandidati_za_program = Kandidat.objects.filter( \

Q(zelja1=studijski_program) | \Q(zelja2=studijski_program) | \

151

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

Q(zelja3=studijski_program) , \upisniRok_kandidati=upisni_rok)

# Testovi koji se polažu sortirani po id-u. Sortiranje se koristi# za uparivanje sa rezultatima testova na stavkama rang liste.testovi_za_program =

studijski_program.polazuSeTestovi.all().order_by('id')

stavke_rang_liste = [] for kandidat in kandidati_za_program:

stavka_liste = {}stavka_liste['kandidat'] = kandidatstavka_liste['razred1'] = kandidat.prosekPrvogRazredastavka_liste['razred2'] = kandidat.prosekDrugogRazredastavka_liste['razred3'] = kandidat.prosekTrecegRazredastavka_liste['razred4'] = kandidat.prosekCetvrtogRazredastavka_liste['ukupnoSkola'] = kandidat.bodoviZaUspeh

def poeni_za_zelju(k, zelja):for i in range(1,4):

k_zelja = getattr(k,'zelja%d'%i)if k_zelja is not None and k_zelja.id == zelja:

return getattr(k, 'zelja%dBodova' % i)else:

raise ValueError('Nepoznata želja')

stavka_liste['ukupnoBodova'] = poeni_za_zelju(kandidat, \ studijski_program.id)

stavka_liste['ukupnoTestovi'] = \stavka_liste['ukupnoBodova'] - \

stavka_liste['ukupnoSkola']

def poeni_za_test(k, test):for i in range(1,4):

k_test = getattr(k,'test%d'%i)if k_test is not None and k_test.id == test:

return getattr(k, 'test%dBodovi' % i)else:

return 0

test_idx = 1for test in testovi_za_program:

stavka_liste['test%dBodovi' % test_idx] = \ poeni_za_test(kandidat, test.id)

test_idx += 1

stavke_rang_liste.append(stavka_liste)

# Na kraju vršimo sortiranjedef poredi_kandidate(a, b):

if a['ukupnoBodova']<b['ukupnoBodova']:return -1

elif a['ukupnoBodova']==b['ukupnoBodova']:return 0

152

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

else:return 1

stavke_rang_liste.sort(cmp=poredi_kandidate, reverse=True)

# Kreiramo redne brojevefor i,stavka in zip(range(len(stavke_rang_liste)), \

stavke_rang_liste):stavka['redniBroj'] = i+1

# Upisujemo u bazurang_lista = RangLista()rang_lista.program = studijski_programrang_lista.sifraRangListe = sledecaSifra(RangLista,

'sifraRangListe')upisni_krug.rangListe.add(rang_lista)

for stavka in stavke_rang_liste:stavka_liste = StavkaRangListe()for key in stavka.keys():

setattr(stavka_liste, key, stavka[key])rang_lista.stavke.add(stavka_liste)

Listing 4.14 ­ Implementacija servisne metode za rangiranje kandidata

4.5. Validacija generisanog koda

Generisani   django   kod   je   testiran  definisanjem   inicijalnih   podataka   putem   dinamički generisanih formi admin aplikacije. Na slici  4.1  je prikazan unos podataka o testu. Forme za CRUD operacije su u potpunosti generisane na osnovu informacija iz DOMMLite modela.

153

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

Slika 4.1 ­ Unos podataka o testu

Pored podataka o testovima definisani su studijski programi, potrebni testovi za studijske programe, upisni rok, upisni krug.

Za   testirane   servisne   metode   za   kreiranje   rang   lista   napravljena   je   procedura   za generisanje  podataka  o  kandidatima.  Generisano  je  1000 kandidata   sa  željama,  uspehom u srednoj  školi   i   na   testovima  uz  oslonac  na  generator  pseudo­slučajnih  brojeva.  Upotrebom servisne metode kreiranjeRangLista opisanoj u 4.4.2. izvršeno je rangiranje. Slika 4.2 prikazuje deo rang liste kandidata jednog studijskog programa.

154

Studija slučaja ­ implementacija informacionog podsistema upotrebom DOMMLite alata

Slika 4.2 ­ Proizvod rada servisne metode kreiranjeRangLista. Pregled u admin aplikaciji.

155

5. Zaključak i dalji pravci razvoja

5.1. Zaključak

Predmet istraživanja  ove teze bio je kreiranje jezika za modelovanje poslovnih sistema (DOMMLite) i razvoj lanca alata za kreiranje i ažuriranje modela i generisanje programskog koda   za   ciljnu   platformu.   Motivacija   rada   bili   su   uočeni   problemi   kod   postojećih   rešenja baziranih  na  DSL principima.  Takođe,   jedan  od  motiva   izrade  ove   teze   jeste  činjenica  da najrasprostranjeniji   jezik za modelovanje ­  UML, zbog svoje opštosti,  nije pogodan u svim slučajevima.  UML  je  koristan,  pre   svega,   za  one  sisteme  čiji   se  domenski  koncepti  mogu jednostavno mapirati  na koncepte UML metamodela,  zatim u situacijama gde razvoj  novog jezika za modelovanje nije moguća alternativa, kao i sredstvo komunikacije jer su koncepti i grafička sintaksa UML­a dobro poznati. 

Prednosti razvoja posebnog jezika prilagođenog domenu su:

• jednostavnost učenja – jezik služi za definisanje rešenja u tačno određenom domenu i samim tim nije opterećen nepotrebnim elementima kao što je to čest slučaj sa jezicima za modelovanje opšteg tipa.

• proširivost – proširivost na nivou metamodela (tzv. heavy­weight proširenja) se postižu jednostavnije jer je struktura metamodela jednostavnija.

• jednostavnija  mašinska obrada – zbog svoje  jednostavnosti  na meta­nivou modeli  se jednostanije interpretiraju od strane  run­time platforme i jednostavnije se kompajliraju tj. jednostavnije je mapiranje na programski kod ciljne platforme.

Na osnovu analize literature, može se zaključiti da pristupi u kreiranju jezika specifičnih za domen, iako donekle različiti,  imaju isti cilj,  podizanje nivoa apstrakcije sa idejom da se sistem od   interesa  opiše  uz  pomoć   koncepata   domena,   odnosno,   da   se   problem opisuje   u domenu problema a ne u domenu rešenja. Prilikom implementacije DOMMLite jezika korišćen je MDE pristup kao specijalizacija opštih DSL ideja. Apstraktna sintaksa jezika definisana je metamodelom u kome figurišu standardni objektno orijentisani koncepti objekat/referenca, kao i  koncepti   entitet   i   servis.  Na  primeru   je  pokazano  da   se  upotrebom prikazanog   jezika  za modelovanje mogu u potpunosti modelovati statičke osobine složenog poslovnog podsistema što  omogućava  generisanje  najvećeg  dela   implementacije   i   istovremeno  postizanje  visokog stepena platformske nezavisnosti. 

Osnovni  doprinos  ove   teze   jeste  kreiranje   jezika  za  opis   statičke   strukture  poslovnih aplikacija čije prednosti, u odnosu na jezike za modelovanje opšte namene, kao i postojećih jezika specifičnih za domen, su sledeće:

156

Zaključak i dalji pravci razvoja

• koncepti globalnog i lokalnog poslovnog ključa entiteta – omogućavaju identifikaciju entiteta u okviru celokupnog sistema (globalni ključ) ili u okviru konteksta određenog entitetom koji sadržava (lokalni ključ). Takođe, ovi koncepti omogućavaju automatsko generisanje korisničkog interfejsa za CRUD operacije.

• jednostavno definisanje ograničenja instanci elemenata modela upotrebom validatora.• podrška za entitete i servise sa velikim brojem atributa i operacija – odeljci.• jezik   je   proširiv   definisanjem   korisničkih   tipova,   validatora   i   oznaka   pri   čemu   su 

validatori i oznake parametrizovani.

Pri tome DOMMLite jezik zadržava dobre osobine modernih jezika za modelovanje kao što su objektna orijentisanost, parcelizacija modela upotrebom paketa, definisanje platformski zavisnih osobina upotrebom oznaka i sl.

Modeli se mogu kreirati  i ažurirati  upotrebom različitih konkretnih sintaksi i različitih editora kao što su: grafički editori, editori tipa stabla, tabele, tekstualni editori itd. U ovom radu je  prikazan  razvoj  konkretne   tekstualne  sintakse   i  odgovarajućeg  editora.  Prednosti   rada  sa konkretnom tekstualnom sintaksom su:

• jednostavnost izrade i modifikacije editora pogoduje brzom prototipskom razvoju. Kada se jezik dovoljno stabilizuje može se, ukoliko je potrebno, pristupiti zahtevnijem poslu razvoja grafičkog editora.

• Model je moguće pregledati i ažurirati uz pomoć običnog tekst editora.• Serijalizovani   format  modela   je   identičan   sa  prikazom modela  koji   se  ažurira.  Nije 

potrebno dodatno mapiranje.• tekstualne sintakse omogućavaju jednostavnu integraciju paralelnih promena i praćenja 

verzija upotrebom sistema za kontrolu verzija (CVS, Subversion itd.).

Upotrebom   MDSD   tehnika   omogućena   je   integracija   generisanog   i   ručno   pisanog programskog koda. Implementacijom složenog poslovnog podsistema prikazanog u poglavlju 4. dokazana je praktična vrednost razvijenog DOMMLite jezika i propratnih alata.

5.2. Dalji pravci razvoja

Dalji pravci razvoja bili bi sledeći:

• proširenje   DOMMLite   metamodela   u   cilju   podrške   definisanju   dinamičkih   osobina poslovnih sistema čime bi se omogućila veća količina generisanog koda u odnosu na ručno   pisani.   Ovo   proširenje   bi,   takođe,   omogućilo   veći   stepen   platformske 

157

Zaključak i dalji pravci razvoja

nezavisnosti.• izrada generatora programskog koda za druge platforme kao što su Java/EJB, .NET, 

CORBA,   Web   servisi   itd.   Ovim   bi   bilo   omogućeno   da   se   isti   DOMMLite   model istovremeno   mapira   na   više   različitih   platformi   što   bi   bilo   naročito   značajno   za Enterprise sisteme gde je softversko­hardverska heterogenost neizbežna.

• izrada  grafičkog  eclipse  pogleda   (view)  koji  bi  omogućio  brzu  navigaciju   i  pregled strukture  modela.  Ovim bi   se  omogućilo   lakše  razumevanje  strukture  modela  što   je osnovna prednost konkretnih grafičkih sintaksi uz očuvanje svih prednosti tekstualnih sintaksi   jer   bi   se   ažuriranje   i     serijalizacija   modela   i   dalje   obavljala   upotrebom tekstualne sintakse.

• izrada   potpunog   grafičkog   editora   sa   mogućnošću   pregleda,   navigacije   i   ažuriranja modela.   Format   za   serijalizaciju   u   ovom   slučaju   morao   bi   omogućavati   čuvanje   i dijagram informacija (položaji, veličine, boje grafičkih primitiva itd.).

158

Reference

[ActiveRecord]  Active Record dizajn obrazac, http://en.wikipedia.org/wiki/Active_record

[Alanen05] Alanen M, Poress I, Model Interchange Using OMG Standards, Proceedings of the 2005 31st EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO­SEAA’05), 2005.

[Alanen05]  Alanen M, Poress I, Model Interchange Using OMG Standards, Proceedings of the 2005 31st EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO­SEAA’05), 2005.

[Almeida04] J. P. Almeida, R. Dijkman, M. van Sinderen, L. F. Pires. Platform­independent modeling in MDA: Supporting abstract platforms. In Proceedings of Model Driven Architecture: Foundations and Applications (MDAFA 2004), pages 217–231, 2004.

[Almeida04]  J. P. Almeida, R. Dijkman, M. van Sinderen, L. F. Pires. Platform­independent modeling in MDA: Supporting abstract platforms. In Proceedings of Model Driven Architecture: Foundations and Applications (MDAFA 2004), pages 217–231, 2004.

[Amati00]  Amati G., Ounis I, conceptual Graphs and First Order Logic. The Computer Journal, 43(1), 2000.

[AMMA]  ATLAS Model Management Architecture, http://wiki.eclipse.org/index.php/AMMA, 2007.

[AndroMDA]  AndroMDA projekat, http://www.andromda.org, 2007.

[Anido02]  Luis Anido, Manuel Caeiro, Judith Rodrıguez, Juan Santos. Applying MDA Concepts to Develop a Domain CORBA Facility for E­learning. Proceedings of the 5th International Conference on The Unified Modeling Language, pp. 321­335, 2002.

[Antkiewicz06]  Antkiewicz M, Czarnecki K, Framework­Specific Modeling Languages with Round­Trip Engineering. In O. Nierstrasz, J. Whittle, D. Harel, G. Reggio, editors, MoDELS 2006 ­ Model Driven Engineering Languages and Systems, 9th International Conference, Genoa, Italy, 2006. 

[Atkinson00]  Atkinson, C. and Kühne, T.: Meta­level independent modelling. In 

159

Reference

International Workshop on Model Engineering at 14th European Conference on Object­Oriented Programming, 2000.

[Atkinson02]  Colin Atkinson, Thomas Kühne: The Role of Metamodeling in MDA, Workshop in Software Model Engineering, 2002.

[Atkinson03]  Colin Atkinson, Thomas Kühne: Model­Driven Development: A Metamodeling Foundation. IEEE Software 20(5): 36­41, 2003.

[Atkinson05]  Colin Atkinson, Thomas Kühne: Concepts for Comparing Modeling Tool Architectures. MoDELS 2005: 398­413, 2005.

[ATL]  ATLAS Transformation Language, dostupno na http   ://   www.sciences.univ­nantes.fr/lina/atl/   

[Bauer05]  Christian Bauer, Gavin King, Hibernate in Action, Manning Publications Co, 2005.

[Bézivin01b]  Jean Bézivin, Olivier Gerbé: Towards a Precise Definition of the OMG/MDA Framework, Proceedings of the 16th Annual International Conference on Automated Software Engineering (ASE), 2001.

[Bézivin05]  Jean Bézivin, Frédéric Jouault, David Touzet: Principles, Standards and Tools for Model Engineering, Proceedings of the 10th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS'05), 2005.

[Bézivin06b]  Jean Bézivin, Frédéric Jouault, Ivan Kurtev, Patrick Valduriez; Model­Based DSL Frameworks

[Booch04] Grady Booch: MDA: A Motivated Manifesto?, Software Development, 2004.

[Bruce97]  Bruce, D.: What makes a good domain specific language? In Proceedings of the First ACM Workshop on Domain­Specific Languages. ACM, 1997.

[CG­OPG]  Code Generation: The One Page Guide, dostupno na http://www.codegeneration.net/files/JavaOne_OnePageGuide_v1.pdf

[Checkland98]  Checkland P., Holwell S., Information, Systems and Information Systems – making sense of the field. Chickester, UK, John Wiley & Sons, 1998.

[CM­SEI]  Carnegie Mellon Software Engineering Institute, Software Product Lines, http://www.sei.cmu.edu/productlines/, 2007.

160

Reference

[Cockburn01]  Alistair Cocburn, Writing Effective Use Cases, Addison­Wesley, 2001.

[Colmerauer92]  Alain Colmerauer, Philippe Roussel. The birth of Prolog. The second ACM SIGPLAN conference on History of programming languages, p. 37­52, 1992.

[CVS]  Concurrent Versions System, http://www.nongnu.org/cvs/, 2007.

[Czarnecki00]  K. Czarnecki and U. Eisenecker. Generative Programming: Methods, Tools, and Applications. Addison­Wesley, Boston, MA, 2000.

[Dejanović07]  Dejanović I, Milosavljević G, Perišić B, Uporedni prikaz dva popularna MDSD/MDA alata otvorenog koda, YU INFO '07, Kopaonik, 2007.

[Django]  Django Project, http://www.djangoproject.com/, 2007.

[Dmitriev]  Sergey Dmitriev, Language Oriented Programming: The Next Programming Paradigm, dostupno na http://www.onboard.jetbrains.com/is1/articles/04/10/lop/, 2007.

[DSLTools]  Microsoft Domain­Specific Language Tools, http://msdn.microsoft.com/vstudio/DSLTools/, 2007.

[Đurić04]  Đurić D, Gašević D, Devedžić V. MDA­Based Ontological Engineering. In Chang, S. K. (Ed.) Handbook of Software Engineering and Knowledge Engineering, Vol. 3, World Scientific Publishing Co., Singapore, 2004.

[Evans04] E. Evans, Domain­Driven Design: Tackling Complexity in the Heart of Software, Addison­Wesley Professional, 2004.

[Eisenecker97]  Eisenecker U. W, Generative Programming (GP) with C++, Lecture Notes In Computer Science; Vol. 1204, Proceedings of the Joint Modular Languages Conference on Modular Programming Languages, pp. 351­365, 1997.

[EMF]  Eclipse Modeling Framework, dostupno na http://www.eclipse.org/modeling/emf/, 2007.

[Ford04]  Neal Ford, Art of Java Web Development, Manning Publications Co, 2004.

[Fowler04]  Martin Fowler, Domain Specific Languages, Dostupno na http://www.martinfowler.com/bliki/DomainSpecificLanguage.html, 2004.

[Frankel03]  David S. Frankel, Model Driven Architecture: Applying MDA to  

161

Reference

Enterprise Computing, Wiley Publishing Inc., 2003.

[Frankel04]  David S. Frankel. The MDA Marketing Message And The MDA Reality. MDA Journal, Mart 2004.

[Gamma94]  Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object­Oriented Software. Addison­Wesley, 1994.

[GEMS]   Generic Eclipse Modeling System, http://www.eclipse.org/gmt/gems/about.php, 2007.

[GEF] Graphical Editing Framework, http://www.eclipse.org/gef/, 2007.

[GME­Manual]  GME User's Manual, dostupno na http://www.isis.vanderbilt.edu/projects/gme/GMEUMan.pdf, 2007.

[GME]  GME: The Generic Modeling Environment, Dostupno na http://www.isis.vanderbilt.edu/Projects/gme, 2007.

[GMF]  Eclipse Graphical Modeling Framework, http://www.eclipse.org/gmf/, 2007.

[Greenfield03]  Jack Greenfield, Keith Short. Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools. OOPSLA'03, Anaheim, California, USA, 2003.

[Gruber95]  Gruber, T. R. Toward Principles for the Design of Ontologies Used for Knowledge Sharing. , International Journal of Human and Computer Studies, 43(5/6): 907­928, 1995.

[Heering02]  Heering J, Mernik M. Domain­Specific Languages for Software Engineering. Proceedings of the 35th Hawaii International Conference on System Sciences, 2002.

[Holovaty07]  Adrian Holovaty, Jacob Kaplan­Moss, The Django Book, dostupno na http://www.djangobook.com/, 2007.

[Hudak96]  Hudak, P.: Building domain­specific embedded languages. ACM Computing Surveys, 28(4), Decembar 1996.

[HUTN]  Human Usable Textual Notation (HUTN) Specification, Version 1.0, OMG, formal/04­08­01, 2004. Dostupno na http://www.omg.org

[Intentional]  Intentional Software, http://intentsoft.com/

[ISIS­MIC]  Model Integrated Computing, Vanderbilt univerzitet, Institut za 

162

Reference

softverski integrisane sisteme, http://www.isis.vanderbilt.edu/

[JMI]  Java Metadata Interface, dostupno na http://java.sun.com/products/jmi/

[Jouault06a]  Jouault, F., Bézivin, J.: KM3: a DSL for Metamodel Specification, Proceedings of 8th IFIP International Conference on Formal Methods for Open Object­Based Distributed Systems, LNCS 4037, Bologna, 171–185, Italy, 2006.

[Jouault06b]  Jouault, F, Bézivin, J, and Kurtev, I : TCS: a DSL for the Specification of Textual Concrete Syntaxes in Model Engineering. In: GPCE'06: Proceedings of the fifth international conference on Generative programming and Component Engineering, Portland, Oregon, USA, pages 249—254. 2006.

[Jouault06c]  Jouault, F, and Bézivin, J : On the Specification of Textual Syntaxes for Models. In: Eclipse Modeling Symposium, Eclipse Summit Europe 2006, Esslingen, Germany. 2006.

[KIF]  Knowledge Interchange Format, dostupno na http://www­ksl.stanford.edu/knowledge­sharing/kif/

[Klint]  Klint, P., Lämmel, R. Kort, J., Klusener, S., Verhoef, C., Verhoeven, E.J. Engineering of Grammarware, http://www.cs.vu.nl/grammarware/

[Kühne06a]  Kühne Thomas, Matters of (meta­) modeling, Software and Systems Modeling, 5(4), 369, 2006.

[Kühne06b]  Kühne Thomas, Clarifying matters of (meta­) modeling: an author’s reply, Springer­Verlag 2006.

[Ledeczi01]  Akos Ledeczi, Miklos Maroti, Arpad Bakay, Gabor Karsai, Jason Garrett, Charles Thomason, Greg Nordstrom, Jonathan Sprinkle and Peter Volgyesi, The Generic Modeling Environment, Proceedings of WISP'2001, Budapest, Hungary, 2001.

[MagicDraw]  MagicDraw, dostupno na http://www.magicdraw.com/, 2007.

[Magnus07]  P. D. Magnus, Forallx – An Introduction to Formal Logic, dostupno na http://www.fecundity.com/logic, 2007.

[MDAGuide]  MDA Guide Version 1.0.1, document omg/2003­06­01, OMG, dostupno na http://www.omg.org/, 2003.

[MDR]  NetBeans Metadata Repository, dostupno na http://mdr.netbeans.org/

163

Reference

[Mellor02]  Mellor S, Balcer M, Executable UML: A Foundation for Model­Driven  Architecture, Addison­Wesley, 2002.

[Mellor04]  Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise. MDA Distilled: Principles of Model­Driven Architecture. Addison­Wesley, 2004.

[Mellor04b]  Mellor S, Starr L. Six Lessons Learned Using MDA. UML Satellite Activities 2004: 198­202, 2004.

[MetaEdit+]  MetaEdit+,  http://www.metacase.com/, 2007.

[metamodel.com]  metamodel.com, http://www.metamodel.com/

[MilosavljevićG04] Gordana Milosavljević, Branko Perišić. A Method and a Tool for Rapid Prototyping of Large­Scale Business Information Systems. Computer Science and Information Systems, Vol. 1, Number 2, November 2004.

[MilosavljevićB03] B. Milosavljević, M. Vidaković, S. Komazec, G. Milosavljević. User Interface Code Generation for EJB­Based Data Models Using Intermediate Form Representations. ACM Principles and Practice of Programming in Java, Kilkenny, Ireland 2003. 

[Miller95]  Miller J. G., “Living Systems”, Colorado: University Press of Colorado, 1995.

[MOF­QVT]  Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification, Final Adopted Specification, ptc/05­11­01, dosupno na http://www.omg.org/

[Muller05]  Pierre­Alain Muller, Michel Hassenforder: HUTN as a Bridge between ModelWare and GrammarWare – An Experience Report, 4th Workshop in Software Model Engineering (WiSME), 2005.

[OAW]  Eclipse Foundation: openArchitectureWare projekat, http://www.eclipse.org/gmt/oaw/, 2007.

[OAW4.2]  Sven Efftinge et al.: openArchitectureWare User Guide, version 4.2, dostupno na http://www.openarchitectureware.org/, 2007.

[OCL]  Object Constraint Language 2.0 Specification, version 2.0, ptc/2005­06­06, dostupno na http://www.omg.org/

[OMG­MIC]  Model Integrated Computing, Object Management Group. dostupno na http://mic.omg.org/

164

Reference

[OMG]  The Object Management Group, http://www.omg.org/

[OptimalJ]  OptimalJ – Model­driven Java development tool, dostupno na http://www.compuware.com/products/optimalj/, 2007.

[OWL]  Web Ontology Language, dostupno na http://www.w3.org/2004/OWL/

[Poli03]  Roberto Poli. Descriptive, Formal and Formalized Ontologies. Husserl's Logical Investigations reconsidered, Dordrecht, Kluwer Academic Publishers, pp. 183­210, 2003.

[Python]  Python Programming Language – Official Website, http://www.python.org/

[Raymond]  Eric S. Raymond, The Art of Unix Programming, Poglavlje 8 – Mini jezici, dostupno na http://www.faqs.org/docs/artu/minilanguageschapter.html

[RDF]  Resource Description Framework, dosupno na http://www.w3.org/RDF/

[Schmid06]  Douglas C. Schmidt, Model­Driven Engineering, Computer, IEEE Computer Society, Februar 2006, pp. 25­31.

[Sculptor]  The Server Side, Improving Developer Productivity with Sculptor, http://www.theserverside.com/news/thread.tss?thread_id=45698, 2007.

[SEP07]   Stanford Encyclopedia of Philosophy, Classical Logic, Standford University,  http://plato.stanford.edu/entries/logic­classical/, 2007.

[Sewall]  Stanley J. Sewall: Executive Justification For Adopting MDA, dostupno na http://www.omg.org/mda/mda_files/11­03_Sewall_MDA_paper.pdf

[Sowa84]  Sowa J. Conceptual Structure: Information Processing in Mind and Machine. Addison­Wesley, 1984.

[Struts] Apache Struts Framework, http://struts.apache.org/, 2007.

[Stahl06]  Stahl T, Völter M. Model­Driven Software Development: Tehnology, Engineering, Management, John Wiley & Sons, Ltd. 2006.

[SVN]  Subversion, http://subversion.tigris.org/

[Swing]  Creating a GUI with JFC/Swing, dostupno na http://java.sun.com/docs/books/tutorial/uiswing/

[TMF]  Eclipse Textual Concrete Syntaxes, dostupno na 

165

Reference

http://www.eclipse.org/gmt/tcs/

[UML2Infra]  Unified Modeling Language: Infrastructure, version 2.0, formal/05­07­05, dostupno na http://www.omg.org/, 2005.

[UML2Super]  Unified Modeling Language: Superstructure, version 2.0, formal/05­07­04, dostupno na http://www.omg.org/, 2005.

[Walls05]  Craig Walls, Ryan Breidenbach, Spring in Action, Manning Publications Co, 2005.

[Ward94]  Martin Ward, Language Oriented Programming, Software Concepts and Tools, 15, pp 147­161, 1994.

[Wiki­4GL]  Fourth­generation programming language.Wikipedia, the free encyclopedia, http://en.wikipedia.org/wiki/4GL, preuzeto 2007.

[Wiki­DSL]  Domain­specific programming language. Wikipedia, the free encyclopedia, http://en.wikipedia.org/wiki/Domain_Specific_Language, preuzeto 2007.

[Wiki­PosAp] Poslovni softver, http://en.wikipedia.org/wiki/Business_software, preuzeto 2008.

[Wiki­QVT]  QVT, Wikipedia, the free encyclopedia, http://en.wikipedia.org/wiki/QVT, preuzeto 2007.

[XMI]  OMG: MOF 2.0 / XMI Mapping Specification, v2.1, OMG Document formal/2005­09­01. Dostupno na http://www.omg.org/cgi­bin/doc?formal/2005­09­01, 2005.

[XMIDI]  OMG. Unified Modeling Language: Diagram Interchange version 2.0, Jul 2003. OMG document ptc/03­07­03. Dostupno na http://www.omg.org

166

Definicije korišćenih skraćenica

4GL  Fourth Generation Languages5GL  Fifth Generation LanguagesAC MDSD Architecture­Centric Model­Driven Software DevelopmentAM3 ATLAS MegaModel ManagementAMMA ATLAS Model Management ArchitectureAMW ATLAS Model WeaverAOP Aspect­Oriented ProgrammingAST Apstraktno stablo sintakse (Abstract Syntax Tree)ATL ATLAS Transformation LanguageBNF Backus­Naur FormCASE  Computer­Aided Software Engineering CDIF CASE Data Interchange FormatCIM Computation Independent ModelCMOF Complete MOFCOM Component Object ModelCORBA Common Object Request Broker ArchitectureCWM Common Warehouse MetadataDAO Data Access ObjectsDDMM Domain Definition MetamodelDI Dependency Injection (dizajn obrazac)DOM Document Object ModelDRY Don't Repeat Yourself (extreme programming)DSL  Domain­Specific LanguagesDSM Domain­Specific ModelingDTD Document Type DefinitionEBNF Extended Backus­Naur FormEJB Enterprise Java BeansEMF Eclipse Modeling FrameworkEMOF Essential MOFGEMS Generic Eclipse Modeling System

167

Definicije korišćenih skraćenica

GME Generic Modeling EnvironmentGMF Graphical Modeling FrameworkGPL  General Purpose LanguageHTML HyperText Markup LanguageHUTN  Human­Usable Textual NotationIP Intentional ProgrammingISO International Organization for StandardizationJ2EE Java 2 Enterprise EditionJCP Java Community ProcessJMI Java Metadata InterfaceJSP Java Server PagesKIF Knowledge Interchange Format KM3 Kernel meta­meta­modelLOP Language Oriented ProgrammingM2C Model­To­CodeM2M Model­To­ModelMDA Model­Driven ArchitectureMDE  Model Driven EngineeringMDR Meta­Data RepositoryMDSD Model­Driven Software DevelopmentMIC Model­Integrated ComputingMIG Model Intelligence GuideMOF Meta Object FacilityMPS Meta­Programming SystemMTV Model­Template­View (dizajn obrazac)MVC Model­View­Controller (dizajn obrazac)OAW OpenArchitectureWareOCL Object Constraint LanguageOMA Object Management ArchitectureOMG Object Management GroupOO Object­OrientedOWL  Web Ontology Language PIM Platform Independent Model

168

Definicije korišćenih skraćenica

PLPR Predikatska logika prvog redaPSM Platform Specific ModelQoS  Quality of Sevice QVT Queries/Views/TransformationsRDF  Resource Description FrameworkRDFS RDF Vocabulary Description LanguageRMI Remote Method InvocationSMOF Semantic MOFSOAP Simple Object Access ProtocolSTEP Standard for the Exchange of  Product   model   data SVG Scalable Vector GraphicsTCS Textual Concrete Syntaxes TMF Textual Modeling FrameworkUML  Unified Modeling LanguageUUID Universally Unique IdentifierWYSIWYG What You See Is What You Get XMI XML  Metadata   InterchangeXML eXtensible Markup LanguagexUML Executable UML

169

Dodatak A. Gramatika DOMMLite jezikaDOMMLiteModel:

"model" name=ID (shortDesc=STRING)? (longDesc=STRING)?((dataTypes+=UserDataType)|(constraintTypes+=ConstraintType))*(packages+=Package)*;

PackageElement:Package|Classifier;

Classifier:Entity|Service|ValueObject|Exception|DataType|ConstraintType;

DataType:BuildInDataType|UserDataType|Enumeration;

ConstraintType:ValidatorType|TagType;

ValidatorType:UserValidatorType|BuildInValidatorType;

TagType:UserTagType|BuildInTagType;

Feature:Property|Operation;

TypedElement:Feature|Parameter;

NamedElement:DOMMLiteModel|PackageElement|FeatureCompartment|OperationCompartment|EnumerationLiteral|TypedElement;

BuildInDataType:"buildinDataType" name=ID (shortDesc=STRING)? (longDesc=STRING)?;

BuildInValidatorType:"buildinValidator" name=ID

("("(parameters+=ConstraintTypeParameter)?(","parameters+=ConstraintTypeParameter)* ")")?

("appliesTo" ((appliesToEntity?="_entity") |(appliesToProperty?="_prop") | (appliesToParameter?="_param") | (appliesToOperation?="_op") |(appliesToService?="_service") | (appliesToValueObject?="_valueObject"))*)?

(shortDesc=STRING)? (longDesc=STRING)?;

BuildInTagType:"buildinTagType" name=ID

170

Dodatak A. Gramatika DOMMLite jezika

("("(parameters+=ConstraintTypeParameter)?(","parameters+=ConstraintTypeParameter)* ")")?

("appliesTo" ((appliesToEntity?="_entity") |(appliesToProperty?="_prop") | (appliesToParameter?="_param") | (appliesToOperation?="_op") |(appliesToService?="_service") | (appliesToValueObject?="_valueObject"))*)?

(shortDesc=STRING)? (longDesc=STRING)?;

UserDataType:"dataType" name=ID (shortDesc=STRING)? (longDesc=STRING)?;

UserTagType:"tagType" name=ID

("("(parameters+=ConstraintTypeParameter)?(","parameters+=ConstraintTypeParameter)* ")")?

("appliesTo" ((appliesToEntity?="_entity") |(appliesToProperty?="_prop") | (appliesToParameter?="_param") | (appliesToOperation?="_op") |(appliesToService?="_service") | (appliesToValueObject?="_valueObject"))*)?

(shortDesc=STRING)? (longDesc=STRING)?;

UserValidatorType:"validatorType" name=ID

("("(parameters+=ConstraintTypeParameter)?(","parameters+=ConstraintTypeParameter)* ")")?

("appliesTo" ((appliesToEntity?="_entity") |(appliesToProperty?="_prop") | (appliesToParameter?="_param") | (appliesToOperation?="_op") |(appliesToService?="_service") | (appliesToValueObject?="_valueObject"))*)?

(shortDesc=STRING)? (longDesc=STRING)?;

Enum ConstraintTypeParameter:string="_string"|int="_int" | ref="_ref" | ellipsis="...";

Package:"package" name=ID (shortDesc=STRING)? (longDesc=STRING)? "{"

(packageElements+=PackageElement)*"}";

Entity:"entity" name=ID

("extends" extends=[Entity])?("depends" depends+=[Service] ("," depends+=[Service])*)?

171

Dodatak A. Gramatika DOMMLite jezika

(shortDesc=STRING)? (longDesc=STRING)? "{"

key=BusinessKey("repr" repr+=ReprParameter ("+" repr+=ReprParameter)*)?("[" constraints+=ConstraintSpec (","

constraints+=ConstraintSpec)* "]")?(features+=Feature)* (featureCompartments+=FeatureCompartment)*

"}";

ReprParameter:ReprParameterStr|ReprParameterRef;

ReprParameterStr:paramValue=STRING;

ReprParameterRef:paramValue=[Property];

BusinessKey:"key" "{"

(properties+=Property)+"}";

ConstraintSpec: type=[ConstraintType] ("(" (parameters+=ConstraintParameter)?

("," parameters+=ConstraintParameter)* ")")?;

ConstraintParameter:ConstraintIntParameter|ConstraintRefParameter|ConstraintStrParameter;

ConstraintStrParameter:paramValue=STRING;

ConstraintIntParameter:paramValue=INT;

ConstraintRefParameter:paramValue = [Property];

Exception:"exception" name=ID (shortDesc=STRING)? (longDesc=STRING)? "{"

(properties+=Property)* "}";

FeatureCompartment:"compartment" name=ID (shortDesc=STRING)? (longDesc=STRING)? "{"

(features+=Feature)* "}";

Service:"service" name=ID("extends" extends=[Service])?("depends" depends+=[Service] ("," depends+=[Service])*)?(shortDesc=STRING)? (longDesc=STRING)? "{"

172

Dodatak A. Gramatika DOMMLite jezika

("[" constraints+=ConstraintSpec ("," constraints+=ConstraintSpec)* "]")?

(operations+=Operation)*(operationCompartmens+=OperationCompartment)*

"}";

OperationCompartment:"compartment" name=ID (shortDesc=STRING)? (longDesc=STRING)? "{"

(operations+=Operation)* "}";

ValueObject:"valueObject" name=ID("extends" extends=[ValueObject])?("depends" depends+=[Entity] ("," depends+=[Entity])*)? (shortDesc=STRING)? (longDesc=STRING)? "{"

("[" constraints+=ConstraintSpec ("," constraints+=ConstraintSpec)* "]")?

(properties+=Property)* "}";

Operation:"op" ( (ordered?="ordered") |

(unique?="unique") | (required?="required"))*type=[Classifier] (many?="[" (multiplicity=INT)? "]")? name=ID "("(parameters+=Parameter)?

(","parameters+=Parameter)* ")"("throws" exceptions+=[Exception]

("," exceptions+=[Exception])?)?("[" constraints+=ConstraintSpec (","

constraints+=ConstraintSpec)* "]")?(shortDesc=STRING)? (longDesc=STRING)?;

/*Atribut i referenca su objedinjeni u jedinstvenom konceptu property

*/Property:

"prop" ( (ordered?="ordered") |(unique?="unique") | (readonly?="readonly") | (required?="required") )* (containment?="+")? type=[Classifier] (many?="[" (multiplicity=INT)? "]")? name=ID ("<>" oppositeEnd=[Property])? ("[" constraints+=ConstraintSpec (","

constraints+=ConstraintSpec)* "]")?(shortDesc=STRING)? (longDesc=STRING)? ;

Parameter:( (ordered?="ordered") | (unique?="unique") |

173

Dodatak A. Gramatika DOMMLite jezika

(required?="required") )*type=[Classifier] (many?="[" (multiplicity=INT)? "]")? name=ID ("[" constraints+=ConstraintSpec

("," constraints+=ConstraintSpec)* "]")?(shortDesc=STRING)? (longDesc=STRING)?;

Enumeration:"enum" name=ID (shortDesc=STRING)? (longDesc=STRING)? "{"

(literals+=EnumerationLiteral)+"}";

EnumerationLiteral:name=ID value=STRING (shortDesc=STRING)? (longDesc=STRING)?;

174

Univerzitet u Novom Sadu Asocijacija centara za interdisciplinarne i

multidisciplinarne studije i istraživanja – ACIMSIKljučna dokumentacijska informacija

Redni broj: RBR Identifikacioni broj: IBR Tip dokumentacije: TD

Monografska dokumentacija

Tip zapisa: TZ

Tekstualni štampani materijal

Vrsta rada (dipl., mag., dokt.): VR

Magistarska teza

Ime i prezime autora: AU

Igor Dejanović

Mentor (titula, ime, prezime, zvanje): MN

Dr Branko Perišić, vanredni profesor

Naslov rada: NR

Metamodel, editor modela i generator poslovnih aplikacija

Jezik publikacije: JP

srpski (latinica)

Jezik izvoda: JI

srp. / eng.

Zemlja publikovanja: ZP

Srbija

Uže geografsko područje: UGP

Vojvodina

Godina: GO

2008

Izdavač: IZ

autorski reprint

Mesto i adresa: MA

Fakultet tehničkih naukaTrg. D. Obradovića 6, Novi Sad

175

Fizički opis rada: FO

5 / 161 / 44 / 0 / 108 / 1

Naučna oblast: NO

Primenjena informatika

Naučna disciplina: ND

Softversko inženjerstvo

Predmetna odrednica, ključne reči: PO

metamodelovanje, modelovanje, jezici specifični za domen, editori, generatori, alati

UDK Čuva se: ČU

U biblioteci Fakulteta tehničkih nauka

Važna napomena: VN Izvod: IZ

Predmet istraživanja magistarske teze spada u domen softverskog inženjerstva i razvoja jezika specifičnih za domen. Tema teze je specifikacija i implementacija jezika za modelovanje statičke strukture poslovnih aplikacija, implementacija editora modela i generatora programskog koda za ciljnu platformu.

Datum prihvatanja teme od strane NN veća: DP

Datum odbrane: DO Članovi komisije: (ime i prezime / titula / zvanje / naziv organizacije / status) KO

predsednik: dr Dušan Surla, red. prof., PMF Novi Sad

član: dr Branko Perišić, van. prof., FTN Novi Sad, mentor

član: dr Branko Milosavljević, doc., FTN Novi Sad

član: dr Milan Vidaković, doc., FTN Novi Sad

176

University of Novi Sad ACIMSI

Key word documentation

Accession number: ANO Identification number: INO Document type: DT

Monograph documentation

Type of record: TR

Textual printed material

Contents code: CC Author: AU

Igor Dejanović

Mentor: MN

Ph.D. Branko Perišić, assoc. prof.

Title: TI

Metamodel, model editor and business applications generator

Language of text: LT

Serbian (latin)

Language of abstract: LA

eng. / srp.

Country of publication: CP

Serbia

Locality of publication: LP

Vojvodina

Publication year: PY

2008

Publisher: PU

authors's reprint

Publication place: PP

Faculty of Engineering,Trg D. Obradovića 6, Novi Sad

177

Physical description: PD

5 / 161 / 44 / 0 / 108 / 1

Scientific field SF

Computer science

Scientific discipline SD

Software engineering

Subject, Key words SKW

metamodeling, modeling, domain specific languages, editors, generators, tools

UC Holding data: HD

Library of Faculty of Engineering, Trg D. Obradovi ́a 6, Novi Sad

Note: N Abstract: AB

The filed of research this thesis focuses to is software engineering and development of domain specific languages. The subject of thesis is specification and implementation of modeling language for business application's static structure description. This thesis also presents implementation of model editor and source code generator.

Accepted on Scientific Board on: AS Defended: DE Thesis Defend Board: DB

president: Full prof. Dušan Surla, PhD, Faculty of Science Novi Sad

member: Assoc. prof. Branko Perišić, PhD, Faculty of Engineering Novi Sad member: Assist. prof. Branko Milosavljević, PhD, Faculty of Engineering Novi Sad

member: Assist. prof. Milan Vidaković, PhD, Faculty of Engineering Novi Sad

178