Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki Katedra Informatyki. Kierunek studiów: Informatyka Specjalność: Systemy komputerowe

Transkrypt

1 Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki Katedra Informatyki Kierunek studiów: Informatyka Specjalność: Systemy komputerowe Praca Dyplomowa Obiektowe bazy danych przegląd i analiza rozwiązań Promotor: prof. dr hab. inż. Antoni Ligęza Autorzy: Paweł Józwik Maciej Mazur Kraków 2002

2 Podziękowania Pragniemy złożyć serdeczne podziękowania dla Promotora naszej pracy, prof. dr hab. inż. Antoniego Ligęzy. Praca ta powstała z jego inicjatywy, a jej zrealizowanie było możliwe dzięki jego wsparciu i życzliwości. Paweł Józwik Maciej Mazur 2

3 Spis treści 1 WSTĘP CEL PRACY ZAWARTOŚĆ PRACY TEORIA DEFINICJE DOTYCZĄCE OBIEKTOWOŚCI Obiekt Identyfikator obiektu Tożsamość obiektu Klasa Atrybut Metoda Komunikat Hermetyzacja Hierarchia klas i dziedziczenie Pojęcia wykraczające poza model podstawowy ALGEBRA OBIEKTOWA Składnia Typ parametrów Równość Operatory Operatory zbiorowe Operatory wielozbiorowe Operatory innych typów ROZWÓJ BAZ DANYCH RYS HISTORYCZNY Przetwarzanie płaskich plików BDAM Podstawowa metoda bezpośredniego dostępu ISAM Metoda indeksowanego dostępu sekwencyjnego Mankamenty płaskich plików Początek formalnego zarządzania bazami danych Hierarchiczny model danych Sieciowy model CODASYL Relacyjne bazy danych Manifesty baz danych OBIEKTOWE BAZY DANYCH Trwałość obiektu Architektura Obiektowo-relacyjne bazy danych PORÓWNANIE RELACYJNYCH I OBIEKTOWYCH BAZ DANYCH STANDARDY JĘZYK SQL: Rozwój standardu Cechy relacyjne Nowe typy danych Nowe predykaty Nowa semantyka Dodatkowe bezpieczeństwo Aktywność bazy danych Cechy obiektowe Strukturalne typy definiowane przez użytkownika Metody a funkcje Zapis funkcjonalny i kropkowy Obiekty oraz typ REF Opinie o standardzie STANDARD ODMG

4 4.2.1 Powstanie grupy ODMG Cele Architektura Model obiektu Języki programowania ODL OIF OML OQL Wiązania do języków programowania Wiązanie do języka C Wiązanie do języka Smalltalk Wiązanie do języka Java JAVA DATA OBJECTS Rozwój standardu Architektura JDO Schemat bazy danych Trwałe obiekty w Javie - interfejs PersistenceCapable Modyfikator kodu binarnego JDO Enhancer Dostęp do bazy danych - język JDOQL Java Data Objects a Enterprise Java Beans Ziarna typu Entity Beans Ziarna typu Session Beans PORÓWNANIE STANDARDÓW ROZSZERZENIA OBIEKTOWE W RELACYJNYCH BAZACH DANYCH ORACLE Kluczowe cechy obiektowe modelu relacyjno-obiektowego w Oracle Dziedziczenie typów Modyfikacje typów Mechanizm obiektowej perspektywy Rozszerzenia obiektowe SQL a Rozszerzenia obiektowe PL/SQL a Java a obiektowość w bazie Oracle Zewnętrzne procedury Translator typów obiektowych Podręczny zbiór obiektów po stronie klienta Oracle Call Interface Object Extensions Rozszerzenia obiektowe Pro*C/C Rozszerzenia obiektowe OO4O Koncepcja obiektowości w bazie danych Oracle Typy obiektowe Dziedziczenie typów obiektowych Obiekty Metody Tabele obiektowe Typ bazodanowy REF Kolekcje Użycie rozszerzeń obiektowych w bazie danych Oracle9i Definiowanie klas oraz typów kolekcji Metody Dziedziczenie Dodatkowe narzędzia ułatwiające obsługę rozszerzeń obiektowych Business Components for Java (BC4J) JPublisher JDeveloper Import/Eksport typów obiektowych SQL*Loader POSTGRESQL Wielkie Obiekty Interfejs JDBC Przechowywanie danych binarnych Rozszerzanie języka SQL Funkcje Typy

