Primer analize i projektovanja arhitekture jedne Web aplikacije

1. Uvod u Web razvoj sa Javom Prikupljanje zahteva Kreiranje use case dijagrama Analiza Dizajn arhitekture Projektovanje Web aplikacije UML modelovanje XML dokumenta Primer analize i projektovanja arhitekture jedne Web aplikacije

2. Osnove Web razvoja sa Javom Osnovna Web arhitektura za statičan Web sadržaj • U ovom slučaju napisaćete HTML strane i postaviti ih na Web server • Osnovni kostur HTML bi izgledao kao na slici levo • Osnovna arhitektura je prikazana dijagramom uvođenja na slici desno

3. Dijagram sekvenci • Kada korisnik ukuca URL u Web browser, browser će komunicirati sa Web serverom kako bi dobio dokument, u ovom slučaju “index.html” • HTTP definiše komunikacioni protokol za ovu komunikaciju između Web browsera i Web servera. • Kada korisnik unese URL, Web browser kreira HTTP zahtev, koji predstavlja paket informacija uključujući ime Web servera, naziv dokumenta i druge informacije o zahtevima. Web browser onda šalje taj HTTP zahtev preko mreže ka Web serveru. Web server pregleda web page “index.html” i vraća ga kao deo odziva (paket informacija koji uključuje zahtevani dokument ili poruku o grešci i druge meta podatke)

4. Dinamički Web sadržaj • Većina Web aplikacija zahteva dinamičko generisanje sadržaja • Npr., kod e-commerce sajte gde želite da pretražujete proizvode, postavite ih u shopping cart-u ili napravite porudžbinu – sve ove aktivnosti zahtevaju neki kôd na Web serveru koji reaguje na HTTP zahtev tako što vrši neku obradu i vraća Web sadržaj kao HTML ili XML • Npr., želite da generišete ažurnu vremensku prognozu za određeni grad • Razmotrite kako bi Web sajt bio implementiran • Ukoliko ignorišete Web aspekt sistema, zamislite kako biste pisali kôd u bilo kom programskom jeziku radi postavljanja upita bazi podatka ili prikupljali podatke o vremenu, računali statistiku, generisali mape slika o vremenu i proizveli HTML rezultate • Jedini problem koji treba da se reši je kako pronaći način da se pokrene (trigger) kôd sa HTTP zahtevom koji stiže na Web server, a zatim da se HTML rezultati postave u HTTP odziv koji se šalje ka Web browseru – npr. CGI skriptovi i Java servleti su dve tehnologije koje rešavaju ovaj problem kačenja koda na HTTP Web protokol • Ovo opšte rešenje je prikazano dijagramom uvođenja na sledećoj slici

5. Dijagram uvođenja za dinamički sadržaj • CGI skriptovi generišu dinamički Web sadržaj omogućavajući pisanje skriptova u većini programskih jezika uključujući i Perl i C. Zatim obezbeđuju mehanizam za ubacivanje vašeg skripta u HTTP zahtev/odziv mehanizam • Java servleti omogućavaju osnovnu funkcionalnost CGI skriptova – omogućavaju pisanje klase u Javi koja će generisati dinamički Web sadržaj

6. Java servlet • Listing desno prikazuje kako Web strana koja prikazuje trenutni datum može biti kreirana kao Java servlet • generisan HTML je postavljen u HTTP zahtev • Servlet je klasa i ima samo jedan metod u ovom primeru koji se zove doGet • Servlet container će pozivati ovu metodu kako bi se odazvala zahtevu kada kod Web browser pošalje HTTP zahtev za ovaj servlet • Metoda doGet uvek uzima dva parametara koji predstavljaju pristigli HTTP zahtev i odlazeći HTTP odziv • Promenljiva out je referenca koja vam omogućava da pišete sadržaj za telo HTTP odziva • HTML i drugi sadržaji u out.println metodi poziva su smešteni u HTTP odziv i poslati do Web browsera • U ovom slučaju web sadržaj je skoro statičan, izuzev gde postavlja “new java.util.Date()” u izlaz

