© K.Subieta. Podejście stosowe 05, Folia 1 Podejście stosowe do obiektowych języków programowania baz danych Wykład 05 Abstrakcyjne modele składu obiektów Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

© K.Subieta. Podejście stosowe 05, Folia 2 Złożoność modeli obiektowych (1) Istniejące modele obiektowe są bardzo złożone. Model obiektowy standardu ODMG włącza dużą liczbę pojęć takich jak: obiekty, literały, typy, podtypy, interfejsy, dziedziczenie, przesłanianie, polimorfizm, kolekcje, struktury, związki, operacje, wyjątki i inne. Jeszcze bardziej złożony jest model SQL-99, ponieważ do wymienionych pojęć dokłada (co najmniej) relacje i abstrakcyjne typy danych (ADT). Zasadniczy udział w tej złożoności mają cechy drugorzędne i brak dążenia do upraszczania i redukcji pojęć, eliminacji pojęć drugorzędnych i zastępowanie bardziej specyficznych pojęć przez pojęcia bardziej ogólne. Konsekwencją złożoności modelu obiektowego jest złożoność języka zapytań, w szczególności jego semantyki, ponieważ każda cecha modelu obiektowego musi mieć swoje odbicie w składni, semantyce i w pragmatyce języka bazującego na tym modelu. Precyzyjna semantyka języka oznacza konieczność zdefiniowania zbioru wszystkich stanów (zbioru Stan). Złożoność modelu obiektowego powoduje złożoność definicji tego zbioru i w konsekwencji złożoność definicji języka.

© K.Subieta. Podejście stosowe 05, Folia 3 Złożoność modeli obiektowych (2) Złożoność oznacza zwiększenie trudności przy formalnej analizie semantyki, czyli utrata kontroli nad uniwersalnością języka oraz znaczne zmniejszenie potencjału dla optymalizacji zapytań. Obecny świat informatyki przemysłowo-komercyjnej nie docenia problemu semantyki języków zapytań oraz optymalizacji zapytań. Dla SQL-99 lub OQL nie można zbudować modeli formalnych z powodu zasadniczych wad ich specyfikacji i licznych niespójności. Brak modelu formalnego uniemożliwia wnioskowanie o semantycznie równoważnych przekształceniach optymalizacyjnych. Z tego powodu konieczne staje się uproszczenie modeli obiektowych i/lub taka abstrakcja nad tymi modelami, która byłaby formalnie prosta i jednocześnie dostatecznie wiernie oddawałaby modele praktyczne. Modele obiektowe wprowadzają dużo pojęć, często różnie rozumianych. Nie jest możliwe zbudowanie pojedynczego modelu formalnego. Będziemy opierali się o pewną rodzinę modeli, z tą samą bazą pojęciową.

© K.Subieta. Podejście stosowe 05, Folia 4 Abstrakcyjne modele składu obiektów AS0: obejmuje dowolnie powiązane hierarchiczne struktury danych; nie obejmuje klas, dziedziczenia, interfejsu i hermetyzacji. Model AS0 pozwala wyjaśnić semantykę relacyjnych języków zapytań (szczególnie SQL), przykrywa koncepcję zagnieżdżonych relacji, struktury implikowane przez XML i dane określane jako pół-strukturalne. AS1: uzupełnia AS0 o pojęcia klasy, dziedziczenia i wielodziedziczenia w najczęściej spotykanym rozumieniu; nie obejmuje hermetyzacji i interfejsu. AS2: uzupełnia model AS1 oraz nieco go modyfikuje wprowadzając dziedziczenie pomiędzy obiektami oraz dynamiczne role. Można go również uważać jako model odwzorowujący koncepcję wielu interfejsów do obiektu. AS3: uzupełnia model AS0 lub AS1 o pojęcie hermetyzacji - podział własności klas i obiektów na publiczne i prywatne. Podana rodzina modeli nie zamyka tematu. object store

