Prof. dr Angelina Njeguš Vanredni profesor Univerziteta Singidunum anjegus@singidunum.ac.rs

1. Prof. dr Angelina Njeguš Vanredni profesor Univerziteta Singidunum anjegus@singidunum.ac.rs Beograd, 2008/2009. Objektno-orijentisana analiza i projektovanje sa UML-omDEV475 Mastering Object-Oriented Analysis and Design with UML - Volume 3, Dodatak

2. Dodatak:ObjectStore mehanizam • Stereotip <<role>> se koristi da prikaže koje klase treba da budu popunjene od strane dizajnera • Operacije koje su definisane u SampleDBManager su specifične za klase koje su perzistentne • Svaka operacija perzistentne klase koja ažurira podatke klase treba da bude iskopirana u klasi SampleDBManager • Npr. ukoliko postoji klasa MojaKlasa koja sadrži dve operacija op1() i op2(), onda će SampleDBManager klasa uključiti i operacije: NewMojaKlasa(), UpdateMojaKlasa, DeleteMojaKlasa(), doMojaKlasaOp1() itd. • “Objekti postaju perzistentni kada su referencirani od strane drugih perzistentnih objekata” • Klijenti su u interakciji (interfejsu) sa SampleDBManager klasom da bi dobili pristup objektima perzistentne klase (PersistentClass) u bazi podataka; • klijent može da kreira novu instancu perzistentne klase sa operacijom newClass() ili da poziva naredbu perzistentne klase sa operacijom command(); • Klijent inicijalizuje i gasi bazu podataka ObjectStore kroz klasu SampleDBManager • U kontekstu ObjectStore baze podataka, perzistentna klasa PersistentClass se smatra “root class”-om

3. Primer: ObjectStore: SampleDBManager • SampleDBManager obezbeđuje jednu ulaznu tačku u ObjectStore bazu podataka • Postoji jedna SampleDBManager klasa po instanci ObjectStore baze podataka • SampleDBManager sadrži kod npr. za početak i kraj transakcija • Klasa Database je ObjectStore klasa koja predstavlja aktuelnu ObjectStore bazu podataka; • pre nego što počnete sa kreiranjem perzisentnih objekata, morate kreirati bazu podataka koja će čuvati objekte; aplikacija može istovremeno da pristupa ka više instanci baze podataka • Map je perzistentni map container klasa koja skladišti parove ključ/vrednost sa jedinstvenim ključem; ne morate koristiti samo klasu Map kao kolekciju, već možete i bilo koju drugu • Klasa ObjectStore definiše operacije na sistemskom nivou koje nisu specifične za bilo koju bazu podataka • Baza podataka Session mora biti kreirana da bi se pristupalo bazi i bilo kojim perzistentnim podacima. Sesija je kontekst u kojem je ObjectStore baza kreirana i otvorena i u kojoj se izvršavaju transakcije • Svim perzistentnim objektima se mora pristupati unutar transakcije ObjectStore. U sesiji može da se izvršava samo po jedna transakcija

4. Primer: ObjectStore: inicijalizacija • Kada se jednom kreira i pridruži sesija, SampleDBManager mora da otvori i kreira novu bazu; • Da bi kreirali bazu, SampleDBManager kreira novu transakciju i kreira koren “root” baze sa operacijom createRoot(); • Root je tačka ulaska u bazu podataka • Kada se kreira koren, transakcija se potvrđuje “commit”

5. Primer: ObjectStore: Create • Da bi kreirao novu instancu PersistantClass u bazi podataka, prvo SampleDBManager mora da kreira transakciju i da pozove konstruktor za PersistentClass • Jednom kada se kreira klasa dodaje se bazi putem root operacije “put()” • Transakcija se potvrđuje

6. Primer: ObjectStore: Read • Da bi čitali objekat, SampleDBManager prvo kreira novu read-only transakciju koja pretražuje objekat korišćenjem root operacije get() • Kada se objekat pronađe, čita se sa metodom getData() i transakcija se potvrđuje • Čim je transakcija potvrđena, objekat se može ažurirati

7. Primer: ObjectStore: Update

8. Primer: ObjectStore: Delete