7. JavaServer Pages (JSPs) • Listing prikazuje JavaServer Pages (JSPs) koji će proizvesti identičnu Web stranu kao kod prethodnog Java servleta • Kao što se vidi sve linije koda su HTML izuzev linije 6 koja je napisana u Javi i ubacuje trenutni datum i vreme • Uporedivši sa servletom može se zaključiti da su JSP dosta lakši za pisanje, razvijanje, imaju manje komplikovanu Java logiku, laki su za čitanje i održavanje – druge tehnologije kao što su ASP, PHP, Cold Fusion i sl. rade na sličan način, ali imaju svojstvene funkcionalnosti, prednosti i mane

8. Prikupljanje zahteva (requirements gathering) • U ovom projektu razvijate Web komponentu za postojeću Visual Basic aplikaciju koja se zove Friendly Reminder • Klijentova inicijalna specifikacija projekta opisuje da trenutni Friendly Reminder sistem omogućava korisnicima praćenje njihovih sastanaka i kontakata omogućavajući im: • Unos podataka o kontaktima (npr. ime i prezime, brojevi telefona, adrese ...) • Unos podataka o sastancima (npr. datum, vreme, opis...) • Pridruživanje kontakata sastancima • Pretraga određenih kontakata ili sastanaka • Prihvatanje obaveštenja o budućem održavanju sastanka • Trenutni sistem je samostalna, zasebna aplikacija koja nema mrežnih komponenata • Friendly Reminder je već dobro prihvaćen proizvod sa već popunjenom bazom lojalnih klijenata. Međutim, kompanija je od svojih klijenata dobila zahtev za mogućnost pregleda njihovih sastanaka preko Weba. Klijenti se žale da ne postoji način provere sastanaka kada su udaljeni od svog računara na poslu. Klijentova inicijalna specifikacija projekta zahteva da razvijete manju aplikaciju koja će omogućiti njihovim korisnicima da: • Upload-uju sve njihove sastanke i kontakte na server odakle im se može pristupiti sa bilo koje lokacije • Postavljanje upita nad bazom sastanaka i kontakata u bilo koje vreme i sa bilo koje lokacije, kada god se javi potreba

9. Prikupljanje zahteva - nastavak • Faza prikupljanja zahteva je proces kada treba pažljivo komunicirati sa klijentima da bi se otkrili i dokumentovali poslovni zahtevi i kako bi se osiguralo da razvojni tim zna šta mora da kreira • S obzirom da je klijent veoma konzervativna kompanija koja je skeptična po pitanju prelaska na Web, ona zahteva da novi sistem nesme da dovede do mogućih rizika pouzdanosti njihovog trenutnog sistema. • S obzirom da trenutna aplikacija nema mrežnih komponenata, svi sastanci su skladišteni na fajlu korisničke mašine. Na osnovu ovog iskustva, klijent zahteva da se uključi i ograničenje da se svi sastanci moraju i dalje čuvati na lokalnoj mašini dok se kopija podataka o sastancima može uploadovati na server radi udaljenog pristupa. • Kompanija takođe želi da ograniči korisnike da unose podatke o sastancima jedino u postojeću Visual Basic aplikaciju, a ne preko Weba • Korisnici zahtevaju pristup njihovim sastancima i kontaktima preko PC-ja ili mobilnih telefona i drugih bežičnih uređaja – ovaj zahtev, je nakon duže diskusije, identifikovan kao ključni zahtev koji se može ispuniti i koji će biti uračunat u troškove projekta • U dizajnu rešenja, tehnološke opcije su kritične kod Web sistema u odnosu na Windows aplikacije. Nekoliko faktora koje treba razmotriti kada se procenjuju tehnologije budućeg Web sistema su: • Raspoloživost i pouzdanost – da li sistem mora da bude dostupan 24/7 bez mogućih padova sistema? Moguće je napraviti Web sistem koji skoro nikada ne pada ili nikad nije raspoloživ, ali takva vrsta pouzdanosti dovodi do određenih troškova. Web sistem čuva samo duplirane vrednosti podataka, a zasebna aplikacija ne treba da zavisi ni na koji način od novog Web sistema • Performanse – koliko brzo sistem mora da odgovara na zahteve klijenata? Web sistemi ponekad imaju više ograničenja u performansama nego zasebni sistemi. Klijent određuje ograničenja za odzivnost sistema • Skalabilnost – koliko konkurentnih korisnika sistem može da podrži? Mnogi Web sistemi mogu biti aktivirani od strane stotine čak i hiljade konkurentnih korisnika. Da bi projekat bio jeftiniji, klijenti odlučuju o prihvatljivosti potencijalnog rasta (skalabilnosti) sve dok je sistem lako prilagodljiv skalabilnim rešenjima u budućnosti • Bezbednost – koliko često i koja vrsta bezbednosne zaštite se zahteva? Bilo koja vrsta umreženih sistema može potencijalno biti ranjiva od malicijoznih napada. Što je veća bezbednost, veći su i troškovi softvera i hardvera. Klijent želi da se osigura da poseduje razumljivu bezbednost za unapred određen budžet • Prilagodljivost – koliko lako sistem može biti modifikovan kako bi ispunio nove zahteve? Razvoj sistema sa visokom prilagodljivošću zahteva više vremena i novca. Klijent je postavio visok prioritet za visoku prilagodljivost jer očekuju da je ovo samo prvi korak na Webu i da će u budućnosti dodavati još funkcionalnosti.