© K.Subieta. Podejście stosowe 05, Folia 5 Pojęcia wspólne dla modeli AS0, AS1, AS2 i AS3 Wewnętrzny identyfikator obiektu. Jest nadawany automatycznie przez system i nie posiada semantyki w świecie zewnętrznym. Jest nieczytelny. Jest unikalny dla danego obiektu. Służy do identyfikacji obiektów w pamięci komputera. Nie będziemy zajmować się budową identyfikatorów ani ich specjalizowaniem w zależności od rodzaju obiektu lub pamięci. Zewnętrzna nazwa obiektu. W odróżnieniu od wewnętrznego identyfikatora, zewnętrzna nazwa jest nadawana przez projektanta, programistę lub administratora. Jest powiązana z modelem koncepcyjnym lub biznesowym aplikacji działających na bazie danych. Posiada (nieformalną) semantykę w świecie zewnętrznym. Np. taką nazwą może być Klient lub Zarobek. W odróżnieniu od wewnętrznego identyfikatora, zewnętrzna nazwa nie musi być i zwykle nie jest unikalna. Wartość atomowa. Wartość atomowa jest z naszego punktu widzenia niepodzielna, nie posiada wyróżnialnych składowych. Wartość atomowa może być liczbą, stringiem, blobem, ciałem metody, perspektywy, procedury, reguły, itd.

© K.Subieta. Podejście stosowe 05, Folia 6 Model AS0 I - zbiór identyfikatorów (i, i 1, i 2,... - oznaczenia identyfikatorów) N - zbiór nazw (n, n 1, n 2,... - oznaczenia nazw) V - zbiór wartości atomowych (v, v 1, v 2,... - oznaczenia wartości) Obiekt atomowy: trójka. Obiekt pointerowy: trójka. Obiekt jest identyfikowany przez i 1, natomiast i 2 jest pointerem (referencją) do innego obiektu. Obiekt złożony: trójka, gdzie T jest zbiorem dowolnych obiektów. Powyższa reguła umożliwia rekurencyjne tworzenie obiektów o nieograniczonej złożoności i o nieograniczonej liczbie poziomów hierarchii. Skład obiektów jest zdefiniowany jako para, gdzie S jest zbiorem obiektów, zaś R jest zbiorem identyfikatorów "startowych. Zbiór R wyznacza punkty wejściowe do składu obiektów, tj. obiekty "korzeniowe" (root objects), które mogą być początkiem wyszukiwania w zbiorze przechowywanych obiektów.

© K.Subieta. Podejście stosowe 05, Folia 7 Ograniczenia w modelu AS0 Każdy obiekt, podobiekt, itd. w składzie posiada unikalny identyfikator. Jeżeli (na dowolnym poziomie hierarchii obiektów) wystąpi obiekt pointerowy, to powinien istnieć również obiekt posiadający identyfikator i 2. Warunek oznacza brak zwisających pointerów (lub tzw. integralność referencyjną). Dowolny identyfikator ze zbioru R jest identyfikatorem pewnego obiektu znajdującego się w składzie. Będziemy abstrahować od obiektów, które nie są osiągalne ze zbioru R, bezpośrednio lub pośrednio. Obiekt bezpośrednio osiągalny posiada identyfikator ze zbioru R. Obiekt jest osiągalny, jeżeli jest bezpośrednio osiągalny lub jest podobiektem obiektu osiągalnego. Obiekt jest także osiągalny, jeżeli posiada identyfikator i 2 oraz jest osiągalny obiekt pointerowy. Obiekty nieosiągalne nie są w stanie wpłynąć na wynik ewaluacji zapytań; są one tzw. nieużytkami (garbage) i mogą być w dowolnym momencie skasowane.

© K.Subieta. Podejście stosowe 05, Folia 8 Przykład składu w modelu AS0 Dział [0..*] Nazwa Lokacja[1..*] Diagram klas PracujeW Zatrudnia [1..*] Prac [0..*] Nazwisko Zar Adres [0..1] Miasto Ulica NrDomu S - Obiekty:,, } >,,, } >,,,, } >,,,, } >,,, } > R - Identyfikatory startowe: i 1, i 5, i 9, i 17, i 22