9. Primer: ObjectStore: Shutdown • Da bi se baza ugasila, SampleDBManager mora prvo da zatvori bazu, a zatim da prekine sesiju

10. Primer: Registracija na kurs • Spisak studenata registrovanih na kurs sadrži više studenata gde je za svakog studenta pridružen najmanje jedan raspored, a svaki raspored ima grupu ponuda kurseva • Ukoliko treba da se implementira prethodni scenario, tada je potrebno nekoliko klasa kolekcija za sve 1-prema-više veze • Root nije ništa drugo do tačka pristupa bazi podataka, jedan od načina postavljanja upita nad bazom • U ovom primeru možemo izabrati više korenskih klasa: Spisak, Student i Raspored • Root je kolekcija klasa koja podržava ObjectStore upite • Pregled koraka implementacije ObjectStore mehanizma: • Obezbediti pristup bibliotekama klasa neophodnih za impelementiranje ObjectStore pristupa • Izabrati root klasu baze podataka • Jedna od važnijih odluka kod uključivanja ObjectStore mehanizma u vaš dizajn je koju korensku klasu (root) izabrati – u ovom primeru je izabrana klasa Student • Izabrati kontejner klasu koja će služiti kao root baze podataka (koja će sadržati, skladištiti izabrane root klase) – izabrana klasa kontejner je specijalna struktura podataka • U ovom primeru odabrana je mapa kao kolekcija klase, a jedinstveni ključ pristupa studentima je StudentID • Kreirati DBManager (jednog po instanci ObjectStore baze podataka) • U ovom primeru biće jedan ObjectStore baza, Course Registration Database koja sadrži informacije o studentima i rasporedima za univerzitetu. Stoga, postojaće jedan CourseRegDBManager koji će biti u novom paketu ObjectStore • Dodati operacije DBManager-u kako bi se pristupalo objektima u OODBMS • Kreirati operacije za studente i rasporede (radi pristupa informacijama o studentima i rasporedima) • Kreirati Create/Update dijagrame interakcija koji opisuju: • Inicijalizaciju i prekidanje baze podataka • Pristup perzistentnim klasama: Create, Read, Udate, Delete • Implementirati perzistentne klase • Dodati iskaz “import com.odi.*”

11. Primer: ObjectStore • CourseRegDBManager kontroliše pristup perzistentnoj klasi Student i njegovim rasporedima (Schedules) • Operacije za pristup Rasporedu su dodate u CourseRegDBManager koji upravlja detaljima oko punjenja studenta pre pristupa rasporedu

12. Primer: ObjectStore (nastavak) • Kreira se paket ObjectStore Support koji sadrži poslovne elemente dizajna • CourseRegDBManager-u će biti potrebno da elementi dizajna podržavaju ObjectStore mehanizam, te se stoga dodaje relacija zavisnosti između paketa ObjectStore Support i com.odi (odi je skraćenica od naziva kompanije koja je napravila Object Design: Object Design, Inc.) • S obzirom da će CourseRegDBManager klasi biti potrebno da ima pristup perzistentnim klasama, dodaje se relacija zavisnosti između paketa ObjectStore Support i University Artifacts

13. Primer: inicijalizacija baze podataka ObjectStore pri start-up-u sistema

14. Primer: prikaz zatvaranja baze

15. Primer: prikaz čuvanja iili ažuriranja Schedule klase

16. Primer: prikaz čitanja info o Studentu

17. Primer: prikaz brisanja Studenta

18. Primer: uključivanje ObjectStore

19. Primer: uključivanje ObjectStore (nastavak)

20. Primer: online phonebook • Kreiranje Java aplikacije online adresara (phonebook) koja omogućava unos telefona, postavljanje upita, ubacivanje, izmenu i brisanje funkcionalnosti • Aplikacija se pokreće Admin klasom, a sloj podataka se sastoji od četiri klase: Phonebook, PhonebookEntry, PhoneRegion i PhoneRegionList • Klasa XMLPhoneEntries parsira i prihvata telefone koji su uskladišteni u XML fajl radi batch upload-ovanja