5 6 OBIEKTOWE BAZY DANYCH W PRAKTYCE BAZY DANYCH DOSTĘPNE NA RYNKU excelon (dawniej Object Design) produkt ObjectStore Historia firmy w skrócie Ogólne informacje Przegląd produktów z rodziny ObjectStore Objectivity produkt Objectivity/DB Historia firmy w skrócie Ogólne informacje o produkcie Przegląd produktów z rodziny Objectivity Versant produkt Versant Historia firmy w skrócie Ogólne informacje o produkcie Przegląd produktów z rodziny Versant Developer Suite Poet Software produkt FastObjects Historia firmy w skrócie Ogólne informacje o produkcie Przegląd produktów z rodziny FastObjects GemStone produkty: GemStone/J, GemStone/S Historia firmy w skrócie Ogólne informacje o produktach Cechy produktów Fresher Information Software produkt Matisse Historia produktu w skrócie Ogólne informacje o produkcie Cechy produktów Wśród obsługiwanych platform znajdują się: Computer Association oraz Fujitsu produkt Jasmine Historia produktu w skrócie Ogólne informacje Przegląd produktów Uniwersytet Moskiewski produkt GOODS Ogólne informacje o produkcie Micro Database Systems produkt Titanium Historia firmy w skrócie Ogólne informacje Orient Technologies produkt Orient Historia produktu w skrócie Ogólne informacje o produkcie Sysra Informatique produkt EyeDB Ogólne informacje Historia projektu w skrócie Cechy produktu Zastosowanie PODSUMOWANIE I WNIOSKI OGÓLNE PERSPEKTYWY ROZBUDOWY PRACY LITERATURA

6 1 Wstęp Obiektowe bazy danych spotyka się obecnie coraz częściej w rozmaitych zastosowaniach. Zdobywają one coraz to nowe obszary, gdzie ich właściwości dają im przewagę nad systemami relacyjnymi. Dużym atutem obiektowych baz danych jest struktura, która naturalnie odpowiada strukturze modelującej rzeczywiste zjawiska i która jest z powodzeniem stosowana w obecnych językach programowania. Badania nad modelem obiektowym w bazach danych są obecnie prowadzone intensywnie w wielu ośrodkach naukowych; rozwijane są również komercyjne implementacje. 1.1 Cel pracy W chwili obecnej brak jest w literaturze pozycji, która obejmowałaby tematykę obiektowych baz danych w sposób całościowy, z uwzględnieniem najnowszych tendencji zarówno jeżeli chodzi o podstawy teoretyczne i przegląd istniejących standardów, jak i o systemy działające w praktyce. Niniejsza praca ma za zadanie wypełnić tę lukę. W kolejnych rozdziałach będziemy starali się przybliżyć problematykę obiektowych baz danych. W pierwszej części pracy zostaną omówione teoretyczne podstawy obiektowości oraz algebry obiektowej. Później zostanie zaprezentowany rys historyczny rozwoju baz danych, zaczynając od płaskich plików, poprzez modele hierarchiczne, sieciowe, relacyjne, aż po obiektowe. W następnej części pracy zostaną omówione istniejące standardy obiektowych baz danych. W niniejszej pracy zostaną przedstawione przede wszystkim trzy główne standardy, czyli SQL:1999, ODMG oraz JDO. Praca ma w zamierzeniach przedstawić problematykę obiektowych baz danych w sposób kompleksowy, tak aby osoba będąca nawet laikiem w tej dziedzinie mogła wyrobić sobie ogólny pogląd w tym temacie oraz poznać najbardziej rozpowszechnione obecnie standardy. Praca ta ma również na celu propagować zagadnienia związane z obiektowymi bazami danych. Zastanawiając się, dlaczego obiektowe bazy danych tak trudno torują sobie drogę na rynku zdominowanym przez relacyjne bazy, można dojść do wniosku, że jednym z powodów na pewno jest niedoinformowanie. Wynikiem tego jest stosowanie 6

