Obiektowość



Pobieranie 6.06 Mb.
Strona2/26
Data28.10.2017
Rozmiar6.06 Mb.
1   2   3   4   5   6   7   8   9   ...   26

Wstęp

  1. Geneza


Obiektowość jest informatyczną ideologią, która zdobywa coraz liczniejsze grono zwolenników oraz coraz częściej jest obecna w produktach przemysłu informatycznego, w literaturze informatycznej, programach nauczania i działalności naukowej. Jako początek rozwoju obiektowości można uznać rok 1980, kiedy pojawił się język Smalltalk. Od tego czasu obiektowość przeniknęła duże obszary informatyki, włączając takie dziedziny jak języki programowania, metodyki analizy i projektowania systemów, bazy danych, systemy rozproszone, narzędzia do rozwoju aplikacji, systemy operacyjne, i inne. Spontaniczny rozwój obiektowości zaowocował oceanem wiedzy, w którym nawet ambitni specjaliści poruszają się z wielkim trudem. Informatyka, jak chyba żadna inna dziedzina, napędza się przede wszystkim coraz to nowymi wynalazkami, zaś w powodzi wynalazków nie wystarcza czasu i zapału do budowania syntetycznych zasad, teorii, klasyfikacji, spójnych systemów pojęć. Z tego powodu wiedza o obiektowości jest w dużym stopniu pochodną ideologicznych założeń, teorii o podłożu intelektualno-estetycznym, idealizującego myślenia życzeniowego i (przede wszystkim) faktów: metod, języków, bibliotek, systemów, standardów, metodyk. Czytanie literatury informatycznej, często odwołującej się do pojęć obiektowości, może być utrudnione ze względu na gąszcz terminów, akronimów, nazw języków, systemów, metodyk, itd.

Celem tego słownika jest uporządkowanie polskiej terminologii w zakresie obiektowości. Jednocześnie słownik zawiera wyjaśnienia różnych pojęć obiektowości, mniej lub bardziej szczegółowe, w zależności od wagi danego pojęcia, stopnia jego skomplikowania, kontrowersji definicyjnych i (daleko nie pełnej) wiedzy autora. Słownik jest archipelagiem małych wysepek w oceanie wiedzy, które (mamy nadzieję) ułatwią ogólną orientację, przyczynią się do zrozumienia wielu kwestii i wspomogą Czytelnika podczas głębszych studiów dotyczących konkretnych tematów związanych z obiektowością.

Słownik zawiera ok. 1500 terminów. Wśród nich znajdują się propozycje polskiej terminologii, wraz z odpowiednikami angielskimi i lakonicznym wyjaśnieniem znaczenia, wyjaśnienia popularnych akronimów występujących w literaturze angielskiej (które przenikają do literatury polskiej), nazwy języków i systemów oraz nazwiska sławniejszych twórców. Niektóre z haseł, takie jak agregacja, CORBA, UML, hermetyzacja, ODMG, manifest, niezgodność impedancji, itd. są w istocie pretekstem do krótkich esejów wyjaśniających dany temat oraz prezentujących poglądy autora.

Ze względu na nieustaloną terminologię (różne rozumienie tych samych terminów) znaczenie niektórych terminów może być wyjaśnione inaczej w pracach innych autorów. Poważnym problemem w literaturze angielskiej jest synonimia i homonimia, która nie we wszystkich przypadkach jest oczywista. Na przykład, co wiąże terminy „polimorfizm”, „przesłanianie”, „dynamiczna dyspozycja”, „późne wiązanie”, „funkcja wirtualna”? W wielu przypadkach autorzy opracowań w języku angielskim używają tego rodzaju terminów dość dowolnie, często naciągając ich znaczenie do danej sytuacji, lub wręcz używając ich niewłaściwie. Ta sytuacja (prawdopodobnie nieuchronna zważywszy na spontaniczny rozwój technologii obiektowych) wymagała podjęcia decyzji odnośnie polskiej terminologii. W odróżnieniu od wielu podobnych opracowań w języku angielskim, które relatywizują znaczenie terminów w zależności od konkretnego autora, języka, standardu, metodyki lub systemu, niniejszy słownik zawiera wyjaśnienia najbardziej typowe. Mimo że taka metoda może być obciążona subiektywizmem (specyficznym rozumieniem terminu przez autora), pozwala jednak na lakoniczność, nie wdawanie się w często dość mętne dywagacje semantyczne, które towarzyszą wielu pojęciom obiektowości.

Problemem, który (jak należy sądzić) dotyczy wszystkich specjalistycznych słowników, jest ustalenie granicy pomiędzy terminologią specjalistyczna a potoczną mową. Często powszechnie używane wyrazy uzyskują w terminologii specjalistycznej specyficzne znaczenie, ale granica pomiędzy rozumieniem potocznym i rozumieniem specjalistycznym jest rozmyta. Podobnym problemem jest kombinacja wyrazów czy też dodawanie potocznych określników do już wykształconej terminologii. Np., czy termin „obiekt złożony” jest kombinacją specyficznego terminu „obiekt” z potocznym określnikiem „złożony”, czy też stanowi nową jakość, którą warto odnotować w słowniku? Tego rodzaju dylematy powodują, że w słowniku Czytelnik może znaleźć wiele złożonych terminów, które są prostą semantyczną kombinacją ich składowych, jak również może odczuwać niedosyt w zakresie wyjaśnienia pewnych kombinacji wyrazów spotykanych w literaturze, szczególnie komercyjnej. Decyzje co do tego, który wyraz lub kombinacja wyrazów zasługuje na to, aby ją odnotować w słowniku, była często subiektywna i w dużym stopniu losowa.