© K.Subieta. Podejście stosowe 05, Folia 9 Poglądowy obraz małej bazy danych i 1 Prac i 2 Nazwisko Nowak i 3 Zar 2500 i 4 PracujeW i 5 Prac i 6 Nazwisko Kowalski i 7 Zar 2000 i 8 PracujeW i 9 Prac i 10 Nazwisko Barski i 11 Zar 900 i 16 PracujeW i 13 Miasto Radom i 14 Ulica Wolska i 15 NrDomu 12 i 12 Adres i 17 Dział i 18 Nazwa Produkcja i 19 Lokacja Kielce i 21 Zatrudnia i 20 Lokacja Kraków i 22 Dział i 23 Nazwa Sprzedaż i 24 Lokacja Radom i 25 Zatrudnia i 26 Zatrudnia

© K.Subieta. Podejście stosowe 05, Folia 10 Modelowanie zmiennych języka programowania Nie będziemy robić rozróżnienia pomiędzy pojęciem języków programowania określanym jako zmienna oraz wprowadzonymi przez nas obiektami. Np. zmienna x z języka programowania posiadająca aktualną wartość 5 będzie w naszych modelach składu reprezentowana jako trójka, gdzie i jest pewnym identyfikatorem wewnętrznym tej zmiennej, np. jej adresem w pamięci operacyjnej. Nie będziemy również rozróżniać pojęcia zmiennej i pojęcia obiektu na zasadzie: obiekt posiada swoją klasę, zaś zmienna nie posiada klasy. Wszystkie obiekty posiadają klasę, ale dla niektórych obiektów są one puste (nie zawierają żadnych inwariantów), wobec czego są pomijane. Model AS0 nie ma klas, ale wprowadza obiekty (inaczej zmienne). Nie zajmujemy się również cechą trwałości obiektów, tj. czy obiekty są przechowywane na dysku czy też w pamięci operacyjnej. Cecha trwałości nie ma znaczenia dla definiowania semantyki języka zapytań.

© K.Subieta. Podejście stosowe 05, Folia 11 Relatywizm obiektów Nie będziemy przywiązywać wagi do podziału obiektów na proste i złożone, a także nie wprowadzamy specjalnej terminologii i pojęć dla obiektów złożonych. Tego rodzaju relatywizm obiektów ma zasadnicze znaczenie dla uproszczenia definiowanych języków, znacznie upraszcza metamodel i operacje na metamodelu, zwiększa uniwersalność języka i ma zasadnicze znaczenia dla prostoty oraz klarowności semantyki i pragmatyki. W wielu koncepcjach obiektowości (np w standardach CORBA i ODMG) relatywizm nie jest wyznawany. Np. w ODMG atrybut jest tzw. literałem, który nie jest obiektem. Podobnie, większość koncepcji innych autorów implicite zakłada, że obiekt musi być złożony, tj. musi posiadać strukturę wewnętrzną w postaci atrybutów, pól, itp. W tej koncepcji zbędne również staje się pojęcie modułu. Moduł jest po prostu obiektem składającym się z obiektów. object relativism

© K.Subieta. Podejście stosowe 05, Folia 12 Modelowanie kolekcji i struktur W zdefiniowanym powyżej modelu AS0 (jak i w następnych modelach) nie zakładamy unikalności zewnętrznych nazw obiektów. Dotyczy to dowolnego poziomu hierarchii obiektów. Przykładowo, na górnym poziomie hierarchii nazwy Prac i Dział nie są unikalne, zaś wewnątrz obiektów Dział nie są unikalne nazwy Lokacja i Zatrudnia. To założenie umożliwia modelowanie kolekcji bez wprowadzania w tym celu specjalnych środków formalnych. Kolekcja nie występuje jako identyfikowalny byt programistyczny - w odróżnieniu np. od ODMG. Podobne założenie odnośnie kolekcji przyjmuje XML. Abstrahujemy od wielu pojęć wprowadzanych w innych modelach, takich jak krotki (tuples), struktury, warianty/unie, zapisy (records), zbiory (sets), wielozbiory (bags), ekstensje (extents), itd. Pojęcia te dadzą się wyrazić w terminach podanego modelu poprzez pewne ograniczenie lub wyspecjalizowanie. Z naszego punktu widzenia są to zestawy obiektów lub obiekty złożone.