21. Razvoj aplikacije • I korak: Obezbediti pristup bibliotekama klasa neophodnih za impelementiranje ObjectStore pristupa Code: Phonebook Import Statements import com.odi.*; import com.odi.util.*; import com.odi.util.query.*; import java.util.Map; import java.util.Set; import java.util.Iterator; import java.util.Collection;

22. Razvoj aplikacije - nastavak • II korak: kreirati bazu podataka i sesiju ka njoj Code: Phonebook Database and Session Setup public Phonebook() { session = Session.create(null, null); session.join(); try { db = Database.open(database, ObjectStore.UPDATE); } catch (DatabaseNotFoundException e) { db=Database.create(database, ObjectStore.ALL_READ | ObjectStore.ALL_WRITE); }

23. Razvoj aplikacije - nastavak • III korak: kreirati ulaznu tačku u OODB (slično definisanju naziva relacione tabele). • U ovom slučaju proveramo da li postoji ulazna tačka “entries”, ukoliko ne postoji kreiramo novu OSHashMap sa nazivom “entries”, u okviru koje ćemo skladištiti objekte PhonebookEntry klase. • OSHashMap je u osnovi podklasa java.util.Map sa dodatim funkcionalnostima i perzistentnim mogućnostima Code: Phonebook Entry Point Transaction t = Transaction.begin(ObjectStore.UPDATE); try { entries = (OSHashMap) db.getRoot("entries"); } catch (DatabaseRootNotFoundException e) { db.createRoot("entries", entries = new OSHashMap()); } t.commit(ObjectStore.RETAIN_READONLY); }

24. Razvoj aplikacije - nastavak • Važno je da se adekvatno završi sesija i prekine sa korišćenjem resursa baze podataka pre nego što se aplikacija završi • Ovu metodu bi trebalo eksplicitno pozvati, jer se metoda finalize() ne izvršava na predvidljiv način Code: Phonebook Cleanup public void close() { db.close(); session.terminate(); }

25. Razvoj aplikacije - nastavak • IV korak: Kreiranje perzistentne klase • Phonebook klasa predstavlja interfejs ka OODB • Klase PhoneRegion i PhoneEntry bi trebalo obraditi kako bi bile spremne za skladištenje u bazi podataka • Naredba osjcfp (ObjectStore Java Class Post-processor) uzima Java class fajlove i dodaje dodatne informacije o ovim klasama kako bi podržale OODB – • ova naredba generiše brojne fajlove koji se smeštaju u odvojene direktorijume (određene sa –dest). • Naredba takođe treba da zna koji class fajl treba prethodno obraditi (post-process). • U ovom slučaju obrađuje se fajl PhonebookEntry.class Code: Makefile Post-Processing of Stored Objects osjcfp -dest ./pData -pc PhoneApp/Data/PhonebookEntry.class

26. Razvoj aplikacije - nastavak • Database Inserts – jedan ili više objekata se skladišti u OODB; • Ubacivanje objekata mora da se izvrši nakon uspostavljanja sesije i kreiranja baze podataka; • Novi objekat PhonebookEntry se kreira pre insert-ovanja, nakon čćega se proverava validnost formata, polja i dr. • Pre ubacivanja treba započeti transakciju; ukoliko objekat već postoji u bazi sa istim primarnim ključem (phone number), ubacivanje (insert) se prekida (abort); inače ubacuje se u OSHashMap “entries” imenovani ključem tj. brojem telefona (phoneNumber) kao entry; • Kada se unosi objekat, unose se i svi njegovi atributi zajedno sa tipom podatka i vrednošću • Nakon uspešnog unosa, transakcija se potvrđuje (commit) i zatvara (close) Code: Phonebook Management of PhonebookEntry Inserts public void addEntry(String firstName, String lastName, ...) { PhonebookEntry entry = new PhonebookEntry(firstName, lastName, ... ); if ( entry.isValid() ) { Transaction t = Transaction.begin(ObjectStore.UPDATE); if (entries.get(phoneNumber) != null) { t.abort(ObjectStore.RETAIN_READONLY); System.out.println("Entry already exists."); } else { entries.put(phoneNumber, entry); t.commit(ObjectStore.RETAIN_READONLY); } } else { System.out.println("Invalid entry (" + entry.toString + ")"); } }