W polskiej literaturze informatycznej jest sporo książek poświęconych obiektowości, wśród nich książki z zakresu języków programowania, baz danych i metodyk analizy i projektowania. Autor starał się dostosować do występujących tam polskich terminów, ale okazało się, że nie jest to proste. Jedną z trudności było to, że różni autorzy lub tłumacze używają nieco odmiennej terminologii. Ponadto, zwykle książki mają określony zakres tematyczny, w obrębie którego występuje mniejsze ryzyko kolizji znaczeniowej (homonimii) wyrazów. W tym słowniku okazało się konieczne dopasowanie terminologii jednocześnie do wielu szerokich dziedzin informatycznych, które są objęte technologiami obiektowymi. Z tego względu niektóre propozycje podane w tym słowniku mogą odbiegać od terminologii stosowanej przez innych polskich autorów lub tłumaczy.

Jest dość trudno wynajdywać polskie odpowiedniki dla terminów, które również w języku angielskim są w większości neologizmami. Istnieje wiele kryteriów translacji terminologii. Wśród nich można mówić o kryterium podobieństwa (kiedy termin angielski zastępujemy terminem spolszczonym o tym samym brzmieniu), kryterium minimalizacji energii Zipfa (termin często używany nie powinien być zbyt długi, bo i tak po pewnym czasie zostanie skrócony), kryterium wierności translacji słownikowej z angielskiego na polski, kryterium zachowania potocznej skojarzeniowej semantyki, kryterium unikania homonimii i synonimii, kryterium estetyczne, itd. Autor wykonał spory wysiłek wertując słowniki w poszukiwaniu najbardziej trafnego polskiego odpowiednika, starając się przy tym unikać neologizmów, spolszczonych kalek językowych, terminów zbyt ogólnych w stosunku do danego pojęcia, lub terminów „zgrzytających”, wymagających wysiłku w wymowie. Wbrew niektórym „ulepszaczom” polskiej terminologii informatycznej, którzy za wszelką cenę starają się wyszukać polski wyraz dla pojawiającego się nowego pojęcia, autor przyjął założenie, że zaadoptowanie terminu angielskiego jest często znacznie lepsze i ma większe szanse na powszechną akceptację, niż niezrozumiały językowy dziwoląg (taki jak np. „sprzęg” dla angielskiego interface lub „wyłuskiwanie” dla dereferencing). Dotyczy to kilkunastu przypadków, takich jak aplet, aglet, instancja, kast, koercja, kohezja, kowariancja, kursor, pragma, referencja, serwlet, widżet, itd. Są to również neologizmy w języku angielskim. Autor ma nadzieję, że podanymi propozycjami terminologicznymi nie narazi się Czytelnikom już przyzwyczajonym do nieco innej terminologii lub też posiadającym negatywny stosunek do wprowadzania do języka polskiego terminów obcego pochodzenia.

Słownik nie pretenduje do kompletności, tym bardziej, że obiektowość znajduje się w fazie dynamicznego rozwoju i każdy nowy rok owocuje szeregiem nowych terminów. Dla porównania, popularny słownik dotyczący obiektowości, skąd zaczerpnęliśmy wiele terminów: D.G.Firesmith, E.M.Eykholt. Dictionary of Object Technology. SIGS BOOKS, 1995 zawiera ponad 600 stron i wykazuje brak wielu terminów, które pojawiły się w międzyczasie (i które umieściliśmy w tym słowniku). Słownik zawiera też sporo terminów (takich jak ACID, transakcja, SQL, model relacyjny, itd.), które wprawdzie nie należą bezpośrednio do terminologii związanej z obiektowością, ale bardzo często występują w literaturze na temat obiektowości, szczególnie przemysłowo-komercyjnej.

Większość materiału prezentowanego w tym słowniku pochodzi z przeogromnej bazy danych zwanej WWW. Wyliczenie wszystkich źródeł WWW, z których autor korzystał, jest przedsięwzięciem beznadziejnym: były ich tysiące. Autor starał się podać źródła WWW przy niektórych hasłach, ale należy liczyć się z tym, że mogą one w każdej chwili utracić aktualność ze względu na dynamikę zmian w stronach WWW. Autor korzystał z popularnych serwisów WWW, takich jak AltaVista (www.altavista.com), HotBot (www.hotbot.com) i Yahoo (www.yahoo.com), które w odpowiedzi na dowolne hasło umieszczone w tym słowniku dostarczają dziesiątki, setki lub tysiące stron WWW, gdzie jest ono obecne. WWW zawiera także wiele gotowych słowników z zakresu obiektowości, chociaż mniejszych i mniej precyzyjnych niż niniejszy słownik.

Podobna sytuacja występuje z materiałami drukowanymi - istnieją dziesiątki tysięcy publikacji na poruszane w tym słowniku tematy. Podczas ich czytania jest dość trudno jednocześnie odnotowywać zawarte w nich istotne myśli lub pojęcia oraz analizować ich etymologię. Z tego powodu słownik zawiera bardzo ograniczony spis literatury, ponieważ przy obecnym zalewie informacji ta tradycyjna formuła prac naukowych przestała mieć większy sens.

Autor wyraża podziękowanie dla osób, które w różny sposób wspomogły pracę nad tym słownikiem. Wiele kwestii terminologicznych zostało rozstrzygnięte podczas dyskusji w ramach listy dyskusyjnej pl.comp.objects; podziękowania należą się Kubie Chabikowi, Adamowi Karpierzowi, Andrzejowi Lewandowskiemu, Januszowi Stopie i innym uczestnikom listy za owocne dyskusje pozwalające mi uświadomić znaczenie różnych terminów. Prace nad słownikiem były wspomagane merytorycznie i formalnie przez Jacka Leszczyłowskiego i Ewę Stemposz. Wkład w dopracowanie haseł tego słownika wnieśli także Grzegorz Bliźniuk, Artur Kasprzyk i Krzysztof Stencel. Szczególne podziękowania należą się Jackowi Płodzieniowi, który wykazał ogromną cierpliwość czytając bardzo uważnie manuskrypt słownika i poprawiając w nim setki mniejszych lub większych błędów, nieścisłości i niekonsekwencji.

