UNIVERZITET U NOVOM SADU

PRIRODNO-MATEMATIČKI FAKULTET

DEPARTMAN ZA MATEMATIKU I INFORMATIKU

Robert Pap

Naked Objects pristup pri razvoju enterprise aplikacija

– Master rad –

Novi Sad, 2012.

PredgovorEnterprise aplikacije se i danas pretežno razvijaju po starom principu višeslojne

arhitekture, pri čemu je funkcionalnost često rasipana u više slojeva. Naked Objects pristup predstavlja nov način razvoja enterprise aplikacija. Po ovom principu najvažniji sloj je zapravo domenski sloj, i umesto da sadrži samo podatke o modelu domena, objekti ovog sloja bi trebali da budu pravi tzv. domenski objekti, što znači da bi i celokupno ponašanje tj. poslovna logika trebala da se nalazi u njima. Istovremeno, programeri ne bi trebali da puno vremena provode radeći na ostalim slojevima, prema tome, korisnički interfejs (GUI) bi trebao da se generiše automatski. Naked Objects framework je jedna od implementacija ovog pristupa.

Master rad se sastoji iz sedam poglavlja.

U prvom poglavlju dati su opis i ciljevi rada. Takođe, urađena je kratka analiza najvažnijih radova čija je tematika slična tematici ovog rada. Na kraju su navedeni svi softveri koji su se koristili za implementaciju demonstrativne aplikacije.

U drugom poglavlju su predstavljeni najvažniji elementi Domain-Driven Design-a, koji je dosta povezan sa Naked Objects pristupom. Data su njegova najvažnija načela, uključujući i principe. Poglavlje se završava navođenjem par realnih primera projekata koji koriste pogodnosti Domain-Driven Design-a, kao i sumiranjem njegovih prednosti i mana.

U trećem poglavlju je predstavljen Naked Objects pristup. Dati su njegovi suštinski elementi, a zatim su opširno opisane njegove dve važne osobine: objektno-orijentisani korisnički interfejs (OOUI) i agilnost. Poglavlje se nastavlja navođenjem nekih realnih primera, i završava se sumiranjem njegovih prednosti i nedostataka.

Četvrto poglavlje sadrži kratak opis demonstracionog primera koji će se koristiti i u narednim poglavljima. Za primer je uzeta jednostavna baza za publikacije rađena u dve verzije: u prvoj verziji se koristi klasični višeslojni, a u drugoj Naked Objects pristup. Višeslojni pristup će se implementirati u Java EJB 3, a drugi u Naked Objects framework-u.

U petom poglavlju je predstavljen Naked Objects framework. Data su najvažnija načela framework-a, kao i njegovi osnovni koncepti, kao što su entiteti, fiksture, itd.

U šestom poglavlju je urađeno detaljno upoređivanje višeslojne i Naked Objects verzije spomenutog demonstracionog primera, sa više tačaka gledišta: sa aspekta njihove globalne strukture, njihovog GUI-ja, i njihove unutrašnje implementacije. Na kraju poglavlja su navedene prednosti i mane Naked Objects framework-a.

Sedmo poglavlje sadrži zaključak rada.

Ovom prilikom se zahvaljujem svom mentoru dr Milošu Rackoviću na korisnim sugestijama i primedbama. Takođe bih želeo da se zahvalim rodbini na podršci tokom mog studiranja.

U Novom Sadu, 2012. Robert Pap

3

4

Sadržaj PREDGOVOR___________________________________________________31. UVOD______________________________________________________7

1.1. KRATAK OPIS I CILJEVI RADA 71.2. KRATKA ANALIZA RADOVA 81.3. KORIŠĆEN SOFTVER 9

2. DOMAIN-DRIVEN DESIGN_______________________________________112.1. VIŠESLOJNE ARHITEKTURE (PRVI PUT) 112.2. ŠTA JE DOMAIN-DRIVEN DESIGN? 142.3. PRINCIPI DOMAIN-DRIVEN DESIGN-A 17

2.3.1. ANALIZIRANJE ZNANJA 182.3.2. SVEPRISUTNI JEZIK 202.3.3. MODEL-DRIVEN DESIGN 23

2.4. OBRASCI DOMAIN-DRIVEN DESIGN-A 252.5. PRIMERI KORIŠĆENJA DOMAIN-DRIVEN DESIGN-A 272.6. PREDNOSTI I MANE DOMAIN-DRIVEN DESIGN-A 30

3. NAKED OBJECTS PRISTUP_______________________________________333.1. VIŠESLOJNE ARHITEKTURE (DRUGI PUT) 333.2. ŠTA JE NAKED OBJECTS PRISTUP? 363.3. OBJEKTNO-ORIJENTISANI KORISNIČKI INTERFEJS (OOUI) 393.4. AGILNOST NAKED OBJECTS PRISTUPA 43

3.4.1. VRSTE AGILNOSTI 433.4.2. SMERNICE ZA DIZAJNIRANJE I RAZVOJ SISTEMA PO NAKED OBJECTS PRISTUPU 443.4.3. ANALIZA KOMPATIBILNOSTI NAKED OBJECTS PRISTUPA SA POSTOJEĆIM RAZVOJNIM MODELIMA 48

3.5. PRIMERI KORIŠĆENJA NAKED OBJECTS PRISTUPA 553.5.1. IZRADA NAKED OBJECT ARCHITECTURE FRAMEWORK-A I SISTEMA ZA ADMINISTRACIJU DEČIJEG DODATKA ZA IRSKU VLADU 553.5.2. RAZVOJ SISTEMA ZA KOMPANIJU SAFEWAY 583.5.3. APLIKACIJA ZA PRISTUP HELSINŠKOJ BERZI 60

3.6. PREDNOSTI I MANE NAKED OBJECTS PRISTUPA 624. OPIS DEMONSTRACIONOG PRIMERA (PUBDB)_________________________655. NAKED OBJECTS FRAMEWORK___________________________________69

5.1. NEKE IMPLEMENTACIJE NAKED OBJECTS OBRASCA 695.1.1. BLUEJ IDE 695.1.2. NAKED OBJECT ARCHITECTURE 715.1.3. NAKED OBJECTS FRAMEWORK 715.1.4. NAKED OBJECTS FOR .NET 73

5.2. KONSTRUKCIJA NAKED OBJECTS FRAMEWORK-A 735.2.1. OSNOVNA NAČELA NAKED OBJECTS FRAMEWORK-A 735.2.2. VIŠESLOJNE ARHITEKTURE (TREĆI PUT) 75

5.3. ENTITETI 795.3.1. ATRIBUTI ENTITETA 79

5

5.3.2. DEFINISANJE POVEZNIKA 815.3.3. ANOTACIJE 845.3.4. AKCIJE 86

5.4. FABRIKE I REPOZITORIJE (SKLADIŠTA) OBJEKATA 895.5. FIKSTURE 915.6. JOŠ NEKI KONCEPTI NAKED OBJECTS FRAMEWORK-A 94

5.6.1. SPECIFIKACIJE 945.6.2. VREDNOSNI TIPOVI 955.6.3. SERVISI 95

6. RAZVOJ ILUSTRATIVNIH APLIKACIJA I NJIHOVO MEĐUSOBNO POREĐENJE_______976.1. VIŠESLOJNE ARHITEKTURE (ČETVRTI PUT) – STRUKTURA PUBDB-A 97

6.1.1. STRUKTURA EJB 3 VERZIJE PUBDB-A 976.1.2. STRUKTURA NAKED OBJECTS VERZIJE PUBDB-A 100

6.2. KORISNIČKI INTERFEJS PUBDB-A 1056.2.1. GUI PUBDB-A (EJB 3 VERZIJA) 1056.2.2. OOUI PUBDB-A (NAKED OBJECTS VERZIJA) 1116.2.3. DISKUSIJA 123

6.3. PERZISTENCIJA U PUBDB-U 1246.4. VIŠESLOJNE ARHITEKTURE (PETI PUT) – IMPLEMENTACIJA PUBDB-A 130

6.4.1. POREĐENJE KROZ LOC METRIKU 1306.4.2. POREĐENJE KROZ SCENARIJA 1326.4.3. DISKUSIJA 146

6.5. PREDNOSTI I MANE NAKED OBJECTS FRAMEWORK-A 1497. ZAKLJUČAK________________________________________________151 LITERATURA_________________________________________________155 KRATKA BIOGRAFIJA___________________________________________159

6

1. UvodOvo poglavlje predstavlja uvod u rad. Prvo će se dati kratak opis rada zajedno sa

definicijom ciljeva. Zatim sledi kratka analiza najvažnijih radova koji imaju sličnu tematiku kao ovaj rad, ili se bave tematikom koja nije primarni cilj ovog rada, ali se na neki način vezuje za isti. Na kraju, biće navedeni i svi softveri koji su se koristili za izradu demonstrativnih aplikacija.

1.1. Kratak opis i ciljevi radaEnterprise aplikacije se i danas pretežno razvijaju po starom principu višeslojne

arhitekture. Broj i kategorizacija ovih slojeva razlikuju se od literature do literature i od tehnologije do tehnologije. Međutim, može se reći da je najviši sloj prezentacioni sloj, zatim sledi aplikativni sloj (sa poslovnom logikom), a na dnu se nalazi sloj podataka. Problem pri razvoju aplikacija po ovom principu je to da je funkcionalnost često rasipana u više slojeva, prema tome, ako se promeni neka funkcionalnost, programeri su najčešće primorani da menjaju sve slojeve. Takođe, po mnogima, ovaj princip na neki način forsira proceduralni stil programiranja, iako se koriste objektno-orijentisani jezici. Direktna posledica ovih problema je tzv. „anemičan model domena“, tj. da su objekti samo nosači podataka, a funkcionalnost tj. ponašanje se nalazi negde drugde.

Naked Objects pristup predstavlja nov način razvoja enterprise aplikacija. Po ovom principu najvažniji sloj je zapravo domenski sloj, i umesto da sadrži samo podatke o modelu domena (nosač podataka), objekti ovog sloja bi trebali da budu pravi tzv. domenski objekti, što znači da bi i celokupno ponašanje tj. poslovna logika trebala da se nalazi u njima. Istovremeno, programeri ne bi trebali da puno vremena provode radeći na ostalim slojevima, prema tome, korisnički interfejs (GUI) bi trebao da se generiše automatski. Ovo se postiže tako što se domenski objekti iz domenskog sloja direktno preslikavaju ka prezentacionom sloju. Zapravo, GUI je po Naked Objects principu objektno-orijentisani korisnički interfejs (OOUI).

Naked Objects pristup zapravo ima dosta sličnosti sa Domain-Driven Design-om. Oba naglašavaju važnost domenskog sloja i pravih domenskih objekata. Takođe, jedan od najvažnijih principa Domain-Driven Design-a je tzv. „sveprisutni jezik“, tj. korišćenje zajedničkog jezika između programera i domenskih eksperata. Naked Objects pristup prirodno podržava ovu filozofiju, a automatski generisan GUI poboljšava komunikaciju između stranaka na vizuelni način.

Naked Objects framework je jedna od implementacija ovog pristupa za programski jezik Java.

Glavni cilj ovog rada je upravo predstavljanje Naked Objects pristupa: kako je kreator ovog pristupa došao do ideje, kako je zamišljen, koje su glavne karakteristike i mogućnosti, itd.

Naravno, potrebno je predstaviti i Domain-Driven Design. Treba napomenuti, da je ova oblast dosta napredna i komplikovana, te će se u radu navesti samo neki njeni elementi. Međutim, čak je i ovako pojednostavljeno predstavljanje ove tematike dovoljno da se uoči suština i da se da odgovor na pitanje, zašto je poželjno da ove dve oblasti „idu zajedno“.

7

Takođe, postavlja se pitanje, kako se Naked Objects pristup uklapa u modele procesa. Zato će se uraditi i analiza kompatibilnosti Naked Objects pristupa sa određenim razvojnim modelima, pre svega sa Ekstremnim programiranjem (XP). Ovo je važno radi procenjivanja agilnosti samog pristupa.

Konačno, biće predstavljen i Naked Objects framework, moćno oruđe za kreiranje Java aplikacija po Naked Objects pristupu. Kao rezultat, za demonstracione svrhe, razviće se i jednostavna aplikacija u ovom framework-u. Važan cilj ovog rada je i poređenje ove ilustrativne aplikacije sa analognom aplikacijom razvijenom po principu četvoro-slojne arhitekture (rađenom u Java EJB 3). Podrazumeva se da je radi što tačnijeg poređenja, potrebno da obe verzije aplikacije imaju manje-više isti skup funkcionalnosti. Međutim, treba napomenuti, da cilj ove demonstracije nije da se napravi složena aplikacija u Naked Objects framework-u, nego da se ilustruju različitosti između Naked Objects pristupa i principa četvoro-slojne arhitekture prvo teorijski, a zatim i na praktični način, tj. u programskom kodu.

1.2. Kratka analiza radovaPo saznanju autora ovog rada, do trenutka pisanja ovog rada ne postoji

adekvatna i sveobuhvatna literatura na srpskom jeziku ni o Naked Objects pristupu (uključujući i framework) ni o Domain-Driven Design-u. Zapravo, situacija nije baš svetlija ni na globalnoj sceni. Broj knjiga na engleskom jeziku koje se bave ovom tematikom je mali.

Najvažniji rad koji se bavi Naked Objects pristupom je zapravo doktorska teza kreatora samog pristupa: „Naked Objects“ od Richard Pawson-a (2004) [Pawson2004]. Autor na lak i razumljiv način objašnjava, kako je došao do ideje da stvori ovaj pristup, a zatim ga opisuje. Za potrebe demonstracije, Pawson je sa grupom programera uspeo da napravi i prototip koji se može koristiti za kreiranje Naked Objects aplikacija. Naked Objects framework je zapravo evolucija ovog prototipa. Pawson je dokumentovao korisnost pristupa sa programerima, menadžerima ali i sa krajnjim korisnicima uz pomoć raznih anketa. Iako je rad dosta teoretski orijentisan, napravljen prototip i rezultati anketa daju praktičnu potporu ovom pristupu.

S druge strane, Domain-Driven Design je ideja nastala od strane Eric Evans-a. Najvažnija knjiga iz ove oblasti je njegov „Domain-Driven Design: Tackling Complexity in the Heart of Software“ (2003) [Evans 2003]. Kroz knjigu, koja se zapravo može kategorisati kao knjiga o modeliranju domena, autor opisuje njegovu ideju, definiše principe (kao što je sveprisutni jezik), a zatim prelazi na detalje. Ovo poslednje se može opisati kao skup obrazaca (eng. Pattern) koji se mogu rangirati od onih koji se koriste unutar klasa do onih najviših koji se koriste u ogromnim projektima. Knjiga se može sumirati kao skup velikog broja ideja koje su vrlo opširno opisane. Međutim, mora se napomenuti da je Domain-Driven Design dosta napredna oblast i zbog toga, knjiga nije pogodna za čitaoce koji nemaju jasnog iskustva sa velikim projektima.

Konačno, knjiga „Domain-Driven Design Using Naked Objects“ od autora Dan Haywood-a (2009) [Haywood 2009] opisuje Naked Objects framework. Za razliku od prethodno opisanih radova, ova knjiga je programerska. Autor na vrlo informativan način opisuje framework i njegove delove kao što su entiteti, fiksture i servisi. Ne troši puno prostora na teorijski deo, ali ako je to potrebno, to radi na vrlo ilustrativan način.

8

Naime, kad se opisuje neki novi koncept, bilo da je reč o konceptu iz Naked Objects pristupa ili iz Domain-Driven Design-a, posle opisa sledi primena tog koncepta u aplikaciji. Prema tome, Haywood-ov rad je vrlo pragmatičan. Naravno, pored predstavljanja samog framework-a, autor ilustruje i neke naprednije ideje Domain-Driven Design-a.

Iako predstavljanje četvoro-slojne arhitekture nije primarni cilj ovog rada, poređenje iste sa Naked objects pristupom razvoja jeste. U radu će se aplikacija implementirana u Naked Objects framework-u biti poređena sa istom aplikacijom rađenoj u klasičnoj četvoro-slojnoj arhitekturi. Knjiga „EJB 3 in Action“ od grupe autora Debu Panda, Reza Rahman i Derek Lane (2007) [Panda, Rahman & Lane 2007] predstavlja odličan praktični putokaz za kreiranje programa u klasičnoj četvoro-slojnoj arhitekturi. Za razvojno oruđe, korišćen je Java EJB 3. Autori na vrlo informativan način opisuju, zbog čega je EJB 3 prava revolucija u odnosu na stari EJB 2. Posle opširnog opisa bean-ova, knjiga prelazi na perzistenciju. Naravno, nisu izostavljene ni neke napredne teme, kao što su pakovanje, deployment i skalabilnost velikih projekata.

Budući da je važan cilj ovog rada i poređenje ilustrativne aplikacije razvijene po Naked Objects pristupu sa analognom aplikacijom razvijenom po principu četvoro-slojne arhitekture, treba spomenuti da su slična poređenja rađena i u [Pawson 2004], kao i u [Keränen & Abrahamsson 2005a] i [Keränen & Abrahamsson 2005b]. Iako se može smatrati da su aplikacije razvijene u ovim radovima naprednije i složenije u odnosu na demonstracioni primer koji se razvio za potrebe ovog rada, načini poređenja su drugačiji. U [Pawson 2004] se koristi LOC metrika (broj linija izvornog koda) za poređenje Naked Objects verzije aplikacije sa četvoro-slojnom verzijom, ukratko je prikazan i njihov GUI, ali se fokus zapravo stavlja na procenjivanje težine proširenja razvijenih aplikacija sa novom funkcionalnošću. S druge strane, članci [Keränen &Abrahamsson 2005a] i [Keränen & Abrahamsson 2005b] opisuju jedan primer ali sa različitim ciljevima: prvi istražuje agilnost Naked Objects pristupa sa ekstremnim programiranjem, a drugi istražuje LOC metriku i način razvoja (npr. vreme trajanja razvoja pojedinačnih korisničkih zahteva kao i njihovu težinu, itd.). Za razliku od ovih radova, u ovom master radu će se fokus staviti na poređenje GUI-ja razvijenih aplikacija, kao i na poređenje njihove unutrašnje implementacije kroz neka scenarija (naravno, biće spomenuti i neki drugi načini poređenja, npr. LOC metrika). Upoređivanje kroz GUI i kroz unutrašnju implementaciju nedostaje u prethodno navedenim radovima, ali po mišljenju autora ovog rada, omogućava dublje shvatanje suštinske razlike između Naked Objects i klasičnog višeslojnog pristupa.

1.3. Korišćen softverU poslednjem delu ovog uvodnog poglavlja biće malo više reči o softveru koji se

koristio za izradu obe verzije demonstrativne aplikacije.

Obe verzije programa su pisane u Javi, i to u verziji 6 sa update-om 29 <http://www.oracle.com/technetwork/java/javase/overview/>, a za razvojno okruženje koristio se besplatni i otvoreni Eclipse IDE for Java EE (verzija: Indigo v3.7.0) <http://www.eclipse.org/>. Za merenje broja linija izvornog koda (LOC) koristio se besplatni i otvoreni Eclipse Metrics plugin v1.3.8 <http://sourceforge.net/projects/metrics2/>.

9

Što se tiče EJB 3 verzije aplikacije (za prikaz četvoro-slojne arhitekture), koristio se još i niz drugih softvera. Pošto aplikacija komunicira sa lokalnom relacionom bazom podataka, bilo je potrebno instalirati i neki aplikativni server. U ovom slučaju, izbor je pao na besplatni i otvoreni JBoss Application Server v5.1.0.GA od kompanije Red Hat <http://www.jboss.org/jbossas/>. Za relacionu bazu podataka koristio se slobodno dostupan MySQL Community Edition v5.5.20 kompanije Oracle <http://www.mysql.com/products/community/>. Za upravljanje MySQL servera koristio se slobodno dostupan MySQL Workbench v5.2.37, takođe od Oracle <http://www.mysql.com/products/workbench/>. Na kraju, za kreiranje Swing grafičkog korisničkog interfejsa za aplikaciju, koristio se besplatni WindowBuilder Pro v1.2.0 od kompanije Google (kao plug-in za Eclipse IDE) <http://marketplace.eclipse.org/content/windowbuilder-pro-gui-designer/>.

Što se tiče Naked Objects verzije aplikacije koristila se neka druga grupa softvera. Pre svega, za pojednostavljeno pravljenje i podešavanje Java softvera koristio se Maven v2.2.1 od Apache <http://maven.apache.org/>. Maven ima šablon (eng. Template) za kreiranje Naked Objects projekata, prema tome njegovo korišćenje se toplo preporučuje. Za povezivanje Maven-a sa Eclipse IDE koristio se m2e v1.0.100 plug-in <http://marketplace.eclipse.org/content/maven-integration-eclipse/>. Konačno, za framework koristio se besplatni i otvoreni Naked Objects v4.0 <http://sourceforge.net/projects/nakedobjects/>. Mora se napomenuti da instaliranje ovog poslednjeg uopšte nije neophodno, jer sve što je potrebno se već nalazi u Maven-u, ali je ipak odlučeno da se instalira, jer sadrži neke primere, ikonice koje se mogu slobodno koristiti u programima, kao i neke korisne alate za Eclipse IDE.

Svi dijagrami u ovom radu su pravljeni u Modelio v2.1.1, besplatnom i otvorenom alatu za UML 2 modeliranje, odnosno u LibreOffice Draw v3.4.5, besplatnom i otvorenom alatu za crtanje. Ovi projekti se mogu naći na <http://www.modelio.org/> i <http://www.libreoffice.org/>, respektivno. Sam rad je pisan u LibreOffice Writer v3.4.5.

10

2. Domain-Driven DesignPre nego što se pređe na opis Naked Objects pristupa, trebalo bi predstaviti i

osnove Domain-Driven Design-a, tj. dizajna usredsređenog ka domenu. Prvo će se opisati njegova suština, a zatim će biti predstavljeni i principi Domain-Driven Design-a. Nekoliko reči će biti i o obrascima (eng. Patterns) koji se vezuju za ovu filozofiju. Na kraju poglavlja će biti razmatrani realni primeri projekata koji su iskoristili pogodnosti Domain-Driven Design-a za postizanje svojih ciljeva, kao i prednosti i mane istog. Međutim, prvo se mora osvrnuti i na višeslojne arhitekture, koje predstavljaju osnovu za razvoj poslovnih aplikacija.

2.1. Višeslojne arhitekture (prvi put)Većina ljudi bi se složila da pravljenje enterprise aplikacija uopšte nije lak posao.

Ovakve aplikacije najčešće imaju veliki broj komponenata, i moraju zadovoljiti potrebe mušterija (tj. klijenata). Međutim, iako je svaka enterprise aplikacija unikatna pošto mora rešiti jedinstven skup problema, može se reći da one imaju i određen nivo sličnosti. Naime, većina njih ima neku vrstu korisničkog interfejsa, implementira poslovne procese, modelira domen problema i pristupa nekim vrstama bazama podataka. [Panda, Rahman & Lane 2007]

Postavlja se pitanje, šta bi se desilo ako bi svi ti delovi aplikacije bili nabacani u neku celinu? Poslovni objekti bi tada sadržali i programski kod za korisnički interfejs, ali i za baratanje bazama podataka. Međutim, u tom slučaju, izgubila bi se preglednost i stabilnost aplikacije. Svaka promena u bilo kom delu programa bi se skupo platila, što zbog teškoće pronalaženja traženog dela u izvornom kodu, što zbog talasnog efekta tj. rizika da najmanja modifikacija rezultuje ozbiljnim promenama u celom kodu. [Evans2003] Sem ako je kompleksnost domena trivijalna, ovakav način razvoja bi samo uveo haos u aplikaciju.

Za rešavanje navedenog problema dovoljno je da se iskoristi činjenica o prethodno spomenutim sličnostima između enterprise aplikacija. Ovako su nastale višeslojne arhitekture. Prvo formulisane kao arhitektonski obrazac (eng. Architectural Pattern)1 od strane Kyle Brown-a u članku iz 1995. pod nazivom „Remembrance of Things Past: Layered Architectures for Smalltalk Applications“ [Pawson 2004], višeslojne arhitekture su danas veoma popularne, a koncept grupisanja u slojeve je većini programera intuitivan i podrazumevan. [Evans 2003] Nazivajući obrazac kao „Slojevi“ (eng. Layers), Frank Buschmann ga definiše na sledeći način:

„Arhitektonski obrazac pod nazivom Slojevi pomaže u struktuiranju aplikacija koje se mogu razložiti u grupe podzadataka, pri čemu se svaka grupa podzadataka nalazi na određenom nivou apstrakcije.“ [Buschmann et al. 1996]

1 Softverske arhitekture su pravljene u skladu sa određenim principima struktuiranja. Po Frank Buschmann-u, ovi principi su opisani upravo arhitektonskim obrascima. Po njegovoj definiciji, „arhitektonski obrazac izražava osnovnu strukturnu organizacionu šemu za softverske sisteme. Obezbeđuje skup predefinisanih podsistema, određuje njihove odgovornosti, i obuhvata pravila i smernice za organizovanje odnosa među njima.“ Prema tome, arhitektonski obrasci su zapravo šabloni za konkretnu softversku arhitekturu, i pomažu pri struktuiranju softverskih sistema u podsisteme. Ovi obrasci se nalaze na najvišem nivou apstrakcije. [Buschmann et al. 1996]

11

U skladu sa definicijom, srodne koncepte treba grupisati u slojeve i jasno naznačiti granice među njima, a zatim te slojeve treba staviti jedan na drugi. Ako se pretpostavi da su ti slojevi sloj 1, sloj 2, … sloj n, pri čemu se sloj 1 nalazi na najnižem nivou apstrakcije, a sloj n na najvišem, onda mora da važi da servisi sloja sloj i zavise samo od servisa sloja sloj i-1. Iz ovoga sledi da servise sloja sloj i mogu koristiti samo servisi sloja sloj i+1. Na ovo još treba dodati da servisi sloja sloj i mogu koristiti i servise istog sloja.

Ovaj obrazac se najčešće koristi na „od-gore-na-dole“ (eng. top-down) način. Ako se pretpostavi da korisnik sistema (tj. klijent) pristupa najvišem nivou (sloj n), taj sloj će njegov zahtev proslediti prvom sloju ispod: sloju sloj n-1. Zatim će sloj n-1 zahtev proslediti sloju sloj n-2, itd., sve dok se ne stigne do sloja sloj 1.2 Konačno, sloj 1 obrađuje zahtev, i ako je potrebno, vraća povratnu vrednost (tj. rezultat) izvršavanja nazad ka višim slojevima (najčešće do sloja sloj n).3

Može se primetiti da je sam obrazac dosta strog, jer omogućava komunikaciju samo unutar samog sloja i sa direktnim susedom nadole. Zato je i izmišljen relaksiran slojevit sistem (eng. Relaxed Layered System). Ova varijanta omogućava komunikaciju određenog sloja sa svim slojevima ispod, znači sloj i može da komunicira ne samo sa slojevima sloj i i sloj i-1, nego i sa slojevima sloj i-2, … sloj 1.

Informacioni sistemi enterprise aplikacija masovno koriste ovaj obrazac. Ovi sistemi su na početku bili grupisani u dva sloja: u niži sloj nazvan sloj podataka (eng. Database Layer) gde se nalazi neka vrsta baze podataka, i u viši sloj pod nazivom aplikativni sloj (eng. Application Layer), gde se nalaze aplikacije. Klasični klijent-server sistemi su često koristili ovakvu dvo-slojnu arhitekturu. Međutim, zbog uskog vezivanja korisničkog interfejsa sa bazom, predstavljen je treći sloj između ova dva sloja: domenski sloj (eng. Domain Layer) radi modeliranja domena problema. Tako su nastale tro-slojne arhitekture. Pošto je najviši sloj još uvek kombinovao korisnički interfejs sa poslovnom logikom, i ovaj sloj je bio podeljen na dva dela: na prezentacioni sloj (eng. Presentation Layer, User Interface Layer) i na uži aplikativni sloj, tj. sloj poslovne logike (eng. Application Layer; Application Logic Layer; Business Logic Layer), i tako su nastale četvoro-slojne arhitekture. [Buschmann et al. 1996]

Međutim, ova podela uopšte nije fiksna, pa razne filozofije, metodologije i tehnologije koriste različite varijacije višeslojne arhitekture, i njihovi autori to javno priznaju. O raznovrsnosti višeslojnih arhitektura mogu svi da se uvere jednostavnim prelistavanjem stručne literature. Tako na primer, Eric Evans, autor Domain-Driven Design-a definiše sledeću podelu: [Evans 2003]

1. Sloj korisničkog interfejsa ili prezentacioni sloj (eng. User Interface Layer; Presentation Layer) – zadužen za prikazivanje raznih informacija korisniku kao i za interpretaciju korisničkih naredbi. Korisnik u ovom slučaju ne mora biti

2 Treba napomenuti da većina slojeva ne samo da prosleđuje zahtev sledećem sloju ispod, nego ga i obrađuje na neki način. Takođe, sasvim je normalno, da će određeni servisi nekog sloja razbiti zahtev na više manjih, pa će svi ti podzahtevi ići različitom putanjom.

3 Pored „od-gore-na-dole“ načina postoje i drugi načini korišćenja, npr. „od-dole-na-gore“ (eng. down-top) koji se bavi notifikacijama (umesto obrađivanja zahteva od strane klijenta). U ovom slučaju komunikacija počinje od najnižeg sloja (sloj 1) i kreće se nagore ka sloju sloj n. Naravno postoje i razne varijacije ovih načina: u nekim situacijama je dovoljno posmatrati samo neki podskup slojeva: npr. nije uvek potrebno da zahtev putuje do najnižeg sloja (sloj 1), ako sloj i (koji se nalazi između slojeva sloj n i sloj 1) može obraditi zahtev.

12

čovek, može biti i drugi sistem.

2. Aplikativni sloj (eng. Application Layer) – definiše softverske poslove i upravlja objektima domena radi rešavanja poslovnih problema.

3. Domenski sloj (eng. Domain Layer) – sadrži poslovne koncepte i pravila, tj. model domena. Ovaj sloj predstavlja srce poslovnog softvera. Evans ističe da je teorijski gledano, domenski sloj jedini koji mora da postoji. Drugim rečima, Domain-Driven Design ne zahteva postojanje ostalih slojeva.

4. Infrastrukturni sloj (eng. Infrastructure Layer) – strogo tehnički sloj sa zadatkom davanja raznih usluga višim slojevima: slanje poruka, mehanizam za čuvanje podataka (tj. perzistencija), itd.

Inače, Evans ostavlja mogućnost proširenja, sužavanja i kombinovanja slojeva, ali ističe da višeslojne arhitekture nemaju puno smisla ukoliko se ne definišu granice između slojeva. Prema tome, slojevi se moraju jasno izolovati od drugih. [Evans 2003]

Drugi autori pak koriste drugačije podele ili koriste druge nazive za određene slojeve. Na primer, u [Läufer 2008] su uočeni sledeći slojevi: prezentacioni sloj, kontroler (eng. Controller), domenski sloj i perzistentni sloj (eng. Persistence Layer). U ovom slučaju, kontroler sloj predstavlja manje-više isti koncept kao i aplikativni sloj kod Evans-a i Buschmann-a, dok je perzistentni sloj zapravo drugačiji naziv za sloj podataka kod Buschmann-a. Međutim, poslednji, perzistentni sloj može biti zanimljiv. Naime, pošto perzistencija generalno rečeno označava sposobnost zadržavanja tj. čuvanja podataka u bazama podataka, mnogi autori naizmenično koriste oba termina za najniži sloj, i to je u redu dok se baze podataka i mehanizmi zadržavanja u tim bazama nalaze u istom sloju.4 Međutim, kad se umesto generičkih višeslojnih arhitektura posmatraju arhitekture nametnute od strane tehnologija, situacija se donekle menja. Naime, perzistencija je kod modernih tehnologija mnogo lakša za korišćenje, i to zahvaljujući modernim mehanizmima za mapiranje objektnih podataka u relacione podatke. Ovaj mehanizam se naziva objektno-relaciono mapiranje (eng. Object-Relational Mapping, O/R Mapping, skraćeno ORM). [Mehta 2008] Pošto se moderne ORM tehnologije nalaze na višem nivou apstrakcije (u odnosu na stare tehnologije za perzistenciju), često vredi razdvojiti do sada jedinstven niži sloj na dva posebna sloja: na perzistentni sloj i na sloj podataka, pri čemu se perzistentni sloj nalazi iznad sloja podataka.

Upravo se ovo dešava kod Java Enterprise JavaBeans 3 (EJB 3). Kod EJB 3, mogu se uočiti sledeći slojevi [Panda, Rahman & Lane 2007]: prezentacioni sloj, sloj poslovne logike (srce softvera), perzistentni sloj i sloj podataka. Pažljivi čitaoci će primetiti dve zanimljivosti. Prvu, naglasak tj. srce softvera je ovde stavljeno na sloj poslovne logike (kod Evans-a, srce softvera se nalazi u domenskom sloju). Drugu, čini se da ova četvoro-slojna arhitektura ni nema domenski sloj. Zapravo postoji i ovde domenski sloj, ali se naziva perzistentni sloj, istina sa određenim razlikama. Naime, perzistentni sloj po [Panda, Rahman & Lane 2007] sadrži ne samo model domena nego i naredbe za perzistenciju (preciznije rečeno, ORM) uz pomoć raznih anotacija.

4 Šta više, kao što se može videti, Evans proširuje sloj sa još nekim drugim tehničkim servisima, kao što je mehanizam za slanje poruka, itd. Zato naziva ovaj sloj infrastrukturnim.

13

Ostaje još pitanje, kako Naked Objects pristup gleda na višeslojne arhitekture. Ukratko rečeno, ovaj pristup takođe prihvata postojanje i važnost ovih slojeva, ali ih smatra problematičnim. Kao rešenje, ovaj pristup nudi mogućnost automatizacije određenih slojeva, pre svega viših (prezentacioni i kontrolni sloj). Kao jedini i najvažniji sloj, ostaje domenski sloj. Ovo je zapravo jedan od najvažnijih principa Naked Objects pristupa. [Pawson 2004] Takođe, ukoliko se odluči da se koristi relaciona baza podataka, Naked Objects framework se može proširiti ORM tehnologijom, i u tom slučaju se naredbe za ORM pišu u domenskom sloju (slično kao i kod EJB 3). [Haywood 2009]

Više reči o višeslojnim arhitekturama biće i u narednim poglavljima, gde će se detaljnije analizirati problematika ovog koncepta, i kako Naked Objects pristup želi da reši problem.

2.2. Šta je Domain-Driven Design?Smatra se da nema razvoja softvera bez izazova. Projekti – stari i novi – su

stalno izloženi raznim izazovima zbog kojih projekat lako može „iskliznuti iz šina“: birokratski pritisci, pogrešno formiran tim, problemi sa korišćenim tehnologijama, pogrešno shvaćeni zahtevi klijenata, pogrešna metodologija razvoja, itd. Što je projekat kompleksniji, to je veća verovatnoća da će nešto poći kako ne treba. Neki izvori kompleksnosti su tehničke prirode. [Evans 2003] Ljudima je trebalo dosta vremena da reše razne tehničke probleme, kako da npr. baze podataka rade brzo i pouzdano, da mreže budu sigurne, da programski jezici budu funkcionalni i korisni, itd. Kompanije su uložile jako puno napora za rešavanje ovih problema, i danas one nude kompletna rešenja koja mogu stvarno olakšati razvoj softvera.5

Međutim, izazovi pri razvoju ni posle ovih napredaka na polju tehnoloških rešenja nisu jenjavali. Ovo je primetio i Eric Evans, radeći na velikom broju projekata. Od tih, mnogi projekti su propali ili su dali minorne rezultate, iako su imali pristup najboljim tehnološkim rešenjima. Zapravo, problem je ležao negde drugde: u samom domenu. Mnogi su kompleksnost domena stavili u drugi plan. Najproblematičniji projekti su bili upravo oni koji su imali sumnjiv domenski dizajn. Ovo je nateralo Evans-a da proba da ispravi probleme tamo „gde najviše boli“. Sakupljajući ideje i dokazana rešenja koja su dala dobre rezultate, stigao je do nečega što je nazvao Domain-Driven Design (na srpskom dizajn usredsređen ka domenu, ili domen-vođen dizajn, skraćeno DDD). Posle četiri godine pisanja, 2003. godine je izdao i svoju knjigu na ovu temu pod nazivom „Domain-Driven Design: Tackling Complexity in the Heart of Software“. [Evans 2003]

U prethodnom pasusu je namerno korišćen termin nečega. Naime, na prvi pogled je dosta teško reći šta je zapravo DDD. Po [Wesenberg, Landre & Rønneberg2006], DDD nije ni tehnologija, niti metodologija. Po Evans-u, DDD je zapravo način razmišljanja i skup prioriteta. [Evans 2003] Može se takođe reći da je DDD jedna filozofija za razvoj softvera. [Wesenberg, Landre & Rønneberg 2006] [Mehta 2008]

Cilj DDD-a je da ubrza i poboljša razvoj softverskih projekata čiji su domeni

5 Šta više, neki smatraju da je ponuda danas već prevelika. U skoro svim oblastima postoji veliki broj rešenja i svi nude nešto što fali kod konkurencije, ali ovim se stavlja dodatni teret na ramena programera (i drugih koji su uključeni u razvoj), pošto je izbor mnogo veći, a kvalitet nije nužno bolji. Takođe, pamtiti razlike među konkurentnim rešenjima je postao novi izazov. [Haywood 2009]

14

komplikovani. [Evans 2003]

Već nekoliko puta je spomenut pojam domena, prema tome sad bi bila odlična prilika da se opiše tačno značenje ove reči. Evans ga definiše na sledeći način:

„Domen (eng. Domain) je sfera (ili delokrug) znanja, dejstava ili aktivnosti.“6 [Evans2003]

On još takođe ističe da pošto je svaki softver povezan sa aktivnostima njegovih korisnika ili ima korist za njegove korisnike, oblast na koju korisnik primenjuje posmatrani program je zapravo domen softvera. Naravno različiti autori daju nešto drugačiji opis za ovaj pojam. Tako na primer Vijay P. Mehta smatra da je domen zapravo problem koji se pokušava rešiti uz pomoć programa. [Mehta 2008]

Domen softvera može biti bilo šta. U nekim slučajevima domen uključuje fizički svet, kao što je softver za rezervisanje avionskih karata. Međutim, u nekim drugim slučajevima domen uključuje neopipljiv ili apstraktni svet, na primer domen računovodstvenog programa su novac i finansije. [Evans 2003]

Takođe, potrebno je dati i definiciju za pojam modela. Evans ga definiše na sledeći način:

„Model je sistem apstrakcija koji opisuje odabrane aspekte domena i može se koristiti za rešavanje problema koji se vezuju za taj domen.“ [Evans 2003]

Slično kao i kod prethodnog pojma, drugi autori daju nešto drugačije opise. Tako ga na primer, Dan Haywood definiše kao „skup povezanih koncepata“7, a na pitanje, šta bi trebalo da se nalazi u modelu, on odgovara da to zavisi od postavljenih ciljeva. Naime, modelirati sve što se nalazi u stvarnom svetu je praktično nemoguće, ali s druge strane, nije ni potrebno. Umesto toga, dovoljno je posmatrati samo delove tog sveta, i vezati ih tako da budu korisni za postavljen problem. Zapravo, po Haywood-u, ni ne postoji model koji je dobar ili loš, nego samo model koji je manje ili više koristan. Prema tome, ključna reč je zapravo simplifikacija tj. uprošćavanje, pojednostavljanje. [Haywood 2009]

Evans takođe ističe važnost simplifikacije, smatrajući da je model zapravo jedna simplifikacija. Naime, za razvoj softvera koji adekvatno rešava problem korisnika, potrebno je često uključiti i ogromnu količinu znanja. Cilj modela je da smanji količinu i kompleksnost ovog znanja, i predstavlja interpretaciju stvarnosti koja apstrahuje aspekte relevantne za rešavanje problema i ignoriše suvišne detalje. [Evans 2003]

Umesto da definiše pojam modela, Jimmy Nilsson koristi drugačiji pristup. Naime, on smatra da je ovaj termin u softverskom svetu preopterećen, pa je bolje umesto definicije navesti osobine ovog pojma. Prema tome, model je: [Nilsson 2006]

• parcijalan (tj. delimičan),

• za određen cilj,

• sistem apstrakcija,

6 Ova definicija zapravo potiče od Merriam-Webster Online rečnika, i može se proveriti na adresi: <http://www.merriam-webster.com/dictionary/domain>.

7 Haywood takođe upozorava da UML dijagrami kao što su dijagrami klasa, nisu modeli. Oni su zapravo vizuelne reprezentacije nekog aspekta modela. [Haywood 2009]

15

• kognitivni alat8.

On još takođe ističe, da model ima razne reprezentacije (kao što su govorni jezik, programski kod ili razni dijagrami) i da neki sistem najčešće ima više modela u igri. [Nilsson 2006] Nilsson-ov način predstavljanja pojma modela je inače u potpunosti u skladu sa prethodno iznetim tvrdnjama od strane drugih autora.

Za realni primer modela mogu se navesti geografske karte. One su modeli, jer svaki model predstavlja neki aspekt stvarnosti. [Evans 2003] Zaista, na geografskim kartama su označene samo one informacije koje su relevantne za rešavanje problema, odnosno koje imaju korist za korisnika. Na primer, reljefne karte označavaju terenske aspekte zemlje (planine, ravnice, itd.), državne karte opisuju granice između država, karte za stanovništvo opisuju populaciju, gradove, broj stanovništva gradova, itd.

Pošto su definisani pojmovi domena i modela, može se preći i na definiciju modela domena. Iskreno rečeno, model domena je takođe jedan obrazac, opširno opisan od strane Martin Fowler-a, koji ga definiše na sledeći način:

„Model domena (eng. Domain Model) je objektni model domena koji uključuje, tj. kombinuje i ponašanje i podatke.“ [Fowler et al. 2002]

Fowler ističe da domen, koji se modelira, sadrži ne samo poslovne podatke, nego i poslovna pravila. Pošto objektna-orijentisanost tako vešto kombinuje i podatke i ponašanje, najbolje ih je kombinovati. Model domena bi trebao da bude sličan sa modelom baze podataka, ali i različit. Razlog za ovu tvrdnju Fowler vidi u činjenici da su objektna-orijentisanost i relacione baze podataka dve različite paradigme: ne samo da neka svojstva kod jedne paradigme ne postoje kod druge, nego su i načini shvatanja različiti, na primer nešto što je kod jedne paradigme dobra praksa, kod druge se izbegava. U svakom slučaju, model domena bi trebao da se nalazi u domenskom sloju, i zato spada u grupu obrazaca za domenski sloj (eng. Domain Logic Pattern).9 [Fowler etal. 2002]

Mehta se slaže sa prethodnim izlaganjima, ali dodaje da je model domena u današnje vreme postao više od pukog obrasca. Naime, model domena nije samo

8 Model je kognitivni alat, odnosno alat za obradu informacija, zato što uključuje moždane aktivnosti, kao što su razumevanje, donošenje odluka, rešavanje problema, itd.

9 Model domena nije jedini obrazac za domenski sloj. Pored ovog, Fowler definiše još dva obrasca u ovoj grupi: transakcionu skriptu i tabelarni modul.Transakciona skripta (eng. Transaction Script) organizuje poslovnu logiku u procedure ili metode, pa svaka procedura obrađuje po jedan zahtev iz prezentacionog sloja.Tabelarni modul (eng. Table Module) je sličan modelu domena u smislu organizovanja koncepata u klase, ali dok kod modela domena svaka instanca te klase predstavlja po jednu individualnu pojavu, kod tabelarnog modula postoji samo jedna instanca klase koja predstavlja sve pojave tog koncepta. Na primer, ako se posmatra klasa Knjiga, jedna instanca te klase kod domena modela će biti jedna individualna knjiga (tj. jedan red u tabeli u bazi podataka), a kod tabelarnog modula, jedna instanca te klase će sadržati sve knjige (tj. celu tabelu Knjiga u bazi podataka). Kod tabelarnog modula identitet ne postoji implicitno, nego eksplicitno, prema tome, nekoj knjizi se može pristupiti uz id broj te knjige koji se prosleđuje instanci te klase kao parametar, npr. za dobijanje naziva knjige sa id-om 17, poziv bi mogao da izgleda ovako: knjiga.getNaziv(17). [Fowler et al. 2002]Može se primetiti da sva tri obrasca forsiraju određen stil programiranja: transakciona skripta forsira proceduralni stil programiranja, model domena objektno-orijentisani stil, a tabelarni modul relacioni stil.

16

zajednički model za predstavljanje neke oblasti, nego i zajednički rečnik za komunikaciju među učesnicima u razvoju. [Mehta 2008] Evans ističe, da UML dijagrami nisu modeli domena, nego ideja koja se nalazi u njima. Analogno, ni ogromno znanje u glavi domenskih eksperata se ne može okarakterisati kao model domena, nego „rigorozno organizovana i selektivna apstrakcija tog znanja“. [Evans 2003]

Posle ovih izlaganja više nije čudno, zašto stavlja DDD akcenat na domen, model i model domena. [Mehta 2008] [Nilsson 2006] [Haywood 2009] Srce softvera se nalazi u domenskom sloju, odnosno u veštini rešavanja problema domenskog karaktera za korisnike tog softvera. Ovo nije nimalo lak poduhvat, naročito kad je domen komplikovan, i zahteva zajedničko angažovanje celog razvojnog tima. Problem je u tome što se prioriteti razvoja često nalaze negde drugde. [Evans 2003] Kako Nilsson objašnjava, DDD se bavi „premošćavanjem raskoraka“ tj. rupa, npr. između programera i klijenata, između samog dizajna i programskog koda, itd. [Nilsson 2006] O ovome će detaljno biti reči u sledećem delu poglavlja.

Do sada nije data definicija za DDD, pre svega zato što sveobuhvatna definicija ni ne postoji. Međutim, posle raznih izlaganja u ovom delu poglavlja, može se zaključiti sledeće: „Domain-Driven Design je jedan način razmišljanja, filozofija i skup prioriteta za razvoj poslovnog softvera, koji se fokusira na model domena radi rešavanja problema. Kao oruđe, DDD koristi dobro prihvaćen skup principa i obrazaca.“ Još jedan razlog za nepostojanje adekvatne i sveobuhvatne definicije može biti i činjenica da sam DDD ne predstavlja ništa novo i revolucionarno. Zapravo skoro sve što se nalazi unutar DDD-a je već prethodno izmišljeno i opisano, ali DDD ove ideje kombinuje na vešt način radi razvijanja bogatog, dubokog i korisnog softvera. [Haywood 2009]

U prethodnoj „definiciji“ su još spomenuti principi i obrasci. Principi DDD-a služe za kreiranje jednog funkcionalnog „okruženja“ za model domena, a obrasci služe za dizajniranje modela tako da on bude u skladu sa domenom. U sledećem delu ovog poglavlja će biti detaljno predstavljeni principi DDD-a.

2.3. Principi Domain-Driven Design-aKao što je bilo spomenuto u prethodnom delu poglavlja, u Domain-Driven

Design-u se fokus mora staviti na model domena, ali kao što se zna, to nije nimalo lak zadatak. Lutanje bez cilja nadajući se da će se model domena sam kreirati neće dati rezultate, a ako i hoće, put će sigurno biti dugačak i preskup. Zato se pridržavanje nekih generalnih smernica koje su se pokazale korisnim, smatra dobrom praksom. Ove smernice se mogu grupisati u sledeće kategorije: [Evans 2003]

1. Pre svega, potrebno je znanje domenskog eksperta pretvoriti u nešto korisno, tj. u model. Za postizanje ovog cilja treba na neki način analizirati znanje.

2. Potrebno je naći jezik koji će svi ljudi razumeti i koji će biti osnova za komunikaciju. Drugim rečima, potrebno je naći neki sveprisutni jezik koji će se koristiti čak i za modeliranje domena.

3. Konačno, potrebno je model nekako pretvoriti u programski kod. Za postizanje ovog cilja potrebno je naći vezu između modela i implementacije, odnosno treba dizajnirati tako da to bude usredsređeno ka modelu.

17

Poštovanje ovih smernica i putokaza daju potporu razvoju softvera sa bogatom funkcionalnošću. Pošto su ove smernice s jedne strane toliko univerzalne, a s druge, sveprisutne (koriste se u celom životnom ciklusu), one se mogu doživeti i kao principi Domain-Driven Design-a.10

U nastavku će se detaljno opisati prethodno spomenuti principi.

2.3.1.Analiziranje znanjaU starom klasičnom vodopadnom modelu domenski eksperti nisu komunicirali

sa programerima, a ni programeri sa domenskim ekspertima. Između ove dve grupe nalazili su se analitičari koji su komunicirali sa domenskim ekspertima, dobijene informacije su apstrahovali u model, a na kraju su taj model (u vidu dijagrama) prosledili programerima radi implementacije. [Haywood 2009] Problem pri ovom načinu razvoja je bio nepostojanje povratne sprege. Programeri nisu model u potpunosti ni razumeli, a često se i dešavalo da ni ne mogu taj model da pretvore u programski kod zbog raznih tehničkih problema. [Evans 2003] Iako je klasični vodopadni model postao prevaziđen zahvaljujući modernijim metodologijama razvoja, problemi još uvek postoje.

U iterativnim metodologijama razvoja već postoji komunikacija između domenskih eksperata i programera. Međutim, čest problem je to da programeri nisu zainteresovani za domen. Strah je uglavnom opravdan, jer domenski eksperti ih bombarduju (često suvišnim) informacijama, a programeri „uzvraćaju udarac“ korišćenjem tehničkih izraza koje samo oni razumeju. Međutim, nema istinskog i korisnog domenskog modela bez kompromisa. S jedne strane, programeri moraju da se upuštaju u domen. S druge strane, domenski eksperti treba da daju sve od sebe da objasne sve ono što je važno u problematici.11 Ključna reč je na simplifikaciji, jer treba objasniti samo ono što je važno za rešavanje problema, i to na jednostavan i razumljiv način. [Evans 2003] Ovo će sa jedne strane navesti programere da pričaju „prirodno“ bez upuštanja u tehničke stvari, a s druge strane će domenski eksperti, koji umeju da zakomplikuju stvari, shvatiti da za rešavanje problema nije potrebno celokupno znanje, već samo deo, a takođe će ih navesti da komplikovane termine pojednostave. Uostalom, kao što je već rečeno, model je simplifikovano i selektivno znanje.

Naravno, modeliranje ne bi trebalo da bude samostalna aktivnost, nego grupna. Ceo tim, bez obzira na uloge, treba da sedi zajedno, i da zajedno analizira znanje. Analiziranje znanja (eng. Knowledge Crunching) predstavlja aktivnost traženja nekog rešenja iz skupa informacija. Ideje se organizuju i kombinuju, traže se veze između njih, rade se eksperimenti, itd. Cela aktivnost najviše liči na brainstorming sesije. Sirovi materijal tj. informacije dolaze najčešće od domenskih eksperata, ali i iz drugih izvora: od korisnika postojećih programa, iz iskustva programera sa sličnim projektima, iz pisanih dokumenata, i iz same konverzacije. Cilj je naravno kreiranje i oblikovanje

10 Haywood ih naziva centralnim idejama DDD-a. [Haywood 2009]11 Preporučuje se da domenski eksperti nauče i bar nešto iz UML-a uz pomoć programera, jer će model

najčešće poprimiti vizuelni oblik, znači neki dijagram (ili skup dijagrama), a dijagrami su ionako odličan način komunikacije. Pojednostavljeni dijagrami klasa su najčešće dovoljni. [Evans 2003] Više o dijagramima će biti u opisu sledećeg principa.

18

modela. [Evans 2003] A pošto je model zapravo rezultat timskog rada, može se pretpostaviti da će on zadovoljiti potrebe: pošto su programeri učestvovali u izradi, model će biti u stanju da se implementira; s obzirom da su i analitičari učestvovali, model će imati dobru strukturu i lepu organizaciju koncepata; a pošto su i domenski eksperti učestvovali, model će odražavati duboku apstrakciju domena i zadovoljiti potrebe korisnika.

Analiziranje znanja je stalna aktivnost, jer se koristi u celom životnom ciklusu projekta: novi koncepti se stalno uključuju u model, a često se dešava i obrnuta aktivnost, tj. izbacivanje postojećih ideja iz modela. Ovo stalno modifikovanje, oblikovanje modela, odnosno ubacivanje i izbacivanje ideja i koncepata se naziva destiliranjem modela (eng. Distilling the Model). Čak iako se ne menjaju zahtevi korisnika, model se stalno profinjava jer savršen model ne postoji. [Evans 2003]

Još jedan važan aspekt u analiziranju znanja je eksplicitnost koncepata. Naime, u komunikaciji se često mogu uočiti razna pravila koja se vezuju za domen. Kao primer, Evans je naveo pravilo prebukiranja kod transportnih kompanija, pošto se često dešava da neka transportna jedinica postane puna, bez mogućnosti tovarenja dodatnog tereta. Međutim, ove kompanije uglavnom prihvate neku određenu količinu prebukiranja, u slučaju da u poslednjem momentu neke mušterije otkažu rezervaciju. Pravilo prebukiranja zavisi od kompanije, ali u najjednostavnijem slučaju može da glasi ovako: „tokom rezervacije dozvoliti 10% prebukiranja“. Programeri bi ovo najverovatnije rešili običnom if-else klauzulom unutar metode rezervacije:public int makeBooking(Cargo cargo, Voyage voyage) { double maxBooking = voyage.capacity() * 1.1; if ((voyage.bookedCargoSize() + cargo.size()) > maxBooking) return –1; // …}Međutim, pravilo prebukiranja je ovde implicitno navedeno, što se neće lepo videti u dijagramu koji je mnogo pogodniji vid komunikacije među učesnicima projekta. Problem se može rešiti tako što će se koncept pretvoriti da bude eksplicitni. Prema tome, isto parče koda bi izgledalo ovako12:public int makeBooking(Cargo cargo, Voyage voyage) { if (!overbookingPolicy.isAllowed(cargo, voyage)) return –1; // …}A klasa OverbookingPolicy bi imao metod isAllowed(…) za proveru prebukiranja:public boolean isAllowed(Cargo cargo, Voyage voyage) { return (cargo.size() + voyage.bookedCargoSize()) <= (voyage.capacity() * 1.1);}Ovako je pravilo postalo eksplicitno (Slika 1), što znači da je ono sada postalo deo zajedničke komunikacije među učesnicima. Prednost ovakvog načina dizajniranja je (pored ostalog) i naglašavanje važnosti ovih poslovnih pravila. [Evans 2003]

12 Ovde se zapravo koristi jednostavna varijanta obrasca pod nazivom strategija ili polisa (eng. Strategy, Policy). [Gamma et al. 1994] Zaista, poslovna pravila se mogu nazvati i polisama.

19

→

Slika 1: Eksplicitnost koncepta. Izvor: [Evans 2003].

Princip analiziranja znanja omogućava izradu adekvatnog i korisnog modela iz mora informacija, ali sve ovo ne bi bilo moguće bez odgovarajuće komunikacije, koja je zapravo centralna tema sledećeg principa.

2.3.2.Sveprisutni jezikU prethodnim odeljcima je već nekoliko puta bilo reči o potrebi zajedničkog

jezika. Kad učesnici u projektu ali u različitim ulogama sede zajedno, i probaju međusobno da komuniciraju, šta će osoba koji sedi sa strane prvo primetiti? Da oni pričaju različitim jezicima. [Evans 2003] Iako svi pričaju na srpskom ili engleskom, oni se međusobno ne razumeju. Kod razvoja softvera ova pojava je skoro uobičajena. Softver se traži u svim domenima: od zdravstva do biblioteka. Zbog ovoga je već jasno, zašto su domenski eksperti potrebni u skoro svakom projektu.

Bez obzira iz koje oblasti domenski eksperti dolaze, može se skoro uvek pretpostaviti da ne znaju ništa o razvoju softvera (kao da ni programeri ne znaju ništa o domenu). Zato nije ni čudo da oni pričaju različitim jezicima. Šta više, svi ljudi su na neki način skloni da koriste žargon, i nisu najčešće ni svesni da ga koriste. [Haywood2009] Nažalost, nije ovo jedini problem. Ljudi su takođe skloni da pojednostave svoj govor. Kad pričaju sa ljudima iz iste oblasti, svima je jasno da iza nekog pojma stoji čitava nauka, pa je dovoljno da pričaju pojednostavljeno, a ostalo se podrazumeva. Međutim, retko se primećuje da taj njihov govor zapravo nema smisla kad pričaju sa ljudima koji ne poznaju tu oblast. Postoji i druga krajnost, kad domenski eksperti prekomplikuju opisivanje koncepata, iako to sa aspekta softvera nije uopšte potrebno. [Evans 2003]

Koji su znaci da ljudi govore različitim jezicima? Kad programeri koriste tehnički rečnik i žargon u komunikaciji sa domenskim ekspertima, to je sigurno loš znak, npr.: kad pričaju o petljama (kao što su while ili for); kad pričaju o tabelama, redovima i kolonama u bazama podataka (naročito kad ubace termine poput primarnog ključa, itd.); kad pričaju o svinjama i pilićima (korišćen žargon u Scrum-u); kad previše ulaze u detalje oko UML dijagrama; kad za slike kažu da su JPG, ili PNG, itd. S' druge strane, ni domenski eksperti nisu izuzeci: na primer, ako je cilj kreiranje softvera za neku biblioteku, eksperti mogu da kažu da DOI mora biti unikatan. Ali programeri ne znaju šta znači DOI, pa eksperti objasne, da je to isto što i ISBN samo za članke (a programeri ne znaju ni značenje ISBN-a). Eksperti takođe mogu skroz zaboraviti, da nešto što se njima podrazumeva, to možda nije slučaj sa programerima, npr. kad pričaju

20

da im treba ISBN knjige, oni zapravo misle na par ISBN-10 i ISBN-13, a pošto se to njima podrazumeva, oni skroz zaborave da to spomenu programerima, itd.

Prvi rezultat ovih problema je najčešće frustracija učesnika na zajedničkim sastancima, odnosno neka vrsta odbojnosti grupa prema ostalim grupama u timu. Domenski eksperti nisu dovoljno jasni kad kažu šta žele, a programeri, čak i ako žele da razumeju domen, najčešće će imati samo maglovitu predstavu o tematici. Da bi se ljudi međusobno razumeli, potrebno je prevoditi jedan jezik na drugi (i obrnuto). [Haywood2009] Domenski eksperti prevode svoj jezik na jezik koji je razumljiv programerima, a programeri prevode svoj tehnički jezik tako da bude razumljiv domenskim ekspertima. Ovakav način komunikacije je pre svega spor, ali najveća opasnost ipak vreba iz raskola tj. šizmi: ljudi imaju različito shvatanje o terminima a nisu toga ni svesni. Rezultat ovoga je – u najboljem slučaju – nepouzdan softver. Na ovo još treba dodati i to da su programeri skloni da kod implementacije koriste neki drugi jezik – naravno, ovi jezici nisu međusobno kompatibilni, pa se moraju „prevesti“ iz jednog u drugi. Što je broj jezika veći, to je verovatnoća, da će se neki važni domenski koncepti „izgubiti u prevodu“, veća. [Evans 2003]

Zato je ideja da se stvori zajednički jezik, od presudnog značaja. Prvo što bi ljudima palo na pamet bi bilo da se jedan jezik iz mnoštva proglasi za zajednički. Međutim, to nije dobra ideja zato što nijedan jezik iz skupa ne zadovoljava sve potrebe. Pravo rešenje je zapravo proglasiti model domena za zajednički jezik, koji se naziva sveprisutnim jezikom (eng. Ubiquitous Language)13. Kao što Evans definiše:

„Sveprisutni jezik je jezik koji se zasniva na modelu domena i koji se koristi od strane svih članova tima radi spajanja svih aktivnosti tima sa softverom.“ [Evans 2003]

Rečnik sveprisutnog jezika sadrži nazive klasa kao i važne operacije. Takođe, on sadrži i poslovna pravila, koja su eksplicitna14. Naravno, rečnik može da sadrži i nazive raznih obrazaca koji se lepo uklapaju u model. Ovaj jezik služi i za opis zadataka, za opis funkcionalnosti, ali i za opis korisničkih zahteva. Svi članovi tima bi trebali da govore ovim jezikom bez obzira na njihovu ulogu: programer sa programerom, domenski ekspert sa domenskim ekspertom, ali i programer sa domenskim ekspertom. Pošto je model domena povezan sa sveprisutnim jezikom, svi učesnici u razvoju bi trebali da imaju interes za oba. Ovo naročito važi za domenske eksperte, naime, ako su oni izostavljeni iz jezika i modela, kako će se znati da su apstrakcije i koncepti u modelu ispravni? [Evans 2003]

Naravno, može se pretpostaviti da će jezik na početku projekta biti primitivan, baš kao i model domena. Ali analiziranjem znanja će se model stalno obogaćivati novim konceptima, i tako će i rečnik jezika rasti. Važno je samo da se ne koristi žargon, i da učesnici budu spremni da objasne pojmove na adekvatan ali dovoljno jednostavan način. Postoji verovatnoća da jezik ostane i kasnije problematičan, npr. kad neki pojmovi i dalje zvuče neprirodno ili manjkavo, ili kad jezik nije dovoljno bogat da objasni nešto. Međutim, ovo je onda znak da je problem zapravo u modelu. Tada treba proširiti ili modifikovati jezik, sve dok on ne zvuči prirodno, a te izmene treba odmah ubaciti i u model. Kao što Evans kaže: „Svaka promena u jeziku je promena u modelu domena“. Ovde domenski eksperti imaju veliku ulogu: oni su ti koji najlakše mogu

13 Nilsson smatra da je sveprisutni jezik zapravo artefakt, iako sadrži i nematerijalne stvari, kao što je govorni, verbalni jezik.[Nilsson 2006]

14 Eksplicitnost koncepata i poslovnih pravila je opisana u prethodnom delu.

21

uočiti probleme u jeziku. [Evans 2003] Kad sveprisutni jezik nije u skladu sa njihovim domenskim jezikom, onda to može biti znak za uzbunu. Kad se to desi, oni moraju o tome obavestiti ostatak tima. Ovo važi i u slučaju kad se primete razne dvosmislenosti i protivrečnosti. Drugim rečima, potrebno je uraditi tzv. standardizaciju terminologije. [Haywood 2009]

Sveprisutni jezik se naziva ovako upravo zbog svoje sveprisutne prirode: svi ga koriste, uvek, i u svim oblicima: pogotovo kod verbalne komunikacije, ali i kod crtanja dijagrama, kod pisanja dokumenata, čak i u samoj implementaciji. Naravno, ovo ne znači da su drugi jezici zabranjeni. Domenski eksperti će međusobno govoriti i na svom jeziku domena, koji je verovatno mnogo obimniji od sveprisutnog jezika. Programeri će takođe koristiti i svoj tehnički jezik kad eksperti nisu prisutni i koji je potreban za implementaciju (koji je opet širi od sveprisutnog jezika). Ali kad tim radi zajedno, sveprisutni jezik mora biti primaran. Slika 2 prikazuje gde se otprilike nalazi sveprisutni jezik u odnosu na druge jezike. Ovi drugi jezici se zapravo mogu posmatrati kao ekstenzije sveprisutnog jezika. [Evans 2003]

Kao što se može pretpostaviti, sveprisutni jezik se koristi u velikom broju oblika, ali verbalni tj. govorni oblik ipak dominira. Međutim, to ne znači da drugi oblici nisu važni. Ovde se pre svega misli na UML. Kao što i ime kaže, objedinjen jezik modeliranja (eng. Unified Modeling Language, skraćeno UML) predstavlja odličan alat za modeliranje. UML dijagrami su uspešni zato što veliki broj ljudi razmišlja vizuelno, a s druge strane postoji neki osećaj trajnosti (dok govorni jezik ovu osobinu nema). UML dijagrami su dobri i za objašnjenje veza između objekata ali i za prikazivanje raznih interakcija. Međutim, ovi dijagrami su manjkavi kod definicije koncepata i kod prikazivanja ponašanja objekata. [Evans 2003]

Pošto su dijagrami deo sveprisutnog jezika, može se zaključiti da će i domenski eksperti morati da ih nauče. Međutim, detaljno upoznavanje sa UML-om nije uopšte

22

Slika 2: Sveprisutni jezik se može posmatrati i kao presek dva skupa, tj. dva jezika: tehničkog i poslovnog. Izvor: [Evans 2003].

Tehnički aspekti dizajna

Tehnički izrazi

Pojmovi modela domena

Obrasci iz DDD-a

Poslovni izrazi nerazumljivi za

programere

Sveprisutni jezik

Tehnički jezik Poslovni jezik

potrebno. Evans, Mehta, Haywood i drugi smatraju da je svega tri vrste dijagrama dovoljno za modeliranje: dijagram klasa i dijagram objekata za statički model, i dijagram sekvenci za dinamički model. [Evans 2003] [Mehta 2008] [Haywood 2009] Važno je napomenuti da dijagrame nikako ne treba komplikovati. Mnogi upadaju u zamku da žele da modeliraju ceo sistem, što preciznije, to bolje. Međutim, ovakav način razmišljanja će samo odbiti domenske eksperte, a kasnije i ostale članove tima. Dijagrami ne moraju biti ni formalni, i ne moraju ni da zadovolje UML specifikacije: sve dok ljudi (uključujući domenske eksperte) razumeju o čemu se radi, svi oblici dijagrama su prihvatljivi. A kod onih aspekata kod kojih UML ne prednjači, mogu se koristiti drugi oblici komunikacije (npr. verbalni jezik). Prema tome, umesto crtanja ogromnih dijagrama, bolje je praviti tzv. minimalne dijagrame za predstavljanje kostura raznih ideja. [Evans 2003]

Ključni detalji dizajna bi trebali da budu predstavljeni u programskom kodu, a programski kod bi trebao da bude u skladu sa modelom. [Evans 2003] Obrasci DDD-a bi trebali da pomognu u postizanju ovog cilja.

Pre nego što se pređe na opis poslednjeg principa, treba se još malo osvrnuti i na pisane dokumente. Po Evans-u, mnogi članovi tima su „mirniji“ kad znaju da postoji pisani dokument (i to sa razlogom), pošto i dokumenti imaju osećaj trajnosti (slično kao i dijagrami). Ali problem je u tome da čim on postigne trajni oblik, postoji opasnost da ubrzo ostari: sveprisutni jezik evoluira, a dokument se ne ažurira (a čak i ako se ažurira, troši dragoceno vreme). Evans nije protiv pisanih dokumenata, ali smatra da je njihovo pisanje i ažuriranje izazov. Prema tome, on preporučuje da se na pisane dokumente gleda neformalno, a njihova namena bi trebala da bude dopunjavaje ostalih oblika sveprisutnog jezika: nije potrebno da se u dokument stavi nešto što drugi oblik jezika (npr. programki kod) već dobro ilustruje. Najbolje je da dokument sadrži tekst „ukrašen“ sa manjim dijagramima. Pridržavanjem ovih preporuka pisani dokument će biti relevantni artefakt, a njegovo ažuriranje će biti mnogo jednostavnije. [Evans 2003]

2.3.3.Model-Driven DesignKod opisa prethodnog principa je spomenuto da mnogi upadaju u zamku i žele

da naprave kompletan dijagram o modelu domena. Ova praksa vuče svoje poreklo još od vodopadnog modela razvoja, i skoro sve modernije (ali formalne) metodologije su je preuzele. Radi se o tome da analitičari komuniciraju sa domenskim ekspertima, naprave model domena, i na kraju prosleđuju model (kao artefakt) programerima. [Haywood2009] Ovaj artefakt je uglavnom ogromni dijagram klasa. Međutim, kad programeri počnu implementirati dijagram u nekom određenom programskom jeziku, jako često se ispostavlja da ne mogu adekvatno predstaviti model u tom programskom jeziku ili u toj tehnologiji. Problemi mogu biti: smanjenje performansi, teškoće mapiranja u relacioni model, itd. Pošto se model smatra „tačnim“, programeri nemaju mnogo razloga da se zvanično žale na model, naročito jer oni ni nisu u direktnom kontaktu sa domenskim ekspertima. Kao krajnje rešenje, programeri modifikuju dijagram, a tako i celi model, radi postizanja cilja: da program „radi“. Ali pošto je njihov model nešto skroz drugo, niko ne garantuje da je njihov model kompatibilan sa originalnim modelom. [Evans2003]

U prethodnom pasusu se može uočiti više problema. Prvo, analitičari su napravili ogroman dijagram klasa za predstavljanje modela. Ogromni dijagrami mogu

23

sugerisati neki osećaj kompletnosti, ali oni i opterećuju čitaoca sa velikom dozom informacija, pa su dosta teški za razumevanje i navigiranje. Drugi problem je to da je model domena kreiran bez prisustva tehničkog osoblja, pa niko ne zna da li je implementacija modela uopšte sprovodljiva. Treći problem je da su programeri bili primorani da naprave „skriveni“ model, bez znanja da li je značenje, funkcionalnost i bogatstvo domena ostalo netaknuto; drugim rečima, izgubila se veza između modela domena i implementacije. [Evans 2003] Posledica ovih problema je ponovno uspostavljanje raskoraka, odnosno nestanak sveprisutnog jezika. [Haywood 2009]

Ovakav način razdvajanja domena modela (pravljen od strane analitičara uz pomoć domenskih eksperata) od modela implementacije (pravljen od strane programera) je ponovo odlika starog vodopadnog modela.15 [Haywood 2009] U stvari, prvi model je zapravo rezultat faze analize, a drugi model je rezultat faze dizajna. Po ovoj metodologiji, u fazi analize se pravi model tako da to bude u skladu sa domenom, i u ovoj fazi su sva tehnička razmatranja (pitanja u vezi implementacije) namerno izostavljena. U drugoj fazi (dizajn) se pokušava da se artefakt faze analize pretvori u model koji već uvažava tehnička razmatranja. [Evans 2003]

DDD smatra da su uočeni problemi oko postojanja više modela preveliki, i da zbog toga, treba naći rešenje koji neće dopustiti da se izgubi veza između ova dva modela. Zapravo, treba naći model koji bi zadovoljio obe svrhe (i analizu i dizajn). Ovaj princip se naziva Model-Driven Design (na srpskom dizajn usredsređen ka modelu, ili model-vođen dizajn, skraćeno MDD). [Evans 2003]

MDD zapravo kombinuje faze analize i dizajna u jednu iterativnu fazu. Pošto model mora zadovoljiti oba cilja, ne sme se prihvatiti model koji dobro reprezentuje domen, ali pati od dečijih tehničkih bolesti. Važi i obrnuto, znači ne sme se prihvatiti ni model koji odlično rešava tehničke probleme, ali domenski eksperti ipak smatraju da je sumnjiv. Iterativni ciklus treba ponoviti sve dok se ne nađe model koji odgovara svim potrebama. [Evans 2003] Takođe, nikad ne treba težiti da se odmah napravi kompletni sistem, nego model treba da evoluira postepeno, korak po korak, na iterativni način. Preporučuje se da implementaciju treba početi čim postoji prvi minimalni model (sa kojim su svi prisutni zadovoljni), čak i ako to u implementaciji predstavlja svega četiri-pet klasa. Tako će skriveni problemi mnogo ranije izaći na površinu, a i domenski eksperti će relativno brzo videti prvi konkretni rezultat zajedničkog rada.

Veza između modela domena i programskog koda treba da bude vidljiva. Implementacija bi zapravo trebala da bude izraz modela, što znači da će bilo kakva promena u modelu biti promena u kodu, i obrnuto, bilo kakva promena u kodu će biti promena u modelu. [Evans 2003]

Postojanje dva posebna modela za analizu i dizajn nije jedini slučaj gde je MDD od velike koristi. Naime, postoje i druge vrste modela, a jedan od njih je i korisnički model koji ustvari predstavlja pogled na sistem sa tačke gledišta korisnika tog softvera. Za formiranje korisničkog modela je zaslužan deo softvera sa kojim korisnik komunicira, a taj deo je korisnički interfejs (GUI). Često se dešava da neki softver

15 Ovo razdvajanja modela postoji čak i u modernim metodologijama, npr. u MDA (skraćenica od Model-Driven Architecture, predstavljenom od strane OMG-a (skraćenica od Object Management Group)). MDA razdvaja model u dva dela: u platform-nezavisni model (eng. Platform-Independent Model, skraćeno PIM) i platform-specifični model (eng. Platform-Specific Model, skraćeno PSM). [Haywood 2009]

24

namerno dezinformiše korisnika, u smislu da se kod korisnika stvara utisak da nešto u softveru funkcioniše na jedan način, a u implementaciji je to realizovano skroz drugačije.16 Problemi koji nastaju razdvajanjem para „korisnički model – dizajn“ su: konfuzija korisnika i bagovi. Sem ako je ta iluzija savršeno urađena, pojavljivanje problema je skoro neminovno. Prema tome, sve što je već prethodno rečeno, važi i ovde: ne stvarati lažnu sliku modela za korisnika, nego mu predstaviti onako kako je to rešeno u implementaciji, a ako se to ne preporučuje, promeniti samu implementaciju.17 [Evans 2003]

Iz prethodnih pasusa već nije teško zaključiti da MDD nije baš kompatibilan sa starim vodopadnim modelom, ali ni sa onim modernijim metodologijama razvoja koje namerno razdvajaju analizu od dizajna. Inače, uobičajena je pojava, da u razvojnom timu jako iskusni ljudi modeliraju, a ostali programiraju. Najverovatnije ima istine u tome da programeri početnici ne bi smeli da menjaju dizajn bez dozvole, ali postavlja se pitanje, da li to znači da ni ljudi koji modeliraju ne bi smeli da programiraju? Po Evans-u, ovo je velika greška. Čak i ako su pravljenje modela domena i implementacija tog modela dve različite faze sa dva različita tima, zabraniti ljudima koji su direktno odgovorni za model da prisustvuju u implementaciji, će rezultovati istim problemima koji su prethodno navedeni. [Evans 2003]

2.4. Obrasci Domain-Driven Design-aU prethodnom delu ovog poglavlja su bile predstavljene osnovne ideje, odnosno

principi Domain-Driven Design-a. Ovi principi naglašavaju važnost analiziranja znanja radi formiranja modela iz sirovog mora informacija, sveprisutnog jezika zasnovanog na

16 Kao odličan primer gde je korisnički model razdvojen od modela implementacije, Evans navodi stare verzije Microsoft Internet Explorer-a, preciznije, osobinu snimanja linkova omiljenih Web stranica (eng. Favorites). Kad je korisnik želeo snimiti link Web stranice u Favorites, on je samo upisao naziv te stranice, i program ga je sačuvao u nekoj listi, stvarajući utisak da je Favorites zapravo lista sa imenima Web stranica. Međutim, ono što korisnik nije znao je to da program nije čuvao nikakvu listu. Umesto toga, jedna stavka u „listi“ je zapravo bila jedan fajl: ime Web stranice je bilo ime fajla, a URL, tj. link se čuvao unutar fajla (kao sadržaj fajla). Ove fajlove je Internet Explorer snimio u neki određen folder, pa je učitavanje liste pri startovanju programa zapravo bilo učitavanje fajlova iz tog folder-a. Ovakav način dezinformisanja je stvorio konfuziju među korisnicima: pošto fajl sistem Windows operativnog sistema ne dozvoljava specijalne znakove poput „:“ i „?“, kad je korisnik hteo da snimi link omiljene stranice sa ovim znacima (a to se često dešavalo), Windows je ispisao poruku da ime fajla ne može da sadrži specijalne znakove. Kakvo ime fajla? S druge strane, ako je korisnik prihvatio podrazumevajuće (eng. Default) ime za omiljenu stranicu (prekopirano iz naslova stranice), Internet Explorer je nedozvoljene karaktere ili tiho izbrisao ili zamenio drugim znakovima. Tiho brisanje ili promena podataka možda nema tako veliki značaj u ovom slučaju, ali je ovakvo ponašanje inače neprihvatljivo. [Evans 2003]

17 Tako na primer rešenje za čuvanje linkova omiljenih Web stranica može biti da program na neki način informiše korisnika da je zapravo reč o običnim fajlovima, a ne o listi. Tada će korisnik znati šta se dešava kad Windows ispiše grešku pri imenovanju fajlova, a biće i u stanju da ih organizuje i da upravlja tim fajlovima onako kako želi uz pomoć nekog fajl menadžera (npr. Windows File Explorer, Total Commander, FreeCommander, itd.).Ipak, prethodni način rešavanja problema nije uvek lep (ako se proceni da bi većini korisnika to bilo previše komplikovano, npr. ljudi možda ne poznaju fajl sisteme). U ovom slučaju, možda bi trebalo promeniti samu implementaciju, znači da se stvarno koristi neka lista umesto fajlova u nekom folder-u, i da se ta lista čuva npr. u obliku jednog tekstualnog fajla. Ovaj način bi rešio i problem nedozvoljenih znakova, šta više, ako bi se fajl snimilo u Unicode formatu, bili bi dozvoljeni i karakteri stranih jezika (npr. ćirilica, azijski jezici, itd.). [Evans 2003]

25

modelu domena za komunikaciju između svih članova tima i Model-Driven Design-a za sprečavanje razdvajanja modela od implementacije. Međutim, ovi principi su pomalo idealistički dok realni projekti to nisu, što znači da ih se nije lako pridržavati. Zato DDD opisuje i dosta veliki skup obrazaca tj. pattern-a koji bi generalno trebali da olakšaju DDD (a naročito MDD). Po granularnosti, ovi obrasci bi se mogli klasifikovati u tri velike grupe: [Evans 2003]

1. Gradivni blokovi MDD-a (eng. Building Blocks of MDD) – za očuvanje veze između modela domena i implementacije, potrebno je identifikovati gradivne koncepte domena. Nalazeći se na najnižem nivou granularnosti, ovi obrasci teže da uvedu red u dizajn i forsiraju izgradnju modela koji je praktičan za implementaciju. Ako se obrati dovoljna pažnja na formiranje ovih malih, gradivnih elemenata, može se izgraditi jedna stabilna osnova na koju bi se mogli primeniti obrasci druge i treće grupe.

2. Refaktorisanje ka dubljem shvatanju (eng. Refactoring Toward Deeper Insight) – idealno gledano, poenta modeliranja bi bila razvoj jednog modela kojim bi se moglo izraziti duboko razumevanje domena. Rezultat ovakvog modela bi bio softver koji bi funkcionisao slično načinu razmišljanja domenskih eksperata. Međutim, pronaći ovakav model uopšte nije lako. Ideje i obrasci izloženi u ovoj kategoriji mogu pomoći u formulisanju samih ciljeva i u opisu procesa kojim se može stići do cilja, pri čemu se ne sme zaboraviti da model i dalje mora zadovoljiti ne samo domenske nego i tehničke potrebe. Refaktorisanja u ovom slučaju su na većem nivou granularnosti, jer su motivisana novim saznanjima iz domena, a njihov cilj nije lepši, nego dublji model.

3. Strateški dizajn (eng. Strategic Design) – kod ozbiljnih i velikih projekata postoji jedna tačka nakon koje celokupni sistem postaje suviše komplikovan da bi ga ljudi poznavali do najnižeg nivoa – do nivoa objekata. Ovi sistemi su toliko veliki da je njihovo upravljanje i shvatanje u celini – bez razbijanja u manje delove – skoro nemoguće. Umesto objekata i klasa, jedinice posmatranja postaju moduli, paketi, pa čak i podsistemi, ali bez obzira na visinu granularnosti, potrebne su tehnike i za baratanje velikim modelima. Ideje i obrasci izloženi u ovoj kategoriji omogućuju skaliranje procesa modeliranja do vrlo komplikovanih domena. Za razliku od jednostavnijih domena gde je upravljanje svega jednim modelom bilo održivo, sad je domen toliko obiman da je potrebno model razbiti na manje delove. Prema tome, pored održavanja veze između modela i implementacije kod pojedinačnih modela domena (po principu MDD-a), sad treba obratiti pažnju i na veze između raznih modela. Sve u svemu, na ovom nivou se već sve odluke donose na nivou celog tima, pa i između više timova, i to sa velikom dozom visoke birokratije i menadžmenta. Po mnogima, DDD najsvetlije sija upravo na ovom najvišem nivou apstrakcije.

Obrasci iz ovih grupa neće biti detaljnije opisani, jer njihovo predstavljanje već uveliko izlazi iz okvira ovog rada, ali će neki od njih biti spomenuti u kasnijim delovima (naročito u poglavlju 5).

26

2.5. Primeri korišćenja Domain-Driven Design-aU prethodnim delovima ovog poglavlja su bili predstavljeni teorijski osnovi

Domain-Driven Design-a, ali DDD je u stvari praktična disciplina. Prema tome, ovde će se istražiti kako se Domain-Driven Design pokazao u praktičnoj primeni.

Dobar izvor informacija se nalazi na zvaničnoj internet prezentaciji DDD-a.18 Na stranicama sajta se mogu pročitati vesti koje se vezuju za DDD, izveštaji sa naučnih konferencija, primeri korišćenja, kao i razne diskusije. Naravno, razne diskusije i članci o DDD-u se mogu naći i u naučnim časopisima.

U nastavku ovog dela biće navedeni neki projekti koji su postali uspešni upravo zbog korišćenja DDD-a.

Labatt Food Service (skraćeno LFS) je deseti najveći distributer hrane u SAD, stacioniran u Texas-u, sa preko 12.000 artikala, 7000 mušterija i sa godišnjim prometom blizu milijardu američkih dolara. Među mušterijama se nalaze restorani, hoteli, bolnice, vojne baze, škole, itd. Jedan veliki izazov kod ovakvih kompanija je distribucija hrane u kritičnim vremenskim periodima, kao što je period od avgusta do septembra, kad školske institucije ponovo počnu sa radom (posle letnjeg raspusta). LFS u ovom periodu mora da popuni inventar oko 2800 školskih lokacija, što nije lak posao: s jedne strane mora imati dovoljne količine svih artikala na zalihama, a s druge strane treba naći balans između ponude i potražnje. Negativni rezultati ovih problema su famozne „nema na zalihama“ (eng. „Out-of-Stock“) poruke, i situacije kad ostane velika količina lako-kvarljivih proizvoda na zalihama. Ovaj period je za LFS bio prilično problematičan.

LFS je odlučio da modernizuje softver kojim se može upravljati zalihama i porudžbinama. Za kreiranje novog softvera, oni su iskoristili pogodnosti DDD-a, naročito pri pravljenju modela. Rezultat napora je bio softver lansiran 2009. godine koji je premašio sva očekivanja. Već u prvoj godini korišćenja, softver je za kompaniju doneo uštedu preko milion dolara. Posle tri godine korišćenja, može se zaključiti da je LFS uštedeo preko osam miliona dolara suvišnih investicija u zalihe (situacija kad se naručuje više proizvoda nego što je realno potrebno), slučaj „Nema na zalihama“ artikala se smanjio za 50%, a globalnu prodaju je povećao za 15%. Takođe, tim zaslužan za kreiranje softvera je posle prve godine korišćenja morao da proširi funkcionalnost softvera. Proširenje je prošlo bez problema, prvenstveno zbog adekvatnosti modela koji je pokazao duboko znanje o domenu. Štaviše, korisnici softvera, u ovom slučaju predstavnici prodaje (eng. Sales Representatives), su smatrali da je softver lak za korišćenje i veoma funkcionalan. [Canty 2012]

Kao jedan drugi primer, može se posmatrati slučaj kompanije Custom House. Custom House Global Foreign Exchange je firma koja se bavi onlajn menjačkim poslovima (sad već deo kompanije Western Union). Kao svaka firma ove vrste, i Custom House je morala da ima kompleksni sistem čiji zadatak je bio vršenje onlajn menjačkih poslova. Međutim, 2005. godine su zaposleni u firmi primetili da je njihov softver postao problematičan, i da je polako počeo da izmiče kontroli.

Pošto su zaključili da njihov softver više ne predstavlja domen onako kako treba, saznali su za postojanje DDD-a, i pozvali su Eric Evans-a da im pomogne u „restauraciji“ njihovog softvera. Ispostavilo se da sistem pati od ozbiljnih problema:

18 Zvanična prezentacija DDD-a se nalazi na adresi: <http://domaindrivendesign.org/>.

27

model je bio prepun primitivnih tipova (npr. String, integer, double, boolean, itd.), koji nisu izražavali koncepte domena, a i sami koncepti su bili implicitni i skoro nevidljivi. Sve u svemu, softver je u celosti gledano bio nejasan, neinformativan, i nadut zbog dupliranja programskog koda. Razvojni tim je uz pomoć Evans-a uspeo da izvrši obnovu softvera. Koncepti domena kao što su valuta, novac, kurs i dobit (eng. Currency, Money, Rate i Markup, respektivno) su umesto primitivnih tipova sad postali pravi objekti sa značenjem. Već ovo uvođenje eksplicitnosti je uveliko poboljšalo izvorni kod softvera. Uz dodatno refaktorisanje, njihov sistem je postao konkurentan, jasan i spreman za dalja proširenja. [Hu & Peng 2007]

Međutim, posle dve godine korišćenja ovog softvera, 2007. godine počeo je da ih muči drugi problem. Naime, ovaj softver (inače pisan u Microsoft .NET-u) je morao da komunicira sa jednom starom tzv. legacy aplikacijom (pravljenom u Microsoft FoxPro). Posle izvesnog vremena, oba softvera su počela da idu skroz drugim putem, rezultujući praktično nemogućom komunikacijom. Napor da oni ostanu međusobno kompatibilni je počeo da oduzima suviše mnogo vremena, po nekim procenama i preko 30% vremena provedenog na razvoju. Na kraju, razvojni tim je problem rešio uz pomoć razvijanja tzv. antikorupcijskog sloja19. [Peng & Hu 2007]

Naravno postoji i čitav niz drugih primera. DDD je čak uspeo da privuče pažnju i uglednog britanskog lista The Guardian. Ovaj list (koji je već nekoliko puta osvojio nagradu najboljeg lista i u „papirnoj“ i u onlajn kategoriji) je 2009. godine kompletno obnovio svoju onlajn ediciju20 koristeći načela DDD-a. Iskustva su bila pozitivna: ne samo da je model postao dublji, nego je i tim za ažuriranje postao efikasniji. [Wills2009]

Do sad su bili opisani uobičajeni primeri kod kojih je DDD pomogao pri pravljenju novih aplikacija ili pri doterivanju starih, postojećih sistema u raznim firmama. Međutim, postoje primeri kod kojih je DDD korišćen na dosta nestandardan način. U nastavku će biti prikazani neki od ovih slučajeva.

Na primer, kod jednog projekta, cilj je bio napraviti jedan prototip arhitekture koja bi pomogla u skraćivanju vremena razvoja softverskih projekata. Naime, „kompjuterizacija“ nekih segmenata državnih institucija zahteva izradu softvera, koji se uglavnom rade od nule, iako možda postoje delovi domena koji se poklapaju sa domenom već postojećih softvera (rađenih u drugim institucijama). Zato su neke državne institucije u Brazilu (Ministarstvo odbrane, Brazilska Mornarica, i Federalni Univerzitet u Rio de Janeiro-u) udružile snage da bi izradile spomenuti prototip arhitekture. Ideja iza arhitekture je sledeća: kad neki razvojni tim želi napraviti neki novi softver, umesto da počnu iz početka, oni bi mogli u nekoj bazi podataka pogledati da li su neki drugi negde drugde već pravili nešto slično, ili barem da li postoji neki projekat koji ima neke dodirne tačke sa novim projektom. Ako je odgovor potvrdan,

19 Antikorupcijski sloj (eng. Anticorruption Layer) je obrazac iz treće grupe obrazaca DDD-a (Strateški dizajn). Kao što Evans ističe, „antikorupcijski sloj nije mehanizam za slanje poruka između dva sistema. Ovaj sloj zapravo predstavlja mehanizam koji prevodi konceptualne objekte i akcije iz jednog modela u drugi.“ Potreba za ovim obrascem potiče iz činjenice da posmatrane dve aplikacije imaju skroz drugačiji model, prema tome, jedna od njih mora preuzeti ulogu prevodioca. Međutim, ovo najčešće znači korumpiranje modela te aplikacije sa modelom legacy softvera. Razvijanjem izolacionog sloja za prevođenje i komunikaciju (u oba smera), oba sistema mogu da dalje rastu bez stranog mešanja. [Evans 2003]

20 Onlajn verzija lista se nalazi na adresi: <http://www.guardian.co.uk/>.

28

model (ili parče modela) bi se skidao preko mreže, a zatim bi se automatski kreirao kostur klasa u razvojnom okruženju (u ovom slučaju, u Eclipse IDE). Model novog projekta bi se takođe upload-ovao na mrežu i bio bi dostupan na globalnom nivou.

Posebno je interesantno pogledati, koje tehnologije su korišćene u izradi ove arhitekture. Kreatori su mešali DDD, MDA, SOA i Web servise. DDD su koristili za modeliranje domena, MDA za standardizaciju načina modeliranja (da bi se svi drugi projekti podržani od strane arhitekture modelirali po istim standardima), a SOA (skraćenica od Service-Oriented Architecture) i Web servise za automatizaciju i za pristup projektima preko servisa na mreži. Kao što je u odeljku 2.3.3 već spomenuto, DDD nije baš u skladu sa idejama MDA, ali su kreatori ipak uspeli da ih spoje. Napravljen prototip ove arhitekture je uspeo da skrati vreme razvoja jednog novog sistema za 25%. [Marzullo, de Souza, & Blaschek 2008]

ROMULUS projekat je nešto slično prethodnom projektu u smislu olakšanja razvoja, ali se nalazi u drugom domenu. Naime, razvoj Web softvera je danas veoma popularan, ali sama oblast još nije dovoljno razvijena. Posledica ove tvrdnje je nastanak velikog broja međusobno dosta različitih framework-ova i komponenata, koji stavljaju dodatni teret na ramena programera, i umesto da poboljšaju njihovu produktivnost, dešava se upravo suprotno. ROMULUS je jedan Web metaframework u Java svetu koji za cilj ima da poveća produktivnost pri razvoju Web softvera. Kao metaframework, on se nalazi u nekom apstraktnom sloju, i funkcioniše tako što nudi zajednički interfejs ka drugim Java framework-ovima kao što je Spring. Prema tome, programeri umesto da direktno pristupaju korišćenom framework-u, oni pristupaju ROMULUS metaframework-u. Prednosti korišćenja ovakvog metaframework-a su da programeri koriste samo jedan objedinjen interfejs umesto više različitih interfejsa, a mogu brzo i da migriraju na neki drugi framework. ROMULUS je kreiran koristeći načela DDD-a. Na izradi je učestvovao veliki broj kompanija kao i univerziteta iz Španije, Italije, Nemačke, Irske i Rumunije. [Garcia et al. 2010]

Poslednji primer koji će biti naveden, predstavlja jednu skroz drugačiju primenu DDD-a. U ovom slučaju su načela DDD-a iskoristili za procenjivanje postojećih softvera za potrebe jedne kompanije, a ne za razvoj neke softverske aplikacije. Statoil je velika norveška energetska kompanija koja zapošljava više od 20.000 osoba. Kompanija je htela da zameni nekoliko starih legacy programa sa novim koji bi bolje podržali operacije za prodaju i transport sirove nafte. Jedna od opcija je bila i kupovina COTS21 softvera. Statoil je formirao malu grupu koja bi procenila postojeću ponudu COTS proizvoda sa više aspekata.

Za procenu, tim je koristio DDD obrasce iz treće grupe (Strateški dizajn) da napravi model domena same kompanije, tačnije rečeno sve što bi novi softver morao da podržava radi određivanja funkcionalnosti koja im treba. Zatim su dobijen rezultat poredili sa mogućnostima COTS softvera. Na kraju procene, grupa je donela zaključak da nijedan COTS proizvod ne zadovoljava precizno njihove potrebe, i doneta je odluka da se pravi unutrašnji softver. [Wesenberg, Landre & Rønneberg 2006]

21 COTS (skraćenica od Commercial Off-The-Shelf) softver označava gotov softver napravljen od strane neke firme. Kompanije mogu da kupe COTS softver za njihove potrebe umesto da same razvijaju svoj softver.

29

2.6. Prednosti i mane Domain-Driven Design-aKao svaka filozofija, i DDD ima svoje sledbenike ali i kritičare. U ovom

poslednjem delu poglavlja će biti navedene neke prednosti i mane Domain-Driven Design-a.

Nije sporno da je Eric Evans sa predstavljanjem DDD-a i izdavanjem njegove knjige napravio veliku uslugu u softverskom svetu. Kao što Dan Haywood ističe, u DDD-u nema ništa revolucionarno, jer skoro sve ideje su postojale i ranije, iako možda izolovano. Međutim, Evans je uspeo da ove ideje vešto upakuje u jednu celinu, napravivši ih moćnijim kad su zajedno. [Haywood 2009] Neke prednosti DDD-a su:

• Usredsređen ka domenu – softverski svet je već odavno uočio važnost domena pri razvoju softvera (ovo ilustruje postojanje faze analize već u starom vodopadnom modelu), ali nije uradio dovoljno da napravljen softver stvarno bude u skladu sa istim. DDD fokus stavlja na domen i to bukvalno, zahtevajući da domenski eksperti komuniciraju ne samo sa nekim analitičarima nego i sa programerima. [Evans 2003]

• Odlična skalabilnost prema složenosti domena – DDD se može koristiti kod projekata bilo koje veličine, ali se smatra da on najviše sija upravo kod komplikovanih domena. Projektima koji se stalno razviju, su potrebne discipline i tehnologije koje se dobro skaliraju, tj. funkcionalne su čak i kod velikih projekata. DDD ima čak i posebnu grupu obrazaca (treća grupa zvana Strateški dizajn) koja se koristi kod velikih projekata). [Evans 2003]

• Kompletno rešenje – DDD sa svojim principima i velikim brojem obrazaca (koji su raspoređeni u tri grupe) nudi kompletno rešenje za razvoj enterprise aplikacija. [Haywood 2009]

• Premošćava raskorake tj. rupa – kod više metodologija razvoja softvera, ono što se veoma često primećuje je fragmentacija. Stavljanjem analitičara između domenskih eksperata i programera, stvara se raskorak između ove dve grupe, a i model će se raspasti na model domena i na model implementacije. Ovaj nedostatak komunikacije između ljudi koji obavljaju različite uloge samo povećava tenzije među tim grupama. Srećom, DDD pomoću Model-Driven Design-a može sprečiti rascepkanje modela na više delova, a uz sveprisutni jezik će forsirati korišćenje samog modela za rešavanje ovakvih problema. [Nilsson2006]

Međutim, ni Domain-Driven Design nije bez mana. Neki od uočenih nedostataka su:

• Nije dovoljno uhodan – DDD je bio predstavljen 2003. godine, što znači da je relativno nov u odnosu na druge metodologije. Kao takav, on još nema dovoljnu podršku u softverskom svetu, i u nekim situacijama je još uvek bolje koristiti stare discipline. [Mehta 2008] Takođe, njegova podrška u raznim tehnologijama bi mogla da bude bolja, npr. podrška za DDD u EJB tehnologiji je uvedena tek od verzije 3. [Panda, Rahman & Lane 2007]

• Težak za učenje – kao što i sam Evans priznaje u predgovoru [Nilsson 2006],

30

„najbolji način za učenje DDD-a je sesti pored ljubaznog, strpljivog, iskusnog stručnjaka, i preći kroz probleme zajedno, korak po korak.“ Zaista, mnogim ljudima će se činiti da je DDD previše apstraktan i težak za razumevanje. Ova filozofija zahteva ozbiljnu količinu praktičnog iskustva. Štaviše, veliki broj ljudi ima problem da neke ideje DDD-a stavi u praktični kontekst. [Haywood 2009]

• Sveprisutni jezik može praviti probleme – kasnije iskustvo je pokazalo da bez obzira koliko je sveprisutni jezik koristan, među članovima tima često naiđe na odbojnost. Pošto ovaj jezik zahteva aktivno uključenje i programera i domenskih eksperata u diskusiju, premostiti razlike između ovih grupa je lakše reći nego realizovati. Aktivno korišćenje pojednostavljenog UML-a je naročito problematično, pošto se pokazalo da ni domenski eksperti, ni menadžeri projekta ne vole UML. [Haywood 2009] [Pawson 2004]

• Neisplativ kod jednostavnih domena – prethodno je navedeno da DDD podržava razvoj projekata na svim nivoima složenosti domena. Međutim, u realnosti se pokazalo da iako je to u teoriji moguće, kod manjih projekata sa relativno jednostavnim domenom, korišćenje DDD-a se ne isplati, sem ako je unapred poznato da će se projekat proširiti u budućnosti. [Haywood 2009]

S ovim je predstavljanje Domain-Driven Design-a završeno. Mora se ponovo napomenuti da cilj ovog rada nije detaljan opis DDD-a, nego samo upoznavanje sa njegovim načelima i principima. Kao što se moglo primetiti, obrasci DDD-a su skroz izostavljeni iz rada. Međutim, može se reći da je čak i ovoliko znanje o DDD-u dovoljno da se napravi kompletna slika o Naked Objects pristupu koji će se prikazati u sledećem poglavlju. Naime, jedan od razloga nastanka ovog pristupa je upravo DDD, preciznije rečeno, frustracija pri korišćenju DDD-a u praksi...

31

3. Naked Objects pristupU ovom poglavlju će biti predstavljen Naked Objects pristup sa teorijskog

aspekta. Prvo će se opisati suština samog pristupa, a zatim će se preći na opisivanje objektno-orijentisanih korisničkih interfejsa. Izlaganje će se nastaviti istraživanjem agilnosti pristupa: koje vrste agilnosti Naked Objects pristup podržava, na koji način ih može postići, i kako se sam pristup uklapa u postojeće metodologije razvoja softvera. Biće dati i realni primeri koji su bili implementirani uz pomoć ovog pristupa. Poglavlje će se završiti sumiranjem njegovih prednosti i mana. Međutim, slično kao i kod prethodnog poglavlja, potrebno je prvo nastaviti osvrt na višeslojne (i druge) arhitekture, čije su prednosti i mane na neki način inspirisale kreatora Naked Objects pristupa.

3.1. Višeslojne arhitekture (drugi put)U odeljku 2.1 su bile predstavljene višeslojne arhitekture, a na kraju tog odeljka

je bilo spomenuto da i Naked Objects pristup prihvata važnost ovog obrasca ali smatra da je problematičan. Naime, struktuiranje tj. razbijanje sistema na podzadatke sa sobom nosi jedan ozbiljan problem: ne garantuje da će rešiti problem talasnog efekta, tj. postoji verovatnoća da će neka promena u kodu rezultovati promenama i u drugim slojevima. Neke promene će ostati „lokalne“ u smislu da će se modifikovati samo jedan sloj, ali ako te promene rezultuju modifikacijama i u preostalim slojevima, tada postoji opasnost da ova mana pomrači pozitivne strane ove arhitekture, kao što su ponovno korišćenje, prenosivost tj. portabilnost i razmenljivost. [Buschmann et al. 1996] Richard Pawson, autor Naked Objects pristupa smatra da je naveden problem realan, jer će se svaki poslovni koncept (npr. Knjiga, Autor, itd.) obično pojaviti onoliko puta koliko ima slojeva, samo u različitim oblicima. Ipak, po Pawson-u, najveći problem višeslojnih arhitektura leži u tome da one implicitno promovišu koncept tzv. behavioralno-slabih objekata. [Pawson 2004]

Po Pawson-ovoj terminologiji, objekti po svom ponašanju mogu biti behavioralno-kompletni i behavioralno-slabi. Kao što se zna, objekat je određen svojim stanjem, ponašanjem i identitetom, pri čemu stanje (podaci) objekta obuhvata sve svoje osobine (atributi ili polja objekta), a ponašanje objekta opisuje način delovanja i reagovanja (operacije objekta). [Booch et al. 2007] Objekat je behavioralno-kompletan ili celovit (eng. Behaviourally-Complete Object) ako enkapsulira (tj. obuhvata) svoje stanje i ponašanje. Naravno, ovo ne znači da objekat mora imati celokupnu funkcionalnost posmatranog entiteta iz realnog sveta, nego samo funkcionalnost koja se odnosi na kontekst koji se posmatra u nekoj aplikaciji. Intuitivno, objekat je behavioralno-slab (eng. Behaviourally-Weak Object), ako ne enkapsulira u potpunosti svoje stanje i ponašanje. [Pawson 2004]

Behavioralna-kompletnost objekata inače nije nikakva novost. Enkapsulacija stanja i ponašanja je u stvari treća karakteristična osobina objekata po Clemens Szyperski-ju.22 Zapravo, objekti su originalno bili zamišljeni tako da budu behavioralno-

22 Objekat ima tri karakteristične osobine: ima jedinstven identitet, može imati stanje koje se može eksterno posmatrati i enkapsulira svoje stanje i ponašanje. [Szyperski, Gruntz & Murer 2002]

33

kompletni. Kad su Norvežani Ole-Johan Dahl i Kristen Nygaard sredinom 1960-ih godina u Oslu položili temelje objektno-orijentisane paradigme sa predstavljanjem prvog objektno-orijentisanog programskog jezika pod nazivom Simula (proširenje programskog jezika Algol), oni su objekte okarakterisali kao samostalne tj. zasebne (eng. Self-Contained) u smislu da sadrže sve delove u sebi. Ova osobina je bila važna, jer su u prethodnim paradigmama podaci bili razdvojeni od ponašanja, što nije odgovaralo cilju, a cilj je bio stvoriti programski jezik za pisanje programa s kojim bi se simulirali fenomeni iz realnog sveta kao što su industrijski procesi ili epidemije bolesti.23 [Pawson 2004]

Na drugom delu sveta, u Americi, tačnije u Xerox-ovom istraživačkom centru u Palo Alto-u (eng. Xerox PARC, skraćenica od Palo Alto Research Center), Alan Kay je bio fasciniran dostignućima iz Norveške. On je početkom 1970-ih godina formirao jednu novu struju objektno-orijentisanog razmišljanja. Smatrajući da je ovaj način razmišljanja zapravo jedan kognitivni alat, jer se dobro uklapa sa načinom kako ljudi razmišljaju o realnom svetu, uveo je nova svojstva u originalnu paradigmu, kao što je polimorfizam. Rezultat ove struje razmišljanja je inače bio programski jezik Smalltalk. [Pawson 2004]

Postavlja se pitanje, ako su objekti originalno bili zamišljeni da budu behavioralno-kompletni, zašto je današnja situacija skoro obrnuta? Priča počinje sa kasnijim dešavanjima unutar Xerox PARC-a.

Jedna osobina Smalltalk jezika je bila mogućnost da se proširi grafičkim korisničkim interfejsom (GUI). Simula i ranije verzije Smalltalk-a su bile zamišljene tako da njihovi korisnici budu programeri, tj. da ljudi pišu programe za svoje potrebe. Međutim, kasnije verzije Smalltalk-a su sve više ličile na neki programski jezik opšte namene, pa su potencijalna tržišta postala i poslovni svet, prosveta i nauka. Ovo je sa sobom nosilo dve posledice: prvu, da korisnici programa neće nužno biti programeri; i drugu, da jedan GUI možda neće odgovarati svim grupama. Bilo je potrebno da se izmisli neki mehanizam s kojim bi se pojednostavili problemi vezani za ovu drugu posledicu. [Pawson 2004]

Rešenje je stiglo krajem 1970-ih godina od strane Norvežanina Trygve Reenskaug-a, u vreme kad je bio gostujući naučnik u Xerox PARC-u. Ideja je bila da se premosti jaz između ljudskog uma (mentalnog modela) i podataka u računaru (modela u softveru). Prema tome, u centru bi trebala da bude reprezentacija korisničkih informacija o domenu. Dalje, treba da postoji i deo pomoću kojeg bi korisnik mogao da posmatra i menja te informacije tj. neki editor. Konačno, treba da postoji i deo koji bi služio za koordinaciju sposobnosti tih editora. Nazvavši te delove modelom, pogledom (eng. View) i kontrolerom (eng. Controller), respektivno, tako je nastala MVC arhitektura (skraćenica od Model-View-Controller). [Pawson 2004]

Kao što Reenskaug priznaje u predgovoru [Pawson 2004], on nikad nije javno objavio svoju kreaciju, jer je naivno mislio da će ljudi razumeti suštinu ideje. Međutim, u sledećoj verziji Smalltalk-a (nazvan Smalltalk-80), MVC je postao jedno puko tehničko rešenje za razdvajanje ulaza, izlaza i informacije, pri čemu je po njegovom

23 U prethodnim paradigmama stanje je bilo razdvojeno od ponašanja, jer su ljudi uglavnom menjali samo stanje tj. podatke, koje su zatim pustili kroz neku funkcionalnost. Međutim, u simulacijama je realno da će ljudi hteti da menjaju ne samo podatke, nego i ponašanje, tj. funkcionalnost. [Pawson2004]

34

mišljenju najvažniji pojam, ljudski um, ostao izostavljen.

Frank Buschmann definiše MVC arhitekturu kao arhitektonski obrazac, koji „razdvaja interaktivnu aplikaciju na tri dela. Model sadrži srž funkcionalnosti kao i podatke. Pogledi prikažu informacije za korisnika, a kontroleri rukuju ulazom24. Pogledi i kontroleri zajedno čine korisnički interfejs“. [Buschmann et al. 1996]

Iako je MVC obrazac predstavljen u Smalltalk-80 bio nešto drugo u odnosu na originalnu ideju, barem je očuvao ideju da u delu za model (slovo „M“), objekti i dalje enkapsuliraju stanje i ponašanje. [Pawson 2004] Međutim, iako je MVC arhitektura imala dosta prednosti, kao što su razdvajanje problema25 i mogućnost stvaranja više pogleda za isti model, imala je i mane, od kojih se posebno izdvaja blisko vezivanje njenih delova. Pogledi i kontroleri su bili usko vezani, jer su deo GUI-ja, pa je menjanje nekog pogleda bilo teško zamislivo bez menjanja odgovarajućeg kontrolera, ali veći problem je bio to da su ova dva dela zavisila od modela, pa je menjati model značio menjati i sve poglede i kontrolere. [Buschmann et al. 1996]

Ovako je počelo izdvajanje određenih delova ponašanja iz dela za model u druge delove, kao što su pogledi,26 ali je ova tendencija postala još izraženija kod kontrolera. Naime, ovaj deo je u Smalltalk-80 bio zamišljen da rukuje ulazom. Međutim, definicija se kroz godine promenila, tako da je kontroler postao oruđe za slučajeve korišćenja (eng. Use-Cases), tj. mehanizam za upravljanje protoka kontrole vezan sa kompletnim korisničkim zadacima. [Pawson 2004] Martin Fowler ovo deklariše kao obrazac pod nazivom kontroler slučajeva korišćenja (eng. Use-Case Controller, skraćeno UCC), i smatra da je mnogo bliži transakcionoj skripti (proceduralnom stilu), nego modelu domena (objektno-orijentisanom stilu).27 [Fowler et al. 2002]

Iz prethodnih izlaganja je već jasno, kako su objekti iz originalne ideje da budu behavioralno-kompletni, polako postali behavioralno-slabi. Pawson zaključuje da je najveći činilac u ovoj tendenciji zapravo iskrivljenje originalne ideje o MVC arhitekturi, preciznije rečeno, UCC obrazac. U slučaju da se za izradu softvera koristi MVC, korišćenje UCC obrasca je skoro neminovno, iako je ideja o MVC arhitekturi bila dosta drugačija. Ova najnovija varijanta MVC-a se inače dobro uklapa i u višeslojne arhitekture. Prema tome, čak i ako razvojni tim ne koristi eksplicitno MVC arhitekturu ili UCC obrazac, on ih indirektno koristi kroz višeslojne arhitekture. [Pawson 2004]

Kao što će se videti, prethodno iznet zaključak o behavioralno-slabim objektima će imati veliki uticaj pri kreiranju Naked Objects pristupa.

24 Pod pojmom ulaz (eng. Input) se prvenstveno misli na ulazne uređaje poput miša, tastature, itd. Pomoću ovih uređaja korisnik utiče tj. vrši se interakcija na izlaz (eng. Output) kao što je monitor, preciznije rečeno: prozori na ekranu, meniji, dugmadi, itd. [Pawson 2004]

25 Pošto su model, pogled i kontroler razdvojeni, ako korisnik zahteva neki novi korisnički interfejs, dovoljno je menjati samo pogled i/ili kontroler. [Buschmann et al. 1996]

26 Na primer, ako je za neko računanje potrebno menjati i način ispisa rezultata na ekranu (tj. pogled), onda se premeštanjem koda za računanje iz modela u deo za pogled može zaštititi model od ovih modifikacija.

27 Model domena i transakciona skripta su opisani u odeljku 2.2.

35

3.2. Šta je Naked Objects pristup?Kao što je izneto u prethodnom odeljku, objekti su originalno bili zamišljeni da

budu behavioralno-kompletni, tj. da enkapsuliraju svoje stanje i ponašanje. Međutim, oni su kasnije sve više i više počeli da gube ovo svojstvo. U današnje vreme, može se reći da su objekti koji predstavljaju poslovne entitete, zapravo behavioralno-slabi. Po Pawson-u, posledica ove tendencije je smanjenje agilnosti sistema. [Pawson 2004]

Drugi problem koji se često primećuje kod današnjih sistema je da oni tretiraju korisnika kao nekog pratioca tokova: korisnik izabere željenu akciju, a onda ga aplikacija vodi kroz celi postupak, često korak po korak. Umesto prisiljavanja korisnika na određen način rešenja, možda bi bilo zgodnije da ga sistem tretira kao nekog ko sam rešava probleme: treba korisniku dati slobodu da reši te probleme onako kako želi. Drugim rečima, treba dati moć u ruke korisnika, tj. treba ih osposobiti, osnažiti. [Pawson 2004] Sa ovim se u potpunosti slaže i autor MVC arhitekture, Trygve Reenskaug, koji u predgovoru [Pawson 2004] ističe da postoje dve tradicije u primeni računara: u prvoj se koristi računar da osposobi njegove korisnike, a u drugoj se koristi računar da kontroliše njegove korisnike, pri čemu izgleda da u današnje vreme ova druga tradicija dominira.

Inače, programski jezik Smalltalk je pripadao prvoj tradiciji. Za razliku od programskog jezika Simula, koji nije imao podršku za korisnički interfejs, Smalltalk je imao mogućnost proširenja sa interaktivnim GUI-jem. U Smalltalk-u, objekti su bili zamišljeni da „predstave sebe“ korisniku na direktan način – ponovo aludirajući na behavioralnu-kompletnost. [Pawson 2004]

Iako je Eric Evans svoj Domain-Driven Design predstavio 2003. godine, otprilike u isto vreme kad i Pawson svoj Naked Objects pristup, poznato je da ideje DDD-a datiraju unazad sve do nastanka objektne-orijentisanosti. Kako Pawson u predgovoru [Haywood 2009] ističe, Domain-Driven pristup se dobro uklapao u originalne ideje objektne-orijentisanosti, ali je njegovo korišćenje u praksi bilo dosta frustrirajuće iskustvo. Pre svega, one članove tima koji nisu bili programeri, je bilo skoro nemoguće angažovati da prihvate UML, ali su naravno uvek bili spremni da pregledaju neki funkcionalan prototip, tj. da vide rezultate. Međutim, odbacivanje UML-a je sa sobom donelo rizik da se oslabi kvalitet sveprisutnog jezika.

Ova tri prethodno navedena problema su dala motivaciju Richard Pawson-u da napravi jedan pristup pravljenju softvera koji bi na neki način rešio ove probleme. Ovaj pristup bi trebao pre svega da podstiče agilnost sistema, što znači da bi objekti trebali da budu behavioralno-kompletni, kojim se smanjuje njihovo usko vezivanje. Dalje, potrebno je osposobiti korisnike da rešavaju probleme, što znači da im treba dati mogućnost da vide te objekte. I konačno, u razvoj treba aktivno uključiti sve članove tima, tj. treba nekako potpomoći razvoj softvera. Pošto se veliki deo vremena utroši na razvoj GUI-ja, mora se uvesti neki mehanizam s kojim bi se ovaj postupak ubrzao radi postizanja još većeg nivoa agilnosti. Prema tome, GUI bi trebalo da se kreira automatski. Pošto korisnici s jedne strane vole da vide „izražajne“ objekte, a s druge strane, model domena bi trebao da bude zajednički jezik celog tima, GUI bi zapravo prikazao istu stvar ne samo za članove razvojnog tima, nego i za korisnike, a to su poslovni objekti. [Pawson 2004] [Haywood 2009]

Iz ovih ideja je nastao pojam Expressive Objects, u prevodu „izražajni objekti“,

36

koji je autor koristio sve do 2001. godine, kad ga je zamenio pojmom Naked Objects, u prevodu „nagi objekti“ ili „goli objekti“. Iza ovog naziva stoji ideja da što se korisnika tiče, on ili ona zapravo posmatra i manipuliše golim poslovnim tj. domenskim objektima. Pojam domenskih objekata (eng. Domain Object) označava objekte koji se nalaze u domenskom sloju tj. oni su zapravo objekti modela domena. Naravno, nije samo gore naveden pojam važan, nego i sam pristup koji se zasniva na ovom pojmu. Prva knjiga koja je izdata na ovu temu se jednostavno zvala „Naked Objects“, od autora Richard Pawson-a i Robert Matthews-a, i pojavila se 2002. godine. Pawson je svoju doktorsku disertaciju na univerzitetu u Dublin-u, Irskoj, isto pod nazivom „Naked Objects“, odbranio dve godine kasnije, u junu 2004. [Pawson 2004] Iako je do sada korišćen termin „pristup“, Naked Objects se u drugim radovima kategoriše kao arhitektonski obrazac [Läufer 2008] [Haywood 2009], pa će se u daljem radu oba termina koristiti naizmenično.

Aruna Raja dobro sumira suštinu Naked Objects pristupa kroz sledeća tri principa: [Raja & Lakshmanan 2010]

1. Cela poslovna logika bi trebala da se enkapsulira u domenske objekte;

2. GUI bi trebao da bude odraz domenskih objekata, uključujući i korisničke zahvate, kao što su kreiranje i pribavljanje domenskih objekata;

3. GUI bi trebao da se automatski kreira iz domenskih objekata.

Da bi se zadovoljili gore navedeni principi, Naked Objects pristup uvodi jedan obrt u originalnu MVC arhitekturu, zahtevajući da deo za pogled i kontoler (slova „V“ i „C“) budu potpuno generični, što znači da programeri nemaju pristup tim delovima. U skladu sa ovim, poslovna aplikacija bi trebala da se implementira isključivo u vidu domenskih objekata, koji se nalaze u delu za model (slovo „M“), forsirajući ih da na ovaj način oni budu behavioralno-kompletni. Ova osobina Naked Objects obrasca je i njegova prednost ali i mana: jednostavno ne postoji drugo mesto gde bi se smestilo ponašanje sem da se ono stavi u domenske objekte. [Pawson 2004]

Prevođenjem prethodnog pasusa na „jezik“ četvoro-slojne arhitekture se dobija sledeća situacija (Slika 3): drugi sloj (sloj poslovne logike, tj. kontrolni sloj) više ne postoji, jer se ponašanje enkapsulira zajedno sa podacima poslovnih objekata. Dalje, najviši prezentacioni sloj je u potpunosti automatizovan, pa programeri više nemaju potrebe da sami implementiraju GUI. Jedini sloj o kojem programeri moraju brinuti je treći tj. domenski sloj (srce poslovnog softvera po Evans-u [Evans 2003]) gde se nalazi model domena, tj. domenski objekti.28 [Pawson 2004] Naravno, u slučaju da je perzistencija u aplikaciji važna, na primer u vidu relacione baze podataka, programeri će i dalje morati da o četvrtom sloju brinu posebno.29

28 Ovde se mora napomenuti da pošto se domenski objekti nalaze u domenskom sloju, korisnik striktno rečeno ipak ne posmatra i barata sa domenskim objektima unutar GUI-ja, nego sa pogledima i kontrolerima koji se nalaze u prezentacionom sloju. Međutim, pošto Naked Objects obrazac zahteva strogu korespondenciju između ova dva sloja, može se reći da je iluzija – da korisnik zapravo posmatra i manipuliše domenskim objektima – savršena. [Pawson 2004]

29 Zapravo, u Naked Objects framework-u, koji je jedna od implementacija Naked Objects obrasca, i sloj podataka je automatizovan, ukoliko se koristi delimična perzistencija u radnoj memoriji ili perzistencija u vidu XML baze podataka. Situacija se menja samo u slučaju da se koristi perzistencija u relacione baze podataka. Naked Objects framework će se detaljno predstaviti u sledećem poglavlju.

37

Postavlja se pitanje, kako nepostojanje sloja poslovne logike utiče na automatski generisan GUI? Kao što Pawson ističe, korisnički interfejs je kod Naked Objects obrasca strogo objektno-orijentisan. Ovakvi interfejsi se nazivaju objektno-orijentisanim korisničkim interfejsima (skraćeno OOUI). Ideja OOUI-ja je prosta: korisnik pri posmatranju i manipulisanju sa objektima mora imati osećaj da on zaista barata sa njima. [Pawson 2004]

Na osnovu iznetih podataka, Pawson zaključuje da korišćenje Naked Objects obrasca za razvoj softvera sa sobom nosi četiri koristi: [Pawson 2004]

k1 Podstiče korišćenje behavioralno-kompletnih objekata, činivši da sistem bude agilniji;

k2 Ubrzava razvojni ciklus, pre svega zato što automatizuje kreiranje korisničkog interfejsa;

k3 Nudi zajednički jezik između programera i korisnika (isto kao sveprisutni jezik kod DDD-a), jer se Naked Objects može koristiti već na samom početku projekta;

k4 Osposobljava korisnike uz pomoć OOUI-ja, koji podstiče korisnike da rešavaju svoje probleme onako kako žele, umesto da ih vodi računar.30

Suština Naked Objects pristupa lepo zvuči u teoriji, ali to nije dovoljno.

30 O ovim koristima će biti više reči i kasnije u odeljku 3.4, gde će se detaljnije analizirati agilnost pristupa.

38

Slika 3: Naked Objects pristup na „jeziku“ klasične četvoro-slojne arhitekture: sloj poslovne logike (tj. aplikativni sloj) je nestao, a najviši, prezentacioni sloj je automatizovan. Izvor: [Pawson 2004].

Prezentacioni sloj

Sloj poslovne logike

Domenski sloj

Sloj podataka

Klasični četvoro-slojni pristup Naked Objects pristup

Potrebno je njegove koristi pokazati i u praksi, prema tome, potrebno ga je i implementirati, zato Naked Objects nije samo arhitektonski obrazac, nego i softverski framework. [Haywood 2009] Jedna implementacija ovog pristupa treba da zadovolji barem dva uslova: prvo, treba da implementira prezentacioni sloj koji bi se kreirao automatski kod pravljenih aplikacija; i drugo, ovaj prezentacioni sloj mora da ima mehanizam za identifikaciju domenskih objekata u domenskom sloju radi njihovog predstavljanja u GUI-ju. [Pawson 2004] Pawson je direktno učestvovao u kreiranju dva ovakva framework-a:

• Naked Object Architecture (NOA) – ovaj framework je nastao radi implementacije jedne aplikacije za potrebe Irske vlade.

• Naked Objects framework (NOF) – ovaj otvoren (open-source) framework je pisan u Javi i inicirao ga je Robert Matthews, koautor knjige „Naked Objects“.

Više reči o NOA framework-u će biti u odeljku 3.5.1, gde će se malo detaljnije predstaviti i aplikacija Irske vlade, dok će sledeće poglavlje u celosti biti posvećeno Naked Objects framework-u. Ali pre toga je potrebno detaljnije osvrnuti se i na dve karakteristične osobine samog obrasca, tačnije na njegov OOUI i na njegovu agilnost, koje će biti opisane u sledeća dva odeljka.

3.3. Objektno-orijentisani korisnički interfejs (OOUI)U prethodnom odeljku je bilo malo reči i o korisničkom interfejsu Naked

Objects pristupa. Naime, GUI je u ovom slučaju objektno-orijentisan, a takav interfejs se naziva objektno-orijentisani korisnički interfejs (eng. Object-Oriented User Interface, skraćeno OOUI). Jedan OOUI se može vizuelno zamisliti na više načina, ali je možda najjednostavnije na sledeći: objekti su predstavljeni ikonicama, pri čemu se stanje objekta može proveriti duplim klikom na objekat (tada se otvara prozor sa podacima objekta), a na ponašanje se može uticati tako što se klikne sa desnim tasterom miša na ikonicu, pojaviće se iskačući meni sa listom akcija za taj objekat, a zatim se izabere željena akcija. Postavlja se još pitanje, kako se realizuju veze između objekata u jednom OOUI-ju, npr. kako povezati neki roman sa piscem? Jedan od načina je korišćenje „prevuci i otpusti“ (eng. Drag and Drop) funkcionalnosti miša, tj. vući ikonicu romana na ikonicu pisca.

Zapravo, ideja o OOUI-ju uopšte nije nova, a neki njeni elementi datiraju unazad sve do 1960-ih godina, kad su se pojavili prvi pokušaji kreiranja GUI-ja. Iako programski jezik Smalltalk svakako nije bio prvi pokušaj kreiranja jednog GUI-ja31, ipak se može zaključiti da je bio prvi uspešni. Smalltalk32 je radio na Xerox-ovom Alto računaru (predstavljen 1973. godine) koji je već imao rasterski ekran i miš. Koncept prozora (eng. Windows) je već u to vreme postojao. Smalltalk je bio prvi jezik koji se mogao proširiti korisničkim interfejsom koji je imao preklapajuće prozore i iskačuće menije (Slika 4). Jedno kasnije okruženje za programiranje pod nazivom Xerox Cedar

31 Ova zasluga pripada naučnicima Douglas Engelbart-u i Ivan Sutherland-u. [Pawson 2004]32 Iako je Smalltalk za većinu ljudi predstavljao jedan programski jezik, on je zapravo bio jedno

integrisano okruženje za programiranje, i obuhvatao je programski jezik (isto pod nazivom Smalltalk), debugger, virtuelnu memoriju, editor i postrojenje za korisnički interfejs. U Xerox-u, ime programskog jezika se često podudaralo sa nazivom okruženja. [Lampson 1986]

39

(koji je radio na Xerox-ovom Star sistemu, tačnije na njegovom hardveru Dorado), koje je cvetalo u prvoj polovini 1980-ih godina, je unelo druge novine kao što su male reprezentacije objekata i prozora pod nazivom ikonice (eng. Icons), kao i padajuće menije (Slika 5). [Lampson 1986]

Međutim, iako je veza između OOUI-ja i GUI-ja jasna, nisu svi GUI-jevi objektno-orijentisani. Kako Dave Collins ističe, podatak da je GUI bio napravljen u objektno-orijentisanom programskom jeziku još ne mora da znači da je i OOUI. Jedan OOUI mora imati i sledeće osobine: [Collins 1995]

40

Slika 4: Korisnički interfejs Smalltalk-a sa preklapajućim prozorima i iskačućim menijima. Izvor: [Lampson 1986].

• korisnici sagledaju i deluju na objekte;

• korisnici mogu grupisati objekte u zavisnosti od njihovih ponašanja33;

• u kontekstu šta korisnici žele da rade, svi objekti u interfejsu se uklapaju u jednu koherentnu obuhvatnu reprezentaciju.

Važno je napomenuti da objektna-orijentisanost korisničkog interfejsa ne mora da implicira objektnu-orijentisanost modela koji leži ispod. Drugim rečima, osobine OOUI-ja važe striktno samo za sam interfejs, a ne nužno i za model koji se predstavlja pomoću njega. Naked Objects obrazac se ovde suštinski razlikuje od drugih pristupa, jer forsira korespondenciju između modela i GUI-ja. [Pawson 2004] Prema tome, ako je GUI odraz domenskih objekata koji su još i behavioralno-kompletni, onda je i GUI objektno-orijentisan. Drugim rečima, objektna-orijentisanost GUI-ja je samo posledica objektno-orijentisanog i behavioralno-kompletnog modela domena.

Po Pawson-u, jako važna osobina jednog OOUI-ja je da koristi tzv. „imenica-glagol“ (eng. Noun-Verb) stil interakcije – bukvalno onako kako je opisano u prvom pasusu ovog odeljka: korisnik izabere objekat (imenica), a zatim ponašanje (glagol) koje

33 Po Pawson-u, ova druga osobina zapravo potvrđuje behavioralnu-kompletnost objekata unutar jednog OOUI-ja. [Pawson 2004]

41

Slika 5: Korisnički interfejs Cedar-a sa ikonicama i padajućim menijima. Izvor: [Lampson 1986].

je asocirano sa tim objektom. Xerox-ov Star sistem, koji se smatra prvim pravim primerom jednog OOUI-ja, je takođe koristio ovaj stil interakcije. Iako su neke ideje ovog stila direktno uticale na kasnije operativne sisteme poput IBM-ov OS/2 i Microsoft-ov Windows, ipak se može reći da danas uglavnom dominira obrnut stil interakcije, tj. „glagol-imenica“ (eng. Verb-Noun) stil, tj. korisnik prvo izabere zadatak iz menija, a zatim određuje nad čim želi izvršiti ovu akciju. [Pawson 2004]

Međutim, upotrebljivost (eng. Usability) jednog GUI-ja je dosta diskutabilna tema, a isto važi i za OOUI. Po zvaničnom ISO/IEC 9126-1:1992, upotrebljivost je „sposobnost softverskog proizvoda da omogući konkretnim korisnicima da postignu konkretne ciljeve uz poštovanje kriterijuma efikasnosti, produktivnosti, bezbednosti i zadovoljstva u konkretnom kontekstu upotrebe“. Pawson ističe da je jedna važna osobina upotrebljivosti zapravo sposobnost osposobljavanja, u smislu da im treba dati moć da reše probleme onako kako žele [Pawson 2004], što je 2002. godine naglasio i na OOPSLA (skraćenica od Object-Oriented Programming, Systems, Languages & Applications) konferenciji, predstavljajući publici Naked Objects pristup i framework.

Međutim, na konferenciji je dobio oštre kritike od Larry Constantine-a, stručnjaka za upotrebljivost grafičkih korisničkih interfejsa. On je kritikovao ne samo Naked Objects-ov automatski generisan korisnički interfejs, nego i OOUI-je generalno. Smatrao je da će zbog automatizacije GUI-ja sve aplikacije u suštini izgledati isto. Takođe je kritikovao Naked Objects-ovu „jedna veličina odgovara svima“ filozofiju (u smislu da jedno rešenje može rešiti sve probleme), jer je svaka aplikacija na svoj način unikatna, što znači da će i njihovo korišćenje u GUI-ju zavisiti od konteksta. Smatrao je da su OOUI-jevi takođe problematični, zbog više razloga. Pre svega, oni nisu zgodni za neiskusne korisnike, jer ih forsira na neki način da uče žargon objektne-orijentisanosti, kao što su objekti i veze između njih. Takođe, način baratanja sa jednim OOUI-jem je suviše komplikovan: iskačućim (ili kontekst) menijima se može pristupiti samo desnim klikom na objekat, što znači da je ponašanje sakriveno, a objekti se mogu povezati samo korišćenjem Drag and Drop akcije pomoću miša.34 Konačno, Constantine je kritikovao i „imenica-glagol“ stil interakcije, ističući da taj stil samo nepotrebno povećava broj otvorenih prozora u aplikaciji, i smatrajući da je ljudima prirodnije da prvo izaberu akciju, a zatim objekat („glagol-imenica“ stil). [Constantine 2002]

Iako se Constantine nije složio sa principima Naked Objects pristupa, čak i optuživši Pawson-a i Matthews-a da je njihov cilj da stručnjaci za upotrebljivost GUI-ja izgube posao tako što firmama nude framework koji generiše GUI umesto njih, štedeći novac, on je ipak istekao da Naked Objects sa sobom nosi jednu važnu poruku: da su korisnici potcenjeni, i da ih treba više osposobiti da rešavaju svoje probleme. [Constantine 2002] Po Pawson-u, ova poslednja konstatacija samo potvrđuje tvrdnju da zajednica za upotrebljivost nije posvetila dovoljno pažnje na važnost osposobljavanja korisnika. [Pawson 2004]

34 Ovde treba napomenuti da u to vreme još nije postojao HTML pogled kod Naked Objects framework-a. Ovaj pogled koristi čist HTML kod unutar Internet brauzera, koji isključuje mogućnost desnog klika i Drag and Drop funkcionalnosti i menja ih alternativnim rešenjima. HTML pogled će biti predstavljen u sledećem poglavlju.Zapravo, Naked Objects framework može da ima više pogleda, a u slučaju da nijedan ne odgovara potrebama, programeri su slobodni da kreiraju svoj, u skladu sa idejom MVC arhitekture.

42

3.4. Agilnost Naked Objects pristupaKao što Craig Larman ističe, agilnost je zapravo „rapidan i fleksibilan odgovor

na promene“. [Larman 2003] Prethodno je već bilo navedeno da Naked Objects pristup povećava agilnost sistema. Zapravo, ova osobina je bila jedna od najvažnijih namena samog pristupa i zato postoji potreba da se oblast detaljnije ispita.

Prvo će biti navedene vrste agilnosti, i kako ih Naked Objects eksploatiše. Zatim će biti nešto reči o smernicama pristupa koje pomažu da se postigne još veći nivo agilnosti. Ove smernice ili putokazi zapravo opisuju način prilagođavanja pristupa sa metodologijama razvoja softvera. Konačno, biće ispitivana i kompatibilnost obrasca sa par ovakvih metodologija.

3.4.1.Vrste agilnostiNaked Objects pristup je napravljen tako da bude agilan. Pri kraju odeljka 3.2 su

bile navedene četiri koristi za ovaj obrazac, a u ovom odeljku će biti jasno, da su one zapravo povezane sa agilnošću. Naked Objects pristup direktno podstiče dve vrste agilnosti: [Pawson & Wade 2003]

• Stratešku agilnost (eng. Strategic Agility) – omogućava jednostavnije menjanje sistema radi bržeg zadovoljenja korisničkih zahteva. U Naked Objects pristupu se ova vrsta agilnosti postiže korišćenjem behavioralno-kompletnih objekata. Pošto ovi objekti enkapsuliraju ne samo stanje nego i svoje ponašanje, sve promene će unutar nekog poslovnog koncepta biti lokalne. Strateška agilnost je zapravo korist k1 koja se spominje u odeljku 3.2.

• Operativnu agilnost (eng. Operational Agility) – pruža sistemu fleksibilnost pri svakodnevnoj upotrebi istog. Pošto se većina aplikacija koristi uz pomoć grafičkog korisničkog interfejsa, jasno je da ova vrsta agilnosti asocira pre svega na GUI. Pošto Naked Objects ima objektno-orijentisani interfejs (OOUI), on prirodno tretira korisnika kao rešavaoca problema, a ne kao pratioca tokova, i tako osposobljava ljude da reše svoje probleme na sopstveni način. Operativna agilnost je korist k4.

Ove dve vrste agilnosti se odnose na menjanje i na korišćenje softvera, respektivno. Međutim, Naked Objects pristup može povećati i agilnost samog ciklusa razvoja posmatranog softvera, i to na dva načina: [Pawson & Wade 2003]

• Poboljšanjem komunikacije između članova tima – ovo je posebno važno u fazi analize tokom ispitivanja korisničkih zahteva. Pošto se kod Naked Objects pristupa model domena bukvalno preslikava u OOUI, može se reći da korisnici i domenski eksperti koriste isti model kao i programeri. Na ovaj način Naked Objects poboljšava i osnovne principe Domain-Driven Design-a. Budući da se koristi isti model i od strane programera i od strane korisnika, jasno je da će oni pričati istim jezikom, (sveprisutni jezik iz DDD-a). S druge strane, generisan OOUI može zameniti UML pri komunikaciji, i tako se zadovoljava i princip Model-Driven Design-a iz DDD-a. Ova stavka je korist k3.

• Ubrzanjem ciklusa razvoja softvera – Naked Objects pristup eliminiše potrebu

43

za dizajniranje i razvoj GUI-ja. Sve što je potrebno uraditi je to da programeri naprave domenske objekte, tj. klase koje enkapsuliraju i stanje i ponašanje, nakon čega će se GUI sam izgenerisati. Ovo ne samo da ubrzava razvoj35, nego i eliminiše potrebu traganja za bagovima unutar GUI-ja. Ova stavka je korist k2.

Iz iznetog se može zaključiti da Naked Objects pristup povećava agilnost u skoro svim segmentima. Međutim, za postizanje solidnog nivoa agilnosti je potrebno ispoštovati i neka pravila u obliku smernica za razvoj softvera. One su opisane sledeće.

3.4.2.Smernice za dizajniranje i razvoj sistema po Naked Objects pristupuJasno je da nivo agilnosti Naked Objects pristupa pre svega zavisi od njegovog

načina korišćenja. Takođe, kroz praktično iskustvo njegovog autora se pokazalo, da nisu svi softverski projekti podjednako pogodni za ovaj pristup. Kao rezultat, nastale su neke smernice ili putokazi koji imaju za cilj da pojednostave korišćenje ovog pristupa radi postizanja većeg nivoa agilnosti.

Pawson je formirao ukupno sedam smernica. Od tih, prve dve bi trebalo da se koriste pre startovanja projekta. One se mogu posmatrati i kao preduslovi za uspešno korišćenje Naked Objects pristupa. One su sledeće: [Pawson 2004]

• Izabrati projekte sa takvim karakteristikama koji bi imali najveće koristi pri korišćenju Naked Objects pristupa.Jasno je da se ova smernica pre svega odnosi na koristi koje su nabrojane u odeljku 3.2. Tako na primer, ako je u posmatranoj aplikaciji potrebno da korisnici budu tretirani kao rešavaoci problema, a ne kao pratioci tokova, onda bi ti sistemi imali korist od Naked Objects pristupa (korist k4). Projekti sa „nestabilnim“ korisničkim zahtevima bi takođe bili dobri kandidati. Naime, kod ovih projekata postoji velika verovatnoća da će se ti zahtevi menjati tokom (ili posle) razvoja, zahtevajući veći nivo fleksibilnosti.

Međutim, Pawson upozorava, da u ovom kontekstu Naked Objects ima i neka ograničenja koja se ne smeju ignorisati. Pre svega, automatsko generisanje GUI-ja isključuje mogućnost ručnog pravljenja istog. Iako ova osobina oslobađa programere od dodatnog tereta, u nekim situacijama može biti nepoželjna, npr. kad treba optimizovati GUI za izvršavanje određenih zadataka ili kad ga treba prilagoditi za potrebe pojedinačnih korisnika36. Međutim, ako ništa drugo, pristup bi se mogao u ovim slučajevima koristiti u početnim fazama razvoja.

Drugo ograničenje je to da se OOUI malo teže uči od strane korisnika, pa im je potrebno dati vremena da se naviknu. Ovo nije problem kod onih aplikacija koje

35 Jasno je da bilo kakva pomoć pri generisanju GUI-ja ima jasnu korist, a automatsko generisanje možda još veću. U prilog ove tvrdnje ide i podatak da za veliki broj softverskih projekata, kreiranje GUI-ja oduzima suviše mnogo vremena, a zauzima i značajnu količinu prostora u programskom kodu: po nekim istraživanjima, 50% ukupnog vremena provedenog na razvoju softvera odlazi na kreiranje GUI-ja, a 48% izvornog koda služi za njegovo kreiranje. [Kennard & Leaney 2011]

36 U ovu kategoriju spadaju npr. pristupačni GUI-jevi za osobe sa invaliditetom, ili kad je potrebno napraviti neki lepši dizajn za GUI zbog marketinških razloga.

44

se svakodnevno koriste od strane istog skupa korisnika, pošto je njihovo treniranje u firmi lako izvodljivo. Međutim, problem mogu da predstavljaju tzv. samouslužni (eng. Self-Service) sistemi koji se koriste od strane širokog sloja stanovništva, kao što su bankomati. Pošto ove aplikacije ne mogu ništa pretpostaviti o korisnicima, GUI mora biti napravljen tako da vodi korisnika.

Treće moguće ograničenje može biti slučaj sa serijskim obrađivanjem (eng. Batch-Processing), koje u ovom slučaju označava zajedničko procesiranje većih količina podataka unutar relacionih baza podataka. Ovo zapravo nije Naked Objects-ova direktna krivica, nego proizilazi iz činjenice da pristup forsira korišćenje lepog objektno-orijentisanog dizajna, koji možda nije tako lep u svetu relacionih baza podataka, što može dovesti do smanjenja performansi.

Na osnovu prethodno iznetih preporuka i ograničenja, Pawson je napravio jedan praktičan podsetnik za ovu smernicu, koji glasi:

Naked Objects pristup se najviše preporučuje kod onih sistema kod kojih je bilo koji od sledećih iskaza tačan:

◦ Korisno je korisnika tretirati kao rešavaoca problema umesto kao pratioca tokova,

◦ Buduća poslovna agilnost je od presudnog značaja,

◦ Zahtevi su nestabilni;

… i svi sledeći iskazi su tačni:

◦ Ne postoji jasno obrazloženje za ručno kreiranje GUI-ja,

◦ Ciljani korisnici bi trebali svakodnevno da koriste sistem,

◦ Sistem se neće baviti zahtevnim serijskim obrađivanjem.

• Preduslovi startovanja dobrog Naked Objects projekta su: dobre veštine oko objektno-orijentisanog modeliranja, odgovarajući framework i uzajamno razumevanje samog pristupa.Ako posmatrani projekat zadovoljava uslove iz prve smernice, potrebno je ispitati, da li i razvojni tim raspolaže sa nekim preduslovima. Pre svega, potrebno je da tim ima bar jednog člana sa jakim iskustvom u objektno-orijentisanom modeliranju. Drugi preduslov je izbor dobrog framework-a i njegovo solidno poznavanje. Danas još ne postoji velik izbor framework-ova, ali se smatra da je open-source Naked Objects framework solidan izbor. Konačno, treći preduslov je da svi članovi tima, bez obzira na njihove uloge, moraju razumeti koncept Naked Objects pristupa. Zadovoljiti ovaj preduslov je lakše nego što se misli, pre svega zato što Naked Objects-ov OOUI efektno povezuje sve članove tima.

Na osnovu prethodne dve smernice, razvojni tim može doneti odluku da li uopšte ima smisla početi razvoj po Naked Objects pristupu. U slučaju da je odgovor potvrdan, može se preći na treću smernicu, koja efektno razbija razvoj na dve faze: [Pawson 2004]

45

• Struktuirati projekat na dve posebne faze: na istraživanje i na isporuku.U fazi istraživanja (eng. Exploration Phase) bi jedan manji tim (sa par programera i korisnika uključujući i jednog domenskog eksperta) imao zadatak da proceni izvodljivost samog projekta. U ovoj fazi, koja inače teče u iterativnom stilu, tim bi se bavio izradom prototipova i modeliranjem domena radi definisanja korisničkih zahteva, uočavanja potencijalnih izazova i testiranja poslovnih scenarija. Ova faza dosta liči na fazu analize iz klasičnih metodologija razvoja, ali sa jednom bitnom razlikom: u fazi istraživanja su i programeri aktivno uključeni. Takođe, umesto kreiranja standardnih artefakata poput pisanih dokumenata ili UML dijagrama, ono što članove tima čvrsto povezuje je zapravo Naked Objects: automatski generisan GUI transformiše model u opipljiv i upotrebljiv oblik. Preporučuje se strogo timebox-ovanje ove faze (tj. određivanje vremenskog okvira), inače bi se faza mogla suviše produžiti: po Pawson-u, okvir od četiri nedelje je idealan za većinu projekata. [Pawson & Wade 2003]

Na kraju ove faze, razvojni tim bi trebao da ima generalnu predstavu o celom projektu, i na osnovu iskustva iz ove faze treba doneti odluku o izvodljivosti projekta: da li vredi nastaviti razvoj i ako jeste, na koji način. U slučaju pozitivne odluke, počinje faza isporuke (eng. Delivery Phase), koja bi takođe trebala da teče na iterativni način. Treba naglasiti da bi razvojni tim (koji bi sad uključio širi krug ljudi) iz faze istraživanja preneo samo stečeno iskustvo, ali ne i izvorni kod. Drugim rečima, programiranje bi trebalo da ide ispočetka.37

Sledeće dve smernice (četvrta i peta) se specifično odnose na fazu istraživanja: [Pawson 2004]

• Tokom faze istraživanja, identifikovati objekte i njihove odgovornosti direktno, a ne pomoću slučajeva korišćenja.Slučajevi korišćenja (eng. Use-Cases) su danas opšte prihvaćeni u softverskom svetu. Oni mogu biti veoma korisni, ali se ne sme zaboraviti, da (kao što je već spomenuto u odeljku 3.1) oni promovišu proceduralni stil razmišljanja, što nije u skladu sa objektno-orijentisanim načinom. Šta više, oni se koriste i pre nego što u projektu počinje objektno-orijentisano modeliranje, ometajući identifikaciju pravih domenskih objekata. Iako ovo ne bi trebalo da bude ozbiljan problem, s obzirom da su objekti danas u većini slučajeva behavioralno-slabi, problem postaje vidljiv kod Naked Objects pristupa koji forsira da objekti budu behavioralno-kompletni. Prema tome, slučajevi korišćenja ne bi trebali da se koriste u ovoj fazi. Međutim, oni mogu biti korisni u fazi isporuke. Više reči o ovome biće u smernicama koje se odnose na fazu isporuke.

• Tokom faze istraživanja, definicije objekata treba zapisati direktno u vidu programskog koda.Ova smernica na prvi pogled može da deluje čudno, imajući u vidu da ljudi koji

37 Razlog za ovo leži u riziku da se ne bi preneli bagovi iz prve faze u drugu. Uz to, ove dve faze su dosta različite i po načinu razvoja. Naime, faza istraživanja je više optimistička u smislu da programeri mogu pretpostaviti da će podaci uvek biti ispravni, a korisnici će uvek raditi onako kako se očekuje od njih. S druge strane, faza isporuke je više pesimistička, prema tome, u ovoj fazi je potrebno misliti i na najsitnije detalje. [Pawson 2004]

46

nisu programeri teško mogu da razumeju programski kod. Međutim, kod Naked Objects pristupa, zahvaljujući automatski generisanom GUI-ju, prvi vidljivi rezultati se javljaju odmah. Ovo je mnogo moćnije rešenje od oslanjanja samo na dijagrame i dokumente.

Međutim, kod Naked Objects-ovog GUI-ja postoje neki aspekti koji nisu lako uočljivi: nasleđivanje klasa je teško uočljivo, baš kao i kardinalitet između povezanih klasa, itd. Zbog ovih razloga, preporučuje se da se pored GUI-ja po potrebi koriste i drugi artefakti. Na primer, prethodna ograničenja su lako uočljiva pomoću UML dijagrama klasa. Ako korišćeno razvojno okruženje podržava generisanje ovog dijagrama iz programskog koda, dodatni rad se praktično neće ni primetiti.

Nažalost, treba imati na umu da dodatni artefakti pri razvoju sa sobom nose jedan rizik, a to je mogućnost međusobne desinhronizacije, tj. da se promene u nekom artefaktu ne reflektuju i u drugim artefaktima. Zato čak i ako korišćeno razvojno okruženje podržava generisanje UML dijagrama, treba proveriti da li je ovo generisanje jednosmerno ili dvosmerno.

Konačno, poslednje dve smernice (šesta i sedma) se odnose na fazu isporuke. One su: [Pawson 2004]

• Razviti sistem po načinu „scenario po scenario“.Dok četvrta smernica jasno ističe da se slučajevi korišćenja u fazi istraživanja ne preporučuju, situacija je drugačija u fazi isporuke. Zapravo, slučajevi korišćenja imaju dve namene: da pomažu pri identifikaciji objekata (koji Pawson ne preporučuje) i da pomažu pri testiranju tj. validaciji sistema. Ova druga namena može biti korisna. U ovom smislu, oni se mogu posmatrati i kao scenarija, kao na nešto što ima vrednost za korisnika.38 A pošto su u prethodnoj fazi već identifikovani behavioralno-kompletni objekti, ne postoji opasnost da će slučajevi korišćenja ponovo razdvojiti stanje objekta od svog ponašanja.

Prema tome, preporučuje se da razvoj teče po scenarijama. Ovo se odlično uklapa u inkrementalni način razvoja. Scenarija identifikovana i rešena u fazi istraživanja će biti preneta u fazu isporuke. Naravno, veliki skup scenarija će se identifikovati tek u ovoj drugoj fazi, ali iskustvo stečeno u prethodnoj fazi će umnogome pomoći i u ovom poduhvatu.

• Tokom faze isporuke, zapisati svaki scenario kao test prihvatanja od strane korisnika.Ova smernica je usko vezana za prethodnu. Naime, ako su scenarija u vidu slučajeva korišćenja dobra za validaciju, zašto ih ne koristiti i u pisanju testova prihvatanja? Testovi prihvatanja od strane korisnika (eng. User Acceptance Tests) su testovi koji su pisani od strane korisnika (najčešće uz pomoć programera), i zato oni imaju vrednost za korisnike. Njima se testiraju scenarija koja bi se izvršavala tokom korišćenja sistema. Testovi prihvatanja su toliko važni u nekim metodologijama razvoja (poput Ekstremnog programiranja), da se

38 Nisu samo slučajevi korišćenja pogodni za opis scenarija. Tako na primer, storije koje se koriste u Ekstremnom programiranju imaju sličnu svrhu.

47

oni pišu pre nego što programeri počinju implementaciju storije. Smatra se da je storija implementirana, kad su svi testovi, koji se vezuju za nju, uspešni.

Ako bi ovi testovi prihvatanja bili pisani u izvršnom obliku, programeri bi ih mogli izvršiti i tokom implementacije. Međutim, njihovo pisanje u ovom obliku nije lako, pošto se vezuju za GUI (jer korisnici komuniciraju sa sistemom uz pomoć GUI-ja). Simuliranje miša i tastature bi se moglo rešiti korišćenjem makroa i sličnih mehanizama, ali je takvo rešenje bagovito. Zato je bolje da se pišu klasični testovi, ali uz pomoć naredbi na višem nivou apstrakcije39, međutim, ovo rešenje ne bi primetilo bagove unutar GUI-ja. Srećom, Naked Objects obrazac olakšava pisanje ovih testova iz dva razloga. Prvi, sve što korisnik vidi u GUI-ju se direktno preslikava iz domenskog sloja. Drugi, GUI je potpuno generičan, prema tome, ako se zna da korišćen GUI nema bagova, onda se može pretpostaviti da ih ni aplikacija (koja koristi taj GUI) neće imati.

Adekvatno korišćenje ovih smernica će razvoj sistema učiniti mnogo agilnijim. Međutim, postavlja se pitanje, kako se ove smernice uklapaju u neke postojeće metodologije razvoja? Odgovor na ovo pitanje će biti dat u poslednjem delu ovog odeljka.

3.4.3.Analiza kompatibilnosti Naked Objects pristupa sa postojećim razvojnim modelimaPrethodni delovi ovog odeljka su detaljno ispitali agilnost Naked Objects

pristupa, ali se postavlja pitanje, kako se uklapa u postojeće metodologije razvoja softvera, tj. u razvojne modele. U nastavku će se zato uraditi kratka analiza kompatibilnosti ovog pristupa sa nekim modelima.40

3.4.3.1. Klasični fazni (vodopadni) modelKlasični fazni model (ili kako se danas popularno zove, klasični vodopadni

model, eng. Classic Waterfall Model) se može nazvati prvim pravim razvojnim modelom. Iako su elementi ovog modela postojali već u 1950-im godinama, prvi formalni opis je dobio tek 1970. godine od strane Winston W. Royce-a u njegovom članku pod nazivom „Managing the Development of Large Software Systems“. [Royce1970] On je u ovom modelu definisao sledeće faze: sistemski zahtevi (eng. System Requirements), softverski zahtevi (eng. Software Requirements), analiza (eng. Analysis), dizajn (eng. Program Design), kodiranje (eng. Coding), testiranje (eng. Testing) i operacije (eng. Operations), pri čemu je ideja bila da razvoj teče iz jedne faze u sledeću i to u gore navedenom redosledu. [Royce 1970] Vremenom su se neke faze međusobno spojile, pa je tako nastao danas svima poznat model sa pet faza: analiza, dizajn, implementacija, testiranje i održavanje.41

39 Ovakve naredbe su npr. otvaranje fajlova. Ova naredba obuhvata skup drugih naredbi na nižem nivou apstrakcije: pritisni dugme za pojavljivanje dijaloga za otvaranje fajlova, pronađi traženi fajl, selektuj ga, a zatim pritisni dugme za otvaranje tog fajla.

40 Treba napomenuti da će pojam „model“ u ovom delu označavati razvojni model tj. metodologiju razvoja, a ne model domena kao u prethodnim delovima ovog rada.

41 Broj i naziv faza zapravo nije fiksiran, i razlikuje se od literature do literature.

48

Međutim, najveći problem ovog modela je bio taj da je bio suviše rigidan. Zaista, od razvojnog tima se zahtevalo da ide redom kroz faze: ako se uočila neka greška u prethodnoj fazi, vraćanje na tu fazu je bilo problematično. Prolazak više puta kroz neke faze je takođe bio nemoguć. [Larman 2003] Međutim, mora se priznati da je čak i pored raznih problema i kritika, vodopadni model bio mnogo bolji izbor od prethodnog haotičnog razvoja softvera, pošto je uspeo da uvede red u razvoj: uvek se znalo u kojoj fazi se nalazi razvoj, pravili su se artefakti kao što su pisani dokumenti, itd. [Royce 1970] Šta više, Pawson smatra da je korišćenje vodopadnog modela opravdano kod nekih tipova projekata. Naime, postoje strogo definisani projekti kod kojih se bilo kakva kasnija promena u zahtevima ne preporučuje ili nije potrebna. U ovu kategoriju uglavnom spadaju ogromni inženjerski projekti sa uhodanim skupom funkcionalnosti, koja se ne menja zbog raznih naučnih ili praktičnih razloga. Kod ovakvih projekata, nefleksibilnost razvojnog modela ne predstavlja veliki problem, a strogost se ceni. Problem je u tome da je broj ovakvih projekata relativno mali u odnosu na projekte koji se nalaze na drugoj strani „spektra“, a to su projekti kod kojih su zahtevi nestabilni. [Pawson 2004]

Kao što se zna, jedan od najvažnijih ciljeva Naked Objects pristupa je poboljšanje agilnosti samog sistema i razvojnog modela. Jasno je da zbog ovog razloga, ovaj pristup nema šta da traži u vodopadnom modelu. [Pawson 2004] Inače, nekompatibilnost ovog razvojnog modela je lako uočljiva i kod Domain-Driven Design-a. Kao što je u prethodnom poglavlju već spomenuto, DDD takođe nastoji da postiže što veći nivo agilnosti. Ideje vodopadnog modela su praktično u suprotnosti sa principima DDD-a, kao što su analiziranje znanja i Model-Driven Design: npr. vodopadni model namerno razdvaja analizu od dizajna i onemogućava programerima da prisustvuju u fazi analize, ostavivši tu fazu analitičarima. [Evans 2003]

3.4.3.2. Iterativni fazni modelNedostatak fleksibilnosti u vodopadnom modelu je možda odgovarao nekim

projektima, ali ne i ostalim. Tako je nastao iterativni fazni model (eng. Iterative Model). Ovaj model je zadržao faze definisane u vodopadnom modelu, ali je dodao jednu značajnu novinu: veze između susednih faza je zamenio dvosmernim vezama, omogućivši vraćanje na prethodnu fazu. Ovo je donekle rešilo problem nemogućnosti vraćanja na prethodnu fazu (mada još uvek nije omogućilo skokove). [Royce 1970] Treba napomenuti, da je iteracija u ovom smislu označavala samo mogućnost kretanja u suprotnom pravcu, a i to na dosta ograničavajući način. Međutim, zanimljivo je znati da Royce, autor originalnog modela, uopšte nije zahtevao da njegov razvojni model bude rigidan, nego da bude iterativan. Zapravo, slično kao i kod MVC arhitekture, došlo je do deformisanja originalne ideje.42

Iteracija se u današnjoj interpretaciji može posmatrati kao mini-projekat sa posebnim fazama analize, dizajna, implementacije i testiranja, kreirajući model nalik na

42 Royce je rigidni („vodopadni“) oblik modela u njegovom radu naveo samo kao prvi korak pre nego što je prešao na uvođenje iteracija. Šta više, smatrao je da nedostatak iteracije i nedovoljna fleksibilnost iterativnog ponašanja nose određen nivo rizika pri razvoju, i zato je uveo još pet koraka ili svojstva koji bi nadoknadili te nedostatke. Treći korak je definisao kao „uradi dvaput“ (eng. Do it Twice), gde je preporučio da se rade dve sukcesivne verzije programa, pri čemu bi verzija namenjena korisnicima trebala da bude druga. [Royce 1970] Ovim je Royce definisao jedan viši oblik iteracije, koji je mnogo bliži današnjem značenju ovog pojma.

49

prethodni, ali uz uvođenje kružnog toka. Način razvijanja koji koristi ovakve iteracije se naziva iterativni razvoj (eng. Iterative Development), i označava način razvoja softvera čiji se ukupni životni vek sastoji od nekoliko sukcesivnih iteracija (Slika 6). U svakoj iteraciji se razvije jedno iterativno izdanje (eng. Iterative Release), koje se često naziva još i prototip (eng. Prototype), pri čemu je svako iterativno izdanje zapravo jedan stabilan, integrisan, istestiran, delimično završen sistem. [Larman 2003]

Pojmovi iteracije i iterativnog razvoja već uveliko „kucaju na vrata agilnosti“. U Naked Objects pristupu postoji velika doza odanosti prema iteracijama. Zapravo, iterativni razvoj je od presudnog značaja kod onih projekata gde su korisnički zahtevi nestabilni. [Pawson 2004] Na taj način, u svakom sledećem iterativnom izdanju se povećava funkcionalnost softvera, i tako on postaje sve kompletniji u odnosu na prethodna izdanja. Ovakav način razvoja sistema se naziva inkrementalnim razvojem (eng. Incremental Delivery). [Larman 2003] Ovo je u skladu sa smernicama Naked Objects pristupa koje promovišu razvoj „scenario po scenario“, pošto se svaki scenario može okarakterisati kao skup funkcionalnosti, tj. kao „inkrement“. [Pawson 2004]

Međutim, treba naglasiti, da u strogom smislu, iterativni fazni model nije uključivao kružni tok razvoja, koji se danas smatra pravim značenjem iteracije. Takođe, faze su još uvek bile strogo razdvojene, što ponovo nije u skladu sa Naked Objects-om. Prema tome, iterativni fazni model u strogom smislu nije ni agilna metodologija, ali se može zaključiti da je Naked Objects obrazac dosta kompatibilan sa iterativnim (i inkrementalnim) načinom razvoja softvera. [Pawson 2004]

3.4.3.3. Objedinjen proces (UP)Iterativni fazni model je već uključivao pojam iteracije u razvoj, mada još u

dosta rudimentarnom obliku. Iterativni razvoj sa konceptom inkrementa i kružnog toka je već bio korak bliže pravom agilnom razvoju. Ovako su nastali agilni metodi za razvoj softvera. Čak postoji i tzv. agilni manifest (eng. The Agile Manifesto) koji glasi: [Shore & Warden 2007]

• pojedinci i interakcija iznad procesa i alata;

• softver koji radi iznad sveobuhvatne dokumentacije;

• saradnja sa klijentima iznad pregovaranja kroz ugovore; i

• odgovor na promene iznad praćenja plana;

50

Slika 6: Iterativni razvoj se zasniva na iteracijama, a svaka iteracija se sastoji od posebnih faza planiranja, analize, dizajna, implementacije i testiranja. Na kraju se vrši deployment razvijenog

prototipa, tj. iterativnog izdanja. Izvor: [Shore & Warden 2007].

Pla

nira

nje

Ana

liza

Impl

emen

taci

ja

Test

iranj

e

Dep

loym

ent

Diz

ajn

Pla

nira

nje

Ana

liza

Impl

emen

taci

ja

Test

iranj

e

Dep

loym

ent

Diz

ajn

Pla

nira

nje

Ana

liza

Impl

emen

taci

ja

Test

iranj

e

Dep

loym

ent

Diz

ajn

Iteracija Iteracija Iteracija

… pri čemu se stavke sa leve strane (napisane masnim slovima) više vrednuju od stavki sa desne strane.43

Zajednička osobina agilnih metoda je uvođenje pojma timebox-a. Timebox označava da je krajnji datum tj. završetak posmatrane iteracije u potpunosti fiksiran, i ne može se naknadno produžiti. Dužina neke posmatrane iteracije se određuje na početku iste, i uglavnom traje od nedelju dana do dva meseca. Ako razvojni tim primeti tokom iteracije da neće moći da završi sve što je bilo planirano do kraja iteracije, umesto da produži dužinu timebox-a (ili da uvede prekovremeni rad), preporučuje se da izbaci zadatke sa manjim prioritetom. [Larman 2003]

Danas postoji značajan broj agilnih metoda, a možda je najpoznatiji od njih Ekstremno programiranje, koje se može smatrati najviše agilnim metodom. Ali pre toga vredi se osvrnuti i na jedan drugi metod pod nazivom Objedinjen proces koji se nalazi na drugom kraju spektra.

Objedinjen proces (eng. Unified Process, skraćeno UP) i njegova varijanta Rational objedinjen proces (eng. Rational Unified Process, skraćeno RUP) su poznati i popularni metodi. Nastali su unutar kompanije Rational između 1995. i 1998, od strane poznatih naučnika kao što su Philippe Kruchten, Grady Booch, Mike Devlin, Rich Reitman i Walker Royce44. Kompanija Rational je uvidela mogućnost zarade na ovom modelu i tako je nastao RUP, ali je izdata i uopštenija varijanta otvorenog tipa (UP). Prva knjiga koja se detaljno bavila ovom tematikom se zvala „The Unified Software Development Process” od autora Ivar Jacobson-a, Grady Booch-a i James Rumbaugh-a (sa uvodom iz 1998. godine pod nazivom „The Rational Unified Process: An Introduction“ od autora Philippe Kruchten-a). [Larman 2003]

UP je u suštini samo generalni kostur, tj. framework za razvoj softvera, i zahteva konkretizaciju da bi funkcionisao. Zapravo, RUP je jedna konkretizacija UP-a. Kao kostur, UP definiše preko pedeset različitih artefakata zajedno sa njihovom namenom i načinom korišćenja. Njihovo korišćenje nije obavezno, ali već ova činjenica stavlja UP među formalne metode za razvoj.45 Takođe, preporučuju se iteracije sa dužinom između dve i šest nedelja. [Larman 2003]

Postavlja se pitanje, da li je UP dovoljno agilan da podržava Naked Objects pristup pri razvoju softvera? Odgovor je – po Pawson-u – negativan. Naime, postoje

43 Naked Objects pristup inače skroz podržava ovaj manifest. Prva stavka je podržana zato što OOUI u prvi plan stavlja korisnika a ne tok, a s druge strane, zato što je stil programiranja u Naked Objects-u neposredan, pa je bliži pravoj veštini programiranja. Druga stavka je podržana zbog direktne korespondencije između modela domena i izvornog koda, čineći izvorni kod možda najboljom dokumentacijom (naročito ako postoji mogućnost generisanja UML dijagrama klasa iz programskog koda). Treća stavka je podržana sveprisutnim jezikom. Konačno, četvrta stavka je podržana zbog promovisanja behavioralno-kompletnih objekata, koji lokalizuju promene samo na domenski sloj (često samo na jednu klasu), i tako omogućavaju brži odgovor na promene. [Pawson 2004]

44 Walker Royce je sin Winston W. Royce-a, autora vodopadnog modela.45 U striktnom smislu, UP i RUP se ne mogu nazvati agilnim metodima. Razlog tome leži i u činjenici

da su previše formalni, jer čak i u najmanjem obimu zahtevaju više dokumenata u odnosu na druge metode. Takođe, ovi metodi više vrednuju projekat od pojedinca, što nije slučaj kod pravih agilnih metoda. Prema tome, mnogi ih klasifikuju samo kao iterativne metode. Međutim, treba napomenuti da je stepen prilagođavanja kod UP-a dovoljno visok da bi se mogao pretvoriti u metod sa malim brojem dokumenata i donekle izmenjenim vrednostima. Zato se oni mogu smatrati i agilnim metodima. [Larman 2003]

51

dve potencijalne tačke konflikta. Prva, ovaj metod je prihvatio jedan oblik UCC obrasca46 pod nazivom EBC obrazac47. U teoriji, bilo bi moguće izbaciti korišćenje EBC obrasca iz UP-a, ali za razliku od dokumenata, ne postoje nikakve smernice za to. I druga, ovaj metod preporučuje slučajeve korišćenja za identifikaciju i analizu zahteva, šta više, oni predstavljaju fundamentalni princip kod UP-a. Kao što je već navedeno u odeljku 3.4.2, korišćenje slučajeva korišćenja kod Naked Objects pristupa za identifikaciju zahteva nije dozvoljeno. Pawson sumnja da bi se ovo moglo izbaciti iz UP-a, budući da su slučajevi korišćenja duboko ukorenjeni u sam model razvoja. Zbog ova dva razloga, UP nije kompatibilan sa Naked Objects-om. [Pawson 2004] Međutim, iako su slučajevi korišćenja važni kod ovog metoda, i njihova upotreba se toplo preporučuje, Larman smatra da to nije obaveza. Naime, UP je stalnim oblikovanjem (zahvaljujući prilagođavanju) s vremenom postao sve više i više agilan. Prema tome, za identifikaciju zahteva nije nužno koristiti slučajeve korišćenja. [Larman 2003]

Iz prethodnih izlaganja se može zaključiti da Naked Objects pristup nije kompatibilan sa metodima UP i RUP, ali se nivo kompatibilnosti može povećati odgovarajućim (mada ozbiljnim) prilagođavanjem istih.

3.4.3.4. Ekstremno programiranje (XP)Ako se UP i RUP nalaze na jednom kraju spektra, onda se Ekstremno

programiranje nalazi na drugom kraju. Ekstremno programiranje (eng. Extreme Programming, skraćeno XP) je nastalo 1999. godine od strane Kent Beck-a (uz saradnju Ward Cunningham-a, Ron Jeffries-a i Martin Fowler-a), mada su prve ideje nastale još sredinom 1980-ih kad je Beck radio u firmi Tektronix. Prvu ediciju XP-a je izdao 1999. godine u svojoj knjizi „Extreme Programming Explained, First Edition” [Beck 1999], a drugu ediciju 2004. godine u knjizi „Extreme Programming Explained, Second Edition”. [Larman 2003] Kasnije su se pojavile i modifikacije XP-a, a među najznačajnijima je modifikacija nastala 2007. godine od strane James Shore-a i Shane Warden-a u knjizi „The Art of Agile Development“ [Shore & Warden 2007].

Kako i naziv metode sugeriše, XP je nastao tako što je autor uzeo sve prakse i principe koji su korisni za razvoj softvera, i forsirao ih je do maksimuma, do ekstrema. Na primer: ako je dobro testirati, onda treba testirati tokom celog razvoja; ako su kratke iteracije dobre zbog povratne sprege, onda treba iteracije skratiti do nedelju-dve dana; ako se mišljenje klijenta (tj. korisnika, domenskog eksperta) tako ceni, onda ga treba pozvati da se „preseli“ kod razvojnog tima48; ako je komunikacija (uključujući verbalnu) tako važna, onda treba rušiti zidove tako da svi sede zajedno, itd. Sad je već jasno, zašto je XP, kad se pojavio, doslovno šokirao softverski svet. [Larman 2003]

Kao što je već rečeno, XP je vrlo agilan metod. Primenjuje se kod manjih

46 UCC obrazac (kontroler slučajeva korišćenja) se opisuje u odeljku 3.1.47 EBC obrazac (skraćenica od Entity, Boundary and Control) je sličan iskrivljenoj varijanti MVC

arhitekture. Ima tri arhetipa objekta koji su: entitet, granica i kontrola. Entiteti bi trebali da budu slični modelu. Granični objekti su odgovorni za GUI (s tim da obuhvataju i poglede („V“) i kontrolere („C“) iz MVC-a). Konačno, kontrolni objekti se nalaze između prethodna dva arhetipa, i kontrolišu tok događaja. [Pawson 2004]

48 Tako „nastaju“ korisnici koji se u XP-žargonu nazivaju on-site klijentima (eng. On-site Customers). Naziv su dobili tako što se oni celo vreme nalaze u istoj prostoriji kao i ostatak tima, tj. oni su stalno na licu mesta. [Shore & Warden 2007]

52

razvojnih timova (do 20 osoba). Dužina iteracije traje od nedelju dana do dve nedelje (ako je opravdano, do četiri). U svakoj iteraciji, rade se sve aktivnosti vezane za tu iteraciju: planiranje, analiza zahteva, dizajniranje, programiranje i testiranje, s tim da ove aktivnosti više nisu razbijene u posebne faze kao u neagilnim metodima (Slika 7). Dalje, XP ne zahteva praktično nikakve dokumente, pa je njegov stepen formalnosti na niskom nivou. Ionako, zašto bi tim trošio vreme na dokumentaciju kad su domenski eksperti stalno na dohvat ruke? Naravno, ovo ne znači da se ništa ne piše ili crta, ali bi to trebalo minimizovati, pa je XP uveo korišćenje malih listića ili ceduljica, tzv. stori-listića (eng. Story Cards). Oni imaju niz prednosti: mobilni su pa se mogu nakačiti na table gde se raspoređuju. Takođe, njihova mala veličina na neki način može sugerisati članovima tima da pišu koncizno i samo kad je potrebno. [Shore & Warden 2007]

Za definisanje korisničkih zahteva XP koristi tzv. storije (eng. Stories). One se mogu zamisliti kao scenarija i pišu se jasno i koncizno na stori-listiće. Ti listići se lepe na table, što omogućava njihovo raspoređivanje. Programeri „zauzimaju“ storije tako što skidaju odgovarajuće listiće, a kad je storija implementirana, listić se vraća i zaokružuje se, tako označivši da je storija implementirana. [Shore & Warden 2007]

XP ima zaista velik broj principa koji se grupišu u grupe. Neki istaknuti principi (u Shore-ovoj verziji) su: programiranje u parovima (možda najprepoznatljivija osobina XP-a), sedenje zajedno (razvojni tim se nalazi u jednoj većoj prostoriji u kojoj članovi tima nisu razdvojeni zidovima), uključivanje stvarnih klijenata (tako nastaju on-site klijenti), sveprisutni jezik (slično kao kod Domain-Driven Design-a), biti „gotov-gotov“ (garantuje da storije budu stvarno gotove, tj. one su čak i istestirane i dokumentovane), inkrementalni zahtevi (softver se razvija postepeno), klijentski testovi (slični testovima prihvatanja od strane korisnika), razvoj usredsređen ka testiranju (dobro poznata metodologija, zahteva da se prvo napiše test, a zatim programski kod koji bi zadovoljio test), refaktorisanje, jednostavan dizajn (dizajnirati model na što jednostavniji način, tako da zadovolji samo ono što je potrebno, bez dizajniranja „unapred“), Spike-rešenja (pravljenje izolovanih eksperimenata), itd. [Shore & Warden 2007]

53

Slika 7: XP se takođe zasniva na iteracijama sa istim fazama unutar svake, ali faze nisu razdvojene kao kod iterativnog razvoja. Izvor: [Shore & Warden 2007].

Itera

cija

Itera

cija

Itera

cija

Itera

cija

Itera

cija

Itera

cija

Itera

cija

Itera

cija

Itera

cija

Itera

cija

Itera

cija

Itera

cija

Pla

nira

nje

Dep

loym

entAnaliza

DizajnImplementacija

Testiranje

1-2 nedelje

Što se tiče kompatibilnosti Naked Objects pristupa sa Ekstremnim programiranjem, Pawson zaključuje da je kompatibilnost na veoma visokom nivou. [Pawson & Wade 2003] Sama suština XP-a je veoma bliska sa idejom pristupa, što potvrđuju i principi XP-a. Neki primeri u prilog ovoj tvrdnji: [Pawson 2004]

• Metafora49 – po Beck-u, ovaj princip znači sledeće: „celi razvoj voditi kroz jednostavnu i zajedničku priču koja opisuje kako celokupni sistem funkcioniše“. [Beck 1999] U suštini, ovaj princip služi da pojednostavi shvatanje sistema za one korisnike koji nisu iskusni u softverskom svetu, i to uz pomoć koncepata koji su svima jasni: tabelama, realnim primerima, itd. Naked Objects takođe ima jednu „metaforu“ koja je bila korišćena u nekim projektima: jednu logičku kompjutersku igru. Više reči o ovoj metafori će biti u odeljku 3.5.1.

• Jednostavan dizajn – kao što je već nekoliko puta rečeno, Naked Objects pojednostavljuje dizajn pre svega zato što ne opterećuje programere da sami kreiraju GUI, i zato što forsira korišćenje behavioralno-kompletnih objekata, smanjivši količinu izvornog koda.

• Inkrementalni zahtevi – po Naked Objects pristupu, razvoj se odvija „scenario po scenario“, tj. funkcionalnost sistema se postepeno povećava. Zato je ovakav način razvoja u skladu sa ovim principom XP-a.

• Klijentski testovi – ovaj princip XP-a jako liči na testove prihvatanja od strane korisnika koji se preporučuju od strane Naked Objects pristupa, jer oba testa uključuju i korisnika. XP preporučuje da se ovi testovi integrišu u razvoj, a na osnovu poslednje smernice (opisane u odeljku 3.4.2) Naked Objects pristup čak i pojednostavljuje ovu integraciju.

Međutim, Pawson ističe da postoji i jedan problem. Naime, faza istraživanja Naked Objects pristupa nije podržana od strane XP-a. U XP-u postoji faza planiranja na početku svake iteracije, ali ona služi za izbor onih zahteva od strane klijenata koje bi oni želeli da vide u sledećom iterativnom izdanju, i ne uključuje nikakvo modeliranje, niti programiranje, što znači da nema veze sa fazom istraživanja. Princip s kojim bi faza istraživanja bila najbliža je princip pod nazivom Spike-rešenja (eng. Spike-Solutions)50. Ovaj princip se koristi u slučaju da se želi istražiti nešto novo poput novih tehnologija ili algoritama, ali da je poduhvat rizičan: rešenje možda neće uspeti, ili će biti bagovito. Zato se pravi jedan tzv. Spike, koji je strogo izolovan od glavnog softvera. Ako se pokaže izvodljivost rešenja, Spike se može integrisati u glavni softver. [Shore & Warden2007] Pawson ističe da bi se ovaj princip mogao modifikovati tako da se odnosi na celokupni softver (ne samo na određene delove, kako je originalno bilo zamišljeno), i da se radi početkom razvoja, ali smatra da se sa ovim menja suština originalnog principa. [Pawson 2004]

Sve u svemu, iako XP ne podržava eksplicitno koncept faze istraživanja u Naked Objects-u, može se reći da su oni veoma kompatibilni. O kompatibilnosti pristupa sa XP-om biće još reči u odeljku 3.5.3.

49 Mora se napomenuti da ovaj princip postoji eksplicitno samo u prvoj ediciji Ekstremnog programiranja. U Shore-ovoj i Warden-ovoj verziji ovaj princip je zamenjen sveprisutnim jezikom. [Shore & Warden 2007]

50 Spike rešenja su eksplicitno navedena samo u Shore-ovoj i Warden-ovoj modifikaciji.

54

3.5. Primeri korišćenja Naked Objects pristupaU prethodnom odeljku se ispitivala agilnost Naked Objects pristupa – koje vrste

agilnosti podržava, na koji način ih može postići (korišćenjem smernica) i kako se uklapa u neke postojeće metodologije razvoja softvera – pa se može zaključiti da je agilnost pristupa stvarno opravdana. Gotovo sve prednosti samog pristupa se direktno ili indirektno vezuju za agilnost. Međutim, bilo bi zanimljivo videti i neke praktične primere koji bi mogli ove prednosti pokazati i u stvarnosti. Zato će se u ovom odeljku predstaviti neki realni projekti koji su koristili neku implementaciju Naked Objects obrasca. Prva dva primera potiču od samog kreatora pristupa, a treći od drugih autora.

3.5.1.Izrada Naked Object Architecture framework-a i sistema za administraciju dečijeg dodatka za Irsku vladuPrva prilika da se pokažu koristi Naked Objects pristupa u praksi se ukazala

upravo za Irsku vladu, i to 1999. godine. Ministarstvo za socijalnu zaštitu51 je u to vreme imalo dosta staru računarsku infrastrukturu čije je održavanje bilo dosta skupo, ali isto se moglo reći i za postojeće informacione sisteme koji su bili nefleksibilni i teško izmenljivi. Ministarstvo je već neko vreme priželjkivalo veću agilnost ne samo u organizacionom smislu (uključivši agilnost samih sistema), već i u smislu korišćenja tih sistema od strane korisnika. [Pawson 2004]

Početkom 1999. godine, uprava informacionih sistema je doznala za Pawson-ova istraživanja iz oblasti behavioralno-kompletnih objekata, pre svega zbog njihovih pretpostavljenih koristi. Pawson je prihvatio poziv da organizuje radionice za zaposlene iz menadžmenta iz oblasti objektno-orijentisanog razmišljanja. Pawson u to vreme još nije imao funkcionalan framework, pa je za što vizuelniji prikaz koristio jednu kompjutersku igru pod nazivom „The Incredible Machine” (skraćeno TIM)52. [Pawson2004] Ova logička igra zahteva od igrača da rešava simulacije kompleksnih problema (Slika 8). Možda se ne vidi na prvi pogled, ali je igra zapravo dosta objektno-orijentisana. Naime, sve što igrač može na datom nivou iskoristiti (npr. makaze, baloni, itd), su objekti. Ovi predmeti su behavioralno-kompletni, jer svi imaju i svoje ponašanje (npr. balon se može zakačiti za konopac, inače će odleteti, a ako naiđe na bodljikav ili vruć predmet, on će pući). I sam interfejs igre je dosta objektno-orijentisan, jer su predmeti vidljivi igraču i može njima direktno manipulisati.

Na sledećoj radionici, učesnici su probali da identifikuju poslovne objekte samog ministarstva. Dobijen rezultat su simulirali u obliku PowerPoint prezentacije, gde su objekti bili predstavljeni ikonicama, a njihovo ponašanje je bilo ilustrovano desnim klikom na izabrani objekat.

Rezultate obe radionice su zatim demonstrirali upravi, koja je bila zadovoljna sa njima. Ljudi su uvideli kako bi mogli da koriste ovu aplikaciju, i bili su saglasni da bi

51 Zapravo, ministarstvo je od 1997. do 2002. godine nosilo naziv Ministarstvo socijalnih, zajedničkih i porodičnih poslova (eng. Department of Social, Community and Family Affairs), a od 2002. do 2010. naziv Ministarstvo socijalnih i porodičnih poslova (eng. Department of Social & Family Affairs). Tek od 2010. godine nosi naziv Ministarstvo za socijalnu zaštitu (eng. Department of Social Protection). Izvor: <http://www.welfare.ie/EN/AboutUs/Pages/dsp_overview.aspx>.

52 Pawson je igru koristio kao metaforu, koja je zapravo jedan od principa Ekstremnog programiranja (pogledati odeljak 3.4.3.4).

55

ovakav korisnički interfejs tretirao korisnika kao rešavaoca problema, povećavši njegovu efikasnost. Iako ministarstvo još nije bilo spremno da prihvati sva načela samog pristupa, postignuta je saglasnost da se pristup dublje istražuje. [Pawson 2004]

Početkom 2000. godine, vlada je inicirala neke izmene za sistem za administraciju dečijeg dodatka (eng. Child Benefit Administation, skraćeno CBA), ali se ispostavilo da postojeći sistem te promene neće moći da podnese, pa je ministarstvo dalo zeleno svetlo za izradu novog CBA sistema baziranog na Naked Objects pristupu, koji bi zamenio stari. Uzgred, CBA nije bio velik sistem: imao je otprilike 80 korisnika, i imao je relativno jednostavan model (u odnosu na druge sisteme), ali se usko vezivao za druge modele. Jedan tim unutar sektora za informacione sisteme je organizovao par radionica za identifikaciju poslovnih objekata za potrebe CBA. Za ove potrebe, iskoristili su rezultat prethodne radionice (na kojoj su učesnici identifikovali poslovne objekte celog ministarstva), i napravili su prototipni model. [Pawson 2004]

U međuvremenu, jedna druga grupa unutar ministarstva je definisala buduće principe framework-a koji će kasnije biti poznat pod nazivom Naked Object Architecture (skraćeno NOA). Ovi principi su demonstrirali visok nivo odanosti prema Naked Objects pristupu, kao što su: izlaganje (objekti moraju biti direktno izloženi ka korisniku, uključujući i ponašanje, a interakcija mora biti u stilu „imenica-glagol“), jedno i samo jedno mesto za definisanje (domenski sloj) i automatski generisan GUI. Pošto je reč o državnoj agenciji, posle definisanja principa se raspisao tender za razvoj ovog framework-a. [Pawson 2004]

Na tenderu je u februaru 2001. pobedila firma DMR Consulting (kasnije

56

Slika 8: „The Incredible Machine“ (skraćeno TIM). Izvor: [Haywood 2009].

preimenovana u Fujitsu Consulting), s kojom je bio potpisan ugovor da se novi CBA sistem lansira u martu 2002. godine. Projekat je tokom razvoja naišao na razne probleme, i datum isporuke je bio odložen par puta, ali je u novembru 2002. godine napokon zaživeo, zamenivši stari sistem. Što se tiče ovog novog sistema, poslovni objekti su bili pisani u jeziku Visual Basic 6.0 i radili su na Microsoft COM+ serveru. Microsoft SQL Server je bio primarni mehanizam za perzistenciju, ali zbog povezanosti sa drugim sistemima je bilo potrebno da se implementira pristup i ka drugim bazama (Oracle i OpenVMS). Klijentske mašine (računari koji se koriste od strane korisnika) su koristile običan Web brauzer za pristup CBA sistemu u vidu Java apleta (Slika 9). Komunikacija između GUI-ja i poslovnih objekata se odvijala uz pomoć XML poruka.

Pawson je u februaru 2003. godine odlučio da uradi procenu celog projekta, tako što je intervjuisao i anketirao ukupno 25 osoba koje su na neki način bile vezane za projekat (menadžere koji su bili angažovani na izradi NOA, menadžere koji su bili angažovani na modeliranju CBA sistema i korisnike CBA). Treba napomenuti da ovaj projekat nije koristio smernice definisane u odeljku 3.4.2 pošto u to vreme one još nisu bile definisane. Rezultati procene u sažetom obliku su sledeći: [Pawson 2004]

• Korisnici su oduševljeni korišćenjem novog sistema. Na početku razvoja su neki menadžeri izrazili zabrinutost u vezi korišćenja novog sistema, pre svega zato što sistem više neće voditi korisnika kroz tokove. Međutim, desilo se obrnuto: korisnici su više voleli kad im je sistem omogućio da reše probleme na sopstveni način, tj. osetili su se osposobljenim.

57

Slika 9: Korisnici su CBA sistemu pristupali preko Web brauzera. Izvor: [Pawson 2004].

• Nov sistem je efikasan sa poslovnog aspekta. Neki su izrazili zabrinutost da će ukupna brzina sistema biti nešto sporija, prvenstveno zbog osobine Naked Objects-a da ne vodi korisnika kroz tokove. Međutim, nov CBA je postao „generalno“ brži. Najbolji dokaz za ovu tvrdnju je informacija da je pre nego što je novi CBA zaživeo, departman već imao zaostatak od 20.000 zahteva, a vreme obrade jednog zahteva je bilo šest nedelja. Neočekivano, samo posle par meseci rada na novom CBA sistemu, zaostatak je uz mali prekovremeni rad praktično nestao, a vreme obrade jednog zahteva se smanjilo na svega nedelju dana. Takođe vredi istaći da se jedan zahtev u starom sistemu obrađivao od strane tri referenta (prvi je uneo podatke sa papira u sistem, drugi je doneo odluku o zahtevu i o visini isplate, a treći je realizovao isplatu). Novi CBA je broj osoblja po zahtevu smanjio sa tri na svega jednu osobu.

• Još je rano adekvatno proceniti stratešku agilnost sistema, ali su početni znaci pozitivni. Strateška agilnost – sposobnost jednostavnog menjanja sistema radi zadovoljenja novih zahteva – je bila važna za novi sistem, ali u trenutku anketiranja još nije prošlo dovoljno vreme za njenu procenu. Međutim, realizovati izmene tokom razvoja je bilo relativno lako.

• Performanse tokom rada na sistemu su zadovoljavajuće, ali performanse tokom serijske obrade predstavljaju zabrinutost. Naked Objects pristup je u ovom segmentu naišao na problem. U nekim slučajevima, brzina obrade je bila duplo sporija od zahtevane.53

• Agilnost u smislu smanjenja vremena razvoja sistema se nije osetila, ali to se može pripisati činjenici da je trebalo implementirati ne samo novi CBA sistem, nego i odgovarajući framework (NOA). Vreme razvoja je bilo 21 mesec (umesto 12 meseci kako je originalno bilo planirano), ali ne treba zaboraviti ni to da se morao implementirati i NOA. Međutim, firma zadužena za izradu CBA i NOA nije koristila načela Naked Objects pristupa, nego je za razvoj koristila klasični vodopadni model.

• Naked Objects je olakšao komunikaciju između korisnika i programera, ali ljudi nisu bili dovoljno angažovani na izradi prototipova. Na osnovu anketa, bilo je jasno da su ljudi voleli iterativan način rada na radionicama, ali su bili pomalo razočarani zbog izostanka istih u glavnoj fazi (firma zadužena za izradu nije koristila iteracije).

Na osnovu iznetih podataka se može zaključiti da je projekat bio manje-više uspešan, i pokazao je neke pozitivne strane Naked Objects pristupa, pre svega u smislu agilnosti, ali ne sve. Na osnovu stečenog iskustva, Pawson je formulisao smernice navedene u odeljku 3.4.2.

3.5.2.Razvoj sistema za kompaniju SafewayCBA sistem za potrebe Ministarstva za socijalnu zaštitu je dokazao neke dobre

osobine Naked Objects pristupa, ali to je bilo pre formulisanja smernica u odeljku 3.4.2. Za pokazivanje njihove korisnosti bilo je potrebno naći neki novi projekat, i takva

53 Ovaj problem je Pawson dodao i u prvu smernicu (odeljak 3.4.2).

58

prilika se ukazala 2001. godine u kompaniji Safeway. [Pawson 2004]

Kompanija Safeway je u to vreme bila četvrti najveći lanac supermarketa u Engleskoj.54 Uprava firme je početkom 2001. godine postala svesna Naked Objects pristupa razvoja softvera. Međutim, pristup je za upravu bio primamljiv ne za razvoj softvera, nego za obuku radnika. Naime, većina sistema u Safeway-u je bila implementirana u programskom jeziku Cobol koji nije bio objektno-orijentisan. Iako je firma te godine uveliko prešla na Javu, činilo se da programeri još uvek razmišljaju na proceduralni način. Radionice održane uz prisustvo Pawson-a pomoću jedne rane verzije Naked Objects framework-a su bile jako uspešne, što je navelo kompaniju da razmotri korišćenje framework-a i za razvoj softvera. [Pawson 2004]

Prva takva prilika se ukazala iz oblasti cenovnih kalkulacija i promocija. Safeway, da bi se takmičio sa konkurencijom, nudio je stalne akcije proizvoda koje se redovno menjaju. Ideja je bila da se napravi softver koji bi upravljao lancem snabdevanja da se izbori sa povećanom potražnjom, obaveštavao bi prodavnice o promenama u cenovniku, i pomagao bi u štampanju odnosno distribuiranju letaka (u domaćinstva). Prethodno su ove aktivnosti bile realizovane nizom softvera, a cilj je bio da se napravi sveobuhvatni softver koji bi radio sve, od izbora promocija do koordinisanja preostalih tokova.

Pawson je uočio da bi ovaj sistem bio idealan za Naked Objects. Naime, na osnovu prve smernice, softver zadovoljava sve zahteve: softver bi bio orijentisan za rešavanje raznih problema, koristili bi ga samo određeni radnici kompanije (pa nema potrebe za ručno generisanje GUI-ja) i to skoro svakodnevno, a serijska obrada ne bi predstavljala problem (za ovu svrhu je već postojao drugi sistem). Takođe, zahtevi su bili jako nestabilni. Prema tome, kompanija je donela odluku da se uradi faza istraživanja.

Faza istraživanja je trajala četiri nedelje.55 Već prvog dana, učesnici su počeli identifikovati poslovne objekte relevantne za projekat (naravno bez slučajeva korišćenja), a implementacija tih objekata u Javi je počela već sledećeg dana. Razvojni tim je radio na iterativni način: svaka iteracija je trajala nedelju dana, a početkom svake je bio organizovan sastanak gde su članovi pregledali napredak i odlučili šta da rade sledeće. Domenski eksperti i korisnici su često sedeli zajedno sa programerima, a GUI Naked Objects framework-a je odmah prikazao rezultate. Ova osobina je bila posebno hvaljena: ljudi su stalno tražili demonstracije, čak i van razvojnog tima. Na kraju faze, uprava je donela odluku da obustavi celi razvoj, sa razlogom da su prvo hteli da procene potencijal Naked Objects pristupa. [Pawson 2004]

Jedna druga grupa unutar Safeway-a je primetila prethodni projekat i odlučila da iskoristi pogodnosti pristupa za jedan drugi projekat nazvan CBP (skraćenica od Cluster-Based Pricing, u prevodu cenovna kalkulacija zasnovana na klasterima). Članovi tima su već u fazi istraživanja zavoleli pristup, i doneli odluku da pređu na fazu isporuke. Tim je u drugu fazu preneo samo definicije objekata, u skladu sa smernicama,

54 Zapravo, kompanija Morrisons je 2004. otkupila engleski Safeway i integrisala ga. Izvor: <http://www.morrisons.co.uk/Corporate/About-us/Company-history/>.

55 Vredi pomenuti, da je i druga smernica bila zadovoljena: razvojni tim je imao bar jednog iskusnog člana koji je bio vešt oko objektno-orijentisanog modeliranja (čak je i Pawson prisustvovao kao konsultant); koristio se dobar framework (Naked Objects framework); i članovi tima su imali mogućnost da uživo isprobaju CBA sistem, pa su brzo shvatili suštinu Naked Objects pristupa.

59

a razvoj je tekao po načinu „scenario po scenario“. Prvo pravo izdanje se pojavilo već posle 90 dana, mnogo ranije od očekivanog. Međutim, uprava je kasnije donela odluku da promeni platformu na kojoj će sistem raditi (mainframe sa primitivnim terminalima), a pošto implementiran sistem na osnovu Naked Objects-a nije podržao tu kombinaciju, razvojni tim je bio primoran da ponovo implementira sistem – ovog puta u Cobol-u. [Pawson 2004]

Slično kao i kod projekta za Irsku vladu, Pawson je posle godinu dana uradio procenu unutar Safeway-a, tako što je intervjuisao i anketirao ukupno deset radnika (programera i korisnika) koji su radili ili samo na jednom ili na oba projekta. Sumirano, rezultati su bili sledeći: [Pawson 2004]

• Naked Objects olakšava komunikaciju između korisnika i programera. Takođe, nijednoj grupi nije bilo teško da prihvati behavioralno-kompletne objekte.

• Naked Objects olakšava rapidnu izradu prototipova. Svi učesnici su bili saglasni da je ovaj pristup ubrzao izradu prototipova, i da je podsticao efikasniji rad. Ovo je bilo nešto što se nije moglo proceniti kod CBA sistema.

• Sprovesti jednu fazu istraživanja pre stvarnog razvoja je korisno. Većina učesnika je verovala da je više zahteva uspela da identifikuje ovako, nego kad bi se sprovela uobičajena faza za modeliranje – na papiru.

Neki učesnici na intervjuu su i priznali da su bili razočarani odlukama kompanije da otkaže dalji razvoj. Međutim, projekti su uspeli da pokažu ono što projekat za izradu CBA sistema nije mogao.

3.5.3.Aplikacija za pristup Helsinškoj berziPosle predstavljanja Naked Objects pristupa, više naučnika i inženjera su postali

svesni Pawson-ovog doprinosa. Međutim, u to vreme broj empirijskih studija o korisnosti pristupa je bio skoro nepostojeći (sem Pawson-ovog originalnog rada), što je umnogome ometalo njegovo adekvatno procenjivanje. Finski naučnici Heikki Keränen i Pekka Abrahamsson su 2004. godine rešili da promene ovo stanje.

Ideja je bila da se proceni korisnost Naked Objects prisupa na empirijski način. Njih je posebno interesovala kompatibilnost pristupa sa agilnim metodologijama razvoja poput Ekstremnog programiranja [Keränen & Abrahamsson 2005a] i stepen poslovne agilnosti u smislu smanjenja količine izvornog koda u implementaciji [Keränen & Abrahamsson 2005b]. Za potrebe istraživanja, implementirala se aplikacija za pristup Helsinškoj berzi na mobilnim telefonima sa Java podrškom, i to na dva načina: na uobičajeni višeslojni način, a kasnije i pomoću Naked Objects pristupa.

Programeri ovih projekata su bili studenti (četiri studenta na oba projekta). Prvi projekat pod nazivom zOmbie je trajao osam nedelje, od oktobra do decembra 2003. godine, i rađen je u klasičnoj četvoro-slojnoj arhitekturi. Drugi projekat pod nazivom Roger je isto trajao osam nedelje, ali godinu dana kasnije, od oktobra do decembra 2004. Pošto još nije postojao adekvatan mehanizam za pogled objekata (tj. GUI) na mobilnim telefonima, bilo je potrebno i njega implementirati. Prema tome, Roger projekat je bio podeljen na dva potprojekta. Prvi je obuhvatao implementaciju GUI-ja na telefonima, i trajao je četiri nedelje. Zatim je startovao drugi potprojekat pod

60

nazivom Naked Zombie (isto u trajanju od četiri nedelje) koji je obuhvatao implementaciju same aplikacije za pristup berzi u Naked Objects framework-u (verzija v1.2.2). Za perzistenciju podataka, koristio se MySQL (za zOmbie) i Naked Objects framework-ovo XML skladištenje (za Naked Zombie) Podaci su bili sakupljeni na kvantitativni (merenjem) i na kvalitativni (intervjuisanjem) način. [Keränen &Abrahamsson 2005b]

Što se tiče istraživanja kompatibilnosti Naked Objects pristupa sa XP, naučnici su došli do sledećih rezultata: [Keränen & Abrahamsson 2005a]

• Naked Objects pristup zaista podržava storije XP-a, testiranje, itd.

• Studenti-programeri su bili jako zadovoljni i sa pristupom i sa framework-om.

• Procenjivanje56 nije bilo baš uspešno – u prvom potprojektu (implementacija pogleda) razvojni tim je na početku dao dosta optimistične procene, ali se ispostavilo da razvoj pogleda nije trivijalan, pa su u drugoj polovini razvoja potprojekta već dali relativno tačne procene. Međutim, u drugom potprojektu (Naked Zombie) razvojni tim je na početku napredovao brže od predviđenog, tj. dao je pesimistične procene. Ovaj uspeh je naveo tim da da optimističnije procene za buduće storijeve. Međutim, desilo se suprotno: razvoj se usporio, pošto su neki aspekti razvoja ponovo zahtevali rad u okruženju koje nema puno veze sa Naked Objects-om.

Što se tiče stepena poslovne agilnosti u smislu smanjenja količine izvornog koda, merenje se vršilo brojanjem linije koda (eng. Lines of Code, skraćeno LOC), a cilj je bio da se porede dobijeni rezultati sa rezultatima iz drugih izvora. Naime, prethodna istraživanja su pokazala da je 50% ukupnog koda zapravo programski kod za korisnički interfejs. Dalje, Pawson je procenio da korišćenje Naked Objects pristupa za razvoj smanjuje LOC za 75% [Pawson 2004], a neki drugi su stigli do još boljih rezultata (teoretsko smanjenje LOC za 80-95%). [Keränen & Abrahamsson 2005b] Na kraju, došlo je do sledećih rezultata: [Keränen & Abrahamsson 2005b]

• Ukupno angažovanje na prvom projektu (zOmbie) je bilo 1080 sati, a na drugom projektu samo 810 sati. Naravno, ne sme se zaboraviti da se drugi projekat sastojao iz dva potprojekta, pošto se morao napraviti još i adekvatan pogled za mobilne telefone. Zapravo vreme angažovanja na pravoj aplikaciji (Naked Zombie) je bilo svega 380 sati.

• Broj korisničkih storija u Naked Zombie potprojektu je bio manji nego u zOmbie projektu. Razlog ovome najverovatnije leži u činjenici da su storije unutar Naked Zombie potprojekta imale više vrednosti za klijenta, i da su zahtevale manje vreme za implementaciju.

• LOC kod Naked Zombie-a je bio za 79% manji nego kod zOmbie-a, što je na neki način potvrdilo rezultate iz drugih istraživanja. Inače, GUI je kod zOmbie projekta zauzeo 65% ukupnog LOC-a.

56 Procenjivanje je poseban princip u XP-u, i označava potrebu da se unapred procenjuje vreme trajanja implementacije neke storije. Po mnogima, predstavlja jedan od najtežih principa jer se zasniva na predosećanju. [Shore & Warden 2007]

61

Sve u svemu, ovo istraživanje je pokazalo da je razvoj pomoću Naked Objects pristupa zaista kompatibilan sa XP, da je razvojni tim produktivniji, i da je implementiran proizvod manji po liniji koda i zahteva manje angažovanje. Međutim, naučnici su tokom ovog istraživanja naučili i neke lekcije: [Keränen & Abrahamsson2005a] [Keränen & Abrahamsson 2005b]

• Naked Objects framework v1.2.2 nije još dovoljno zreo – bagovi su bili česti, što je naročito važilo za XML skladištenje.57

• Automatski generisan OOUI može imati probleme u smislu upotrebljivosti – o ovome je već diskutovano u odeljku 3.3.

• Pravljenje softvera uz pomoć Naked Objects framework-a je efikasno i produktivno, ali to ne znači da je proširenje istog jednostavno – kako su studenti-programeri primetili, unutrašnja implementacija framework-a je dosta komplikovana, i proširenje istog (npr. u smislu pravljenja novog pogleda) nije uopšte lako. S druge strane, pravljenje GUI-ja kod zOmbie projekta (pravljen u klasičnoj višeslojnoj arhitekturi) takođe nije bilo lako, što dokazuje da pravljenje GUI-ja generalno zahteva veće angažovanje.

U svakom slučaju, naučnici su došli do zaključka da Naked Objects pristup ima veliki potencijal, a ako se isprave uočeni problemi u framework-u, može predstavljati moćnu alternativu za razvoj softvera.

3.6. Prednosti i mane Naked Objects pristupaU poslednjem odeljku ovog poglavlja će se još jednom sumirati prednosti i mane

Naked Objects pristupa, ali pre toga se mora dati odgovor na pitanje, kome je Naked Objects namenjen. Pawson je ga isprobao za razvoj aplikacije za Irsku vladu radi procesiranja zahteva za dečiji dodatak, i to uspešno. Takođe, pristup se dobro pokazao i u privatnoj kompaniji. [Pawson 2004] Po mišljenju Läufer-a, ovaj pristup bi bio koristan i u naučnim zajednicama. [Läufer 2008] Zapravo, može se reći, da Naked Objects pristup najviše odgovara u onim situacijama, kad je kreativno rešavanje problema jedan od prioriteta. Prema tome, prednosti Naked Objects pristupa su:

• Augmentuje58 ljudski um – kao što Douglas Engelbart, pronalazač računarskog miša i jedan od prvih vizionara računarskih GUI-ja, u svom izveštaju iz 1962. godine za Stanford istraživački institut (eng. Stanford Research Institute, skraćeno SRI) pod nazivom „Augmenting Human Intellect: A Conceptual Framework“ objašnjava, augmentovanje ljudskog intelekta označava poboljšanje sposobnosti čoveka da rešava kompleksne probleme. Po Reenskaug-u, Alan Kay i njegov tim je uspeo nešto slično da postigne u Smalltalk-u, baš kao i Pawson sa svojim Naked Objects pristupom. [Pawson 2004]

• Promoviše korišćenje behavioralno-kompletnih objekata – na ovaj način,

57 Ovde treba naglasiti da je istraživanje iz 2004. godine, i da je Naked Objects framework tokom godina prošao kroz više unapređenja. Trenutna verzija ovog framework-a je v4.0.

58 Augmentovati nešto znači povećati, pojačavati osobine nečega, tj. podići ih na sledeći stepen.

62

podstiče se korišćenje lepog objektno-orijentisanog dizajna. [Pawson 2004]

• Osposobljava korisnike uz pomoć OOUI – Naked Objects pristup tretira korisnike kao rešavaoce problema, a ne kao pratioce tokova. [Pawson 2004]

• Skraćuje razvojni ciklus i veličinu izvornog koda tako što automatski generiše GUI – Naked Objects pristup skida potrebu ručnog pravljenja GUI-ja sa ramena programera, što rezultuje bržem razvoju softvera i smanjuje količinu linije koda (LOC). [Pawson 2004] [Keränen & Abrahamsson 2005b]

• Nudi zajednički jezik između korisnika i programera – automatski generisan GUI je podjednako upotrebljiv i za programere i za korisnike, koji tako postaje osnova za zajednički jezik između članova tima. [Pawson 2004]

• Kompatibilan sa agilnim metodologijama razvoja softvera, kao što je Ekstremno programiranje – Pawson-ove smernice pomažu u poboljšanju agilnosti i daju preporuke oko korišćenja istog u kontekstu metoda razvoja. [Pawson 2004] [Pawson & Wade 2003] [Keränen & Abrahamsson 2005a]

• Stavlja Domain-Driven Design u praktični kontekst – poznato je iz prethodnog poglavlja da su neki principi i obrasci DDD-a teško upotrebljivi u praksi. Naked Objects pristup olakšava upotrebu DDD-a. [Haywood 2009]

• Ako ništa drugo, može se koristiti samo za identifikaciju korisničkih zahteva – zahvaljujući automatski generisanom GUI-ju i kratkim iteracijama, razvojni tim će uspeti da identifikuje više zahteva i da rešava veći broj problema nego uobičajenim načinima. Čak i ako se donese odluka da se kasnije izbaci Naked Objects iz upotrebe, iskustvo stečeno u fazi istraživanja će poboljšati efikasnost tima u kasnijim fazama razvoja. [Pawson 2004] [Constantine 2002]

Naravno i Naked Objects pristup ima neke probleme, i o većini njih je već bilo reči u prethodnim delovima ovog poglavlja. Znači, mane Naked Objects pristupa su:

• Odgovara suverenim aplikacijama ali ne i prolaznim59 – ovo je indirektno navedeno i u smernicama. [Raja & Lakshmanan 2010]

• Serijska obrada velikih količina podataka može biti problematična – ovo nije direktna krivica Naked Objects pristupa, nego njegovog promovisanja lepog objektno-orijentisanog koda. Pošto se podaci uglavnom perzistuju u relacione baze podataka, dolazi do sudara između objektno-orijentisane i relacione paradigme. Zato se preporučuje ili ručno optimizovanje koda radi povećanja performansi, ili prosleđivanje ove obrade drugim sistemima. [Pawson 2004]

• Skalabilnost još nije dovoljno testirana – još ne postoje empirijski dokazi o

59 Po stavu (eng. Posture), znači u smislu načina interakcije softvera sa korisnikom, aplikacija može biti suverena, prolazna i pozadinska. Suverena (eng. Sovereign) aplikacija oduzima celu pažnju korisnika na duže vreme, kao što je Microsoft Word. Ovakve aplikacije najčešće zauzimaju ceo ekran. Prolazne (eng. Transient) aplikacije „dolaze pa odlaze“, tj. rešavaju samo određen broj manjih problema, prema tome, one se startuju samo po potrebi, a posle se zatvore, da bi se korisnik vratio glavnoj (najčešće suverenoj) aplikaciji. Ovoj grupi pripada npr. Calculator. Konačno, pozadinske (eng. Daemonic) aplikacije rade u pozadini, i upozoravaju korisnika samo po potrebi, kao što su antivirusne aplikacije. [Cooper, Reimann & Cronin 2007]

63

tome, da li bi povećanje modela domena ili količine podataka predstavljalo problem za Naked Objects. Teorijski rečeno, ova osobina bi trebala da zavisi prvenstveno od implementacije pristupa, tj. od framework-a. [Pawson 2004]

• Nemogućnost ručnog pravljenja GUI-ja – iako je Naked Objects pristup blizu ideje originalne MVC arhitekture, što aludira na sposobnost menjanja korisničkih interfejsa, taj interfejs i dalje mora biti OOUI, što sa sobom nosi određene posledice, npr. da GUI neće voditi korisnika. [Pawson 2004]

• Upotrebljivost OOUI-ja je diskutabilna – Naked Objects pristup daje minimalnu ili čak nikakvu mogućnost za prilagođavanje GUI-ja, a ovo sa aspekta upotrebljivosti može biti problematično. Svojstva OOUI-ja, kao što su Drag and Drop funkcionalnost, korišćenje desnog klika na mišu, i „imenica-glagol“ stil interakcije, takođe mogu biti problematična. [Constantine 2002]

• Može se činiti da je Naked Objects pristup neki magični alat, što će otežati sposobnost realnog procenjivanja složenosti zahteva – Naked Objects pristup strahovito ubrzava razvoj nekih korisničkih zahteva, ali ne svih. Ovo može otežati sposobnost razvojnog tima da proceni vreme potrebno za implementaciju scenarija. [Keränen & Abrahamsson 2005a]

S ovim je teorijsko predstavljanje Naked Objects pristupa završeno. Međutim, treba se osvrnuti i na praktičnu stranu u vidu predstavljanja neke implementacije pristupa, što će biti tema sledećeg poglavlja, ali će se prvo predstaviti demonstracioni primer.

64

4. Opis demonstracionog primera (pubDB)Pre nego što se pređe na predstavljanje Naked Objects framework-a, potrebno je

predstaviti i primer koji će se koristiti za demonstraciju. Aplikacija se zove pubDB (skraćenica od Publication Database, u prevodu baza podataka za publikacije) i predstavlja jednostavni informacioni sistem za skladištenje i upravljanje publikacijama.

Funkcionalnost pubDB-a bi se mogla opisati na sledeći način: pubDB treba da omogućava korisnicima da barataju sa publikacijama, kao što su članci i knjige. Treba omogućiti da se članci stave u naučne časopise, a knjige da imaju izdavača. Treba omogućiti da se svaka publikacija poveže sa autorima, i konačno, da se kategorišu na osnovu kategorije, tj. oblasti kojoj pripadaju. Kategorije bi se predstavile u obliku hijerarhije, drugim rečima, kategorije bi se mogle deliti na podkategorije. Informacioni sistem bi imao jednostavne CRUD operacije (skraćenica od Create, Read, Update, Delete; u prevodu napravi, učitaj, ažuriraj i briši) kao i Search (tj. pretraživanje). Prema tome, sistem bi morao da ima i neki mehanizam za perzistenciju ovih podataka.

Što se tiče uloga, zbog jednostavnosti je doneta odluka da sistem ima samo jednu ulogu: administratorsku, tj. da se pubDB koristi od strane jednog korisnika koji bi imao sva moguća prava. Zapravo, ova odluka je i logična, budući da je cilj da se pokažu razlike između Naked Objects pristupa i klasične višeslojne arhitekture, a ne da se demonstriraju neke napredne osobine Naked Objects framework-a.

Što se tiče modela pubDB-a, jasno je da će model imati entitete koji se vezuju za publikacije, poput kategorije, autora, itd. Prvo će se predstaviti ER-model (skraćenica od Entity-Relationship Model) sistema. PubDB ima sedam tipova entiteta: Author, Category, Publication, Article, Book, Journal i Publisher (u prevodu redom Autor, Kategorija, Publikacija, Članak, Knjiga, Časopis i Izdavač). Što se tiče tipa entiteta Author, on se jedinstveno identifikuje na osnovu njegovog ili njenog identifikacionog tj. ID broja, ali postoje podaci i o prezimenu, imenu i biografiji.

Tip entiteta Publication predstavlja generičnu publikaciju. Publikacija ima svoj identitet na osnovu koga se identifikuje, a ostala obeležja su: naslov publikacije, godina publikacije i opis. Jedan Autor može da piše jednu ili više Publikacija, ali ne mora ni jednu (drugim rečima, Autor može da postoji bez ijedne pisane Publikacije). S druge strane, jedna Publikacija se piše od strane bar jednog Autora (tj. Publikacija ne može da postoji bez srodnog Autora).

Jedna generična Publikacija mora biti ili Article (tj. Članak) ili Book (tj. Knjiga). Jedna Publikacija koja je Članak, ne može istovremeno da bude i Knjiga, i obrnuto, Knjiga ne može istovremeno da bude i Članak. Što se tiče tipa entiteta Članak, osim što nasleđuje zajednička obeležja generične Publikacije kao što su ID broj, naslov, godina publikacije i opis, takođe ima i jedan jedinstven atribut koji ne postoji kod Knjiga, a to je DOI (skraćenica od Digital Object Identifier). S druge strane, Knjiga, pored nasleđivanja zajedničkih atributa generične Publikacije, ima još tri jedinstvena obeležja: broj strana, ISBN (skraćenica od International Standard Book Number) i korice (u obliku slike)60.

60 Važno je napomenuti da ovaj atribut nije implementiran u Naked Objects verziji pubDB-a zbog nedostatka u samom framework-u. Više reči o ovom nedostatku biće još u odeljcima 6.2.2 i 6.5.

65

Jedan Članak se objavljuje isključivo u naučnom Časopisu, predstavljen tipom entiteta Journal. Jedan Članak se objavljuje u tačno jednom Časopisu, i ne može da postoji bez srodnog Časopisa. U jednom Časopisu se objavljuje jedan ili više Članka, ali ne mora ni jedan. Časopis se jedinstveno identifikuje na osnovu svog ID broja, a postoje podaci i o nazivu i o tomu.61 S druge strane, jedna Knjiga se izdaje od strane Izdavača, predstavljenog tipom entiteta Publisher. Slično, kao i kod Članka, jedna Knjiga može imati tačno jednog Izdavača, i ne može da postoji bez srodnog Izdavača. Jedan Izdavač može izdati jednu ili više Knjiga, ali ne mora ni jednu. Izdavač (kao firma) se jedinstveno identifikuje na osnovu svog ID broja, a ostali atributi su naziv i mesto izdavača.

Konačno, sve Publikacije (bez obzira da li su Članci ili Knjige) moraju pripadati nekoj Kategoriji. Jedna Publikacija mora da pripada tačno jednoj Kategoriji. S druge strane, jedna Kategorija može biti povezana sa jednom ili više Publikacija, ali ne mora ni sa jednom. Tip entiteta Category ima samo dva atributa: jedinstven ID broj i labela (tj. naziv). Međutim, skup kategorija se mora tretirati u obliku hijerarhije. Prema tome, jedna pojedinačna Kategorija (tj. čvor) u hijerarhiji može biti ili roditelj-kategorija, ili dete-kategorija, ili nijedna od njih (u slučaju da postoji samo jedna Kategorija u hijerarhiji), ili oba. Jedna pojedinačna Kategorija može imati jednu ili više podkategorija (tj. dece), ali ne mora ni jednu. S druge strane, jedna pojedinačna Kategorija može imati jednog ili nijednog roditelja, ali nikad ne može imati dva.

Slika 10 prikazuje ER-dijagram pubDB-a. Međutim, model ima neke

61 Mora se napomenuti da se dva različita toma jednog časopisa smatraju dvema različitim pojavama tipa entiteta Časopis, npr. 15. i 16. broj (tj. tom) časopisa „IEEE Software“ su dva fizički različita časopisa.

66

Slika 10: ER-dijagram pubDB-a

WritesAuthor(0, N)

Publication

Book

Category

Article

PublisherJournal

Belongs toHas

IS_A

Appears in

(1, N) (1, 1) (0, N)

(0, N)

(0, 1)

(1, 1)

(0, N)

(1, 1)

(0, N)

subcategory

(1, 1)

Published by

AUTHOR_ID

LAST_NAME FIRST_NAME

BIO

PUB_YEARPUB_ID PUB_TITLE

PUB_DESC

CAT_LABEL

CAT_ID

DOI

COVER

ISBN

PAGES

JOURNAL_VOL

JOURNAL_TITLE

JOURNAL_ID

PUB_ADDRESS

PUBLISHER_NAME

PUBLISHER_ID

karakteristike koje se moraju napomenuti:

• Svi tipovi poveznika su dvosmerni: pojava tipa entiteta uvek može pristupiti pojavama susednog tipa entiteta, bez obzira sa koje strane poveznika se ta pojava nalazi.

• Većina poveznika ima kardinalitet jedan-prema-više (tj. 1-N), sem jednog poveznika koji je tipa više-prema-više (tj. N:M), a to je veza između Autora i Publikacije.

• Veza između tipova entiteta Publikacija, Članak i Knjiga je modelirana kao totalna i disjunktna IS_A hijerarhija. Ona je totalna, jer svakoj pojavi superklase Publikacija odgovara bar jedna pojava neke od potklasa (Članak ili Knjiga). Ovo znači da je minimalni kardinalitet 1. S druge strane, hijerarhija je disjunktna, jer je svakoj pojavi superklase pridružena najviše jedna pojava potklase. Ovo stavlja maksimalni kardinalitet na 1. Sve u svemu, jedna Publikacija mora biti ili Članak ili Knjiga (drugih mogućnosti nema), ali ta Publikacija ne može istovremeno biti i Članak i Knjiga.

• Većina tipova poveznika je binarna, tj. oni predstavljaju veze između dva tipa entiteta, međutim, postoji jedan tip poveznika koji modelira vezu između samo jednog tipa entiteta: Kategorija. Ovo je zapravo rekurzivni tip poveznika, i pomoću njega se modelira prethodno spomenuta hijerarhija kategorija. Jedna pojedinačna kategorija može imati nijednu, jednu ili više podkategorija, i nijednog ili jednog roditelja tj. nadkategoriju.

Na osnovu ER-modela se može kreirati i objektni model. Slika 11 prikazuje objektni dijagram pubDB-a.

Za potrebe ovog rada, biće predstavljene dve verzije pubDB-a. U prvoj verziji se koristi klasični četvoro-slojni pristup, a u drugoj Naked Objects pristup. Prva verzija je rađena u Java EJB 3, a druga u Naked Objects framework-u (v4.0). Za perzistenciju podataka se odlučilo da se koristi relaciona baza podataka za prvu verziju sistema, i in-memory kao i XML perzistor za drugu verziju.

Što se tiče implementacije pubDB-a, prvu verziju je autor ovog rada implementirao još u proleće 2011. godine, kad još uopšte nije ni čuo o Naked Objects pristupu i o NOF-u. Drugu verziju je implementirao krajem 2011. godine.

Prethodno spomenute dve verzije pubDB-a će se detaljno porediti u poglavlju 6, ali pre toga je potrebno predstaviti Naked Objects framework.

67

68

Slika 11: Objektni dijagram pubDB-a

5. Naked Objects frameworkPoglavlje 3 se bavilo generalnim predstavljanjem Naked Objects pristupa, i to sa

teorijske tačke gledišta, koje je bilo potrebno za adekvatno razumevanje istog. Međutim, drugi deo se odnosi na praktično predstavljanje obrasca. Za te svrhe, potrebno je izučavati jednu njegovu implementaciju, tj. neki framework: kako funkcioniše, na koji način se pišu Naked Objects programi uz pomoć tog framework-a i kako izgledaju ti programi pri izvršavanju. Za potrebe ovog poglavlja, izabran je besplatni Naked Objects framework za programski jezik Java.

Poglavlje je struktuirano na sledeći način: prvo će biti par reči i o nekim drugim implementacijama pristupa, a zatim će se preći na generalno opisivanje Naked Objects framework-a sa još jednim osvrtom na višeslojne arhitekture, gde će se opisati heksagonalna arhitektura. Zatim će se preći na predstavljanje koncepata iz Naked Objects framework-a (i Domain-Driven Design-a), kao što su entiteti, fabrike, repozitorije, fiksture, itd., a njihovo korišćenje će se prikazati kroz kratke delove izvornog koda iz Naked Objects verzije pubDB-a (opisana u poglavlju 4).

5.1. Neke implementacije Naked Objects obrascaPre nego što se pređe na predstavljanje Naked Objects framework-a, bilo bi

zgodno sa par reči opisati i neke druge implementacije Naked Objects pristupa. Biće predstavljene sledeće implementacije: BlueJ IDE, Naked Object Architecture, Naked Objects framework i Naked Objects for .NET.

5.1.1.BlueJ IDEBlueJ (Slika 12) od autora Michael Kölling-a i John Rosenberg-a je prilično

čudan izbor za jednu Naked Objects implementaciju, iz više razloga. Pre svega, dok drugi framework-ovi omogućavaju pisanje Naked Objects aplikacija, BlueJ je zapravo jedno razvojno okruženje (tj. IDE) za pisanje programa u programskom jeziku Java. Druga zanimljivost je da BlueJ zvanično nema veze sa Naked Objects pristupom, a treća da on koristi osobinu „izražajnosti“ za vizuelizaciju strukture pisanih Java programa, a ne za predstavljanje samih objekata u nekom GUI-ju.62 [Läufer 2008]

Motivacija za kreiranje BlueJ-a je bila pedagoške prirode. Naime, predavati na kursu za učenje Jave i objektne-orijentisanosti na fakultetima nije uopšte trivijalan zadatak, pre svega i zbog neadekvatnog alata. Alati koji se koriste za pedagoške svrhe često nisu ni objektno-orijentisani (pa studenti barataju sa fajlovima i programima, i sem izvornog koda ništa drugo ne vide), ili su suviše komplikovani, ili su fokusirani na kreiranje GUI-ja. Zbog toga, mnogi predavači ni ne koriste IDE, nego samo obični tekstualni editor, a kompajliranje se vrši ručno u komandnoj liniji, mada i ovo rešenje ima svoje slabosti. BlueJ je bio predstavljen upravo za učenje objektne-orijentisanosti na fakultetima, i namenjen je studentima. [Kölling et al. 2003]

62 Zvanična stranica BlueJ IDE-a se nalazi na adresi <http://www.bluej.org/>.

69

Ideja iza ovog IDE-a je jednostavna: tokom rada, studenti moraju osetiti da zaista barataju sa pravim klasama i objektima. Prema tome, glavni prozor BlueJ-a zapravo prikazuje UML dijagram klasa (Slika 13). Duplim klikom na neku klasu pojavljuje se prozor koji prikazuje izvorni kod te klase, a zatvaranjem ovog prozora promene se sačuvaju, a dijagram se ažurira. Na dijagramu je moguće crtati i veze asocijacije i nasleđivanja. Dijagram i izvorni kod su povezani dvosmernom vezom, pa

70

Slika 12: Zvanični logo BlueJ-a. Izvor: <http://commons.wikimedia.org/wiki/File

%3ABlueJ_Logo.gif>.

Slika 13: Glavni prozor BlueJ-a sa dijagramom klasa. Na donjem delu prozora se nalazi deo za objekte, npr. staff_1 je objekat tipa Staff. Izvor: [Kölling et al.

2003].

se bilo koje promene u kodu propagiraju ka dijagramu, i obrnuto. Ako klasa ima konstruktor, moguće je kreirati objekat te klase pomoću desnog klika na klasu, a zatim izborom željenog konstruktora. Tada će se prvo pojaviti prozor gde se može zadati ime novog objekta, kao i vrednosti parametara (ako ih ima), a zatim će se objekat pojaviti (tj. živeće) u donjem delu glavnog prozora. Metodi ovog objekta se mogu pozvati desnim klikom na objekat, nakon čega će se pojaviti mali prozor gde se mogu zadati parametri (uključujući i parametre referencijalnog tipa). Takođe, stanje (tj. polja) nekog objekta se može pogledati (i promeniti) bilo kad, pomoću Inspect naredbe. BlueJ ima i jednostavni debugger, automatski generiše dokumentaciju pisanog programa, a ima i mogućnost pakovanja projekta u JAR fajlove. [Kölling et al. 2003]

Što se tiče procene vrednosti ovog pedagoškog IDE-a, rezultati su uglavnom ohrabrujući, ali su potrebna dalja istraživanja. Tako su na primer u [Haaster & Hagan2004] opisani neki pozitivni efekti korišćenja BlueJ okruženja sa studentima, pre svega u vidu boljeg razumevanja objektno-orijentisane paradigme i bolje prolaznosti na ispitu. Međutim, u [Xinogalos et al. 2006] su dokumentovani i neki potencijalni problemi, na primer teže snalaženje studenata bez vizuelne pomoći (tj. UML dijagrama klasa) i problemi sa čitanjem i razumevanjem izvornog koda. Slični problemi su opisani i u [Kölling et al. 2003] u kojem se primećuje da je studentima teže da ostave BlueJ nakon polaganja ispita.

Iako neki smatraju da je BlueJ jedna implementacija Naked Objects pristupa, BlueJ je zapravo postojao pre nego što je Naked Objects bio zvanično dokumentovan. [Läufer 2008] Njihova namena je drugačija i ciljaju različite grupe, ali je očigledno da BlueJ ima velike sličnosti sa načelima Naked Objects-a. Međutim, ne sme se zaboraviti da „izražajnost“ objekata nije novi koncept, i bila je prisutna i u Smalltalk-u.

5.1.2.Naked Object ArchitectureOva implementacija se razvila za Irsku vladu za potrebe izrade sistema za

administraciju dečijeg dodatka. Prethodno je nosio naziv Expressive Object Architecture, a tek je tokom 2003. godine promenio naziv u Naked Object Architecture. [Pawson 2004] O ovom framework-u je već bilo dosta reči u odeljku 3.5.1.

5.1.3.Naked Objects frameworkIzradu Naked Objects framework-a (skraćeno NOF) je inicirao Robert Matthews,

koautor „Naked Objects“ knjige i bio je zamišljen kao besplatni, otvoreni (tj. open-source) projekat za pisanje Naked Objects aplikacija u programskom jeziku Java. Neku raniju prevremenu verziju su koristili čak i tokom razvoja CBA sistema za Irsku vladu radi izrade prototipova modela. [Pawson 2004]

Matthews je rad na framework-u počeo još 1999. godine posle niza konsultacija sa Richard Pawson-om, autorom Naked Objects pristupa.63 Prva prava verzija NOF-a, verzija v1.0, se pojavila 4. decembra 2002. godine, pod GNU opštoj javnoj licenci v2 (eng. GNU General Public License v2), a prva javno dostupna verzija, v1.0.2, se pojavila 5. februara 2003.64 Sledeća prekretnica, verzija v2.0, se pojavila 28. juna 2006.

63 Izvor: zvanična dokumentacija distribucije Naked Objects framework-a (v1.2.2).64 Izvor: zvanična dokumentacija distribucije Naked Objects framework-a (v1.0.2).

71

godine. Verzija v3.0 se pojavila 1. oktobra 2007., ali od sad pod Apache v2.0 licencom. Konačno, aktuelna verzija, v4.0, koja će se koristiti u nastavku poglavlja, se pojavila 10. avgusta 2009. godine. Najveća novina ove verzije je bila „komponentizacija“ do sada monolitnog framework-a, sa glavnim jezgrom i sa brojnim komponentama koje funkcionišu na „plug-in“ način. Tako su na primer pogledi su postali komponente.65

Slika 14: Zvanični logo Naked Objects framework-a i Apache Isis-a.Izvor: <http://www.nakedobjects.org/>.

Naravno, razvoj framework-a nije stao, naprotiv, u poslednje vreme došlo je do velikih pomaka. Možda je najveća novina ta da je tokom 2010. godine projekat migrirao u Apache Software Foundation i promenio naziv u Apache Isis (Slika 14). Razlozi za migraciju su bili mnogobrojni: veće zadovoljstvo i od strane korisnika i od strane programera (bez obzira da li žele samo koristiti framework ili ga žele proširiti), bolja tehnička podrška, veći publicitet, drugim rečima, obezbeđivanje svetlije budućnosti. Naziv je promenjen budući da je NOF od verzije v4.0 postao više od obične implementacije Naked Objects obrasca, naime, počeo je intenzivno da preuzima načela Domain-Driven Design-a.66 Isis se trenutno nalazi u Apache Incubator-u67. Najnovija verzija Isis-a (do pisanja ovog rada) je v0.2.0-incubating i izdata je 20. februara 2012.68

Iako je Isis sa tehničkog aspekta noviji, ipak je doneta odluka da se koristi nešto stariji Naked Objects framework v4.0. Razlog ovoj odluci leži u činjenici da projekti unutar Apache Incubator-a nisu nužno stabilni, njihova svojstva se stalno menjaju, a i dokumentacija je ograničena i nepotpuna. U ovom smislu ni Isis nije izuzetak: tako je na primer, jedan od najvažnijih pogleda za posmatranje objekata izbačen iz najnovije verzije Isis-a, zbog dorade i najave velikih refaktorisanja unutar projekta.69 Takođe, NOF v4.0 ima mnogo bolju i kompletniju dokumentaciju od Isis-a. Međutim, ova odluka je kasnije donela i jednu negativnu posledicu: nemogućnost perzistiranja u

65 Izvor: zvanična dokumentacija distribucije Naked Objects framework-a (v4.0).66 Izvor: <http://wiki.apache.org/incubator/IsisProposal>.67 Svi projekti koji žele postati deo Apache-a moraju prvo proći kroz Apache Incubator.68 Zvanična stranica Isis-a se nalazi na adresi <http://incubator.apache.org/isis/>. Stare

verzije Naked Objects framework-a (uključujući i verziju v4.0) se mogu preuzeti sa adrese <http://sourceforge.net/projects/nakedobjects/>.

69 Izvor: zvanični blog Dan Haywood-a, autora knjige „Domain-Driven Design Using Naked Objects“ i ko-kreatora NOF-a i Isis-a <http://danhaywood.com/2012/02/27/apache-isis-0-2-0-incubating-released/>.

72

relacionu bazu podataka. Više reči o ovoj posledici biće u odeljku 6.3.

5.1.4.Naked Objects for .NETKad je nov sistem za administraciju dečijeg dodatka (CBA) za Ministarstvo za

socijalnu zaštitu zaživeo krajem 2002. godine (pravljen u NOA), niko nije očekivao da će biti tako uspešan, a ministarstvo je izrazilo želju da se modernizuju i neki drugi informacioni sistemi. Nešto kasnije, početkom 2003., pojavila se i prva javna verzija besplatnog i otvorenog Naked Objects framework-a. Uprava je uvidela da je NOF moćniji od NOA, i donela je odluku70 da sledeći sistem (administracija penzija) bude pravljen u ovom framework-u (tj. pisan u Javi), koji bi se zatim kompajlirao za .NET platformu. Posle završetka radova, kreatori framework-a su odlučili da ga podele na dva odvojena projekta: prvi će nastaviti razvoj besplatnog i otvorenog framework-a za Javu, a drugi će se fokusirati na .NET verziju i postaće komercijalni proizvod. Ministarstvo je 2004. godine napravilo ugovor sa Richard Pawson-ovom firmom, Naked Objects Group Ltd., radi modernizacije većeg broja informacionih sistema. Sistemi su zaživeli tokom 2006. godine. Naked Objects Group je usput napravio i pravu .NET verziju framework-a, implementirajući ga od nule. Tako je nastao Naked Objects for .NET, za koji je ministarstvo nabavilo enterprise licencu.71

Naked Objects for .NET (koji je sredinom 2010. postao Naked Objects MVC) je bio komercijalni proizvod – sve do kraja 2011. godine, kad je konačno postao besplatni i otvoreni proizvod pod Microsoft javnom licencom (eng. Microsoft Public License, skraćeno Ms-PL).72 Pošto je Java verzija framework-a promenila ime u Isis, .NET verzija je preuzela stari Naked Objects naziv.

5.2. Konstrukcija Naked Objects framework-aU ovom odeljku će se detaljnije predstaviti osnovi Naked Objects framework-a.

Prvo treba opisati njegova osnovna načela i njegovu strukturu, a zatim će se ponovo osvrnuti na višeslojne arhitekture, gde će se opisati heksagonalna arhitektura.

5.2.1.Osnovna načela Naked Objects framework-aKao što je već poznato, Naked Objects framework je jedna besplatna i otvorena

implementacija Naked Objects obrasca za programski jezik Java. Iza naziva Naked Objects (tj. „goli objekti“) stoji ideja da korisnik zapravo posmatra i manipuliše golim domenskim objektima. Sa aspekta framework-a, prethodna rečenica u praksi označava da su ti domenski objekti sve što programeri moraju da naprave, i to u POJO obliku (skraćenica od Plain Old Java Objects)73. [Raja & Lakshmanan 2010]

Po Dan Haywood-u, NOF v4.0 ima tri cilja: [Haywood 2009]

• Da pomaže rapidnu izradu prototipova – pošto NOF ne zahteva pisanje koda za

70 Takođe, firma zadužena za izradu NOA i CBA sistema ih nije razvila na iterativni način, nego pomoću vodopadnog modela, što nije odgovaralo agilnim načelima Naked Objects pristupa. [Pawson 2004]

71 Izvori: <http://nakedobjects.net/resources/dsfa_case_study.shtml> i <http://wiki.apache.org/incubator/IsisProposal>.

72 Zvanična stranica za Naked Objects for .NET se nalazi na adresi <http://nakedobjects.codeplex.com/>.

73

GUI (a podrazumevano ni za perzistenciju), vreme razvojnog ciklusa u jednoj iteraciji se smanjuje, a rezultati dolaze brže.

• Da pomaže pri razvoju – NOF v4.0 je usko integrisan sa drugim softverskim alatima, kao što je Eclipse IDE (za kodiranje) i Maven (za pravljenje i podešavanje Naked Objects projekata, kao i njihovo pakovanje).

• Da pomaže pri deployment-u – NOF v4.0 je konačno uveo komponentizovanu arhitekturu, pa pogledi i mehanizmi perzistencije funkcionišu na „plug-in“ načinu.

Sa aspekta komponentizacije, NOF v4.0 se sastoji od glavnog jezgra (eng. Core) i od nekoliko plug-in komponenata. Dve najvažnije grupe ovih plug-in-ova su pogledi (eng. Viewers) i mehanizmi za perzistenciju, tzv. perzistori (eng. Persistors, ali se još koristi i naziv Object Store, u prevodu skladišta objekata). NOF se isporučuje sa dva ugrađena pogleda i sa dva perzistora. Ugrađeni pogledi su DnD i HTML. DnD pogled (skraćenica od Drag-n-Drop) omogućava posmatranje objekata u vidu Java aplikacije, i aktivno koristi osnovna načela OOUI-ja, kao što su desni klik i Drag and Drop funkcionalnost. S druge strane, HTML pogled ima sličnu funkcionalnost ali radi u Web brauzeru. Što se tiče perzistora, ugrađena su dva: in-memory (podrazumevani način) i XML. In-memory perzistor čuva podatke u radnoj memoriji, ali se oni brišu kad korisnik zatvori aplikaciju, zato ovo nije pravi način perzistencije, ali je odličan za izradu prototipova. S druge strane, XML perzistor čuva podatke u XML bazi podataka, pa se oni ne gube ni nakon zatvaranja aplikacije. Naravno, ne sme se zaboraviti da pored ugrađenih plug-in-ova postoje još i drugi pogledi i perzistori, a u slučaju da nijedan od njih ne zadovoljava potrebe, programeri su slobodni da naprave nove. [Raja &Lakshmanan 2010] [Haywood 2009]

Celi NOF bi se mogao sumirati pomoću jednog konceptualnog dijagrama (Slika15). [Raja & Lakshmanan 2010] Na dijagramu se vidi da se interfejs aplikacije sastoji od domenskih objekata, fikstura i servisa. Domenski objekti su predstavljeni ikonama, i imaju tri elementa: naslov (koji služi za identifikaciju objekata), osobine (tj. polja objekta) i akcije (ponašanje objekta u vidu metoda). Fiksture služe za pohranjivanje aplikacije sa podacima prilikom njenog pokretanja, i najčešće se koriste zajedno sa in-memory perzistorom. Konačno, servisi predstavljaju funkcije (akcije, naredbe) koje prirodno ne pripadaju domenskim objektima, pa su definisane posebno. U ovu grupu pripadaju repozitorije koje služe za skladištenje objekata i fabrike koje služe za njihovo kreiranje. Zapravo, ova dva koncepta predstavljaju obrasce iz Domain-Driven Design-a.74

73 Naziv POJO označava regularne Java objekte, bez ikakvih dodataka. Naziv je formulisao Martin Fowler tokom 2000. godine, čisto da bi dao zvučni naziv najobičnijim objektima, koji su ranije bili ignorisani od strane kompanija. Ironično, naziv je za kratko vreme doživeo veliku popularnost, i naterao velikane da pojednostave svoje proizvode. U „čistom“ obliku, POJO označava objekte koji nisu vezani restrikcijama sem interne Java biblioteke, tj. ne implementiraju ili nasleđuju predefinisane klase, niti ih koriste u vidu anotacija. [Panda, Rahman & Lane 2007] [Haywood 2009]

74 O konceptima spomenutim u prethodna dva pasusa biće još reči u kasnijim odeljcima ovog poglavlja.

74

5.2.2.Višeslojne arhitekture (treći put)Diskusija o višeslojnim arhitekturama se u odeljku 3.1 završila konstatacijom da

su objekti danas behavioralno-slabi zbog rasipanja njihovog ponašanja u drugim slojevima. Iako u nešto opštijem smislu, ali s ovim se slaže i Alistair Cockburn, jedan od pisaca agilnog manifesta. On smatra da je opasnost da se poslovna logika infiltrira u ostale slojeve – realna. Naime, postoje dve opasnosti: [Cockburn 2005]

• Rasipanje poslovne logike u izvorni kod korisničkog interfejsa – ovo otežava adekvatno testiranje sistema (pošto je deo poslovne logike u prezentacionom sloju koji se stalno menja), a takođe onemogućava da se GUI zameni mehanizmom automatizovanog serijskog izvršavanja ili da se poveže sa drugim eksternim sistemima. GUI je zapravo postao deo poslovne logike.

• Usko vezivanje poslovne logike sa spoljnim servisima (npr. bazama podataka) – u slučaju da baza podataka postane nedostupna, programeri neće moći da rade na razvoju sistema, pošto je dostupnost baze krucijalna za njihov rad.

Osnovni problem zapravo leži u lošem dizajnu – granica između unutrašnjosti sistema i njegove spoljašnjosti se gubi, iako po pravilu, izvorni kod koji se tiče unutrašnjosti ne bi trebalo da pobegne u spoljašnji deo. Jedna aplikacija zapravo komunicira sa spoljašnjim „entitetima“ pomoću portova75. Ovi entiteti imaju adapter, koji konvertuje API definicije na njihov „jezik“ i obrnuto. Na primer, GUI se može tretirati i kao adapter za korisnika, pošto je njegova namena da preslikava naredbe korisnika ka pozivima unutar API-ja. Slično, SQL adapter je adapter neke relacione baze podataka, i da bi aplikacija pristupala podacima iz baze, komuniciraće sa ovim adapterom preko porta, koristeći protokol baze podataka. U jedan port se može uključiti više adaptera.76 Tako na primer, umesto GUI-ja bi se mogli koristiti mehanizmi za testiranje, drajveri za serijska izvršavanja ili drugi spoljašnji sistemi. Analogno, umesto

75 Port se može zamisliti na više načina. Npr. port na nekom električnom uređaju označava mogućnost da se drugi uređaji priključe na posmatrani uređaj, jedino je važno da budu kompatibilni sa protokolom porta posmatranog uređaja. Situacija je slična i kod operativnih sistema. Protokol se može zamisliti i kao API (eng. Application Program Interface). [Cockburn 2005]

76 Ovo je logično, pošto jedna aplikacija u većini slučajeva ima više načina za ulaz u tu aplikaciju, i više načina za izlaz iz te aplikacije. [Haywood 2009]

75

Slika 15: Konceptualni dijagram NOF-a. Izvor: [Raja & Lakshmanan 2010].

Interfejs NOF-a

ServisiFikstureDomenski objekti

AkcijeOsobine (atributi)Naslov RepozitorijeFabrike

SQL adaptera bi se mogli koristiti adapteri drugih tipova baza podataka, kao što su XML adapteri i slično. Pri tome, nije zadatak porta (tj. unutrašnje aplikacije) da se prilagodi adapterima, nego obrnuto, da se adapteri prilagode portu. [Cockburn 2005]

Prema tome, aplikacije u jednostavnom slučaju imaju dva porta: korisnički port (eng. User-Side Port) i port za baze podataka (eng. Database-Side Port, mada se koristi i naziv port za podatke (eng. Data-Side Port)). Ovo se može predstaviti i pomoću višeslojnih arhitektura, pri čemu će se adapteri za korisnički port (npr. GUI) nalaziti iznad aplikacije, a adapteri za port za podatke (npr. SQL) ispod. Međutim, korišćenje višeslojnih arhitektura u ovakvim situacijama ipak nije srećno rešenje, pre svega zato što će programeri intuitivno ponovo početi sa rasipanjem poslovne logike ka drugim slojevima, ali i zato što aplikacija može imati više od dva porta. [Cockburn 2005]

Ovako je nastao arhitektonski obrazac pod nazivom „portovi i adapteri“ (eng. Ports and Adapters) od strane Alistair Cockburn-a, mada se popularnije zove heksagonalna arhitektura (eng. Hexagonal Architecture). Obrazac se vizuelno prikazuje pomoću dva heksagona tj. šestougaonika (Slika 16). Unutar manjeg se nalazi aplikacija, sa stranicama kao portovima, a u prostoru između dva heksagona su stavljeni adapteri spoljašnjih entiteta. Spoljašnji entiteti se nalaze van većeg heksagona. Ovakva reprezentacija jasno i koncizno definiše granice, i olakšava dodavanje novih portova. Šestougaonik se koristi samo kao vizuelna pomoć, zato što se u praksi ne preporučuje da sistem ima više od četiri porta. Ova arhitektura je donekle povezana i sa MVC arhitekturom, budući da obe promovišu jednostavno menjanje pogleda, mada se primećuje da heksagonalna arhitektura ide i korak dalje, pošto MVC ne razmatra desni deo šestougaonika (port podataka i odgovarajuće adaptere). [Cockburn 2005]

76

Slika 16: Heksagonalna arhitektura sa dva porta i nekoliko spoljašnjih entiteta sa odgovarajućim adapterima. Izvor: [Cockburn 2005].

AplikacijaKoris

nički

port Port za podatke

GUIadapter

Adaptereksternogsistema

Adapter testframework-a

Drajver zaserijsko

izvršavanje

XML adapter

SQL adapter

Haywood smatra da se NOF lepo uklapa u heksagonalnu arhitekturu sa četiri porta (Slika 17). Kao što bi se moglo očekivati, sa leve (korisničke) strane se nalaze pogledi koji sa centralnim heksagonom komuniciraju preko dva porta: in-memory i daljinskim. Većina pogleda radi u istom memorijskom prostoru kao i domenski sloj, znači oni pristupaju tom sloju preko in-memory porta. Naravno, neki drugi pogledi mogu pristupiti ovom sloju preko daljinskog porta (u slučaju klijent-server načina deployment-a). S druge, desne strane heksagona se nalaze dva porta za podatke: perzistencija i servisi. Port za perzistenciju komunicira sa perzistorima, kao što su in-memory i XML. Konačno, servis port služi za pozivanje servisa koji ne moraju nužno biti implementirani unutar NOF-a.77 [Haywood 2009]

77 Kao što se može videti na slici, NOF ima zaista velik izbor adaptera, ali treba napomenuti, da njihovo detaljno predstavljanje (znači pogleda, perzistora i servisa) nije cilj ovog rada. Slika je navedena u originalnom obliku samo radi kompletnosti. U nastavku sledi njihov kratak opis:• RCP pogled je zapravo Rich Client Objects pogled u vidu aplikacije (nalik na DnD), koji koristi

Eclipse RCP kao platformu. Eclipse RCP (skraćenica od Rich Client Platform) aplikacije su one koje se zasnivaju na Eclipse-u, ali čija svrha nije razvoj softvera.

• Scimpi je preintegrisani Web framework za NOF koji pored uobičajenog HTML-a ume da barata sa XML tag-ovima i XHTML-om. Pogledu se može pristupiti iz Web brauzera.

• Wicket pogled koristi Apache Wicket, Web framework za Javu nalik na JSF (JavaServer Faces). I ovom pogledu se pristupa iz Web brauzera.

• FitNesse predstavlja jedan framework za testiranje scenarija u vidu tabela koje se pišu unutar Wiki-ja, i može se integrisati sa NOF-om.

• Headless pogled „simulira“ ponašanje jednog pravog pogleda (zapravo komunicira sa metamodelom NOF-a), i koristi se kad se NOF deploy-uje na „ugrađen metamodel“ način.

• Aplikacije pisane u NOF-u takođe mogu komunicirati sa drugim sistemima kroz EJB (skraćenica od Enterprise Service Bus) uz pomoć poruka. Komunikacija je naravno dvosmerna.

• Malo više o REST Web servisima biće u odeljku 6.4, a o JPA perzistoru u odeljku 6.3.

77

Slika 17: Heksagonalna arhitektura NOF-a. Izvor: [Haywood 2009].

Modeldomena

Daljin

ski

Perzistencija

Serv

isiIn-m

emory

Aplik

ativn

i sloj

DnD pogled

RCP pogled

HTML pogled

Scimpi pogled

Wicket pogled

Framework zatestiranje:FitNesse

Headless(bezglav) pogled

RESTfulWeb servis

Korisnička strana

ESB (EnterpriseService Bus)

– dolazeći

In-memoryperzistor

Strana za podatke

XML perzistor

JPA perzistor

Implementacijaservisa

ESB - odlazeći

Na slici se može primetiti da je unutrašnji heksagon namerno podeljen na dva dela: na model domena i na aplikativni sloj, koji se zapravo podudaraju sa istoimenim slojevima unutar četvoro-slojne arhitekture (na slici se mogu identifikovati i preostala dva sloja). Kao što je već poznato, karakteristična osobina Naked Objects pristupa je pojednostavljivanje slojeva unutar višeslojnih arhitektura kroz korišćenje behavioralno-kompletnih objekata, omogućavajući da drugi, aplikativni sloj bude slobodan tj. bez poslovne logike i automatizovan (zato je na slici nacrtan tankim). Posledica ovoga je mogućnost da se i GUI (prvi, prezentacioni sloj) generiše automatski. Međutim, NOF, u odnosu na originalni obrazac, ide i korak dalje, jer automatizuje i četvrti, perzistentni sloj. NOF koristi bukvalno nevidljiv ORM mehanizam ukoliko se izabere in-memory ili XML perzistencija, a u slučaju da se koristi relaciona baza podataka, ORM naredbe se pišu pomoću Java anotacija nalik na EJB 3 ili Hibernate. [NO v4.0 User Guide 2009]

Treba još istaći da NOF zapravo ne forsira automatizaciju prethodno spomenutih slojeva. Po Haywood-u, NOF se može koristiti tj. deploy-ovati na četiri načina: [Haywood 2009]

• Čist POJO (eng. Pure POJO) – u ovom obliku, domenski sloj je razdvojen od NOF-a, a programeri moraju sami da kreiraju i implementiraju ostala tri sloja (prezentacioni, aplikativni i perzistentni). POJO objekti su u ovom slučaju „čisti“ (za razliku od preostala tri načina), jer ne implementiraju ili nasleđuju klase iz NOF-a, niti koriste anotacije. Ovaj način deployment-a se preporučuje kad se ne želi ili ne može koristiti NOF nakon neke tačke razvoja, ili kad se NOF koristi samo kao pomoćni alat za dizajniranje (slično kao i UML). Logično, ovaj način deployment-a je najmanje rizičan sa aspekta enterprise-a.

• Ugrađen metamodel (eng. Embedded Metamodel) – u ovom obliku, „uključuje se“ jedan deo aplikativnog sloja, prema tome, poslovna pravila se od sad procesiraju od strane NOF-a. Naravno, programeri moraju i dalje implementirati prezentacioni i perzistentni sloj, kao i deo aplikativnog sloja (koji se odnosi na komunikaciju sa ručno pravljenim GUI-jem). Ovaj način deployment-a se koristi u slučaju integrisanja sistema sa Web framework-ovima (kao što su Apache Wicket, Struts, JSF, Spring MVC, Tapestry, itd.).

• Prilagođen GUI (eng. Custom Presentation) – liči na prethodni način, sa jednom razlikom: od sad, NOF će raditi perzistenciju umesto programera, tj. i poslednji sloj se automatizuje. Naravno, u slučaju da se koristi relaciona baza podataka, programeri će još morati da podešavaju ORM i da pišu ORM naredbe.

• Full Runtime – konačno, kod ovog načina deployment-a se koristi kompletni NOF koji će raditi „prljavi“ posao u prezentacionom, aplikativnom i perzistentnom sloju umesto programera. Sa aspekta enterprise-a, ovaj način deployment-a je najviše rizičan.

Iz prethodnih izlaganja se može zaključiti, da se NOF može deploy-ovati, tj. da se koristi u tri okruženja: kao jedan korisnik (eng. Single User), kao Web aplikacija, i u klijent-server režimu. [Haywood 2009] Međutim, demonstrativna aplikacija će se koristiti samo u istraživačkom (eng. Exploration) režimu bez deployment-a, koji odgovara načinu razvoja u fazi istraživanja. NOF će se koristiti u Full Runtime-u.

78

5.3. EntitetiPredstavljanje Naked Objects verzije pubDB-a će početi sa opisivanjem entiteta.

Entiteti su duboko ukorenjeni u kompjuterski svet. Oni se spominju u programiranju, šta više, u DDD-u se smatraju obrascima. Međutim, entiteti su poznati i u svetu baza podataka, npr. u ER-modeliranju slovo „E“ zapravo označava entitet i predstavlja jedinicu posmatranja, a u relacionim bazama podataka su uglavnom smešteni u tabele.

Po Merriam-Webster Online rečniku, entitet (eng. Entity) označava „nezavisno, odvojeno ili zasebno postojanje ili biće“.78 Iako je ova definicija dosta apstraktna, poznato je da objektno-orijentisana paradigma omogućava modeliranje realnog sveta, omogućavajući da entiteti unutar ove paradigme budu vrlo konkretni, ako ne i opipljivi, iako je možda reč o apstraktnim, misaonim imenicama. Naime, objekti (baš kao i odgovarajući entiteti u realnom svetu) imaju svoj jedinstven identitet, koji razdvaja trenutno posmatran objekat od ostalih. U svetu baza podataka, identitet se predstavlja primarnim ključem, najčešće u obliku string-a ili broja. Međutim, sa aspekta objektno-orijentisane paradigme, identitet je nešto apstraktniji. U nekim situacijama, identitet entiteta se može prepoznati na osnovu njegovih obeležja, atributa, ali ovo ne mora da bude slučaj. Identitet entiteta je zapravo nešto što „traje“ kroz vreme. Najbolje je da se identitet shvati u smislu „stvarnog postojanja“. Npr. računar se može identifikovati navođenjem serijskog broja, ili nabrajanjem komponenata unutar kućišta. Međutim, prirodnije je ga identifikovati kao „moj kompjuter“, „kuhinjski kompjuter“, itd. U ovom slučaju, čak i ako se izmeni većina unutrašnjih komponenata računara (pa čak i samo kućište), računar će i dalje biti „moj“ ili „kuhinjski“. [Mehta 2008]

U DDD-u pojam entiteta predstavlja jedan od baznih obrazaca i spada u prvu grupu obrazaca. Eric Evans, koji ga naziva i kao referentni objekat (eng. Reference Object), definiše entitet kao „objekat koji se fundamentalno definiše ne na osnovu svojih atributa, nego na osnovu niti kontinuiteta (tj. neprekidnosti) i identiteta“. [Evans2003] Haywood na ovo još dodaje da je „entitet objekat čiji se identitet mora očuvati, prvenstveno zato što svoje stanje vremenom može promeniti“. Poslovni objekti koji se definišu uz pomoć domenskih eksperata su entiteti, ako ti eksperti mogu njima dodeliti identitet, i naravno ako je njima taj identitet važan sa aspekta domena. Naravno, mora se napomenuti da nisu svi objekti entiteti. [Haywood 2009]

5.3.1.Atributi entitetaU slučaju pubDB-a, može se reći da su svi tipovi entiteta u ER-dijagramu (Slika

10), odnosno sve klase u objektnom dijagramu (Slika 11) entiteti tj. referentni objekti. Tako će se na primer entitet Author (tj. Autor) predstaviti klasom Author.java, itd. Ova klasa bi u pojednostavljenom obliku izgledala na sledeći način:import org.nakedobjects.applib.AbstractDomainObject;public class Author extends AbstractDomainObject { // {{ LastName private String lastName; public String getLastName() {

78 Izvor: <http://www.merriam-webster.com/dictionary/entity>.

79

return lastName; }

public void setLastName(final String lastName) { this.lastName = lastName; } // }} // {{ FirstName private String firstName; public String getFirstName() { return firstName; }

public void setFirstName(final String firstName) { this.firstName = firstName; } // }}

// {{ Biography private String biography; public String getBiography() { return biography; }

public void setBiography(final String biography) { this.biography = biography; } // }}}

Kao što se može videti, entitet Author je jedan vrlo jednostavan POJO, koji ima tri atributa: prezime (lastName), ime (firstName) i biografiju (biography). ID autora se ne navodi kod in-memory i XML perzistora, jer se dodeljuje automatski. Svaki atribut se sastoji od samog polja, i od odgovarajućeg getter-a i setter-a.

Pažljivi čitaoci će sigurno primetiti da klasa Author nasleđuje klasu AbstractDomainObject (iz paketa org.nakedobjects.applib). Ova nadklasa je zapravo pomoćna i služi za jednostavnije pisanje entiteta. Naime, domenski objekti se u NOF-u nalaze unutar kontejnera pod nazivom DomainObjectContainer, koji obezbeđuje pristup NOF-ovom mehanizmu za perzistenciju i za GUI, a klasa AbstractDomainObject omogućava jednostavnije baratanje ovim kontejnerom unutar entiteta. Naravno, njeno nasleđivanje uopšte nije obavezno (ako razvojni tim koristi NOF u čistom POJO režimu, pogledati odeljak 5.2.2), ali će programeri u tom slučaju morati sami da pribave referencu na kontejner – ako ga žele koristiti. [Haywood 2009] Uzgred, izvorni kod u ovom jednostavnom obliku još ne koristi pogodnosti klase AbstractDomainObject.

Pomoću NOF-a, pisanje programa je još više pojednostavljeno uz pomoć Eclipse šablona (eng. Template). Oni se dobijaju u NOF paketu i moraju se ubaciti u Eclipse. Ubacivanje se vrši na sledeći način: Window → Preferences → Java → Editor → Templates → Import, a zatim treba naći template fajl unutar NOF paketa

80

(nakedobjects-4.0.0\resources\ide\eclipse\templates\nakedobjects-templates.xml). Za korišćenje šablona treba samo ukucati naziv šablona u izvornom koda, pritisnuti Ctrl+Space na tastaturi, izabrati šablon iz padajuće liste i pritisnuti Enter. Šablon će se izgenerisati unutar koda, a jedina obaveza programera je da konkretizuje promenljive sa stvarnim vrednostima. Tako se npr. novi atributi mogu dodati pomoću šablona nop (skraćenica od Naked Objects Property). NOF ima 43 osnovnih šablona. [Haywood 2009]

5.3.2.Definisanje poveznikaUporedivši klasu Author sa istoimenim tipom entiteta u ER-dijagramu se može

zaključiti da su atributi „na mestu“, ali je potrebno još realizovati i poveznik sa klasom Publication. Međutim, budući da je ova veza tipa više-prema-više, predstaviće se nešto ilustrativnija varijanta: veza tipa jedan-prema-više.

Neka se posmatra tip poveznika između tipova entiteta Article (tj. Članak) i Journal (tj. Časopis). Ova veza je tipa jedan-prema-više, budući da se jedan članak može objaviti u tačno jednom časopisu, dok se u jednom časopisu može objaviti više članka. Poveznici se u objektno-orijentisanim jezicima realizuju pomoću asocijacija, koje omogućuju da objekat neke klase ima referencu (jednu ili više) na objekat druge klase. Međutim, ako je posmatrana veza dvosmerna, asocijacija se mora navesti na oba kraja. Ni NOF nije izuzetak iz ovog pravila, ali je realizacija srećom nešto jednostavnija uz pomoć šablona.

Neka se prvo posmatra asocijacija kod Article-a. Jedan članak se može objaviti u tačno jednom časopisu, prema tome, ovde će se navesti skalarna asocijacija, tj. referenca na jedan časopis. Ovo je zapravo jedan atribut, pa se koristi nop šablon, samo se umesto primitivnog tipa navodi referencijalni tip (Journal). Međutim, posao još nije završen. Naime, ako se pretpostavi da je članak a1 povezan sa časopisom j1, časopis j1 ne mora biti povezan sa člankom a1, nego sa člankom a2. Drugim rečima, narušio se referencijalni integritet. Asocijacije uvek moraju biti u konzistentnom stanju, znači ako se kreira, modifikuje ili briše veza na jednom kraju, ta veza se mora ažurirati i na drugom kraju. Za postizanje ovog ponašanja, NOF koristi jedan obrazac pod nazivom uzajamna registracija (eng. Mutual Registration). Ideja iza ovog obrasca je da se mehanizam ažuriranja veze stavi samo na jedan kraj koji će biti odgovoran za ažuriranje oba kraja veze, a drugi kraj će samo delegirati ka suprotnom kraju. [Haywood 2009]

Ovaj obrazac se u NOF-u realizuje na sledeći način (sa strane klase Article): prvo se koristi nop šablon koji će napraviti asocijaciju, a ispod getter-a i setter-a se upiše nopmod šablon (skraćenica od Naked Objects Property Modify) koji će još dodati pomoćne metode ModifyXxx(…), clearXxx(), onModifyXxx(…) i onClearXxx(…), pri čemu je Xxx naziv klase sa druge strane veze (u ovom slučaju Journal)79. Konačno, izbrišu se metodi ModifyXxx(…) i clearXxx(), i ponovo se kreiraju ali sad uz pomoć šablona nop-m1. U slučaju klase Article.java, dobija se sledeća asocijacija:

79 Zapravo, ova četiri nova metoda, koji se kreiraju uz pomoć šablona nopmod, se dodeljuju svakom atributu unutar framework-a, ali ispod haube. Šablon nopmod samo ih čini vidljivim, pa se otključava mogućnost za njihovu modifikaciju (konkretno u ovom slučaju, za dodavanje uzajamne registracije obrasca). Uzgred, NOF će pozvati ove metode za modifikaciju i brisanje veze umesto setter-a. [Haywood 2009]

81

public class Article extends Publication { // nepotrebno izostavljeno

// {{ Journal private Journal journal; public Journal getJournal() { return journal; }

public void setJournal(final Journal journal) { this.journal = journal; }

public void modifyJournal(final Journal journal) { Journal currentJournal = getJournal(); // proveri da li je časopis ništavan ili je isti sa prethodnim // časopisom if (journal == null || journal.equals(currentJournal)) { return; // ako je odgovor da, izlazi iz metoda modify } // delegiraj ka roditelju gde će se praviti asocijacija journal.addToArticles(this); // dodatna poslovna logika onModifyJournal(currentJournal, journal); }

public void clearJournal() { Journal currentJournal = getJournal(); // proveri da li je članak uopšte povezan sa nekim časopisom if (currentJournal == null) { return; // ako je odgovor da, izlazi iz metoda clear } // delegiraj ka roditelju gde će se brisati asocijacija currentJournal.removeFromArticles(this); // dodatna poslovna logika onClearJournal(currentJournal); }

protected void onModifyJournal(final Journal oldJournal, final Journal newJournal) { }

protected void onClearJournal(final Journal oldJournal) { } // }}}

Kao što se može videti, mehanizam za ažuriranje veze se nalazi na drugom kraju veze, a ovde se vrši samo delegiranje ka tom kraju. Prema tome, ovaj kraj veze se može smatrati detetom, a drugi kraj roditeljem. Još treba isteći da zadnja dva metoda služe za dodavanje dodatne poslovne logike (ukoliko je to potrebno), ali su ovde prazni.80

80 Pažljivi čitaoci će primetiti da ova klasa nasleđuje klasu Publication (umesto AbstractDomainObject). Ako se baci pogled na ER-dijagram modela (Slika 10), biće jasno da je reč o IS_A hijerarhiji, koja se u objektno-orijentisanim jezicima realizuje pomoću nasleđivanja. Klasa Publication nasleđuje AbstractDomainObject, pa će svojstva preći i na klasu Article.

82

Neka se sad posmatra drugi (roditeljski) kraj veze, gde će se staviti mehanizam za ažuriranje oba kraja veze. To je klasa Journal. Jedan časopis može objaviti više članka, prema tome, umesto skalarnog atributa je potrebno staviti kolekciju, tj. vektorsku asocijaciju. Ovo se u NOF-u postiže pomoću dva šablona: nocl (skraćenica od Naked Objects Collection List) za dodavanje kolekcije tipa lista i nocs (skraćenica od Naked Objects Collection Set) za dodavanje kolekcije tipa skup. U ovom slučaju, koristio se šablon nocs, koji je dodao kolekciju sa odgovarajućim getter-om i setter-om. Za implementaciju uzajamne registracije obrasca potrebno je prvo pomoćne metode učiniti vidljivim uz pomoć nocmod šablona (skraćenica od Naked Objects Collection Modify), koji će ubaciti metode AddToXxx(…), RemoveFromXxx(…), onAddToXxx(…) i onRemoveFromXxx(…). NOF će ove metode pozvati za dodavanje i brisanje elemenata iz kolekcije umesto getter-a. Konačno, brišu se metodi AddToXxx(…) i RemoveFromXxx(…), i koristi se šablon noc-1m koji će ih re-implementirati uz poštovanje obrasca. Na ovaj način se dobija sledeća kolekcija u klasi Journal.java:public class Journal extends AbstractDomainObject { // nepotrebno izostavljeno

// {{ Articles private Set<Article> articles = new LinkedHashSet<Article>(); public Set<Article> getArticles() { return articles; }

public void setArticles(final Set<Article> articles) { this.articles = articles; } public void addToArticles(final Article article) { // proveri da li je članak ništavan ili je već objavljen u // časopisu (tj. nalazi se već u kolekciji) if (article == null || getArticles().contains(article)) { return; // ako je odgovor da, izlazi iz metoda addTo } // briši vezu sa starim roditeljem (časopisom), ako postoji article.clearJournal(); // poveži članak sa časopisom article.setJournal(this); // poveži časopis sa člankom (tj. stavi ga u kolekciju) getArticles().add(article); // dodatna poslovna logika onAddToArticles(article); }

public void removeFromArticles(final Article article) { // proveri da li je članak ništavan i da li je uopšte objavljen u // časopisu if (article == null || !getArticles().contains(article)) { return; // ako je odgovor da, izlazi iz metoda removeFrom } // briši vezu članak → časopis article.setJournal(null); // briši vezu časopis → članak (tj. briši ga iz kolekcije) getArticles().remove(article);

83

// dodatna poslovna logika onRemoveFromArticles(article); }

protected void onAddToArticles(final Article article) { }

protected void onRemoveFromArticles(final Article article) { } // }}}

Kao što se može videti, mehanizam za ažuriranje oba kraja veze nije uopšte komplikovan, a uz pomoć šablona je njegovo pisanje jednostavnije i štedi vreme.

Pisanje dvosmernih asocijacija kod ostalih tipova poveznika (jedan-prema-jedan i više-prema-više) je analogno. Kod tipa jedan-prema-jedan se koriste šabloni nop-11c (eng. Child, tj. za dete koje delegira ka roditelju) i nop-11p (eng. Parent, tj. za roditelja koji implementira mehanizam), a kod tipa više-prema-više se koriste šabloni noc-mmc (za dete) i noc-mmp (za roditelja). Kod ovih tipova veza je svejedno koji kraj veze će se izabrati za roditelja, dok je kod tipa jedan-prema-više fiksirano, i nalazi se na onom kraju gde se implementira kolekcija.

Do sad su bili predstavljeni oni delovi entiteta koji se odnose na stanje objekta, a sad je došlo vreme da se pokaže kako se implementira ponašanje objekta. Kao što je poznato, kod Naked Objects pristupa nije moguće da se poslovna logika stavlja u druge slojeve, nego samo u domenski sloj, štiteći model od rasipanja funkcionalnosti.

5.3.3.AnotacijeNajlakši način da se domenski objekti proširuju ponašanjem je uz pomoć

anotacija. Anotacije (eng. Annotations) se pišu na raznim mestima u zavisnosti od toga, na šta se odnose: na objekat, na član objekta (kao što su atributi, kolekcije i akcije81) ili na parametar akcije. Prema tome, anotacije se mogu staviti ispred deklaracije klase (ako se odnosi na celi objekat), ispred getter-a (za atribute i kolekcije), ispred deklaracije metoda (za akcije) i ispred deklaracije parametra unutar zagrade metoda (za parametar akcije). [NO v4.0 User Guide 2009]

NOF v4.0 u svom paketu ima 24 predefinisanih anotacija. U nastavku će se kratko opisati najvažnije od njih: [NO v4.0 User Guide 2009]

• @Named – NOF automatski generiše naziv objekata i njihovih članova na osnovu njihovih imena unutar klase i normalizuje ih po potrebi, npr. objekat tipa Author će se u GUI-ju pojaviti kao „Author“; atribut lastName će se pojaviti kao „Last Name“, itd. Međutim, nije uvek moguće dati željeni naziv, npr. u slučaju Java rezervisanih reči. Tada se koristi @Named anotacija, npr.:private String packageArg; // polje se ne sme nazvati kao // package (Java rezervisana reč),@Named("Package") // ali se lako rešava pomoću @Named public String getPackageArg() { return packageArg; }Takođe, NOF ne može saznati nazive parametara unutar akcija, pa je korišćenje

81 Akcije će se opisati u odeljku 5.3.4.

84

ove anotacije tamo neminovno. Međutim, preporučuje se da se ova anotacija koristi samo kad je to neophodno, prema tome, klasama i članovima uvek treba dati reprezentativna imena. Ovo je potrebno da se ne bi izgubio sveprisutni jezik.

• @DescribedAs – radi (i koristi se) na vrlo sličan način kao i @Named, sa jednom razlikom: koristi se za opisivanje koncepata (objekata, njihovih članova i parametara akcija). U GUI-ju se uglavnom predstavlja u obliku balončića.

• @MemberOrder – NOF podrazumeva da će redosled članova posmatranog objekta (atributi, kolekcije i akcije) u GUI-ju biti isti kao i njihov redosled unutar klase. Ako se to želi promeniti, može se koristiti @MemberOrder anotacija koja ima sledeću sintaksu:@MemberOrder(sequence = "<relativni redosled>")NOF za određivanje redosleda koristi stringovsko poređenje. Najlakše je navesti cele brojeve, ali se preporučuje korišćenje tzv. Dewey decimalnog formata82. Ova anotacija je posebno korisna kod nasleđivanja radi određivanja redosleda članova podklasa u odnosu na članove nadklase.

• @Optional – po default-u, svi atributi nekog objekta su obavezni, prema tome, kad korisnik želi napraviti novi objekat, NOF će zatražiti da se ispune sva njegova polja. Slično je i sa parametrima akcija – i oni su obavezni. Izuzeci iz ovog pravila se mogu napraviti pomoću @Optional anotacije, koja će prethodno obavezno polje pretvoriti u opciono.83 Ova anotacija se koristi bez parametara.

• @MultiLine – ova anotacija šalje signal NOF-u da je posmatran atribut objekta ili parametar akcije duži od ostalih, pa treba omogućiti da se piše u više redova, tj. u tekstualni okvir. Jasno je da ova anotacija ima smisla samo kod atributa i parametara tipa String. Anotacija ima sledeću sintaksu:@MultiLine([numberOfLines=<broj redova>], [preventWrapping=<false|true>])@MultiLine ima dva opciona parametra: numberOfLines označava broj redova unutar tekstualnog okvira, a preventWrapping isključuje prelamanje teksta (ukoliko je true). Podrazumevane vrednosti parametara (ukoliko se ne navode) su 6 i true, respektivno.

• @MaxLength – predstavlja maksimalan broj karaktera koji se mogu ukucati u tekstualno polje u GUI-ju. Koristi se samo kod atributa objekata i parametara akcija. Ima samo jedan celobrojni parametar: broj maksimalnih karaktera. Ukoliko se koristi perzistor u relacione baze podataka (poput JPA perzistora), preporučuje se navođenje ove anotacije za sve atribute.

• @RegEx – omogućava validaciju (i normalizaciju) atributa objekata i parametara akcija tokom unosa podataka, pomoću regularnih izraza (eng. Regular Expression). Uz ovu anotaciju se mogu otkloniti neki potencijalni izvori bagova, jer se onemogućava unos nedozvoljenih vrednosti za polja. Sintaksa je sledeća:

82 Zove se i „tačka-decimalni“ format i koristi se i za numeraciju poglavlja i odeljaka unutar knjiga. Omogućava ubacivanje beskonačnog broja elemenata, kao i jednostavno umetanje novih elemenata između dva postojeća elementa. Npr.: 1, 1.2, 1.2.1, 1.2.2, 1.3, 4.1.1.1, 4.1.1.2, 4.1.2, itd.

83 @Optional anotacija nema puno smisla kod kolekcija, pošto su sve kolekcije unapred inicijalizovane operatorom new (mada su prazne). Pogledati kako rade šabloni nocl i nocs.

85

@RegEx(validation = "<regularni izraz>", [format = "<regEx string>"], [caseSensitive = <false|true>])Prvi parametar (validation) je obavezan, i ovde se piše željeni regularni izraz, a ostali parametri su opcioni i služe za formatiranje teksta, kao i osetljivost za velika i mala slova, respektivno. Dva zadnja parametra se ne koriste u praksi, i njihove podrazumevane vrednosti su redom: prazan string i false.

• @MustSatisfy – omogućava ubrizgavanje specifikacija u entitete ili vrednosne tipove. Pogledati još odeljak 5.6.1.

• @Hidden – po default-u, svi članovi klase (atributi, kolekcije i akcije) su vidljivi korisniku sistema. Međutim, ovo nije uvek zgodno, i zato postoji anotacija @Hidden, koja efektno sakriva posmatranog člana od korisnika. Može se koristiti bez parametara, i u tom slučaju će član uvek biti sakriven. Međutim, može se odrediti i vreme sakrivanja. Ovo se postiže parametrom anotacije koji može imati četiri vrednosti: When.ALWAYS, When.NEVER, When.ONCE_PERSISTED i When.UNTIL_PERSISTED. Prva vrednosti uvek sakrije član, pa je ova funkcionalnost ista kao @Hidden bez parametra (zapravo, ova vrednost je podrazumevajuća). Druga vrednost nikad ne sakrije član, pa njegovo korišćenje nema puno smisla. Treća vrednost će sakriti član čim se objekat perzistuje. Konačno, četvrta vrednost će sakriti član sve dok objekat nije sačuvan.

• @Disabled – radi slično kao i anotacija @Hidden, ali umesto da sakrije član, @Disabled ga samo „isključuje“, tj. deaktivira. Ovakvi elementi u GUI-ju su vidljivi ali su prikazani sivom bojom: u slučaju atributa, ime atributa je ispisano sivom bojom, i tekstualno polje se ne može ispuniti, a u slučaju akcija korisnik ne može kliknuti na nju iz menija. Korišćenje ove anotacije je analogno korišćenju @Hidden: može se koristiti bez parametara (tada će član uvek biti deaktiviran), i sa parametrom (sa prethodno spomenute četiri vrednosti).

• @Exploration – ova anotacija (koja se inače koristi bez parametra) se koristi samo kod akcija, i markira posmatranu akciju kao „istraživačku“. Drugim rečima, ova akcija se koristi samo u fazi istraživanja, ali ne i u fazi isporuke. Prema tome, akcije markirane anotacijom @Exploration će biti dostupne samo ako se sistem izvršava u „exploration“ režimu.

• @Value – markira klasu kao vrednosnog tipa. Pogledati još odeljak 5.6.2.

Kao što se može videti, neke anotacije se odnose samo na GUI, neke druge utiču na način izvršavanja, a postoje i takve koje služe za validaciju i testiranje. Prethodno navedene anotacije predstavljaju samo mali skup u odnosu na kompletnu biblioteku anotacija, ali su dovoljne za pisanje jednostavnih aplikacija.

5.3.4.AkcijeAkcije su već bile spomenute par puta, prema tome, sad bi bila odlična prilika da

se i one predstave. Akcije (eng. Actions) su zapravo public metodi, i tehnički gledano, njima se definiše ponašanje objekata (dok se poljima, tj. atributima i kolekcijama, definiše stanje). Akcije su u GUI-ju uglavnom dostupne pomoću desnog klika na

86

objekat (mada zavisi i od korišćenog pogleda). NOF omogućava jednostavno kreiranje akcija pomoću šablona noa (skraćenica od Naked Objects Action). [Haywood 2009]

Neka se ponovo posmatra klasa Author.java. Ova klasa ima jednu akciju, deleteAuthor(…) koja briše trenutno posmatranog autora:public class Author extends AbstractDomainObject { // nepotrebno izostavljeno

// {{ deleteAuthor public void deleteAuthor( @Named("Also delete related publications (if any)") final boolean deletePublicationsToo) { // 1) Publication[] publicationsToDelete = getPublications().toArray( new Publication[0]); // 2a) if (deletePublicationsToo) { // 2b) for (Publication publication : publicationsToDelete) { if (publication instanceof Article) ((Article) publication).deleteArticle(); else ((Book) publication).deleteBook(); } } else { // 2c) for (Publication publication : publicationsToDelete) { removeFromPublications(publication); } }

remove(this); // 2d) } public boolean default0DeleteAuthor() { // 3) return true; } // }}}

Neke linije su u gore navedenom izvornom kodu zabeležene brojem. U nastavku sledi njihovo objašnjenje:

1) Kao što se može videti, sve akcije su public metodi. Iako ova klasa nema povratnu vrednost (void), to ne mora da bude slučaj. Akcija deleteAuthor(…) ima jedan parametar, i naziva se parametar akcije. Jedna akcija može imati više parametara, ali ne mora imati ni jedan. Kad korisnik u GUI-ju pozove akciju, pojaviće se mali prozor sa poljima gde se mogu ispuniti ovi parametri. [Haywood 2009] Uzgred, parametar u ovom slučaju (deletePublicationsToo) je logičkog tipa, i ako je true, sistem će pored samog autora izbrisati i sve publikacije (članke i knjige) koje su pisane od strane posmatranog autora. Takođe, može se primetiti da je parametar markiran sa @Named anotacijom. Kao što je rečeno, NOF ne može izvaditi imena parametara akcija, samo njihov tip. Prema tome, navođenje ove anotacije se preporučuje (inače će se parametar nazvati imenom njegovog tipa, u ovom slučaju, pojaviće se kao „Boolean“).

2) U ovom delu će se objasniti način funkcionisanja akcije:

87

a) Prvo se mora napraviti jedna identična kopija kolekcije publications, samo u obliku niza. Metod getPublications() je getter kolekcije publications, a parametar poziva toArray (new Publication[0]) će napraviti onoliko elemenata u nizu koliko ima elemenata u kolekciji. U nastavku ove akcije će se koristiti ovaj niz (publicationsToDelete) umesto kolekcije.84

b) Ako je korisnik odlučio da pored autora izbriše i publikacije pisane od strane ovog autora, izvršiće se prvi deo if grane: prvo će se proveriti da li je posmatrana publikacija članak ili knjiga, i pozvaće se odgovarajuća akcija za njihovo brisanje: deleteArticle() ili deleteBook(). Postupak se zatim ponavlja i za preostale publikacije pisane od strane posmatranog autora.

c) Inače, ako je korisnik odlučio da briše samo autora (a publikacije sačuva), izvršiće se else grana, koja zapravo briše samo veze između pomatranog autora i njegovih publikacija. Metod removeFromPublications(…) je zapravo metod za kolekciju publications, i implementira obrazac uzajamne registracije. Inače, veze između ova dva tipa entiteta se brišu i u prvom delu if grane (2b), samo je ta funkcionalnost implementirana u metodima deleteArticle() i deleteBook().

d) Konačno, budući da su veze među povezanim entitetima izbrisane, posmatrani autor se može i fizički izbrisati. Ovo se radi pomoću metoda remove(Object). Ovaj metod je zapravo nasleđen od strane već spomenute klase AbstractDomainObject.

3) Svaka akcija može imati i pomoćne metode, a metod default0DeleteAuthor() je jedan od njih. Ovim se definiše podrazumevana vrednost posmatranog parametra. Treba obratiti pažnju na deklaraciju metoda, jer ima unapred definisanu sintaksu:public <tip parametra> default<broj parametra><Naziv akcije>()Tip ovog metoda se mora poklapati sa tipom parametra na koji se odnosi. Redni broj parametra počinje od nule, pa se prvi parametar akcije označava sa 0, drugi sa 1, itd. Konačno, naziv ovog metoda se mora završiti sa nazivom akcije gde se nalazi posmatrani parametar, ali sa velikim početnim slovom. Uzgred, ovi pomoćni metodi se mogu napraviti i pomoću šablona noadef (skraćenica od Naked Objects Action Argument Defaults). Naravno, nisu default pomoćni metodi jedini koji se mogu dodati akcijama: postoji način i za njihovo sakrivanje, deaktiviranje, validaciju, itd., ali se oni neće navesti u ovom radu. [NO v4.0 User Guide 2009]

U sledećem odeljku će se opisati fabrike i repozitorije objekata

84 Razlog ovome leži u činjenici da nije moguće istovremeno i modifikovati kolekciju (npr. brisati njene elemente) i preći kroz njene elemente. Ako se primeti ovakvo ponašanje, Java će odmah generisati ConcurrentModificationException izuzetak. Prema tome, bolje rešenje je napraviti pomoćni niz koji ne pati od ovog problema, mada se mora priznati da performanse mogu pasti ukoliko kolekcija ima jako puno elemenata.

88

5.4. Fabrike i repozitorije (skladišta) objekataPrethodni odeljak je predstavio entitete: njihovo stanje (atributi i kolekcije) i

ponašanje (akcije i neke anotacije). Međutim, postavlja se pitanje, kako se ti objekti kreiraju i skladište. Jasno je, bez njih, korisnik bi pri pokretanju programa gledao prazan ekran. Da bi korisnik mogao pristupiti entitetima, potrebno je prvo napraviti njihovu fabriku i repozitoriju.

Obrazac pod nazivom fabrika (eng. Factory) je jedan od najpoznatijih obrazaca iz [Gamma et al. 1994]. Reč je o tzv. kreacionom obrascu (eng. Creational Pattern) i zasniva se na ideji da objekti ne bi smeli da se kreiraju na direktan način. Umesto toga, treba iskoristiti osobinu enkapsulacije. Jednostavno rečeno, ovaj obrazac služi za kreiranje objekata na kontrolisan način. Koristeći ovu tehniku u modelu domena, funkcionalnost kreiranja objekata se može razdvojiti od ostatka, i može se prilagoditi raznim potrebama. Ovaj obrazac se može lako zamisliti i u realnom svetu u vidu fabrika: npr. u fabrici automobila jedna pokretna traka je odgovorna za sklapanje nekog određenog modela automobila, šta više, moguće je praviti i razne varijacije tog modela, kao što su kola u različitim bojama, sa različitim motorima, sa tri ili pet vrata, i sa raznim dodacima (npr. klima uređaj). [Mehta 2008]

Ovaj obrazac je važan i kod Domain-Driven Design-a. Evans ga stavlja u prvu grupu obrazaca i definiše ga kao „mehanizam za enkapsulaciju kompleksne logike za stvaranje i za apstrahovanje tipa pravljenog objekta“. [Evans 2003]

Za razliku od fabrike koja služi za kreiranje objekata, obrazac repozitorija tj. skladište (eng. Repository) služi za njihovo skladištenje. Ovaj obrazac efektno razdvaja funkcionalnost perzistiranja objekata od ostatka modela, čime se postiže veća fleksibilnost. [Mehta 2008] Međutim, Evans daje obrascu nešto širu definiciju, i smatra da je „mehanizam za enkapsulaciju skladištenja, pronalaženja i pretraživanja objekata“. Ovaj obrazac se takođe nalazi u prvoj grupi obrazaca DDD-a. [Evans 2003]

Autori NOF-a su ukombinovali ova dva obrasca i tako je nastala klasa za fabriku i repozitoriju (eng. Factory and Repository Class), koja služi za kreiranje i skladištenje novih objekata kao i za pronalaženje i pretraživanje već postojećih. Ove klase će korisnici prvo primetiti pri startovanju aplikacije. [Haywood 2009]

Klase za fabriku i repozitoriju se u NOF-u prave na sledeći način. Prvo se pravi uobičajena Java klasa (preporučuje se da se pri imenovanju klase koristi sufiks Repository), ali umesto da nasleđuje klasu AbstractDomainObject, ona će naslediti klasu AbstractFactoryAndRepository iz paketa org.nakedobjects.applib. Ova nadklasa je takođe pomoćna, i omogućava jednostavnije pisanje klasa za fabriku i repozitoriju. Slično kao i kod prethodne pomoćne klase, ona obezbeđuje jednostavniju komunikaciju sa kontejnerom, ali sadrži pomoćne metode koje su više prilagođene klasama za fabriku i repozitoriju nego entitetima. Naravno, njeno nasleđivanje nije obavezno, ali se preporučuje. [Haywood 2009]

Sledeće parče izvornog koda prikazuje jednu ovakvu klasu. Klasa AuthorRepository.java služi za kreiranje, pronalaženje i pretraživanje autora.import org.nakedobjects.applib.AbstractFactoryAndRepository;import org.nakedobjects.applib.Filter;// još neki drugi import-i

89

@Named("Authors")@DescribedAs("Add a new Author to the database or view existing ones.")public class AuthorRepository extends AbstractFactoryAndRepository { // nepotrebno izostavljeno

// {{ Kreiraj novog (ali još uvek prelaznog) Autora @MemberOrder(sequence = "1") public Author newAuthor() { Author author = newTransientInstance(Author.class); return author; } // }} // {{ pretraži sve Autore @Exploration @MemberOrder(sequence = "2") public List<Author> allAuthors() { return allInstances(Author.class); } // }}

// {{ pretraži Autora po imenu @MemberOrder(sequence = "3") public List<Author> searchByName(@Named("Name") final String name) { return allMatches(Author.class, new Filter<Author>() { public boolean accept(final Author author) { return author.getLastName().concat(author.getFirstName()) .toLowerCase().contains(name.toLowerCase()); }

}); } // }}}

Kao što se može videti, klasa ima tri akcije, tj. metoda. Prvi metod, newAuthor(), služi za kreiranje novih autora. Metodi za kreiranje objekata se prave pomoću šablona noft (skraćenica od Naked Objects Factory-Transient). Poenta celog metoda se nalazi u pozivu newTransientInstance(Object.class) iz nadklase AbstractFactoryAndRepository. Ovaj metod vraća objekat koji još nije perzistovan, tj. objekat koji se još mora ubaciti u skladište. Ovi objekti su poznati kao prelazni (eng. Transient) objekti. [Haywood 2009] U GUI-ju se ovo prikazuje kao novi prozor gde se mogu ispuniti potrebna polja za novi objekat, a kad korisnik pritisne dugme Save, objekat se snimi u skladište.

Drugi metod, allAuthors(), pretražuje i vraća sve postojeće autore iz skladišta, i predstavlja najjednostavniji način pretraživanja. Za kreiranje ovog metoda se koristi šablon nosa (skraćenica od Naked Objects Search for All). Poziv metoda allInstances(Object.class) iz nadklase vraća sve postojeće instance navedenog tipa. Pošto je pretraživanje i vraćanje svih entiteta skupa, preporučuje se navođenje @Exploration anotacije radi ograničavanja vidljivosti metoda samo u fazi istraživanja.

90

[Haywood 2009]

Konačno, treći metod, searchByName(…), predstavlja specijalizovan način pretrage, i to po imenu autora (prosleđeno kao parametar). Za razliku od prethodnog metoda, ovaj metod poziva allMatches(Object.class, Filter<Object>) iz nadklase, koji ne vraća sve instance određenog tipa, nego samo one koje zadovoljavaju određene kriterijume. Ovi kriterijumi se definišu u interfejsu Filter<T> iz NOF-ove biblioteke org.nakedobjects.applib, pri čemu je T tip objekta.85 Ovaj interfejs ima jedan metod, accept(T) koji se mora uvek naknadno implementirati, i vraća logičku vrednost u zavisnosti od toga, da li trenutno procesirana instanca zadovoljava zadat kriterijum. Prema tome, kriterijum se piše upravo u ovaj metod. Pošto se interfejs mora implementirati, to se radi unutar anonimne klase. Što se tiče samog kriterijuma, on je jednostavan: prvo se radi konkatenacija prezimena i imena autora, koja se zatim pretvara u mala slova, i konačno, dobijen string se upoređuje sa string-om ukucanim od strane korisnika (koji se takođe pretvara u mala slova).

Međutim, kreiranje klasa za fabriku i repozitoriju je samo prvi korak. Potrebno je ove klase registrovati i sa framework-om. Za ovu svrhu treba editovati konfiguracioni fajl pod nazivom nakedobjects.properties o kome će više reči biti u odeljku 6.1.2.

5.5. FikstureKao što je poznato, podrazumevan perzistor u NOF-u je in-memory skladište

podataka koje čuva podatke u radnoj memoriji – sve dok se aplikacija izvršava, a kad se ona zatvori, podaci se brišu iz memorije. Ovaj perzistor zapravo služi za rapidnu izradu prototipova – ne zahteva konfigurisanje, a ORM je potpuno nevidljiv. Međutim, ovo ne mora da znači da će se aplikacija uvek izvršiti sa praznim početnim skladištem. Za ovu svrhu, izmišljene su fiksture.

Fikstura (eng. Fixture) u suštini predstavlja neko svojstvo kojim se podešava aplikacija pri startovanju iste radi demonstracije nekog scenarija. Najkorisnija namena fikstura je da se pohranjuje skladište sa nekim inicijalnim podacima pre startovanja programa. Ovi podaci su tzv. hard-kodirani tj. fiksno kodirani u izvornom kodu, ali su razdvojeni od ostatka funkcionalnosti, i pišu se relativno lako. Takođe, pomoću fikstura, mogu se odrediti i neka druga svojstva aplikacije, kao što su datum i vreme izvršavanja (može se simulirati da se sistem izvršava u prošlosti ili u budućnosti), a mogu se simulirati i sesije različitih korisnika sa različitim privilegijama. [Haywood 2009] Međutim, u ovom radu će se predstaviti fiksture samo kao način pohranjivanja skladišta sa podacima.

U NOF-u su fiksture zapravo jednostavne klase, a preporučuje se da se ime klase

85 Pored prethodno spomenuta dva načina pretraživanja NOF definiše još dva: firstMatch(Object.class, Filter<Object>) i uniqueMatch(Object.class, Filter<Object>): firstMatch(…) vraća prvu nađenu instancu iz skladišta koja zadovoljava prosleđene kriterijume, a uniqueMatch(…) vraća jedinu nađenu instancu. Razlika između njih je u tome da ako uniqueMatch(…) primeti da postoji više instanci koje zadovoljavaju kriterijume, generisaće izuzetak. Inače, ako nijedna instanca ne zadovoljava kriterijume, vraća se vrednost null.Vredi pomenuti da su sva četiri načina pretraživanja overload-ovana, tj. oni postoje i sa drugim parametrima. Tako npr. postoji i varijanta sa parametrom tipa Query (takođe iz NOF-ove biblioteke). Na taj način se mogu proslediti i upiti. Naravno, sve ovo zavisi od korišćenog perzistora, tako npr. in-memory i XML perzistor razumeju samo Filter (dok Query ne).

91

završava sa sufiksom Fixture. NOF nudi jednu pomoćnu nadklasu i za fiksture, a to je AbstractFixture (iz paketa org.nakedobjects.applib.fixtures). Slično kao i kod prethodnih slučajeva, ova nadklasa omogućava jednostavnije pisanje fikstura kao i povezivanje sa kontejnerom. [Haywood 2009]

Za demonstraciju pisanja fikstura prikazaće se fikstura za kreiranje autora. Iako se jednostavne fiksture mogu napisati u jednoj klasi, kod komplikovanih (kad se želi kreirati više objekta istog tipa) se preporučuje da se napravi jedna apstraktna klasa za način kreiranja objekata (u ovom slučaju, Autora), i određen broj drugih koje će naslediti prethodnu i u kojima će biti navedeni podaci objekta (po načinu jedna klasa po konkretnom objektu). Neka se prvo posmatra klasa AbstractAuthorFixture.java:import org.nakedobjects.applib.fixtures.AbstractFixture;public abstract class AbstractAuthorFixture extends AbstractFixture { public abstract void install(); protected Author createAuthor(String lastName, String firstName, String biography) { Author author = newTransientInstance(Author.class); author.setLastName(lastName); author.setFirstName(firstName); author.setBiography(biography); persist(author); return author; }}

Prvo što se primećuje je apstraktni metod install(). Ovaj metod se nasleđuje iz pomoćne nadklase i ovde bi trebalo da se pišu konkretni podaci za kreiranje objekta. Međutim, metod je proglašen kao apstraktni (pa i cela klasa), i biće konkretizovan u podklasi.

Kao što je rečeno, namena ove klase bi trebala da bude definisanje načina kreiranja objekata. Ova funkcionalnost se realizuje u metodu createAuthor(…). Prvo se kreira prelazni objekat (kao i u klasi AuthorRepository, pogledati odeljak 5.4). Zatim se postave vrednosti atributa klase Author (prezime, ime i biografija) pomoću setter-a. Kad su atributi postavljeni, poziva se metod persist(Object) iz pomoćne nadklase, koji perzistuje objekat u skladištu objekata. Uzgred, ovakvi metodi se mogu jednostavnije napraviti uz pomoć šablona nofp (skraćenica od Naked Objects Factory-Persistent).

Neka se sad posmatra jedna od klasa koja nasleđuje prethodno spomenutu klasu. Ova klasa se zove DanHaywoodAuthorFixture.java, i kao što se može naslutiti, predstavlja fiksturu za kreiranje autora Dan Haywood-a:public class DanHaywoodAuthorFixture extends AbstractAuthorFixture { @Override public void install() { String bioDHaywood = "Dan Haywood has …"; // ostatak biografije createAuthor("Haywood", "Dan", bioDHaywood); }}

Ova klasa je jednostavna: samo implementira metod install() koji je u

92

prethodnoj klasi još bio apstraktan. U ovom metodu se navode (preciznije, hard-kodiraju) podaci Dan Haywood-a, kao što su njegovo prezime, ime i biografija, i sve to se šalje metodu createAuthor(…) koji je definisan u nadklasi, i koji zna, šta dalje raditi sa ovim podacima.

Međutim, poznato je da pubDB ima i druge domenske objekte, kao što su kategorije, izdavači, publikacije, itd., a kreiranje fikstura za sve ove entitete već zahteva veću pažnju. Zato su autori NOF-a implementirali mogućnost hijerarhizacije fikstura koja omogućava njihovu bolju organizaciju. Čak postoji za ovu svrhu i poseban metod iz pomoćne nadklase: addFixture(…). [Haywood 2009]

Hijerarhija se pravi tako da ona ima jedan koren na koji se vezuju ostali čvorovi, pri čemu jedna hijerarhija predstavlja jedan scenario. Ovde će se hijerarhija prikazati u obrnutom redosledu: od lista ka korenu. Klase DanHaywoodAuthorFixture i AbstractAuthorFixture su već prikazane. Sledeća po redu je klasa AuthorSetupFixture.java:public class AuthorSetupFixture extends AbstractFixture { public AuthorSetupFixture() { addFixture(new DanHaywoodAuthorFixture()); addFixture(new AlanWBrownAuthorFixture()); addFixture(new KeithShortAuthorFixture()); // itd... }}

Ova klasa grupiše u svom konstruktoru sve autore koji su relevantni za posmatran scenario pomoću addFixture(Object). Sledeća klasa po redu je AuthorsAndPublicationsSetupTransactionalFixture.java:public class AuthorsAndPublicationsSetupTransactionalFixture extends AbstractFixture {

public AuthorsAndPublicationsSetupTransactionalFixture() { addFixture(new CategorySetupFixture()); addFixture(new AuthorSetupFixture()); addFixture(new JournalSetupFixture()); addFixture(new PublisherSetupFixture()); addFixture(new PublicationSetupFixture()); }}

Kao što se može videti, ova klasa već grupiše tipove entiteta: kategorije, autore, časopise, izdavače i publikacije (koja obuhvata članke i knjige).86 Konačno, definiše se

86 Prethodno su bile predstavljene samo fiksture vezane za autore, ali se i druge fiksture definišu na analogni način. Jedino što treba napomenuti je da fikstura za kreiranje publikacija (tj. članka i knjiga), PublicationSetupFixture, ima i metode za pretraživanje. Neki entiteti, kao što su autori, kategorije, itd., se mogu kreirati „izolovano“, tj. bez potrebe da se vežu sa drugim tipovima entiteta pomoću poveznika. Međutim, jednom će doći trenutak da se svi entiteti povežu. Ovaj „poslednji“ korak se nalazi kod publikacija, gde se konkretni članci i knjige povezuju sa odgovarajućim autorima, kategorijama, itd. Za postavljanje ovih fikstura je dakle potrebno pretražiti već perzistovane entitete. Zato i pomoćna nadklasa AbstractFixture omogućava pozivanje metoda za pretraživanje (allInstances(…), allMatches(…), itd.).Sad je već jasno, da pri pravljenju hijerarhija treba obratiti pažnju na redosled pravljenja fikstura. Ako se neki entitet mora povezati sa drugim tipom entiteta, taj drugi entitet mora da postoji pre nego što se poveže sa prvim.

93

koren hijerarhije pod nazivom AuthorsAndPublicationsSetupFixture.java:public class AuthorsAndPublicationsSetupFixture extends AbstractFixture { public AuthorsAndPublicationsSetupFixture() { addFixture(new AuthorsAndPublicationsSetupTransactionalFixture()); }}

Slično kao i kod klasa za fabriku i repozitoriju, i fiksture se moraju prvo registrovati sa framework-om unutar fajla nakedobjects.properties (koji će se predstaviti u odeljku 6.1.2) i to svaka klasa posebno. Međutim, ovde dolazi do izražaja još jedne pogodnosti hijerarhizacije fikstura. Pošto je hijerarhija jedna povezana struktura, u ovom slučaju će biti dovoljno da se registruje samo jedna klasa: koren.

5.6. Još neki koncepti Naked Objects framework-aU ovom odeljku će još nakratko biti opisani neki koncepti NOF-a (koji su

direktno preuzeti iz Domain-Driven Design-a). Oni nisu korišćeni pri izradi pubDB-a (sem nekih servisa), pošto je model ove aplikacije suviše mali da bi korišćenje ovih koncepata imalo pozitivni efekat. Takođe, ideja pri izradi Naked Objects verzije je bila da njegov model što više liči na model četvoro-slojne verzije pubDB-a.

5.6.1.SpecifikacijeSpecifikacija (eng. Specification) označava obrazac kojim se predstavlja

„poslovno pravilo koje se ne može jasno staviti pod odgovornost nekog entiteta ili vrednosnog tipa“. [Haywood 2009] Kao što još Evans kaže, „specifikacija je predikat koji određuje da li neki objekat zadovoljava neke kriterijume, ili ne“ i stavlja je u drugu grupu obrazaca. [Evans 2003] Znači, najvažnija namena specifikacije je validacija.

Za demonstraciju ovog koncepta Haywood navodi primer registarskih tablica tj. brojeva kod vozila, koje su uglavnom predstavljene nizom karaktera unutar entiteta Vozilo. Ako se pretpostavi da postoje neka pravila pri generisanju ovih brojeva, npr. da u nekoj državi tablica mora da ima tačno 10 karaktera, pri čemu su prva dva uvek slova, i osmi znak je povlaka, onda se ovo pravilo mora negde definisati. Međutim, definisanje ovog pravila u suštini nije odgovornost vozila. Takođe, ako se pretpostavi da će pravljena aplikacija imati neku akciju koja zahteva upisivanje ovog broja, onda to znači da će pravilo biti definisano na više mesta. Šta više, ako su pravila drugačija u susednim državama, ovo će još iskomplikovati njihovu definiciju. Zato je dobro da se pravilo definiše kao specifikacija: u posebnoj klasi, samo jedanput. [Haywood 2009]

Specifikacije se u NOF-u definišu dosta jednostavno. Prvo se kreira klasa (preporučuje se da ime klase ima sufiks Specification), koja će naslediti AbstractSpecification<T> (još jedna pomoćna nadklasa iz NOF-a), pri čemu je T tip objekta koji koristi ovu specifikaciju. Poslovna pravila specifikacije se pišu unutar metoda satisfiesSafely(…). Na kraju, kreiranu specifikaciju treba ubrizgati u entitete, što se postiže navođenjem anotacije @MustSatisfy(Object.class) ispred atributa.

94

5.6.2.Vrednosni tipoviNeka se posmatra prethodni primer sa registarskim tablicama. Poslovno pravilo

koje važi kod njih ne spada u odgovornost entiteta Vozilo. Međutim, ako se razmisli na trenutak, moglo bi se reći da u suštini ni celi koncept registarskih tablica ne spada baš unutar entiteta Vozilo, prema tome, možda bi bilo bolje razdvojiti ova dva koncepta. Međutim, problem je u tome da koncept RegistarskiBroj nije baš entitet – on nema svoj identitet. On je zapravo vrednosni tip (eng. Value Type), ili kako ga Evans zove, vrednosni objekat (eng. Value Object).

Inače, celi koncept polazi iz ideje da se svi entiteti sastoje od članova kao što su atributi. Ovi članovi su uglavnom primitivnog tipa: celobrojni (int), znakovni (char, String), logički (boolean), itd. Problem je u tome da su neki članovi ovih entiteta više od primitivnih tipova – oni mogu imati poslovna pravila, pa čak i posebnu funkcionalnost. Zbog ovoga je bolje da postoji posebna klasa RegistarskiBroj umesto jednog atributa tipa String unutar entiteta Vozilo. Na taj način, registarski broj će u entitetu Vozilo biti tipa RegistarskiBroj. Ova nova klasa neće biti entitet – biće vrednosni tip. Evans ga definiše kao obrazac iz prve grupe DDD-a, i smatra ga objektom koji „opisuje neke karakteristike ili atribute, ali koji nema koncept identiteta“. [Evans 2003] Drugim rečima, oni su zanimljivi ne zbog njihovog identiteta, nego zbog vrednosti koje predstavljaju. [Haywood 2009] Mehta ističe da se vrednosni objekti mogu zamisliti i kao „paraziti“ modela – nema puno smisla da postoje bez vezivanja za neke entitete (slično kao i kod slabog tipa entiteta u ER-modelu). [Mehta2008]

Definisanje vrednosnog tipa u NOF-u već nije tako trivijalan poduhvat (u odnosu na prethodne koncepte), ali nije ni tako komplikovan. Ova kompleksnost najverovatnije potiče iz striktne politike definisanja: oni bi trebali da budu nepromenjivi, uporedivi po vrednosti (ne po identitetu), serijalizabilni, i po algebri moraju imati zatvoren skup operacija. Za kreiranje vrednosnog tipa u NOF-u se prvo mora napraviti klasa koja će implementirati klasu Serializable (a po potrebi treba implementirati i metode equals(…), hashCode() i toString()), i neće imati setter-e. Da bi NOF mogao da tretira ovu klasu kao klasu vrednosnog tipa, koristi se @Value anotacija ispred deklaracije klase, u kojoj se kao parametar navodi naziv te klase u kojoj je definisana semantika ovog vrednosnog tipa. Ova klasa se mora definisati posebno, i preporučuje se da njen naziv ima sufiks ValueSemanticsProvider. NOF nudi posebnu pomoćnu nadklasu i za ovaj slučaj: AbstractSemanticsProvider<T>, gde je T tip vrednosnog tipa.

5.6.3.ServisiU modelu se često mogu naći delovi funkcionalnosti (akcije i druge aktivnosti)

koji ne pripadaju prirodno ni entitetima ni vrednosnim tipovima, naročito kad ovo ponašanje nema svoje stanje. Ova funkcionalnost bi se mogla izdvojiti da postoji zasebno od ostatka. Ovako su nastali servisi (eng. Services), koji su danas vrlo popularni (nalaze se u prvoj grupi obrazaca DDD-a), zato je potrebna njihova klasifikacija. Po Haywood-u, oni se dele na: domenske (vezuju se za posmatrani model domena), infrastrukturne (nalaze se ispod modela i strogo su tehničke prirode) i aplikativne (nalaze se iznad modela i kontrolišu model domena po potrebi). Domenski servisi su već bili korišćeni u pubDB-u u obliku fabrika i repozitorija (i zaista,

95

razdvojeni su od ostatka funkcionalnosti). Infrastrukturni servisi mogu biti: servis za slanje email-ova, servis za računanje vremena, itd. Aplikativni servisi su zapravo NOF-ovi servisi koji se nalaze u aplikativnom sloju, i mogu se isključiti po potrebi. [Haywood 2009]

Domenski i infrastrukturni servisi se u NOF-u prave na sledeći način. Prvo se napravi klasa koja će naslediti pomoćnu nadklasu AbstractFactoryAndRepository (ukoliko se pravi klasa za fabriku i repozitoriju) ili AbstractService (inače). Naravno, ako se ne želi da se servis pojavi u GUI-ju, klasu treba označiti @Hidden anotacijom. Unutar klase sve akcije (koje bi bile raspoložive ostalim delovima modela) moraju biti označene kao javne (public). Konačno, klasa servisa se mora registrovati unutar nakedobjects.properties fajla.

S ovim je generalno predstavljanje Naked Objects framework-a završeno. U sledećem poglavlju će se vršiti upoređivanje dve razvijene verzije demonstracionog primera.

96

6. Razvoj ilustrativnih aplikacija i njihovo međusobno poređenje

U poglavlju 4 je generalno opisan demonstracioni primer pod nazivom pubDB. Ovaj primer se implementirao na dva načina: na klasični višeslojni i na Naked Objects način. Cilj ovog poglavlja je upoređivanje ove dve verzije pubDB-a na razne načine: prvo će se predstaviti njihova globalna struktura, zatim će se uporediti njihov korisnički interfejs, i konačno, uporediće se i njihova unutrašnja implementacija. Poglavlje će se završiti sumiranjem prednosti i mana Naked Objects framework-a.

6.1. Višeslojne arhitekture (četvrti put) – struktura pubDB-aU ovom odeljku će se predstaviti globalna struktura pubDB-a iz ptičje

perspektive.

6.1.1.Struktura EJB 3 verzije pubDB-aPrvo će se opisati struktura EJB 3 verzije pubDB-a, koja je rađena po klasičnoj

četvoro-slojnoj arhitekturi. Predstavljanje će se vršiti na način dole-prema-gore, tj. od sloja podataka do prezentacionog sloja.

Što se tiče sloja podataka, on je realizovan u vidu relacione baze podataka. Za potrebe ovog sloja se koristio MySQL, koji nije zahtevao programiranje, samo konfigurisanje: kreiranje korisnika (sa korisničkim imenom i lozinkom), kreiranje šeme,

97

Slika 18: Struktura EJB 3 verzije pubDB-a: dijagram klasa trećeg, perzistentnog sloja

itd. Konfigurisanje se radilo u MySQL Workbench-u.

Svi ostali slojevi arhitekture su, međutim, pravljeni u Javi unutar Eclipse IDE. Unutar Eclipse-a se pravio enterprise projekat (Enterprise Application, tj. EAR87) sa JBoss v5.0 kao aplikativnim serverom, koji je bio zadužen za komunikaciju sa slojem podataka.

Za kreiranje trećeg, perzistentnog sloja se kreirao tzv. JPA projekat88, koji se zatim ubacio u EAR. Ovaj sloj ima samo jedan paket, persistence, koji čuva EJB entitete89. Kao što se može videti na dijagramu klasa (Slika 18), paket ima sedam klasa tj. entiteta, koje odgovaraju tipovima entiteta unutar ER-modela (Slika 10). Zapravo, ovaj dijagram klasa je identičan objektnom dijagramu (Slika 11), budući da su oba

87 EAR služi za međusobno povezivanje J2EE modula (uključujući EJB module).88 JPA (skraćenica od Java Persistence API) je zaslužna za perzistenciju podataka u baze podataka u

Java EJB svetu. JPA je zapravo jedan Java framework za upravljanje relacionim podacima u aplikacijama. Slično kao i kod drugih tehnologija, za postizanje ove funkcionalnosti JPA koristi ORM, koji pretvara podatke iz objektno-orijentisane paradigme (u ovom slučaju iz Jave) u relacionu paradigmu, i obrnuto. [Panda, Rahman & Lane 2007]

89 U EJB 3, postoje tri vrste komponenata, tzv. bean-ova (u prevodu, „zrna“): session bean-ovi, message-driven bean-ovi i entiteti. Session bean-ovi su pozvani od strane korisnika sistema radi izvršavanja raznih naredbi, a message-driven bean-ovi su aktivirani pomoću poruka (a ne od strane korisnika). Obe vrste bean-ova žive u drugom, aplikativnom sloju, i predstavljaju srž poslovne logike. Entiteti su u suštini Java objekti koji se perzistuju u bazu podataka pomoću JPA, i žive u trećem, perzistentnom sloju. Oni su se dosta promenili u odnosu na EJB 2, i zato su izgubili sufiks „bean“. U EJB 3, sve tri vrste komponenata su predstavljene u POJO obliku. [Panda, Rahman &Lane 2007] Uzgred, EJB 3 entiteti imaju slično značenje kao i entiteti u DDD-u i NOF-u.

98

Slika 19: Struktura EJB 3 verzije pubDB-a: dijagram klasa drugog, aplikativnog sloja, tj. sloja poslovne logike

dijagrama objektno-orijentisana. U svakoj klasi se nalaze ORM naredbe za mapiranje objekata u entitete unutar relacionih baza podataka.

Što se tiče drugog, aplikativnog sloja, on se smatra srcem poslovnog sistema kod četvoro-slojnih arhitektura. Naime, tu se nalazi srž poslovne logike, a takođe kontroliše i tok podataka: prima i izvršava korisničke naredbe i sakuplja podatke od strane korisnika, šaljući ih dole ka trećem sloju; a s druge strane, vraća vrednosti izvršavanja nazad ka korisniku. Za kreiranje drugog sloja unutar Eclipse-a, potrebno je kreirati tzv. EJB projekat, koji se takođe mora ubaciti u EAR. I ovaj sloj ima samo jedan paket, buslogic, u kojem su smešteni session bean-ovi. Kao što se može videti na dijagramu klasa (Slika 19), paket ima pet klasa, i svaka od njih upravlja sa po jednim tipom entiteta: autorom, kategorijom, časopisom, izdavačem i publikacijom (tj. člankom i knjigom). Unutar svake klase se nalaze metodi poslovne logike koji se odnose na posmatran entitet, kao što su dodavanje, brisanje ili pretraživanje. U EJB 3, session bean-ovi moraju imati i bar jedan poslovni interfejs od ponuđenih tri: lokalni, daljinski i Web-servis. Kao što se može videti na dijagramu, u slučaju pubDB-a su se koristila dva interfejsa za svaki session bean (lokalni i daljinski), ali se koristio samo daljinski, dok je lokalni bio naveden samo radi kompletnosti.

Konačno, prvi, prezentacioni sloj stoji na samom vrhu arhitekture, i generiše GUI cele aplikacije. Pošto EJB nije prezentaciona tehnologija, ovaj sloj se mora praviti uz pomoć neke druge tehnologije, kao što su Java Swing, JSP, itd. (u slučaju pubDB-a, koristio se Java J2SE Swing). Prema tome, u Eclipse-u je dovoljno praviti jednostavan

99

Slika 20: Struktura EJB 3 verzije pubDB-a: dijagram klasa prvog, prezentacionog sloja

Java projekat. Ovaj sloj ima dva paketa: gui i agency.90 Paket gui sadrži Swing grafičke komponente, kao što su prozori i dijalozi. Međutim, ovaj paket je pravljen tako da ne koristi ništa iz aplikativnog sloja, drugim rečima, on je skroz razdvojen od EJB bean-ova. Komunikacija između GUI-ja i drugog sloja se zapravo vrši pomoću drugog paketa (agency). Ovaj paket igra funkcionalnost „treće strane“, tj. ima ulogu agencije, medijatora. Ova odluka u dizajnu je bila doneta radi pojednostavljenja GUI-ja i radi razdvajanja od aplikativnog sloja, povećavajući fleksibilnost.

Kao što se može videti na dijagramu klasa (Slika 20), paket gui ima jednu klasu sa sufiksom Window, i puno drugih sa sufiksom Dialog. Glavna klasa ovog paketa (kao i celog sloja) je MainWindow.java, budući da ima main metod, i očekuje se da se aplikacija startuje iz ove klase. Dijalozi se pozivaju iz ove klase ili iz drugih dijaloga, 91 i njima su predstavljeni dijalozi za autore, kategorije, itd., a dijalog SearchDialog implementira dijalog za pretraživanje već sačuvanih entiteta. S druge strane, paket agency se sastoji od samog medijatora (Agent.java) i od pet pomoćnih klasa sa sufiksom Session. U klasi Agent su grupisani pozivi ka aplikativnom sloju, kao što su kreiranje, brisanje, itd., a usput koristi i prethodno spomenute pomoćne klase sa sufiksom Session radi pribavljanja referenci na bean-ove (koji se nalaze u drugom sloju, tj. u J2EE okruženju) iz J2SE okruženja.

6.1.2.Struktura Naked Objects verzije pubDB-aŠto se tiče Naked Objects verzije pubDB-a, jasno je da ona neće imati slojeve:

sve što će programeri videti unutar Eclipse-a je zapravo samo jedan sloj – domenski. Međutim, iako je NOF bliži heksagonalnoj arhitekturi, može se zamisliti i u obliku četvoro-slojne arhitekture, pri čemu su prezentacioni i aplikativni slojevi automatizovani, a u slučaju da se koristi in-memory ili XML perzistor, čak i sloj podataka.

Kreiranje NOF projekata je olakšano uz pomoć alata za automatizaciju procesa pravljenja softverskih build-ova. NOF podržava dva ovakva alata: Apache Ant i Apache Maven92, pri čemu se za izradu Naked Objects verzije pubDB-a koristio Maven.93 Pomoću Maven-a, kreiranje praznog Naked Objects projekta je jednostavno. Prvo treba u Eclipse-u otvoriti čarobnjaka za kreiranje novih Maven projekata: File → New → Other, a zatim iz liste čarobnjaka izabrati Maven → Maven Project. Prva strana čarobnjaka se može slobodno preskočiti klikom na Next, a na drugoj strani se mora izabrati arhetip, koji se postiže tako što se iz liste kataloga izabere Nexus Indexer koji će poskidati kompletni Maven 2 Central Repository sa mreže (ovo može da potraje), a zatim se iz dobijene liste arhetipova izabere org.nakedobjects:application-archetype (Group Id: org.nakedobjects; Artifact Id: application-archetype; Version: 4.0.0). Klikom na Next će se pojaviti treća strana čarobnjaka gde se zadaju potrebni parametri za novi Naked Objects projekat. U slučaju pubDB-a, bili su zadati sledeći parametri:

90 Zapravo postoje još dva paketa unutar prezentacionog sloja: img i test. Paket img sadrži slike korišćene u GUI-ju, a paket test je služio za testiranje perzistencije u komandnoj liniji, i koristio se samo na početku razvoja.

91 Takođe, paket gui ima još jednu klasu koja igra ulogu fabrike: ComponentFactory. Ova klasa kreira često korišćene Swing komponente, npr. raznu dugmad sa određenom veličinom ili tekstom, itd. Ova fabrika zapravo štiti prezentacioni sloj od dupliranja izvornog koda.

100

• Grupni ID (eng. Group Id): ac.nakedobj

• ID artefakta (eng. Artifact Id): pubDB

• Verzija (eng. Version): 0.0.1-SNAPSHOT (ovo je podrazumevana vrednost, i označava prototip pri izradi)

• Paket (eng. Package): ac.nakedobj.pubDB

Pritiskom na dugme Finish kreiraće se novi Naked Objects projekat, koji se zapravo sastoji od glavnog projekta (u ovom slučaju, pubDB) i od pet dodatnih potprojekata (tzv. Maven modula): [Haywood 2009]

• Sufiks commandline (pubDB-commandline) – ovde se vrši konfiguracija posmatrane aplikacije, i odavde se vrši i njeno startovanje. U ovom potprojektu se nalazi nakedobjects.properties fajl koji je već bio spomenut par puta.

• Sufiks dom (skraćenica od Domain Object Model) (pubDB-dom) – predstavlja najvažniji deo cele aplikacije, ovde živi model domena.

• Sufiks fixture (pubDB-fixture) – u ovaj potprojekat se stave fiksture potrebne kod in-memory perzistora.

• Sufiks service (pubDB-service) – iako nije obavezno, servisi se mogu staviti u ovaj potprojekat. Pošto pubDB koristi samo klase za fabriku i repozitoriju, doneta je odluka da se one ostavljaju u dom potprojektu, prema tome, service potprojekat je u ovom slučaju prazan.

• Sufiks webapp (pubDB-webapp) – koristi se samo u slučaju deploy-ovanja u vidu Web aplikacije.

Što se tiče strukture Naked Objects verzije, ona jako liči na objektni model pubDB-a (Slika 11), zapravo jedina razlika je ta da je proširena klasama za fabriku i repozitoriju. Razlika u odnosu na EJB 3 verziju je još ta da su ovde svi tipovi entiteta

92 Alati za automatizaciju procesa pravljenja softverskih build-ova služe za automatizaciju svakodnevnih zadataka oko izrade build-ova, kao što su kompajliranje, pakovanje, validacija i deployment projekata. Ant i Maven su najpoznatiji primeri iz ove grupe alata u Java svetu. Međutim, oni ovu funkcionalnost postižu na dosta različit način.Apache Ant za build-ovanje koristi obično skriptovanje unutar fajla build.xml. U ovom (često vrlo komplikovanom) XML fajlu se mogu definisati ciljevi, tzv. target-i, i zadaci koji se vezuju za njih.Apache Maven, s druge strane, uvodi koncept POM-a (skraćenica od Project Object Model, u prevodu objektni model projekta), koji označava jedan projekat za build-ovanje, i koji se čuva unutar fajla pom.xml. Međutim, ovaj fajl ne „živi“ izolovano, jer može da definiše zavisnosti ka drugim modulima, komponentima i plug-in-ovima, i da ih preuzima po potrebi ne samo sa lokalnog skladišta, nego čak i sa mreže. Ova skladišta se zovu repozitorije. Najpoznatija repozitorija je Maven 2 Central Repository i nalazi se na adresi <http://repo1.maven.org/maven2/>. Ova repozitorija host-uje i NOF (ali i noviji Isis).Maven, međutim, podržava ne samo preuzimanje iz ovih repozitorija, nego i upload-ovanje softverskih paketa, zbog čega je pogodan i za kreiranje projekata. Kreiranje Maven projekata se radi pomoću plug-in-a Archetype, koji omogućava kreiranje novih projekata od tzv. arhetipova, tj. šablona (eng. Template).

93 Za korišćenje Maven-a unutar Eclipse-a je takođe potrebno da se instalira plug-in m2e.

101

predstavljeni u okviru sopstvenog paketa, prema tome, klasa Author se nalazi unutar paketa ac.nakedobj.pubDB.dom.author, itd. Slika 21 pokazuje dijagram klasa Naked Objects verzije pubDB-a, tj. strukturu potprojekta dom.94 Možda je teško poverovati, ali kompletna funkcionalnost aplikacije se nalazi unutar ovog potprojekta. Ovaj detalj će se još analizirati u odeljku 6.4.

Potprojekat sa sufiksom fixture sadrži fiksture. Pošto pubDB koristi in-memory i XML način skladištenja, korišćenje fikstura se toplo preporučuje. Kao što je već rečeno u odeljku 5.5, u pubDB-u se iskoristila mogućnost hijerarhizacije fikstura, koja predstavlja bolji i pregledniji način njihovih struktuiranja. Slika 22 pokazuje dijagram klasa ove hijerarhije. Cela hijerarhija se nalazi unutar paketa ac.nakedobj.pubDB.fixture koji sadrži koren hijerarhije (AuthorsAndPublicationsSetupFixture) na koji se kače ostali čvorovi stabla. Naravno, slično kao i kod potprojekta dom, fiksture vezane za jedan tip entiteta su smeštene u sopstvene pakete.

94 Potprojekat dom ima još jedan paket, main.resources.images, koji ne sadrži Java klase, nego služi za smeštanje ikonica koje će se koristiti u OOUI-ju aplikacije. Biće još reči o ovom paketu u odeljku 6.2.2.

102

Slika 21: Struktura Naked Objects verzije pubDB-a: dijagram klasa potprojekta dom

Pre završetka ovog odeljka, bilo bi zanimljivo još pogledati šta se nalazi unutar fajla nakedobjects.properties. Ovaj fajl se nalazi unutar commandline potprojekta, unutar folder-a config.95 U slučaju pubDB-a, fajl izgleda na sledeći način:nakedobjects.services.prefix = ac.nakedobj.pubDB.dom # 1)nakedobjects.services = author.AuthorRepository, category.CategoryRepository, publication.PublicationRepository, journal.JournalRepository, publisher.PublisherRepository

nakedobjects.fixtures.prefix = ac.nakedobj.pubDB.fixture # 2)nakedobjects.fixtures = AuthorsAndPublicationsSetupFixture

# nepotrebno izostavljeno

nakedobjects.persistor=xml # 3)

nakedobjects.value.format.int=#### # 4)

95 Ovaj config folder sadrži još nekoliko drugih fajlova kojima se vrši konfiguracija raznih aspekata NOF-a, kao što su port-ovi, korisnici, lozinke, itd., ali njihovo opisivanje već izlazi iz okvira rada.

103

Slika 22: Struktura Naked Objects verzije pubDB-a: dijagram klasa potprojekta fixture. Treba napomenuti, da dijagram prikazuje hijerarhiju fikstura samo do trećeg nivoa (XxxSetupFixture).

Na četvrtom nivou se nalaze konkretne fiksture, tj. podaci konkretnih objekata (npr. ComputerScienceCategoryFixture, DanHaywoodAuthorFixture, itd.), ali radi preglednosti nisu

navedene. Apstraktne Utility klase AbstractXxxFixture se koriste upravo od strane ovih konkretnih fikstura. Pogledati još odeljak 5.5.

U nastavku sledi opis delova zabeleženih brojem: [NO v4.0 User Guide 2009]

1. Kao što je spomenuto u odeljcima 5.4 i 5.6.3, servisi (uključujući i klase za fabriku i repozitoriju) se moraju registrovati sa framework-om da bi bili prepoznati. Oni se navode u delu nakedobjects.services, i razdvajaju se zarezima.96 Kao što se može videti, navode se zapravo imena klasa servisa uz navođenje paketa (po potrebi). Ako se svi servisi nalaze u istom paketu, taj paket se može proglasiti polaznim koji se navodi u delu nakedobjects.services.prefix. Naravno, ako se servisi nalaze u nekom potpaketu unutar polaznog, oni se i dalje mogu navesti kod pojedinačnih servisa.

2. Kao što je poznato iz odeljka 5.5, i fiksture se moraju registrovati sa framework-om. Srećom, njihovo navođenje ide analogno kao kod servisa: u delu nakedobjects.fixtures (polazni paket se može navesti kod dela nakedobjects.fixtures.prefix).

3. U ovom delu se naređuje NOF-u da koristi XML perzistor. Ako se ovaj red izbriše, NOF će po default-u koristiti in-memory perzistor.

4. Ovaj red definiše formatiranje (tj. normalizaciju) celih brojeva, tj. integer-a.97

Naravno ovo parče izvornog koda predstavlja samo izvod iz ovog fajla, a veliki broj naredbi za konfigurisanje u njemu nisu ni navedene, pošto imaju podrazumevane vrednosti. Preostale naredbe za konfigurisanje se mogu pogledati u [NO v4.0 UserGuide 2009].

Kad se porede strukture EJB 3 i Naked Objects verzije pubDB-a, jasno je da je struktura Naked Objects verzije jednostavnija. Dok EJB 3 verzija poštuje pravila višeslojne arhitekture, za Naked Objects verziju je postojanje samo jednog sloja (domenskog sloja) dovoljno. Ovde igra važnu ulogu i osobina samog Naked Objects obrasca, da se GUI mora generisati automatski. Ovi detalji će se još analizirati u odeljku 6.4.

U sledećem odeljku će se preći na predstavljanje grafičkog korisničkog interfejsa (GUI), prvo za EJB 3 verziju pubDB-a, a zatim i za Naked Objects verziju. Njihovo upoređivanje je važno da bi se uočile suštinske razlike između uobičajenog GUI-ja i jednog objektno-orijentisanog korisničkog interfejsa (tj. OOUI-ja).

96 Iako je deo nakedobjects.services u kodu naveden u tri reda, treba napomenuti da to nije dozvoljeno – svi servisi se moraju navesti u istom redu, a ovde se moralo izlomiti na tri reda radi bolje preglednosti. Ovo važi i kod svih drugih delova unutar fajla nakedobjects.properties.

97 Naime, po default-u, NOF uzima regionalni format za formatiranje brojeva, vremena, datuma, itd. Npr. dok US (tj. Američki) regionalni format formatira datum u obliku mesec/dan/godina, UK (Velika Britanija) ga prikazuje kao dan/mesec/godina. Što se tiče celih brojeva, većina lokala stavlja interpunkciju posle svake tri cifre, što ne odgovara potrebama pubDB-a. Ovaj red zapravo redefiniše formatiranje celih brojeva koristeći Java maske (eng. Mask), po kojima znak # označava jednu cifru, a četiri takvih znaka (tj. ####) brišu interpunkciju na trećem mestu.

104

6.2. Korisnički interfejs pubDB-aU ovom odeljku će se predstaviti GUI pubDB-a. Kao što je poznato, EJB 3

verzija aplikacije koristi ručno pravljen GUI (kreiran u Swing-u), a Naked Objects verzija koristi OOUI koji se generiše automatski na osnovu modela domena. Cilj ovog odeljka je da prikaže razlike između ova dva grafička interfejsa. Tokom odeljka, opisaće se rad sa ovim interfejsima i ilustrovaće se slikama.

6.2.1.GUI pubDB-a (EJB 3 verzija)EJB 3 verzija pubDB-a se startuje pokretanjem fajla MainWindow.java iz paketa

gui (naravno, tokom izvršavanja, i JBoss server mora da radi, a startovanje servera se vrši iz Eclipse-a).

Pri pokretanju pubDB-a prikazaće se njegov glavni prozor (Slika 23) sa nekoliko dugmadi: većina od njih služi za dodavanje novih entiteta (autora, kategorija, časopisa, izdavača, članka i knjiga) u bazu podataka, a poslednje služi za pretraživanje već postojećih entiteta. Donji deo prozora prikazuje pomoćne poruke, koje se dinamično menjaju u zavisnosti od pozicije miša: kad korisnik postavlja kurzor miša na određeno dugme, prikazaće se pomoćni tekst sa objašnjenjem svrhe tog dugmeta.

Kad korisnik klikne na Add Author dugme, prikazaće se dijalog za dodavanje novog autora (Slika 24). Dijalog je vrlo jednostavan: očekuje se da korisnik upiše ime, prezime, a opciono i biografiju novog autora. Naravno, polja za ime i prezime se moraju popuniti, inače će se pojaviti greška. Klikom na dugme Add se autor perzistuje u bazu i dijalog se zatvara, vraćajući korisnika na glavni prozor.

105

Slika 23: Glavni prozor EJB 3 verzije pubDB-a

Dugme Add Category omogućava dodavanje nove kategorije. Dijalog je jednostavan (Slika 25), ali budući da su kategorije smeštene u hijerarhiju, omogućavajući da imaju i podkategorije, mora se izabrati i roditeljska kategorija, pri čemu je podrazumevan izbor zapravo koren, tj. Root. Poruke o greškama se pokazuju u sledećim situacijama: kad korisnik zaboravi da upiše labelu (tj. naziv) kategorije, kad proba upisati „root“ kao labelu (ova labela je rezervisana za korensku kategoriju98) i kad labela nije jedinstvena.

Dugme Add Journal služi za dodavanje novog časopisa, a Add Publisher za dodavanje novog izdavača. Ovi dijalozi su jako slični, i imaju po dva tekstualna polja, pri čemu je ispunjavanje prvog polja obavezno.

Klikom na dugme Add Article pojaviće se dijalog za unos novog članka (Slika26). Dijalog je kompleksniji u odnosu na prethodne dijaloge, budući da pored tekstualnih polja omogućava povezivanje novog članka sa autorima, i sa po jednom kategorijom i časopisom. Postojeći autori se prikazuju u obliku liste koja omogućava njihovo selektovanje. Pošto članak može imati više autora, korisnik može izabrati više autora tako što tokom selektovanja drži pritisnut taster Control. Poruke o greškama se pokazuju u sledećim situacijama: kad korisnik zaboravi ispuniti obavezna polja (naslov i godina izdavanja), kad uneta godina izdavanja nije pozitivan broj, i kad zaboravi da poveže članak sa autorom (ili autorima), kategorijom i časopisom. Ovaj dijalog ima i odgovarajuću dugmad Add i View za dodavanje novih autora, kategorija i časopisa u bazu podataka (ukoliko ne postoje), kao i njihovo pregledanje i modifikovanje. Naravno posle dodavanja ili modifikovanja nekog entiteta, sve liste (sa autorima, kategorijama i

98 Ovo ograničenje polazi iz samog GUI-ja. Zapravo ne postoji kategorija sa labelom „root“, ali se koristi u GUI-ju da bi se označila korenska kategorija u hijerarhiji, jer GUI prosleđuje izabranu kategoriju preko njene labele. Direktna posledica ovoga je još jedno ograničenje: naziv (tj. labela) kategorije mora biti jedinstven.

106

Slika 24: Dijalog za dodavanje novog autora

časopisima) se ažuriraju.

107

Slika 25: Dijalog za dodavanje nove kategorije

Slika 26: Dijalog za dodavanje novog članka

Dodavanje nove knjige se vrši klikom na dugme Add Book. Dijalog je vrlo sličan dijalogu za dodavanje novog članka (samo se umesto liste časopisa prikazuje lista izdavača). Međutim, ono što je skroz novo kod ovog dijaloga je da postoji i slikovno polje, koje omogućava dodavanje korice za knjigu. Klikom na dugme Browse pojavljuje se dijalog za izbor JPG slike na fajl sistemu, nakon čega će se slika pojaviti u slikovnom polju dijaloga, dok dugme Remove služi za brisanje trenutno izabrane slike (ne fizičko brisanje sa fajl sistema). Klikom na dugme Add knjiga se perzistuje u bazu podataka, zajedno sa slikom (drugim rečima, slika će se čuvati u bazi podataka).

Mora se napomenuti da su dijalozi za dodavanje novog članka i nove knjige dosta „skupi“ u smislu komunikacije sa bazom podataka, pre svega zbog načina dizajniranja ovih dijaloga. Naime, pri kreiranju ovih dijaloga aplikacija mora iz baze da preuzme sve autore, sve kategorije i sve časopise (ili izdavače, zavisno od dijaloga) i da ih smesti u odgovarajuće liste. Budući da su ovakvi upiti relativno skupi, naročito kad je baza velika, smatra se da ovi dijalozi nisu baš efikasni, mada odgovaraju potrebama u slučaju manjih količina podataka.

Konačno, klikom na dugme Search, otvoriće se dijalog za pretraživanje već perzistovanih entiteta iz baze podataka (Slika 27). Dijalog je podeljen na dva dela: gornji deo služi za unos pretrage od strane korisnika, a rezultati će se pojaviti u donjem

108

Slika 27: Dijalog za pretraživanje entiteta iz baze podataka

delu. Takođe, gornji deo je grupisan u dve kartice, tj. tab-a: prva kartica služi za pretraživanje autora, kategorija, časopisa i izdavača, a druga za pretraživanje publikacija (tj. članka i knjiga). Za pretragu postoje sledeće opcije: pretraga autora (po imenu), kategorija (po labeli), časopisa (po nazivu), izdavača (po nazivu i/ili adresi), publikacija (po naslovu, godini izdavanja, autoru ili kategoriji), specifičnih članka (po DOI ili časopisu) i specifičnih knjiga (po ISBN ili izdavaču). Klikom na dugme Search izvršiće se pretraga, a rezultati će se prikazati u donjem delu dijaloga u obliku tabele. Korisnik zatim može kliknuti na neki red tabele. Selektovani entitet iz tabele se može pregledati (klikom na dugme View) ili obrisati (klikom na dugme Delete).

U slučaju da korisnik klikne na dugme View, pojaviće se dijalog za pregled i modifikaciju tog entiteta (Slika 28). Ovaj dijalog je vrlo sličan dijalogu za dodavanje posmatranog tipa entiteta. Međutim, ako je reč o autorima, kategorijama, časopisima ili izdavačima, pojaviće se i dodatni deo sa listom publikacija sa kojima je posmatrani entitet povezan. S druge strane, ako je reč o člancima ili knjigama, umesto prikazivanja liste publikacija (ovo nema smisla) radiće se nešto drugo: liste za autore, kategoriju, časopisa ili izdavača (zavisno od tipa publikacije) će automatski selektovati one entitete sa kojima je posmatrani članak (ili knjiga) povezan. Takođe, u slučaju da je reč o dijalogu za pregled knjige (Slika 29), on mora učitati i sliku (korice) iz baze podataka (ne iz fajl sistema).99 Bez obzira koji entitet se posmatra, dijalog omogućava i njegovu modifikaciju (klikom na dugme Update).

U slučaju da korisnik želi obrisati izabrani entitet iz tabele, mora kliknuti na dugme Delete. Ovde se mora napomenuti da se brisanje vrši dosta destruktivno. Naime, ako korisnik želi obrisati nekog autora, kategoriju, časopis ili izdavača, aplikacija će

99 Uzgred, dijalozi za kreiranje i modifikovanje entiteta su slični zato što su kreirani iz istih klasa. Naime, klase sa sufiksom Dialog su parametrizovane. U zavisnosti od prosleđenog parametra, pojaviće se dijalog za dodavanje novog entiteta ili dijalog za pregledanje i modifikaciju entiteta.

109

Slika 28: Dijalog za pregledanje i modifikaciju postojećih autora

obrisati i one publikacije (članke i knjige) s kojima je posmatran entitet povezan. Na primer, autor može da „živi“ bez publikacija, ali publikacija ne može da živi bez autora. Prema tome, ako aplikacija primeti da je izabran entitet povezan sa nekim publikacijama, klikom na dugme Delete pojaviće se poruka u kojoj se upozorava korisnik da će i te publikacije biti obrisane.

Posle ovih izlaganja je očigledno da ovaj GUI predstavlja tipičan primer „glagol-imenica“ stila interakcije (odeljak 3.3). Zaista, u glavnom prozoru se prvo izabere zadatak (šta se želi uraditi), a zatim objekat (nad čim se želi izvršiti taj zadatak). Na primer: korisnik prvo izabere dugme za pretraživanje, a zatim izabere vrstu pretrage i upiše upit u odgovarajuće polje. Slično je i kod dodavanja, samo je glavni prozor struktuiran tako da postoje posebna dugmad za sve tipove entiteta. Ona na neki način kombinuju „glagol“ sa „imenicom“, i to je u redu dok model domena nema puno tipova entiteta. Međutim, čim model postane veći, bila bi bolja ideja da se napravi samo jedno generalno dugme za dodavanje („glagol“), a klikom na njega bi se pojavio padajući meni sa raznim tipovima entiteta („imenica“). Moglo bi se ovo implementirati i u obliku menija: u meniju bi postojao element New (tj. novi) koji bi otvorio jedan podmeni sa listom tipova entiteta. Sve ove ideje takođe spadaju u „glagol-imenica“ stil interakcije.

Ono što je zanimljivo je to da je autor ovog rada GUI (zajedno sa celom EJB 3 aplikacijom) implementirao bez poznavanja ovih stilova interakcije. Ovo zapravo daje neku vrstu potpore tvrdnjama Constantine-a iz [Constantine 2002], tj. da je većini ljudi

110

Slika 29: Dijalog za pregledanje i modifikaciju postojeće knjige

„glagol-imenica“ stil interakcije prirodniji pri korišćenju korisničkih interfejsa. Dovoljno je samo pogledati GUI kod EJB 3 verzije pubDB-a: naglasak je stavljen na zadatke, a sve ostalo dolazi kasnije. Međutim, postavlja se pitanje da li je stvarno reč o prirodnom načinu interakcije ili možda o nametnutom načinu. O ovome će još biti reči u sledećem delu ovog odeljka.

6.2.2.OOUI pubDB-a (Naked Objects verzija)U ovom delu će se predstaviti korisnički interfejs Naked Objects verzije pubDB-

a. Kao što je poznato, ovaj interfejs je objektno-orijentisan, i generiše se automatski.

Kao što je bilo spomenuto u 6.1.2, jedan zanimljiv detalj u vezi dom potprojekta je paket main.resources, kao i paket images unutar njega. U ovaj paket se stavljaju razni resursi aplikacije, kao što su ikonice. Naime, jedan od osnovnih elemenata OOUI-ja je ikonica za objekte. NOF naravno omogućava vizuelno prilagođavanje svakog objekta. Ova osobina je zapravo dosta automatizovana. Naime, svaki objekat ima deo za identifikaciju, koji se može posmatrati kao proširenje koncepta identiteta: svakoj instanci se (pored identiteta) još mogu dodeliti naslov (eng. Title) i ikonica.

Što se tiče naslova, on se odnosi na predstavljanje konkretnog objekta (tj. instance).100 Naslov objekta se piše u rezervisanom metodu title(). [Haywood 2009] Sledeće parče izvornog koda iz klase Author.java bi trebalo da pokazuje način korišćenja ovog metoda:public class Author extends AbstractDomainObject { // {{ Identification public String title() { final TitleBuffer buf = new TitleBuffer(); buf.append(getFirstName()).append(getLastName()); return buf.toString(); } // }}

// nepotrebno izostavljeno

}Smatra se dobrom praksom da se deo za identifikaciju objekta stavlja na početak

klase. Prvo, pomoću šablona noid (skraćenica od Naked Objects Identification Region) se pravi oblast za ovaj deo, a zatim se metod kreira pomoću noidtitle (skraćenica od Naked Objects Identification – Title). Metod title() vraća vrednost tipa String kojim se predstavlja naslov jedne instance ove klase. U slučaju autora, metod je implementiran tako da vraća ime plus prezime autora koji se čuvaju unutar polja buf tipa TitleBuffer. Ovaj tip se nalazi u biblioteci NOF-a (org.nakedobjects.applib.util) i ima dva cilja: da po potrebi normalizuje string (npr. da stavi razmak između imena i prezimena) i da zamenjuje null string-ove adekvatnijim vrednostima.

Što se tiče ikonica za objekte, NOF će ih automatski potražiti u prethodno spomenutom paketu images (podržane su slike sa ekstenzijama GIF, PNG i JPG) i dodeliće ih objektima, važno je samo da se naziv fajla ikonice poklapa sa nazivom

100 Ne mešati sa anotacijom @Named koja se odnosi na imenovanje celog tipa entiteta.

111

klase. Ako takav fajl nije pronađen, ali ako posmatrana klasa ima nadklasu unutar potprojekta dom, koristiće sliku nadklase, a ako ni to nije moguće, koristiće podrazumevanu sliku iz NOF-a. Međutim, u nekim situacijama, npr. kad neka klasa želi koristiti već korišćenu sliku, nema svrhe duplirati fajl samo da bi se naziv fajla poklopio sa nazivom klase. U ovakvim slučajevima se koristi drugi rezervisani metod za identifikaciju, iconName(), koji vraća String sa imenom fajla ikonice (bez ekstenzije). Naravno, i ovaj metod je opcioni, pa se navodi samo kad je potrebno. Ovaj metod se kreira pomoću šablona noidicon (skraćenica od Naked Objects Identification – Icon). [NO v4.0 User Guide 2009] Tipično mesto gde se koristi spomenuti metod je klasa za fabriku i repozitoriju. Naime, logično je da ta klasa ima istu ikonicu kao i objekti koji se kreiraju od strane te klase. Sledeće parče koda iz klase AuthorRepository.java prikazuje ovaj metod:public class AuthorRepository extends AbstractFactoryAndRepository { // {{ Identification public String iconName() { return "Author"; } // }}

// nepotrebno izostavljeno}

Posle ove kraće digresije, došlo je vreme da se pokrene Naked Objects verzija pubDB-a. Kao što je poznato iz 5.2.1, NOF se isporučuje sa dva ugrađena pogleda: DnD (tj. Drag-n-Drop Viewer, prikazuje se u obliku Java aplikacije) i HTML (prikazuje se u Web brauzeru). Zato NOF definiše i dva tzv. Maven launch fajla za startovanje, kojima se može pristupiti u Eclipse-u putem Run → Run Configurations, a zatim izborom Naked Objects (DnD) ili Naked Objects (HTML) i pritiskom na dugme Run. U nastavku će se prikazati oba pogleda: prvo DnD, a zatim i HTML.

Startovanjem pubDB-a u DnD pogledu prikazaće se jedan GUI koji možda najviše liči na desktop nekog operativnog sistema (Slika 30). Glavni prozor pri pokretanju zapravo ne prikazuje objekte, nego klase za fabriku i repozitoriju. One su predstavljene u obliku ikonica, i stavljanjem kurzora miša iznad njih će se pojaviti pomoćna poruka u donjoj statusnoj liniji prozora, koja objašnjava svrhu te ikonice (tj. klase). Desnim klikom na neku ikonicu će se pojaviti iskačući meni sa odgovarajućim akcijama: npr. u slučaju autora, definisane su tri akcije: dodavanje novog autora (New Author), izlistavanje svih autora iz skladišta (All Authors), kao i pretraživanje po imenu (Search By Name). Akcija All Authors se nalazi na dnu menija (i razdvojena je od ostatka), jer je markirana anotacijom @Exploration (Slika 31).

Dodavanje novog autora (Slika 32) zahteva ispunjavanje prezimena, imena i biografije autora, a publikacije se mogu dodati na levoj strani dijaloga. Polje za biografiju je višelinijsko, budući da je odgovarajući atribut označen sa @MultiLine. Na dnu se nalaze i tri dugmeta: Save (dodaj novog autora u skladište, ali nemoj zatvoriti dijalog), Save & Close (dodaj i zatvori) i Discard (odbaci autora i zatvori dijalog). Na slici se mogu primetiti da su prva dva dugmeta siva (tj. deaktivirana). To je zato što su polja za ime i prezime obavezna, i autor se neće perzistovati sve dok ta polja nisu ispunjena.

112

Pretraživanje autora po imenu se podudara sa akcijom searchByName(String name). Pošto akcija ima jedan parametar, pojaviće se mali dijalog (Slika 33) u koji se mora uneti ime (ili prezime) autora. Klikom na dugme OK aplikacija će vratiti rezultate pretrage u novom dijalogu.

Akcija All Authors samo vraća sve perzistovane autore (Slika 34). U listi je moguće pogledati nekog autora pomoću duplog klika, koji će se pojaviti u novom dijalogu (modifikacija atributa je ovde takođe omogućena). Uzgred, publikacije autora se mogu proveriti na levom delu dijaloga, klikom na znak plus ispred elementa Publications (budući da je reč o kolekciji) (Slika 35). Dalje, poznato je iz 5.3.4 da entitet Author ima akciju za brisanje autora, deleteAuthor(boolean

113

Slika 30: Glavni prozor Naked Objects verzije pubDB-a (DnD pogled)

Slika 31: Iskačući meni ikonice Authors

deletePublicationsToo). Budući da je reč o akciji objekta tipa Author, njoj se može pristupiti desnim klikom na objekat, bez obzira gde se on nalazi: na desnoj (Slika 36) ili levoj strani dijaloga, ili unutar dijaloga sa listom autora (Slika 34). Pošto akcija ima jedan parametar, pojaviće se mali dijalog (Slika 37), u kojem se pita da li korisnik želi obrisati i publikacije vezane za posmatranog autora (destruktivno brisanje) ili ne. Radi podsećanja, korisnik u EJB 3 verziji pubDB-a nije imao izbora – entiteti su se brisali destruktivno. Ovde je autor odlučio da implementira oba načina, budući da su toliko jednostavna (mada će logički parametar po default-u uvek biti true).

Kao što se može primetiti, iskačući meni ima još neke stavke: Dispose Object, koji briše element, ali se smatra nepouzdanim načinom brisanja, budući da ne obraća pažnju na veze sa drugim tipovima entiteta; Instances, koji izlistava instance posmatranog tipa entiteta; i Clone, koji klonira posmatranu instancu (tj. pravi novi prelazni objekat i kopira vrednosti polja). Ove stavke su vidljive u istraživačkom

114

Slika 33: Dijalog za pretraživanje autora po imenu Slika 34: Lista sa

svim autorima

Slika 32: Dijalog za dodavanje novog autora

(exploration) režimu rada.

Ostale ikonice na desktopu aplikacije omogućavaju rad sa kategorijama, publikacijama, časopisima i izdavačima, i funkcionišu analogno kao kod autora. Kod kategorija je moguće dodati novu kategoriju, pretražiti ih po labeli i izlistati ih (svaku od njih ili samo korenske kategorije). Kod publikacija (Slika 38) je moguće kreirati novi članak ili knjigu i izlistati svaki od njih. Takođe, publikacije se mogu pretražiti na nekoliko načina: po naslovu, godini izdavanja, autoru, kategoriji, DOI, časopisu, ISBN i po izdavaču. Što se tiče časopisa, omogućeno je njihovo kreiranje, izlistavanje, kao i pretraga po nazivu časopisa. Konačno, ikonica za izdavače omogućava dodavanje novog izdavača, kao i njihovo izlistavanje i pretraživanje. Jedino što treba napomenuti je to da u odnosu na EJB 3 verziju, ovde ne postoji atribut za korice (tj. sliku) knjiga. Razlog ovome leži u činjenici da NOF v4.0 za sad nema mogućnost kreiranja atributa tipa slika.

115

Slika 35: Dijalog za pregledanje i modifikaciju postojećeg autora

Slika 36: Desnim klikom na naslov entiteta se mogu pozvati akcije tog tipa entiteta

Slika 37: Dijalog za brisanje autora

Ono što može biti zanimljivo je kako povezati neki entitet sa drugim tipom entiteta. Za ovu svrhu, neka se pretpostavi da se želi dodati nova kategorija, Chemistry (tj. hemija) i neka bude podkategorija od Scientific (tj. naučni). Prvo se pravi nova kategorija, i upiše se njena labela. Da bi se ona povezala sa roditeljskom kategorijom, mora se pribaviti referenca na tog roditelja. To se može uraditi na više načina: izlistavanjem svih kategorija, pretraživanjem, itd. Važno je samo da se na desktopu vidi taj roditelj. Zatim je potrebno kliknuti mišem na naziv roditelja, i prevući ga u dijalog za kreiranje nove kategorije, i baciti na polje Parent Category (Slika 39). Skalarne asocijacije (poput roditeljske kategorije) se nalaze na desnoj strani dijaloga, a vektorske (tj. kolekcije, poput podkategorija) na levoj. Dodavanje podkategorija ide analogno: treba samo mišem željenu podkategoriju prevući u deo Subcategories. Brisanje veza je takođe jednostavno: treba kliknuti desnim tasterom na Parent Category, i iz iskačućeg menija izabrati Clear association. Uspostavljanje kao i brisanje veza je zapravo definisano odgovarajućim getter-ima i setter-ima unutar klase, kao i njihovim dodatnim metodima (pogledati odeljak 5.3.2).

Bilo bi zanimljivo pogledati malo i HTML pogled. Ovaj pogled generiše čist HTML kod unutar Web brauzera, prema tome, mogućnosti ovog pogleda su ograničene u odnosu na DnD pogled. Pre svega, naprednije mogućnosti miša, kao što su desni klik i Drag and Drop funkcionalnost, su isključene. Međutim, ovaj pogled koristi neke trikove pomoću kojih se mogu simulirati prethodne funkcionalnosti.

Pri pokretanju HTML pogleda, u Eclipse-u će se automatski startovati Jetty v6.1.16 Web server koji se dobija uz NOF paket. Zatim treba pokrenuti neki Web brauzer i upisati adresu localhost:8080/logon.app. Glavni prozor (tačnije, stranica) HTML pogleda je nešto drugačiji u odnosu na DnD pogled (Slika 40).101 Kod ovog pogleda, klase za fabriku i repozitoriju se nalaze direktno ispod zaglavlja stranice u tzv. navigacionoj traci. Takođe, sa desne strane ove linije se nalaze tri dodatna linka: Log Out služi za izlogovanje; About prikazuje verziju NOF-a; a Swap User omogućava promenu korisnika, ali budući da pubDB ima samo podrazumevanog korisnika, i radi u istraživačkom režimu, oni se ne koriste.

101 Vredi spomenuti da HTML pogled podržava i CSS (skraćenica od Cascading Style Sheets), što omogućava prilagođavanje ovog pogleda za potrebe aplikacije: npr. moguće je izmeniti logo u zaglavlju stranice, itd. [Haywood 2009]

116

Slika 38: Iskačući meni ikonice Publications

Slika 39: Kod DnD pogleda, za povezivanje nekog entiteta sa drugim entitetom se koristi drag and drop funkcionalnost miša

Klikom na link neke klase za fabriku i repozitoriju pojaviće se stranica sa akcijama te klase koje se sad nalaze u levom okviru stranice (Slika 41). Pomoćni tekst će se pojaviti u statusnoj liniji brauzera, ali i u obliku balončića.

Klikom na New Author, pojaviće se stranica za dodavanje novog autora. Pored uobičajenih tekstualnih polja za unos imena, prezimena i biografije, pri čemu su prva dva polja označena crvenom zvezdicom (obavezna polja), stranica ima dva dugmeta: Save (sačuvaj) i Cancel (odustani), pri čemu je dugme Save uvek aktivno. Međutim, ovo ne znači da će aplikacija dopustiti skladištenje novog autora bez imena i prezimena. Zaista, klikom na dugme Save pojaviće se ista stranica ali sa upozorenjem da su polja za ime i prezime obavezna (Slika 42).

Klikom na link Search By Name pojaviće se stranica (Slika 43) koja traži da se upiše ime autora (budući da ova akcija ima jedan parametar).

Link [All Authors] samo izlistava sve autore (Slika 44).102 Ako korisnik klikne na nekog autora, pojaviće se stranica sa podacima tog autora (Slika 45), pri čemu se sa desne strane nalaze podaci, a s leve strane akcije vezane za taj tip entiteta. Dalje, na dnu stranice se pojavilo jedno dugme, Edit Object, koje služi za modifikaciju posmatranog

102 Link se nalazi u uglastim zagradama, budući da se u HTML pogledu na taj način označavaju akcije markirane sa @Exploration.

117

Slika 40: Glavna stranica Naked Objects verzije pubDB-a (HTML pogled)

autora. Konačno, kolekcije ovog tipa entiteta (u ovom slučaju, publikacije) se mogu proveriti klikom na polje kolekcije.

Postavlja se pitanje, kako se realizuje Drag and Drop funkcionalnost koja ne postoji kod HTML pogleda, npr. kako se mogu praviti asocijacije između različitih tipova entiteta? Kod DnD pogleda je bilo dovoljno samo prevući objekat na odgovarajuće polje drugog tipa. Umesto toga, kod HTML pogleda je pravljenje asocijacija rešeno pomoću padajućih lista i tabela.

Padajuće liste se koriste kod skalarnih asocijacija (Slika 46). Ovde se mora spomenuti jedna zanimljiva osobina HTML pogleda. Ovaj pogled koristi tzv. lenjo učitavanje (eng. Lazy Loading), što znači da se učitavaju samo oni entiteti koji su potrebni. U skladu sa tim, kao što se može videti na slici, u listi se za izbor roditeljske kategorije ne nalaze sve kategorije, nego samo već prethodno učitane. Naime, kad se dobro pogleda slika, vidi se da navigaciona traka ima više linija: u prvoj se nalaze klase za fabriku i repozitoriju, u drugoj se nalaze do sad učitani objekti, a u trećoj do sad posećene stranice, pri čemu se donje dve linije menjaju dinamično, tj. one se proširuju novim podacima posle svake učitane stranice. Na slici se vidi da je što se tiče druge linije prvo korisnik učitao pet objekata (zapravo, svih pet autora), zatim jednog konkretnog autora (Dan Haywood), a zatim tri objekta (zapravo, kliknuto je na akciju

118

Slika 41: Klikom na link Authors pojaviće se stranica koja zapravo pokazuje sadržaj ove klase za fabriku i repozitoriju

All Root Categories, koji vraća sve korenske kategorije, a njih ima tri). Zato padajuća lista za izbor roditeljske kategorije ima samo tri konkretne kategorije.103

Tabele se koriste kod vektorskih asocijacija. Njima se ne može pristupiti sa stranice za modifikaciju objekta (tj. klikom na dugme Edit Object), nego klikom na polje vektorske asocijacije na stranici gde se objekat pregleda (Slika 45). Sama tabela (Slika 47) ima onoliko redova koliko ima entiteta sa kojima je posmatran entitet povezan, a u kolonama se mogu videti podaci tog entiteta. Klikom na dugme Add Item pojaviće se nova stranica gde se mogu jedan po jedan dodavati novi entiteti u kolekciju. Naravno, potrebno je pre toga učitati te entitete, zbog lenjog učitavanja.104

103 Stavka [not set] iz padajuće liste označava da se ne želi zadati roditeljska kategorija, a Untitled Category zapravo označava kategoriju koja se sad želi dodati – ovo nema puno smisla, i predstavlja nedostatak HTML pogleda.

119

Slika 42: Stranica za dodavanje novog autora. Ako korisnik klikne na Save bez popunjavanja obaveznih polja, pojaviće se greška „Invalid properties“.

Slika 43: Stranica za pretraživanje autora po imenu

Ako se porede DnD i HTML pogled, jasno je da je DnD moćniji. Pre svega, nemogućnost korišćenja naprednih funkcija na mišu, kao što su desni klik i Drag and Drop, smanjuje funkcionalnost HTML pogleda, iako su one zamenjene nekim alternativnim rešenjima. Takođe, stiče se utisak da je HTML pogled pomalo nezavršen proizvod, budući da nema implicitno mogućnost brisanja asocijacija (mada se može dodati eksplicitno).

104 Važno je napomenuti da za razliku od DnD pogleda, HTML pogled nema mogućnost brisanja postojećih asocijacija. U DnD pogledu ovo se radilo sa Clear Association, međutim, u HTML pogledu ova opcija ne postoji. Iz ovoga se vidi da HTML pogled nije skroz završen. Ovo potvrđuju i polja za potvrdu (tj. check-box) u svakom redu tabele (Slika 47, poslednja kolona), koja za sad nemaju nikakvu funkciju. Međutim, programeri mogu slobodno kreirati nove akcije koje bi imale zadatak brisanja asocijacija.

120

Slika 44: Stranica koja sadrži listu svih autora

Slika 45: Stranica za pregledanje i modifikaciju postojećeg autora

Još jedna bitna razlika između ova dva pogleda je to da HTML pogled radi po načinu „jedan zadatak po stranici“, dok DnD pogled omogućava paralelan način rada. Neka se posmatra kategorija Scientific. Klikom na znak plus ispred kolekcije Subcategories se mogu izlistati podkategorije. Svaka od tih podkategorija ima znak plus ispred imena, pa se mogu čak proveriti i podkategorije ovih podkategorija. Šta više, klikom na samu kolekciju (umesto na znak plus) pojaviće se svi elementi kolekcije u obliku tabele na desnoj strani dijaloga. Dalje, klikom na znak plus ispred elementa Publications, mogu se izlistati i publikacije koje pripadaju toj kategoriji. Ako se klikne na bilo koji element sa leve strane dijaloga, desna strana će se promeniti da pokaže podatke tog entiteta (Slika 48). Podaci se mogu modifikovati bilo kad, a isto to važi i za

121

Slika 46: U HTML pogledu se koriste padajuće liste za skalarne asocijacije

Slika 47: U HTML pogledu se koriste tabele za prikaz vektorske asocijacije. Novi entiteti se mogu dodati klikom na dugme Add Item.

asocijacije. Kad korisnik želi ozbiljnije da se bavi nekim entitetom, treba samo da klikne dva puta na naslov tog objekta, i on će se pojaviti u novom dijalogu. Ovako se mogu nagomilati dijalozi za efikasnije rešavanje problema. Naravno, dijalozi se mogu minimizirati klikom na odgovarajuće dugme u gornjem desnom uglu. Sve u svemu, ako korisnik voli da radi paralelno, DnD to omogućava (Slika 49).

122

Slika 48: U DnD pogledu se desna strana dijaloga menja u zavisnosti od izbora konkretnog entiteta ili vektorske asocijacije sa leve strane dijaloga

Slika 49: DnD pogled omogućava otvaranje više dijaloga, a samim tim i paralelni rad. Minimiziranje dijaloga je takođe omogućeno.

Bez obzira koji pogled se koristi, oba predstavljaju primere objektno-orijentisanog korisničkog interfejsa. Za razliku od GUI-ja EJB 3 verzije pubDB-a, OOUI implementira „imenica-glagol“ stil interakcije. Zaista, prva stvar koju korisnik primećuje pri pokretanju Naked Objects verzije pubDB-a su ikonice koje predstavljaju tipove entiteta (zapravo, reč je o klasama za fabriku i repozitoriju). Desnim klikom na ikonicu koja predstavlja „imenicu“ (npr. autora) korisnik može odabrati željenu akciju, tj. „glagol“: da doda novog autora u skladište, ili da ih pretražuje. Ovo je skroz u suprotnosti sa „glagol-imenica“ stilom, koji prvo zahteva izbor željene akcije, a tek onda izbor objekta.

6.2.3.DiskusijaPrethodni deo ovog odeljka (6.2.1) se završio konstatacijom da je autor ovog

rada napravio GUI sa „glagol-imenica“ stilom interakcije (kod EJB 3 verzije) bez ikakvog znanja o stilovima, i postavilo se pitanje, da li ovo predstavlja prirodan način interakcije, ili je možda na neki način nametnut. Odgovor na ovo pitanje je teško dati, pošto je reč o dosta subjektivnoj tematici. Naime, sam pojam upotrebljivosti je dosta širok, a velikom broju ljudi je važna i vizuelna dopadljivost. Procenjivanje ovih atributa je prema tome individualna stvar svakog pojedinca, i teško je meriti. Međutim, moglo bi se reći, da u današnje vreme dominiraju upravo aplikacije sa „glagol-imenica“ stilom interakcije. Što se tiče operativnih sistema, većina njih je sačuvala ideje predstavljene u starim Smalltalk okruženjima, kao što su ikonice, iskačući meniji koji se pojavljuju desnim klikom i Drag and Drop funkcionalnost, ali može se u njima naći dosta toga i iz drugog stila, kako što je svima poznat Start meni u Windows sistemima. Međutim, kod ostalih vrsta softvera, uključujući i poslovni, barem po Trygve Reenskaug-u i Pawson-u, dominira „glagol-imenica“ stil interakcije. [Pawson 2004] Constantine i verovatno još i drugi stručnjaci ističu da je ovaj stil lakši za upotrebu [Constantine 2002], i lako se može proširiti sa mehanizmom vođenja korisnika. Jasno je da bi ovu funkcionalnost bilo teško implementirati kod „imenica-glagol“ stila, pre svega zbog nedostatka imperativnog tona (poput „dodaj“, „pretraži“, itd.). Zapravo ovaj stil interakcije bi se mogao preporučiti kod prolaznih aplikacija, pošto se one koriste od strane većeg broja korisnika. [Cooper, Reimann & Cronin 2007] Čarobnjaci i druge ideje mogu olakšati korišćenje programa, ali to ne znači da će oni povećati i efikasnost rada. Međutim, i suverene aplikacije, koje se koriste od strane nešto manjeg broja korisnika, su ovakve – računari su osposobljeni da vode korisnika, iako bi trebalo obrnuto. [Pawson 2004] Prema tome, ljudi danas pretežno vide aplikacije koje koriste „glagol-imenica“ stil interakcije, što indirektno može da utiče na formiranje generalnog mišljenja o korisničkim interfejsima.

S druge, unutrašnje strane, programeri poslovnog softvera se danas uglavnom susreću sa višeslojnim arhitekturama i sa slučajevima korišćenja koji dominiraju već od prve faze razvoja. Jasno je da ovi koncepti utiču na način shvaćanja kompletnog softvera, uključujući i GUI. [Pawson 2004] Zaista, dugmad i drugi elementi interfejsa simuliraju slučajeve korišćenja, a pošto su oni dosta imperativni, dobija se GUI koji je oblikovan na ovaj način. Drugim rečima, dobija se interfejs sa „glagol-imenica“ stilom interakcije.

Ova dva prethodna opažanja (globalna dominacija „glagol-imenica“ stila, kao i slučajevi korišćenja) su najverovatnije bili glavni uzroci da je autor ovog rada napravio

123

GUI sa „glagol-imenica“ stilom interakcije za EJB 3 verziju pubDB-a. Naravno, GUI je sasvim funkcionalan, ali ako se direktno poredi sa nekim OOUI-jem (pre svega sa DnD pogledom), stiče se utisak, da je Naked Objects verzija pubDB-a moćnija. Ono što je najzanimljivije je to da su se neke funkcionalnosti „same implementirale“ (tabelarni prikaz rezultata pretrage, modifikacija podataka i još neke druge), a neke druge funkcionalnosti skroz nedostaju iz EJB 3 verzije (prikaz rezultata u obliku stabla ili lista, paralelni rad, itd.). Može se takođe slobodno reći da je OOUI (pre svega DnD pogled) mnogo više osposobio autora ovog rada da reši probleme vezane za pubDB: paralelni rad i prikaz rezultata na više načina čini upotrebu softvera efikasnijom, naročito ako se softver koristi svakodnevno – baš kao suverena aplikacija.

6.3. Perzistencija u pubDB-uU ovom odeljku će se predstaviti perzistencija unutar pubDB-a, kao i razna

opažanja od strane autora ovog rada u vezi sa istom.

Što se tiče perzistencije u EJB 3 verziji pubDB-a, već je spomenuto da se kao baza podataka koristio MySQL. Ovo je umnogome olakšalo generisanje sloja podataka, koji nije zahtevao programiranje, ali to ne znači da EJB 3 može sve automatizovati. Naime, i dalje je potrebno da se konfiguriše ORM, tj. mehanizam za preslikavanje objekata u relacione podatke. Kao što je poznato, u EJB 3, sa ORM-om i generalno rečeno perzistencijom, se bavi JPA. Srećom, konfigurisanje ORM-a je dosta pojednostavljeno, i svodi se uglavnom na pisanje raznih Java anotacija u klasama perzistentnog sloja. Međutim, predstavljanje JPA i anotacija za perzistenciju već izlaze iz okvira ovog rada, pa je dovoljno reći da postoje razne anotacije koje se tiču perzistencije, npr.: @Table (specificira tabelu u relacionoj bazi, navodi se pre deklaracije klase); @Id (definiše atribut kao primarni ključ); @Column (specificira kolone unutar tabele, navodi se ispred atributa); @Lob (skraćenica od Large Object, označava „težak“ tj. veliki objekat sa kojim se markiraju atributi kao što su dugački tekstualni string-ovi ili binarni podaci poput slika); @OneToMany i odgovarajući @ManyToOne (koriste se kod referentnih tipova, i služe za definisanje poveznika, u ovom slučaju za vezu tipa jedan-prema-više); @ManyToMany (za definisanje veze tipa više-prema-više); @Inheritance (sa ovim se implementira IS_A hijerarhija u ER-modelu, a u objektno-orijentisanoj paradigmi se rešava pomoću nasleđivanja), itd. [Panda, Rahman & Lane 2007]

Za razliku od EJB 3, Naked Objects framework v4.0, barem u originalnom paketu, nema ovakvih anotacija. Kao što je već spomenuto, NOF v4.0 se isporučuje sa dva perzistora, in-memory i XML, pri čemu su oba automatizovana. Ovo znači da programer ne piše programski kod za perzistenciju, nego samo odabere željeni perzistor u nakedobjects.properties fajlu. Podrazumevani perzistor je in-memory, i služi za čuvanje podataka u memoriji računara. Ovo znači da će oni nestati čim se zatvori aplikacija, ali se može napraviti inicijalno skladište pomoću fikstura. Zapravo, ovaj perzistor se najčešće koristi u početnim fazama razvoja, kad se još baratanje pravom perzistencijom smatra suvišnim zadatkom. [Haywood 2009]

Posle neke tačke u razvoju, razvojni tim može doneti odluku da je došlo vreme da se pređe na pravu perzistenciju. Tada se preporučuje prelazak na XML perzistor koji čuva podatke na fajl sistemu u vidu XML fajlova, pa će podaci biti sačuvani čak i posle zatvaranja aplikacije. Baza se inače čuva unutar commandline potprojekta, u folder-u xml\objects. Prebacivanje ove baze na druge računare je jednostavno, budući da

124

zahteva samo prekopiranje ovih fajlova u odgovarajući folder drugog računara, a brisanje kompletne baze je još lakše, jer treba samo izbrisati objects folder na fajl sistemu. [Haywood 2009]

Postavlja se pitanje, šta se dešava sa fiksturama u slučaju da se koristi XML perzistor. Poznato je da se fiksture kod in-memory perzistencije izvršavaju svaki put pri startovanju aplikacije radi pohranjivanja (inicijalno uvek) praznog skladišta sa podacima. Međutim, kod XML perzistora je situacija drugačija, budući da se podaci ne brišu čak ni posle zatvaranja programa. Prema tome, u ovom slučaju, NOF radi sledeće: svaki put kad se pokrene aplikacija, proverava se da li XML baza postoji, pri čemu se izvršavanje fikstura preskoči ako ta baza postoji. Ovo pravilo efektno znači, da će se fiksture izvršavati samo prvi put nakon aktiviranja XML perzistora radi inicijalnog pohranjivanja baze sa podacima, a kod svakog sledećeg izvršavanja, one će se preskočiti. [Haywood 2009]

XML perzistor je takođe automatizovan, prema tome, sem jednog dodatnog reda u fajlu nakedobjects.properties, izvorni kod bi trebao da bude identičan kao i kod in-memory perzistora – u teoriji. [Haywood 2009] Međutim, kako se pokazalo, u praksi je situacija donekle složenija zbog prelaznih objekata. U odeljku 5.4 su bili spomenuti tzv. prelazni (eng. Transient) objekti. Oni predstavljaju nove objekte koji još nisu sačuvani. Čim su oni sačuvani, kaže se da je objekat sačuvan, perzistovan ili trajan (eng. Persisted).

Prethodno spomenut koncept trajnih i prelaznih objekata nije imao tako važnu ulogu kod in-memory perzistora, ali već kod XML skladištenja jeste. Neka se pretpostavi sledeći scenario: korisnik želi kreirati novi članak u aplikaciji, a budući da postoji veza između tipova entiteta članak i časopis, korisnik može ovaj novi članak povezati sa odgovarajućim časopisom. Prema tome, korisnik će potražiti željeni časopis i prevućiće ga u odgovarajuće polje u dijalogu za kreiranje novog članka, a na kraju će samo pritisnuti dugme za sačuvanje (tj. dugme Save). Postavlja se pitanje, šta je problem u ovom scenariju. Poenta je u tome da je gore spomenuti članak prelazni objekat sve dok se ne pritisne dugme Save nakon čega će objekat biti perzistovan. Problematični deo ovog scenarija je zapravo deo u kojem se članak (još uvek prelazni objekat) želi povezati sa časopisom (koji je trajni objekat). NOF bi ovo vezivanje hteo da uradi odmah čim korisnik prevuče časopis u odgovarajuće polje u entitetu članak. Kod in-memory perzistora ovo ne predstavlja problem, jer se nalazi u istom prostoru gde i aplikacija, znači u memoriji, i oba su pod ingerencijom NOF-a. Drugim rečima, oba objekta (i prelazni i trajni) su na istom mestu, i NOF ih poznaje.

Međutim, kod XML perzistora je situacija drugačija. Naime, u ovom slučaju, trajni, tj. perzistovani objekti se nalaze u drugom prostoru: u fajl sistemu u obliku XML fajlova. Čim korisnik prevuče časopis na članak, NOF će s jedne strane povezati ova dva objekta u samoj aplikaciji (da se to vidi u GUI-ju), a takođe će izdati naredbu za XML perzistor da ih i on poveže. Međutim, povezivanje kod XML perzistora neće uspeti: članak, budući da je još uvek prelazni, ne postoji u vidu XML fajla sve dok korisnik ne pritisne dugme za njegovo perzistovanje. A kad korisnik pritisne dugme Save, perzistovaće se članak koji će imati referencu na časopis, ali časopis neće imati referencu na članak. Drugim rečima, izgubio se referencijalni integritet. Najveći problem je taj da aplikacija nije prikazala nikakve greške, i prikazala je ove entitete onako kako treba (pošto ih je NOF pravilno povezao), ali kad se ona ponovo startovala,

125

pokazala je da je članak povezan sa časopisom, ali ne i da je časopis povezan sa člankom. Ručnim pregledom XML fajlova je već bilo jasno da ovi entiteti zaista nisu pravilno povezani. Autor je ovaj problem primetio kod rekurzivnog poveznika (kod kategorija), kad je NOF ispisao NakedObjectAssertException izuzetak (iz paketa org.nakedobjects.metamodel.commons.ensure) za prelazni objekat.

Problem je zapravo bio u implementaciji poveznika, tj. u obrascu uzajamne registracije. Rešenje se zasniva na ideji da ne treba obrascu dopustiti da poveže oba kraja veze. Znači, tada treba samo povezati prelazni objekat sa trajnim, a trajni objekat sa prelaznim treba povezati tek kad i prelazni objekat postane trajni, tj. kad korisnik klikne na dugme Save.

Rešenje se sastoji iz dva dela. U prvom koraku treba modifikovati obrazac uzajamne registracije za poveznik, tj. da se uspostavi veza samo u jednom pravcu: od prelaznog ka trajnom. Neka se posmatra veza između časopisa i članka. Budući da je veza tipa jedan-prema-više, poznato je iz 5.3.2 da se obrazac implementira samo kod roditelja, u ovom slučaju kod onog entiteta kod kojeg se nalazi kolekcija, a to je časopis, a drugi kraj veze (dete, tj. članak) samo delegira ka roditelju. Prema tome, sve potrebne modifikacije se rade u klasi Journal.java:public class Journal extends AbstractDomainObject { // nepotrebno izostavljeno // {{ Articles private Set<Article> articles = new LinkedHashSet<Article>(); @MemberOrder(sequence = "3") public Set<Article> getArticles() { return articles; }

public void setArticles(final Set<Article> articles) { this.articles = articles; } public void addToArticles(final Article article) { if (article == null || getArticles().contains(article)) { return; } // briši vezu sa starim roditeljem (časopisom), ako postoji article.clearJournal(); // poveži članak sa časopisom, ali samo ako je časopis perzistovan if (isPersistent(this) == true) { article.setJournal(this); // p1 } // poveži časopis sa člankom, ali samo ako je članak perzistovan if (isPersistent(article) == true) { getArticles().add(article); // p2 } onAddToArticles(article); }

public void removeFromArticles(final Article article) { // isto kao i ranije }

126

protected void onAddToArticles(final Article article) { }

protected void onRemoveFromArticles(final Article article) { } // }}}

Kao što se može videti, jedina razlika u odnosu na originalni obrazac naveden u 5.3.2 je ta da su dodate if klauzule za vezivanje. Potrebno je „čuvati“ obe naredbe (u izvornom kodu označene sa p1 i p2), jer se jedna odnosi na to kad korisnik napravi novi članak, a druga se odnosi na to kad se pravi novi časopis (tada se očekuje da će korisnik prevući članak u kolekciju kod časopisa). Poziv isPersistent(Object) se dobija iz pomoćne superklase, i proverava da li je prosleđen objekat trajan ili ne, pri čemu ako jeste, vraća true, inače false.

Kao što je već rečeno, drugi kraj veze (koji se nalazi u klasi Article), se ne menja, budući da samo delegira ka roditeljskom kraju.

U drugom koraku rešenja je potrebno uspostaviti i drugi smer veze, ali tek kad je prelazni objekat postao trajan. Da bi se ovo implementiralo, potrebno je uticati na životni vek (ili ciklus) objekata. U NOF-u postoje rezervisani metodi koji služe upravo za ovu svrhu. Oni su sledeći: [Haywood 2009]

• created() – prelazni objekat upravo kreiran;

• persisting() – prelazni objekat se želi perzistovati;

• persisted() – prelazni objekat se upravo perzistovao u skladište, i od sad je trajan;

• loading() – trajni objekat se želi učitati iz skladišta;

• loaded() – trajni objekat je upravo učitan;

• updating() – trajni objekat se želi modifikovati;

• updated() – trajni objekat je upravo modifikovan, i sve promene su sačuvane u skladištu;

• removing() – trajni objekat se želi izbrisati iz skladišta;

• removed() – objekat je izbrisan iz skladišta, i sad je prelazni.

Za potrebe rešenja treba koristiti metod persisted(). Pošto se ne zna unapred koji entitet (u ovom slučaju, časopis ili članak) će se kreirati, tj. koji će od njih biti prelazni, potrebno je metod persisted() ubaciti u obe klase. Metodi za životni ciklus objekata se pišu pomoću šablona nol (skraćenica od Naked Objects Lifecycle) koji će praviti oblast105 za ove metode, a zatim se unutar oblasti mogu koristiti sledeći šabloni zavisno od potreba: nolc (skraćenica od Naked Objects Lifecycle – Create), nolp (skraćenica od NOL – Persist), noll (NOL – Load), nolu (NOL – Update) i nolr (NOL – Remove). [Haywood 2009] U klasi Article.java će oblast za životni vek

105 Preporučuje se da se ova oblast kao i metodi unutar nje stave pri kraju klase.

127

izgledati na sledeći način:public class Article extends Publication { // nepotrebno izostavljeno

// {{ Metodi životnog ciklusa public void persisting() { // prazan metod, ne koristi se }

public void persisted() { super.persisted(); // potrebno je pozvati i metod nadlase // ako je članak bio prelazni objekat, poveži časopis sa člankom if (getJournal() != null) { getJournal().addToArticles(this); } } // }}}

Kao što se može videti, metod je vrlo jednostavan. Prvo treba pozvati persisted() metod i iz nadklase (Publication), budući da je potrebno članak povezati i sa odgovarajućim autorima i sa kategorijom. Zatim treba proveriti da li je članak povezan sa nekim časopisom (rađeno u prvom koraku rešenja). Ako jeste, onda je potrebno uraditi i obrnuto, tj. povezati časopis sa člankom. Ovo poslednje se samo svodi na poziv metoda addToArticles(…) koji će sad uspostaviti oba smera veze (budući da su sad oba entiteta trajna).

A na drugom kraju veze, u klasi Journal.java, je potrebno ubaciti sledeće:public class Journal extends AbstractDomainObject { // nepotrebno izostavljeno // {{ Metodi životnog ciklusa public void persisting() { // prazan metod, ne koristi se }

public void persisted() { // ako je časopis bio prelazni objekat, poveži sve njegove članke // sa časopisom for (Article articleToConnect : getArticles()) { if (articleToConnect.getJournal() == null) { articleToConnect.setJournal(this); // poveži articleToConnect.modifyJournal(this); // lažni poziv } } } // }}}

Znači, potrebno je preći kroz sve članke posmatranog časopisa, i za svaki od njih proveriti da li su povezani sa posmatranim časopisom. Ako je odgovor negativan, potrebno je pozvati metode setJournal(…) i modifyJournal(…). Pravo vezivanje se vrši pozivom setJournal(…), međutim, poznato je iz 5.3.2 da ukoliko se aktiviraju

128

pomoćni metodi za referencijalni tip (za klasu Article, reč je o metodima modifyJournal(…) i clearJournal()), NOF više ni ne razmatra prvobitne metode, i zbog toga se XML perzistor neće ni pozvati. Zato je potrebno pozvati i drugi metod, modifyJournal(…), koji zapravo neće raditi ništa korisno, ali će zato pozvati XML perzistor koji će update-ovati članke u XML bazi.106

Sa ovim je izlaganje rešenja završeno. Naravno, potrebno je rešenje implementirati kod svakog poveznika, ali njihova realizacija ide analogno.

Na kraju ovog odeljka se treba još kratko osvrnuti na neke druge perzistore koji postoje u okviru NOF-a. Naime, posle neke tačke u fazi razvoja softvera, tim može doneti odluku da je sistem dovoljno zreo da se XML baza zameni sa relacionom bazom podataka. NOF ima više relacionih perzistora. Jedan od njih je Hibernate perzistor, koji omogućava da se objekti unutar NOF-a perzistuju pomoću Hibernate-a. On se koristio u ranijim verzijama NOF-a, ali je NOF v4.0 predstavio novi, moćniji perzistor pod nazivom JPA Objects, ili samo JPA perzistor. Kako se može naslutiti iz imena, ovaj perzistor funkcioniše slično kao JPA unutar EJB 3, barem sa spolja. Ovo znači da će programeri imati na raspolaganju puno novih anotacija koje jako liče na JPA anotacije u okviru EJB 3, i pomoću kojih se zapravo konfiguriše ORM. Prema tome, od programera se očekuje da – slično kao i kod EJB 3 – markiraju klase, atribute, kolekcije i veze sa odgovarajućim atributima.107 Posle konfigurisanja ORM-a je potrebno izgenerisati šemu (postoji poseban launch fajl za ovu svrhu), pohraniti inicijalnu bazu sa fiksturama (po želji)108, i konačno, startovati Naked Objects aplikaciju.109

JPA Objects nije deo originalnog paketa NOF-a, nego je deo posebnog tzv. krovnog projekta pod nazivom Star Objects koji ima više potprojekta, pri čemu je JPA Objects samo jedan od njih.110 Prema tome, budući da je zapravo reč o plug-in-u, potrebno je povezati NOF sa ovom komponentom. Povezivanje se vrši pomoću Maven-a. Međutim, autor ovog rada nije nikako uspeo da integriše JPA perzistor u NOF.

106 Postavlja se pitanje, ako već metod setJournal(…) ne poziva XML perzistor, zašto ga je uopšte potrebno pozvati. Odgovor leži u činjenici da drugi metod, modifyJournal(…) zapravo neće ništa povezati. Naime, budući da ovaj metod samo delegira ka roditelju, tj. metodu addToArticles(…) u klasi Journal, ovaj metod će odmah uhvatiti „lažni“ poziv u if klauzuli (getArticles().contains(article)), i okončaće izvršavanje ostatka metoda. Zato je potrebno pozvati i prvi metod, setJournal(…).

107 U slučaju JPA perzistora je već potrebno da se definiše ID atribut. Može se još postaviti pitanje, šta raditi unutar sa klasama za fabriku i repozitoriju u kojima su definisani metodi za pretraživanje entiteta. Iako će ovi metodi i dalje raditi (sa pozivima allMatches(), firstMatch() i uniqueMatch() sa parametrom tipa Filter), oni neće biti efikasni, jer će vratiti sve torke iz relacione baze (umesto da se filtriranje vrši u relacionoj bazi). Prema tome, preporučuje se da se koriste odgovarajući overload-ovani metodi sa parametrom tipa Query, koji omogućava da se prosleđuju pravi upiti ka bazi. Što se tiče upita, oni se definišu isto kao i kod EJB 3, a kao upitni jezik, koristi se JPQL (skraćenica od Java Persistence Query Language). [Haywood 2009]

108 Što se tiče fikstura, JPA perzistor ih po default-u nikad neće izvršiti. Ovaj pristup se razlikuje od XML perzistora koji uvek izvršava fiksture ukoliko XML baza ne postoji. Kod JPA perzistora, ova funkcionalnost se mora posebno zvati. Zato postoji još jedan launch fajl pomoću kojeg se fiksture izvršavaju radi pohranjivanja prazne relacione baze. [Haywood 2009]

109 Vredi spomenuti da JPA Objects, iako koristi JPA anotacije, i način konfigurisanja ORM-a jako liči na onaj iz EJB 3 sveta, kao provajder koristi Hibernate. [Haywood 2009]

110 Zvanična stranica JPA Objects-a se nalazi na adresi <http://jpaobjects.sourceforge.net/m2-site/main/>.

129

Najverovatniji uzrok problema je nekompatibilnost JPA Objects-a sa Maven-om.111 Naime, poznato je da je NOF v4.0 nešto stariji, a isto to važi i za JPA perzistor. Međutim, ostali projekti potrebni za kreiranje Naked Objects projekata, kao što su Maven i m2e, su mnogo noviji. Prema tome, autor je doneo odluku da ne koristi JPA perzistor. S druge strane, i autori NOF-a su uočili ove probleme, i odlučili da sve potprojekte unutar Star Objects-a integrišu u Apache Isis. Ovo znači da će Isis imati i ugrađen JPA perzistor.112

6.4. Višeslojne arhitekture (peti put) – implementacija pubDB-aU odeljku 6.1 je već predstavljena globalna struktura obe verzije pubDB-a iz

ptičje perspektive. U ovom odeljku će se uporediti njihova unutrašnja implementacija, tj. izvorni kod: kako izgleda unutrašnjost jedne tipične četvoro-slojne arhitekture, i kako ista funkcionalnost izgleda u Naked Objects implementaciji (tj. u Domain-Driven Design-u). Ovde se mora spomenuti da su neka upoređivanja urađena i u [Pawson2004], kao i u [Keränen & Abrahamsson 2005a] i [Keränen & Abrahamsson 2005b], ali sa izvesnim razlikama (pogledati odeljak 1.2).

6.4.1.Poređenje kroz LOC metrikuPre svega, bilo bi zanimljivo pogledati veličinu pubDB-a u vidu LOC-a. LOC

(skraćenica od Lines of Code) označava broj linija izvornog koda, i predstavlja jedan od najkorišćenijih načina merenja softvera (postoji i posebna oblast softverskog inženjerstva pod nazivom softverske metrike). LOC naravno u zbir ne ubraja linije komentara, kao ni prazne linije (mada je ova metrika nezaštićena od gustine linija). Za merenje LOC-a, koristio se Eclipse Metrics plugin v1.3.8. Tabela 1 pokazuje rezultate merenja.

Kao što se može videti u tabeli, pubDB rađen u klasičnoj četvoro-slojnoj arhitekturi ima preko 5500 linija koda, dok Naked Objects verzija otprilike 1500, što znači da je manja od EJB 3 verzije za 72.5%. Što se tiče EJB 3 verzije, vidi se da najveći procenat, skoro 75%, iznosi prvi, prezentacioni sloj (4132 linija)113, a unutrašnji slojevi (aplikativni i perzistentni) imaju 1389 linija. Ovo je u skladu sa rezultatima iznetim u [Pawson 2004] i [Keränen & Abrahamsson 2005b], tj. da implementiranje aplikacije u Naked Objects pristupu donosi uštedu od 75% LOC-a u odnosu na tradicionalni razvoj, i da GUI aplikacije može zauzeti više od polovine izvornog koda.

111 JPA Objects nema arhetip unutar centralne repozitorije Maven-a, nego se mora preuzeti sa stare Star Objects repozitorije.

112 Takođe, JPA Objects će sa Hibernate-a najverovatnije preći na Apache OpenJPA. Izvor: <http://wiki.apache.org/incubator/IsisProposal>.

113 Naravno, legitimno je pitanje, zašto se uopšte meri veličina paketa test (u EJB 3 verziji), ako je poznato da se on koristio samo za testiranje komunikacije sa bazom podataka pre nego što je autor započeo implementaciju GUI-ja. Međutim, tada bi se moglo postaviti i pitanje zašto se meri podprojekat fixture (u Naked Objects verziji). Jednostavno, i paket test, i potprojekat fixture imaju svoju svrhu, ali se koriste relativno retko: test se koristio na početku razvoja, a fixture se koristi za pohranjivanje skladišta (ukoliko je prazno), pa se kod XML perzistora koristi jako retko. Budući da je njihova veličina relativno ista (320 i 456), doneta je odluka da se uključe u merenje.

130

EJB 3 verzija pubDB-a Naked Objects verzija pubDB-aBroj

paketaBroj klasa

Broj linija koda (LOC)

Broj paketa

Broj klasa

Broj linija koda (LOC)

Prez

enta

cion

i slo

j GU

I(g

ui)

1 10 3384

Med

ijato

r(a

genc

y)1 6 428

Pak

ette

st 1 1 320

Aplikativni sloj 1 15 931

Perz

iste

ntni

/ D

omen

ski s

loj

1 7 458

Dom

en(d

om)

5 12 1063

Fiks

ture

(fixt

ure)

6 39 456

Ukupno 5 39 5521 11 51 1519

Tabela 1: Broj paketa, klasa i linija koda (LOC) za EJB 3 i Naked Objects verziju pubDB-a

Naravno, može se postaviti pitanje, koliko bi porasla Naked Objects verzija ako bi se koristio JPA perzistor. Po proceni autora, kompletni LOC bi bio veći za otprilike 100 linija, budući da JPA anotacije s kojima se konfiguriše ORM u EJB 3 verziji zauzimaju otprilike 75 linija114. Pošto bi ovo donelo povećanje ukupnog LOC-a Naked Objects verzije za samo 6.5%, može se reći da je gore navedena tabela dovoljno reprezentativna.

Što se tiče dužine trajanja razvoja pubDB-a, implementacija EJB 3 verzije je trajala tačno mesec dana, a Naked Objects verzije otprilike dve nedelje. Od ukupnog vremena trajanja razvoja EJB 3 verzije, otprilike 75-80% vremena je bilo potrošeno na razvoj GUI-ja i na njegovo povezivanje sa aplikativnim slojem. Ovo na neki način potvrđuje izjave iz [Kennard & Leaney 2011] da ljudi troše previše vremena (barem polovinu ukupnog vremena) na razvoj korisničkog interfejsa, i potkrepljuje tvrdnje da je bilo koja pomoć pri razvoju GUI-ja dobrodošla. Ovde se mora isteći da je autor čak koristio i vizuelni alat za kreiranje GUI-ja koji je umnogome pojednostavio njegov razvoj, pa se može reći da bi bez ove pomoći vreme razvoja bilo još duže. Naravno, kreiranje prozora i dijaloga je jedno, a povezivanje njihovih Swing grafičkih elemenata sa donjim slojevima nešto sasvim drugo, budući da se ovo povezivanje radi uglavnom ručno. Takođe, programeri su često primorani da proširuju donje slojeve sa dodatnom funkcionalnošću samo zbog GUI-ja – one u striktnom smislu nisu potrebne za aplikaciju, nego za GUI. O ovom aspektu biće još reči nešto kasnije.

114 Bez upita za pretraživanje. Naime, kad bi se upiti dodali u Naked Objects verziju, postojeći način pretraživanja (sa Filter-om) bi se izbrisao. Ovo znači da bi LOC ostao otprilike na istom nivou.

131

Na osnovu prethodnog pasusa nije teško zaključiti, da se što se tiče težine implementacije, može sveukupno reći da je EJB 3 verzija pubDB-a bila nešto teža za implementaciju, ali je razvoj Naked Objects verzije bio neizvesniji. Naime, za razliku od EJB 3 (i Swing), Naked Objects framework još nije toliko rasprostranjen, pa ako se naiđe na bilo koji problem, postoji izvesna verovatnoća da će programeri morati sami da nađu rešenje.115 Takođe, činjenica da su svi ostali slojevi automatizovani ne znači automatski da ne treba o njima znati ništa: npr. razlike između DnD i HTML pogleda se mogu činiti malim, ali ove sitne razlike na kraju mogu igrati presudnu ulogu za izbor primarnog pogleda za posmatranu aplikaciju, budući da HTML pogled ima nešto manji procenat funkcionalnosti i koji može rezultovati čak i proširenjem modela domena (npr. HTML pogled nema mogućnost za brisanje asocijacija). Prema tome, dobro poznavanje celog NOF-a se toplo preporučuje za razvoj ozbiljnih aplikacija.

6.4.2.Poređenje kroz scenarijaDošlo je vreme da se pogleda unutrašnjost pubDB-a i da se na ovaj način poredi

način funkcionisanja klasične višeslojne arhitekture sa Naked Objects pristupom (tj. sa Domain-Driven Design-om). Međutim, umesto da se prekopira izvorni kod u rad, bilo bi bolje da se upoređivanje demonstrira na dinamičan način, tj. tokom izvršavanja ovih aplikacija. Za demonstraciju su izabrana tri konkretna scenarija: pretraživanje, brisanje i modifikovanje entiteta.

6.4.2.1. Prvi scenario (pretraživanje)Što se tiče prvog scenarija, neka se pretpostavi da korisnik želi pretražiti

publikacije po godini izdavanja. U EJB 3 verziji, ova aktivnost se mora inicirati iz dijaloga za pretraživanje (SearchDialog.java iz paketa gui unutar prezentacionog sloja). Neka se pretpostavi da je korisnik popunio dva potrebna tekstualna polja za početni i krajnji datum, i na kraju je pritisnuo dugme Search. Aplikacija bi sad trebala da pronađe sve publikacije (članke i knjige) koje su bile izdate u navedenom datumskom intervalu (npr. od 2005. do 2010. godine), a rezultat pretrage da prikaže u tabeli (Slika 27). Ispod haube, aplikacija zapravo radi sledeće:

1. Prvo, SearchDialog će proveriti da li su popunjena polja u dijalogu validna, znači, treba proveriti da li je uopšte reč o brojevima (budući da se traži upisivanje godine), i ako jeste, da li su pozitivni. Ovo se radi na sledeći način:// Paket gui, klasa SearchDialog.java (izvod)

try { Integer yearTo = null; if(textFieldToYear.getText().equals("")) { // u slučaju da yearTo = null; // krajnja godina } // nije navedena else { yearTo = Integer.valueOf(textFieldToYear.getText() .replace('-', 'n')); // ne prihvati negativne brojeve, } // namerno pretvori „–“ u neki znak, // da bi se generisao izuzetak

115 Ovo se desilo i sa autorom kad je naišao na problem sa perzistencijom u XML bazu. Više o problemu i o rešenju je bilo u odeljku 6.3.

132

resultList = Agent.findPublicationByYear(Integer .valueOf(textFieldFromYear.getText() .replace('-', 'n')), yearTo); } catch (NumberFormatException nfe) { // izuzetak JoptionPane.showMessageDialog(null, "Tekst poruke...", "Error", JOptionPane.ERROR_MESSAGE); return;}Može se videti da će program ispisati poruku o grešci u slučaju da korisnik nije pravilno ispunio polja (zapravo, generisaće se izuzetak). Ovo je već prvi slučaj rasipanja funkcionalnosti u druge slojeve, u ovom slučaju u GUI, o čemu upozorava i Pawson. [Pawson 2004] Jednostavno, validacija o negativnim brojevima je prešla u ovaj sloj, da se ne bi opteretio aplikativni. Ova odluka je za vreme razvoja EJB 3 verzije bila logična i očigledna.

2. U slučaju da je korisnik pravilno uneo godine u polja, pozvaće se metod findPublicationByYear(Integer, Integer) u klasi Agent.java (iz paketa agency unutar prezentacionog sloja). Ova klasa striktno rečeno ne pripada GUI-ju, nego igra ulogu medijatora između GUI-ja i drugog sloja. Metod izgleda na sledeći način:// Paket agency, klasa Agent.java (izvod)

public static List<Object[]> findPublicationByYear (Integer yearStart, Integer yearEnd) { Integer revisedYearEnd = yearEnd; if(yearEnd == null) { revisedYearEnd = yearStart; // oba datuma će biti identična } try { return PublicationSession.getPublicationManager() .findPublicationByYear(yearStart, revisedYearEnd); } catch (NamingException e) { e.printStackTrace(); return null; }}Ovaj metod ne radi ništa drugo sem što poziva istoimeni metod iz drugog, aplikativnog sloja. Međutim, kao što se može videti, deo funkcionalnosti je uspeo da pobegne čak i u ovu klasu, potvrdivši izjavu Cockburn-a da je opasnost daljeg rasipanja poslovne logike realna. [Cockburn 2005] Naime, ako korisnik nije uneo krajnji datum za pretragu, aplikacija će pretpostaviti da korisnik želi vratiti samo publikacije izdate u nekoj određenoj godini (navedena u polju from), pa će prekopirati sadržaj prvog polja u drugo.116

3. U slučaju da je sve u redu, pozvaće se metod findPublicationByYear(Integer, Integer) iz session bean-a (tj. klase) PublicationManager iz paketa buslogic koji se već nalazi u drugom,

116 Klasa PublicationSession je pomoćna klasa u paketu agency, i ima samo jedan metod koji služi za pribavljanje reference na session bean PublicationManager iz drugog, aplikativnog sloja, preko daljinskog interfejsa. Pribavljanje reference može generisati NamingException izuzetak ukoliko ne može da ga nađe, zato se celi poziv mora ograditi try/catch blokom.

133

aplikativnom sloju. Metod izgleda na sledeći način:117

@Stateless(mappedName = "publicationManager")public class PublicationManager implements PublicationManagerRemote, PublicationManagerLocal { @PersistenceContext protected EntityManager em; // nepotrebno izostavljeno

public List<Object[]> findPublicationByYear(Integer yearStart, Integer yearEnd) { Query query = em.createNamedQuery("findPublicationByYear"); query.setParameter("yearStart", yearStart.intValue()); query.setParameter("yearEnd", yearEnd.intValue()); List list = query.getResultList(); List<Object[]> pubList = populateListWithPublicationsFound(list); return pubList; }

private List<Object[]> populateListWithPublicationsFound(List list) { List<Object[]> pubList = new ArrayList<Object[]>(); Iterator<Publication> it = list.iterator(); Publication publication; while(it.hasNext()) { publication = it.next(); if(publication instanceof Article) { // ova pub. je članak // dodaj ovog članka u pubList... } else if(publication instanceof Book) {//ova pub. je knjiga // dodaj ovu knjigu u pubList... } } return pubList; }}Kao što se može videti, ova klasa zapravo sadrži ponašanje tj. poslovnu logiku entiteta Publication (kao i njegovih podklasa Article i Book), i ima metode (tj. akcije) kao što su dodavanje, modifikovanje i brisanje publikacija. Naravno, i svi načini pretraživanja imaju svoj metod, tako je npr. pretraživanje po godini izdavanja implementirano u metodu findPublicationByYear(…). Svi ovi metodi su javni (tj. public), ali postoje i pomoćni metodi koji su privatni.

Što se tiče metoda za pretraživanje, on je zapravo veoma prost, i predstavlja tipičan način pretraživanja u EJB 3.118 Rezultati će se čuvati u običnoj listi.

117 Session bean-ovi se u EJB 3 označavaju anotacijom @Stateless ili @Stateful, zavisno od toga, da li se želi sačuvati stanje bean-a između poziva njegovih metoda.Što se tiče globalnog polja em, on je tipa EntityManager. Naime, pre nego što se poziva bilo koja operacija vezana za perzistenciju, potrebno je imati jednu instancu EntityManager-a. On je takođe markiran anotacijom @PersistenceContext koji olakšava baratanje sa EntityManager-om.

118 Prvo treba napraviti upit (tipa Query) koji će biti prosleđen bazi podataka. Upit se u ovom slučaju zove findPublicationByYear, i definisan je unutar entiteta Publication. Zatim treba parametre upita zameniti pravim vrednostima, i konačno, upit se može izvršiti pozivom getResultList().

134

Međutim, dobijena lista se mora modifikovati tako da odgovara potrebama GUI-ja. Zato se poziva i jedan privatni metod iz ove klase, populateListWithPublicationsFound(List). Svrha ovog metoda je da napravi odgovarajuću listu publikacija koja je razumljiva od strane GUI-ja. No ono što je zanimljivo u vezi ovog metoda je provera pojedinačnih publikacija pomoću operatora instanceof, tj. da li je posmatrana publikacija članak ili knjiga, pošto popunjavanje liste zavisi od tipa publikacije. Ovakve provere su zapravo vrlo česte u klasičnim višeslojnim arhitekturama, budući da u slučaju da se posmatrana funkcionalnost definiše van entiteta kojem inače pripada, nema drugog načina da se proveri tip entiteta, nego da se koristi instanceof. Međutim, ovakav stil implementiranja donosi sa sobom još jednu posledicu – grananja. Kao što se može videti u prethodno navedenom izvornom kodu, pomoću if naredbe su se kreirale dve grane: jedna za članak i jedna za knjigu. Međutim, u slučaju kada bi model bio veći, cela klasa bi bila puna sa masivnim if (ili switch-case) granama.

4. Metod findPublicationByYear(…) tokom izvršavanja kontaktira i entitete Publication, Article i Book, koji se nalaze u paketu persistence unutar trećeg, perzistentnog sloja, pa bi bilo zanimljivo pogledati i barem jedan od tih entiteta. Sledeći izvorni kod pokazuje entitet Publication.java:119

@Entity@Table(name="PUBLICATION")@Inheritance(strategy=InheritanceType.JOINED)@DiscriminatorColumn(name = "PUB_TYPE", discriminatorType = STRING, length = 1)@NamedQueries({ @NamedQuery(name = "findPublicationByYear", query = "SELECT p FROM Publication p WHERE p.yearPub BETWEEN :yearStart AND :yearEnd"), // još neki upiti... })public abstract class Publication implements Serializable { @Id @GeneratedValue @Column(name = "PUB_ID") private int idPub; @Column(name = "PUB_TITLE") private String titlePub; @Column(name = "PUB_YEAR") private int yearPub; @Column(name = "PUB_DESC")

119 U EJB 3 (i JPA) entiteti se označavaju anotacijom @Entity. Ostalim anotacijama se zapravo konfiguriše ORM: definiše se naziv tabele u relacionoj bazi podataka (sa @Table), definiše se nasleđivanje sa podklasama Article i Book (pomoću @Inheritance i @DiscriminatorColumn), definišu se upiti (sa @NamedQuery se mogu definisati imenovani upiti pisani u JPQL), itd.. Kao što se može videti, upit pod imenom findPublicationByYear je zapravo upit koji se poziva iz metoda findPublicationByYear(…) u klasi PublicationManager. Naravno i atributi unutar entiteta imaju svoje anotacije.

135

@Lob @Basic(fetch = LAZY) private String desc; @ManyToMany(mappedBy = "publications", cascade = MERGE) private Set<Author> authors; @ManyToOne(cascade = MERGE) @JoinColumn(name = "PUBLICATION_CAT_ID", referencedColumnName = "CAT_ID") private Category category; private static final long serialVersionUID = 1L; public Publication() { super(); }

public int getIdPub() { return this.idPub; }

public void setIdPub(int idPub) { this.idPub = idPub; }

// getter-i i setter-i za atribute titlePub, yearPub, desc, // category

public Set<Author> getAuthors() { return authors; }

public void setAuthors(Set<Author> authors) { this.authors = authors; }

public void addAuthor(Author author) { // pomoćni metod za if(authors == null) { // autora authors = new HashSet<Author>(); } authors.add(author); }}Bez upuštanja u detalje, ova klasa zapravo predstavlja kompletan entitet, i sastoji se samo od atributa i kolekcija (kao i od njihovih getter-a i setter-a). Njima se definiše stanje ovog objekta, a ponašanje se definisalo u aplikativnom sloju unutar session bean-ova, i pomalo u prezentacionom sloju.

5. Konačno, kad je lista rezultata pretraživanja u pomoćnom metodu populateListWithPublicationsFound(…) u session bean-u normalizovana (tako da odgovara potrebama GUI-ja), vraća se sve do najvišeg, prezentacionog sloja, tj. nazad do klase SearchDialog.java, koja će napraviti tabelu sa dobijenim rezultatima.

136

Sad će isti scenario biti predstavljen i u Naked Objects verziji pubDB-a. Da bi korisnik mogao da pretražuje publikacije po godini izdavanja, dovoljno je sa desktopa (tj. glavnog prozora) kliknuti desnim tasterom na ikonicu Publications, i iz iskačućeg menija izabrati akciju Search By Year. Pojaviće se mali dijalog sa dva tekstualna polja, u kojima se – slično kao i kod EJB 3 verzije – mogu navesti početni i krajnji datum za pretraživanje. Klikom na dugme OK, aplikacija će pretražiti skladište, a rezultate pretrage će pokazati u novom dijalogu. Iza scene, aplikacija zapravo radi sledeće:

1. Poziva se metod searchByYear(String, String) iz klase PublicationRepository.java. Kao što je poznato iz odeljka 5.4, ova klasa je zapravo klasa za fabriku i repozitoriju (i u OOUI-ju se prikazuje u obliku ikonice), i sadrži metode (tj. akcije) vezane za publikacije: dodavanje novog članka (ili knjige), kao i pretraživanje istih. Svi ovi metodi su dostupni iz iskačućeg menija (desni klik na ikonicu). Metod za pretraživanje po godini izdavanja izgleda na sledeći način:public class PublicationRepository extends AbstractFactoryAndRepository { // metodi (akcije) za dodavanje novog članka/knjige, kao i za // njihovo pretraživanje

// {{ SearchPublicationByYear @MemberOrder(sequence = "5") public List<Publication> searchByYear( @Named("From") @RegEx(validation = "[12][0-9]+") @MaxLength(value = 4) final String from, @Named("To") @Optional @RegEx(validation = "[12][0-9]+") @MaxLength(value = 4) final String to) { final int fromYear = Integer.parseInt(from); final int toYear = ((to == null) ? fromYear : Integer.parseInt(to)); return allMatches(Publication.class, new Filter<Publication>() { public boolean accept(final Publication publication) { return (fromYear <= publication.getYear() && publication.getYear() <= toYear); }

}); } // }}}Kao što se može videti, funkcionalnost ovog metoda na neki način liči na onu iz EJB 3 verzije. Tako je na primer pre izvršavanja pretrage potrebno uraditi validaciju tekstualnih polja. Ovo se radi pomoću anotacija @MaxLength (određuje maksimalnu „dužinu“ polja) i @RegEx (definiše regularni izraz)120. Slično kao i kod EJB 3 verzije, u slučaju da korisnik drugo polje (krajnji datum) ostavi prazno, aplikacija će vrednost prvog polja prekopirati u drugo polje. Konačno, poziva se allMatches(…) iz NOF-a sa parametrom tipa Filter koji

120 Regularni izraz „[12][0-9]+” znači sledeće: prvi karakter mora biti cifra 1 ili 2, a preostali karakteri mogu biti bilo koje cifre.

137

će raditi filtriranje rezultata.121

2. Tokom pretraživanja, allMatches(…) referencira klasu Publication.java. Radi poređenja, bilo bi zanimljivo nakratko pogledati implementaciju ove klase:public abstract class Publication extends AbstractDomainObject { public String title() { // naslov ovog objekta (proširenje ID-a) }

// {{ Title private String title; @MemberOrder(sequence = "1") @MaxLength(255) public String getTitle() { return title; }

public void setTitle(final String title) { this.title = title; } // }}

// atribut year (plus getter i setter)

// skalarna asocijacija category kao i implementacija obrasca // uzajamne registracije (delegiranje ka roditelju): // modifyCategory i clearCategory

// vektorska asocijacija (tj. kolekcija) Authors, kao i // implementacija obrasca uzajamne registracije (delegiranje // ka roditelju): addToAuthors i removeFromAuthors // atribut description (plus getter i setter) // {{ Metodi životnog ciklusa public void persisted() { // potrebno za XML perzistor } // }}}Kao što se može videti, ova klasa se sastoji od svog naslova (metod title()), od nekoliko atributa poput naziva publikacije i godine izdavanja, od poveznika sa drugim tipovima entiteta (kategorija i autori), i konačno, od jednog metoda za životni ciklus entiteta (persisted()), pri čemu su svi ovi odeljci opcioni.

121 Za definisanje Filter-a je potrebno implementirati metod accept(Object), koji vraća vrednost true za sve publikacije koje zadovoljavaju naveden kriterijum. Ovaj kriterijum, kao što se može videti, je efektno isti kao i imenovani upit findPublicationByYear u EJB 3 verziji (pisan u JPQL).

138

Takođe, entitet može imati i akcije, ali ih klasa Publication nema.122

3. Konačno, kad je allMatches(…) završio pretragu, rezultate će staviti u listu, koja zajedno predstavlja i rezultat celog metoda searchByYear(…). NOF će ovu listu prikazati u vidu novog dijaloga u GUI-ju.

6.4.2.2. Drugi scenario (brisanje)Što se tiče drugog scenarija (brisanje entiteta), neka se pretpostavi da korisnik

želi obrisati neki članak iz baze podataka. U EJB 3 verziji, ova aktivnost se može izvršiti samo iz dijaloga za pretraživanje (SearchDialog). Pre nego što se može bilo šta obrisati, potrebno je uraditi neko pretraživanje u dijalogu, i sačekati da aplikacija popuni tabelu sa rezultatima. Zatim korisnik treba da klikne na neki red iz tabele (koji predstavlja neki entitet), i konačno, da klikne na dugme Delete. Tada će aplikacija uraditi sledeće:

1. U klasi SearchDialog.java će se proveriti da li je selektovan entitet publikacija (tj. članak ili knjiga) ili neki drugi tip entiteta (npr. autor, kategorija, itd.). Ovo je važno, pošto se brisanje u EJB 3 verziji radi destruktivno, pa u slučaju da korisnik želi obrisati nešto što nije publikacija, aplikacija će izbrisati i sve publikacije koje se vezuju za izabrani entitet (ukoliko postoje). U tom slučaju će se prvo izbrisati te publikacije, i tek na kraju izabrani entitet. Budući da se u ovom scenariju želi brisati članak, pubDB može odmah da pređe na njegovo brisanje. Brisanje članka je zapravo implementirano u jednom redu:Agent.deleteArticle((Integer) defaultTableModel .getValueAt(selectedRow, 0));Ovaj red izvornog koda zapravo poziva metod deleteArticle(int) iz klase Agent.java sa ID brojem članka kao parametrom (ID broj entiteta se inače čuva u prvoj koloni tabele).

2. Metod deleteArticle(int) iz klase Agent je veoma jednostavan, budući da samo poziva odgovarajući metod iz drugog, aplikativnog sloja:// Paket agency, klasa Agent.java (izvod)

public static void deleteArticle(int idArticle) { try { PublicationSession.getPublicationManager() .deleteArticle(idArticle); } catch (NamingException e) { e.printStackTrace(); }}

3. Metod deleteArticle(int) iz klase PublicationManager.java (u paketu buslogic) je zaslužan za brisanje članaka iz baze podataka:123

122 Jedna takva klasa će biti prikazana pri opisu drugog scenarija. Takođe, neki delovi klase Publication će se detaljnije pokazati pri opisu trećeg scenarija.

123 Metodi find(…) i getReference(…) služe za pretraživanje entiteta iz baze pomoću jedinstvenog ID-a tog entiteta. Budući da se prosleđuje samo ID entiteta, oba poziva će vratiti najviše jedan rezultat. Jedina razlika između njih je da metod find(…) vraća i učitava celi entitet, dok getReference(…) samo vraća referencu na pronađen entitet, koji će se učitati tek kad je to potrebno. Zbog ovog lenjog učitavanja, drugi metod se smatra bržim.

139

// Paket buslogic, klasa PublicationManager.java (izvod)

public void deleteArticle(int idArticle) { Article article = em.find(Article.class, idArticle); // prvo briši vezu sa kategorijom Category category = em.getReference(Category.class, article.getCategory().getIdCat()); category.getPublications().remove(article); article.setCategory(null); // zatim briši vezu sa časopisom Journal journal = em.getReference(Journal.class, article.getJournal().getIdJournal()); journal.getArticles().remove(article); article.setJournal(null); // na kraju briši veze i sa autorima for(Author author : article.getAuthors()) { author.getPublications().remove(article); } article.getAuthors().clear();

// konačno, briši članak iz baze em.remove(em.merge(article));}Kao što se može videti, ovaj metod prvo mora pronaći posmatrani članak (pomoću ID-a članka). Zatim treba da obriše sve veze sa drugim tipovima entiteta (sa kategorijom, časopisom i sa autorima), a ovo se vrši pozivom odgovarajućih getter-a i setter-a iz entiteta. Podrazumeva se da se oba smera veze moraju brisati. Konačno, da bi se izbrisao članak iz baze, treba pozvati remove(…) iz EntityManager-a.124

4. Posle brisanja, tok kontrole se vraća nazad do GUI-ja, u klasu SearchDialog, koji će osvežiti sadržaj tabele (zapravo ponovo će se izvršiti poslednji upit), tako da se izbrisan članak više neće pojaviti u njoj.

Neka se posmatra isti scenario kod Naked Objects verzije pubDB-a. Kod ove verzije ne postoji određeno mesto za brisanje članka (kao kod EJB 3 verzije). Umesto toga, dovoljno je samo da posmatrani članak bude vidljiv na ekranu. Tada desnim klikom treba pozvati iskačući meni, i iz menija samo izabrati akciju Delete Article. Ispod haube, NOF će zapravo pozvati samo jedan metod iz klase Article.java, a to je deleteArticle():public class Article extends Publication { // {{ DOI private String doi; // plus getter i setter

124 Pre brisanja je potrebno update-ovati i ostale entitete sa kojima je članak (bio) u vezi, a to se radi pomoću poziva merge(…). Budući da je kaskadno update-ovanje uključeno za veze u klasama Article (kao i u Publication), dovoljno je ovaj metod pozvati samo za članak.

140

// {{ Journal private Journal journal; // plus getter i setter, kao i implementacija obrasca uzajamne // registracije (delegiranje ka roditelju): // modifyJournal i clearJournal // {{ deleteArticle @MemberOrder(sequence = "1") public void deleteArticle() { // prvo napraviti kopije autora u vidu niza, da se ne bi // desio ConcurrentModificationException (odeljak 5.3.4) Author[] authorsToDelete = getAuthors().toArray(new Author[0]); // briši veze sa autorima for (Author author : authorsToDelete) { removeFromAuthors(author); }

// briši vezu sa kategorijom clearCategory();

// briši vezu sa časopisom clearJournal();

// konačno, obriši ovog članka iz skladišta remove(this); } // }}

// metodi za životni ciklus ovog entiteta}

Kao što je poznato, entitet Article nasleđuje klasu Publication, pa i sve njene atribute i kolekcije. Pored njih, ovaj entitet ima i jedan specifični atribut (DOI), a definiše i jednu vezu prema tipu entiteta časopis.

Međutim, kao što se može videti, entitet Article implementira i poslovnu logiku sopstvenog brisanja u vidu akcije deleteArticle(). Ovaj metod dosta liči na onaj iz EJB 3 verzije: prvo se brišu veze sa drugim tipovima entiteta (sa autorima, sa kategorijom i sa časopisom), a zatim se obriše članak iz skladišta. Međutim, ono po čemu se oni razlikuju je da metod iz Naked Objects verzije ne mora da brine o brisanju oba smera veze. Naime, njihovo ažuriranje je implementirano u samim entitetima u vidu obrasca uzajamne registracije. Zato je ovaj metod kraći i jednostavniji u odnosu na EJB 3 verziju.

6.4.2.3. Treći scenario (modifikovanje)Konačno, za treći scenario je izabrano modifikovanje entiteta. Neka se

pretpostavi da korisnik želi modifikovati neki članak. U EJB 3 verziji pubDB-a, pregledanje i modifikovanje članaka i knjiga je moguće samo iz dijaloga za pretraživanje. Prema tome, slično kao i kod drugog scenarija, korisnik prvo mora pretražiti bazu podataka za traženim člankom, sačekati da se popuni tabela sa

141

rezultatima, kliknuti na članak (tj. red) iz tabele, i zatim pritisnuti dugme View. Pojaviće se dijalog za pregledanje izabranog članka. Ovde korisnik može pregledati njegove atribute kao i veze sa drugim tipovima entiteta (autorima, kategorijom i časopisom). Naravno, korisnik može bilo koji od ovih atributa ili veza i promeniti. Tada treba kliknuti na dugme Update koje će snimiti sve izmene, a zatim će se korisnik vratiti na prethodni dijalog (pretraživanje). Iza scene se dešavaju sledeće aktivnosti:

1. U klasi SearchDialog.java će se samo kreirati novi dijalog za izabran članak sa ID-om članka kao parametrom. Prosleđivanje ID-a umesto null vrednosti će dijalog pozvati u tzv. view/update režimu (pregledanje/modifikovanje):ArticleDialog ard = new ArticleDialog((Integer) defaultTableModel .getValueAt(selectedRow, 0));

2. U view/update režimu, ArticleDialog.java treba da popuni sva polja dijaloga, znači potrebno je učitati izabrani članak sa njegovim atributima i vezama. Međutim, pre toga je potrebno popuniti Swing liste dijaloga sa svim autorima i časopisima. Popunjavanje liste sa autorima se radi sledećim pozivom:List<Object[]> authorList = Agent.populateAuthorList();// pa napravi iterator, i popuni Swing listu sa autorima // iz authorListKao što se može videti, sve se svodi na poziv odgovarajućeg metoda iz klase Agent.

3. Metod populateAuthorList() ne radi ništa posebno sem pozivanja istoimenog metoda iz drugog, aplikativnog sloja:// Paket agency, klasa Agent.java (izvod)

public static List<Object[]> populateAuthorList() { try { return AuthorSession.getAuthorManager() .populateAuthorList(); } catch (NamingException e) { e.printStackTrace(); return null; }}

4. Metod populateAuthorList() iz klase AuthorManager u paketu buslogic predstavlja tipičan slučaj „opterećenja“ aplikacije sa funkcionalnošću koja se striktno tiče samo GUI-ja:// Paket buslogic, klasa AuthorManager.java (izvod)

public List<Object[]> populateAuthorList() { Query query = em.createNamedQuery("findAllAuthors"); List list = query.getResultList(); List<Object[]> authorList = new ArrayList<Object[]>(); Iterator<Author> it = list.iterator(); while(it.hasNext()) { // dodaj ovog autora u authorList... } return authorList;}

142

Ovaj metod treba da vrati sve autore iz baze podataka. Nakon što se učitaju svi autori, oni se smeštaju u listu koja je razumljiva GUI-ju, i zatim se lista vraća nazad do klase ArticleDialog koja će sve ove autore staviti u svoju Swing listu.

5. Pošto je Swing lista za autore popunjena, treba ovo uraditi i za Swing listu sa časopisima. Prvo se pravi poziv ka odgovarajućem metodu klase Agent:List<Object[]> journalList = Agent.populateJournalComboBox();

6. Zatim metod populateJournalComboBox() iz klase Agent.java samo poziva istoimeni metod iz klase JournalManager, u paketu buslogic (aplikativni sloj).

7. Metod populateJournalComboBox() klase JournalManager izgleda i radi analogno kao i populateAuthorList() iz klase AuthorManager. Znači, metod vraća sve časopise iz baze, smešta ih u listu koja odgovara GUI-ju, a zatim se lista vraća nazad sve do klase ArticleDialog, koji će sve časopise staviti u svoju Swing listu.125

8. Konačno, treba polja dijaloga popuniti sa podacima izabranog članka. Budući da dijalog poznaje samo ID broj članka, potrebno je prvo ovaj članak učitati iz baze. Prema tome, ArticleDialog će prvo učitati izabrani članak iz baze pomoću svog ID broja, a zatim će popuniti sva polja dijaloga sa vrednostima atributa, a selektovaće i odgovarajuće autore kao i časopis u Swing listama sa kojima je članak povezan:// Paket gui, klasa ArticleDialog.java (izvod)

List<String> articleData = Agent.retrieveArticle(idArticle.intValue());Iterator<String> it = articleData.iterator();textFieldTitle.setText(it.next());// popuni ostala polja

// selektuj časopis iz Swing liste sa kojim je članak povezan

// selektuj autore iz Swing liste sa kojima je članak povezan9. Metod retrieveArticle(int) iz klase Agent samo poziva istoimeni metod iz

aplikativnog sloja.

10. Metod retrieveArticle(int) iz klase PublicationManager.java u paketu buslogic (aplikativni sloj) je još jedan metod za potrebe GUI-ja. On učitava članak iz baze (pomoću prosleđenog ID broja), kreira jednu listu string-ova koju popunjava sa podacima iz učitanog članka, a zatim ovu listu vraća nazad klasi ArticleDialog.

11. Budući da su sve pre-aktivnosti završene, otvoriće se napokon dijalog za pregledanje (i modifikovanje) izabranog članka. Korisnik može menjati vrednosti polja, a ako želi, može da briše stare i definiše nove veze sa drugim entitetima (autorima, časopisom i kategorijom). Kad korisnik klikne na dugme Update, aplikacija će zapravo prvo uraditi seriju provera: da li su obavezna polja

125 Kategorije ne treba posebno učitati, budući da dijalog za članak nema takvu listu. Umesto toga, korisnik mora iz ovog dijaloga da klikne na dugme Select, koje će otvoriti jedan novi dijalog sa Swing stablom koje će već sadržati sve kategorije.

143

(u ovom slučaju naslov članka i godina izdavanja) popunjena, i da li je korisnik povezao članak sa ostalim tipovima entiteta (kategorijom, časopisom kao i autorima). Ako je validacija uspešno prošla, dijalog će pokupiti vrednosti polja kao i veze, i pozvaće metod updateArticle(…) iz klase Agent.

12. Metod updateArticle(…) će samo pozvati istoimeni metod iz aplikativnog sloja.

13. Metod updateArticle(…) iz klase PublicationManager.java u paketu buslogic (aplikativni sloj) služi za modifikovanje postojećeg članka u bazi, i izgleda na sledeći način:// Paket buslogic, klasa PublicationManager.java (izvod)

public void updateArticle(int idArticle, String title, int year, String desc, String doi, String category, Integer idJournal, List<Integer> authors) { Article article = em.find(Article.class, idArticle); article.setTitlePub(title); // postavi ostale atribute (year, description, doi)

// menjaj kategoriju samo ako ju je korisnik promenio if(category != null) { Category categoryOld = em.getReference(Category.class, article.getCategory().getIdCat()); categoryOld.getPublications().remove(article); article.setCategory(null); Category categoryNew = (Category)em.createNamedQuery("findCategoryByLabel") .setParameter("categoryLabel",category).getSingleResult(); categoryNew.addPublication(article); article.setCategory(categoryNew); }

// menjaj časopis samo ako ga je korisnik promenio if(idJournal != null) { // slično kao i kod kategorije }

// menjaj autore samo ako ih je korisnik promenio if(authors != null) { // slično kao i kod kategorije, ali budući da je reč o // kolekciji, prvo briši veze za sve autore, a zatim dodaj // nove autore, jedan po jedan }

em.merge(article); // snimi promene u bazu}Kao što se može videti, metod prvo treba da učita posmatrani članak iz baze, a zatim da postavi vrednosti atributa (pozivom setter-a). Dalje, treba ažurirati veze sa kategorijom, časopisom, kao i sa autorima, ali samo ako ih je korisnik promenio (sa ovim se izvršavanje može malo ubrzati). Ovo ažuriranje efektno radi na sledeći način: prvo se učitava stara kategorija (ili časopis ili autori) sa kojom je članak povezan, i brišu se veze sa tim entitetom (naravno oba smera veze), a zatim se učitava nova kategorija (ili časopis ili autori) sa kojom sad korisnik želi povezati članak, i poveže se sa člankom (u oba smera). Konačno,

144

kad su sve veze ažurirane, treba ove promene sačuvati u bazi, što se postiže pozivom merge(…).

14. Budući da je modifikovanje članka završeno, tok kontrole se vraća nazad ka klasi ArticleDialog, koja će se samo zatvoriti, i vratiće kontrolu u klasu SearchDialog, koja će još morati ažurirati tabelu sa rezultatima (slično kao i kod operacije brisanja) da bi i tabela prikazala promene.

Neka se sad posmatra isti ovaj scenario kod Naked Objects verzije pubDB-a. Slično, kao i kod brisanja, ne postoji određeno mesto sa kojeg se može pozvati ova funkcionalnost. Umesto toga, važno je samo da korisnik vidi na ekranu onaj članak koji želi pogledati (ili modifikovati). Da bi se otvorio dijalog za modifikovanje, potrebno je uraditi dupli-klik na tom članku. U ovom dijalogu korisnik može menjati sva polja i može definisati nove veze, a da bi se izmene sačuvale, dovoljno je da samo zatvori dijalog.

Međutim, u Naked Objects verziji pubDB-a ne postoji eksplicitno mesto u kojem se definiše funkcionalnost modifikovanja entiteta, barem ne u sloju domena (tj. u dom potprojektu). Ova funkcionalnost se zapravo dobija automatski od NOF-a. Naime, u NOF-u su svi entiteti zapravo direktno preslikani u OOUI, prema tome, dijalog za modifikovanje entiteta koji se otvara duplim klikom, je zapravo slika tog entiteta.

Naravno, provera ispravnosti podataka entiteta (tj. validacija) postoji i u ovom dijalogu, i definisana je zapravo u samoj klasi entiteta. Validacija se može uključiti za sve atribute, i u slučaju članka, takva validacija se radi npr. kod godine izdavanja, koja se nasleđuje iz nadklase Publication. Budući da je implementacija ove klase već predstavljena kod opisa prvog scenarija, sad će se samo pokazati kako je atribut year implementiran:// Potprojekat dom, klasa Publication.java (izvod)

// {{ Yearprivate int year;@MaxLength(4)@MemberOrder(sequence = "2")public int getYear() { return year;}

public void setYear(final int year) { this.year = year;} public int defaultYear() { return 1970;} public String validateYear(final int year) { String validateYearErrorMessage = "Poruka o grešci."; if(year >= 1000 && year < 2013) return null; else return validateYearErrorMessage;

145

}// }}Kao što se može videti, atribut year je validan, ako upisan broj ima maksimalno četiri cifre (@MaxLenght(4)) i kad se nalazi između 1000 i 2013. Ovo poslednje se radi u rezervisanom metodu validateXxx(…), pri čemu je Xxx naziv atributa (u ovom slučaju, Year). Takođe, budući da atribut nije markiran anotacijom @Optional, to znači da je popunjavanje polja obavezno. Atribut ima i podrazumevanu vrednost, 1970, koja se postavlja u rezervisanom metodu defaultXxx(), gde je Xxx naziv atributa.

Pravilno vezivanje entiteta (u ovom slučaju, članka) je takođe rešeno, budući da entiteti imaju implementiran obrazac uzajamne registracije koji će postaviti (ili brisati) veze u oba smera. Prema tome, može se reći da je ovaj scenario kod Naked Objects verzije najlakši, dok je kod EJB 3 verzije bio najteži, i zahtevao je jako puno skakanja između slojeva.

6.4.3.DiskusijaSve u svemu, kad se rezimiraju utisci stečeni sa predstavljanjem ova tri

scenarija, jasno je da postoje određene razlike između višeslojnih arhitektura i Naked Objects (tj. Domain-Driven Design) pristupa. O teorijskim razlikama se već pričalo par puta, a ovde su ove razlike bile demonstrirane i tokom izvršavanja. Sad je već jasno, zašto je aplikativni sloj srce softvera kod višeslojnih arhitektura, i zašto je to domenski sloj kod Domain-Driven Design-a. Jednostavno rečeno, kod višeslojneih arhitektura je najvažniji sloj aplikativni, zato što se većina funkcionalnosti nalazi upravo tamo. Međutim, sva ta funkcionalnost je kod DDD-a prebačena u treći, domenski sloj.

Tokom prethodnih izlaganja, bili su navedeni razni izrazi. Pawson je objekte klasifikovao na behavioralno-kompletne i behavioralno-slabe, u zavisnosti da li je ponašanje enkapsulirano u objektima ili nije. [Pawson 2004] Evans je naglasio da je model domena najvažniji deo softvera koji se nalazi u domenskom sloju, ali da se to ne može postići rasipanjem funkcionalnosti na sve strane. [Evans 2003] Pawson je naveo nekoliko razloga (kao što su slučajevi korišćenja i UCC obrazac) koji su ubrzali tendenciju rasipanja funkcionalnosti i razbijanja objekata na stanje i ponašanje, ali je Martin Fowler dao naziv i za krajnji ishod ovakvog rasipanja i razbijanja: anemičan model domena (eng. Anemic Domain Model). Smatrajući da je reč o tzv. anti-obrascu (eng. Anti-Pattern), tj. o obrascu koji više škodi nego koristi, Fowler ga definiše kao model bez ponašanja. Zaista, elementi modela imaju atribute i definišu veze, ali kad se baci pogled na njihovu unutrašnjost, postaje jasno da oni nemaju poslovnu logiku u njima, tj. oni su anemični, malokrvni, samo kosturi, jer sem atributa i njihovih getter-a i setter-a ne sadrže ništa. Ponašanje je stavljeno iznad njih, u aplikativni sloj. Fowler ističe da ovakav način pravljenja softvera nema veze sa objektnom-orijentisanošću, nego zapravo predstavlja maskiran proceduralni stil programiranja. Sa ovim se slaže i Haywood, ali takođe primećuje da je anemičan model domena vrlo česta posledica u klasičnim višeslojnim arhitekturama. Međutim, ne treba zaboraviti da Fowler nije nikako protiv višeslojnih arhitektura: one su vrlo korisne, jer mogu razdvojiti model od onih delova sistema koji u suštini ne bi trebali da imaju veze sa modelom domena – kao što je GUI – ali da je poslovna logika deo modela, pa je treba i tako tretirati. [Fowler2003] [Haywood 2009]

146

Unutrašnja višeslojna arhitektura EJB 3 verzije pubDB-a predstavlja tipičan primer jednog anemičnog modela domena. Zaista, u perzistentnom (tj. domenskom) sloju se nalazi model sa entitetima. Oni su anemični, budući da sem atributa i veza kao i njihovih getter-a i setter-a nemaju ništa drugo – čak ni pravilno vezivanje između tipova entiteta (u oba smera). Sve ovo, kao i ostale akcije poput kreiranja, modifikovanja, brisanja, učitavanja i pretraživanja entiteta, se nalazi u aplikativnom sloju u obliku session bean-ova, koji koriste anemične objekte iz perzistentnog sloja samo kao nosioce podataka, slično kao kod proceduralnog stila programiranja. Takođe, može se primetiti da metodi (tj. akcije) unutar tih session bean-ova zapravo nisu ni metodi pravih objekata. Oni su procedure, pošto se nalaze u nekom bean-u u kojem su samo nagomilane. Ove procedure znaju šta treba raditi, one rade potrebna izračunavanja i barataju sa nosiocima podataka, tj. sa entitetima. Još jedan odraz da se koristi proceduralni stil programiranja je postojanje raznih instanceof operatora odnosno if i switch-case grananja. Oni se javljaju kad se neki problem iz objektno-orijentisanog sveta želi rešiti na proceduralni način.

U Naked Objects verziji pubDB-a je drugačije: metodi su tamo metodi pravih objekata. Kad korisnik pristupa nekoj akciji, on pristupa akciji određenog objekta. Naravno, jedan objekat zna samo ono što ga se tiče: jedan članak će znati kako može sebe izbrisati, ali neće znati kako se briše autor. Takođe, klasa za fabriku i repozitoriju je samo pomoćni omotač za entitete u obliku servisa. Ova klasa će znati kako se može neki objekat kreirati, pretražiti, itd., u zavisnosti od potreba.

Dodatna prednost Naked Objects pristupa je ta da može ove prethodno spomenute ideje staviti u praktični kontekst. Kod ovog pristupa ne postoji opasnost da će programeri rasipati funkcionalnost ili da će napraviti anemičan model domena sa behavioralno-slabim objektima, pošto oni faktično nemaju pristup nijednom sloju sem domenskog. Ako i naprave loš model, budući da se model direktno preslikava u GUI, prvi koji će primetiti da nešto ne štima će biti upravo korisnici.

Budući da su ove dve verzije pubDB-a tako različite, postavlja se pitanje, koliko je teško ili lako proširiti ove aplikacije sa novim osobinama. Neka se pretpostavi da treba dodati novi atribut u neki entitet (npr. godina rođenja kod autora). U EJB 3 verziji bi prvo trebalo dodati atribut u entitet unutar perzistentnog sloja, zatim proširiti GUI u prezentacionom sloju sa novim tekstualnim poljem, onda proširiti sve metode za dodavanje, pretraživanje, modifikovanje i učitavanje proširenog entiteta, i na kraju povezati novo polje GUI-ja sa aplikativnim slojem. Drugim rečima, promena se propagirala ka svim slojevima. U Naked Objects verziji treba samo dodati novi atribut u entitet (i eventualno ažurirati fiksture, ako se koriste). Neka se sad pretpostavi da se želi proširiti model sa novom funkcionalnošću (npr. pretraživanje autora po godini rođenja). U EJB 3 verziji bi se morao dodati novi upit za pretraživanje u odgovarajući entitet (mada bi se mogao staviti i u session bean), napraviti novi metod (tj. novu proceduru) u session bean-u (aplikativni sloj), i u GUI-ju proširiti dijalog, tj. da se napravi mesto za popunjavanje polja, koje se mora dodatno povezati sa procedurom iz session bean-a. Konačno, neka se pretpostavi da se želi dodati novi tip entiteta u model (npr. Biblioteka koja bi bila u vezi sa publikacijama). U EJB 3 verziji bi se morao dodati nov tip entiteta u perzistentni sloj sa svim atributima, zatim dodati sve akcije u novi ili već postojeći session bean, u GUI-ju treba napraviti novi dijalog za kreiranje novog i modifikovanje postojećeg entiteta novog tipa, a zatim još treba proširiti dijalog za pretraživanje da bi mogao da „primi“ i nov tip entiteta (i ponovo sve ovo povezati sa aplikativnim slojem).

147

U Naked Objects verziji bi se morao dodati nov tip entiteta u model domena, zajedno sa svim atributima, vezama, i akcijama (poput brisanja). Zatim bi verovatno trebala da se napravi i nova klasa za fabriku i repozitoriju koja bi bila zadužena za kreiranje i pretraživanje novih entiteta. Možda bi trebalo napraviti i par novih fikstura. Sve u svemu, proširenje Naked Objects verzije bi bilo brže, prvenstveno zbog toga što se GUI automatski generiše. Kao što se može videti, sve spomenute izmene zahtevaju promenu svih slojeva u EJB 3 verziji, a postoji verovatnoća da bi proširenje prezentacionog sloja bilo najteže i najduže. Međutim, ovo ne znači da su sva proširenja jednostavnija kod Naked Objects verzije. Naime, korišćeni stilovi su različiti (proceduralni i objektno-orijentisani) i sigurno postoje problemi koji se lakše rešavaju u jednoj paradigmi nego u drugoj. Međutim, sposobnost Naked Objects pristupa da sam generiše GUI bi svakako skratila vreme izrade.

Pre završetka ovog odeljka, bilo bi interesantno kratko ispitati da li EJB 3, budući da već ima mogućnost pravljenja objekata na POJO način, podržava Domain-Driven Design. Odgovor je potvrdan. EJB 3, pored tradicionalne četvoro-slojne arhitekture podržava i DDD. Ovo nije bilo moguće u EJB 2, budući da bean-ovi tamo nisu bili POJO objekti. Sve se to promenilo u EJB 3, a budući da je moguće i ponašanje enkapsulirati u sam objekat, kreiranje behavioralno-kompletnih objekata je dozvoljeno. U ovom slučaju, drugi, aplikativni sloj se može „degradirati“ u jedan tanak sloj. [Panda,Rahman & Lane 2007] Međutim, promena načina razvoja softvera često donosi sa sobom i druge promene, a ni EJB 3 nije izuzetak. Tako na primer, što se tiče session bean-ova, oni su kod klasičnih višeslojnih arhitektura označeni sa @Stateless anotacijom, što znači da se stanje bean-a između poziva procedura ne čuva. Međutim, suština kod DDD-a je stanje i ponašanje, prema tome, stanje se mora između poziva sačuvati. Zato bean-ovi kod DDD-a moraju biti @Stateful. Takođe, ako se koriste Web servisi, mora se znati da DDD nije baš kompatibilan sa SOAP stilom, nego sa REST-om.126 Prema tome, može se reći da je DDD sa EJB 3 svakako moguć, ali zahteva dosta drugačiji način rada.127 Međutim, budući da je literatura o kreiranju DDD aplikacija uz pomoć EJB 3 skoro nepostojeća, može se zaključiti da će razvoj biti otežan i dosta rizičan.

U sledećem odeljku ovog poglavlja će se sumirati prednosti i mane Naked Objects framework-a.

126 Web servisi se po stilu dele na dva pristupa: SOAP i REST.SOAP (skraćenica od Simple Object Access Protocol) koristi tzv. daljinski poziv procedure, tj. RPC (skraćenica od Remote Procedure Call) da bi izlagao (eng. Expose) servis. Ovi servisi su operacije, tj. funkcije, delovi poslovne logike (kao što su procedure u session bean-u).S druge strane, REST (skraćenica od REpresentational State Transfer) kao servise izlaže resurse sa podacima.Kao što se može videti, DDD se ne uklapa u SOAP stil, budući da je teško reći kom objektu ta funkcija pripada (zapravo pripada session bean-u), dok se kod REST-a, resursi lepo mapiraju ka domenskim objektima ili DDD-servisima (kao što su repozitorije i fabrike). [Haywood 2009]

127 Izvor: <http://www.javaworld.com/javaworld/jw-05-2009/jw-05-domain-driven-design.html>.

148

6.5. Prednosti i mane Naked Objects framework-aBudući da su i prethodna poglavlja (Domain-Driven Design i Naked Objects

pristup) bila završena navođenjem njihovih prednosti i mana, i predstavljanje Naked Objects framework-a će se završiti na ovaj način.

Sumirano, Naked Objects framework je jedna funkcionalna implementacija Naked Objects obrasca za programski jezik Java, i pomoću njega se mogu praviti aplikacije po Naked Objects načinu razvoja softvera. Prednosti NOF-a su: [Haywood2009]

• Predstavlja punopravnu implementaciju Naked Objects obrasca, i još više od toga – pozitivne strane razvoja po Naked Objects pristupu će se zato maksimalno osetiti. Međutim, NOF je otišao i korak dalje. Naime, pored automatskog generisanja GUI-ja on može automatizovati i generisanje sloja podataka (ukoliko se koristi in-memory ili XML perzistor).

• Stavlja DDD u praktični kontekst – poznato je da su neki koncepti DDD-a dosta apstraktni, ili se teže realizuju u praksi. NOF je u poslednje vreme počeo aktivno da preuzima terminologiju DDD-a, kao što su entiteti, fabrike, repozitorije, specifikacije, itd. Jedna posledica ove osobine je ta da ljudi ne moraju razmišljati o tome da li vredi kod manjih projekata koristiti DDD ili ne, pošto je razvoj softvera umnogome olakšan uz pomoć NOF-a, a korišćenje čistog DDD-a u suštini nije obavezno dok se poštuju načela Naked Objects pristupa.

• Lako se uči, ubrzava razvoj i smanjuje veličinu aplikacija – iako je potreban određen period uhodavanja u framework i u sam Naked Objects pristup, posle toga je kreiranje prototipova za aplikaciju umnogome olakšano. Razvoj softvera u NOF-u smanjuje i veličinu izvornog koda (u slučaju pubDB-a je uočeno smanjenje koda za 72.5% u odnosu na klasični višeslojni način).

• Ima komponentizovanu arhitekturu – proširenje portova sa novim adapterima (pogledima, perzistorima, itd.) je jednostavnije. Takođe, ova osobina omogućava da se korišćeni plug-in-ovi aktiviraju i deaktiviraju po potrebi, povećavajući broj načina deployment-a (čist POJO, ugrađen metamodel, itd.).

• NOF je besplatan i otvoren softver – izvorni kod NOF-a je dostupan, i može se modifikovati u zavisnosti od potreba.

• Aktivno se razvija – mada od sad pod nazivom Apache Isis.

Međutim, tokom implementiranja Naked Objects verzije pubDB-a, autor ovog rada je uočio i neke potencijalne probleme vezane za NOF (verzija 4.0):

• Očekivano, neke mane Naked Objects pristupa su automatski prešle i u NOF – prema tome, skalabilnost, serijska obrada veće količine podataka kao i upotrebljivost OOUI-ja su i dalje pod znakom pitanja.

• Kao i svaki softver, nije bez bagova – ovo posebno važi za poglede, budući da je autor već par puta naišao na bagove tokom korišćenja nekog pogleda. Kod DnD pogleda se preporučuje da se paralelni način rada koristi oprezno, budući

149

da se ne garantuje da će svi otvoreni dijalozi biti ažurirani u slučaju da se promeni ili briše neki entitet. Što se tiče HTML pogleda, u njemu fale neke potrebne funkcionalnosti, kao što je brisanje asocijacija. Takođe, korišćenje ovog pogleda zajedno sa XML perzistorom blokira aplikaciju posle svakog brisanja nekog entiteta.

• Atributi entiteta mogu biti samo primitivnog ili referencijalnog tipa – pubDB je imao jedan tip entiteta, Knjigu, sa atributom koji je bio binarnog tipa (korice knjige u vidu slike). U EJB 3 verziji je moguće deklarisati atribut tipa byte[] koji se markira anotacijom @Lob (označava težak objekat). Ovako nešto u NOF-u nije moguće, iako je potreba da entiteti imaju npr. i slike kao atribute – realna.

• Nije još dovoljno popularan – ako članovi razvojnog tima naiđu na neki problem, postoji verovatnoća da će sami morati da nađu rešenje.

• Izdat 2009. godine, NOF v4.0 je već relativno star – iako NOF dalje živi unutar Apache Isis-a, budući da je on u momentu pisanja ovog rada još uvek u inkubatoru, ne ostavlja puno mogućnosti, nego da se koristi NOF v4.0. Starost NOF-a je bila najverovatniji razlog i za nemogućnost njegovog povezivanja sa JPA perzistorom.

Međutim, iako se navedeni problemi mogu činiti ozbiljnim, ne treba zaboraviti da je framework otvoren projekat, prema tome, programeri mogu slobodno ispraviti bagove, proširiti NOF sa novim mogućnostima, ili čak pisati nove plug-in-ove, zavisno od potreba. Takođe, realno je za očekivati da će Apache Isis biti stabilniji od NOF v4.0, i da će imati bolju podršku, budući da je postao deo Apache familije softvera.

S ovim je predstavljanje Naked Objects framework-a, kao i demonstracionog primera završeno. U poslednjem delu će se izneti zaključak ovog rada.

150

7. ZaključakPri razvoju enterprise aplikacija se pretežno koriste principi klasičnih višeslojnih

arhitektura. Višeslojne arhitekture kao arhitektonski obrazac su bile izmišljene da bi struktuirale sisteme na podzadatke, da bi se grupisali srodni koncepti radi uvođenja reda u prethodnu haotičnu strukturu. Tako su nastali danas popularni slojevi poput prezentacionog sloja sa korisničkim interfejsom (tj. GUI-jem), aplikativni sloj koji definiše softverske poslove, domenski sloj sa poslovnim konceptima i pravilima, tj. modelom domena i infrastrukturni sloj koji pruža tehničke usluge višim slojevima, kao što su baze podataka (sloj podataka).

Međutim, razbijanje sistema na podzadatke je s vremenom otišlo predaleko. Kad je nastala objektno-orijentisana paradigma, objekti su u sebi enkapsulirali i stanje i ponašanje, tj. oni su bili behavioralno-kompletni, ali sa nastankom MVC (model-pogled-kontroler) arhitekture, tačnije, zbog njenog pogrešnog shvatanja, ljudi su počeli da prebacuju ponašanje iz modela u druge delove radi zaštite ostalih delova od talasnog efekta u slučaju da se neki deo softvera menja. Deo za kontroler je postao puko oruđe za slučajeve korišćenja, koji je poznat i kao obrazac pod nazivom kontroler slučajeva korišćenja (UCC). Ovako su objekti postali behavioralno-slabi, anemični, znači, bez ponašanja, a model je postao anemičan model domena, u prevodu model samo sa podacima, a poslovna logika se nalazila iznad ovog modela u aplikativnom sloju.

Ali s ovim se izgubila smisao objektne-orijentisanosti, i razvoj softvera se praktično sveo na maskiran proceduralni stil programiranja. Poznati stručnjaci, kao što su Eric Evans, Martin Fowler, Richard Pawson, i drugi, su počeli „kampanju“ da vrate smisao objektno-orijentisanoj paradigmi. Evans je izmislio Domain-Driven Design, jednu filozofiju za razvoj softvera, sa fokusom na model domena, i ciljem da se ubrza i poboljša razvoj poslovnog softvera sa komplikovanim domenima. Kao oruđe, DDD koristi dobro prihvaćen skup principa i obrazaca. Principi predstavljaju generalne smernice za razvoj, a od njih je možda najpoznatiji drugi, sveprisutni jezik, koji predstavlja jezik koji će biti razumljiv svim članovima tima bez obzira da li je reč o programerima ili domenskim ekspertima, i koji će zato predstavljati osnovu i za sam model. Međutim, DDD je bio sve samo ne lak za učenje, naime, neke ideje su bile suviše apstraktne ili komplikovane da bi se stavile u praktični kontekst.

S druge strane, Richard Pawson je izmislio jedan pristup (tj. obrazac) razvoju softvera pod nazivom Naked Objects, zbog tri razloga: da reši problem behavioralno-slabih objekata, da ponovo osposobi ljude da oni rešavaju probleme umesto da ih računar vodi, i konačno, da stavi DDD u praktični kontekst. Suština Naked Objects pristupa je sledeća: cela poslovna logika bi trebala da se enkapsulira u domenske objekte (tj. da oni budu behavioralno-kompletni), GUI bi trebao da bude odraz tih domenskih objekata (što znači da će biti objektno-orijentisan, tj. OOUI), i konačno, GUI bi trebao da se generiše automatski. Da bi forsirao pravilno korišćenje objektne-orijentisanosti, Naked Objects pristup zaključa aplikativni i prezentacioni sloj, primoravajući programere da poslovnu logiku stave u domenski sloj unutar objekata. Sve u svemu, ovakav način razvoja softvera bi trebao da ubrzava razvojni ciklus. Posledica prethodno spomenutih ideja je zapravo poboljšanje agilnosti.

151

Dok je Pawson postavio teorijske temelje Naked Objects pristupa, drugi su počeli da rade na implementacijama pristupa. Jedna od najpoznatijih je Naked Objects framework (NOF) za programski jezik Java. NOF je jedan otvoren (open-source) komponentizovan framework rađen u heksagonalnoj arhitekturi. NOF je pored implementiranja pristupa otišao i korak dalje: automatizovao je i sloj podataka. NOF dolazi sa dva ugrađena pogleda (DnD i HTML) i dva perzistora (in-memory i XML), ali se može proširiti sa drugim plug-in-ovima.

Cilj ovog rada je bio da teorijski i delom praktički kroz poglavlja prikaže celu problematiku oko višeslojnih arhitektura u kombinaciji sa objektno-orijentisanom paradigmom. Ukratko je bio predstavljen Domain-Driven Design, njegovi principi, i praktična primena. Zatim se prešlo na teorijsko predstavljanje Naked Objects pristupa, na OOUI, na njegovu kompatibilnost sa agilnim metodologijama poput Ekstremnog programiranja, na njegovu praktičnu primenu, itd. Predstavili su se i osnovni koncepti Naked Objects framework-a. Pored teorijskog opisivanja višeslojnih arhitektura i njenih mana, implementirao se i jedan jednostavan demonstrativni primer nazvan pubDB – baza podataka za publikacije – koji je pored uobičajenih CRUD operacija imao i mogućnost pretraživanja. Primer se implementirao u dve verzije: jedna verzija se razvila na klasični četvoro-slojni način uz pomoć EJB 3, a druga verzija po Naked Objects pristupu uz pomoć NOF v4.0. Obe verzije su bile detaljno upoređivane sa raznih aspekata: po njihovoj strukturi, po njihovom GUI-ju, po veličini izvornog koda (LOC) i po njihovoj unutrašnjoj implementaciji. Na osnovu rezultata je donet zaključak, da OOUI Naked Objects verzije više osposobljava korisnika da rešava probleme i koristi „imenica-glagol“ stil interakcije, dok GUI EJB 3 verzije koristi „glagol-imenica“ stil. Veličina izvornog koda je bila mnogo manja kod Naked Objects verzije, i lakše se implementirala zbog automatski generisanog OOUI-ja. Što se tiče unutrašnje implementacije, model EJB 3 verzije je bio tipičan primer anemičnog modela domena, budući da se ponašanje implementiralo u session bean-ovima unutar aplikativnog sloja. Relativno često korišćenje instanceof operatora kao i if grananja je bio još jedan dokaz da se zapravo koristi maskiran proceduralni stil programiranja unutar objektno-orijentisanog jezika. Iako samo hipotetički, bilo je par reči i o težini modifikovanja odnosno proširenja primera, i došlo se do zaključka da je postojanje talasnog efekta realan problem kod EJB 3 verzije, i da bi proširenje GUI-ja bilo „najskuplje“, dok bi iste promene bile manje kod Naked Objects verzije, mada sve zavisi i od tipa i složenosti problema. Naravno budući da glavni cilj nije bio izrada složenog sistema po ovim načinima razvoja, odlučilo se da primer ostane jednostavan, ali je čak i u ovom obliku bio dovoljno reprezentativan da prikaže najosnovnije razlike između ova dva načina razvoja poslovnog softvera.

Naravno, uvek postoje mesta za dalja unapređenja i proširenja, u zavisnosti od postavljenih ciljeva i prioriteta. Tako na primer, ukoliko bi predstavljanje Domain-Driven Design-a bilo važan cilj, model aplikacije bi se mogao proširiti sa novim tipovima entiteta i sa novom funkcionalnošću da bude dovoljno velik za razmatranje obrasca iz DDD-a. Proširenje modela bi se moglo meriti radi procenjivanja težine dodavanja novih funkcionalnosti u postojeću aplikaciju. S druge strane, ako bi se fokus stavio više na Naked Objects pristup, mogle bi se porediti razne njegove implementacije. Na primer, poznato je da pored Naked Objects framework-a za Javu postoji i varijanta za .NET. Budući da je nedavno i .NET verzija postala otvorena i besplatna, bilo bi zanimljivo uporediti ova dva framework-a, prvo sa funkcionalne

152

strane, a zatim i sa praktične, implementacijom pubDB-a i za .NET verziju. Konačno, ako bi postojala potreba za detaljnije predstavljanje Naked Objects framework-a, mogla bi se opisati i neka njegova naprednija svojstva. Na primer, bilo bi zanimljivo pogledati kako JPA perzistor funkcioniše sa relacionom bazom podataka, ili pogledati neke druge poglede. Takođe, poznato je da NOF ima mehanizam za autentifikaciju i autorizaciju, pa bi se mogle predstaviti i ove osobine, kao i razni oblici deployment-a.

Sve u svemu, može se zaključiti da je Naked Objects pristup (zajedno sa DDD) jedan vrlo zanimljiv poduhvat koji predstavlja jednu logičnu alternativu pri razvoju enterprise softvera, ali još nije stigao do „kritične mase“. Postoje brojne priče o uspesima, i veruje se da će njihov broj s vremenom postati još veći. Međutim, što se tiče NOF v4.0, pokazalo se da je dosta bagovit, i nema bogatu tehničku podršku. Još jedan problem je i relativna starost projekta, budući da je iz 2009. godine. Međutim, realno je za očekivati da će njegov naslednik, Apache Isis, kad izađe iz Apache inkubatora, biti stabilniji, i da će ga ljudi konačno primetiti. Naravno, Naked Objects pristup kao i DDD nije pogodan u svim situacijama, ali su njegove prednosti značajne, što bi trebalo da da dovoljan razlog da se i ovaj pristup uzima u obzir pri razvoju enterprise aplikacija.

153

LiteraturaBeck, K 1999, Extreme Programming Explained: Embrace Change, First Edition, Addison-Wesley Professional, Boston, MA

Booch, G, Maksimchuk, RA, Engle, MW, Young, BJ, Conallen, J & Houston, KA 2007, Object-Oriented Analysis and Design with Applications, Third Edition, Addison-Wesley, Upper Saddle River, NJ

Buschmann, F, Meunier, R, Rohnert, H, Sommerlad, P & Stal, M 1996, Pattern-Oriented Software Architecture, Volume 1, A System of Patterns, First Edition, John Wiley & Sons, Chichester

Canty, T (CIO, Labatt Food Service) 2012, School Startup System Hits the Mark, Experience report, Labatt Food Service, viewed 5 March 2012, <http://domaindrivendesign.org/library/canty_2012>

Cockburn, A 2005, 'Hexagonal Architecture', Alistair Cockburn's blog, weblog post, 4 January, viewed 14 October 2011, <http://alistair.cockburn.us/Hexagonal+architecture>

Collins, D 1995, Designing Object-Oriented User Interfaces, 1st Edition, Benjamin/Cummings, Redwood City, CA

Constantine, L 2002, The Emperor Has No Clothes: Naked Objects Meet the Interface, Attendance Report, Constantine & Lockwood, Ltd., viewed 14 October 2011, <http://foruse.com/articles/nakedobjects.htm>

Cooper, A, Reimann, R & Cronin, D 2007, About Face 3: The Essentials of Interaction Design, Third Edition, Wiley, Indianapolis, IN

Evans, E 2003, Domain-Driven Design: Tackling Complexity in the Heart of Software, First Edition, Addison Wesley,

Fowler, M 2003, 'AnemicDomainModel', Martin Fowler's blog, weblog post, 25 November, viewed 14 October 2011, <http://martinfowler.com/bliki/AnemicDomainModel.html>

Fowler, M, Rice, D, Foemmel, M, Hieatt, E, Mee, R & Stafford, R 2002, Patterns of Enterprise Application Architecture, First Edition, Addison Wesley, Boston, MA

Gamma, E, Helm, R, Johnson, R & Vlissides, J 1994, Design Patterns: Elements of Reusable Object-Oriented Software, First Edition, Addison-Wesley Professional, Boston, MA

Garcia, B, Dueñas, JC, Fernandez-Villamor, JI, Westerski, A, Garijo, M & Iglesias, CA 2010, 'ROMULUS: Domain Driven Design and Mashup Oriented Development Based on Open Source Java Metaframework for Pragmatic, Reliable and Secure Web Development', 2010 14th European Conference on Software Maintenance and Reengineering (CSMR), vol. -, no. -, pp. 186-189, viewed 14 October 2011, <http://doi.ieeecomputersociety.org/10.1109/CSMR.2010.30>

Haaster, KV & Hagan, D 2004, 'Teaching and Learning with BlueJ: an Evaluation of a Pedagogical Tool', Issues in Informing Science and Information Technology, vol. -, no. -, pp. 455-470, viewed 4 April 2012, <http://arrow.monash.edu.au/hdl/1959.1/130610>

155

Haywood, D 2009, Domain-Driven Design Using Naked Objects, First Edition, Pragmatic Bookshelf, Raleigh, Dallas

Hu, Y & Peng, S 2007, So We Thought We Knew Money, Experience report, Custom House, viewed 21 December 2011, <http://domaindrivendesign.org/library/peng_hu_2007_1>

Kennard, R & Leaney, J 2011, 'Is There Convergence in the Field of UI Generation?', Journal of Systems and Software, vol. 84, no. 12, pp. 2079–2087, viewed 14 October 2011, <http://dx.doi.org/10.1016/j.jss.2011.05.034>

Keränen, H & Abrahamsson, P 2005, 'A Case Study on Naked Objects in Agile Software Development', XP'05 Proceedings of the 6th international conference on Extreme Programming and Agile Processes in Software Engineering, vol. 3556/2005, no. -, pp. 189-197, viewed 21 December 2011, <http://dx.doi.org/10.1007/11499053_22>

Keränen, H & Abrahamsson, P 2005, 'Naked Objects versus Traditional Mobile Platform Development: A Comparative Case Study', EUROMICRO '05 Proceedings of the 31st EUROMICRO Conference on Software Engineering and Advanced Applications, vol. -, no. -, pp. 274-281, viewed 21 December 2011, <http://dx.doi.org/10.1109/EUROMICRO.2005.42>

Kölling, M, Quig, B, Patterson, A & Rosenberg, J 2003, 'The BlueJ System and its Pedagogy', Journal of Computer Science Education, Special issue on Learning and Teaching Object Technology, vol. 13, no. 4, pp. 249-268, viewed 4 April 2012, <http://www.cs.kent.ac.uk/pubs/2003/2190/index.html>

Lampson, BW 1986, 'Personal Distributed Computing: The Alto and Ethernet Software', Proceedings of the ACM Conference on The History of Personal Workstations (HPW '86), vol. -, no. -, pp. 101-131, viewed 16 March 2012, <http://dx.doi.org/10.1145/12178.12186>

Larman, C 2003, Agile and Iterative Development: A Manager's Guide, First Edition, Addison-Wesley Professional, Boston, MA

Läufer, K 2008, 'A Stroll through Domain-Driven Development with Naked Objects', Computing in Science and Engineering, vol. 10, no. 3, pp. 76-83, viewed 14 October 2011, <http://doi.ieeecomputersociety.org/10.1109/MCSE.2008.67>

Marzullo, FP, de Souza, JM & Blaschek, JR 2008, 'A Domain-Driven Development Approach for Enterprise Applications, Using MDA, SOA and Web Services', 2008 10th IEEE Conference on E-Commerce Technology and the Fifth IEEE Conference on Enterprise Computing, E-Commerce and E-Services, vol. -, no. -, pp. 432-437, viewed 14 October 2011, <http://doi.ieeecomputersociety.org/10.1109/CECandEEE.2008.119>

Mehta, VP 2008, Pro LINQ Object Relational Mapping with C# 2008, First Edition, Apress, Berkeley, CA

Nilsson, J 2006, Applying Domain-Driven Design and Patterns: With Examples in C# and .NET, First Edition, Addison Wesley Professional, Upper Saddle River, NJ

Naked Objects v4.0.0 User Guide 2009, Techn. documentation, Naked Objects Group, viewed 21 December 2011, <http://www.nakedobjects.org/nakedobjects-4.0.0.pdf>

Panda, D, Rahman, R & Lane, D 2007, EJB 3 in Action, First Edition, Manning,

156

Greenwich

Pawson, R & Wade, V 2003, 'Agile Development Using Naked Objects', XP'03 Proceedings of the 4th International Conference on Extreme Programming and Agile Processes in Software Engineering, vol. 2675/2003, no. -, pp. 97-103, viewed 14 October 2011, <http://dx.doi.org/10.1007/3-540-44870-5_13>

Pawson, R 2004, 'Naked Objects', PhD thesis, Trinity College, Dublin

Peng, S & Hu, Y 2007, IAnticorruption – A Domain-Driven Design Approach To More Robust Integration, Experience report, Custom House, viewed 21 December 2011, <http://domaindrivendesign.org/library/peng_hu_2007_2>

Raja, A & Lakshmanan, D 2010, 'Naked Objects Framework', International Journal of Computer Applications, vol. 1, no. 20, pp. 37-41, viewed 14 October 2011, <http://dx.doi.org/10.5120/425-628>

Royce, WW 1970, 'Managing the Development of Large Software Systems', Proceedings, IEEE WESCON'70, vol. -, no. -, pp. 328-338, viewed 16 March 2012, <http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf>

Shore, J & Warden, S 2007, The Art of Agile Development, First Edition, O'Reilly, Sebastopol, CA

Szyperski, C, Gruntz, D & Murer, S 2002, Component Software - Beyond Object-Oriented Programming, Second Edition, Addison-Wesley, Harlow, London

Wesenberg, H, Landre, E & Rønneberg, H 2006, 'Using Domain-Driven Design to Evaluate Commercial Off-The-Shelf Software', Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications (OOPSLA '06), vol. -, no. -, pp. 824-829, viewed 14 October 2011, <http://dx.doi.org/10.1145/1176617.1176730>

Wills, P 2009, Rebuilding guardian.co.uk with DDD, Video presentation, The Guardian, viewed 21 December 2011, <http://www.infoq.com/presentations/rebuild-guardian-ddd-wills>

Xinogalos, S, Sartatzemi, M, Dagdilelis, V & Evangelidis, G 2006, 'Teaching OOP with BlueJ: A Case Study', Sixth IEEE International Conference on Advanced Learning Technologies (ICALT'06), vol. -, no. -, pp. 944-946, viewed 4 April 2012, <http://doi.ieeecomputersociety.org/10.1109/ICALT.2006.6>

157

Kratka biografija

Robert Pap je rođen 11. aprila 1984. godine u Bačkoj Topoli (Vojvodina, Srbija) od oca Lasla i majke Katalin. Ima starijeg brata, Zoltana. Osnovnu školu „Čaki Lajoš“ u Bačkoj Topoli završava 1999. godine sa odličnim uspehom i Vukovom diplomom. Dalje obrazovanje nastavlja u gimnaziji „Dositej Obradović“ u Bačkoj Topoli koju takođe završava sa odličnim uspehom i Vukovom diplomom, 2003. godine. Iste godine postaje student na Prirodno-matematičkom Fakultetu u Novom Sadu, smer Diplomirani informatičar – poslovna informatika. Diplomirao je u oktobru 2008. godine sa prosečnom ocenom 8.93 (osam i 93/100). Diplomski rad pod nazivom „Ekstremno programiranje kao metod agilnog razvoja softvera“ je odbranio sa ocenom 10.

Poslediplomske studije, smer Diplomirani informatičar – informacione tehnologije – master, modul Softversko inženjerstvo, upisuje 2008. godine na Prirodno-matematičkom Fakultetu u Novom Sadu. Sve ispite predviđene planom i programom je položio sa prosečnom ocenom 9.50 (devet i 50/100).

Novi Sad, jun 2012. Robert Pap

159

UNIVERZITET U NOVOM SADUPRIRODNO-MATEMATIČKI FAKULTET

KLJUČNA DOKUMENTACIJSKA INFORMACIJA

Redni broj:RBRIdentifikacioni broj:IBRTip dokumentacije:TD

Monografska dokumentacija

Tip zapisa:TZ

Tekstualni štampani materijal

Vrsta rada:VR

Master rad

Autor:AU

Robert Pap

Mentor:MN

dr Miloš Racković, redovni profesor

Naslov rada:NR

Naked Objects pristup pri razvoju enterprise aplikacija

Jezik publikacije:JP

Srpski (latinica)

Jezik izvoda:JI

s / en

Zemlja publikovanja:ZP

R Srbija

Uže geografsko područje:UGP

Vojvodina

Godina:GO

2012

Izdavač:IZ

Autorski reprint

Mesto i adresa:MA

Novi Sad, Trg D. Obradovića 4

Fizički opis rada:FO

(broj poglavlja/ broj strana/ broj lit. citata/ broj tabela/ broj slika/ broj grafika/ broj priloga)

(7/159/38/1/49/0/0)

Naučna oblast:NO

Informatika

Naučna disciplina:ND

Informacione tehnologije i sistemi

Predmetne odrednice, Ključne reči:POUDK

Naked Objects, model domena, višeslojne arhitekture, OOUI, Domain-Driven Design, XP

Čuva se:ČU

Biblioteka departmana za matematiku i informatiku, Novi Sad

Važna napomena:VN

nema

Izvod:IZEnterprise aplikacije se i danas pretežno razvijaju po starom principu višeslojne arhitekture, pri čemu je funkcionalnost često rasipana u više slojeva. Naked Objects pristup predstavlja nov način razvoja enterprise aplikacija, i ima dosta sličnosti sa Domain-Driven Design-om. Po ovom principu najvažniji sloj je zapravo domenski sloj, i umesto da sadrži samo podatke o modelu domena, objekti ovog sloja bi trebali da budu pravi tzv. domenski objekti, što znači da bi i celokupno ponašanje tj. poslovna logika trebala da se nalazi u njima. Istovremeno, programeri ne bi trebali da puno vremena provode radeći na ostalim slojevima, prema tome, korisnički interfejs (GUI) bi trebao da se generiše automatski. Naked Objects framework je jedna od implementacija ovog pristupa. Pored teorijskog opisa Naked Objects pristupa zajedno sa elementima Domain-Driven Design-a, rad sadrži i jednostavni demonstracioni primer rađen u dve verzije: u prvoj verziji se koristi klasični višeslojni, a u drugoj Naked Objects pristup. U radu je urađeno i njihovo detaljno upoređivanje.

Datum prihvatanja teme od strane NN veća:DP

6. oktobar, 2011.

Datum odbrane:DOČlanovi komisije:KOPredsednik: dr Zoran Budimac, redovni profesor Prirodno-

matematičkog Fakulteta u Novom SaduČlan: dr Miloš Racković, redovni profesor Prirodno-

matematičkog Fakulteta u Novom SaduČlan: dr Danijela Tešendić, docent Prirodno-matematičkog

Fakulteta u Novom Sadu

UNIVERSITY OF NOVI SADFACULTY OF SCIENCES

KEY WORDS DOCUMENTATION

Accession number:ANOIdentification number:INODocument type:DT

Monograph documentation

Type of record:TR

Textual printed material

Contents code:CC

Master thesis

Author:AU

Robert Pap

Mentor:MN

PhD Miloš Racković, full professor

Title:TI

The Naked Objects Approach in Developing Enterprise Applications

Language of text:LT

Serbian (Latin)

Language of abstract:LA

en / s

Country of publication:CP

Serbia

Locality of publication:LP

Vojvodina

Publication year:PY

2012

Publisher:PU

Author's reprint

Publication place:PP

Novi Sad, Trg D. Obradovića 4

Physical description:PD

(7/159/38/1/49/0/0)

Scientific field:SF

Informatics

Scientific discipline:SD

Information Technologies and Systems

Subject key words:SKWUC

Naked Objects, domain model, layered architectures, OOUI, Domain-Driven Design, XP

Holding data:HD

Department of Mathematics and Informatics Library, Faculty of Sciences,Trg D. Obradovića 4, Novi Sad

Note:N

none

Abstract:ABEnterprise applications are still predominantly developed under the old principle of layered architectures with functionality often scattered in several layers. The Naked Objects approach represents a new method in the development of enterprise applications, and it's quite similar to Domain-Driven Design. According to this approach, the most important layer is actually the domain layer, and instead of just holding the data of the domain model, the objects of this layer should be genuine so-called domain objects, meaning that the whole behavior, i.e. business logic should be encapsulated within them. At the same time, developers shouldn't waste too much time working on other layers, therefore, the user interface (GUI) should be generated automatically. The Naked Objects framework is an implementation of this approach. Apart from the theoretical description of the Naked Objects approach with the elements of Domain-Driven Design, this thesis also contains a simple demonstrative example made in two flavors: the first version utilizes the classic layered approach, and the second the Naked Objects approach. Their detailed comparison is also included.

Accepted by the Scientific Board on:ASB

October 6th, 2011

Defended:DEThesis defend board:DBPresident: PhD Zoran Budimac, full professor, Faculty of Sciences,

Novi SadMember: PhD Miloš Racković, full professor, Faculty of Sciences,

Novi SadMember: PhD Danijela Tešendić, assistant professor, Faculty of

Sciences, Novi Sad