7 produktów innych niż obiektowe bazy danych w zastosowaniach, gdzie właśnie obiektowe bazy danych byłyby najwłaściwszym rozwiązaniem. Bez rzetelnej informacji na temat tych produktów niewielu inżynierów uwierzy, iż bardziej korzystne może być zainwestowanie w obiektowe bazy danych. Tymczasem zostało wielokrotnie dowiedzione, że na przykład do zastosowań związanych ze składowaniem multimediów obiektowe bazy danych nadają się lepiej niż na przykład relacyjne. Również czas tworzenia aplikacji jest krótszy gdy nie ma potrzeby mapowania modelu obiektowego, wykorzystywanego w procesie projektowania i programowania aplikacji, do modelu relacyjnego w jakim dane są najczęściej przechowywane w bazach. Niniejsza praca przedstawia ogólne omówienie problematyki obiektowych baz danych. Może ona posłużyć jako podstawa do dalszych studiów związanych z wybranym aspektem, bądź konkretnym produktem. 1.2 Zawartość pracy Rozdział drugi ma na celu przedstawienie teoretycznych podstaw obiektowości i algebry obiektowej. Omówione zostały podstawowe pojęcia obiektowości, takie jak: obiekt, identyfikator obiektu, tożsamość obiektu, klasa, atrybut, metoda, komunikat, hermetyzacja, hierarchia klas i dziedziczenie. W rozdziale tym porównane zostały różne definicje pojawiające się w literaturze. Dodatkowo przedstawiono wybrane pojęcia wykraczające poza model podstawowy, takie jak: polimorfizm, obiekty złożone oraz zarządzanie wersjami. W związku z tym, iż nie istnieje jedna ogólnie przyjęta algebra obiektowa, w pracy skupiono się na propozycji algebry obiektowej określonej mianem AQUA. Jej autorami są dobrze znani na tym polu naukowcy, co pozwala uważać tę algebrę za w dużym stopniu reprezentatywną. W pracy przedstawiono składnię oraz podstawowe operatory algebry. Kolejny rozdział omawia etapy w rozwoju baz danych. Przegląd rozpoczęto od najstarszych systemów przechowywania danych, działających w oparciu o przetwarzanie płaskich plików. Następnie przybliżono działanie baz danych opartych na hierarchicznym modelu danych, potem na modelu sieciowym CODASYL, aby wreszcie 7

8 zaprezentować najpopularniejsze obecnie relacyjne bazy danych. Ostatecznie przedstawiono obiektowe bazy danych, będące tematem niniejszej pracy. Rozdział ten zawiera także prezentację systemów będących swoistym pomostem pomiędzy relacyjnymi a obiektowymi bazami danych, czyli obiektowo-relacyjnych baz danych. Zaprezentowane zostało także porównanie relacyjnych i obiektowych baz danych. Następny rozdział zawiera prezentację standardów w zakresie obiektowych baz danych. Omówione zostały trzy najważniejsze obecnie standardy. Pierwszym z nich jest SQL:1999 (SQL3), rozwinięcie standardu relacyjnego języka SQL, efekt współpracy organizacji ANSI oraz ISO. Następnie omówiono propozycje standaryzacyjne ODMG (Object Database Management Group). Jest to grupa, której głównym celem jest opracowywanie standardów dla obiektowych baz danych, które to standardy bardzo często są implementowane w produktach komercyjnych. Ostatnim przedstawionym standardem jest JDO (Java Data Object). Jest to najnowsza propozycja, stworzona i promowana przez firmę Sun Microsystems, będąca interfejsem Javy do baz danych. W kolejnym rozdziale przedstawione zostały rozszerzenia obiektowe wprowadzone w relacyjnych bazach danych: Oracle oraz PostgreSQL. Baza danych Oracle to bardzo zaawansowana i najbardziej ceniona baza na świecie. Natomiast PostgreSQL jest bardzo popularnym, niekomercyjnym systemem zarządzania bazą danych. Wprowadzone rozszerzenia pozwalają zaliczyć opisywane systemy do rodziny obiektowo-relacyjnych baz danych, jednakże ich rdzeń nadal stanowi model relacyjny. Następny rozdział stanowi przegląd dostępnych obecnie na rynku najbardziej popularnych systemów obiektowych baz danych. Przedstawione zostały następujące produkty: ObjectStore, Objectivity/DB, Versant, FastObjects, GemStone/J, GemStone/S, Matisse, Jasmine, GOODS, Titanium, Orient oraz EyeDB. Przy każdym z tych produktów zaprezentowano jego historię, budowę, udostępniane usługi i możliwości zastosowań. 8