© K.Subieta. Podejście stosowe 05, Folia 13 W naszych modelach składu kolekcja nie występuje jako pojedynczy, identyfikowalny byt programistyczny. Nie można utworzyć pojedynczej referencji prowadzącej do kolekcji. Można zbudować zbiór referencji do elementów danej kolekcji, w szczególności, do wszystkich elementów danej kolekcji. Można oczywiście utworzyć obiekt, który w środku będzie miał tak samo nazwane podobiekty, i wtedy można zbudować referencję do takiego obiektu. Taki zabieg oczywiście nic nie wnosi do koncepcji, nadal jesteśmy w modelu AS0. Model AS0 zajmuje się wyłącznie kolekcjami zwanymi bagami (bags). Inne kolekcje, takie jak sekwencje, wymagają nowego modelu. Kolekcje Osoba Osoba OsobaOsobaOsoba Osoby

© K.Subieta. Podejście stosowe 05, Folia 14 Modelowanie powiązań pomiędzy obiektami Obiekty pointerowe umieszczone wewnątrz obiektów są w stanie odwzorować powiązania pomiędzy obiektami. Np. każdy obiekt pointerowy PracujeW prowadzi do odpowiedniego obiektu Dział, zaś każdy obiekt pointerowy Zatrudnia prowadzi do obiektu Prac. Podobnie jak w modelu ODMG nie będziemy interesowali się powiązaniami o arności wyższej niż 2 oraz powiązaniami posiadającymi własne atrybuty. Takie opcje zwiększają złożoność programistycznego interfejsu. W szczególności, trudności są związane z aktualizacją takich powiązań, np. przełączeniu jednej gałęzi danego powiązania do innego obiektu. Powiązania posiadające własne atrybuty prowadzą do niejasności koncepcyjnej. Konieczne byłoby tworzenie nowego rodzaju klasy, która opisywałaby atrybuty powiązań. Konieczne byłyby podwójne definicje klas: dla obiektów i dla powiązań. Nie wydaje się również potrzebne dekorowanie powiązania klasą (jak w UML)

© K.Subieta. Podejście stosowe 05, Folia 15 Wartości zerowe, warianty, dane półstrukturalne AS0 umożliwia formalizację wartości zerowych i wariantów (unii). Np. atrybut (złożony) Adres występuje tylko dla jednego obiektu Prac. Model niczym nie zobowiązuje nas do tego, aby obiekty posiadające te same nazwy posiadały pod-obiekty o tych samych nazwach. Model nie wprowadza (jak dotąd) ograniczeń typologicznych, co daje pełną swobodę w zakresie budowy poszczególnych obiektów. Będziemy uważać, że ewentualny dyskryminator wariantu jest takim samym pod-obiektem jak pozostałe. AS0 przykrywa nieregularności w danych, określane ostatnio jako dane pół-strukturalne (semistructured). Oznacza to, że budowana przez nas semantyka będzie adekwatna do budowy języków zapytań i języków programowania obsługujących takie struktury. W szczególności, semantyka będzie nadawała się do struktur rozważanych w technologiach opartych na XML. Nie będziemy jednak dążyć do dopasowania lukru syntaktycznego języka zapytań do lukru syntaktycznego XML.

© K.Subieta. Podejście stosowe 05, Folia 16 Model relacyjny i model zagnieżdżonych relacji Model AS0 włącza struktury danych zakładane przez model relacyjny jako szczególny przypadek. Semantykę relacyjnego języka zapytań (w szczególności SQL) można będzie zdefiniować jako szczególny przypadek definiowanej przez nas semantyki. Nie będziemy nastawiać się na definiowanie semantyki SQL. SQL jest językiem o licznych anomaliach, niekonsekwencjach i semantycznych rafach, w związku z tym definiowanie jego precyzyjnej semantyki jest trudne i mało sensowne. Przed taką definicją należałoby wcześniej uporządkować koncepcję języka, a na to w przypadku SQL jest za późno. Model AS0 przykrywa również model zagnieżdżonych relacji (NF 2 ) jako szczególny przypadek. Również struktury danych implikowane przez inne modele, określane przez ich autorów jako funkcjonalne, obiektowe, logiczne, semantyczne, itd. dadzą się sformalizować w terminach podanego prostego modelu.