10. Kreiranje use case dijagrama • Use case dijagram vam pomaže da bolje sagledate ko će koristiti sistem i koje će funkcionalnosti koristiti • Use case Create an account će omogućiti klijentima da se loguju da bi mogli da skladište i postavljaju upite nad bazom njiovih kontakata i sastanaka • Upload appointments i Contacts use case će upload-ovati kopiju klijentovih sastanaka i kontakata na Web server radi postavljanja upita • Klijenti koji koriste bežične uređaje kao što su npr. mobilni telefoni zahtevaće drugu vrstu markup jezika za ove veoma ograničavajuće uređaje • S obzirom da su žični Web klijenti (desktop, laptop računari) i bežični Web klijenti (mobilni telefoni, PDA uređaji i sl.) slični, upotrebićemo generalizaciju slučajeva korišćenja kako bi ukazali da četiri specifična upita • Sve aktivnosti uploadovanja i postavljanja upita će biti proširena sa funkcionalnošću Log in slučaja korišćenja, jer korisnik mora biti prvo ulogovan da bi izvršavao bilo koji od datih use case-ova • Tim zatim razvija use case detalje prikazanih kroz use case specifikaciju i dijagrame aktivnosti. Takođe pronalaze sva scenarija za svaki use case da bi se obezbedila osnova za plan testiranja

11. Analiza • U fazi prikupljanja zahteva, razmatrali ste šta sistem mora da radi da bi izašao u susret zahtevima klijanata • U fazi analize, proširujete ovo razumevanje poslovnih problema tako što kreirate dijagram klase koji reprezentuje poslovni problem • S obzirom da se faza analize više bavi poslovnim problemom nego tehničkim rešenjem problema, ova faza kao i prethodna biće u osnovi slične kako za Web tako i Windows aplikacije • U ovoj studiji slučaja, treba analizirati kako će se sastanci predstaviti u sistemu • Analitičari kreiraju konceptualni dijagram klasa Friendly Reminder sastanaka i kontakata: • Klijent može da napravi 0 ili više sastanaka i nula ili više kontakata. • Svaki sastanak sadrži datum, vreme, opis, prioritet, beleške i kontakte koje su povezani za taj sastanak • Kontakt može biti svako o kome klijent želi da čuva informacije (ime, kućni tel, tel na poslu, email, adrese, beleške i dr.) • Kontakt ima dve asocijacije ka klasi Adrese, jedna za kućnu adresu, a druga za adresu na poslu

12. Arhitekturalni dizajn • U fazi dizajna, tim za projektovanje treba da sagleda način korišćenja Web tehnologija. UML će im pomoći u vizuelizaciji i specifikaciji ovih odluka. • Tokom inicijalne dizajn faze, treba da se donesu glavne arhitekturalne odluke – projekt arhitekta je odlučio da koristi Java servlete i JavaServer Pages za Web implementacije zbog njihove fleksibilnosti i robusnosti i zbog toga što tim već ima iskustva u programiranju sa Javom. • Model View Controller dizajn patern omogućava sagledavanje koda sa tri aspekta: • Model: kod koji se bavi sa modelom podataka, logikom baze podataka i direktnom manipulacijom podataka (poslovna logika za manipulaciju sa podacima i pristupom baze podataka, uglavnom napisana u Javi) • View: korisnički interfejs ili prezentacija podataka ka korisnicima (kod Web razvoja, to je Web sadržaj, npr. HTML) • Controller: kod koji reaguje na korisničke zahteve, modifikuje podatke i kontroliše tok aplikacije (kod koji proverava pristigle podatke u formi HTTP zahteva; u interakciji je sa modelom podataka i selektuje naredni pogled (Web stranu) koji treba da se pošalje korisniku) • Ova osnovna struktura je prikazana na slici desno • MVC se može primeniti na skoro sve aplikacije koje razvijate, bilo da su one Web zasnovane ili ne. • Jedna od važnijih prednosti MVC je ta što omogućava laku izmenu jednog aspekta sistema bez uticaja na druge aspekte