Jest rzeczą pewną, że po jakimś czasie część terminów występujących w tym słowniku będzie nieaktualna. Pojawią się też nowe terminy. Stąd wynika konieczność ciągłej pracy nad aktualizacją słownika. Autor zamierza ponawiać wydania zaktualizowanych i poprawionych wersji tego słownika, w związku z czym zwraca się z prośbą do wszystkich osób zainteresowanych obiektowością o włączenie się do jego redakcji.


Autor zachęca firmy komputerowe, które chciałyby umieścić w kolejnej edycji słownika hasła związane z ich produktami, o przesyłanie propozycji.
Wszelkie uwagi dotyczące tego słownika, propozycje zmiany terminów, propozycje wprowadzenia nowych terminów, propozycje zmiany organizacji słownika, itp. proszę przesyłać na adres autora: subieta@ipipan.waw.pl

    1. Obszary oddziaływania obiektowości


Obiektowość jest doktryną ideologiczną, która stara się ukształtować wiele dziedzin informatyki. Ich listę podajemy niżej.


  • Inżynieria oprogramowania, a w szczególności metodyki analizy i projektowania systemów informatycznych oraz związane z nimi notacje graficzne (OMT, Booch, Objectory, Coad/Yourdon, Martin/Odell, Shlaer/Mellor, Wirfs/Brock, FUSION, OPEN, UML i wiele innych). Wiele z nich posiada odbicie w narzędziach CASE (komputerowym wspomaganiu inżynierii oprogramowania). Najbardziej istotna zmiana w stosunku do poprzednich metodyk polega na możliwości precyzyjnego wyspecyfikowania operacji, które można wykonać na obiektach oraz znacznie większy nacisk na problem ponownego użycia.

  • Języki programowania: Smalltalk, C++, Java, Eiffel, Beta, OO-COBOL, Ada95, i wiele innych. Języki te wprowadzają nowe pojęcia bezpośrednio odnoszące się do obiektowości, takie jak: klasy, metody, dziedziczenie, hermetyzacja, późne wiązanie i polimorfizm. Pewnym zjawiskiem (pozytywnym i negatywnym) są tendencje budowy języków hybrydowych, polegające na wyposażaniu znanych języków programowania (C, Pascal, Modula, Ada, itd.) w wymienione wyżej cechy.

  • Bazy danych i składy trwałych obiektów. Koncepcje i pojęcia obiektowości są przenoszone do dziedziny baz danych; jest to grunt, na którym obiektowość może w pełni zrealizować swoją misję. Powstało wiele systemów zarządzania obiektowymi bazami danych, w szczególności GemStone, Versant, ObjectStore, O2, Poet, i inne. Podobnie jak w przypadku języków programowania, silnie zaznaczają się tendencje eklektyczne, polegające na wyposażaniu popularnych systemów relacyjnych (Oracle, DB2, Informix, Sybase, Ingres, itd.) w niektóre cechy obiektowości oraz budowie systemów hybrydowych relacyjno-obiektowych. Próbą uporządkowania koncepcji obiektowych w dziedzinie baz danych są prace standardyzacyjne prowadzone przez grupę ODMG (Object Database Management Group). Również nowy standard języka SQL, znany jako SQL3, wprowadza wiele cech obiektowości. Obiektowość w bazach danych adaptuje wiele rozwiązań systemów relacyjnych, w szczególności: dostęp do danych i ich przetwarzanie przy pomocy języków zapytań, zarządzanie pamięcią zewnętrzną, zarządzanie transakcjami, i inne.

  • Współdziałanie systemów heterogenicznych. Obiekty, klasy i inne cechy obiektowości są proponowane jako elementy standardowego interfejsu pośredniczącego w wymianie informacji pomiędzy niezależnie zbudowanymi, heterogenicznymi systemami. Na takim pomyśle jest oparty standard CORBA zaproponowany przez grupę OMG oraz standardy COM i DCOM firmy Microsoft.

  • Wizyjne środki programistyczne. Zakładają one użycie pojęć i technik obiektowych w środowiskach programowania wizyjnego. Takie środowisko oferuje Smalltalk (w tym sensie jest on czymś więcej niż tylko językiem programowania). Na koncepcji Smalltalk’a jest oparte środowisko VisualAge firmy IBM, a także szereg środowisk programistycznych określanych jako języki czwartej generacji (Fourth Generation Languages, 4GL) lub narzędzia szybkiej budowy aplikacji (Rapid Application Development, RAD).

  • Inne: biblioteki oprogramowania (biblioteki klas), grafika, miary i oceny oprogramowania, reinżynieria biznesu (BPR), zarządzanie pracą grupową (groupware) i przepływem pracy (workflow), magazyny danych (data warehouses), systemy operacyjne, niektóre metody sztucznej inteligencji oraz sieci komputerowe, w tym Internet i WWW.


  1. Słownik encyklopedyczny


0-9

1NF (First Normal Form) Patrz: pierwsza postać normalna.

2NF (Second Normal Form) Patrz: druga postać normalna.

2PC (Two-Phase Commit) Patrz: dwufazowe potwierdzenie.

2PL (Two-Phase Locking) Patrz: dwufazowe blokowanie.

3GL (Third Generation Language) Patrz: język trzeciej generacji.

3NF (Third Normal Form) Patrz: trzecia postać normalna.