© K.Subieta. Podejście stosowe 05, Folia 17 Relacja zapisana w modelu AS0 Schemat relacyjny: Prac( Nazwisko, Zarobek, PracujeW ) Nazwisko Nowak Kowalski Barski Zarobek PracujeW Produkcja Sprzedaż Model relacyjny - Relacja Prac S - Obiekty:, } >,, } >,, } > R - Identyfikatory startowe: i 1, i 5, i 9 Model składu obiektów AS0: Krotki relacji jako obiekty złożone

© K.Subieta. Podejście stosowe 05, Folia 18 Jan Kowalski S - Obiekty: < i 1, pracownik, {, } > R - Identyfikatory startowe: i 1 Model składu obiektów AS0: Plik XML Dokument XML zapisany w modelu AS0 Nie ma różnic koncepcyjnych. Potencjalne drobne problemy: Jak określić identyfikatory dla obiektów XML? Jak traktować informacje (tzw. atrybuty) wewnątrz XML-owych tagów? Jak modelować powiązania (obiekty pointerowe) w XML?

© K.Subieta. Podejście stosowe 05, Folia 19 Sekwencje i tablice w modelu AS0 Istnieją ważne operatory, które potrzebują uwzględnienia porządku w obiektach. Do nich należy np. operator order by języka SQL. Istotny jest również operator wyboru n pierwszych (lub ostatnich) elementów z pewnej kolekcji. Umożliwia on m.in. takie zapytania jak Podaj 50-ciu najlepiej zarabiających pracowników. Czy potrzebne jest wzbogacenie naszego modelu o pojęcie "sekwencji"? Model AS0 bezpośrednio nie uwzględnia sekwencji. Należy go rozszerzyć. Można też np. zastosować konwencję w której nazwy obiektów są liczbami naturalnymi. Np. tablica ustalająca dzieci pracownika w porządku od najstarszego do najmłodszego mogłaby mieć postać:,, }> Przy takim modelu dostęp do elementu tablicy następowałby poprzez indeks, np. Dzieci.2 oznaczałoby wiązanie do identyfikatora i 3 (wartości Adam). Możliwe byłoby również użycie takich wyrażeń jak np. Dzieci.[x+1], które przy wartości obiektu x równej 2 zwróci i 4.

© K.Subieta. Podejście stosowe 05, Folia 20 Model AS1 - klasy i dziedziczenie Model AS1 wprowadza pojęcia klasy i dziedziczenia w wersji prototypów. Klasa jest obiektem podobnym do wprowadzonych poprzednio obiektów. Obiekty będące klasami będą wyróżnione jako te, które przechowują inwarianty innych obiektów. Ta rola klas będzie miała wpływ na definiowaną przez nas semantykę języków zapytań. W AS1 skład obiektów jest zdefiniowany jako, gdzie: S jest zbiorem obiektów (rozszerzonym o klasy), R jest zbiorem identyfikatorów obiektów będących wejściem do nawigacji w obiektowej strukturze danych, relacja KK I I wyznacza związek dziedziczenia pomiędzy klasami, relacja OK I I wyznacza przynależność obiektów do klas. Dla każdej pary KK, i 1 oznacza identyfikator klasy dziedziczącej, zaś i 2 oznacza identyfikator klasy z której się dziedziczy. Model AS1 obejmuje wielokrotne dziedziczenie.

© K.Subieta. Podejście stosowe 05, Folia 21 Przykład modelu AS1 S - Obiekty i klasy:, } >,,,, } >,,,, } >,,..pozostałe inwarianty klasy KlasaOsoba..}>,,..pozostałe inwarianty klasy KlasaPrac.. }>, R - Identyfikatory startowe: i 1, i 4, i 9 KK - Związki dziedziczenia między klasami: OK - Związki dziedziczenia między obiektami i klasami:,,

© K.Subieta. Podejście stosowe 05, Folia 22 Graficzna reprezentacja przykładu modelu AS1 i 40 KlasaOsoba i 41 Wiek (...kod...) i 50 KlasaPrac i 51 ZmieńZar (...kod...) i 52 ZarNetto (...kod...) i 4 Prac i 5 Nazwisko Nowak i 7 Zar 2500 i 8 PracujeW i 6 RokUr 1944 i 127 i 1 Osoba i 2 Nazwisko Wilski i 3 RokUr 1950 i 128 i 9 Prac i 10 Nazwisko Kowalski i 12 Zar 2000 i 13 PracujeW i 11 RokUr 1940 Osoba Nazwisko RokUr Wiek Prac Zar ZmieńZar ZarNetto PracujeW