9 2 Teoria 2.1 Definicje dotyczące obiektowości Zagadnienie obiektowych baz danych powstało jako efekt prac w wielu dziedzinach. Wpływ na jego rozwój miały nowe tendencje, jakie pojawiały się w obiektowych językach programowania, inżynierii oprogramowania, a także w pracach dotyczących systemów rozproszonych, systemów multimedialnych oraz komunikacji przez WWW. Nowe kierunki rozwoju zarysowały się również w technologii tradycyjnych, relacyjnych baz danych. Obecnie występuje pewnego rodzaju zamieszanie związane ze znaczeniem obiektowości w ogóle, a znaczeniem obiektowych baz danych w szczególności. Wiele osób traktuje termin zorientowany obiektowo jako rodzaj modnego sformułowania, mieszczącego w sobie wiele znaczeń. Wielu ekspertów stara się określić silne, techniczne kryteria związane z terminem obiektowości, aby umożliwić rozróżnienie systemów zorientowanych obiektowo od pozostałych. Co przemawia za wykorzystaniem obiektowości w bazach danych? Istnieje kilka koncepcji. Najbardziej popularna mówi, iż bazy danych składają się raczej z obiektów niż relacji, tabel czy innych struktur. Pojęcie obiektu jest rodzajem metafory, odnoszącej się do ludzkiej psychiki, sposobu w jaki ludzie myślą i postrzegają świat rzeczywisty. Ewolucja wykształciła w umysłach ludzkich mechanizmy umożliwiające nam wyodrębnianie obiektów w naszym środowisku, nazywanie ich i przyporządkowywanie im pewnych cech i zachowań. Obiektowość w technologii komputerowej, z psychologicznego punktu widzenia, jest więc oparta na wrodzonych mechanizmach ludzkiego umysłu. Kolejnym zagadnieniem jest potrzeba obiektowości w technologii komputerowej. Przez wiele lat eksperci wskazywali na negatywny syndrom, określany mianem kryzysu oprogramowania (ang. software crisis). Kryzys oprogramowania może być przedstawiany jako efekt wzrastających kosztów produkcji oprogramowania i jego utrzymania, problemów związanych z oprogramowaniem spadkowym (ang. legacy 9

10 software), ogromnym ryzykiem związanym z niepowodzeniem projektów informatycznych, niedojrzałością metod projektowania i konstrukcji oprogramowania, brakiem niezawodności, różnego rodzaju frustracjami projektantów oprogramowania i programistów i wielu tym podobnych czynników. Jednocześnie wraz z przedstawionymi zagrożeniami stale wzrasta rola systemów informatycznych jako czynników krytycznych w misji konkretnego przedsiębiorstwa. Kryzys oprogramowania jest więc powodowany przez skomplikowanie oprogramowania i złożoność metod jego wytwarzania. Obiektowość, będąca próbą naśladowania naturalnej psychiki człowieka, jest postrzegana jako sposób na zmniejszenie złożoności oprogramowania, a w efekcie na zredukowanie negatywnych zjawisk związanych z kryzysem oprogramowania. Ma to zostać uczynione poprzez skrócenie dystansu pomiędzy ludzkim postrzeganiem dziedziny problemu, abstrakcyjnym modelem konceptualnym dziedziny problemu (wyrażonym przykładowo za pomocą diagramu klas), a podejściem programisty zorientowanym na struktury danych i operacje. Zmniejszenie dystansu pomiędzy postrzeganiem problemu przez projektantów, a myśleniem programistów, jest uważane za najważniejszy czynnik zmniejszający złożoność analizy, projektowania, konstrukcji i utrzymania oprogramowania. Obiektowe modele dostarczają pojęć umożliwiających analitykom i projektantom lepsze odwzorowanie problemu w abstrakcyjny schemat konceptualny. W skład tych pojęć wchodzą między innymi: złożone obiekty, klasy, dziedziczenie, kontrola typów, metody powiązane z klasami, hermetyzacja i polimorfizm. Istnieje kilka notacji i metodologii (przykładowo OMT, UML, OPEN), które pozwalają na wydajne odwzorowywanie problemu w zorientowany obiektowo model konceptualny. Z drugiej strony, systemy obiektowych baz danych oferują podobne pojęcia odnośnie struktur danych, tak więc odwzorowywanie pomiędzy modelem konceptualnym a strukturami danych jest dużo łatwiejsze, niż w przypadku tradycyjnych systemów relacyjnych. Model obiektowy przede wszystkim dostarcza wyższego poziomu abstrakcji w sposób bardziej skuteczny, konsekwentny i jednorodny. Dotyczy on głównie struktur danych przechowywanych w obiektowej bazie danych. Wyznacza intelektualną i 10

11 ideologiczną bazę pozwalającą na budowę modeli obiektowych struktur danych oraz na komunikację. Jest on spójnym zestawem własności, pojęć, terminologii, notacji i formalizmów służących do: porozumiewania się profesjonalistów, uczenia i objaśniania metod i technik obiektowych, budowy języków, systemów, interfejsów, budowy i objaśniania zasad analizy i projektowania obiektowego. W stosunku do modelu relacyjnego, obiektowość wprowadza znacznie więcej pojęć, często o niezbyt precyzyjnej semantyce. Z jednej strony obiektowość stara się uogólnić i rozszerzyć ideologiczne założenia modelu danych, z drugiej strony stara się objąć nimi te pojęcia, które w modelu relacyjnym nie dały się wyrazić. W chwili obecnej nie istnieje jeden, ogólnie przyjęty, standard jednoznacznie definiujący pojęcia obiektowe. Trwają prace nad ustandaryzowaniem pojęć obiektowych w dziedzinie baz danych, prowadzone między innymi przez ODMG. Brak powszechnie akceptowalnych definicji modelu obiektowego w dziedzinie baz danych wynika z faktu, iż rozwój podejścia obiektowego następował w trzech różnych obszarach: językach programowania, sztucznej inteligencji, bazach danych. W różnych językach programowania i reprezentacji wiedzy przyjęto różne interpretacje pojęć obiektowych. Jednak mimo to, obiektowe języki programowania i reprezentacji wiedzy zawierają wiele spójnych pojęć obiektowych, na podstawie których można stworzyć podstawowy, obiektowy model danych. Przedstawione poniżej pojęcia są podstawowymi dla obiektowości i według [Kim 1996] wchodzą w skład podstawowego modelu obiektowego: obiekt, identyfikator obiektu, 11