13. JavaBeans • Većina JSPs koristi mnogo Java koda kada treba da postavi upit i ažurira bazu, računa podatke kao i za druge operacije • Rezultat je da imate dosta Java koda unutar Web sadržaja – umesto HMTLa u Java kodu, vi imate Javu u vašem HTMLu • Jednostavan prelaz sa servleta na JSP nije dovoljno za uspešno odvajanje vašeg HTML pogleda od Java modela i controller-a – postoji drugi način da izdvojite Java kôd iz JSP strana • Jednostavno rešenje ovog problema bi bilo da izmestite veliki deo java koda sa vaše JSP strane u regularne Java klase, tako da JSP strana sadrži metode poziva ka metodama u ovim klasama. Sa ovim rešenjem otklonila bi se velika količina java koda iz JSP, ali bi JSP strana i dalje sadržala Java sintaksne metode poziva • JavaBeans je rešenje ovog problema – JavaBean je obična Java klasa sa privatnim atributima i javnim get/set metodama • Na slici je prikazan UML dijagram klase za jedan jednostavan JavaBean za praćenje porudžbine klijenta – kreiranje JavaBean-a je jednostavno kao što i zvuči • JSP ima specijalne markup tagove koji se mogu koristiti za pozivanje get i set metoda JavaBean-a – tako java syntax method calls mogu biti zamenjeni sa markup tagovima. Na primer, sintaksa Jave i JSP taga, prikazanih ovde, su ekvivalnente metode poziva • Kod koji ste izmestili iz JSP strana u JavaBeans uključiće i vaše podatke aplikacije, kôd pristupa bazi podataka i poslovne servise – ono što ostaje u vašem JSPu je uglavnom Web sadržaj, koji predstavlja pogled na te podatke; Korišćenjem JavaBeans-a možete odvojiti vaš pogled od vašeg modela i učiniti prvi korak ka MVC Web arhitekturi

14. MVC patern u studiji slučaja • Zahtevi studije slučaja su da korisnici mogu da postavljaju upite nad bazom sastanaka i kontakata kako sa tradicionalnih žičnih Web klijenata tako i sa bežičnih Web klijenta • Kod žičnih Web klijenata klijenti će pristupati sistemu preko Web browsera i sistem će generisati HTML za odgovarajući Web browser • Kod bežičnih Web klijenata, obično postoje određena ograničenja (input devices, mrežni opseg, nepouzdana raspoloživost mreže, ograničenja kod mogućnosti prikaza itd); zbog ovih ograničenja oni imaju svoje browsere, protokole i markup jezike (većina bežičnih Web klijenata ima mikro Web browser koji komunicira preko WAP protokola i interpretira Wireless Markup Language - WML, koji izgleda slično HTMLu, ali je kompaktniji u odnosu na zahteve bežičnih uređaja) • Sistem zahteva dva interfejs pogleda: HTML pogled i WML pogled; dok su osnovna poslovna logika i servisi podataka isti za oba interfejsa • S obzirom da JSP predstavljaju pogled na sistem, postoje dva skupa JSP strana: jedan sa HTML i drugi sa WML sadržajem - Oba JSPa komuniciraju sa istim JavaBeans-om za poslovnu logiku i manipulaciju sa podacima, što je i prikazano na slici

