© K.Subieta. Obiektowe języki zapytań 06, Folia 1 kwiecień 2004 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik.

Prezentacja na temat: "© K.Subieta. Obiektowe języki zapytań 06, Folia 1 kwiecień 2004 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik."— Zapis prezentacji:

1 © K.Subieta. Obiektowe języki zapytań 06, Folia 1 kwiecień 2004 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa subieta@pjwstk.edu.pl Instytut Podstaw Informatyki PAN, Warszawa subieta@ipipan.waw.pl Wykład 06: Modele składu obiektów

2 © K.Subieta. Obiektowe języki zapytań 06, Folia 2 kwiecień 2004 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.

3 © K.Subieta. Obiektowe języki zapytań 06, Folia 3 kwiecień 2004 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ą.

4 © K.Subieta. Obiektowe języki zapytań 06, Folia 4 kwiecień 2004 Modele składu obiektów M0: obejmuje dowolnie powiązane hierarchiczne struktury danych; nie obejmuje klas, dziedziczenia, interfejsu i hermetyzacji. Model M0 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. M1: uzupełnia M0 o pojęcia klasy, dziedziczenia i wielodziedziczenia w najczęściej spotykanym rozumieniu; nie obejmuje hermetyzacji i interfejsu. M2: uzupełnia model M1 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. M3: uzupełnia model M1 lub M2 o pojęcie hermetyzacji - podział własności klas i obiektów na publiczne i prywatne. Podana rodzina modeli nie zamyka tematu. object store

5 © K.Subieta. Obiektowe języki zapytań 06, Folia 5 kwiecień 2004 Pojęcia wspólne dla modeli M0, M1, M2 i M3 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.

6 © K.Subieta. Obiektowe języki zapytań 06, Folia 6 kwiecień 2004 Model M0 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.

7 © K.Subieta. Obiektowe języki zapytań 06, Folia 7 kwiecień 2004 Ograniczenia w modelu M0 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.

8 © K.Subieta. Obiektowe języki zapytań 06, Folia 8 kwiecień 2004 Przykład składu w modelu M0 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

9 © K.Subieta. Obiektowe języki zapytań 06, Folia 9 kwiecień 2004 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

10 © K.Subieta. Obiektowe języki zapytań 06, Folia 10 kwiecień 2004 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 M0 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ń.

11 © K.Subieta. Obiektowe języki zapytań 06, Folia 11 kwiecień 2004 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

12 © K.Subieta. Obiektowe języki zapytań 06, Folia 12 kwiecień 2004 Modelowanie kolekcji i struktur W zdefiniowanym powyżej modelu M0 (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.

13 © K.Subieta. Obiektowe języki zapytań 06, Folia 13 kwiecień 2004 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 M0. Model M0 zajmuje się wyłącznie kolekcjami zwanymi bagi (bags). Inne kolekcje, takie jak sekwencje, wymagają nowego modelu. Kolekcje Osoba Osoba OsobaOsobaOsoba Osoby

14 © K.Subieta. Obiektowe języki zapytań 06, Folia 14 kwiecień 2004 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)

15 © K.Subieta. Obiektowe języki zapytań 06, Folia 15 kwiecień 2004 Wartości zerowe, warianty, dane półstrukturalne M0 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. M0 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.

16 © K.Subieta. Obiektowe języki zapytań 06, Folia 16 kwiecień 2004 Model relacyjny i model zagnieżdżonych relacji Model M0 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 M0 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.

17 © K.Subieta. Obiektowe języki zapytań 06, Folia 17 kwiecień 2004 Relacja zapisana w modelu M0 Schemat relacyjny: Prac( Nazwisko, Zarobek, PracujeW ) Nazwisko Nowak Kowalski Barski Zarobek 2500 2000 PracujeW Produkcja Sprzedaż Model relacyjny - Relacja Prac S - Obiekty:, } >,, } >,, } > R - Identyfikatory startowe: i 1, i 5, i 9 Model składu obiektów M0: Krotki relacji jako obiekty złożone

18 © K.Subieta. Obiektowe języki zapytań 06, Folia 18 kwiecień 2004 Jan Kowalski 1973-12-1 2500 S - Obiekty: < i 1, pracownik, {, } > R - Identyfikatory startowe: i 1 Model składu obiektów M0: Plik XML Dokument XML zapisany w modelu M0 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?

19 © K.Subieta. Obiektowe języki zapytań 06, Folia 19 kwiecień 2004 Sekwencje i tablice w modelu M0 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 M0 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. Są inne metody realizacji pojęcia sekwencji w ramach modelu M0.

20 © K.Subieta. Obiektowe języki zapytań 06, Folia 20 kwiecień 2004 Model M1 - klasy i dziedziczenie Model M1 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 M1 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 M1 obejmuje wielokrotne dziedziczenie.