12 tożsamość obiektu, klasa, atrybut, metoda, komunikat, hermetyzacja, hierarchia klas i dziedziczenie. W kolejnych rozdziałach pracy zostaną przybliżone przedstawione powyżej pojęcia Obiekt Obiekt (ang. object) jest podstawowym pojęciem dla obiektowości. W pracy [Subieta 1999a] obiekt jest definiowany jako abstrakcyjny byt, reprezentujący lub opisujący pewną rzecz lub pojęcie obserwowane w świecie rzeczywistym. Obiekt jest odróżnialny od innych obiektów, ma nazwę i dobrze określone granice. Obiektem może być także pewna abstrakcja programistyczna. Mogą istnieć obiekty programistyczne, które nie posiadają swoich odpowiedników w świecie rzeczywistym. Obiektem może być pewien zamknięty fragment oprogramowania (dana, procedura, moduł itp.), którymi programista może operować jak pewną zwartą bryłą. Obiektom przypisuje się cechy takie jak: tożsamość, stan i operacje. Obiekt posiada nazwę, jednoznaczną identyfikację, określone granice, atrybuty i inne własności. Tenże autor uważa, iż wiele prac nie różnicuje pojęcia obiektu jako pewnej abstrakcji pojęciowej lub informacyjnej, struktury danych określanej jako obiekt przechowywanej wewnątrz komputera oraz konkretnego obiektu istniejącego w świecie rzeczywistym. Stwierdza on jednak, iż z metodologicznego punktu widzenia takie rozróżnienie jest konieczne i wynika zwykle z kontekstu. Przykładami obiektów ze świata rzeczywistego są: miasto Kraków, faktura, konkretna osoba czy model samochodu. Obiektami nie są przykładowo: śnieg, woda, piasek. 1 1 W literaturze istnieje pojęcie nieobiektu (ang. non-object). W pracy [Subieta 1999a] jest ono przedstawione jako coś, co nie jest obiektem. Autor ten stwierdza, iż nieobiektowość w informatyce wciąż czeka na swego odkrywcę, ideologa i guru. 12

13 RYSUNEK 2.1. GRAFICZNA PREZENTACJA OBIEKTU Identyfikator obiektu Opierając się na definicji przedstawionej przez [Subieta 1999a], identyfikator obiektu (ang. object identifier) jest to unikalna wewnętrzna nazwa obiektu, nadawana automatycznie przez system i nie posiadająca znaczenia w świecie zewnętrznym. Służy on do odróżnienia obiektu od innych obiektów oraz do budowy odwołań prowadzących do obiektu. [Lausen 2000] stwierdza, iż identyfikator przypisany do obiektu pozostaje niezmienny w całym cyklu jego życia. W konsekwencji identyfikator obiektu jest różny od jego wartości, która może ulegać zmianom. W pracy [Subieta 1999a] poruszony jest także problem unikalności identyfikatorów. Autor uważa, iż pojęcie unikalnego identyfikatora obiektu staje się dość trudne w przypadku istnienia wielu kopii tego samego obiektu, lub w przypadku istnienia wielu wersji obiektu. Istnienie unikalnych identyfikatorów obiektów czyni w zasadzie zbędnym pojęcie klucza 2, występujące w modelu relacyjnym. Zdarza się, że identyfikator obiektu jest związany logicznie z adresem miejsca przechowywania obiektu. Jednakże związek tego rodzaju jest uważany za niekorzystny jeśli chodzi o elastyczność w zakresie ulokowania obiektu, z drugiej jednak strony bywa konieczny z uwagi na wymaganą wydajność. 2 Klucz jest atrybutem, bądź zestawem atrybutów, których wartości są wykorzystywane w celu unikalnej identyfikacji. Jest to zbiór minimalny. 13

