Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 1 2011 Języki i środowiska programowania systemów rozproszonych Wykładowca:

Prezentacja na temat: "Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 1 2011 Języki i środowiska programowania systemów rozproszonych Wykładowca:"— Zapis prezentacji:

1 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 1 2011 Języki i środowiska programowania systemów rozproszonych Wykładowca: Tomasz Kowalski Wykłady przygotowane na podstawie materiałów prof. Kazimierza Subiety Wykład 4 Modele składów obiektów

2 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 2 2011 Złożoność modeli obiektowych 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 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 3 2011 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 AS1 lub AS2 o pojęcie hermetyzacji - podział własności klas i obiektów na publiczne i prywatne. Podana rodzina modeli nie zamyka tematu. object store

4 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 4 2011 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.

5 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 5 2011 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.

6 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 6 2011 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.

7 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 7 2011 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

8 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 8 2011 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

9 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 9 2011 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ń.

10 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 10 2011 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

11 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 11 2011 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.

12 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 12 2011 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 bagi (bags). Inne kolekcje, takie jak sekwencje, wymagają nowego modelu. Kolekcje Osoba Osoba OsobaOsobaOsoba Osoby

13 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 13 2011 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)

14 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 14 2011 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.

15 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 15 2011 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.

16 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 16 2011 Relacja zapisana w modelu AS0 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 AS0: Krotki relacji jako obiekty złożone

17 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 17 2011 Jan Kowalski 1973-12-1 2500 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?

18 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 18 2011 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.

19 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 19 2011 Przykład modelu AS1 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:,,

20 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 20 2011 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

21 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 21 2011 Inwariant klasy - nazwa jej obiektów Model AS1 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. AS1 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.

22 Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd 22 2011 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.