27. Razvoj aplikacije - nastavak • Izvršavanje upita – • u ovom primeru traže se PhonebookEntry objekti čija imena sadrže John (firstName = “John”); • Kad se upit izvrši, pomoću Iteratora prolazi se kroz sve rezultate i prihvataju se odgvarajući PhonebookEntry objekti, a zatim poziva metoda toString kako bi se dobio tekstualni prikaz Code: Simple Queries in the Phonebook Class Query query = new Query(PhonebookEntry.class,"firstName == \"John\""); Collection queryResults = query.select(entries.values()); String[] results = new String[queryResults.size()]; Iterator resultIterator = queryResults.iterator(); int count = 0; while(resultIterator.hasNext()) { PhonebookEntry tmpEntry = (PhonebookEntry)resultIterator.next(); results[count] = tmpEntry.toString(); count++; }

28. Razvoj aplikacije - nastavak • Izvršavanje ažuriranja – • Objekat se uzima iz hash mape koristeći phone number kao ključ • nakon izmene objekta, potvrđuje se transakcija Code: Updating existing PhonebookEntry Objects Transaction t = Transaction.begin(ObjectStore.UPDATE); PhonebookEntry entry = (PhonebookEntry) entries.get("555-123-4567); entry.setFirstName("Steve"); } t.commit(ObjectStore.RETAIN_HOLLOW);

29. Dodatak:Mehanizam bezbednosti (security mechanism) Packages in the system being developed that mightdepend upon the security packages. • GUI framework obezbeđuje standardni skup UI klasa • Radi bezbednosti, UI obezbeđuje login ekran koji radi sa poslovnim objektom na server strani; ovaj server objekat će ostati na raspolaganju svim kontrolama u toku trajanja sesije • Security Manager podsistem uključuje klase koje implementiraju ponašanje bezbednosti • Secure Interfaces – entiteti koji su bezbedni će realizovati interfejs i obezbediti manji skup ponašanja Reused components from the Implementation Model Representation of components in the DesignModel Here we are reverse engineeringexisting components into the Implementation and Design Model (Three reusable components – one is a GUI framework; other two support security on the server)

30. Primer: Security mechanism MainApplicationFormkeeps a referenceto a ISecureUser obj until the form closes(this is represented bythe compositionrelationship). • Bezbedni korisnik (ne podaci)! • Stereotip <<role>> se koristi da identifikuje koje klase i role treba da razvije dizajner da bi primenile mehanizam bezbednosti • Za svaku sesiju aplikacije, mora postojati klasa čiji objekat realizuje ISecureUser interfejs (npr. UserSecurityContext klasa) • Ovaj objekat upravlja informacijama o trenutnom korisnikovom pristupu bezbednosnim podacima bez direktne zavisnosti od klasa (ISecureUser klase zavise od interfejsa ISecureData, a ne od aktuelnih bezbednostnih podataka klasa) • Sistem bezbednosti, preko operacija prikazanih u ISecureUser, omogućava klijentima da postave pristup objektima kada se kreiraju i proveravaju pristup tim objektima kada se oni kasnije koriste • Postoji jedna instanca SecurityAccess po user login/sesiji po bezbednosnom objektu This is a secureentry; “Realizes”the ISecureUserInterface. The reference to the ISecureUser object actually comes backfrom the LoginForm, which creates the ISecureUser object upon successful logon (this is represented by the dependencyrelationship) The UniqueID classmakes sure that all users and allpieces of data from all different applicationsget their own unique ids.

31. Primer: security mechanism:Secure User Set-Up at Login • Za svaku sesiju aplikacije, mora da postoji jedan objekat čija klasa realizuje ISecureUser interfejs. • Ovaj objekat upravlja informacijama o trenutnom korisnikovom pristupu bezbednom podatku. • LoginForm će (nakon uspešnog logovanja) kreirati instancu ISecureUser

32. Primer: Security mechanism: Prikaz kako podforme i kontroler obezbeđuju pristup bezbednoj korisničkoj sesiji • Svi unosi koji treba da izvršavaju proveru pristupa moraju da imaju pristup trenutnoj korisnikovoj sesiji (tj. da imaju pristup ka ISecureUser) • Ovak dijagram pokazuje kako podforma i pridruženi controller obezbeđuju pristup bezbenoj korisnikovoj sesiji. • Bezbedna korisnička sesija se uspostavlja tokom login-a i održava je MainApplication Form.

33. Sve klase koje su mapirane ka mehanizmu analize Security treba da realizuju interfejs ISecureData Sve klase koje moraju da verifikuju pristup nekom bezbednom podatku treba to da urade preko interfejsa ISecureUser Biće jedan objekat čija klasa realizuje interfejs ISecureUser po sesiji Kada se prihvataju bezbedni podaci, klijent mora da verifikuje trenutnog korisnika da li ima dozvolu pristupa podacima (preko infomracija o bezbednom pristupu – security access) Na dijagramu je prikazano da nakon prihvatanja objekta koji realizuje ISecureData interfejs, Secure Object Client mora da prihvati security access info za secure object za trenutnog usera i da ga uporedi kako bi se osigurao da trenutni korisnik može da gleda/edituje/briše objekat. Primer: bezbedni pristup objekta

34. Pregled koraka implementacije mehanizma bezbednosti • Obezediti pristup bibliotekama klasa koje su potrebne za implementaciju mehanizma bezbednosti • Kreirati novi Security paket koji će da sadrži klase koje će da implementiraju mehanizam bezbednosti • Kreirati glavnu formu aplikacije sa pridruženim login formama • Paket koji sadrži forme zavisi od paketa Security GUI Framework • Kreirati glavne forme aplikacije • Neka sve bezbedne klase realizuju interfejs ISecureData • Paket koji sadrži ključne tipove podatka zavisi od paketa Security Secure Interface • Dodati relacije realizacije • Obezbediti bezbednu korisničku sesiju pristupa gde je potrebno • Paket koji sadrži kontrolne klase zavisi od paketa Security GUI Framework • Kontrolne klase zahtevaju bezbedni pristup sesiji korisnika • Dodati setSession(IsecureIUser) operacije • Kreirati/ažurirati dijagrame interakcija sa bezbednosnom obradom • Bezbedni login korisnika • Bezbedna sesija korisnika • Bezbedan pristup podacima (provera dozvola pristupa)

35. Primer: uključivanje mehanizama bezbednosti u model registracije kurseva

36. Primer: uključivanje mehanizma bezbednosti • Sample Application package sadrži glavne application forms-e i stoga zavisi od GUI Framework-a. • Sample Secure Data package sadrži klase koje treba da budu bezbedne te su zavisne od Security Secure Interfaces paketa • Sample Application package sadrži klase koje treba da pristupaju bezbednim klasama te će stoga zavisiti od Security Secure Interfaces paketa.

37. Primer: uključivanje Security mechanism-a • Naredni primeri ukazuju na izmene koje je potrebno uraditi na prethodnim slajdovima kako bi se uključio mehanizam sigurnosti • LoginForm iz security GUI framework će biti zamenjen LoginForm-om koja je identifikovana use case analizom • Klasa Schedule mora biti bezbedna tako da će realizovati interfejs ISecureData • Klase kontrole RegistrationController će zahtevati pristup bezbednoj sesiji korisnika, tako da će se dodati operacija setSession(ISecureUser)

38. Primer: uključivanje Security mehanizma (nastavak)

39. Primer: uspostavljanje bezbedne sesije korisnika

40. Primer: kontrole izvršavaju bezbednosne provere

41. Primer: bezbedan pristup podacima

42. Primer: View of Participation Classes (VOPC)

43. Napomena (Note) se može dodati bilo kom UML elementu Dodatak:Mapiranje UML-a u Javu

44. Vidljivost atributa i operacija

45. Domen atributa i operacija

46. Grupisanje globalnih atributa i operacija

47. Sakrivanje klasa koje su relevantne samo za implementaciju

48. Asocijacije u oba smera • Klase koje su deklarisane u istom Java paketu mogu da vide jedna drugu

49. Jednosmerne asocijacije

50. Pravila asocijacije • Pravila na krajevima asocijacije mogu da pojasne