15. Dijagram uvođenja studije slučaja • Sledeće što treba razmotriti jeste da li sistem zahteva specijalni softver ili hardversku konfiguraciju za komunikaciju sa bežičnim Web klijentima • Bežični Web klijenti komuniciraju preko WAP protokola umesto preko HTTP protokola • S ozbirom da su tradicionalni Web serveri dizajnirani da komuniciraju koristeći HTTP protokol, možda ćete pomisliti da sistemu treba drugi Web server koji koristi WAP protokol • Provajderi bežične mreže imaju sisteme koje zovu WAP Gateways-i koji prevode između WAP i HTTP-a, a sve što treba da uradite je da napišete JSP strane koje sadrže WML, specifirate tip sadržaja i postavite ga na vaš normalan Web srever • WAP Gateway, koga obično obezbeđuje provajder bežične (mobilne) mreže, a ne vi, automatski vodi računa o ostatku - na slici je prikazan dijagram uvođenja sa hardverom (obično: žični uređaji, bežični uređaji, WAP Gateway i Web Server) i komponentama koje se nalaze (reside) na njima

16. Projektovanje Web aplikacije • Do sada smo parcijalno implementirali Web Model View Controller (MVC) dizajn odvajajući model u JavaBeans-e i poglede u JSP-je – ovakva parcijalna implelmentacija MVC paterna obezbeđuje mnoge prednosti, kao što je nezavisan razvoj, bolja kohezija, lako održavanje itd. • Radi potpune primene MVC arhitekture, treba takođe razdvojiti i controller elemente • Model 2 Architecture, koju je predstavio Sun Microsystems u ranijim verzijama servlet specifikacije, danas je popularno korišćena i diskutovana MVC arhitektura za Java Web aplikacije • Model 2 arhitektura je MVC arhitektura koja će razdvojiti controller elemente – na sledećim stranicama se prikazuju odgovarajući UML dijagrami komponenti i sekvenci ->

17. UML dijagram komponenti - Model 2 arhitektura

18. Dijagram sekvenci arhitekture Model 2 • Svi HTTP zahtevi za bilo koji deo Web aplikacije će biti usmereni na controller servlet koji će verifikovati ulazne podatke sa HTTP zahteva i pozivati metode JavaBeans-a radi ažuriranja podataka modela, zatim će forward-ovati zahtev JSPu koji će generisati odgovarajući pogled • JSP će pristupiti JavaBeans-u radi dobijanja podatka koji treba da se pojave na Web strani • Controller servlet arhitekture Model 2 nudi neke dodatne mogućnosti, usled toga što svi zahtevi za Web aplikacijom prolaze kroz jedan servlet, developer može da postavi generičku proveru bezbednosti i da prati kôd logovanja na servletu koji će se izvršavati za bilo koje zahteve ka bilo kojim delom Web aplikacije

19. Dijagram uvođenja, Model 2 arhitekture • Kao što je ranije diskutovano, dva JSPa su odvojena iz modela, te obično razvojni tim, radi potpune Model 2 arhitekture, dodaje jedan servlet koji će prihvatati sve zahteve poslatih od strane Web browsera za bilo koji deo Web aplikacije • Međutim, u ovoj studiji slučaja razvojni tim je odlučio da ima odvojene controller-e za žične i bežične Web klijente, tako da sada imaju dva servlet controller-a - njihova nova arhitektura je prikazana na slici:

20. Upload-ovanje sastanaka i kontakata • Do sada je razmotrena arhitektura koja će podržati ispitivanje (querying) baze podataka o sastancima i kontaktima, a sada treba razmotriti neophodnu arhitekturu koja će klijentima omogućiti upload-ovanje njihovih informacija o sastancima i kontaktima sa postojeće Visual Basic aplikacije u bazu podataka na serveru. • Ukoliko postojeća Visual Basic aplikacija bude direktno komunicirala sa bazom podataka, to će znatno umanjiti bezbednost sistema kao i njegovu prilagodljivost, jer će promena logike baze podataka zahtevati izdavanje nove verzije klijent aplikacije korisnicima. • Umesto toga, dizajneri projekta su odlučili da imaju Visal Basic aplikaciju koja će da okida (trigger) Java servlet koji će ubacivati podatke u bazu. • Sigurno se pitate kako Microsoft Visual Basic (VB) može da komunicira sa Java servletom? • Ovo nije nikakav problem jer bilo koja vrsta sistema može da generiše HTTP zahtev koji može da razgovara sa servletom. VB, kao i većina programerskih okruženja je savršeno sposobna da generiše HTTP zahtev kako bi komunicirala sa Java servletom • Dizajneri su odlučili da za te svrhe VB aplikacija komunicira sa novim controller servletom • Ovaj servlet neće koristiti nijednu JSP stranu, jer neće ni vraćati HTML ili bilo koji drugi Web sadržaj VB klijentu • VB klijent šalje sve podatke o sastancima i kontaktima ka Java servletu, servlet čuva podatke u bazi podataka i vraća broj snimljenih zapisa VB aplikaciji • Ovo je prikazano UML dijagramom uvođenja na sledećoj strani • Dizajn tim zatim razmatra koji format podataka da pošalje, jer žele čiste, verifikovane, adaptibilne formate. S obzirom da XML zadovoljava sve ove zahteve i predstavlja odličan način slanja podataka između sistema, odlučili su da pošalju podatke o sastancima i kontaktima u XML formatu.