4GL (Fourth Generation Language) Patrz: język czwartej generacji.

A

A

abstrakcja (abstraction) Eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów oraz wprowadzanie pojęć lub symboli oznaczających takie cechy. Abstrakcja jest podstawową zasadą obiektowości. Oprócz klasycznych procedur, modułów i typów, abstrakcję wspomagają takie pojęcia jak klasy, dziedziczenie, metody, hermetyzacja, późne wiązanie i polimorfizm.

abstrakcja proceduralna (procedural abstraction) Nazwany byt programistyczny hermetyzujący pewien ciąg instrukcji (procedura, funkcja, operacja, metoda, itp.), traktowany przez programistę (i niekiedy przez system) jako zamknięta jednostka modelu pojęciowego konstruowanego oprogramowania.

abstrakcje danych (data abstractions) Ogólne określenie pojęć takich jak: generalizacja (generalization), specjalizacja (specialization), klasyfikacja (classification), agregacja (aggregation) i asocjacja (association). Abstrakcje danych są paradygmatem tzw. semantycznych modeli danych służących do modelowania pojęciowego, w szczególności modelu encja-związek i modeli obiektowych.

abstrakcyjny typ danych (abstract data type, ADT) Pojęcie (udostępniane w niektórych językach programowania) oparte na założeniu, że typ struktury danych jest skojarzony z operacjami działającymi na elementach tego typu. Nie istnieje potrzeba i możliwość używania operacji nie należących do oferowanego zestawu; operacje są kompletne i wyłączne (patrz: hermetyzacja). Bezpośredni dostęp do składowych takiej struktury danych nie jest możliwy, dzięki czemu jej szczegóły implementacyjne (np. zestaw i reprezentacja atrybutów) są niewidoczne. Nie jest możliwe przetwarzanie struktur ADT przy pomocy operacji generycznych (generic), np. przy pomocy operacji odzyskania wartości atrybutu (dereferencji) lub operacji podstawienia. Klasycznym przykładem abstrakcyjnego typu danych jest stos, wraz z operatorami takimi jak push (połóż element na wierzchołku stosu), pop (zdejmij element z wierzchołka stosu), top (odczytaj element znajdujący się na wierzchołku stosu) i empty (sprawdź, czy stos jest pusty). Po zadeklarowaniu lub utworzeniu zmiennej X jako stosu, wszelkie operacje na tej zmiennej odbywają się poprzez powyższe cztery operatory.

Mechanizm ADT może odnosić się do wartości lub do obiektów. W wielu propozycjach (np. w systemach obiektowo-relacyjnych) ADT jest kojarzony z obiektowością. ADT jest cechą nowego standardu SQL3 i stanowi o jego obiektowości. Do pewnego stopnia jest to uzasadnione: element należący do ADT jest zwykle pewną strukturą złożoną z wielu wartości i w tym sensie przypomina obiekt, zaś manipulowanie takim elementem wyłącznie przy pomocy operatorów realizuje tę zasadę hermetyzacji, którą przypisuje się pojęciu klasy.

Z drugiej jednak strony, ADT może być uważany za pojęcie węższe lub ortogonalne w stosunku do pojęcia klasy. W szczególności, w czystej postaci ADT nie zakłada dziedziczenia (nie dotyczy to SQL3), nie uwzględnia powiązań pomiędzy obiektami (wystąpieniami ADT), ani też ich tożsamości. ADT nie zajmuje się innymi inwariantami klas niż operacje. ADT nie zakłada również operatorów działających jednocześnie na wszystkich aktualnych wystąpieniach ADT (czyli na ekstensji klasy).

Pojęcie ADT jest istotnie różne od pojęcia typu (konkretnego), m.in. ze względu na różnice celów pragmatycznych tych dwóch pojęć. Wielu autorów plącze pojęcie ADT z pojęciem typu, co często prowadzi do nieporozumień.



ACID (Atomicity, Consistency, Isolation, Durability) Podstawowe własności pojęcia transakcji: atomowość, spójność, izolacja, trwałość; patrz: transakcja.

ActiveX Technologia Microsoftu integrująca technologie określane jako OLE, OLE2, COM, DCOM; przystosowana do współpracy z Internetem. Podzbiór technologii ActiveX jest przedmiotem prac standardyzacyjnych w ramach konsorcjum Active Group. Patrz też: OLE, OLE2, COM, DCOM.

http://www.microsoft.com/activex/

http://www.activex.org/


Ada95 Nowa, rozszerzona wersja języka Ada z roku 1995. Dodatkowe cechy włączają: obiektowość, etykietowane typy (tagged types), typy abstrakcyjne i klasowe (class-wide), hierarchiczne biblioteki, i inne. Nie posiada wielodziedziczenia, ale wspomaga je poprzez generalia (generics) oraz kompozycję typów.

http://lglwww.epfl.ch/Ada/FAQ/

http://www.acm.org/sigada/

http://sw-eng.falls-church.va.us/AdaIC/



adapter obiektów (object adapter) Termin OMG CORBA; oznacza oprogramowanie służące do zamiany interfejsu przewidzianego przez implementację obiektu na bardziej abstrakcyjny interfejs oczekiwany przez pośrednika ORB (wyspecyfikowany w IDL).

http://www.omg.org



administrator bazy danych (data base administrator, DBA) Osoba lub grupa osób odpowiedzialna za jedną lub więcej baz danych podtrzymywanych przez pewien SZBD. Administrator bazy danych tworzy bazę danych oraz dba o jej spójność, integralność i bezpieczeństwo. Nadaje przywileje i prawa do korzystania z baz danych dla poszczególnych użytkowników.

ADT (Abstract Data Type) Patrz: abstrakcyjny typ danych.

agent (agent) Patrz: aktywny agent.