14 [Ludwikowska 2000] dodaje, iż identyfikator obiektu jest ważnym elementem semantyki języków dostępu i manipulacji obiektami. W praktyce nie występuje bezpośrednie posługiwanie się wartością identyfikatora obiektu, lecz wykorzystywane jest pewne oznaczenie symboliczne, przykładowo nazwa obiektu, które następnie w procesie wiązania jest zmieniane na jego identyfikator Tożsamość obiektu Tożsamość obiektu (ang. identity) jest pojęciem ściśle wiążącym się ze zdefiniowanym wcześniej pojęciem identyfikatora obiektu. Oznacza ono, iż obiekt istnieje i jest odróżnialny od innych obiektów niezależnie od jego aktualnego stanu, który może się zmieniać. Tożsamość obiektu jest kategorią filozoficzną, która nie jest wiązana z jakimkolwiek zestawem atrybutów obiektu lub jego aktualnym stanem. Dopuszczalne jest istnienie dwóch różnych obiektów o identycznych wartościach atrybutów. W praktyce tożsamość oznacza istnienie unikalnego wewnętrznego identyfikatora, nie ulegającego zmianom w trakcie życia obiektu. Tożsamość obiektu jest niezależna od jego lokacji w świecie rzeczywistym lub w przestrzeni adresowej komputera [Subieta 1999a] Klasa Wszystkie obiekty mające ten sam zbiór atrybutów i metod, mogą zostać zgrupowane w jednej klasie. Obiekt należy do klasy jako jej instancja (wystąpienie). Klasa stanowi wzorzec dla tworzonego obiektu. Klasa jest również bytem semantycznym, rozumianym jako miejsce przechowywania, specyfikacji i definicji takich cech grupy podobnych obiektów, które są dla nich niezmienne: atrybuty, metody, ograniczenia dostępu, dozwolone operacje na obiektach, wyjątki. W systemach obiektowych klasa jest traktowana jako obiekt klasowy w celu zagwarantowania jednolitego posługiwania się komunikatami. W związku z tym, z klasą mogą być związane atrybuty i metody klasowe (statyczne). W atrybutach takich przechowywane są wartości wspólne dla wszystkich obiektów tej klasy [Ludwikowska 2000]. 14

15 Istnieje wiele rodzajów klas. Do najważniejszych z nich można zaliczyć: klasę abstrakcyjną oraz klasę konkretną. Pojęcie klasy abstrakcyjnej (ang. abstract class) jest uważane za jedno z podstawowych dla obiektowości, wzmacniające zarówno mechanizmy abstrakcji pojęciowej, jak i możliwości ponownego użycia. Klasa abstrakcyjna zawiera własności, które są dziedziczone przez jej podklasy, ale jednocześnie nie posiada bezpośrednich wystąpień obiektów. Stanowi ona wyższy poziom abstrakcji podczas rozpatrywania pewnego zestawu obiektów. Najczęściej wykorzystuje się klasy abstrakcyjne do zdefiniowania wspólnego interfejsu dla pewnej liczby podklas. Klasa abstrakcyjna może posiadać metody, które są wyspecyfikowane w jej wnętrzu, a których implementacja jest oczekiwana w jej bezpośrednich lub pośrednich podklasach. W odróżnieniu od klasy abstrakcyjnej, klasa konkretna (ang. concrete class) może posiadać bezpośrednie wystąpienia obiektów. RYSUNEK 2.2. GRAFICZNA PREZENTACJA KLASY Atrybut Atrybuty (ang. attributes), będące częścią definicji klasy, poprzez przypisywane im wartości tworzą stan obiektu. Atrybuty obiektu są analogiczne do atrybutów (kolumn) krotki relacji w relacyjnych bazach danych. Dziedziną atrybutu może być jakakolwiek klasa, wliczając w to klasy wartości pierwotnych (np. integer, string itp.). Z powyższego faktu wynika zagnieżdżona struktura definicji klasy. Klasa składa się ze zbioru atrybutów, dziedzinami których mogą być inne klasy z ich własnymi zbiorami 15