21. Dijagram uvođenjaVisual Basic client

22. Detaljan dizajn • Projektni tim je do sada kompletirao arhitekturalni dizajn sistema visokog nivoa; izabrane su tehnologije koje će koristiti – dijagrami komponenti i uvođenja prikazuju kako će različite Web tehnologije biti organizovane • Detaljan dizajn će specificirati kako će svaki pojedinačni deo sistema biti implementiran – više će se crtati dijagrami klasa, objekata, sekvenci i kolaboracije • U fazi detaljnog dizajna, dizajneri (projektanti) će kreirati jednu mapu (roadmap) za programere prikazujući im kako će browseri, servleti, JSP strane, JavaBeans i baze podataka raditi zajedno i omogućiti klijentima ispitivanje podataka o sastancima i kontaktima • Razvojni tim prvo pravi dijagram kolaboracije koji pokazuje kako će se korisnici pomerati sa Web strane na drugu Web stranu – s obzirom da pokazuje samo ono šta će korisnik videti, ovaj dijagram će samo da sadrži JSP strane • Dijagram prikazuje da korisnik mora da koristi Login JSP stranu da bi se ulogovao, nakon čega bi mogao da pristupa AppointmentQueryForm JSP strani - ova forma će omogućiti korisnicima da unesu kriterijume za sastanke koje žele da pregledaju • Kada pošalje upit i ukoliko se rezultati poklapaju, biće mu poslat AppointmentQueryResults JSP strana koja će prikazivati ove rezultate • Ukoliko nema odgovarajućih rezultata, poslaće mu se JSP strana No Appopintments, koja će ga informisati da ne postoje parovi za zadati upit

23. Dijagram kolaboracije - postavljanje upita nad bazom sastanaka i kontakata

24. Razvoj dijagrama sekvenci • Dizajn tim, zatim, modeluje kako će se prethodni dijagram implementirati u sistemu • Za ove svrhe razvija se dijagram sekvenci koji prikazuje sve uključene komponente • Radi jednostavnosti, tim je odlučio da na dijagramu sekvenci ne prikaže proces Login, već da počnu sa zahtevom u obliku upita • Svi zahtevi od Web browsera idu ka controller servletu • Inicijalni zahtev ka servletu se prosleđuje JSP strani AppointmentQueryForm tako da će se korisniku prikazati forma upita da bi mogao da napravi zahtev • Kada korisnik popuni i pošalje ovu formu, servlet šalje zahtev (upit) ka JavaBeans-u da izvrši upit i vrati rezultate • Ukoliko upit bean-a vrati neke sastanke, onda se zahtev prosleđuje AppointmentQueryResults JSP strani tako da ih korisnik vidi • Ukoliko nema parova zahtev se forward-uje ka NoAppointments JSP strani

25. Dijagram sekvenci – implementacija upita o sastancima

26. Implementirane Web tehnologije na dijagramu klasa • Ukoliko želite da prikažete JSP strane, servlete, HTML sadržaj, JavaScript i druge Web tehnologije na dijagramu klasa, onda ih možete prikazati na sledeći način: • Servleti su obične klase u Javi tako da se one mogu normalno prikazati na dijagramu klasa • Servleti prikazuju JSP strane, tako da se jednostavno mogu prikazati servlet klase koje su generisane od JSP strane • Servleti nisu u relaciji asocijacije sa JSP stranama, već između njih postoji relacija zavisnosti jer oni preusmeravaju HTTP zahtev ka JSP strani • JSP strana gradi HTML strane i one sadrže HTML forme i JavaScript-ove