© K.Subieta. Podejście stosowe 05, Folia 23 Model AS2 - dynamiczne role Model AS2 jest uporządkowaną piątką, gdzie wprowadziliśmy nową relację OO I I. Relacja OO pozwala obiektom dziedziczyć z innych obiektów, na takiej samej zasadzie jak obiekty dziedziczą z klas. Obiekty dziedziczące z obiektu A będziemy nazywać rolami obiektu A. Możliwe jest dziedziczenie z ról. Relacja OO ustala semantykę manipulacji obiektami z dynamicznymi rolami. W szczególności, usunięcie obiektu będzie powodować usunięcie wszystkich jego ról. Model AS2 jest wolny od pewnych anomalii typologicznych i jest formalnie bardziej czysty w stosunku do modelu AS1. Jest jednak uważany za zbyt skomplikowany. Nie jest implementowany.

© K.Subieta. Podejście stosowe 05, Folia 24 Przykład modelu AS2 S - Obiekty i klasy:, } >,,...pozostałe inwarianty klasy KlasaOsoba...}>,,...pozostałe inwarianty klasy KlasaPrac... }>,,...pozostałe inwarianty klasy KlasaStudent... }>, R - Identyfikatory startowe: i 1, i 4, i 7, i 13, i 16, i 19 KK - Związki dziedziczenia między klasami: Zbiór pusty OK - Związki dziedziczenia między obiektami i klasami:,,,,,, OO - Związki dziedziczenia między obiektami i obiektami:,,

© K.Subieta. Podejście stosowe 05, Folia 25 Graficzna reprezentacja przykładu modelu AS2 i 1 Osoba i 2 Nazwisko Wilski i 3 RokUr 1950 i 40 KlasaOsoba i 41 Wiek (...kod...) i 50 KlasaPrac i 51 ZmieńZar (...kod...) i 52 ZarNetto (...kod...) i 60 KlasaStudent i 61 ŚredniaOcen (...kod...) i 13 Prac i 14 Zar 2500 i 15 PracujeW i 127 i 4 Osoba i 5 Nazwisko Nowak i 6 RokUr 1944 i 7 Osoba i 8 Nazwisko Kowalski i 9 RokUr 1940 i 128 i 16 Prac i 17 Zar 2000 i 18 PracujeW i 19 Student i 20 NrIndeksu i 21 Wydział fizyka

© K.Subieta. Podejście stosowe 05, Folia 26 Odmienność i zalety modelu z rolami (1) Wielokrotne dziedziczenie: Ponieważ role są hermetyzowane, nie może wystąpić konflikt nazw nawet wtedy, gdy różne role (czyli specjalizacje obiektu) posiadają własności o tych samych nazwach. Powtarzalne dziedziczenie: Jest normalne, że obiekt może mieć dwie lub więcej ról o tej samej nazwie. Np. Kowalski może być dwa razy studentem, w różnych szkołach. Ten przypadek nie jest objęty klasycznym modelem dziedziczenia lub wielokrotnego dziedziczenia. Przechowywanie obiektów historycznych: Role idealnie nadają się do przechowywania obiektów historycznych nie powodując przy tym anomalii z unikalnością identyfikatorów obiektów. Np. można łatwo zapisać fakt, że Kowalski był już kiedyś dwa razy studentem. Wielo-aspektowe dziedziczenie: Klasa może być specjalizowana wg wielu aspektów, np. według stosunku do zatrudnienia lub stosunku do wykształcenia. UML przykrywa tę cechę, ale jest ona nieobecna w narzędziach obiektowych, co prowadzi m.in. do efektu "eksplozji klas". Role automatycznie mają cechę wielo-aspektowego dziedziczenia.

