Obiektowe języki zapytań

1. 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. 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. 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. Modele składu obiektów object store • 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.

5. 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. Model M0 • I - zbiór identyfikatorów (i, i1, i2, ... - oznaczenia identyfikatorów) • N - zbiór nazw (n, n1, n2, ... - oznaczenia nazw) • V - zbiór wartości atomowych (v, v1, v2, ... - oznaczenia wartości) • Obiekt atomowy: trójka <i, n, v>. • Obiekt pointerowy: trójka <i1, n, i2>. Obiekt jest identyfikowany przez i1, natomiast i2 jest pointerem (referencją) do innego obiektu. • Obiekt złożony: trójka <i, n, T>, 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 <S, R>, 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. 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 <i1,n,i2>, to powinien istnieć również obiekt posiadający identyfikator i2. 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 i2 oraz jest osiągalny obiekt pointerowy <i1, n, i2>. 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. Przykład składu w modelu M0 S - Obiekty: < i1 , Prac , {< i2, Nazwisko, ”Nowak” >, < i3, Zar, 2500 >, < i4, PracujeW, i17 > } >, < i5 , Prac , {< i6, Nazwisko, ”Kowalski” >, < i7, Zar, 2000 >, < i8, PracujeW, i22 > } >, < i9 , Prac , {< i10, Nazwisko, ”Barski” >, < i11, Zar, 900 >, < i12, Adres, {< i13, Miasto, ”Radom” >, < i14, Ulica, ”Wolska” >, < i15, NrDomu, 12 > } >, < i16, PracujeW, i22 > } >, < i17 ,Dział, {<i18, Nazwa, ”Produkcja” >, < i19, Lokacja, ”Kielce” >, < i20, Lokacja, ”Kraków” >, < i21, Zatrudnia, i1 > } >, < i22 , Dział,{< i23, Nazwa, ”Sprzedaż” >, < i24, Lokacja, ”Radom” >, < i25, Zatrudnia, i5 >, < i26, Zatrudnia, i9 > } > R - Identyfikatory startowe: i1 , i5 , i9 , i17 , i22 Diagram klas Prac [0..*] Nazwisko Zar Adres [0..1] Miasto Ulica NrDomu PracujeW Zatrudnia[1..*] Dział [0..*] Nazwa Lokacja[1..*]

9. Poglądowy obraz małej bazy danych i1Prac i5Prac i9Prac i2 Nazwisko ”Nowak” i6 Nazwisko ”Kowalski” i10 Nazwisko ”Barski” i3 Zar 2500 i7 Zar 2000 i11 Zar 900 i4 PracujeW i12 Adres i8 PracujeW i13 Miasto ”Radom” i14 Ulica ”Wolska” i15 NrDomu 12 i16 PracujeW i17Dział i22Dział i18 Nazwa ”Produkcja” i23 Nazwa ”Sprzedaż” i19 Lokacja ”Kielce” i24 Lokacja ”Radom” i25 Zatrudnia i20 Lokacja ”Kraków” i26 Zatrudnia i21 Zatrudnia

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 <i, x, 5>, 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. Relatywizm obiektów object relativism • 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.

12. 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. Kolekcje Osoba Osoba Osoba Osoba Osoba • 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. Osoby

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)

15. 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. 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 (NF2) 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. Relacja zapisana w modelu M0 Nazwisko Nowak Kowalski Barski Zarobek 2500 2000 2000 PracujeW Produkcja Sprzedaż Sprzedaż Schemat relacyjny: Prac( Nazwisko, Zarobek, PracujeW ) Krotki relacji jako obiekty złożone Model relacyjny - Relacja Prac Model składu obiektów M0: S - Obiekty: < i1 , Prac, { < i2, Nazwisko, ”Nowak” >, < i3, Zarobek, 2500 >, < i4, PracujeW, ”Produkcja” > } >, < i5 , Prac, { < i6, Nazwisko, ”Kowalski” >, < i7, Zarobek, 2000 >, < i8, PracujeW, ”Sprzedaż” > } >, < i9 , Prac, { < i10, Nazwisko, ”Barski” >, < i11, Zarobek, 2000 >, < i12, PracujeW, ”Sprzedaż” > } > R - Identyfikatory startowe: i1 , i5 , i9