aglet (aglet) Pojęcie zbliżone do apletu wprowadzone przez IBM. W odróżnieniu od apletu, aglet podczas transmisji w sieci przenosi swój aktualny stan wykonania, co daje ogromne możliwości, w szczególności w zakresie tworzenia tzw. aktywnych lub mobilnych agentów. Patrz: aktywny agent.

Agora Obiektowy język programowania bazujący na pojęciu prototypu; zaprojektowany na Uniwersytecie w Brukseli, Belgia.

http://progwww.vub.ac.be/prog/pools/agora/agora.html



agregacja (aggregation) Związek pomiędzy klasami obiektów (szczególny przypadek asocjacji), modelujący stosunek całości do jej części (np. stosunek samochodu do silnika). Obiekty są powiązane związkiem agregacji, jeżeli jeden z nich można uważać za część drugiego, zaś cykl i czas życia tych obiektów są jednakowe. Pojęcie agregacji w modelowaniu jest niejasne i rodzące mnóstwo wątpliwości semantycznych i pragmatycznych. Nie istnieje powszechnie akceptowana definicja agregacji, zaś wątpliwości co do jej znaczenia są zasadnicze. Np. Peter Coad podaje jako przykład agregacji związek pomiędzy organizacją i jej urzędnikami; dla odmiany James Rumbaugh twierdzi, że firma nie jest agregacją jej pracowników. Komu wierzyć? Wątpliwości powstają nawet w tak banalnym przypadku, jak cytowany wyżej przykład samochodu i silnika. Silnik może być towarem w sklepie nie związanym z żadnym samochodem lub może być przełożony z jednego samochodu do drugiego; wobec czego jest samodzielnym obiektem. Ponadto powstaje pytanie, czy chodzi o konkretny samochód i konkretny silnik, czy też o typ samochodu i typ silnika; w tym drugim przypadku większość analityków nie zgodziłaby się z założeniem, że silnik jest częścią samochodu. Podane przykłady pokazują powody, dla których formalna definicja agregacji grzęźnie w mętnych dywagacjach, z których trudno wyprowadzić jasne i naturalne zasady użycia tego pojęcia.

Dodatkowy mętlik wynika z wykorzystywania pojęcia agregacji do rozwiązywania pewnych technicznych problemów związanych z ograniczeniami modelu obiektowego. Np. popularne wyjaśnienie technik obejścia braku wielodziedziczenia mówi, że można je „odwzorować przez agregację”. Np., jeżeli klasa emerytowanych pracowników dziedziczy zarówno od klasy Emeryt jak i od klasy Pracownik, wówczas „odwzorowanie wielodziedziczenia przez agregację” oznacza, że obiekt emerytowanego pracownika zawiera jako swoją „część” inny obiekt grupujący informację o cechach osoby jako emeryta. Mówi się, że obiekty pracownika i emeryta pozostają w związku agregacji; emeryt „jest częścią” pracownika (sic). Tego rodzaju pseudowyjaśnienia, dodatkowo splątane z równie mętną interpretacją pojęcia „delegacji”, powodują nie lada zamieszanie w głowach tych, którzy próbują dokładnie zrozumieć istotę pojęcia agregacji i jego stosowalność w konkretnych sytuacjach. Dodać należy, że żaden z istniejących obiektowych języków, systemów i standardów nie wprowadza agregacji jako wyróżnionego, odrębnego pojęcia programistycznego, odwołuje się więc ono wyłącznie do ludzkiej wyobraźni.

Autorzy UML podejmują próbę uporządkowania pojęcia agregacji. Wprowadzili oni mocniejszą formę agregacji, nazywając ją kompozycją. Związek kompozycji oznacza, że dana część może należeć tylko do jednej całości. Taka część nie może istnieć bez całości, pojawia się i jest usuwana razem z całością. Przy takim zróżnicowaniu pojęć pozostaje jednak problem, co dokładnie oznacza „słaba” forma agregacji i jakie są pragmatyczne reguły jej użycia.

http://www.rational.com/uml/



agregat (aggregate) Ogólne określenie dowolnego pojęcia (klasy, kontenera, obiektu, ekstensji, grona, stanu, zbioru, tablicy, sekwencji, itd.), które może zawierać wiele części składowych.

agregat rekurencyjny (recursive aggregate) Agregat złożony z elementów tego samego typu. Np. agregatem rekurencyjnym jest część samochodu, ponieważ składa się z części, które również składają się z części, itd.

akcesor (accessor) W języku Smalltalk metoda, która zwraca wartość zmiennej wystąpienia (instance variable).

akcja (action) W modelach dynamicznych lub diagramach stanów czynność, która powoduje zmianę stanu lub ma niezauważalny czas trwania. Obiekt, który otrzymuje komunikat, wykonuje akcję odpowiadającą temu komunikatowi. Akcją może być np. wywołanie metody, wyzwolenie zdarzenia, start lub zakończenie aktywności, itd.

aktor (actor) W metodykach analizy i projektowania (np. w modelu przypadków użycia): obiekt modelujący określoną rolę zewnętrznego użytkownika systemu. Aktor może operować na innych obiektach, ale sam nie podlega operacjom ze strony innych obiektów. W językach tzw. aktorowych: fragment programu o dużym stopniu autonomii, działający równolegle (asynchronicznie i niezależnie) oraz posiadający własny stan i sterowanie. Synonimy: aktywny obiekt, agent, aktywny agent.

aktualizacja (updating) Zmiana wartości zmiennej, obiektu, atrybutu; operacja podstawienia.