16 atrybutów, itd. W wyniku tego definicja klasy określa skierowany graf klas o korzeniu w tej klasie [Kim 1996]. W literaturze pojawia się wiele rodzajów atrybutów. Wśród nich można wyróżnić [Subieta 1999a]: atrybut prosty (ang. simple attribute, atomic attribute) przechowuje dokładnie jedną wartość, będącą z punktu widzenia użytkownika wartością niepodzielną (atomową). atrybut złożony (ang. complex attribute, composite attribute) przechowuje wiele wartości niepodzielnych (atomowych). Atrybut taki może posiadać strukturę hierarchiczną. atrybut klasowy (ang. class attribute) nazywany także statycznym. Nazwa i wartość takiego atrybutu jest wspólna dla wszystkich wystąpień danej klasy. atrybut powtarzalny (ang. repeating attribute) przechowuje zestaw wartości o nieokreślonej i zmiennej w czasie liczbie elementów. atrybut pochodny (ang. derived attribute) nazywany także wyliczalnym. Przechowuje wartość, która jest wyliczana na podstawie innych atrybutów, bądź też innych danych. atrybut wskaźnikowy (ang. pointer attribute) atrybut, którego wartością jest wskaźnik prowadzący zwykle do pewnego obiektu. atrybut opcyjny (ang. optional attribute) atrybut, którego wartość może być pusta, lub który może być nieobecny w konkretnym wystąpieniu obiektu. Opcyjność może dotyczyć atrybutu dowolnego rodzaju. Atrybut ten można uważać za specjalny przypadek atrybutu powtarzalnego, w którym liczba elementów zestawu wartości wynosi zero lub jeden. atrybut domyślny (ang. default attribute) atrybut ten wiąże się pojęciowo z przedstawionym wcześniej atrybutem opcyjnym. Oznacza on wartość przyjmowaną domyślnie, o ile nie została wstawiona żadna inna wartość Metoda Metoda (ang. method) to procedura, funkcja lub operacja przypisana do klasy obiektów i dziedziczona przez jej podklasy. Identyfikacja stanu obiektu oraz 16

17 identyfikacja zmiany stanu obiektu są możliwe dzięki metodom związanym z danym obiektem. W przypadku idealnym, metody zdefiniowane przez programistę powinny być jedynym sposobem dostępu do obiektu. Metoda jest abstrakcją programistyczną tej samej kategorii co procedura lub procedura funkcyjna. Metoda, w przeciwieństwie do procedury, działa w środowisku obiektu po wysłaniu do niego komunikatu zawierającego nazwę tej metody. Metoda wykorzystuje wewnętrzne informacje tego obiektu, jakimi są przede wszystkim wartości atrybutów. Z koncepcyjnego punktu widzenia miejscem przechowywania metody jest odpowiednia klasa. Oznacza to, że metoda takowa może zostać zastosowana do dowolnego obiektu będącego instancją tej klasy. Istnieje kilka charakterystycznych metod posiadających odrębne nazewnictwo. Zaliczyć do nich można następujące rodzaje metod: metoda abstrakcyjna (ang. abstract method) jest to metoda, której specyfikacja znajduje się w danej klasie, ale której implementacje znajdują się w podklasach. metoda fabrykująca (ang. factory method) nazywana inaczej konstruktorem. Służy do tworzenia nowych obiektów. metoda klasowa (ang. class method) metoda ta nie działa na pojedynczych wystąpieniach danej klasy (obiektach), lecz na całej ekstensji klasy Komunikat Komunikat (ang. message) jest sygnałem skierowanym do obiektu, wywołującym określoną metodę lub operację, którą należy wykonać na obiekcie. Nazwa użyta w komunikacie jest nazwą wywoływanej metody. Źródłem komunikatu jest działający aktualnie program, w szczególności może to być wykonywana aktualnie metoda. Komunikat może posiadać parametry; zwykle jest ich co najwyżej kilka, w każdym razie parametry komunikatu nie służą do przenoszenia większej ilości informacji. Obiekt otrzymujący komunikat wykonuje odpowiednią metodę, która to metoda może zmienić jego stan. W efekcie wykonania metody na obiekcie, który otrzymał komunikat, może zostać zwrócona odpowiedź do nadawcy komunikatu. 17

18 W wielu opracowaniach uważa się, że zarówno komunikat, jak i nazwy występujące w ciele metody są dynamicznie wiązane, w związku z czym ten sam komunikat może zostać wysłany do różnych obiektów i może wywołać różne metody. Fakt ten posiada istotne znaczenie dla metod oraz technik projektowania i programowania [Subieta 1999a] Hermetyzacja Hermetyzacja (ang. encapsulation) polega na grupowaniu elementów składowych w obrębie jednej bryły i umożliwieniu manipulowania tą bryłą jako całością. Hermetyzacja wiąże się z ukrywaniem pewnych informacji dotyczących struktury i implementacji wnętrza tej bryły [Ludwikowska 2000]. Hermetyzacja jest podstawową techniką abstrakcji, czyli ukrycia wszelkich szczegółów danego przedmiotu lub bytu programistycznego, które na danym etapie rozpatrywania (analizy, projektowania, programowania) nie stanowią jego istotnej charakterystyki [Subieta 1999a]. Pojęcie hermetyzacji, jako jedna z zasad inżynierii oprogramowania, zostało sformułowane przez D. Parnasa w roku Można wyróżnić dwie koncepcje hermetyzacji: hermetyzacja ortodoksyjna oraz hermetyzacja ortogonalna. Pierwsza z nich, hermetyzacja ortodoksyjna, jest dość popularnym stereotypem w obiektowości. Ten rodzaj hermetyzacji został zaimplementowany między innymi w języku Smalltalk. W tym podejściu wszelkie operacje, jakie można wykonać na obiekcie, są określone przez metody do niego przypisane (znajdujące się w jego klasie i nadklasach). Bezpośredni dostęp do atrybutów obiektu jest niemożliwy. Drugim rodzajem jest hermetyzacja ortogonalna, zaimplementowana między innymi w językach C++ i Eiffel. W tym przypadku dowolny atrybut i metoda obiektu mogą być prywatne (czyli niedostępne z zewnątrz), bądź też publiczne Hierarchia klas i dziedziczenie Klasy w systemie tworzą hierarchię klas (ang. class hierarchy). Oznacza to, że dla pewnej klasy A może istnieć inna klasa (jedna lub więcej) B, znajdująca się na 18