18. 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? Plik XML <pracownik> <imie>Jan</imie> <nazwisko>Kowalski</nazwisko> <data_urodz>1973-12-1</data_urodz> <pensja>2500</pensja> </pracownik> Model składu obiektów M0: S - Obiekty: < i1, pracownik, { < i2, imie, ”Jan” >, < i3, nazwisko, "Kowalski" >, < i4, data_urodz, 1973-12-1> < i5, pensja, 2500> } > R - Identyfikatory startowe: i1

19. 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ć: • <i1, Dzieci, { <i2, 1, ”Jacek”>, <i3, 2, ”Adam”>, <i4, 3, ”Anna”> }> • Przy takim modelu dostęp do elementu tablicy następowałby poprzez indeks, np. Dzieci.2 oznaczałoby wiązanie do identyfikatora i3(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 i4. • Są inne metody realizacji pojęcia sekwencji w ramach modelu M0.

20. 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 <S, R, KK, OK>, 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 <i1, i2> KK, i1oznacza identyfikator klasy dziedziczącej, zaś i2 oznacza identyfikator klasy z której się dziedziczy. • Model M1 obejmuje wielokrotne dziedziczenie.

21. Przykład modelu M1 S - Obiekty i klasy: < i1 , Osoba , { < i2, Nazwisko, ”Wilski” >, < i3, RokUr, 1950 > } >, < i4 , Prac , { < i5, Nazwisko, ”Nowak” >, < i6, RokUr, 1944 >, < i7, Zar, 2500 >, < i8, PracujeW, i127 > } >, < i9 , Prac , { < i10, Nazwisko, ”Kowalski” >, < i11, RokUr, 1940 >, < i12, Zar, 2000 >, < i13, PracujeW, i128 > } >, < i40 , KlasaOsoba , { < i41, Wiek, (..kod metody Wiek..) >, inwariant: Nazwa obiektów = "Osoba", ..pozostałe inwarianty klasy KlasaOsoba ..}>, < i50 , KlasaPrac , { < i51, ZmieńZar, (..kod metody ZmieńZar..) >, < i52, ZarNetto, (...kod metody ZarNetto..) >, inwariant: Nazwa obiektów = "Prac"; ..pozostałe inwarianty klasy KlasaPrac .. }>, R - Identyfikatory startowe: i1 , i4 , i9 KK - Związki dziedziczenia między klasami: < i50 , i40 > OK - Związki dziedziczenia między obiektami i klasami: < i1 , i40 >, < i4 , i50 >, < i9 , i50 >

22. Graficzna reprezentacja przykładu modelu M1 Osoba Nazwisko RokUr Wiek i40 KlasaOsoba i41 Wiek (...kod...) ................ i1 Osoba i2 Nazwisko ”Wilski” PracujeW i3 RokUr 1950 Prac Zar ZmieńZar ZarNetto i50 KlasaPrac i51 ZmieńZar (...kod...) i52 ZarNetto (...kod...) ................ i4 Prac i9 Prac i5 Nazwisko ”Nowak” i10 Nazwisko ”Kowalski” i6 RokUr 1944 i11 RokUr 1940 i7 Zar 2500 i12 Zar 2000 i8 PracujeW i13 PracujeW i127 i128

23. 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. Model M2 - dynamiczne role • Model M2 jest uporządkowaną piątką <S, R, KK, OK, OO>, 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. Przykład modelu M2 S - Obiekty i klasy: < i1 , Osoba , { < i2, Nazwisko, "Wilski" >, < i3, RokUr, 1950 > } >, < i4 , Osoba , { < i5, Nazwisko, "Nowak" >, < i6, RokUr, 1944 >} >, < i7 , Osoba , { < i8, Nazwisko, "Kowalski" >, < i9, RokUr, 1940 >} >, < i13 , Prac , { < i14, Zar, 2500 >, < i15, PracujeW, i127 > } >, < i16 , Prac , { < i17, Zar, 2000 >, < i18, PracujeW, i128 > } >, < i19 , Student , { < i20, NrIndeksu, 76943 >, < i21, Wydział, "fizyka" >} >, < i40 , KlasaOsoba , { < i41, Wiek, (...kod metody Wiek...) >, ...pozostałe inwarianty klasy KlasaOsoba ...}>, < i50 , KlasaPracownik , { < i51, ZmieńZar, (...kod metody ZmieńZar...) >, < i52, ZarNetto, (...kod metody ZarNetto...) >, ...pozostałe inwarianty klasy KlasaPrac ... }>, < i60 , KlasaStudent , { < i61, ŚredniaOcen, (...kod metody ŚredniaOcen...) >, ...pozostałe inwarianty klasy KlasaStudent ... }>, R - Identyfikatory startowe: i1 , i4 , i7 , i13 , i16 , i19 KK - Związki dziedziczenia między klasami: Zbiór pusty OK - Związki dziedziczenia między obiektami i klasami: < i1 , i40 >, < i4 , i40 >, < i7 , i40 >, < i13 , i50 >, < i16 , i50 >, < i19 , i60 >, OO - Związki dziedziczenia między obiektami i obiektami: < i13 , i4 >, < i16 , i7 >, < i19 , i7 >

26. Graficzna reprezentacja przykładu modelu M2 i50 KlasaPrac i51 ZmieńZar (...kod...) i52 ZarNetto (...kod...) ................ i40 KlasaOsoba i41 Wiek (...kod...) ............. i1 Osoba i60 KlasaStudent i2 Nazwisko ”Wilski” i61 ŚredniaOcen (...kod...) i3 RokUr 1950 ................ i4 Osoba i5 Nazwisko ”Nowak” i7 Osoba i6 RokUr 1944 i8 Nazwisko ”Kowalski” i9 RokUr 1940 i19 Student i13 Prac i16 Prac i20 NrIndeksu 76943 i14 Zar 2500 i17 Zar 2000 i21 Wydział ”fizyka” i15 PracujeW i18 PracujeW i128 i127

27. 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. 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. 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. 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. Przykład modelu M3 Osoba + Nazwisko - RokUr + Wiek +PracujeW Prac - Zar + ZmieńZar + ZarNetto S - Obiekty i klasy: < i1 , Osoba , { < i2, Nazwisko, ”Wilski” >, < i3, RokUr, 1950 > } >, < i4 , Prac , { < i5, Nazwisko, ”Nowak” >, < i6, RokUr, 1944 >, < i7, Zar, 2500 >, < i8, PracujeW, i127 > } >, < i9 , Prac , { < i10, Nazwisko, ”Kowalski” >, < i11, RokUr, 1940 >, < i12, Zar, 2000 >, < i13, PracujeW, i128 > } >, < i40 , KlasaOsoba , { < i41, Wiek, (..kod metody Wiek..) >, inwariant: Nazwa obiektów = "Osoba", inwariant: Lista eksportowa = {"Nazwisko", "Wiek"}, ..pozostałe inwarianty klasy KlasaOsoba ..}>, < i50 , KlasaPrac, { < i51, ZmieńZar, (..kod metody ZmieńZar..) >, < i52, ZarNetto, (...kod metody ZarNetto..) >, inwariant: Nazwa obiektów = "Prac"; inwariant: Lista eksportowa = {"PracujeW", "ZmieńZar", "ZarNetto" }, ..pozostałe inwarianty klasy KlasaPrac .. }>, R - Identyfikatory startowe: i1 , i4 , i9 KK - Związki dziedziczenia między klasami: < i50 , i40 > OK - Związki dziedziczenia między obiektami i klasami: < i1 , i40 >, < i4 , i50 >, < i9 , i50 >

32. 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.