aktualizacja perspektyw (view updating) Problem teoretyczny i technologiczny polegający na znalezieniu skutecznych, spójnych i uniwersalnych metod aktualizacji danych widzianych i udostępnianych przez perspektywę bazy danych (database view). Perspektywę można zdefiniować jako odwzorowanie zapamiętanych danych w dane lub obiekty wirtualne (virtual data, virtual objects). Istotne jest tu zapewnienie przezroczystości, tj. użytkownik nie powinien być świadomy tego, że aktualizuje dane wirtualne, a nie zapamiętane. Aktualizacja wirtualnych danych prowadzi do zasadniczych problemów. Dość często istnieje wiele odwzorowań aktualizacji wirtualnych danych na aktualizację zapamiętanych danych. Np. jeżeli wirtualna dana zawiera średni zarobek pracowników i ktoś chciałby go podwyższyć, to istnieje nieskończenie wiele sposobów odwzorowania tej podwyżki na podwyżki dla konkretnych pracowników. Bez dodatkowej informacji lub reguły takie odwzorowanie jest niemożliwe. Może również nie istnieć jakiekolwiek poprawne odwzorowanie aktualizacji wirtualnych danych na aktualizację zapamiętanych danych. Innym problemem są efekty uboczne: aktualizacja pewnej wirtualnej danej pociąga za sobą aktualizację innych wirtualnych danych lub aktualizację danych, które nie są objęte zakresem danej perspektywy.

Problem aktualizacji perspektyw zajmuje sporo miejsca w literaturze ze względu na jego wagę dla niezależności danych, przystosowania danych do potrzeb konkretnego użytkownika, współdziałania systemów heterogenicznych, przenaszalności, itd. Perspektywy są również mocnym mechanizmem abstrakcji i ograniczenia dostępu do danych. Istnieje wiele prac dotyczących aktualizacji perspektyw w modelu relacyjnym, ale w większości proponują one niepraktyczne teorie nie mające istotnych skutków dla informatycznej rzeczywistości. W relacyjnych SZBD aktualizacja perspektyw jest ograniczona do bardzo uproszczonych sytuacji, z reguły do wirtualnych tablic będących pionowym lub poziomym obcięciem tablic zapamiętanych, z zachowaniem klucza głównego. Istnieje kilka prób podejścia do problemu aktualizacji perspektyw w obiektowych bazach danych; jak dotąd, problem znajduje się w fazie badawczej.



aktualizuj (update) Nazwa operacji podstawienia (assignment) definiowana w językach programowania baz danych, w szczególności w SQL. Przykładowe zdanie aktualizacji w SQL (podwyżka zarobku dla Nowaka) ma postać:

update Pracownik

set Zarobek = Zarobek+100

where Nazwisko = ‘Nowak’;

aktyw (l.mn. aktywa) (asset) Termin kojarzony z ponownym użyciem (reuse), oznaczający skatalogowany i nazwany składnik oprogramowania lub projektu systemu, który może być jednostką ponownego użycia.

aktywacja (activation) Skopiowanie danych (oraz niekiedy metod) z trwałego nośnika do przestrzeni adresowej wykonywalnych programów celem przetwarzania tych danych (np. poprzez metody).

aktywna baza danych (active database, reactive database) Baza danych zawierająca aktywne reguły.

aktywne reguły (active rules) Byty programistyczne (zbudowane z sekwencji instrukcji) umieszczane w bazie danych, których uruchomienie jest powodowane spontanicznie (niezależnie od normalnego przebiegu sterowania programu aplikacyjnego) przez określone zdarzenia zachodzące w bazie danych, np. aktualizację pewnej danej, upłynięcie pewnego czasu, itp. Aktywne reguły często przyjmują postać tzw. reguł ECA (Event-Condition-Action): akcja (action) jest podejmowana przez regułę wtedy, gdy zajdzie określone zdarzenie (event) oraz spełniony będzie określony warunek (condition). Aktywne reguły są często nazywane trygerami (triggers) lub regułami biznesu (business rules). Aktywne reguły są cechą wielu SZBD, w tym relacyjnych, obiektowo-relacyjnych i obiektowych. Istnieją również specjalne systemy zorientowane na tego typu reguły.

aktywność (activity) Proces posiadający zauważalny czas trwania; sekwencja akcji. Synonimy: działanie, proces, funkcja.

aktywny agent (active agent) Inaczej aktywny obiekt. W ostatnim czasie istotna stała się własność przemieszczania się aktywnych agentów w sieci, m.in. w sieci Internet. Temat aktywnych agentów nawiązuje do mobilnego kodu (apletów) języka Java; terminami pojawiającymi się w związku z aktywnymi agentami są: aglet, mobilny agent (mobile agent), mobilny przepływ prac (mobile workflow), aktywny obiekt.

aktywny obiekt (active object) Obiekt posiadający własny program o sterowaniu inicjowanym i biegnącym niezależnie i równolegle w stosunku do przebiegu innych programów/procesów. Synonimy: aktor, agent, aktywny agent.

aktywny SZBD (active DBMS) SZBD specjalnie przystosowany do rejestrowania zdarzeń i spontanicznej reakcji na zdarzenia zachodzące w środowisku bazy danych lub w środowisku zewnętrznym, np. aktualizację danych lub zdarzenia zegarowe. W szczególności, paradygmatem aktywnych SZBD są reguły zdarzenie-warunek-akcja (event-condition-action, ECA). Często tym terminem określa się także konwencjonalny SZBD umożliwiający przechowywanie aktywnych reguł w bazie danych.

alfa (alpha) Popularne określenie okresu testowania produktów programistycznych przed oficjalnym wypuszczeniem ich na rynek. Produkty takie zawierają często dużo błędów i są dostarczane dla wybranych użytkowników, którzy życzą sobie wcześniejszego przetestowania produktu. Po okresie alfa zwykle następuje okres beta. Stosowane są także terminy: testowanie alfa (alpha testing) oraz wersja alfa (alpha version).