19 niższym poziomie, która jest uszczegółowieniem (specjalizacją) klasy B. Natomiast klasa A, będąca na wyższym poziomie w hierarchii, jest uogólnieniem (generalizacją) klasy (klas) B. Klasa B dziedziczy wszystkie atrybuty i metody klasy A, mogąc jednocześnie posiadać własne atrybuty i metody. Określone dla klasy A atrybuty i metody są rekurencyjnie dziedziczone przez wszystkie jej podklasy (rys. 2.3). Większość systemów obiektowych posiada predefiniowaną przez system klasę, stanowiącą jedyny korzeń dla wszystkich klas w systemie. Hierarchia klas jest spójna, co oznacza, że nie istnieją odizolowane węzły, natomiast do każdego węzła (klasy) istnieje dostęp z korzenia. RYSUNEK 2.3. HIERARCHIA KLAS I DZIEDZICZENIE. Cechą wspólną dla wszystkich bez wyjątku systemów obiektowych jest to, że klasa może posiadać dowolną liczbę podklas. Jednakże w pewnych systemach klasy mogą mieć tylko jedną nadklasę, natomiast w innych klasy mogą mieć dowolną liczbę nadklas. 19

20 Pierwszy przypadek, kiedy klasa dziedziczy atrybuty i metody od tylko jednej klasy, nazywany jest dziedziczeniem pojedynczym (ang. single inheritance). W sytuacji takiej każda klasa ma co najwyżej jedną nadklasę. Drugi przypadek dotyczy klasy, która dziedziczy atrybuty i metody od więcej niż jednej nadklasy. Sytuacja taka nosi nazwę dziedziczenia wielokrotnego (ang. multiple inheritance). Jeżeli system umożliwia wielokrotne dziedziczenie, wówczas klasy tworzą zakorzeniony spójny skierowany graf acykliczny, nazywany czasem kratą klas. Nie ma porozumienia odnośnie tego, czy wielokrotne dziedziczenie jest naprawdę konieczne. Jednakże pomimo tego, iż ten rodzaj dziedziczenia komplikuje model danych, wydaje się, że jest ono potrzebne i jego zaakceptowanie jest nieuniknione [Kim 1996]. Metody odziedziczone mogą zostać przeciążone. Oznacza to, iż podklasa może zmodyfikować działanie odziedziczonej metody nie zmieniając jej nazwy. Pojęcie dziedziczenia stwarza pewne problemy, takie jak: konflikty nazw, zasięg dziedziczenia, naruszenia hermetyzacji. Są to jednak sytuacje charakterystyczne dla programowania obiektowego, dlatego nie należy ich traktować jako wady rzutujące negatywnie na decyzje, czy stosować dziedziczenie Pojęcia wykraczające poza model podstawowy Przedstawione powyżej pojęcia wchodzące w skład podstawowego modelu obiektowego w większości przypadków zaspokajają podstawowe wymagania dotyczące modelowania danych. Istnieje jednak wiele ważnych pojęć, które są istotne w wielu przypadkach, ale które nie należą do pojęć podstawowych. W tym rozdziale postaramy się przedstawić trzy z takich pojęć. Są to: polimorfizm, obiekty złożone oraz zarządzanie wersjami. Polimorfizm (ang. polymorphism) w terminologii obiektowej oznacza możliwość istnienia wielu metod o takiej samej nazwie, powiązaną z możliwością wyboru konkretnej metody podczas czasu wykonania (dynamicznego wiązania). Wybór nazwy jest określany wyłącznie jej zewnętrznym, pojęciowym znaczeniem w ramach danej klasy obiektów. Wybór ten nie jest uwarunkowany własnościami lub 20