21 © K.Subieta. Obiektowe języki zapytań 06, Folia 21 kwiecień 2004 Przykład modelu M1 S - Obiekty i klasy:, } >,,,, } >,,,, } >,, inwariant: Nazwa obiektów = "Osoba",..pozostałe inwarianty klasy KlasaOsoba..}>,, inwariant: Nazwa obiektów = "Prac";..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:,,

22 © K.Subieta. Obiektowe języki zapytań 06, Folia 22 kwiecień 2004 Graficzna reprezentacja przykładu modelu M1 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

23 © K.Subieta. Obiektowe języki zapytań 06, Folia 23 kwiecień 2004 Inwariant klasy - nazwa jej obiektów Model M1 implikuje problemy z wiązaniem nazw. Zgodnie z zasadą zamienialności (substitutability, LSP), jeżeli w wyrażeniu występuje nazwa Osoba, to związane muszą być nie tylko obiekty Osoba, ale również obiekty Prac. M1 w sformułowaniu formalnym nie zawiera bezpośrednio informacji, która to umożliwia, zatem musi być rozszerzony. W klasycznych modelach problem ten nie występuje, gdyż nazwa obiektów nie jest inwariantem klasy, zaś zamienialność wynika z hierarchii klas lub typów. To rozszerzenie można zrobić na kilka sposobów. Podany sposób zakłada, że klasy są wyposażona w dodatkowy inwariant - nazwę obiektów danej klasy.

24 © K.Subieta. Obiektowe języki zapytań 06, Folia 24 kwiecień 2004 Model M2 - dynamiczne role Model M2 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 M2 jest wolny od pewnych anomalii typologicznych i jest formalnie bardziej czysty w stosunku do modelu M1. W szczególności, nie ma wspomnianego problemu z wiązaniem nazw. Jest paradoksem fakt, że model składu wprowadzający role, który jest semantycznie czysty i prosty, jest uważany za zbyt skomplikowany. Wydaje się, że wynika to z pewnych obciążeń myślenia o obiektowości, wynikających z tradycji istniejących języków programowania, takich jak C++ i Smalltalk.

25 © K.Subieta. Obiektowe języki zapytań 06, Folia 25 kwiecień 2004 Przykład modelu M2 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:,,

26 © K.Subieta. Obiektowe języki zapytań 06, Folia 26 kwiecień 2004 Graficzna reprezentacja przykładu modelu M2 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 76943 i 21 Wydział fizyka

27 © K.Subieta. Obiektowe języki zapytań 06, Folia 27 kwiecień 2004 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.

28 © K.Subieta. Obiektowe języki zapytań 06, Folia 28 kwiecień 2004 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.

29 © K.Subieta. Obiektowe języki zapytań 06, Folia 29 kwiecień 2004 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.

30 © K.Subieta. Obiektowe języki zapytań 06, Folia 30 kwiecień 2004 Model M3 - hermetyzacja i ukrywanie informacji Model M3 uwzględniający hermetyzację możemy zbudować zarówno na gruncie modelu M1, jak i modelu M2, 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 M3 uzupełnia model M1 lub M2 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.

31 © K.Subieta. Obiektowe języki zapytań 06, Folia 31 kwiecień 2004 Przykład modelu M3 S - Obiekty i klasy:, } >,,,, } >,,,, } >,, inwariant: Nazwa obiektów = "Osoba", inwariant: Lista eksportowa = {"Nazwisko", "Wiek"},..pozostałe inwarianty klasy KlasaOsoba..}>,, inwariant: Nazwa obiektów = "Prac"; 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

32 © K.Subieta. Obiektowe języki zapytań 06, Folia 32 kwiecień 2004 Schemat bazy danych dla modeli składu Język schematu bazy danych jest bardzo ważnym uzupełnieniem dowolnego modelu składu. Język schematu stanowi inherentną część języka zapytań (jego pragmatyki), gdyż na podstawie schematu programista wie, co baza danych zawiera i jak jest zorganizowana. Schemat bazy danych jest również wykorzystywany przez SZBD dla właściwej organizacji danych, reprezentacji danych, kontroli typów danych oraz wymuszenia niektórych ograniczeń dotyczących danych. Przykładem takiego języka jest ODL wg standardu ODMG. Schematy są również wyrażane w postaci graficznej; np. w UML. Dla każdego wprowadzonego modelu składu konieczne jest opracowanie języka umożliwiającego zapis schematu. Jest to duże zadanie. W tym wykładzie będziemy przyjmować (nie do końca słusznie), że schemat jest ważny dla pragmatyki języka, ale jest mniej istotny dla jego semantyki. Z tego powodu dalej będziemy stosować notację ad hoc (wzorowaną na UML) popartą objaśnieniami i przykładami.