algebra obiektowa (object algebra) Z założenia, matematyczna podstawa semantyki obiektowych języków zapytań wzorująca się na algebrze relacji. Obiektowa algebra wprowadza operatory takie jak: złączenie, selekcja, projekcja, grupowanie, zagnieżdżanie (nesting), rozgnieżdżanie (unnesting) i inne. W odróżnieniu od algebry relacyjnej operatory te działają na zbiorach obiektów i zwracają zbiory obiektów. Powodem prac nad obiektowymi algebrami jest potrzeba takiego sformalizowania modelu obiektowego i semantyki języków zapytań, aby można było przeprowadzać dowody poprawności technik optymalizacji zapytań. Niestety, cel ten nie został jak dotąd osiągnięty. Z reguły, algebry te są niespójne koncepcyjnie, dość skomplikowane, niedostatecznie uniwersalne i mające luźne związki z rygorystyczną matematyką (przez co jakikolwiek „dowód” jest niewiarygodny). Obiektowe algebry są w gruncie rzeczy słabo sformalizowanymi językami (udekorowanymi symbolami i pojęciami matematycznymi), uważanymi przez ich autorów (bezpodstawnie) za dobrze przystosowane do wewnętrznego przetwarzania zapytań w obiektowej bazie danych, zgodnie z odwzorowaniami: zapytaniewyrażenie algebraicznezoptymalizowane wyrażenie algebraicznekod ewaluacji zapytania. Liczne prace na temat obiektowych algebr rażą matematyczną niekompetencją i wadami koncepcyjnymi. Np. w algebrze AQUA kwantyfikatory są operatorami algebraicznymi, co jest niezgodne z aktualną wiedzą matematyczną, zaś w innych pracach do operatorów algebry obiektowej zaliczono także operacje aktualizacji, tworzenia i usuwania danych, co jest koncepcyjnym nieporozumieniem. Powszechne jest splątanie w tych algebrach poziomu języka i metajęzyka, np. operator złączenia jest indeksowany wyrażeniem tej samej algebry. Jest prawdopodobne, że nie istnieje koncepcja algebry w stylu algebry relacji, która byłaby adekwatną, uniwersalną i precyzyjną podstawą semantyczną obiektowych języków zapytań. Twierdzenia autorów tych algebr, że przy ich pomocy można opanować semantykę takich języków jako OQL (lub wręcz, że został zbudowany odpowiedni procesor przekształcający dowolne zapytania OQL na wyrażenia algebry obiektowej) są kłamstwami. Temat jest przedmiotem licznych prac akademickich bardzo niskich lotów, będących manifestacją pędu do naukowych karier, braku kompetencji, ograniczeń twórczych, oraz zwyczajnej blagi.

algebra relacyjna (relational algebra) Koncepcja języka wyszukiwania w relacyjnej bazie danych jako zbioru wyrażeń algebraicznych, które tworzą z (zapamiętanych) relacji nowe relacje poprzez zastosowanie operatorów algebraicznych określanych jako selekcja (selection), projekcja (projection), złączenie (join), suma zbiorów (union) i innych. Algebra relacji stała się podstawowym paradygmatem modelu relacyjnego; uważa się ją za osiągnięcie tego kierunku naukowego i źródło jego sukcesów. Te opinie są jednak nieco fałszywym stereotypem wobec faktu, że algebra relacji nie jest w stanie wyrazić wielu podstawowych operacji wyszukiwania (np. wielu konstrukcji języka SQL), nie jest przystosowana do opisu operacji aktualizacyjnych, oraz nie jest w pełni adekwatna w stosunku do struktur danych i przetwarzania zrealizowanego w systemach relacyjnych (patrz np. duplikaty krotek, wartości zerowe (null values), grupowanie (operator group by), uporządkowanie (operator order by), funkcje zagregowane (aggregate functions), operatory arytmetyczne i inne). W systemach relacyjnych algebra relacji nie odgrywa istotnej roli, chociaż pewne jej operatory, takie jak selekcja, projekcja, iloczyn kartezjański i suma zbiorów są używane do objaśnienia niektórych konstrukcji języków zapytań. Niektórzy autorzy (szczególnie o orientacji teoretycznej) przypisują algebrze relacji zasadniczą rolę w optymalizacji zapytań, poprzez odkrycie praw umożliwiających np. wykonywanie (tańszych) operatorów selekcji i projekcji przed (droższymi) operatorami złączenia i produktu kartezjańskiego. Z kilku powodów tego rodzaju opinie są podważalne: (1) analogiczne prawa zostały zrealizowane (np. w systemie Ingres) na długo przedtem, niż pojawiło się ich algebraiczne „uzasadnienie”; (2) struktury danych przechowywane w systemach relacyjnych (tablice) różnią się semantycznie od struktur przetwarzanych przez algebrę relacyjną (relacji), wobec czego dowolne twierdzenie dotyczące algebry relacji nie musi być prawdziwe dla struktur danych systemów relacyjnych i wymaga istotnej weryfikacji praktycznej; (3) metody optymalizacyjne sugerowane przez algebrę relacji są fragmentem (niekoniecznie najważniejszym) zestawu metod optymalizacyjnych stosowanych w rzeczywistych systemach. Istnieje bardzo wiele prób przeniesienia koncepcji algebry relacji na grunt obiektowości; jak dotąd są one raczej nieudane. Patrz też: algebra obiektowa.

alias (alias) Pseudonim, dodatkowa nazwa obiektu, atrybutu, metody, itd. Termin używany w wielu kontekstach.

aliasowanie (aliasing) Przypisywanie pseudonimu, dodatkowej nazwy dla obiektu, atrybutu, metody, itd.