© K.Subieta. Podejście stosowe 05, Folia 27 Odmienność i zalety modelu z rolami (2) Warianty (unie): Cecha ta, wprowadzona m.in. w C++, CORBA i ODMG, prowadzi do wielu semantycznych i implementacyjnych problemów. Role przykrywają tę cechę, przez co staje się niepotrzebna. Migracja obiektów: Role mogą pojawiać się i znikać dynamicznie, co w terminach klasycznych modeli obiektowych oznacza, że obiekt zmienia klasę (czyli "migruje") bez zmiany tożsamości. Dla klasycznych modeli jest to duży problem. W przypadku ról problem ten nie istnieje. Spójność referencyjna: W przypadku ról związki mogą prowadzić do ról, a nie do całych obiektów. Np. jeżeli nawigujemy od obiektu Szkoła do obiektu Kowalskiego poprzez jego rolę Student, wówczas niedostępny jest atrybut Zar i metoda ZarNetto. Jest to znaczne uściślenie hermetyzacji. Dynamiczne dziedziczenie: KlasaPrac nie dziedziczy statycznie z KlasaOsoba. Zamiast tego, rola Prac dziedziczy dynamicznie z roli Osoba wszystkie cechy, włączając metody zawarte w klasie KlasaOsoba. Stwarza to nową sytuację dla przesłaniania i polimorfizmu.

© K.Subieta. Podejście stosowe 05, Folia 28 Odmienność i zalety modelu z rolami (3) Heterogeniczne, przecinające się kolekcje. W klasycznych modelach, np. w ODMG, jeżeli obiekt był elementem kolekcji, to nie mógł być jednocześnie elementem innej kolekcji. Jest to ograniczenie modelowania pojęciowego. Dynamiczne role posiadają naturalną zdolność modelowania heterogenicznych, przecinających się kolekcji. Np. można utworzyć rolę Pacjent, i tą rolę objąć ludzi i zwierzęta, oraz inną rolę ObiektyDzisiajAktualizowane obejmującą obiekty dowolnego typu. Kolekcje Pacjent i ObiektyDzisiajAktualizowane są heterogeniczne i zachodzą na siebie. Programowanie aspektowe (Aspect-Oriented Programming, AOP) i rozdzielenie aspektów. AOP zajmuje się rozdzieleniem przecinających się aspektów (cross-cutting concerns) celem umieszczenie każdego aspektu w odrębnym module programu (np. historię zmian, reguły bezpieczeństwa, wizualizację, itd.). Dynamiczne role mają wiele zbieżności z AOP lub mogą być wykorzystane jako techniczne wspomaganie AOP.

© K.Subieta. Podejście stosowe 05, Folia 29 Model AS3 - hermetyzacja i ukrywanie informacji Model AS3 uwzględniający hermetyzację możemy zbudować zarówno na gruncie modelu AS1, jak i modelu AS2, ponieważ cecha hermetyzacji jest ortogonalna w stosunku do wprowadzonych wcześniej własności. Idea hermetyzacji polega na tym, aby w określonych sytuacjach zabronić dostępu do pewnych własności obiektów, określanych jako prywatne. Chodzi o to, aby własności prywatne były dostępne z wnętrza obiektu, zaś niedostępne z jego zewnętrza. Będzie to wymuszone poprzez stosową semantykę języka zapytań. Model AS3 uzupełnia model AS1 lub AS2 w taki sposób, że klasy są wyposażona w dodatkowy inwariant - listę eksportową. Jest ona zbiorem nazw własności tej klasy i jej obiektów (metod, atrybutów), które będą widoczne z zewnątrz. Lista eksportowa będzie użyta w procesie ewaluacji zapytań jako dodatkowy środek kontroli zakresu obowiązywania nazw. Podobny środek polega na wprowadzeniu pojęcia interfejsu do obiektów danej klasy.

© K.Subieta. Podejście stosowe 05, Folia 30 Przykład modelu AS3 S - Obiekty i klasy:, } >,,,, } >,,,, } >,, inwariant: Lista eksportowa = {Nazwisko, Wiek},..pozostałe inwarianty klasy KlasaOsoba..}>,, inwariant: Lista eksportowa = {PracujeW, ZmieńZar, ZarNetto},..pozostałe inwarianty klasy KlasaPrac.. }>, R - Identyfikatory startowe: i 1, i 4, i 9 KK - Związki dziedziczenia między klasami: OK - Związki dziedziczenia między obiektami i klasami:,, +PracujeW Osoba + Nazwisko - RokUr + Wiek Prac - Zar + ZmieńZar + ZarNetto