27. XML • XML je u poslednjih godina postao izuzetno popularan alat za prenos podataka u sve više sistema • XML dokumenti se mogu proveriti (validated) sa XML šemom ili DTD (Document Type Definitions) • Šema definiše pravila za sva dokumenta određenog tipa • Odnos između šema i dokumenata je kao odnos između dijagrama klasa i objektnog dijagrama – objektni dijagram prikazuje skup objekata koji prate pravila i relacije definisane dijagramom klasa • XML dokument ima skup podataka koji prate pravila i relacije definisane XML šemom • XML šema može da odredi: koji podaci će se skladištiti u dokumentima, strukturalne asocijacije između podataka, multiplikativnosti (koliko je od jednog tipa objekata entiteta pridružen drugom tipu i tipovima podataka) • Prednosti korišćenja XMLa su: • XML je jednostavan i efektivan način za skladištenje podataka • Validacioni alati mogu automatski da proveravaju XML dokument u odnosu na šemu • Alati raščlanjivanja (parsing) mogu automatski da parsiraju podatke iz XML dokumenta • Šeme omogućavaju da standardizujete strukture podataka tako da se možete dogovoriti sa vašim partnerima da delite podatke u standardnom formatu • XML dokumenta se mogu lako deliti od strane virtuelno bilo koje kombinacije programskog okruženja

28. UML modelovanje XMLa • XML ima hijerarhijsku strukturu koja se može modelovati kao hijerarhija objekata u UMLu koristeći generalizaciju u dijagramu klasa • XML šeme se mogu generisati iz dijagrama klasa ili iz objektnog dijagrama • OMG (Object Management Group) koja održava UML specifikaciju, takođe održava XML MetaData Interchange (XMI) specifikaciju – ova specifikacija opisuje standard za mapiranje UML modela u XML • Primarna svrha ove specifikacije je bila kreiranje industrijskog standrarda za UML alate modelovanja radi delenja UML modela • Mnogi UML alati imaju opciju da sačuvaju UML model kao XML fajl prema XMI – ovo znači da možete da počnete da razvijate vaš UML model u jednom UML alatu za modelovanje, da ga sačuvate u tom standardnom formatu, a zatim ga puniti u bilo koji drugi UML alat za modelovanje koji podržava XMI specifikaciju • Funkcionalnosti XMI su korisne i za generisanje XML šema i dokumenta za jednu aplikaciju koja se zasniva na aplikaciji UML modela

29. XML dokument za studiju slučaja • Razvojni tim je odlučio da koristi XML za prenos podataka o sastancima i kontaktima iz postojeće VB aplikacije u Java servlet koji će čuvati podatke u bazi • Projektanti treba da odluče koju strukturu XML dokumenta i šemu će koristiti za prenos podataka • Prvi korak je da preurede dijagram klasa koji prikazuje kako su podaci o sastancima i kontaktima povezani • Proveravaju da ne nedostaju atributi i asocijacije, da svi atributi imaju tip podataka, da je prikazan smer relacija i da se prikazuju uloge na relacijama – tim dodaje tabelu PriorityLevel koji određuje vrednosti za atribut Priority klase Sastanci (Appointment)

30. XML dokument za studiju slučaja • Kao što je već pomenuto, dijagrami klase su uporedivi sa XML šemama – oba definišu pravila organizovanja podataka • Razvojni tim može da koristi XMI funkcionalnost alata za modelovanje da bi automatski generisao XML šemu iz dijagrama klasa • Na slici je prikazan objektni dijagram koji predstavlja validno instanciranje dijagrama klasa sa prethodne slike i ima iste podatke i strukturu kao i XML dokument

31. XML dokument za sastanke • Objektni dijagram sa prethodne strane se mapira u XML dokument prikazanog ovde • Objekat korisnik postaje <user> element koji sadrži podelemente za svaki atribut klase korisnik • Svaki atribut, npr. <User.name> sadrži vrednosti atributa koja se prikazuje do krajnjeg taga </User.name> • Link od korisnika ka sastancima je prikazana kao podelement <user> elementa i sadrži sve atribute u klasi Sastanci