analiza (analysis) Proces rozpoznawania, wyjaśniania, modelowania, specyfikowania i dokumentowania rzeczywistości lub problemu będącego przedmiotem projektu; ustalanie kontekstu projektu, wymagań użytkowników, wymagań organizacyjnych i innych. Analiza nie zajmuje się zmianą tej rzeczywistości poprzez wprowadzenie tam nowych elementów np. w postaci systemu informatycznego; jej celem jest dokładne rozpoznanie wszystkich tych aspektów danej rzeczywistości, które mogłyby mieć wpływ na postać, organizację lub wynik projektu.

analiza i projektowanie obiektowe (object-oriented analysis and design, OOAD, object analysis and design, OA&D) Pojęcia, techniki i narzędzia służące do analizy problemu będącego przedmiotem planowanego przedsięwzięcia informatycznego, oraz do projektowania aplikacji lub systemu, które bazują na pojęciach obiektowości i wykorzystują obiektową metodykę. Analiza i projektowanie obiektowe jest wspomagane poprzez budowę modeli (zwykle w postaci diagramów graficznych) odwzorowujących klasy obiektów, ich atrybuty, metody, powiązania oraz zachowanie (metody). Często jest to wspomagane poprzez budowę modeli dynamicznych, odwzorowujących przebieg sterowania dla poszczególnych procesów realizowanych w systemie oraz wzajemną interakcję obiektów. Zasadniczymi celami analizy i projektowania obiektowego jest oddzielenie wymagań stawianych dla systemu od projektu tego systemu, oddzielenie projektu tego systemu od jego implementacji oraz utworzenie abstrakcyjnych modeli relewantnych do problemu i nie przekraczających akceptowalnego stopnia złożoności.

analiza obiektowa (object-oriented analysis, OOA) Patrz: obiektowa analiza.

analiza punktów funkcyjnych (function point analysis, FPA) Empiryczna metoda oceny złożoności realizacji projektów informatycznych poprzez tzw. punkty funkcyjne (function points, FP). Polega na wydzieleniu atrybutów produktywności (miar pracy) w projektach informatycznych. Na podstawie szacowanych wartości atrybutów produktywności dla danego projektu ocenia się ilość punktów funkcyjnych jako miarę produktywności zespołu lub złożoności projektu. Atrybutami produktywności projektowanego systemu informatycznego są: wejścia użytkownika (dane, sterowanie), wyjścia użytkownika (wydruki, ekrany, pliki), zbiory danych wewnętrzne, zbiory danych zewnętrzne, zapytania zewnętrzne. Szacunkowe oceny są poddawane korekcji uwzględniającej warunki realizacji systemu informatycznego.

ANSI (American National Standard Institute) Amerykański Narodowy Instytut Standardyzacji.

http://www.ansi.org



ANSI X3H2 Komitet ANSI zajmujący się opracowaniem standardu SQL3.

antropomorfizm (antropomorphism) Przypisywanie obiektom lub klasom cech ludzkich celem analizy ich odpowiedzialności, zachowania się i interakcji. Synonim: personifikacja.

antywzorzec (anti-pattern) Opis powszechnego, wydawałoby się naturalnego podejścia do pewnego problemu, które po pewnym czasie okazuje się błędne lub bardzo nieefektywne.

any Dowolny. Określenie klasy będącej nadklasą wszystkich klas (najbardziej ogólnego przodka). Również określenie typu będącego nadtypem wszystkich typów. W niektórych językach lub systemach stosowane jest inne słowo kluczowe, np. „object”.

API (Application Programming Interface) Interfejs do programowania aplikacji (w postaci biblioteki procedur lub innej formy oprogramowania) umożliwiający dostęp do bazy danych, systemu operacyjnego, interfejsu graficznego, itp. z pewnego języka programowania.

aplet (applet) Mały program w kodzie pośrednim (znakowym) powstały w wyniku kompilacji programu napisanego w Java, który jest przesyłany w sieci Internet wraz ze stroną HTML (jako odrębny plik) i następnie interpretowany poprzez wirtualną maszynę wbudowaną w lokalną przeglądarkę WWW, np. Netscape. Aplety umożliwiają znaczne podwyższenie formy prezentacji i funkcjonalności stron WWW.

aplikacja (application) Oprogramowanie realizujące pewne funkcje użytkowe; oprogramowanie, z którym ma do czynienia użytkownik końcowy.

aplikacja spadkowa (legacy application) Patrz: zastosowanie spadkowe.

AppleScript Obiektowy język skryptowy systemu operacyjnego komputerów Apple Macintosh.

architektura (architecture) Ogólna, ramowa budowa systemu komputerowego lub oprogramowania, określająca składowe, powiązania pomiędzy składowymi, wzajemne interakcje oraz przepływ informacji. Zwykle w literaturze tym terminem określa się kombinację własności strukturalnych (np. fizycznych komponentów) oraz funkcjonalnych (wewnętrznych i zewnętrznych funkcji systemu). Niżej prezentujemy przykładową architekturę obiektowego systemu zarządzania bazą danych.



Architektura OSZBD

architektura ANSI/SPARC (ANSI/SPARC architecture) Trzywarstwowa architektura SZBD zaproponowana przez komitet ANSI/SPARC. Wyróżnia ona poziom pojęciowy systemu, wspólny dla wszystkich jego użytkowników, poziom zewnętrzny, specyficzny dla konkretnego użytkownika oraz poziom fizyczny, odnoszący się do implementacji bazy danych; patrz rysunek poniżej.



Architektura ANSI/SPARC


Pobieranie 6.06 Mb.

Share with your friends:
1   2   3   4   5   6   7   8   9   ...   26




©operacji.org 2020
wyślij wiadomość

    Strona główna