Obiektowość - ipipan.waw.plsubieta/artykuly/slownik_obiektowosci/slownik.doc · Web...

Obiektowość jest stosunkowo nowym zjawiskiem ideologicznym, które jest często wiązane z najbardziej nowoczesnymi koncepcjami i technologiami współczesnej informatyki. Wśród nich można wymienić języki C++, Smalltalk, Java i Eiffel, standardy CORBA, COM, ODMG i SQL3, metodyki analizy i projektowania OMT, OPEN, BON, OOAD i Objectory, notację UML, systemy Oracle-8, Informix Dynamic Server, Orbix, O2, Gemstone, ObjectStore, i wiele, wiele innych tworów. Równie popularne stały się pojęcia charakteryzujące obiektowość, takie jak: obiekt, tożsamość, klasa, typ, metoda, dziedziczenie, hermetyzacja, polimorfizm. Co one oznaczają? Jaki jest ich stosunek do nowoczesnych języków, standardów, systemów, metodyk i technologii?

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 słownika jest z jednej strony uporządkowanie polskiej terminologii z zakresu obiektowości, zaś z drugiej strony wyjaśnienie w lakonicznej, encyklopedycznej formie znaczenia wielu terminów. Słownik jest archipelagiem małych wysepek w oceanie wiedzy, które mogą ułatwić ogólną orientację w temacie, 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. Wyjaśnienia haseł są uzupełnione słownikami-skorowidzami angielsko-polskim i polsko-angielskim.

Słownik jest niezbędną pozycją w bibliotece studenta informatyki, dydaktyka, pracownika naukowego, oraz dowolnego innego specjalisty z zakresu informatyki, któremu zależy na śledzeniu postępu w zakresie nowoczesnych informatycznych technologii.

Słownik terminów z zakresu obiektowości

PROBLEMY WSPÓŁCZESNEJ NAUKITEORIA I ZASTOSOWANIA

INFORMATYKA

Edytor serii: Leonard Bolc

Kazimierz Subieta

Słownik terminówz zakresu obiektowości

Akademicka Oficyna Wydawnicza PLJWarszawa 1999

Copyright by Kazimierz Subieta Warszawa 1999

Adresy autora:

Instytut Podstaw Informatyki PAN ul. Ordona 21,01-237 [email protected]

Polsko-Japońska Wyższa Szkoła Technik Komputerowychul. Koszykowa 86,02-008 Warszawa

Copyright by Akademicka Oficyna Wydawnicza PLJ Warszawa 1999

RecenzentProf. dr hab. Leonard Bolc

RedaktorAnna Bittner

Komputerowy skład tekstuKazimierz Subieta

Projekt graficzny seriiAkademicka Oficyna Wydawnicza PLJ

ISBN 83-7101-407-4

Spis treści

1. WSTĘP.....................................................................................................................1

1.1. GENEZA..............................................................................................................11.2. OBSZARY ODDZIAŁYWANIA OBIEKTOWOŚCI......................................................4

2. SŁOWNIK ENCYKLOPEDYCZNY....................................................................7

3. BIBLIOGRAFIA.................................................................................................233

4. SŁOWNIK-SKOROWIDZ ANGIELSKO-POLSKI.......................................235

5. SŁOWNIK-SKOROWIDZ POLSKO-ANGIELSKI.......................................263

1. Wstęp

1. Wstęp

1.1. GenezaObiektowość 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ą.

1

1. Wstęp

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

2

1. Wstęp

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ść

3

1. Wstęp

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: [email protected]

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

4

1. Wstęp

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.

5

1. Wstęp6

2.Słownik encyklopedyczny

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

AA

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.

7


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/

8


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

9


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

10


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.

11


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

12


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: zapytanie wyrażenie algebraiczne zoptymalizowane wyrażenie algebraiczne kod 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

13


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

14


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.

15


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.

Preprocesor

Kompilator

Źródłowy tekstprogramu

Moduły w formaciedo konsolidacji

Konsolidator

Biblioteka klas,moduły run-timejęzyka program.

Biblioteka klas,moduły run-time

OSZBD

Wykonywalnyprogram

Przetwarzanietransakcji, prow.dziennika,odwracanie,odtwarzanie,autoryzacja,bezpieczeństwo

DanePerspektywyReguły

Optymalizacja iwykonanie

zapytań

Zbiory bazy danych

Indeksy Katalogi

Środowisko 4GL/RAD

Źródłowy program w 4GL/RAD

Procesorinterakcyjnych

zapytań

Udogodnienia

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.

16


Schemat zewnętrzny 1



Schemat pojęciowy

Poziom fizycznybazy danych

Użytkownik Użytkownik Użytkownik

Administrator BD

Projektant BDProjektant aplikacji

Architektura ANSI/SPARC

architektura klient-serwer (client-server architecture) Architektura sprzętu lub oprogramowania, w której występuje podział na część zlecającą pewne usługi (czyli klienta) oraz część wykonującą te usługi (czyli serwer).

architektura komponentowa (component architecture) Pojęcie w programowaniu obiektowym. W architekturze komponentowej program jest zestawem generycznych komponentów o dobrze zdefiniowanym interfejsie i zachowaniu. Komponenty są łączone przy pomocy oprogramowania pośredniczącego. Przykładami architektury komponentowej są: COM/DCOM, JavaBeans, oraz pakiety ORB wg standardu CORBA.

architektura trzywarstwowa (three-tier architecture, three-tiered architecture) Architektura klient-serwer, która jest podzielona na trzy warstwy: interfejs użytkownika, logikę przetwarzania (reguły biznesu, logikę biznesu) oraz bazę danych. Warstwy te są zaprojektowane i istnieją niezależnie, co ma duże znaczenie dla pielęgnacyjności całego systemu ze względu na możliwość zmian w dowolnej warstwie bez konieczności interwencji w pozostałych warstwach. Często warstwy są zrealizowane na odrębnych platformach: interfejs na MS Windows, logika przetwarzania na serwerze aplikacji i baza danych na serwerze bazy danych. Środkowa warstwa może składać się z wielu warstw, co jest określane jako „architektura wielowarstwowa”.

architektura wielowarstwowa (multi-tiered architecture) Architektura klient-serwer składająca się z wielu warstw z dobrze zdefiniowanym interfejsem pomiędzy warstwami. Patrz też: architektura trzywarstwowa.

17


argument (argument) Inaczej parametr (formalny lub aktualny) metody, funkcji procedury, wyjątku, itd.

argument aktualny (actual argument) Patrz: parametr aktualny.

argument formalny (formal argument) Patrz: parametr formalny.

Ariane 5 Rakieta kosmiczna będąca efektem europejskiego programu badań kosmicznych (European Space Agency), która 4 czerwca 1996 roku eksplodowała 40 sekund po starcie, przynosząc bezpośrednią stratę 500 mln. dolarów, pośrednie straty szacowane na 2 do 6 mld. dolarów, oraz załamanie się europejskiego programu badań kosmicznych. Przyczyną katastrofy był błąd w oprogramowaniu - najbardziej spektakularny błąd programistyczny, w sensie strat materialnych. Bezpośrednią przyczyną było nie przechwycenie wyjątku przy konwersji liczby 64 bitowej na 16 bitową, co zawiesiło oprogramowanie. Pośrednią przyczyną było przeniesienie fragmentu oprogramowania z poprzedniej wersji Ariane 4. Bertrand Meyer i jego współpracownicy uważają, że przyczyną błędu było niewłaściwe ponowne użycie (reuse) wytworzonych komponentów oprogramowania. Przypadek Ariane 5 uważają za jeden z argumentów za metodyką projektowania poprzez kontrakty (Design By Contracts), która nie dopuściłaby do powstania tego błędu.

http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.htmlhttp://www.esrin.esa.it/htdocs/Press/Press96/ariane5rep.html

asercja (assertion) Warunek wstawiony do programu określający dopuszczalny stan przetwarzania, np. X - Y > 10. Asercja zwykle wiąże wartości jednej lub więcej zmiennych. Nie spełnienie asercji podczas wykonania powoduje sygnalizację błędu.

asocjacja (association) Związek pomiędzy klasami obiektów (np. pokazany niżej związek Zatrudnia między firmami i osobami). Asocjacja może łączyć dwie lub więcej klas (niekoniecznie różnych). Zwykle uważa się, że asocjacja umożliwia przechodzenie (nawigację) pomiędzy powiązanymi nią obiektami w dowolnym kierunku. M.in. z tego powodu asocjacja niekoniecznie musi być utożsamiana z powiązaniami wskaźnikowymi; uważa się, że to pojęcie występuje na wyższym poziomie abstrakcji, zaś wskaźniki mają status techniki implementacyjnej. Praktycznie jednak wskaźnikowa interpretacja asocjacji (binarnych) jest dostatecznie precyzyjna i nie prowadzi do trudności koncepcyjnych lub utraty ogólności.

Firma OsobaZatrudnia

Asocjacja Zatrudnia łącząca klasę Firma i klasę Osoba

Semantyką asocjacji jest pewna liczba „nitek” (powiązań) łączących obiekty będące wystąpieniami klas połączonych przez asocjację. Przykładowo, poniżej znajduje się pewien stan wystąpień klas Firma i Osoba oraz konkretne powiązania Zatrudnia łączące konkretne osoby z konkretnymi firmami: Madzia i Kasia pracują w Globi, Jasio ma posadę w Auchan, Gucio zaczepił się w Społem, gdzie dorabia także Kasia. Wskaźnikowa interpretacja tych „nitek” oznacza, że każda z nich jest implementowana

18


jako dwa wskaźniki: np. od obiektu Madzia prowadzi wskaźnik do obiektu Globi, oraz od obiektu Globi prowadzi wskaźnik do obiektu Madzia. Niekiedy (np. w UML) asocjacja jest zorientowana i zaznaczona strzałką. W takim przypadku definiuje ona wskaźniki prowadzące w jednym kierunku, zgodnie z zaznaczoną strzałką.

OSOBAMadzia

OSOBAJasio

OSOBAKasia

OSOBAGucio

FIRMAGlobi

FIRMAAuchan

FIRMASpołem

Zatrudnia

Zatrudnia

Zatrudnia

Zatrudnia

Zatrudnia

Przykładowa realizacja asocjacji Zatrudnia

Dość częstym błędem popełnianym przez początkujących jest plątanie asocjacji z akcją. W danym przypadku Zatrudnia nie oznacza jakiejkolwiek czynności zatrudniania osoby przez firmę. Asocjacja ta oznacza wyłącznie statyczne połączenie obiektów klas Firma i Osoba. Akcje, które doprowadziły do tego połączenia, nie są odwzorowywane przez asocjację. Są one opisywane przez metody, procedury lub inne byty odwzorowujące zachowanie się obiektów.

asocjacja binarna (binary association) Asocjacja łącząca dwie klasy.

asocjacja dwukierunkowa (bidirectional association) Asocjacja umożliwiająca przechodzenie (nawigację) od obiektów jednej klasy do obiektów drugiej klasy, i odwrotnie.

asocjacja jednokierunkowa (unidirectional association) Asocjacja umożliwiająca przechodzenie (nawigację) od obiektów jednej klasy do obiektów drugiej klasy, ale nie odwrotnie.

asocjacja kwalifikowana (qualified association) W OMT i UML asocjację można dodatkowo określić atrybutem asocjacji (lub zestawem atrybutów asocjacji), którego wartości służą do podziału zbioru obiektów definiowanych przez klasę znajdującą się na jednym z końców tej asocjacji. Ilustruje to rysunek poniżej. Kwalifikator (atrybut asocjacji) jest umieszczony wewnątrz mniejszego prostokąta dostawionego do oznaczenia klasy. Obiekt klasy, do której jest dostawiony kwalifikator, plus wartość kwalifikatora wyznaczają w sposób unikalny obiekt klasy znajdującej się na drugim końcu asocjacji (ogólnie, wyznaczają w sposób unikalny pewien zbiór obiektów). Przykładowo, na podanym rysunku Zamówienie+produkt określają konkretny wiersz zamówienia. Ta zależność ma konsekwencje w oznaczeniach liczności, np. każda para

19


Zamówienie+produkt jest związana z co najwyżej jednym obiektem WierszZamówienia.

produktZamówienieWierszZamówienia

ilość: Liczba0..1pozycja zamów

Przykład asocjacji kwalifikowanej


asocjacja n-arna (n-ary association) Asocjacja, w której uczestniczy n klas (niekoniecznie różnych); zwykle n jest większe od 2.

asocjacja pochodna (derived association) Asocjacja, którą można wyznaczyć z innych asocjacji. Np. asocjację JestSzefem pomiędzy obiektami klasy Pracownik można wyznaczyć na podstawie asocjacji Zatrudnia pomiędzy klasami Firma i Pracownik oraz asocjacji DyrektorFirmy pomiędzy klasami Firma i Pracownik; patrz rysunek.

Firma Pracownik

Zatrudnia

DyrektorFirmy

* JestSzefem

*

asocjacjapochodna

0..1

Przykład asocjacji pochodnej

asocjacja ternarna (ternary association) Asocjacja pomiędzy trzema klasami (niekoniecznie różnymi); patrz rysunek poniżej.

Towar

sprzedażkupuje sprzedaje

jest sprzedawany

SprzedawcaKlient

Przykład asocjacji ternarnej

asynchroniczność (asynchronicity) Równoległe działanie, współbieżność, brak centralnej koordynacji wielu procesów.

asynchroniczny (asynchronous) Określenie paradygmatu programowania, przy którym występuje równoległe (współbieżne) działanie metod, procedur lub innych abstrakcji proceduralnych. Asynchroniczność wymaga określenia metod synchronizacji równoległych procesów oraz podziału tzw. krytycznych zasobów. (Np. wiele implementacji Smalltalka wprowadza w tym celu semafory.) Dość często termin „przesyłanie komunikatów” jest mylnie kojarzony z asynchronicznością; w istocie jest ona w stosunku do obiektowości własnością ortogonalną.

20


atomowość (atomicity) Jedna z własności transakcji oznaczająca, że wykonują się albo wszystkie operacje wchodzące w jej skład, albo żadna.

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

atomowy (atomic) Określenie wartości, obiektu, atrybutu itd., którego nie można zdekomponować na mniejsze elementy.

atrybut (attribute) Termin występuje w kilku dość bliskich znaczeniach: Nazwana własność lub wartość przypisana do obiektu, np. Nazwisko(„Kowalski”)

dla obiektu Pracownik. Obiekt będący składową innego obiektu; taki obiekt-atrybut jest zwykle

wystąpieniem swojej własnej klasy. Nazwa przypisana do pewnej wartości przechowywanej w ramach obiektu, np.

nazwa Nazwisko. Wyrażenie składające się z nazwy i typu wartości przechowywanych wewnątrz

pewnej grupy obiektów; takie wyrażenie jest częścią definicji klasy (typu) obiektów, np. Nazwisko: string.

Wartości atrybutów obiektu składają się na jego stan. Synonimy: pole, członek klasy, zmienna wystąpienia.

atrybut asocjacji (association attrribute) Atrybut charakteryzujący asocjację pomiędzy obiektami. Np. asocjacja Wypożyczył pomiędzy obiektami klasy Czytelnik i klasy Książka może mieć atrybut asocjacji DataWypożyczenia.

atrybut atomowy (atomic attribute) Patrz: atrybut prosty.

atrybut domyślny (default attribute) Predefiniowana wartość atrybutu podstawiana w momencie tworzenia nowego obiektu (np. ciąg 30 spacji dla atrybutu Nazwisko). Atrybut domyślny wiąże się także z atrybutem opcyjnym i oznacza wartość, która jest przyjmowana domyślnie, o ile wartością atrybutu jest NULL.

atrybut dzielony (shared attribute) Patrz: atrybut klasy.

atrybut klasy (class attribute) Atrybut przechowywany wewnątrz definicji klasy (lub wewnątrz obiektu reprezentującego klasę), którego nazwa i wartość jest wspólna (jednakowa) dla wszystkich wystąpień tej klasy. Przykładem atrybutu wspólnego dla typowych obiektów klasy SSAK jest LiczbaOczu z wartością 2.

atrybut kompozytowy (composite attribute) Atrybut składający się z dwóch lub więcej wartości; atrybut składający się z podatrybutów, atrybut złożony.

atrybut masowy (bulk attribute) Patrz: atrybut powtarzalny.

atrybut multimedialny (multimedia attribute) Atrybut przechowujący długą

21


wartość (w szczególności rzędu megabajtów) stosowaną przy przechowywaniu danych multimedialnych (pliki edytorów tekstowych, grafika, dźwięk, wideo). Wiele systemów obiektowych ma możliwość deklarowania atrybutów multimedialnych.

atrybut opcyjny (optional attribute) Atrybut, którego wartość może być pusta (niezapełniona, NULL), lub który może być nieobecny w konkretnym wystąpieniu obiektu; np. atrybut NazwiskoPanieńskie dla obiektów Osoba (który jest nierelewantny dla osób płci męskiej). Opcyjność może dotyczyć dowolnego rodzaju atrybutu, np. atrybutu prostego, złożonego, lub wskaźnikowego. Większość metodyk i notacji obiektowych nie posiada specjalnych oznaczeń dla atrybutów powtarzalnych, co należy uznać za wadę ze względu na znaczenie faktu opcyjności atrybutu w modelowaniu pojęciowym. W SQL atrybut opcyjny zaznacza się frazą NULL IS ALLOWED.

atrybut pochodny (derived attribute) Atrybut, którego wartość jest obliczana np. z wartości innych atrybutów. Przykładowo, jeżeli obiekt OSOBA zawiera atrybut RokUrodzenia, to atrybut Wiek jest atrybutem pochodnym, ponieważ jego wartość jest obliczana poprzez odjęcie wartości atrybutu RokUrodzenia od aktualnego roku. Koncepcyjnie, atrybut pochodny jest równoważny bezparametrowej metodzie funkcyjnej.

atrybut powiązania (link attribute) Patrz: atrybut asocjacji.

atrybut powtarzalny (repeating attribute) Atrybut, którego wartość może się powtarzać określoną lub nieokreśloną liczbę razy. Przykładem powtarzalnego atrybutu prostego może być lista wyuczonych specjalności dla pracownika, np. {”tokarz”, ”ślusarz”, ”frezer”, ”spawacz”}. Przykładem powtarzalnego atrybutu złożonego dla pracownika może być lista zwolnień chorobowych, np.:

{ {Od: 95.02.11; Do: 95.02.18; Przyczyna: ”Grypa”}, {Od: 95.05.17; Do: 95.06.10; Przyczyna: ”Uraz” } }

Przykładem powtarzalnego atrybutu wskaźnikowego może być atrybut Zatrudnia obiektów klasy DZIAŁ, zawierający identyfikatory obiektów wszystkich pracowników pracujących w danym dziale. Powtarzalne mogą być także podatrybuty, pod-podatrybuty, itd. W systemach typowanych atrybut powtarzalny jest definiowany przez typ masowy, np. zbiór, wielozbiór lub sekwencję. Większość metodyk i notacji obiektowych nie posiada specjalnych oznaczeń dla atrybutów powtarzalnych, co należy uznać za dość poważną wadę (szczególnie istotną przy ewentualnym odwzorowaniu modelu obiektowego na schemat relacyjny i w modelowaniu pojęciowym). Synonim: atrybut masowy.

atrybut prosty (simple attribute, atomic attribute) Np. atrybut NAZWISKO dla obiektu PRACOWNIK. Atrybut prosty przechowuje dokładnie jedną wartość, która z punktu widzenia użytkownika jest niepodzielna (atomowa); np. ”Kowalski”.

atrybut referencyjny (pointer attribute) Patrz: atrybut wskaźnikowy.

atrybut statyczny (static attribute) Patrz: atrybut klasy.

22


atrybut wewnętrzny (internal attribute) Atrybut obiektu dostępny wyłącznie dla metod zdefiniowanych wewnątrz jego klasy.

atrybut wielowartościowy (multi-valued attribute) Patrz: atrybut powtarzalny.

atrybut wirtualny (virtual attribute) Patrz: atrybut pochodny.

atrybut wskaźnikowy (pointer attribute) Atrybut, którego wartością jest wskaźnik (pointer) prowadzący zwykle do pewnego obiektu; inaczej atrybut referencyjny.

atrybut wyjątku (exception attribute) Atrybut charakteryzujący wyjątek. W wielu koncepcjach wyjątek jest także obiektem i może posiadać atrybuty. Np. wyjątek BrakReakcjiUżytkownika może mieć atrybut CzasOczekiwaniaNaReakcję.

atrybut wyliczalny (derived attribute) Patrz: atrybut pochodny.

atrybut wystąpienia (instance attribute) Atrybut wraz z wartością będący składową obiektu - wystąpienia danej klasy.

atrybut zdarzenia (event attribute) Atrybut charakteryzujący zdarzenie. W wielu koncepcjach zdarzenie jest także obiektem i może posiadać atrybuty. Np. zdarzenie AktualizacjaZarobku może mieć atrybuty KtoAktualizował, AktualizowanyObiekt, StaraWartość, NowaWartość.

atrybut zewnętrzny (external attribute) Atrybut dostępny publicznie.

atrybut złożony (complex attribute, composite attribute) Atrybut, którego wartość nie jest atomowa i składa się z podatrybutów, np. atrybut Data składa się z podatrybutów Rok, Miesiąc, Dzień. Atrybut złożony może być utożsamiony z podobiektem; jego wartość jest wówczas wystąpieniem pewnej klasy.

audyt (audit) Systematyczne badanie danego produktu, przeprowadzone przez organ niezależny od wytwórcy tego produktu. Badanie ma na celu określenie, czy działania dotyczące jakości i ich wyniki odpowiadają zaplanowanym ustaleniom, czy te ustalenia są skutecznie realizowane i czy pozwalają na osiągnięcie odpowiedniego poziomu jakości produktu.

autoryzacja (authorization) Mechanizm lub czynność przypisania użytkownikom praw dostępu do poszczególnych danych, obiektów, usług lub funkcji systemu.

BB

Bancilhon, Francois Prekursor i propagator obiektowych baz danych, główny twórca systemu O2, inicjator i propagator standardu ODMG.

http://www.o2tech.fr/

23


banda czworga (gang of four, GOF) Patrz: GOF. Niekiedy terminem tym (i akronimem G4) określa się także porozumienie czterech firm komputerowych, Netscape, Oracle, IBM i Sun, w zakresie rozwijania technologii komponentowych opartych o standard CORBA i protokół IIOP.

Barry, Douglas K. Jeden z założycieli i aktywny członek komitetu ODMG, właściciel firmy konsultingowej Barry & Associates.

http://www.odbmsfacts.com/

baza danych (data base) Zestaw danych, metadanych (katalogów), programów i innych środków pozwalających na utrzymywanie, zabezpieczanie, przetwarzanie i udostępnianie danych dla użytkowników. Bazy danych są podtrzymywane przez systemy zarządzania bazą danych (SZBD). Mogą one być oparte o pewien model danych (np. hierarchiczny, sieciowy, relacyjny, funkcjonalny, obiektowy) lub mogą stosować rozwiązanie własne, nie mieszczące się w ramach zdefiniowanych modeli. Często bazą danych określa się także pewien system plików, pewien zestaw stron WWW, repozytorium dokumentów (np. pod LotusNotes) oraz inne środki przechowywania i udostępniania danych.

baza obiektów (object base) Baza danych zawierająca obiekty.

baza wiedzy (knowledge base) Repozytorium informacyjne (wraz ze środkami przechowywania, utrzymywania i udostępniania), które oprócz danych statycznych przechowuje także reguły logiczne, reguły aktywne, grafy wiedzy, sieci semantyczne, ograniczenia, perspektywy, zapamiętane procedury, itp. Podział na bazy wiedzy i bazy danych nie jest precyzyjny, gdyż współczesne bazy danych posiadają również niektóre z w/w własności. Patrz też: system zarządzania bazą wiedzy.

bazujący na obiektach (object-based) Określenie modelu, języka lub systemu, który wprowadza byt programistyczny o cechach zbliżonych do obiektu, ale który jest pozbawiony istotnych cech obiektowości, takich jak klasy i dziedziczenie. Pojęcie „bazujący na obiektach” jest bardzo słabym wyróżnikiem stopnia „obiektowości” systemu lub języka, gdyż praktycznie w każdym z nich można wyróżnić pewien byt programistyczny, który można nazwać „obiektem”. Np. „obiektem” można nazwać krotkę relacji i w ten sposób każdy system relacyjny będzie „bazujący na obiektach”. Termin ten funkcjonuje więc jako określenie reklamowe lub dekoracyjne, pozbawione jednoznacznej semantyki. Niekiedy (np. w języku CLU) termin ten jest przypisywany do języka posiadającego abstrakcyjne typy danych. W innych opracowaniach termin ten oznacza, że dany język lub system operuje danymi (zmiennymi) posiadającymi wewnętrzny unikalny identyfikator (co jest ważnym, ale nie wystarczającym wyróżnikiem obiektowości).

bazujący na wartościach (value-based) Określenie modelu danych, w którym nie występuje pojęcie stanu, identyfikatora obiektu (identyfikatora krotki) oraz referencji do obiektu (do atrybutu, do krotki, itd.). Przykładem modelu bazującego na wartościach jest model relacyjny; również model funkcjonalny oraz modele oparte na logice matematycznej, np. F-logika lub Datalog. Modele bazujące na wartościach są często

24


proponowane w ramach nurtu teoretycznego. Ich podstawową wadą, która czyni je praktycznie nieprzydatnymi dla modelowania realnych systemów, jest brak możliwości uwzględnienia operacji aktualizacyjnych (lub konieczność istotnych „poprawek” modelu, które z reguły podważają aparat matematyczny będący ich podstawą). Poza modelem relacyjnym (który w systemach relacyjnych został istotnie „poprawiony”), modele bazujące na wartościach nie uzyskały większego znaczenia w praktyce (mimo nacisku teoretyków; patrz np. bardzo kategoryczne wypowiedzi J. Ullmana). Przykładem systemu bazującego na wartościach jest LDL zrealizowany w MCC w Austin, Texas.

BCNF (Boyce-Codd Normal Form) Patrz: postać normalna Boyce-Codda.

B-drzewo (B-tree) Zbalansowane (zrównoważone, wyważone) drzewo. Struktura organizacji fizycznych zbiorów danych oparta o koncepcję drzewa, w którym nie występują duże różnice pomiędzy wielkością gałęzi wychodzących z tego samego pnia. Liczba takich gałęzi jest parametrem drzewa; zwykle jest ona większa od dwóch. B-drzewa zyskały sobie uznanie jako jedna z najlepszych metod organizacji indeksów. Niektórzy autorzy pod terminem B-drzewo rozumieją omyłkowo drzewo binarne, tj. drzewo, w którym każdy węzeł ma co najwyżej dwie gałęzie.

behawior (behaviour, behavior) Patrz: zachowanie.

benczmark (benchmark) Patrz: sprawdzian.

BETA Obiektowy język programowania i środowisko programistyczne firmy Mjolner Informatics, Aarhus, Dania. BETA posiada strukturę blokową, korutyny, współbieżność, mocną kontrolę typów i obiekty nie należące do żadnej klasy. Cechą centralną jest mechanizm abstrakcji zwany „wzorcem” (pattern), który jest generalizacją pojęcia klasy zapewniającą tworzenie wystąpień i hierarchię klas dla wszystkich obiektów, włączając w to procedury i procesy. BETA jest reklamowany jako jednorodny system integrujący fazy analizy, projektowania, definicji danych, budowy prototypu i kodowania. Wyposażony jest w narzędzie CASE umożliwiające bezpośrednią generację programów w BETA.

http://www.daimi.aau.dk/~beta/http://www.mjolner.dkhttp://www.daimi.aau.dk/~beta/FAQ/beta-language-faq.html

beta Popularne określenie próbnej, nie do końca sprawdzonej wersji nowego systemu lub oprogramowania, która jest przekazywana do próbnej eksploatacji wybranym użytkownikom. Faza beta następuje zwykle po fazie alfa. Funkcjonują także terminy „testowanie beta” (beta testing) oraz „wersja beta” (beta version).

bezpieczeństwo (safety) Stopień, w jakim oprogramowanie nie zagraża ludziom lub ich własności, niezależnie od tego w jaki sposób i przez kogo jest użyte. Bezpieczeństwo oznacza przede wszystkim odporność na awarie i nienormalną pracę systemu wynikającą z jego (nieuniknionej) zawodności i niemożliwości usunięcia wszystkich błędów. (Porównaj z ochroną, security).

25


bezpieczeństwo typologiczne (type safety) Automatyczne wykrywanie błędów typologicznych przy pomocy mechanizmu mocnej kontroli typów.

bezpośredni przodek (direct ancestor) W hierarchii klas bezpośrednia nadklasa w stosunku do danej klasy.

bezszwowa integracja (seamless integration) Integracja języka zapytań z językiem programowania oparta o wspólny system typów, reguły zakresu, przestrzeń nazw, składnię, semantykę, itd.; przeciwieństwo niezgodności impedancji. Patrz też: bezszwowy.

bezszwowy (seamless) Termin używany zwykle do określenia takiego zintegrowania języka zapytań z językiem programowania, które jest całkowicie jednorodne z punktu widzenia składni, semantyki, struktur danych, faz wiązania, reguł zakresu, itd. Uważa się, że powiązanie SQL z językami programowania nie kwalifikuje się do tego określenia. W większym stopniu określenie to jest właściwe dla powiązania np. OQL z C++ wg standardu ODMG, chociaż i w tym przypadku całkowicie bezszwowa integracja nie ma miejsca (chociażby ze względu na różnice w składni).

Czasami terminu „bezszwowy” (bezszwowe) używa się w kontekście przechodzenia pomiędzy poszczególnymi fazami projektu (analizą, projektowaniem, konstrukcją), które nie wymaga znacznych zabiegów niezbędnych do wykorzystania rezultatów poprzedniej fazy. Uważa się niekiedy, że metodyki obiektowe zapewniają tego rodzaju bezszwowe przejścia, w odróżnieniu od poprzednich metodyk strukturalnych.

biała skrzynka (white box) Termin związany z ponownym użyciem (reuse), oznaczający taki aktyw ponownego użycia, który należy używać bez zmian, ale z koniecznością rozpoznania wewnętrznej zawartości. Przykładem ponownego użycia na zasadzie białej skrzynki jest tworzenie klas wyspecjalizowanych bazujące na wykorzystaniu nadklas, których zawartość jest znana i nie może być zmieniona. Synonim: szklana skrzynka (glass box).

biblioteka klas (class library) Zestaw specyfikacji i implementacji klas, stanowiący aktyw ponownego użycia i/lub jednostkę w obrocie handlowym.

bigot (bigot) Osoba fanatycznie przywiązana do swojego ulubionego języka programowania, systemu, modelu, lub koncepcji teoretycznej, np. C++, SQL, modelu relacyjnego, programowania w logice, lub polimorficznego systemu typów. Bigot jest odporny na wszelką krytykę przedmiotu swojej adoracji, zbywając ją odpowiedziami typu: to jest nieistotne, to nie ma znaczenia w praktyce, to będzie w następnej wersji, to można łatwo obejść, itd. Miłość bigota często nie ustaje nawet w sytuacji, gdy przedmiot jego adoracji utonął w zakurzonej makulaturze. Do bigota na ogół nie trafiają argumenty, że wszystko można obejść w assemblerze, zaś brak autostrad można obejść przez sieć dobrze wydeptanych ścieżek.

bizantyjski (byzantine) Pejoratywne określenie projektu, programu, diagramu, itd., który ma tak wiele wewnętrznych połączeń, że niemożliwe jest zrozumienie jego wewnętrznej logiki, budowy, składowych, itd. Patrz też: spaghetti.

26


Black Widow Pakiet ORB integrujący obiekty CORBA z WWW firmy PostModern Computing; obecnie znany pod nową nazwą VisiBroker firmy Borland/Visigenic.

BLOB (Binary Large OBject) Duży obiekt binarny - struktura danych implementowana w systemach relacyjnych (zwykle ad hoc, bez troski o koncepcyjną i językową spójność) dla potrzeb danych multimedialnych (teksty, grafika, dźwięk, itd.). BLOB jest zwykle wartością atomową (niepodzielną) o znacznej długości (od kilkudziesięciu kilobajtów do kilkudziesięciu megabajtów), przechowywaną poza strukturą relacyjną i przetwarzaną przez odpowiedni zestaw procedur.

blokada (deadlock) Patrz: zakleszczenie.

Blue Obiektowy język programowania nawiązujący do C++, przeznaczony dla celów dydaktycznych.

http://www.cs.su.oz.au/~mik/blue/blue.html

BOA (Basic Object Adapter) W terminologii OMG CORBA, podstawowy, standardowy adapter dokonujący zmiany interfejsu implementacyjnego obiektu (np. w C++) na interfejs bardziej abstrakcyjny, oczekiwany przez klienta pośrednika (ORB).

http://www.omg.org

BOF (Business Object Framework) Określenie inicjatywy OMG zmierzającej do opracowania standardu „obiektu biznesowego”, którego intencją jest ukrycie przed programistami detali infrastruktury związanej z systemem opartym o standard CORBA i pozostawienie wyłącznie tych elementów, które są istotne dla logiki biznesu.

http://www.omg.org

bogaty klient (rich klient) Patrz: mocny klient.

BOM (Bill-Of-Material) Rachunek materiałów. Określenie problemu przetwarzania danych, w którym przetwarzana struktura ma postać rekurencyjną, np. lista części, które składają się z podczęści, pod-podczęści, itd. Terminem tym niekiedy określa się inne tego rodzaju zagadnienia, np. drzewo genealogiczne, strukturę połączeń komunikacyjnych, itd. Problem ma dwa aspekty: reprezentacji takich struktur, np. w relacyjnej lub obiektowej bazie danych, oraz środków przetwarzania, np. rekurencyjnych procedur, różnych metod określanych mianem „tranzytywne domknięcie” (transitive closure), itd.

BON (Business Object Notation) Obiektowa metodyka analizy i projektowania systemów informatycznych oraz notacja graficzna zaproponowana przez Nersona, Meyera i Wadena. BON jest wiązany z językiem Eiffel, chociaż nie jest ograniczony do tego języka. Podstawowymi zasadami BON są: bezszwowa integracja i użycie jednego spójnego systemu pojęć na wszystkich

etapach projektu; odwracalność, oznaczająca, że dowolna zmiana poczyniona na dalszym etapie

projektu może być odwzorowana do tyłu (do poprzednich etapów projektu); kontrakty w ramach oprogramowania (software contracting). Budowa

27


oprogramowania jest poprzedzana ustalaniem precyzyjnych kontraktów pomiędzy jego modułami, dla zapewnienia niezawodności i spójności.

Patrz też: projektowanie przez kontrakty.http://www.eiffel.com/products/bon.htmlhttp://ftoomsh.progsoc.uts.edu.au/~geldridg/frsd2/b-bon1.htm

Booch Obiektowa metodyka analizy i projektowania systemów informatycznych. Patrz: OODA.

http://www.itr.ch/tt/case/BoochReferenzhttp://www.itr.ch/courses/case/BoochReference/

Booch, Grady Twórca metodyki obiektowej OODA określanej również jego nazwiskiem; także jeden z twórców notacji Unified Modeling Language, UML.

http://www.rational.com/

BPM (Business Process Modeling) Modelowanie procesów biznesowych.

BPR (Business Process Reengineering) Patrz: reinżynieria procesów biznesowych.

brudna strona (dirty page) Określenie strony dyskowej zaktualizowanej przez pewną transakcję, która nie została jeszcze potwierdzona. Patrz: brudny obiekt.

brudne programowanie (dirty programming) Styl programowania, który w naganny sposób zaniedbuje podstawowe zasady, powodując nieuchronne błędy przy rozroście danych, liczby użytkowników, czasu eksploatacji, itd. Typowymi symptomami brudnego programowania jest alokowanie obszaru na stercie i następnie „zapominanie” o konieczności zwolnienia go w odpowiednim momencie, korzystanie z niezainicjowanych zmiennych (licząc, że komputer sam je ustawi na zero), zadeklarowanie (w C) pewnego obszaru przeznaczonego na wartość stringową i następnie nie ustawienie strażnika kontrolującego rozmiar stringu podstawianego na ten obszar, zadeklarowanie zamiast kontenera (np. Pracownicy) tablicy o rozmiarze 10000 elementów, licząc na to, że zanim nastąpi jej przepełnienie mnie już nie będzie w tej pracy, powołanie wielu wątków bez troski o ich interakcję i synchronizacje dostępu do zasobów, itd. Walka z brudnym programowaniem wymaga często powołania w danej firmie odpowiedniej wyspecjalizowanej komórki, której obowiązkiem jest (wyrywkowe lub systematyczne) badanie jakości programowania.

brudny obiekt (dirty object) Określenie obiektu zaktualizowanego przez pewną transakcję, która nie została jeszcze potwierdzona. Brudny obiekt może być fizycznie i logicznie niespójny, w związku z czym dostęp do niego przez inną transakcję może doprowadzić do utraty spójności bazy danych i/lub przetwarzania. Termin ten występuje w kontekście zmniejszania poziomu izolacji (isolation level), np. w SQL, m.in. z powodu konieczności przetwarzania długich transakcji.

brudny odczyt (dirty read) Czytanie z brudnej strony lub brudnego obiektu.

brzęczydło (buzzword) Często powtarzane słowo (lub fraza), szczególnie w

28


literaturze komercyjnej, używane zwykle jako określenie (lub niekiedy jako synonim) czegoś pozytywnego, znakomitego, nowoczesnego. Nierzadko to słowo jest stosowane w oderwaniu od jego rzeczywistej semantyki, posiada mało precyzyjne znaczenie lub występuje w niewłaściwym kontekście. Użycie brzęczydeł ma na celu wywołanie odpowiedniego wrażenia u słuchaczy lub czytelników. Często brzęczydło pełni rolę komercyjnego fetyszu, stereotypu mającego pozyskać klientów poprzez wytworzenie wrażenia nowoczesności, doskonałości technologicznej. Uporczywymi brzęczydłami są terminy: „relational”, „integrated”, „distributed”, „open system”, „SQL”, „structural”, „modular”, „client/server”, itd. Zwrot świata komercyjnego ku obiektowości spowodował wytworzenie wielu nowych brzęczydeł, wśród nich: „object-oriented”, „portable”, „interoperable”, „component”, „agent”, „abstract”, „scalability”, „C++”, „Java”, itd.

brzytwa Occama (Occam’s razor) „Entia non sunt multiplicanda praeter necessitatem”: nie mnożyć bytów ponad potrzebę. Zasada sformułowana przez Williama Occama (1280-1349), zalecająca unikanie cech redundantnych. W językach i systemach obiektowych zasada ta nakazuje unikanie redundantnej składni oraz unikanie wprowadzania takich konstrukcji językowych, które można łatwo zastąpić przez inne konstrukcje.

bufor (buffer, cache) Obszar w pamięci operacyjnej służący do czasowego zapamiętywania i przetwarzania kopii obiektów przechowywanych w bazie danych.

bzdura (nonsense, rubbish) Określenie argumentu, opinii, stereotypu, wypowiedzi, itp., która jest nonsensem, zaprzecza oczywistym faktom, jest niezgodna ze zdrowym rozsądkiem, jest pochopnym i nieprzemyślanym poglądem, prezentuje skrajne myślenie życzeniowe w ramach forsowanej przez jej autora ideologii lub koncepcji, jest wewnętrznie sprzeczna. Wśród bzdur dotyczących obiektowości można wyróżnić zwyczajne idiotyzmy, prezentowane przez różne osoby niezbyt kompetentne w przedmiocie, jak również bzdury wybitne, wypowiadane przez światowe autorytety na renomowanych konferencjach oraz wypisywane w książkach i podręcznikach. Historia niektórych bzdur ma już ponad 25 lat, z tego względu godne są uwagi i zainteresowania środowiska naukowego jako ważny i modny temat badawczy - zważywszy chociażby na obfitość materiału wejściowego oraz jego poznawczą, ekonomiczną i społeczną wagę.

Bzdury dzielimy na: (a) absolutne bzdury; (b) bzdury relatywne lub inaczej względne; (c) bzdury-przekręty. Powyższa klasyfikacja nie zawsze jest jednoznaczna. Absolutna bzdura ma miejsce wtedy, gdy jest bzdurą w dowolnych okolicznościach. Bzdura relatywna nie jest bzdurą dla jej autora, gdyż prezentuje podstawowe założenie lub aksjomat pewnej szkoły, ideologii lub koncepcji; jest natomiast bzdurą dla osób, które nie są jej wyznawcami. Bzdura-przekręt występuje wtedy, gdy pewna osoba lub firma świadomie puszcza ją w świat dla wymiernego interesu, ponieważ jest ona dla niej bardzo wygodna, sprzyja aktualnym (kulawym) rozwiązaniom, lub występuje nadzieja, że zamieni się ona w fałszywy stereotyp, który osłabi lub wyeliminuje konkurencję. Niżej prezentujemy niektóre wybitne bzdury, które można spotkać w obiektowej literaturze, zarówno komercyjnej jak i naukowej: Systemy relacyjne i SQL posiadają solidne podstawy matematyczne (w

29


przeciwieństwie do systemów obiektowych). Operatory algebry relacji spełniają tę samą rolę dla systemów baz danych, jak

operatory arytmetyczne dla komputera. W języku Smalltalk wszystko jest obiektem! („A komunikat też?” - „Eeeeee ...

no .... nie.”) Algebra relacji może być łatwo rozszerzona do pełnego, uniwersalnego języka

programowania aplikacji. Warunkiem optymalizacji obiektowych zapytań jest przekształcenie ich do postaci

określonej przez pewną obiektową algebrę. Zagnieżdżanie obiektowych zapytań wymaga spełnienia własności domkniętości

(closure property), polegającej na tym, że zarówno wejściem jak i wynikiem zapytań są obiekty.

Standard SQL zapewnia pełną kompatybilność i przenaszalność oprogramowania dla systemów relacyjnych.

Hermetyzację należy odrzucić, bo uniemożliwia realizację języków zapytań. Hermetyzacja polega na tym, że widoczne są wyłącznie niektóre metody obiektu,

zaś niewidoczny jest jego stan (atrybuty). (Patrz: hermetyzacja.) Dziedziczenie (oraz wielodziedziczenie) jest całkowicie zbędne, bo można je łatwo

odwzorować przez agregację (delegację, asocjację, dodatkową tablicę, itd.). Dynamiczne role obiektu powodują nieakceptowalne skomplikowanie modelu

obiektowego; można je łatwo odwzorować przez odpowiednie wzorce projektowe (np. dekoratora).

Obecność wskaźników w strukturach obiektowych cofa rozwój baz danych do lat 70-tych.

Obiekty rozproszone nie mogą mieć (lub nie powinny mieć) stanu. Systemy relacyjne umożliwiają matematyczną weryfikację poprawności

zaprojektowanej bazy danych. Ponieważ bazy danych zawierają fakty, zaś fakty opisuje logika predykatów, wobec

tego logika predykatów jest doskonałym narzędziem przetwarzania baz danych. Kręgosłupem SQL jest logika matematyczna. Kręgosłupem OQL jest rachunek dziedzinowy (domain calculus). Obiektowość w bazach danych jest przejściową modą; w dłuższym horyzoncie

zwyciężą dedukcyjne bazy danych. Obiektowe bazy danych nie mogą być wyposażone w języki zapytań. Obiektowe języki zapytań nie mają (i nie mogą mieć) sprawnych metod

optymalizacyjnych. Jeżeli X jest kolekcją, wówczas składnia języka zapytań X.Y prowadzi do

niejednoznaczności; konieczne jest w takiej sytuacji użycie składni select Y from X. Obiektowe bazy danych nie mogą zapewnić skalowalności (bezpieczeństwa,

wydajności, wielodostępu, przetwarzania transakcji, rozproszenia, itd.). Obiektowość jest dobra na etapie analizy i projektowania, ale jest mało przydatna

dla implementacji. Aby uniknąć niespójności związanej ze zwisającymi wskaźnikami wystarczy nie

wprowadzać w języku operacji usuwania obiektu, ale powierzyć tę sprawę

30


mechanizmowi automatycznego zbierania nieużytków. Uniwersalnym środkiem projektowania jest notacja Z (sieci Petriego, VDM, itd.);

umożliwia ona matematyczną weryfikację poprawności projektu. Obiektowe bazy danych sprowadzają się do dodania cechy trwałości do

obiektowych języków programowania.

Jako ćwiczenie z zakresu bzdurologii proponujemy zastanowienie się: (1) dlaczego powyższe stwierdzenia są bzdurami; (2) do której kategorii należą; (3) dlaczego któryś z niepodważalnych informatycznych autorytetów je wypowiedział lub lansuje.

CC

C/S (Client/Server) Patrz: klient-serwer.

C++ Obiektowy język programowania o konstrukcji hybrydowej, pochodna języka C. Duże zastosowania na skalę przemysłową. Łączy własności C niskiego poziomu, takie jak arytmetyka wskaźników, z konstrukcjami wysokiego poziomu, takimi jak klasy, podklasy, funkcje wirtualne, hermetyzacja. W C++ klasa jest zdefiniowanym przez użytkownika typem. Jest ona syntaktycznie zapisywana jako struktura z funkcjami członkowskimi. Konstruktory i destruktory są funkcjami członkowskimi, które są wołane w celu utworzenia lub skasowania obiektu danej klasy. Funkcja zaprzyjaźniona (friend) jest funkcją z innej klasy, która ma dostęp do prywatnych własności danej klasy. C++ daje możliwości konwersji typu implicite (poprzez kast), funkcji „rozwijanych w miejscu” (inline functions), przeciążania operatorów i funkcji, oraz funkcji z domyślnymi argumentami. Posiada pojęcie strumieni (streams) dla wejścia i wyjścia, oraz referencje. Wprowadza także wielodziedziczenie, bezpieczną typologicznie konsolidację, wskaźniki do członków klasy, oraz klasy abstrakcyjne.

C++ jest najszerzej rozpowszechnionym obiektowym językiem programowania. Eklektyczna natura C++ jest przedmiotem krytyki. Jest on też krytykowany z powodu wolnego tworzenia aplikacji, zawodności, słabej przenaszalności, zwiększonego ryzyka wadliwego działania programów (np. wyciekanie pamięci) i szeregu innych wad. Jakkolwiek C++ ma w obecnej chwili duże powodzenie, wielu specjalistów wróży szybki koniec jego kariery, m.in. w związku z pojawieniem się języków wyższego poziomu i bardziej przyjacielskich, takich jak Java lub środowisk programowania wizyjnego. Wielu autorów podkreśla, że C++ jest językiem trudnym do uczenia się i użycia. Ponadto, w większości programiści używają C++ jako „lepszego C”, nie wykorzystując w istocie jego możliwości obiektowych.

http://www.csci.csusb.edu/dick/c++std/ (C++ Standard)http://www.cygnus.com/misc/wp/http://info.desy.de/user/projects/C++.htmlhttp://www.icce.rug.nl/docs/cplusplus/cplusplus.html

CAD [1] (Computer Aided Design) Projektowanie wspomagane komputerowo. Często wymieniana dziedzina potencjalnych zastosowań technologii obiektowych.

31


CAD [2] (Class Association Diagram) Patrz: diagram asocjacji klas.

CAM (Computer Aided Manufacturing) Wytwarzanie wspomagane komputerowo. Często wymieniana dziedzina potencjalnych zastosowań technologii obiektowych.

Cardelli, Luka Propagator teorii typów polimorficznych, szczególnie w zastosowaniu do obiektowości. Również autor lub współautor kilku (obiektowych, polimorficznych) języków programowania (Galileo, Quest, Amber, Obliq) o charakterze modelowym i akademickim.

Cartridges Pakiet oprogramowania (biblioteka klas) oferowany przez firmę Oracle dla systemu Oracle-8, służący do przetwarzania multimediów (tekst, wideo, grafika bitowa) i danych przestrzennych.

CASE (Computer Aided Software Engineering, Computer Aided System Engineering) Komputerowe wspomaganie inżynierii oprogramowania, komputerowe wspomaganie inżynierii systemów. Określenie systemu wspomagającego analizę i projektowanie systemów informatycznych, w tym opartych o technologie obiektowe. CASE jest również często wymienianą dziedziną potencjalnych zastosowań technologii obiektowych. Pakiety CASE mogą, w szczególności, składać się z następujących elementów: Graficzne interfejsy do rysowania, modyfikacji i drukowania diagramów encja-

związek, diagramów klas, diagramów stanów, diagramów przepływu danych, lub innych diagramów.

Procedury automatycznego generowania relacyjnych schematów bazy danych (np. w SQL) lub schematów obiektowych (np. w IDL).

Sprawdzanie formalnej zgodności pomiędzy różnymi diagramami. Prowadzenie wspólnego słownika użytych nazw i sprawdzanie zgodności ich

użycia. Definiowanie i przetwarzanie więzów integralności. Specyfikowanie funkcji aplikacyjnych działających na projektowanej bazie danych,

poprzez określenie danych wejściowych, danych wyjściowych, oraz semantyki funkcji.

Wspomaganie procesu tworzenia dokumentacji bazy danych, oraz dokumentacji programów aplikacyjnych, dla różnych faz procesu projektowania i różnych poziomów abstrakcji.

Automatyczna budowa prototypu aplikacji na podstawie sformalizowanej (uproszczonej) specyfikacji.

32


Środowisko implementacji

Moduł inżynieriiodwrotnej

Generatorykodu

Moduł pracysieciowej

Moduł zarządzaniapracą grupową

Moduł zarządzaniakonfiguracjami

Generatoryraportów

Generatory dokumentacjitechnicznej

Moduł kontrolijakości

Moduł kontrolipoprawności

Moduł importu/eksportu danych

Sprzęgi donarzędzi RAD

Słownikdanych

Moduł projektowaniainterfejsu użytkownika

Edytorydiagramów

Składowe narzędzi CASE

http://iamwww.unibe.ch/~scg/OOinfo/FAQ/oo-faq-S-10.html

Catalysis Obiektowa metodyka analizy i projektowania systemów informatycznych opracowana przez D’Souza i Willsa.

http://www.iconcomp.com/papers/cata/index.html

Cattel, Rick Prezes grupy ODMG, główny architekt standardu ODMG.

cecha eksportowana (exported feature) Cecha pewnego bytu programistycznego (atrybut, procedura, metoda, typ, itd.) dostępna publicznie.

Cecil Obiektowy język programowania opracowany przez Uniwersytet w Waszyngtonie, przeznaczony do wspomagania szybkiej konstrukcji rozszerzalnego oprogramowania. Cecil jest oparty o prosty model obiektowy bazujący na prototypach, posiada mechanizm wspomagający strukturalną formę dziedziczenia, hermetyzację opartą na modułach i elastyczny mechanizm mocnej statycznej kontroli typów.

CF (Common Facilities) Patrz: wspólne udogodnienia.

CFOM (Composition Filters Object Model) Rozszerzony model obiektowy pozwalający wyrazić wiele pojęć obiektowości, wspomagający ponowne użycie i rozszerzalność.

http://wwwtrese.cs.utwente.nl/

Chen, Peter Twórca i propagator modelu encja-związek.

33


chroniony (protected) Określenie cechy, atrybutu, metody, funkcji, która jest niedostępna z zewnątrz danej klasy, z wyjątkiem klas będących jej specjalizacją.

chudy klient (thin klient) W architekturze klient-serwer określenie klienta o bardzo ograniczonych funkcjach, korzystającego głównie z usług świadczonych przez serwer. Przeciwieństwem jest tłusty (mocny) klient (fat client).

ciało metody (method body) Kod (zapisany w języku programowania) implementujący metodę. Synonim: treść metody.

cienki klient (thin klient) Patrz: chudy klient.

CIO (Chief Information Officer) Główny specjalista d/s informacji. Stanowisko w firmie (amerykańskiej). Osoba piastująca to stanowisko jest odpowiedzialna za rozpoznanie pojawiających się nowych technologii na rynku oraz za kroki zmierzające do wdrożenia tych technologii w firmie. Wiele materiałów marketingowych, dokumentów, opracowań, analiz pojawiających się w związku z technologiami obiektowymi jest adresowane do CIO.

CLI (Call-Level Interface) Interfejs poziomu wołań procedur (dla SQL). CLI jest interfejsem programistycznym (zestawem procedur) umożliwiającym dostęp programów aplikacyjnych do relacyjnych baz danych poprzez SQL na poziomie wołań procedur. CLI stał się podstawą standardu ODBC. SQL/CLI jest międzynarodowym standardem, dodatkiem do SQL-92. Obecnie trwają prace nad stworzeniem standardu CLI dla SQL3.

http://www.jcc.com/sql_cli.html

CLIPS (C Language Integrated Production System) Język przeznaczony do budowy systemów ekspertowych, zaimplementowany przez NASA. Posiada możliwości wnioskowania i reprezentowania wiedzy, wspomaganie dla reguł oraz obiektowego i proceduralnego programowania. Składnia jest oparta na języku Lisp.

CLOB (Character Large Object) Duży obiekt znakowy; pojęcie występujące w niektórych systemach obiektowo-relacyjnych.

CLOS (Common LISP Object System) Obiektowe rozwinięcie języka programowania Lisp.

http://www.franz.com/

CLU Obiektowy język programowania z rodziny Pascala, opracowany w MIT. Wspomaga abstrakcje danych oraz iteratory. Program w CLU składa się z oddzielnie kompilowanych procedur, klastrów (clusters) oraz iteratorów (bez zagnieżdżania). Klaster jest modułem włączającym typ abstrakcyjny, jego operacje, wewnętrzną reprezentację oraz implementację. Klastry i iteratory mogą być generyczne (parametryzowane). Posiada uniwersalny typ any oraz procedurę sprawdzającą typ obiektu. Obiekty mogą być zmienialne lub niezmienialne. Wspomaga także wyjątki. Podstawienie odbywa się bez tworzenia kopii, lecz poprzez zbudowanie referencji do

34


podstawianej wartości. CLU posiada zmienne własne (own variables) oraz wielokrotne podstawienie.

CO2 Obiektowy język programowania (oparty o C) dla systemu O2 (obecnie nie podtrzymywany).

Coad, Peter Twórca metodyki obiektowej analizy i projektowania systemów informatycznych, określanej jako Coad/Yourdon.

Coad/Yourdon Obiektowa metodyka analizy i projektowania systemów informatycznych. Patrz: OOA/OOD.

COBRA Częsta błędna pisownia akronimu CORBA.

COM (Component Object Model lub Common Object Model) Powszechny model obiektowy lansowany przez Microsoft. COM jest modelem komunikacji i komponentów zastosowanym w OLE2. Wersja COM umożliwiająca pracę w systemie rozproszonym jest określana jako DCOM (Distributed COM). W 1995 technologia OLE2/COM/DCOM została przystosowana do współpracy z Internetem, uzyskując przy tym nową nazwę ActiveX. (Będziemy tę technologię oznaczać OLE2/COM/ActiveX.) Literatura na ten temat jest ogromna i jak dotąd nieco chaotyczna, w związku z czym jest dość trudno rozpoznać, jakie są dokładnie założenia architektoniczne OLE2/COM/ActiveX, gdzie są granice tej technologii, jakie języki, interfejsy i narzędzia ona włącza. Równie niejasny jest stosunek technologii OLE2/DCOM/ActiveX do standardu CORBA (w szczególności do protokołu IIOP). Są opinie, że CORBA jest rozwiązaniem eleganckim i uniwersalnym, natomiast OLE2/COM/ActiveX jest technologią niedojrzałą, przypisaną (proprietary) do produktów Microsoftu, skonstruowaną chaotycznie na zasadzie oddolnego rozrostu prostej koncepcji OLE, wreszcie zawodną i nie posiadającą walorów ochrony i bezpieczeństwa (safety, security) niezbędnych do pracy w sieci. Technologia OLE2/COM/ActiveX może być jednak poważnym konkurentem dla standardu CORBA. Pewne cechy mogą przesądzić na korzyść OLE2/COM/ActiveX; wśród nich można wymienić stosunkowo niski koszt, lepszą wydajność i pełne zintegrowanie z popularnymi produktami Microsoftu, które zdobyły ogromny segment rynku zastosowań biurowych. Często stwierdza się, że technologia OLE2/COM/ActiveX „już jest w powszechnym użyciu”, natomiast CORBA „jest tylko specyfikacją” (co nie jest do końca prawdą, ponieważ istnieje wiele systemów ORB opartych na CORBA). Niektóre opinie głoszą, że te standardy uzupełniają się, ponieważ CORBA jest bliżej systemu operacyjnego (back end), zaś OLE2/COM/ActiveX jest bliżej interfejsów do rozwijania aplikacji (front end). Jakkolwiek OMG wyraża explicite swój krytyczny stosunek do OLE2/COM/ActiveX (i odwrotnie, np. wypowiedzi Rogera Sessions), niemniej traktuje Microsoft jako ważnego partnera w obecnej i przyszłej współpracy. W szczególności, konsorcjum OMG opracowało specyfikację „pomostu” pomiędzy COM i CORBA. W tej chwili trudno jednak przewidzieć, jakie konsekwencje przyniesie dalsza konfrontacja COM i CORBA.

http://www.microsoft.com/comhttp://www.microsoft.com/oledev/olecom/title.htm

35

http://www.microsoft.com/com


COM+ Rozszerzenie COM obejmujące poprzednią technologię Microsoftu, określaną jako MTS (Microsoft Transaction Server).

Component Broker Obiektowy monitor transakcji bazujący na standardzie CORBA, rozwinięcie SOM. Produkt IBM.

http://www.software.ibm.com/objects/somobjects/http://www.software.ibm.com/ad/cb/

COOL [1] (Chorus Object-Oriented Layer) Pakiet ORB dla obiektowego systemu operacyjnego Chorus opracowany w ramach projektu Esprit/OUVERTURE.

http://www.chorus.com/Products/Cool/index.html

COOL [2] (Cobol Object-Oriented Language) Patrz: OO-Cobol.

COOL [3] (Concurrent Object-Oriented Language) Rozszerzenie C++ z równoległym wykonywaniem zadań oraz podziałem pamięci dla multi-procesorów.

CORBA (Common Object Request Broker Architecture) Standard współdziałania systemów obiektowych i nieobiektowych, heterogenicznych i rozproszonych, opracowany przez gremium OMG. Celem standardu OMG CORBA jest uzyskanie możliwości współdziałania pomiędzy niekompatybilnymi systemami, pracującymi na różnych platformach sprzętowych i programowych, oddalonych geograficznie. Osiągnięcie tego celu wymagało zwiększenia poziomu abstrakcji w taki sposób, aby (zazwyczaj zasadnicze) różnice implementacyjne nie miały znaczenia. Ten poziom abstrakcji osiąga się poprzez opis obiektów w uniwersalnym języku IDL (Interface Definition Language), który oprócz struktury obiektów ustala także specyfikacje metod działających na obiektach oraz zależności (wielo) dziedziczenia. Do współdziałania konieczne jest także określenie odwzorowania (mapping) implementacji obiektów na abstrakcyjną postać implikowaną przez IDL. Temu celowi poświęcony jest adapter obiektów, w szczególności BOA (Basic Object Adapter); jest on specyficzny dla danego języka programowania. Powiązanie pomiędzy aplikacją (odwołującą się do obiektów) i implementacją obiektów może mieć charakter statyczny lub dynamiczny, w zależności od tego, czy wiązanie następuje w czasie kompilacji czy też w czasie wykonania. W przypadku statycznym, z wyrażenia IDL jest generowany automatycznie tzw. pniak (stub), czyli fragment kodu, który jest konsolidowany z aplikacją klienta. Po stronie serwera obiektów z wyrażenia IDL generowany jest szkielet (skeleton) implementacji, który programista musi zapełnić konkretnym kodem implementacyjnym wyspecyfikowanych metod. W przypadku dynamicznym, dostęp następuje bezpośrednio poprzez odwołania dynamiczne, na zasadzie podobnej do RPC.

36


Wołaniadynamiczne

(RPC)

KlientImplementacja obiektów

(reprezentacja i przechowywanieobiektów; realizacja dostępu i usług)

Interfejs do

pośrednika ORB

Adapterobiektów

Rdzeń Pośrednika (ORB core)

Takie samo dla wszystkich ORBPniaki i szkielety specyficzne dla interfejsów

Może być wiele adapterów obiektów

Prywatne interfejsy ORB

Repozytoriuminterfejsów

Repozytoriumimplementacji

dynamiczne

statyczne

PniakIDL

(IDL stub)

Szkielet obiektów(IDL skeleton)

DynamicznySzkielet Interfejsu

Architektura standardu CORBA oraz przesyłanie zleceń statycznych i dynamicznych

OMG CORBA obejmuje także dużą kolekcję usług i udogodnień, zarówno poziomych (niezależnych od dziedziny aplikacyjnej, np. usługi w zakresie nazw, zdarzeń, trwałych obiektów, związków, zapytań), jak i pionowych (specyficznych dla danej dziedziny aplikacyjnej, np. telekomunikacja, medycyna, finanse, wytwarzanie). Podstawowym elementem architektonicznym standardu CORBA jest tzw. pośrednik (Object Request Broker, ORB), skupiający w sobie wymienione wyżej funkcjonalności niezbędne do przetwarzania rozproszonych obiektów i współdziałania. Pakiety ORB komunikują się ze sobą w sieci komputerowej przy pomocy protokołu GIOP (General Inter-ORB Protocol). W tej chwili zaimplementowano kilkanaście pakietów ORB. CORBA ma ogromne znaczenie kulturotwórcze w dziedzinie informatyki, chociaż wydaje się, że maksymalistyczne cele tego standardu są trudne do osiągnięcia, szczególnie w zakresie akceptowalnej wydajności (performance). Niektórzy specjaliści głoszą, że oparcie rozproszonych aplikacji o standard CORBA będzie zbyt kosztowne. Nie jest jednak do końca pewne, czy opinie te nie są podsycane przez konkurencję, m.in. przez Microsoft oferujący technologię COM/DCOM, która jest rozwiązaniem znacznie „lżejszym” i tańszym (ale też o mniejszej uniwersalności i mniejszym zakresie zastosowań). Konkurentem dla pakietów opartych o standard CORBA jest także pakiet pośredniczący JavaBeans, integrujący rozproszone komponenty napisane w Java.

http://www.omg.orghttp://www.acl.lanl.gov/CORBA/http://www.acl.lanl.gov/cgi-bin/doclist.plhttp://www.cs.wustl.edu/~schmidt/corba.htmlhttp://plato.cis.nctu.edu.tw/CORBA/idl.htmhttp://www.sw-technologies.com/corba/http://www.acl.lanl.gov/~reverbel/orb_odbms.htmlhttp://adams.patriot.net/~tvalesky/freecorba.html

37


http://galaxy.uci.agh.edu.pl/~vahe/orb_odb/corba.htm

CORBA 1.1 Specyfikacja standardu CORBA z roku 1991, obecnie znowelizowana. Patrz: CORBA.

CORBA 2.0 Specyfikacja standardu CORBA z grudnia 1994 zapewniająca współdziałanie pomiędzy niezależnie zbudowanymi pośrednikami ORB. Patrz też: CORBA.

http://www.omg.org

CORBA 3.0 Nowa wersja standardu CORBA będąca w trakcie opracowywania. Planowane jest wiele rozszerzeń obecnego standardu CORBA 2.0, w szczególności: obsługa komunikatów (messaging), przenaszalność po stronie serwera (server portability, POA), wielokrotne interfejsy (multiple interfaces), obiekty biznesowe zintegrowane z JavaBeans (business objects/JavaBeans), wiązania do Java (Java bindings), obiekty jako wartości (objects-by-value), mobilni agenci (mobile agents), wiązanie do DCOM (CORBA/DCOM), automatyczna trwałość (automatic persistence), wspomaganie dla zapory ogniowej protokółu IIOP (IIOP firewall support), przepływy prac (workflow), szkielety dziedzinowe (domain-level frameworks). Patrz też: CORBA.

http://www.corbajava.engr.sjsu.eduhttp://www.omg.org

CRC (Class Responsibility Collaborator) Prosta metoda pracy z przyszłymi użytkownikami systemu mająca na celu określenie ich potrzeb i wymagań. Metoda CRC jest zalecana w kilku metodykach analizy i projektowania. Patrz też: karta CRC.

CRUD (Create, Retrieve, Update, Delete) Tworzenie, wyszukiwanie, aktualizacja, usuwanie. Akronim określający podstawowe funkcjonalności wymagane przez mechanizm trwałych danych lub obiektów.

CSCW (Computer Supported Cooperative Work) Komputerowe wspomaganie pracy grupowej. Określenie dziedziny badawczej i technologii zajmującej się organizacją pracy grupowej. Typowym produktem wspomagającym jest LotusNotes.

cykl życia obiektu (object life cycle) Diagram lub inna notacja pokazująca fazy życia obiektu pod kątem jego roli w systemie informacyjnym. Zwykle, ten termin jest łączony z operacjami (metodami) tworzenia i usuwania obiektów.

czarna skrzynka (black box) Określenie pewnej rzeczy, której wewnętrzna budowa lub implementacja jest ukryta. Termin ten jest wiązany z ponownym użyciem (reuse), gdzie oznacza taki aktyw ponownego użycia, który można i należy używać bez potrzeby lub możliwości rozpoznania jego wewnętrznej zawartości. Przykładem ponownego użycia na zasadzie czarnej skrzynki jest tworzenie obiektów kompozytowych składających się z mniejszych obiektów o znanym interfejsie, lecz nieznanej implementacji.

czas kompilacji (compile-time) Czas, w którym następuje zamiana tekstu programu na jego wykonywalny (binarny) kod.

38


czas wykonania (run-time) Czas, w którym następują akcje komputera zgodne z aktualnie wykonywanym kodem programu.

czas życia obiektu (object lifetime) Patrz: cykl życia obiektu.

członek (member) Termin występuje w dwóch znaczeniach: Obiekt będący wystąpieniem danej klasy; synonim wystąpienia (instance).

Niektórzy autorzy różnicują terminy wystąpienie i członek w taki sposób, że wystąpienie dotyczy bezpośredniej klasy obiektu, natomiast członek dotyczy również klas stojących wyżej w hierarchii dziedziczenia (np. konkretny obiekt może być wystąpieniem klasy Student, ale nie jest wystąpieniem klasy Osoba; jest on natomiast członkiem obydwu klas).

Definicja lub deklaracja metody lub atrybutu w ramach definicji klasy, zapisu lub struktury, np. atrybut Nazwisko jest członkiem struktury Osoba.

DD

DAIS Pośrednik ORB wg standardu CORBA rozprowadzany przez ICL.http://www.icl.co.uk/products/dais/home.html

dane biznesowe (business data) Dane, które mają znaczenie dla dziedziny przedmiotowej (szeroko pojmowanego biznesu); dane, które uczestniczą w przetwarzaniu określonym przez logikę biznesu.

dane masowe (bulk data) Dane, których rozmiar może zmieniać się dynamicznie w sposób nieograniczony. Zwykle chodzi tu o wartości danych określone przez konstruktory typów masowych, takich jak: zbiór, relacja, wielozbiór, sekwencja i tablica dynamiczna.

dane niestrukturalne (unstructured data) Dane (zwykle tekstowe lub graficzne), których struktura (typ, format, schemat) nie jest określona i nie może być w prosty sposób rozpoznana przez system. Przykładem danych niestrukturalnych są dokumenty (przepisy) z zakresu prawa.

dane półstrukturalne (semistructured data) Dane, których struktura nie jest znana, jest nieregularna, ale może być w pewnym zakresie rozpoznana przez system. Często tym terminem określa się dane, w których etykiety danych (nazwy obiektów, nazwy atrybutów) są przechowywane razem z wartościami, przy czym nie są one ograniczone przez typ i mogą zmieniać się w ramach tego samego rodzaju obiektu.

dane przestrzenne (spatial data) Dane opisujące przestrzeń (zwykle trójwymiarową) oraz obiekty w tej przestrzeni, np. dane projektów architektonicznych, dane dotyczące konstrukcji maszyn, itd.

dane temporalne (temporal data) Dane, w których kluczową rolę odgrywa

39


rejestracja momentów lub odcinków czasu, np. dane o wydarzeniach historycznych.

dane wirtualne (virtual data) Dane, które nie są zapamiętane fizycznie, lecz są wyliczane w momencie dostępu; dane widziane poprzez pewną perspektywę (view).

DataBlades Pakiet oprogramowania (biblioteka klas) oferowany przez firmę Informix dla przetwarzania multimediów (tekst, audio, wideo, grafika bitowa), danych przestrzennych, danych temporalnych i innych.

http://www.informix.com/informix/

DataExtenders Pakiet oprogramowania (biblioteka klas) oferowany przez firmę IBM jako składnik systemu DB2 Universal Database dla przetwarzania multimediów (tekst, audio, wideo, grafika bitowa, odciski palców), danych przestrzennych i innych.

DB (Data Base) Patrz: baza danych.

DB2 Universal Database Obiektowo-relacyjny SZBD firmy IBM; następca prototypu o nazwie Starburst. Wspomaga duże obiekty (BLOB-y i CLOB-y), typy i funkcje definiowane przez użytkownika (w językach C, Visual Basic i Java), funkcje zwracające tablice, funkcje OLE, przeciążanie oraz SQL wzmocniony o wyrażenia ścieżkowe.

DBA (Data Base Administrator) Patrz: administrator bazy danych.

DBMS (Data Base Management System) Patrz: system zarządzania bazą danych.

DBPL (Data Base Programming Language) Patrz: język programowania baz danych.

DCE (Distributed Computing Environment) Standard rozproszonego systemu informatycznego oparty o koncepcję odległego wołania procedury (RPC); opracowany przez konsorcjum Open Software Foundation, OSF.

http://www.opengroup.org/pubs/catalog/f201.htm

DCOM (Distributed Common Object Model) Standard firmy Microsoft w zakresie współdziałania systemów obiektowych w środowiskach rozproszonych; wersja sieciowa standardu COM powstała poprzez zintegrowanie go z technologią wołania odległej procedury OSF DCE. DCOM jest niekiedy reklamowany przez Microsoft jako konkurent dla standardu CORBA; jak dotąd jednak (w odróżnieniu od CORBA), stosowalność jego jest ograniczona wyłącznie do MS Windows i innych produktów Microsoftu. DCOM jest także krytykowany za brak dziedziczenia; zgodnie z zapowiedziami będzie ono własnością nowej wersji COM+. Patrz też: COM.

http://www.microsoft.com/oledev/olecom/title.htmhttp://www.microsoft.com/oledev/olecom/draft-brown-dcom-v1-spec-02.txt

DDD (Data Dictionary-Directory) Słownik-przewodnik danych. Patrz: słownik.

DDL (Data Description Language, Data Definition Language) Język opisu lub

40


definicji danych. Początkowo, język zaproponowany przez DBTG CODASYL, służący do zapisu schematu bazy danych. Termin ten służy również jako ogólne oznaczenie całej klasy takich języków, np. języka IDL wg OMG CORBA lub ODL wg standardu ODMG.

deaktywacja (deactivation) Zapamiętanie obiektu w trwałej pamięci zewnętrznej i usunięcie go z pamięci operacyjnej.

dedukcyjno-obiektowe (deductive object-oriented) Określenie badań w dziedzinie baz danych, które próbują łączyć dedukcyjne bazy danych (oparte na logice matematycznej) z pojęciami obiektowości, takimi jak klasy i dziedziczenie. Jak dotąd, temat pozostaje w sferze akademickiej i (jak można sądzić) jego jedynym motywem są naukowe kariery („następny artykuł na następną konferencję”). Sadząc po rezultatach kierunku określanego jako „dedukcyjne bazy danych”, koncepcja dedukcyjno-obiektowych baz danych nie jest perspektywiczna. Patrz też: pseudo-teoria.

deklaracja (declaration) Zdanie kodu źródłowego określające nazwę i typ (lub klasę) zmiennej lub obiektu. Deklaracje mogą również określać typy i klasy. Dla funkcji, procedury, metody, itd. deklaracja określa jej nazwę, nazwy i typy parametrów, oraz typ zwracanego przez nią wyniku. Deklaracja różni się od tworzenia danego bytu programistycznego tym, że jego nazwa, typ, itd. są znane i są wiązane podczas kompilacji. Na ogół przyjmuje się, że tworzone poprzez deklarację byty programistyczne są obywatelami drugiej kategorii programistycznej.

deklaracyjny (declarative) Określenie języka programowania, w którym bezpośrednio formułuje się cel przetwarzania, a nie akcje prowadzące do tego celu. Przykładem (niedoskonałym) języka deklaracyjnego jest Prolog. W bazach danych termin „deklaracyjny” odnosi się najczęściej do języka zapytań, np. SQL lub OQL. Pojęcie deklaracyjności jest często niezbyt zrozumiałe lub sprowadza się do drugorzędnych cech syntaktycznych; dotyczy to szczególnie operacji aktualizacyjnych. Synonim: nieproceduralny. Antonim: imperatywny.

dekompozycja (decomposition) Mechanizm redukowania złożoności; podział pewnego bytu (klasy, modułu, problemu, itd.) na składowe, mający na celu dalsze rozpatrywanie składowych niezależnie od pozostałych składowych i niezależnie od całości.

delegacja (delegation) Określenie sytuacji w obiektowej strukturze danych, gdy operacje, które można wykonać na danym obiekcie, są własnością innego obiektu (są „oddelegowane” do innego obiektu). W nieco innym znaczeniu (UML) delegacją jest nazywana sytuacja, kiedy obiekt po otrzymaniu komunikatu wysyła komunikat do innego obiektu. Często określenie „delegacja” dotyczy sytuacji, kiedy jakiś złożony atrybut obiektu jest także obiektem i jest wystąpieniem innej klasy. Delegacja jest uważana także za alternatywę lub szczególny przypadek dziedziczenia. Jest także określana jako dziedziczenie w ramach wystąpień obiektów, co kojarzy ją z pojęciem prototypu. Należy uprzedzić, że pojęcie delegacji nie zawsze jest jasne, ponieważ opiera się na dość powierzchownych cechach specyficznych dla modelu obiektowego

41


przyjętego w danym języku, co powoduje dość różne jego rozumienie. Np. w języku Smalltalk (gdzie „wszystko jest obiektem”) trudno wyróżnić istotną merytorycznie podstawę definicji tego pojęcia.

delegowanie (delegation) Patrz: delegacja.

Delphi Obiektowy system programowania firmy Borland, oparty o obiektowe rozszerzenie języka Pascal. Delphi łączy wizyjne projektowanie i programowanie oparte o komponenty z optymalizowaną kompilacją i dostępem do bazy danych.

denormalizacja (denormalization) Odwrotność normalizacji: połączenie dwóch lub więcej tablic relacyjnych w jedną. Denormalizacja jest konsekwencją dwóch problemów: (1) niskiej efektywności operacji złączenia; (2) zbytniego skomplikowania struktury relacyjnej bazy danych utrudniającej pielęgnację oprogramowania. Denormalizacja polega na wykonaniu zewnętrznego złączenia (outer join) dwóch lub więcej tablic, patrz przykład poniżej.

NazwiskoKowalskiMalinowskiNowakGrotLeski

IdPrac3425467323

Pracownicy PrzynależnośćDoZZ

IdPrac257346

ZwiązekZawSolidarnośćOPZZSolidarność

Pracownicy

NazwiskoKowalskiMalinowskiNowakGrotLeski

IdPrac3425467323

ZwiązekZawNULLSolidarnośćSolidarnośćOPZZNULL

Przykład denormalizacji

dereferencja (dereferencing) Zamiana referencji lub wskaźnika (identyfikatora obiektu lub adresu zmiennej) na wartość przechowywaną wewnątrz tego obiektu lub tej zmiennej. W większości języków programowania operator dereferencji nie występuje explicite, lecz jest implikowany przez inne operatory, np. w wyrażeniu X+1 referencja do zmiennej X zostaje automatycznie zamieniona na wartość przechowywaną wewnątrz tej zmiennej z powodu kontekstu (którym jest operator +). W obiektowości pojęcie dereferencji wymaga zdefiniowania pojęcia wartości obiektu, co rodzi pewne problemy semantyczne.

42


derywacja (derivation) Tworzenie klasy pochodnej (podklasy).

destruktor (destructor) Operator lub metoda usuwająca obiekty; przeciwieństwo konstruktora.

DFD (Data Flow Diagram) Patrz: diagram przepływu danych.

diagram (diagram) Model wizualny, przeważnie w postaci grafu, odwzorowujący pewien aspekt problemu lub pewien aspekt rozwiązania problemu.

diagram aktywności (activity diagram) Diagramy aktywności w swej zasadniczej idei są dokładnie tym samym, co diagramy przepływu sterowania (flowcharts, control flow diagrams). Jedyną różnicą koncepcyjną jest to, że pojawiają się na nich elementy synchronizacji równoległych procesów (w dość prostej formie). Niżej przedstawiony został przykładowy diagram aktywności w UML.

Znajdź Napój

Nasyp kawydo filtru

Dolej wodydo zbiornika

Włóż filtr do maszynki

Włącz maszynkę Gotowanie kawy

Nalejkawę Wypij

Zrób herbatę Weź wody

[nie ma kawy]

[kawa znaleziona]

[nie ma herbaty]

[herbata znaleziona]

[maszynka włączona]

[światełko zgasło]

Weźfiliżankę

1..4 1..4

Przykład diagramu aktywności w UML


diagram asocjacji klas (class association diagram, CAD) Patrz: diagram klas.

diagram encja-związek (ERD, Entity-Relationship Diagram) Diagram stanowiący element modelu encja-związek (patrz: model encja-związek), przedstawiający encje, związki, atrybuty oraz (w często spotykanym rozszerzeniu) hierarchię dziedziczenia. Istnieje wiele konwencji notacyjnych diagramów encja-związek; przykładowy diagram przedstawiony poniżej stosuje konwencję C. Batini, S. Ceri, S. Navathe.

43


OSOBA

FAN TRENER ZAWODNIK PREZES

wspomaga prowadzi gra dla kieruje

DRUŻYNA

grająprzeciwko

sobie

MECZ odbywa się STADION

trenuje

kibicuje

(1, 1) (1, 1) (1, 1) (1, 1)

(1, 1) (1, 1)(1, n)(1, n)

(1, n)

(1, n) (1, 1)

(1, n)

(1, n)(0, n)

(1, n)(1, n)

Nr_EwidNazwiskoData_Urodz

NazwaSuma_PktData_T

Nazwa_SAdres_SWielkość

Data_GGodz_G

Numer_M

Wynik_MStatus

Przykładowy diagram encja-związek

diagram Harela (Harel diagram) Patrz: diagram stanów.

diagram interakcji (interaction diagram) Diagram ułatwiający zrozumienie zależności w przepływie sterowania. Metody realizujące to sterowanie są rozproszone w wielu klasach, co powoduje trudności ze zrozumieniem ich wzajemnej zależności i interakcji. Jest to powód sporządzania diagramów interakcji. Służą one do opisu zależności przy przesyłaniu komunikatów dla pewnej grupy obiektów. Często stanowią bardziej precyzyjny opis pojedynczego przypadku użycia. Istnieje wiele wariantów diagramów interakcji o różnych odmianach syntaktycznych. UML wprowadza dwa rodzaje takich diagramów: diagramy sekwencji i diagramy kolaboracji (współpracy).


diagram interakcji obiektów (object interaction diagram) Patrz: diagram interakcji.

diagram klas (class diagram) Diagram przedstawiający klasy obiektów, nazwy (i niekiedy typy) atrybutów, nazwy (i niekiedy sygnatury) metod, związki asocjacji i agregacji zachodzących między obiektami, liczności (cardinalities) tych związków, związki generalizacji/specjalizacji (dziedziczenia) pomiędzy klasami, a także niekiedy inne oznaczenia. Diagram klas jest także zwany diagramem asocjacji klas (class association diagram) lub modelem obiektowym (object model). Jest on pojęciem centralnym we wszystkich znanych metodykach obiektowych. W porównaniu do analogicznych diagramów encja-związek diagramy klas wprowadzają dziedziczenie (które było wprowadzone wcześniej w niektórych wersjach diagramów encja -związek) oraz metody przypisane do specyfikowanych klas. Oprócz tego zasadniczego elementu

44


pojawiają się w diagramach klas różnorodne oznaczenia o charakterze pomocniczym. Diagram klas pokazuje klasy w postaci oznaczeń graficzno-językowych powiązanych w sieć zależnościami należącymi do trzech kategorii:

Dziedziczenie (inheritance), czyli ustalenie związku generalizacji/specjalizacji pomiędzy klasami; patrz: dziedziczenie.

Asocjacja (association), czyli dowolny związek pomiędzy obiektami dziedziny przedmiotowej, który ma znaczenie dla modelowania; patrz: asocjacja.

Agregacja (aggregation), czyli szczególny przypadek asocjacji, odwzorowujący stosunek całość-część pomiędzy obiektami z modelowanej dziedziny przedmiotowej; patrz: agregacja.

Te oznaczenia są uzupełniane szeregiem dalszych oznaczeń, m.in. oznaczeniami liczności, ról związków, ograniczeń, itd. Poniżej znajduje się przykładowy diagram klas zapisany w UML.

poprzedza

następuje_po

zawiera

jest_składowąma_asystenta

asystuje_w

zapisany_na

prowadzony_dla

prowadzony_przez

prowadzi

PracownikStudent

Osoba

KursStudent_asystent Profesor

Wykład

1..*

0..*

1..* 1..*

0..*

0..*

0..1

Przykładowy diagram klas

Istnieją trzy podstawowe rodzaje zastosowań diagramów klas: Zapis modelu pojęciowego. Diagramy reprezentują pojęcia w dziedzinie

zastosowań, które aktualnie podlegają analizie. Sformalizowana specyfikacja danych i metod. Jest ona bardziej związana z

oprogramowaniem, ale dotyczy jego zewnętrznego opisu (interfejsów) bez wchodzenia w szczegóły implementacyjne.

Implementacja. W tym zastosowaniu diagram klas może służyć bezpośrednio jako graficzny środek pokazujący szczegóły implementacji klas, np. w C++.


diagram kolaboracji (collaboration diagram) Istotą diagramów kolaboracji jest przedstawienie przepływu komunikatów pomiędzy obiektami. Kolaboracja pomiędzy

45


obiektami włącza dwa aspekty: statyczną strukturę uczestniczących obiektów, włączając związki, atrybuty i operacje (jest to nazywane „kontekstem kolaboracji”), oraz sekwencję komunikatów wymienianych pomiędzy obiektami dla realizacji konkretnego zadania. Diagram kolaboracji może być rozrysowany dla pewnych typów obiektów, dla pewnych operacji lub dla pewnych przypadków użycia. Kolaboracja może dotyczyć skutków powodowanych przez dany fragment programu w środowisku zewnętrznym. Może także dotyczyć wewnętrznej implementacji obiektów i ich zachowania. W odróżnieniu od diagramów sekwencji wymiar czasu nie jest tu bezpośrednio odwzorowany (ale może być częściowo odwzorowany przez odpowiednią numerację komunikatów). Natomiast odwzorowane są powiązania pomiędzy obiektami (prezentujące pewną część powiązań z diagramu klas). Poniższy rysunek przedstawia przykładowy diagram kolaboracji w UML. Synonim: diagram współpracy.

:OknoWprowadzaniaZamówienia

:Zamówienie

LiniaMacallana: WierszZamówienia AkcjeMacallana: PozycjaAkcji

:PozycjaDostarczana :PozycjaPonownieZamówiona

Obiekt1: przygotuj()

Komunikat

2: *[dla wszystkich wierszy zamówienia] przygotuj()

3: maAkcje := sprawdź()4:[maAkcje]:usuń()5:czyNoweZamów := potrzebaNowegoZamów()

7: [maAkcje]: new 6:[czyNoweZamów]: new

Numer kolejny komunikatu

Przykładowy diagram kolaboracji


diagram komponentów (component diagram) Diagram pokazujący strukturę komponentów oprogramowania, ich związki i przepływ komunikatów oraz interfejsy ze światem zewnętrznym. Jest to graf, w którym węzłami są komponenty, zaś strzałki prowadzą od klienta pewnej informacji do jej dostawcy. Rodzaj zależności jest zależny od typu języka programowania. Diagram może także pokazywać interfejsy poszczególnych komponentów. Poniżej znajduje się przykładowy diagram komponentów w UML.

46


Program doharmonogramów

Program planujący

Interfejsgraficzny

rezerwacje

aktualizacje

Przykładowy diagram komponentów


diagram modułów (module diagram) Diagram pokazujący zależności pomiędzy fizycznymi modułami oprogramowania; patrz diagram poniżej.

We/wyMenu

użytkownika

Dostęp do bazy danych

Interpreterkomend

Przykładowy diagram modułów

diagram obiektów (object diagram) Najczęściej to samo co diagram klas. Niekiedy tym terminem określa się diagram, w którym oprócz oznaczeń występujących na diagramie klas występują także oznaczenia konkretnych obiektów (zwykle przykładowych).

diagram pakietów (package diagram) Pakiety są zestawami klas wraz z zachodzącymi pomiędzy nimi zależnościami. Diagramy pakietów odwzorowują przekazywanie (import) informacji z pakietu do pakietu. Poniższy rysunek przedstawia

47


przykładowy diagram pakietów w UML dla systemu okienkowego włączającego pewien edytor.

Edytor

Elementy diagramówgraficznych

Elementy dziedzinyzastosowań

Sterownik

Rdzeń grafiki

Rdzeń grafiki Motif

Rdzeń grafiki Windows

Systemokienkowy

Motif

MS Windows

Przykładowy diagram pakietów


diagram procesów (process diagram) Diagram pokazujący strukturę i wzajemne zależności pomiędzy procesami; najczęściej jest to odmiana diagramu przepływu danych.

diagram przejść pomiędzy stanami (STD, State Transition Diagram) Patrz: diagram stanów.

diagram przepływu danych (data flow diagram, DFD) Diagram pokazujący związki pomiędzy wartościami wprowadzanymi, przetwarzanymi i wyprowadzanymi z systemu. Diagram przepływu danych nie zajmuje się czasem i zależnościami czasowymi; w większości, nie jest w nim istotne, jakie jest następstwo aktywności lub związek przyczynowo-skutkowy pomiędzy czynnościami. Diagram ten pokazuje zestaw modułów systemu ze wskazaniem, jakie informacje przepływają pomiędzy poszczególnymi modułami. Diagram zawiera cztery rodzaje oznaczeń: procesy, interfejsy zewnętrzne (aktorzy), składnice danych oraz strzałki pokazujące przepływ danych lub informacji. Istnieją bardziej rozbudowane wersje tych diagramów. Stanowią one podstawę metodyk analizy i projektowania określanych jako „strukturalne”. Poniżej znajduje się przykładowy diagram przepływu danych zapisany w notacji OMT.

48


PRZYJĘCIEZAMÓWIENIACZYTELNIKA

WERYFIKACJAZAMÓWIENIA

WYPOŻYCZENIEKSIĄŻKI

REJESTRACJACZYTELNIKA

CZYTELNIK

KARTOTEKA CZYTELNIKÓW

SPIS KSIĄŻEK

ZgłoszenieCzytelnika

Dane o Czytelniku

Dane osoboweo Czytelniku

Dane osoboweo Czytelniku

KartaCzytelnika

Konto Czytelnika

Dostępne Książki

Wydane Książki

Zapis wydanych Książek na konto

Dane ozamównieniu

Dane ozamówieniu

Odpowiedź dlaCzytelnika

WypożyczoneKsiążki

CZYTELNIK

Przykładowy diagram przepływu danych

diagram przepływu sterowania (control flow diagram, flowchart): Patrz: diagram stanów.

diagram przypadków użycia (use case diagram) Diagram pokazujący aktorów i przypadki użycia. Poniższy rysunek przedstawia diagram przypadków użycia dla pewnej firmy zajmującej się pośrednictwem w sprzedaży.

Ustalenie limitów

Analiza ryzyka

Sprawy cenowe

Przekroczenie limitów

Ocena zysków

Aktualizacja rozliczeń

Wyliczenieocen

Dyrektor handlowy

Handlowiec

Sprzedawca

Systemrozliczeniowy

«extends»

«uses»

«uses»

Przykładowy diagram przypadków użycia

Diagram przypadków użycia zawiera znaki graficzne oznaczające aktorów (ludziki) oraz przypadki użycia (owale z wpisanym tekstem). Te oznaczenia połączone są liniami i strzałkami odwzorowującymi powiązania poszczególnych aktorów z poszczególnymi

49


przypadkami użycia oraz przypadki użycia z innymi przypadkami użycia. Strzałki oznaczone «extends» prowadzą od przypadku użycia, który (w niektórych sytuacjach) rozszerza dany przypadek użycia. Strzałki oznaczone «uses» prowadzą do bloku ponownego użycia, czyli takiego przypadku użycia, który może być wykorzystany w wielu przypadkach użycia. Patrz też: przypadek użycia.

diagram rozprzestrzeniania (deployment diagram) Diagram pokazujący konfigurację elementów czasu wykonania: komponentów sprzętowych, komponentów oprogramowania, procesów oraz związanych z nimi obiektów. Komponenty, które nie istnieją w trakcie czasu wykonania, nie pojawiają się na tych diagramach. Diagram rozprzestrzeniania jest grafem, gdzie węzłami są elementy czasu wykonania połączone przez linie odwzorowujące ich połączenia komunikacyjne. Komponenty są połączone strzałkami wskazującymi komponent wykorzystywany przez dany komponent, patrz rysunek poniżej. Synonimy: diagram wdrożenia, diagram wdrożeniowy.

«baza danych»spotkaniaBD

AdminServer:KomputerHost

Program doharmonogramów rezerwacje

KomputerJacka:PC

Program planujący

Przykładowy diagram rozprzestrzeniania

diagram sekwencji (sequence diagram) Diagramy sekwencji posiadają dwa wymiary: wymiar pionowy reprezentuje czas, zaś wymiar poziomy reprezentuje klasy obiektów. Istotna jest kolejność pewnych zdarzeń, natomiast nie jest istotna rzeczywista miara czasu. Niekiedy (dla systemów uwarunkowanych czasowo) czas może być przedstawiony w pewnej mierzalnej skali. Niżej znajduje się prosty diagram sekwencji w UML.

sterowaniedzwoniący odbierający

podniesienie słuchawki

ton w słuchawce

wybór cyfry

łączenie

ton dzwonka uruchomienie dzwonka

podniesienie słuchawki

koniec tonu koniec dzwonienia

. . .

ab

c

dd’

{b - a < 1 sec.}

{c - b < 10 sec.}

Rozmowa jest łączona poprzez sieć{d’ - d < 5 sec.}

W tym punkcierozmówcy mogąrozmawiać

Przykładowy diagram sekwencji

50


Obiekty są zaznaczane w postaci prostokątów z wpisaną wewnątrz nazwą obiektu (klasy). Od każdego obiektu prowadzi linia reprezentująca „linię życia” obiektu. Na tych liniach zaznacza się momenty wysłania komunikatów przez dany obiekt do innego obiektu, w postaci strzałek prowadzących od jednej linii do innej linii.


diagram stanów (state diagram, state-machine diagram, statechart) Diagram, w którym węzłami są stany jakiegoś procesu (w sensie czynności, które są wykonywane przez ten proces), zaś krawędzie oznaczają przepływ sterowania (przejścia) pomiędzy tymi stanami. Diagram stanów jest rozwinięciem znanej koncepcji diagramów blokowych (flowcharts). W metodykach analizy i projektowania systemów informatycznych dość często występują diagramy stanów na różnych poziomach abstrakcji, gdzie poziom bardziej szczegółowy jest rozwinięciem poziomu bardziej abstrakcyjnego. Poniższy rysunek przedstawia przykładowy diagram stanów w UML dotyczący procedury zakupów dla pewnej firmy.

Akceptacja (przez prezesa)Rejestruj akcept. prezesa

Wniosek

Formularz wniosku

Akceptacja

Kierownik

Startujwystąpienie

procesu

Kierownik

Przygotuj info ozakupie

Pracownik

Info o zakupieutwórz

Przygotuj info o odrzuceniu

Pracownik

Akceptacja (przez dział finansowy)Rejestruj akcept. dzialu finansowego

Przygotuj info o akceptacjiPracownik

Pracownik

Pracownik

Zakup AND

Info o odrzuceniu

Info oakceptacji

dekretuj_na

utwórz

[zaakceptowany][odrzucony] [odrzucony]

[wątpliwości][zaakceptowany]

[odrzucony]

[koszt < 1000ECU]

[koszt >= 1000ECU]

[zaakceptowany]

utwórz

Przykładowy diagram stanów

Zwrócimy uwagę, że w środowisku komercyjnym występuje tendencja do utożsamiania terminów „diagram stanów” (state diagram) oraz „diagram przepływu sterowania” (flowchart). Np. w UML jest dość trudno wyróżnić merytorycznie stabilną podstawę do rozróżnienia pomiędzy tymi pojęciami. W związku z tym diagram stanów może mieć niewiele wspólnego z diagramami stanów rozpatrywanymi w teorii automatów. Ta homonimia lub uproszczenie często prowadzi do nieporozumień.


diagram struktury obiektów (object structure diagram) Patrz: diagram obiektów.

diagram tropów zdarzeń (event-trace diagram) Diagram pokazujący byty

51


wysyłające zdarzania, byty odbierające zdarzenia oraz kolejność zdarzeń. Inne określenia: diagram przepływu komunikatów, diagram interakcji, graf interakcji obiektów, diagram przepływu komunikatów, diagram sekwencji.

diagram zmiany stanów (state transition diagram, STD) Patrz: diagram stanów.

DII (Dynamic Invocation Interface) W OMG CORBA, interfejs do dynamicznych wołań operatorów (metod).

http://www.omg.org

dinozaur (dinosaur) Określenie niegdyś sławnej osoby, dzisiaj nieco zapomnianej; autora lub propagatora pewnej przestarzałej koncepcji. Również określenie przestarzałego systemu o monstrualnych rozmiarach (np. IMS).

Distributed Smalltalk Pośrednik wymiany obiektów (ORB) wg standardu OMG CORBA, rozwijany i rozpowszechniany przez firmę HP.

długa transakcja (long transaction) Transakcja, która trwa na tyle długo (np. tygodnie lub miesiące), że niedopuszczalna jest całkowita niedostępność zablokowanych przez nią zasobów. Długie transakcje wymagają osłabienia warunku izolacji; patrz: np. poziomy izolacji (isolation levels) w SQL. Również niekorzystną cechą staje się atomowość transakcji, gdyż w przypadku zerwania długiej transakcji może być niemożliwe, nieakceptowalne lub zbyt kosztowne przywrócenie stanu sprzed transakcji.

DML (Data Manipulation Language) Język manipulowania danymi. Początkowo terminem tym oznaczono podjęzyk do programowania aplikacji z bazą danych zaproponowany przez DBTG CODASYL w 1971 r. Wielu autorów używa akronimu DML na określenie dowolnego języka manipulowania danymi, np. SQL. W standardzie ODMG akronimu DML używa się na oznaczenie klas i funkcji języka programowania (np. C++), służących do wykonywania operacji na bazie danych.

DOE (Distributed Object Environment) Obiektowe środowisko rozwoju rozproszonych aplikacji firmy SunSoft.

DOME (Distributed Object Management Environment) Pośrednik (broker, ORB) wg standardu OMG CORBA.

DOMF (Distributed Object Management Facility) System zarządzania obiektami zgodny ze standardem OMG CORBA, część systemu DOE firmy SunSoft.

Domino 5.0 Następna wersja Lotus Notes (firmy IBM/Lotus), obiektowa, zintegrowana z IIOP wg standardu CORBA.

domyślny (default) Określenie pewnej wartości, atrybutu lub innego bytu, który jest wstawiany w pewne miejsce w sytuacji, gdy użytkownik lub program nie zapełnił go explicite. Np. wartość domyślna 0 może być wstawiana jako wartość początkowa nowo

52


utworzonej zmiennej typu integer. Podobnie, wartości domyślne mogą być wstawiane do pewnego wyniku (np. wyniku zapytania) jako substytut wartości NULL; np. jeżeli atrybut CzyPaliPapierosy dla obiektu Pracownik ma wartość NULL, wówczas wartością domyślną może być Nie.

DOOD (Deductive and Object-Oriented Databases) Dedukcyjne i obiektowe bazy danych. Cykliczna konferencja z zakresu obiektowości angażująca głównie środowiska akademickie.

DOOS (Designing Object-Oriented Software) Metodyka analizy i projektowania obiektowego, inaczej Wirfs-Brock. Faza początkowa metodyki włącza identyfikację klas, identyfikację odpowiedzialności oraz identyfikację współdziałania. Szczegółowa analiza zawiera identyfikację hierarchii, podsystemów i protokołów. Obiekty i klasy są traktowane jednakowo, zakłada się komunikację poprzez przesyłanie komunikatów, podsystemy traktuje się jako grupy klas. Metodyka jest przystosowana do analizy, ale nie jest uważana za dobrą do projektowania i implementacji. Jest ona oparta na intuicyjnej terminologii, niezbyt zgodnej z koncepcjami obiektowości.

dostęp asocjacyjny (associative access) Dostęp do danych poprzez nieproceduralne wyrażenia wysokiego poziomu, np. poprzez zapytania języka SQL lub OQL.

dostęp nawigacyjny (navigational access) Dostęp do danych poprzez wskaźniki reprezentujące powiązania lub asocjacje pomiędzy danymi. Najczęściej dostęp nawigacyjny jest wiązany z wyrażeniami ścieżkowymi lub kropkowymi, które umożliwiają bardzo przejrzyste zapisanie operacji przechodzenia od obiektów do obiektów zgodnie z powiązaniami wskaźnikowymi lub związkami asocjacji. Należy uprzedzić, że wielu autorów (nieprzychylnych obiektowości) używa terminu „dostęp nawigacyjny” w sensie pejoratywnym, uważając tę metodę dostępu za powrót do niesławnych czasów CODASYLu i nawigacji w sieciowej bazie danych przy pomocy prymitywnych, wadliwych mechanizmów bardzo niskiego (fizycznego) poziomu (języka DML). Tego rodzaju asocjację należy uważać za demagogię, ponieważ w obiektowych językach zapytań (np. w OQL) dostęp nawigacyjny jest realizowany przy pomocy mechanizmów wysokiego poziomu (pojęciowych, makroskopowych) nie odwołujących się do jakichkolwiek fizycznych własności struktur danych.

DPD Diagram Przepływu Danych. Patrz: diagram przepływu danych.

druga postać normalna (second normal form, 2NF): Relacja nie jest w drugiej formie normalnej, jeżeli jej klucz składa się z dwóch lub więcej atrybutów, i pewien nie-kluczowy atrybut znajduje się w zależności funkcjonalnej (functional dependency) od części klucza. Nie spełnienie warunku drugiej formy normalnej prowadzi do redundancji w danych i anomalii aktualizacyjnych. Z punktu widzenia projektanta bazy danych nie zachowanie drugiej formy normalnej jest rzadkim błędem, wobec czego to pojęcie nie odegrało istotnej roli w metodykach projektowania baz danych.

DSI (Dynamic Skeleton Interface) Termin OMG CORBA; DSI umożliwia dynamiczne przekazanie zlecenia do obiektu od strony serwera obiektów (podobnie do

53


szkieletu w zleceniach statycznych).http://www.omg.org

DSOM (Distributed Standard Object Model) Pośrednik (ORB) udostępniający i przetwarzający obiekty w systemach rozproszonych wg standardu CORBA; wytworzony i rozprowadzany przez IBM.

DSS (Decision Support System) System wspomagania decyzji.

duży obiekt binarny (Binary Large OBject, BLOB) Patrz: BLOB.

duży obiekt znakowy (Character Large OBject, CLOB) Patrz: CLOB.

dwufazowe blokowanie (two-phase locking, 2PL) Technika zapewniająca spójność przetwarzania transakcji, polegająca na tym, że każda transakcja zawiera dwie fazy: fazę wzrostu (growing), kiedy transakcja blokuje coraz więcej danych żadnej z nich nie odblokowując, oraz fazę potwierdzenia (commit), kiedy transakcja odblokowuje dane, nie blokując w tym czasie jakichkolwiek nowych danych. Dwufazowe blokowanie zapewnia szeregowalność (serializability), czyli brak niekorzystnych (prowadzących do niespójności) interferencji jednocześnie działających transakcji.

dwufazowe potwierdzenie (two-phase commit, 2PC) Technika przetwarzania transakcji w systemach rozproszonych. Przetwarzanie transakcji odbywa się w dwóch fazach: przetwarzanie (obliczenia i aktualizacje); potwierdzenie (commit), które oznacza fizyczne wprowadzenie aktualizacji do bazy

danych i odblokowanie danych dla innych transakcji.

Druga faza jest krytyczna z punktu widzenia niezawodności, gdyż awaria w tej fazie może oznaczać utratę spójności bazy danych lub przetwarzania. W systemach scentralizowanych zwykle nie zachodzi potrzeba dodatkowych zabezpieczeń drugiej fazy, gdyż potwierdzenie następuje szybko i prawdopodobieństwo awarii w tym czasie jest małe. Inaczej jest w systemach rozproszonych, gdzie aktualizacja i odblokowanie danych w odległych bazach danych jest związane z wymianą informacji poprzez zawodne łącza i węzły komputerowe. Dla transakcji realizowanej w systemie rozproszonym potwierdzenie wymaga specjalnego protokołu uzgodnień, który zapewniłby niezawodność i wydajność. Dwufazowe potwierdzenie jest jednym z najprostszych tego rodzaju protokołów. Załóżmy, że pewien klient realizuje rozproszoną transakcję przy pomocy odległych serwerów. W dwufazowym potwierdzeniu w pierwszej fazie serwery zgłaszają gotowość potwierdzenia, załączając do tego zgłoszenia informacje o danych, które należy zaktualizować (być może, w innych węzłach). W drugiej fazie, klient, po skompletowaniu wszystkich zgłoszeń potwierdzenia, wydaje komendy wykonania fizycznych aktualizacji jednocześnie do wszystkich serwerów, załączając do tych komend informacje o danych, które mają być zaktualizowane. Dwufazowe potwierdzenie stało się dość popularną techniką w relacyjnych bazach danych; z powodzeniem wprowadza się ją także w systemach obiektowych. Niektórzy specjaliści uważają dwufazowe potwierdzenie za zbyt

54


kosztowne; ich zdaniem tańszą alternatywą dla tej techniki są replikacje. Wadą dwufazowego potwierdzenia jest możliwość zablokowania klienta i serwerów przez jeden z nich, który z powodu awarii nie zgłasza gotowości potwierdzenia.

Program aplikacyjny klienta

SZBD klienta

1. Serwery wysyłają komunikaty “gotów “ do klienta.2. Po skompletowaniu wszystkich zgłoszeń klient wysyła komunikat “potwierdź” do wszystkich serwerów.Jeżeli nie nadejdą wszystkie zgłoszenia “gotów”, klient wysyłakomunikat “zerwij transakcję” do wszystkich serwerów.

SZBD serweraSZBD serwera SZBD serwerago

t ów

gotów gotówpotwierdź

potw

ierd

ź potwierdź

Dwufazowe potwierdzenie

Dylan Obiektowy język programowania firmy Apple.http://www.cambridge.apple.com/dylan/dylan.htmlhttp://legend.gwydion.cs.cmu.edu/

dylemat elipsy i koła (elipse/circle dilemma) Pozorny paradoks, który ma odbicie w obiektowej literaturze. Załóżmy, że klasa Elipsa jest zdefiniowana jako typ

typedef Elipsa = struct{ integer OśPozioma, integer OśPionowa };

gdzie OśPozioma i OśPionowa oznaczają szerokość i wysokość elipsy, zaś klasa Koło jest zdefiniowana jako typ

typedef Koło = struct{ integer OśPozioma };

gdzie OśPozioma oznacza zarówno szerokość jak i wysokość. Doświadczenie podpowiada, że koło jest podklasą elipsy. Formalnie jednak, elipsa jest podklasą koła, ponieważ ma więcej atrybutów.

Ten paradoks jest skutkiem formalistycznego potraktowania typów/klas i dziedziczenia, bez uwzględnienia modelowania pojęciowego. W modelowaniu pojęciowym jest niewłaściwe zastosowanie nazwy atrybutu OśPozioma dla klasy Koło; jest to wyłącznie skutek formalistycznej oszczędności nazw, nie uwzględniającej ich semantyki. Poprawna definicja wzajemnego stosunku tych klas oznacza konieczność dodatkowych zabiegów (np. wprowadzenia w podklasie Koło ograniczenia OśPozioma = OśPionowa, zmiany nazwy jednego z atrybutów na Średnica i/lub ograniczenie ilości cech dziedziczonych przez podklasę. Obecne języki takie jak C++ są jednak do tych zabiegów słabo przystosowane; stąd cały problem. Zwrócimy uwagę, że podobny problem wyniknie w stosunku pomiędzy klasami Osoba i Pacjent, jeżeli założymy, że dla potrzeb przychodni zdrowia pacjent nie musi posiadać wszystkich atrybutów osoby i

55


nie ma żadnych nowych atrybutów.

dynamiczna dyspozycja (dynamic dispatching) Wiązanie metod w czasie wykonania, synonim późnego wiązania.

dynamiczna klasyfikacja (dynamic classification) Dynamiczne przypisywanie obiektu do klasy, umożliwienie zmiany klasy obiektu.

dynamiczna kontrola typów (dynamic type checking, dynamic typing) Kontrola typów podczas czasu wykonania. Jest to kontrola znacznie mniej skuteczna od statycznej kontroli typów, gdyż wymaga przetestowania wszystkich możliwych przebiegów programu, co z reguły jest niemożliwe, zaś błąd typologiczny w fazie eksploatacji programu jest równie groźny jak dowolny inny błąd. Przykładem języka z dynamiczną kontrolą typów jest Smalltalk.

dynamiczny SQL (dynamic SQL) SQL pozwala na styl programowania, w którym programista przygotowuje zdania SQL w postaci ciągów znaków, np. poprzez konkatenację fragmentów tekstu pochodzących z różnych źródeł. Przygotowane zdania można natychmiast wykonać, wykorzystując instrukcję

execute immediate <ciąg znaków>

gdzie <ciąg znaków> jest tekstem zapytania. Ta technologia uzyskała nazwę programowania dynamicznego (dynamic programming). Programowanie dynamiczne jest szczególnie przydatne dla tzw. programowania generycznego (generic programming), tj. techniki pisania programów działających dla wielu baz danych, tablic, atrybutów, etc. Np. takim generycznym programem jest program przeglądania tablic, gdzie nazwa bazy danych i nazwa tablicy są wczytywane z klawiatury, zaś nazwy i typy atrybutów są dowolne i nieznane. Instrukcje oraz obiekty programistyczne języka SQL, które umożliwiają programowanie dynamiczne, noszą nazwę dynamicznego SQL. Instrukcja execute immediate nie jest wystarczająca dla zdania select, gdyż wymaga ono dodatkowych konstrukcji, dzięki którym wynik zwrócony przez to zdanie może być przekazany na zmienne języka-gospodarza. Z tego względu wprowadzono instrukcję describe, która rolą jest odzyskanie informacji o ilości, nazwach, typach, rozmiarach, etc. atrybutów tablicy zwracanej przez zdanie select. Ta informacja jest używana do dynamicznego zaalokowania zmiennych gospodarza (host variables) w obszarze zwanym heap. Kursory, aktualizacja, oraz zdania z parametrami są powodem dalszego mnożenia opcji językowych.

Dynamiczny SQL jest odmianą techniki znanej jako refleksja (reflection). W językach programowania ta technika ma nie najlepszą opinię, gdyż prowadzi do mało czytelnych, podatnych na błędy programów oraz utrudnia mocną kontrolę typów. Alternatywą dla niej jest polimorfizm typów; jednakże ten pomysł jest ciągle w strefie akademickich rozważań i prototypów.

dyskryminator [1] (discriminator) Atrybut, którego wartość umożliwia dynamiczne rozróżnienie pomiędzy poszczególnymi przypadkami unii lub wariantu. Patrz: unia.

dyskryminator [2] (discriminator) Cecha, zgodnie z którą następuje specjalizacja danej klasy na podklasy. Np. dla klasy Pojazd dyskryminatorem specjalizacji może być

56


Teren (pojazd naziemny, wodny, powietrzny) lub Rodzaj napędu (pojazd silnikowy, wiatrowy, pociągowy, itd.).

dyspozycja (dispatching) Możliwości językowe przewidziane w danym języku programowania dla realizacji polimorfizmu, przesłaniania i przeciążania. Chodzi o to, którą z metod o nazwie m należy wybrać, jeżeli obiekt otrzymał komunikat m(...). W koncepcji pojedynczej dyspozycji (single dispatching) (C++, Smalltalk) wybierana jest zawsze metoda znajdująca się „najbliżej” obiektu w sensie hierarchii dziedziczenia. W koncepcji wielokrotnej dyspozycji (multiple dispatching) (CLOS) wybór odbywa się na podobnej zasadzie, ale pomijane są te metody, dla których nie zgadza się liczba lub typ parametrów.

działanie (activity) Patrz: aktywność.

dziedziczenie (inheritance) Związek pomiędzy klasami obiektów określający przekazywanie cech (definicji atrybutów, metod, itd.) z nadklasy do jej podklas. Np. obiekt klasy Pracownik dziedziczy wszystkie własności (definicje atrybutów, metody) określone w ramach klasy Osoba. Dziedziczenie jest podstawowym mechanizmem sprzyjającym ponownemu użyciu. Istnieje wiele form dziedziczenia, wśród nich dziedziczenie oparte na klasach (class-based inheritance), dziedziczenie oparte na prototypach lub delegacja, dziedziczenie dynamiczne, wielokrotne dziedziczenie, itd. Poniższy rysunek przedstawia wyodrębnienie hierarchii dziedziczenia z dwóch klas, OSOBA i PRACOWNIK.

Klasaogólna

Klasawyspecjalizowana

PRACOWNIKNazwisko

ImięRokUrodzZarobekFirma

ZdjęcieWiek()

ZarobekNetto()ZmieńZarobek(...)

PRACOWNIKZarobekFirma

ZdjęcieZarobekNetto()

ZmieńZarobek(...)

Hierarchia dziedziczenia

OSOBANazwisko

ImięRokUrodz

Wiek()

OSOBANazwisko

ImięRokUrodz

Wiek()

Wyodrębnienie hierarchii dziedziczenia

dziedziczenie dynamiczne (dynamic inheritance) Dziedziczenie przez obiekt cech klas lub cech innych obiektów (np. ich stanu) podczas czasu wykonania; często powiązane z możliwością dynamicznej zmiany dziedziczonych cech lub dynamicznej zmiany przynależności obiektu do klasy. Dziedziczenie dynamiczne można osiągnąć wyłącznie w językach/systemach, gdzie klasa jest obywatelem pierwszej kategorii lub w językach/systemach opartych o koncepcję prototypu.

57


dziedziczenie implementacji (implementation inheritance) Sytuacja, w której podklasy danej klasy dziedziczą definicje znajdujące się w danej klasie, jak też korzystają z zaimplementowanych tam metod.

dziedziczenie interfejsu (interface inheritance) Sytuacja, w której można zdefiniować nowy interfejs (interfejs do obiektów podklasy) na podstawie danego interfejsu. Nie oznacza to jednak, że można automatycznie korzystać z metod zaimplementowanych w klasie określonej przez dany interfejs.

dziedziczenie oparte na klasach (class-based inheritance) Dziedziczenie, w którym wprowadza się klasy i hierarchię (lub inną strukturę) klas.

dziedziczenie pojedyncze (single inheritance) Patrz: pojedyncze dziedziczenie.

dziedziczenie statyczne (static inheritance) Dziedziczenie, które można rozstrzygnąć w czasie kompilacji.

dziedzina (domain) Zbiór wszystkich dopuszczalnych wartości pewnej zmiennej, atrybutu, kolumny relacji, itd. Np. dziedziną atrybutu Nazwisko może być zbiór niepustych stringów o długości co najwyżej 30 znaków.

dziedzina aplikacyjna (application domain) Obszar zastosowań danej aplikacji. Patrz: dziedzina problemu.

dziedzina biznesu (business domain) Patrz: dziedzina problemu.

dziedzina problemu (problem domain) Fragment świata rzeczywistego będący przedmiotem rozważań przy analizie i projektowaniu; środowisko biznesu, w stosunku do którego rozważana jest dana aplikacja. Pojęcie dziedziny problemu jest zbliżone lub synonimiczne do dziedziny aplikacyjnej, dziedziny biznesu, przedmiotu rozważań (universe of discourse, UoD).

dzielony (shared) Zwykle chodzi o pewne zasoby (np. bazę danych), które są dzielone pomiędzy wielu użytkowników lub procesów, lub o pewne byty programistyczne, które są wspólne dla innych bytów programistycznych. Np. atrybut klasy „jest dzielony” pomiędzy obiekty będące jej wystąpieniami.

dziennik (log) Plik, na którym zapisuje się zmiany w bazie danych od momentu ostatniego jej składowania (back up) lub zmiany powodowane przez transakcję. Plik ten umożliwia odtworzenie (recovery) lub odwrócenie (roll-back) stanu bazy danych w przypadkach awarii lub zerwania transakcji.

EE

E Rozszerzenie C++ o typy właściwe dla baz danych oraz obiekty trwałe. E jest

58


mocnym i elastycznym językiem programowania baz danych zrealizowanym w eksperymentalnym SZBD Exodus.

http://www.cs.wisc.edu/exodus/

ECA (Event-Condition-Action) Patrz: zdarzenie-warunek-akcja, aktywne reguły.

ECOOP (European Conference on Object-Oriented Programming) Coroczna europejska konferencja nt. programowania obiektowego.

EER (Extended Entity-Relationship) Rozszerzony model encja-związek.

efekt uboczny (side effect) Zmiana stanu powodowana przez funkcję programistyczną, np. aktualizacja zmiennych globalnych, aktualizacja bazy danych, nowy zapis na logu, wysłanie komunikatu o błędzie na ekran, itd.

Eiffel Obiektowy język programowania opracowany i rozwijany przez B. Meyera. Zdaniem jego twórcy, jest specjalnie przystosowany do specyfikacji, projektowania, implementacji i modyfikacji dużych aplikacji i komponentów ponownego użycia. Eiffel posiada klasy, wielokrotne dziedziczenie, klasy abstrakcyjne (określane deferred), klasy parametryzowane (poprzez typ) oraz grona (clusters) klas. Obiekty mogą mieć typy statyczne i dynamiczne. Wiązanie dynamiczne umożliwia rozstrzyganie konfliktów nazw przy wielodziedziczeniu. Innymi cechami języka Eiffel są trwałe obiekty, zbieranie nieużytków, obsługa wyjątków i interfejsy do innych języków. Klasy mogą być wyposażone w asercje (warunki wstępne (preconditions), warunki końcowe (postconditions) oraz inwarianty klasowe), które wspomagają paradygmat określany jako „projektowanie poprzez kontrakty” (Design by Contracts) przyczyniający się do produkcji bardziej niezawodnego oprogramowania. Wynikowy kod produkowany przez kompilator języka Eiffel jest zapisany w C. Eiffel jest wyposażony w ogromną bibliotekę klas: struktury danych i algorytmy (EiffelBase), grafika i interfejsy użytkownika (EiffelVision), analiza językowa (EiffelLex, EiffelParse), i inne. Istnieje wersja języka Eiffel przetwarzająca rozproszone obiekty (Distributed Eiffel).

http://www.eiffel.comhttp://hepunx.rl.ac.uk/atlas/oo/eiffel/intro.htmlhttp://www.cm.cf.ac.uk/CLE/index.htmlhttp://outback.eiffel.com/eiffel/index.htmlhttp://www.sigs.com/publications/docs/oc/9604/oc9604.c.meyer.htmlhttp://www.progsoc.uts.edu.au/~geldridg/

EIS (Executive Information Systems) Określenie klasy systemów wspomagających kierowanie i zarządzanie.

eklektyczny (eclectic) Określenie (z lekkim odcieniem pejoratywnym) czegoś, co powstało w wyniku dość przypadkowej kombinacji dwóch lub więcej niezbyt spójnych koncepcji lub stylów. Np. eklektyczny jest C++, ponieważ łączy programowanie obiektowe z konstrukcjami niskiego poziomu, eklektyczny jest SQL3, ponieważ wtłoczono do niego zbyt wiele różnych (często nadmiarowych i niespójnych) opcji, eklektyczne są systemy obiektowo-relacyjne, ponieważ łączą własności odnoszące się

59


do relacji i obiektów, itd.

eksploracja danych (data mining) Odkrywanie nieoczywistych związków wewnątrz dużych zbiorów danych, poszukiwanie pewnych tendencji, zależności lub anomalii w danych i wyciągania z nich wniosków mających znaczenie jako wspomaganie dla podejmowanych decyzji. Eksploracja danych ma duże znaczenie w planowaniu biznesu, oraz kierowaniu i zarządzaniu biznesem. Podstawowymi technikami eksploracji danych jest analiza statystyczna, różne środki agregacji i wizualizacji danych, środki językowe (np. języki zapytań) mające na celu łatwiejsze sformułowanie nietrywialnych hipotez oraz automatyczną ich weryfikację. Podstawowy nurt w eksploracji danych wiąże się z technologiami określanymi jako hurtownie danych (data warehouses), OLAP i kostka danych (data cube), która reprezentuje dane w postaci wieloargumentowej funkcji (przestrzeni wielowymiarowej). Innym nurtem są techniki eksploracji danych oparte na przetwarzaniu danych półstrukturalnych.

eksport (export) Określenie faktu udostępnienia niektórych cech pewnego bytu programistycznego (modułu, klasy, obiektu, itd.) dla innych bytów.

ekstensja (extent, extension) Zestaw aktualnie istniejących obiektów danej klasy. Zwykle ten termin oznacza specjalną strukturę danych skojarzoną z daną klasą, której zadaniem jest przechowywanie wszystkich obiektów będących wystąpieniami tej klasy. Filozofia ta jest uważana za atawizm, kontynuację koncepcji modelu relacyjnego, gdzie deklaracja typu tablicy (relacji) była nierozerwalnie związana z utworzeniem samej tablicy. Dla każdej deklaracji typu w schemacie relacyjnej bazy danych istniała dokładnie jedna tablica przechowywana w bazie danych. Wielu specjalistów postulowało rozdzielenie tych dwóch deklaracji. Postulat uniezależnienia deklaracji typów/klas i odpowiadających im obiektów staje się aktualny w przypadku obiektowości, której filozofią jest dekompozycja pojęć oraz ortogonalna ich kombinacja. Pojęcie ekstensji staje się semantycznie mało spójne w przypadku klas abstrakcyjnych.

ekstensja klasy (class extent) Patrz: ekstensja.

ekstensja typu (type extent) Zbiór (zwykle bardzo duży) wszystkich wartości, które są zgodne z danym typem. Np. ekstensją typu integer jest zbiór wszystkich liczb całkowitych. W niektórych propozycjach typ utożsamia się z klasą i wówczas ekstensja typu może znaczyć to samo, co ekstensja klasy.

elastyczność (flexibility) Łatwość, z jaką dane oprogramowanie może być przystosowane do nowych funkcji.

element pochodny (derived element) Element (wartość, obiekt, związek, itd.), który można wydedukować, wyznaczyć lub obliczyć z innych elementów.

Emerald Obiektowy język programowania specjalnie przystosowany do rozwijania rozproszonych aplikacji; zrealizowany na Uniwersytecie w Waszyngtonie. Posiada mocną kontrolę typów i jest oparty o koncepcję prototypów.

60


encja (entity) Pojęcie z modelu encja-związek, oznaczające konkretny lub abstrakcyjny byt wyróżnialny w modelowanej rzeczywistości. W odróżnieniu od obiektu, encja nie jest kojarzona z metodami. Patrz: model encja-związek.

encja-związek (entity-relationship, ER) Model pojęciowy, techniki i notacja, służące jako środek do opisu rzeczywistości w projektowaniu baz danych (szczególnie relacyjnych), zaproponowany przez P. Chena. Patrz: model encja-związek.

Encore Eksperymentalny obiektowy system zarządzania bazą danych zbudowany na Brown University, USA.

enkapsulacja (encapsulation) Patrz: hermetyzacja.

ER (Entity-Relationship) Patrz: model encja-związek.

ERD (Entity-Relationship Diagram) Patrz: diagram encja-związek.

ERM (Entity-Relationship Model) Patrz: model encja-związek.

EROOS (Entity-Relationship Object-Oriented Specification) Obiektowa metodyka analizy i projektowania systemów informatycznych opracowana na Katolickim Uniwersytecie w Leuven, Belgia. Metodyka przewiduje podstawowe bloki konstrukcji projektu dla każdego z następujących podstawowych pojęć: obiekty i klasy, relacje, atrybuty, więzy integralności i trygery oraz zapytania.

http://www.cs.kuleuven.ac.be/cwis/research/som/EROOS/

ESIOP (Environment-Specific Inter-ORB Protocols) Termin OMG CORBA; protokół wymiany informacji pomiędzy pośrednikami (ORB), specyficzny dla danej aplikacji lub dziedziny zastosowań; np. bazujący na OSF DCE RPC.

http://www.omg.org

ewolucja schematu (schema evolution) Temat badawczo-rozwojowy zmierzający do opracowania środków umożliwiających radykalne zmiany schematu bazy danych w trakcie eksploatacji systemu. Po wieloletniej eksploatacji systemu zwykle pojawiają się nowe wymagania i okoliczności związane z bazą danych. Z drugiej strony, możliwości w zakresie zmiany schematu bazy danych są ograniczone przez już przechowywane dane, istniejące programy aplikacyjne i rutynowe procesy obsługi i użytkowania systemu. Bardziej istotna zmiana schematu oznacza więc nie tylko zmianę postaci danych, lecz także zmianę wielu programów aplikacyjnych oraz niekiedy organizacji pracy. Temat ten jest więc bardzo trudny i wymaga opracowania szeregu metod technicznych i organizacyjnych pozwalających na osiągnięcie wymaganego efektu przy minimalizacji kosztów i okresu niestabilnej pracy systemu.

Exodus Eksperymentalny obiektowy system zarządzania bazą danych zbudowany na Uniwersytecie w Wisconsin, USA.

http://www.cs.wisc.edu/exodus/

61


Expertsoft Pośrednik (broker, ORB) wg standardu OMG CORBA.

Express Język do zapisu obiektowego schematu pojęciowego. Express jest wynikiem prac standardyzacyjnych ISO (dokumenty ISO/DIS 10303-11, ISO/CD 10302-22).

FF

fabryka (factory) Zestaw metod, operatorów lub instrukcji służący do tworzenia obiektów.

FAQ (Frequently Asked Questions) Często zadawane pytania. Strony WWW lub pliki tekstowe zawierające wyjaśnienia dotyczące różnych tematów, w szczególności obiektowości, publikacje lub informacje o publikacjach, oraz połączenia (links) do innych stron WWW. Wadą połączeń jest ich mała stabilność, ale niemniej można próbować:

http://cuiwww.unige.ch/langlist/http://cuiwww.unige.ch/OSG/OOinfo/index.htmlhttp://iamwww.unibe.ch/~scg/OOinfo/FAQ/index.htmlhttp://info.gte.com/ftp/doc/activities/x3h7.htmlhttp://morannon.fido.de/~mj/links/l_oo.htmlhttp://swss00.isbe.ch/~bach/oo.htmlhttp://wombat.doc.ic.ac.uk/http://www.aisys.com/objectGate/people/ooFolk.htmlhttp://www.cera.com/object.htmhttp://www.cetus-links.org/http://www.clark.net/pub/howie/OO/oo_home.htmlhttp://www.cyberdyne-object-sys.com/oofaq/http://www.enteract.com/~bradapp/links/oo-links.html#OOhttp://www.fokus.gmd.de/ovma/dooos/http://www.mtjeff.com/~calvin/devhbook/objectori.htmlhttp://www.next-objects.com/ooanluc.htmhttp://www.next-objects.com/ooanly/index.htmhttp://www.next-objects.com/tutpage.htmhttp://www.objfocus.com/object.htmlhttp://www.odbmsfacts.com/http://www.planet.net/bwalker/oo.htmlhttp://www.rai.com/soft_eng/indexes/oop.htmlhttp://www.rhein-neckar.de/~cetus/oo_entry.htmlhttp://www.sigs.com/resources.htmlhttp://www.sigs.com/omo/dot/index.htmlhttp://www.soft-design.com/softinfo/objects.htmlhttp://www.tiac.net/users/chasb/c-ot.htmlhttp://www.tiac.net/users/jsuth

62


http://www.toa.com/shnn?htmldocshttp://www.toa.com/shnn?onlinedocshttp://www.well.com/user/ritchie/oo.htmlhttp://zgdv.igd.fhg.de/papers/se/oop/

fasolka (bean) Komponent łączony poprzez architekturę komponentową JavaBeans. Termin jest również używany w bardziej ogólnym sensie jako synonim komponentu.

faza strategiczna (strategic phase) Patrz: studium osiągalności.

federacyjna baza danych (federated database) Podejście do rozproszonych baz danych, w którym każda lokalna baza danych zachowuje swoją autonomię (autonomy), udostępniając tylko część danych i/lub ograniczając operacje na danych dla innych miejsc w rozproszonej bazie danych. Podejście federacyjne zakłada, że każda lokalna baza danych jest widziana poprzez pewną perspektywę (view) lub podschemat (subschema), który ukrywa niektóre dane tak, że nie są one widoczne lub niemożliwe są na nich pewne operacje z zewnątrz.

Fibonacci Eksperymentalny obiektowy język programowania baz danych z trwałością, polimorfizmem typów i rolami, opracowany na uniwersytecie w Pizie, Włochy; następca języka Galileo.

F-logic Koncepcja teoretyczna zaproponowana przez Kifera i Lausena dotycząca formalnego opisu semantyki języków zapytań dla obiektowych baz danych, oparta o rozszerzoną logikę matematyczną.

format stały (fixed format) Fizyczny format obiektu, który nie ulega zmianie przy zmianach stanu obiektu; format jednakowy dla wszystkich obiektów danej klasy; format znany w czasie kompilacji; format, w którym wartości atrybutów mają ustalone przesunięcie (offset) względem początku obiektu. Przeciwieństwo: format zmienny.

format wymiany (exchange format) Konwencja syntaktyczna i semantyczna lub pewien protokół umożliwiający wymianę obiektów (lub innej informacji) pomiędzy różnymi platformami lub implementacjami. Format wymiany obiektów jest składową standardu ODMG.

format zmienny (variable format) Fizyczny format obiektu, który może ulec zmianie przy zmianach stanu obiektu; format nie ustalający rozmiaru obiektu; format nieznany w czasie kompilacji; format, w którym wartości atrybutów nie mają ustalonego przesunięcia (offset) względem początku obiektu. Przeciwieństwo: format stały.

formularz (form) Określenie środka wizualnego pojawiającego się w graficznym interfejsie użytkownika, służącego do wprowadzania i wyprowadzania danych. Formularz składa się z tła (tj. informacji stałej), widżetów (np. przycisków), oraz z pewnej ilości pól tekstowych, numerycznych lub graficznych, które są zapełniane przez użytkownika lub przez system w trybie interakcyjnym.

63


FP (Function Point) Punkt funkcyjny. Patrz: analiza punktów funkcyjnych.

FPA (Function Point Analysis) Patrz: analiza punktów funkcyjnych.

Fresco [1] Obiektowe API dla graficznych interfejsów użytkownika, rozwijane przez Konsorcjum X jako otwarty standard dla wielu dostawców.

http://www-comp.mpce.mq.edu.au/~mpole/fresco/fresco.htmlhttp://nucleus.hut.fi/~jorma/fresco/faslab/fresco/FAQ.html

Fresco [2] Obiektowy język do specyfikacji oprogramowania.

funkcja (function) Nazwana operacja lub nazwany kod, która zwraca pewną wartość (w odróżnieniu od procedury). Pojęcie funkcji w programowaniu różni się od pojęcia funkcji w matematyce, gdyż pierwsza z nich może mieć efekty uboczne (może zmienić stan) oraz może być uzależniona od pewnych elementów środowiska programistycznego (zmiennych globalnych, zmiennych środowiskowych, czasu, itd.). Również semantyka parametrów funkcji programistycznych i funkcji matematycznych jest traktowana odmiennie (patrz: przekazywanie parametrów).

funkcja członkowska (member function) Termin C++ określający funkcję zdefiniowaną w ramach klasy. Synonim: metoda.

funkcja generyczna (generic function) Funkcja, która może działać na argumentach (lub obiektach) wielu typów, funkcja polimorficzna, funkcja wirtualna. Przykładem może być funkcja count wyznaczające liczbę krotek w tablicy niezależnie od jej typu.

funkcja mieszająca (hash function) Funkcja, której argumentem jest pewna wartość przechowywana wewnątrz obiektu (np. nazwisko), zaś wynikiem jest liczba naturalna, zwykle używana jako podstawa określenia adresu przechowywania tego obiektu. Funkcje mieszające są elementem metody organizacji zbiorów danych lub obiektów określanej jako kodowanie mieszające (hash coding) lub tablice z kodowaniem mieszającym (hash tables). Zaletą tych organizacji jest bardzo szybki dostęp do danych na podstawie znajomości wartości będącej argumentem funkcji mieszającej. Wadą metody jest występowanie konfliktów (identycznych wartości funkcji dla różnych wartości argumentów), wskutek których organizacja tablic mieszających oraz algorytmy lokowania i odszukiwania obiektów stają się niekiedy bardzo złożone. Inną wadą tej metody jest to, że jest ona nastawiona na wyszukiwanie wg jednego aspektu i jest nieefektywna o ile wyszukiwanie dotyczy innego aspektu (np. zarobku). Metody oparte na funkcjach mieszających znalazły zastosowanie jako środek organizacji indeksów oraz jako środek implementacji operacji złączenia (join) w relacyjnych bazach danych.

funkcja wirtualna (virtual function) Funkcja, która jest wiązana dynamicznie (późne wiązanie); może ona być dziedziczona przez podklasy oraz może być przesłonięta w pewnej podklasie przez inną funkcję o tej samej nazwie. Synonim: metoda.

funkcja wyższego rzędu (higher-order function) Funkcja, której parametrem może

64


być funkcja (ogólniej: procedura). Np. funkcją wyższego rzędu jest procedura sortująca dowolny zbiór, gdzie parametrem jest funkcja porównująca dwa elementy zbioru. Funkcje wyższego rzędu są często potrzebne do definiowania klas abstrakcyjnych; są one także własnością wielu języków polimorficznych. W związku z funkcjami wyższego rzędu wprowadzane są także takie pojęcia, jak programowanie wyższego rzędu (higher-order programming), programowanie obiektowe wyższego rzędu (higher-order object-oriented programming) i inne.

funkcja zagregowana (aggregate function) Funkcja działająca na wartości typu masowego i zwracająca pojedynczą liczbę, np. count (liczba elementów zbioru, wielozbioru lub sekwencji), sum (suma arytmetyczna wartości zbioru, wielozbioru lub sekwencji wartości numerycznych), avg (średnia arytmetyczna wartości zbioru, wielozbioru lub sekwencji wartości numerycznych), max/min (maksymalna/minimalna wartość ze zbioru, wielozbioru lub sekwencji wartości numerycznych). Podane pięć funkcji zostało wbudowane w SQL i OQL. Oprócz nich można sobie wyobrazić bardzo wiele innych użytecznych funkcji zagregowanych, np. mediana, średnia geometryczna, średnia harmoniczna, odchylenie standardowe, itd. Na ogół języki zapytań (poza SBQL zaimplementowanym w systemie Loqis) nie dają możliwości definiowania nowych funkcji zagregowanych.

funkcja zaprzyjaźniona (friend function) Termin C++ oznaczający funkcję zewnętrzną, której implementacja odwołuje się do ukrytych (prywatnych) własności pewnej (zaprzyjaźnionej) klasy.

Fusion Obiektowa metodyka rozwoju oprogramowania opracowana przez D. Colemana i innych w firmie HP Laboratories. Fusion zapewnia systematyczne podejście do rozwijania obiektowego oprogramowania. Twórcy uważają ją za metodykę obiektową „drugiej generacji”, ponieważ jest ona całkowicie zintegrowana i rozszerza istniejące podejścia celem objęcia pełnego cyklu projektowego, od zdefiniowania wymagań do implementacji w konkretnym języku programowania.

http://www.hpl.hp.com/fusionhttp://arkhp1.kek.jp/managers/computing/activities/OO_CollectInfor/

Methodologies/Fusion/fusionBook/fusionBookContents.html

GG

GC (garbage collector) Patrz: zbieranie nieużytków.

GCC Popularny kompilator C, C++ i Objective C wyprodukowany przez konsorcjum GNU.

GemORB Pośrednik (broker, ORB) wg standardu OMG CORBA; wbudowany w system Gemstone (SmalltalkBroker, DNS Technologies).

http://www.gemstone.com/products/products_main.html

65


Gemstone, GemStone Jeden z pierwszych (1985) obiektowych systemów zarządzania bazą danych oparty na koncepcji języka Smalltalk i zrealizowany przez Gemstone Systems, Inc.

http://www.gemstone.com/products/products_main.html

generalium (l.mn. generalia) (generics) Określenie niektórych języków programowania (np. Modula-3) oznaczające parametryzowany zestaw obiektów, klas, modułów, itp. Synonimem jest termin szablon (template) lub klasa parametryzowana.

generalizacja (generalization, is-a relationship) Abstrakcja dotycząca danych lub obiektów. Termin jest używany w dwóch podobnych znaczeniach: (1) Generalizacja oznacza relację pomiędzy daną klasą i jej klasą nadrzędną. np. generalizacją klasy Student jest klasa Osoba. (2) Generalizacja oznacza utworzenie nowej nadklasy z jednej lub więcej danych klas. Np. mając klasy Student i Pracownik generalizacją będzie utworzenie nowej klasy Osoba. Przeciwieństwem generalizacji jest specjalizacja.

generator aplikacji (application generator) Oprogramowanie (zwykle część pewnego narzędzia CASE) umożliwiające wygenerowanie gotowej aplikacji na podstawie zadanych parametrów i/lub diagramów wyprodukowanych w fazie projektowania. Należy zwrócić uwagę, że nadzieje pokładane w generatorach aplikacji są zwykle znacznie przesadzone w stosunku do ich możliwości i jakości wyprodukowanego kodu.

generyczna funkcja (generic function) Patrz: funkcja generyczna.

generyczne programowanie (generic programming) Patrz: programowanie generyczne.

generyczny (generic) Określenie procedury, funkcji, klasy lub techniki programowania, która może być użyta w szerokim obszarze zastosowań, akceptuje różne typy argumentów, rodzaj przetwarzanych danych, kontekst aplikacyjny, itd. Np. generycznych procedur wymaga interfejs umożliwiający przeglądanie dowolnej relacyjnej bazy danych, generyczną jest funkcja zwracająca rozmiar zbioru elementów dowolnego typu, generyczny jest analizator leksykalny, który można zastosować do wielu języków, generyczny jest program, który jest w stanie wykonać dowolne zapytanie w SQL wczytane z klawiatury, itd. Patrz też: programowanie generyczne.

gigabajt (gigabyte) W powszechnym rozumieniu - 1 000 000 000 (miliard) bajtów. W informatyce obowiązuje atawistyczny stereotyp, zgodnie z którym gigabajt jest to 230, czyli 1 073 741 824 bajtów.

GIGO (Garbage In - Garbage Out) Śmiecie na wejściu - śmiecie na wyjściu. Jedno z najstarszych praw informatycznych. Np. śmiecie wyprodukowane przez fazę określania wymagań zaowocują śmieciami wyprodukowanymi w fazie projektowania. GIGO może być argumentem informatyka w odpowiedzi na narzekania klienta lub użytkownika, że system nie robi tego co powinien.

66


GIOP (General Inter-ORB Protocol) Protokół transportowy proponowany w standardzie OMG CORBA dotyczący wymiany informacji pomiędzy poszczególnymi pakietami ORB. GIOP specyfikuje format komunikatów i zezwala na wiele zleceń w jednym połączeniu.

http://www.omg.org

GIS (Geographic Information System) Patrz: system informacji geograficznej.

globalna zmienna (global variable) Patrz: zmienna globalna.

GNU E Obiektowy język programowania baz danych; rozszerzenie C++, zrealizowany w projekcie Exodus. Patrz: E.

GOF (Gang Of Four) Banda czworga; żartobliwe określenie czwórki autorów popularyzujących wzorce projektowe (design patterns): E. Gamma, R. Helm, R. Johnson, J. Vlissides.

Goldberg, Adele Twórczyni języka Smalltalk. A. Goldberg wniosła również wkład w metodyki obiektowe i zarządzanie projektami obiektowymi.

http://www.parcplace.com

graf dziedziczenia (inheritance graph) Graf zależności pomiędzy klasami ustalający kierunek dziedziczenia (generalizacji/specjalizacji, is-a). W przypadku pojedynczego dziedziczenia graf przyjmuje postać drzewa. W przypadku wielodziedziczenia graf jest pewną strukturą bez pętli, zwaną acyklicznym grafem skierowanym lub półkratą.

grono (cluster) Pojęcie odnoszące się do fizycznej implementacji obiektów, oznaczające grupę obiektów, które ze względu na wydajność warto przechowywać blisko siebie na dysku i wspólnie kopiować do bufora w pamięci operacyjnej. Synonim: klaster.

grupa (komitet) zarządzania obiektami (Object Management Group, OMG) Patrz: OMG.

grupa (komitet) zarządzania obiektową bazą danych (Object Database Management Group, ODMG) Patrz: ODMG.

grupa (komitet) zarządzania obiektowymi danymi (Object Data Management Group, ODMG) Patrz: ODMG.

GUI (Graphical User Interface) Graficzny interfejs użytkownika. Ogólna nazwa interfejsu graficznego o własnościach zbliżonych do Microsoft Windows. Podobnym narzędziem dla platform UNIXa jest OSF/Motif. Standardem stały się belki z ikonami i rozwijalne w dół menu (zapoczątkowane w Apple Macintosh).

HH

67


HAD (Heterogeneous, Autonomous, Distributed) Heterogeniczna, autonomiczna, rozproszona. Określenie rodzaju aplikacji, która operuje na heterogenicznych zasobach, respektuje autonomię lokalnych systemów, oraz działa na zasobach oddalonych geograficznie.

Henderson-Sellers, Brian. Aktywny metodolog, twórca metodyk MOSES i OPEN.

hermetyzacja (encapsulation) Zamknięcie pewnego zestawu bytów programistycznych w „kapsułę” o dobrze określonych granicach; oddzielenie abstrakcyjnej specyfikacji tej kapsuły (obiektu, klasy, modułu, etc.) od jej implementacji; ukrycie części informacji zawartej w tej kapsule dla operacji z zewnątrz obiektu. Hermetyzacja jest podstawową techniką abstrakcji, tj. ukrycia wszelkich szczegółów danego przedmiotu lub bytu programistycznego, które na danym etapie rozpatrywania (analizy, projektowania, programowania) nie stanowią jego istotnej charakterystyki. Hermetyzacja jest starą zasadą inżynierii oprogramowania (sformułował ją D. Parnas w 1975 r.) i znalazła swoje odbicie w takich pojęciach programistycznych jak moduł, abstrakcyjny typ danych i obiekt/klasa (co za tym idzie, niektórzy autorzy wyróżniają trzy rodzaje hermetyzacji).

W obiektowości dość popularnym stereotypem jest koncepcja ortodoksyjnej hermetyzacji (Smalltalk), w której wszelkie operacje, które można wykonać na obiekcie, są określone przez metody przypisane do obiektu (znajdujące się w jego klasie i nadklasach); bezpośredni dostęp do atrybutów obiektu jest niemożliwy. Oznacza to często, że każdy atrybut obiektu musi być wyposażony w dwie metody: CzytajWartość i ZmieńWartość; takie założenie przyjmuje np. standard CORBA. Alternatywą jest hermetyzacja ortogonalna (C++, Eiffel), gdzie dowolny atrybut obiektu (i dowolna metoda) może być prywatny (niedostępny z zewnątrz) lub publiczny. Atrybut publiczny może być obsłużony przez operatory generyczne, takie jak odzyskanie referencji do atrybutu (czyli wiązanie), podstawienie i dereferencja. Zwolennicy ortodoksyjnej hermetyzacji argumentują, że zapewnia ona rzekomo brak możliwości zrobienia na obiektach danej klasy czegokolwiek, co nie zostało przewidziane przez projektanta tej klasy. Tę argumentację łatwo obalić, gdyż udostępnienie atrybutu poprzez metody CzytajWartość i ZmieńWartość jest semantycznie równoważne udostępnieniu danego atrybutu do przetwarzania poprzez w/w operatory generyczne.

Ortodoksyjna hermetyzacja jest ponadto semantycznie i koncepcyjnie niespójna, jeżeli założymy, że atrybuty mogą być powtarzalne, czyli mogą być kolekcjami o nieznanym i nieograniczonym rozmiarze; np. atrybut WypożyczoneKsiążki dla obiektów Student. W takich przypadkach zwolennicy ortodoksyjnej hermetyzacji sugerują, że potrzebne są metody takie jak DajPierwszy, DajNastępny, CzyOstatni (zaimplementowane np. w postaci iteratora). W takim przypadku powstaje pytanie, co mają zwrócić metody DajPierwszy i DajNastępny. Odpowiedź na to pytanie jest prosta: muszą one zwrócić referencje do (kolejnych) wartości tego atrybutu. Udostępnienie tych referencji na zewnątrz oznacza wyłom w koncepcji ortodoksyjnej hermetyzacji; np. takie referencje mogą być użyte w operacji podstawienia, przekazane jako call-by-reference parametr do procedury, itd. Dodatkowo, schemat iteracyjny DajPierwszy,

68


DajNastępny, CzyOstatni (lub podobny) ustala określony porządek przetwarzania elementów, co oznacza, że kolekcje takie jak zbiory i wielozbiory stają się fikcją (oraz związane z nimi ewentualne metody optymalizacyjne). Poważnym argumentem na niekorzyść ortodoksyjnej hermetyzacji są języki zapytań, których semantyka bazuje na bezpośrednim wiązaniu nazw występujących w zapytaniu z wartościami atrybutów. Z tego względu C.J.Date uważa, że koncepcja hermetyzacji powinna być w ogóle odrzucona. Date w swoich wnioskach idzie za daleko; wystarczy bowiem zrezygnować z ortodoksyjnej hermetyzacji na rzecz hermetyzacji ortogonalnej, takiej, jak w C++, Eiffel, Modula-2, i innych językach (czyli wrócić do oryginalnego pomysłu D.Parnasa). Hermetyzacja ortogonalna nie prowadzi do jakichkolwiek sprzeczności z językami zapytań. Poniższy rysunek jest ilustracją hermetyzacji ortogonalnej.

PRACOWNIK

NAZWISKO Nowak ROK_UR 1951

ZAROBEK 2500

ZmieńZarobek(...) {...};

Podatek(){...};ZarobekNetto() {...};

Wiek() { return RokBież - ROK_UR };

DZIAŁ Zabawki

Wewnętrzna struktura obiektu Zewnętrzna struktura obiektu

PRACOWNIK

NAZWISKO Nowak

ZmieńZarobek(...)

ZarobekNetto()

Wiek()

DZIAŁ Zabawki

Hermetyzacja: wewnętrzna i zewnętrzna struktura obiektu

heterogeniczna baza dana (heterogeneous database) Baza danych, której fragmenty są podtrzymywane przez różne SZBD, niekiedy na różnych platformach sprzętowych. Heterogeniczne bazy danych są przedmiotem kierunku określanego jako współdziałanie (interoperability). Problemy dotyczące heterogenicznej bazy danych są związane z opracowaniem wspólnej wizji danych, wspólnych jednorodnych środków dostępu do danych, oraz zasad federacji baz danych zapewniających lokalnym bazom danych autonomię lokalnych operacji.

heterogeniczny (heterogeneous) Niejednorodny, niekompatybilny.

heterogeniczny, autonomiczny, rozproszony (Heterogeneous, Autonomous, Distributed, HAD) Określenie problemu lub technologii, której celem jest połączenie w ramach jednej aplikacji systemów, które są geograficznie rozproszone, autonomiczne (realizujące własne funkcje nie udostępniane publicznie, niemodyfikowalne z punktu widzenia celów zintegrowanego systemu) oraz heterogeniczne, czyli niejednorodne, posiadające różne organizacje danych i środki dostępu. Patrz też: współdziałanie.

hierarchia agregacji (aggregation hierarchy) Hierarchia związków całość-część, np. hierarchia części samochodu. Patrz: agregacja.

hierarchia dziedziczenia (inheritance hierarchy) Patrz: hierarchia klas.

69


hierarchia klas (class hierarchy) Struktura klas ustalająca ich zakres znaczeniowy lub drogi dziedziczenia; np. klasa PRACOWNIK jest niżej w hierarchii klas niż klasa OSOBA.

PRACOWNIKZarobekFirma

ZdjęcieZarobekNetto()

ZmieńZarobek(...)

STUDENTNrIndeksu

RokStudiówWydział

WstawOcenę(...)ZaliczSemestr()

OSOBANazwisko

ImięRokUrodz

Wiek()

obiekt obiekt obiekt obiekt obiekt obiekt obiekt obiekt

Przykład hierarchii klas

hierarchia obiektu (object hierarchy) Struktura podobiektów pewnego obiektu.

hierarchia typów (type hierarchy) Struktura typów ustalająca typy oraz ich podtypy.

hierarchiczna biblioteka (hierarchical library) Biblioteka funkcji i procedur zorganizowana w postaci drzewa (grupująca funkcje wg ich roli lub przeznaczenia). Biblioteki hierarchiczne są cechą niektórych obiektowych języków programowania, np. Ada95.

HMSL (Hierarchical Music Specification Language) Obiektowy język programowania, rozszerzenie Forth, do eksperymentowania w zakresie komponowania i wykonywania muzyki.

http://www.softsynth.com/hmsl

homomorfizm (homomorphism) Termin OMT oznaczający stosunek pomiędzy dwoma klasami lub asocjacjami polegający na tym, że wystąpienie jednej klasy (asocjacji) „skleja” wiele wystąpień innej klasy (asocjacji). Np. stosunek homomorfizmu zachodzi pomiędzy klasą książek rozumianych jako pozycje wydawnicze i klasą konkretnych egzemplarzy książek. Każde wystąpienie pozycji wydawniczej „skleja” wiele wystąpień konkretnych egzemplarzy książek.

homonimiczny (homonimic) Określenie bytu programistycznego (np. funkcji), którego nazwa jest identyczna z innym bytem programistycznych; kojarzy się z przeciążaniem (overloading) lub przesłanianiem (overriding).

70


humor obiektowy (object-oriented humour) Zestaw żartów i anegdot pozwalających obudzić drzemiących słuchaczy wykładów i seminariów nt. technologii obiektowych, np.:

*Podczas prezentacji J.L.Morgana na seminarium Yourdona:Pytanie: Jaka jest różnica pomiędzy metodykiem obiektowym a terrorystą?Odpowiedź: Z terrorystą można negocjować.

*Z wykładu Ch.Bachmana na konferencji OOER:Pytanie: Jaka jest różnica pomiędzy encją i obiektem?Odpowiedź: Encja jest to obiekt, który nie wie, jak się zachować.

*Przypisywane Billowi Gatesowi:Większość programistów C++ w rzeczywistości używa podzbioru C++, powszechnie znanego jako C++.

*Przypisywane Bjarne Stroustrupowi:Języki programowania dzielą się na takie, które wszyscy krytykują, oraz takie, których nikt nie używa.

*Przypisywane Prof. G.Karamowi z Uniwersytetu w Carleton:W C kodujemy nasze własne błędy, natomiast w C++ możemy je odziedziczyć.C pozwala ci strzelić w swoją nogę, natomiast C++ pozwala ci oderwać całą nogę.

*C jest językiem programowania, który łączy elastyczność i uniwersalność assemblera z elegancją i pielęgnacyjnością ... assemblera.

*(Dla miłośników żartów na listach dyskusyjnych News.)Pytanie: Jak wielu programistów potrzeba, aby wymienić żarówkę?Odpowiedź: Żadnego. Wystarczy wysłać do blondynki komunikat „zmień żarówkę”.

*Chirurg, architekt i informatyk dyskutują w barze, która dyscyplina jest starsza. Chirurg: Oczywiście, że chirurgia. Wyjęcie żebra Adamowi i stworzenie z niego Ewy było z pewnością najstarszą operacją chirurgiczną. Architekt protestuje: Przepraszam, ale zanim to nastąpiło, należało zbudować świat. Było to najstarsze przedsięwzięcie architektoniczne. Przedtem był chaos. Informatyk: W takim razie inżynieria oprogramowania jest jeszcze starsza. Zastanówcie się tylko, skąd wziął się chaos?

*Dobrą cechą C++ jest to, że tylko twoi przyjaciele mogą używać twoich prywatnych własności.

*Szybki program. Tani program. Dobry program. Możesz wziąć tylko dwa z trzech.

*Hasło w encyklopedii komputerowej w 2000 roku (lub późniejszej):SQL - szeroka rodzina języków komputerowych. Wyróżniają się tym, że każdy z nich jest oparty na trzech jednostkach leksykalnych: select, from i where.

71


*Chirurg po kursie projektowania obiektowego do pacjenta na stole operacyjnym: „Przesyłam panu skalpel, zoperuj się pan sam.”

*Prelegent na wykładzie z obiektowości: Tematy ważne są zwykle nudne (np. testowanie oprogramowania). Tematy fascynujące są zwykle nieprzydatne (np. reguły dedukcyjne). Jeżeli na wykładzie będzie was ogarniała senność, to znak, że temat jest bardzo ważny.

http://cis.gsu.edu/~shong/oojokes.html

hurtownia danych (data warehouse, data mart) Scentralizowane repozytorium informacji dotyczących określonego tematu lub dziedziny, gromadzonych z różnych, być może odległych źródeł (np. dotyczących rynku metali kolorowych, usług transportowych, eksportu towarów, itd.). Hurtownie danych służą do przeprowadzania różnorodnych analiz, wyszukiwań i przeglądów mających na celu podejmowanie decyzji. Analizy mogą być przeprowadzane przy pomocy środków manualnych, półautomatycznych lub automatycznych (np. metod statystycznych); te ostatnie wymagają zwykle zamiany formatu informacji przechowywanych w odległych miejscach (często bardzo nieregularnego) na format wygodny dla określonej grupy metod i algorytmów przetwarzania. Hurtownie danych są także nazywane magazynami danych. Są one często kojarzone z terminami OLAP (On Line Analytical Processing), eksploracją danych (data mining) oraz kostką danych (data cube), czyli specjalnym, bardzo regularnym formatem danych przystosowanym do tworzenia szybkich analiz, przeglądów i zestawień. Hurtownie danych często opierają się na wyrafinowanych technikach kompresji danych, kodowaniu mieszającym (hashing) oraz wprowadzają zaawansowane techniki filtracji danych. Hurtownią danych nazywa się także niekiedy pewne „zdjęcie migawkowe” (snapshot) odwzorowujące stan bazy danych w niedawnej przeszłości, pozwalające analitykom, planistom i badaczom na przeprowadzenie odpowiednich analiz i badań bez obciążania bieżących operacji dostępu do bazy danych. Zwykle terminem składnica danych (data mart) określa się wyspecjalizowaną hurtownię danych o małych rozmiarach. Synonim: magazyn danych.

http://www.informatik.tu-darmstadt.de/DVS1/staff/wu/dw.html

hybrydowy (hybrid) Inaczej niejednorodny. Np. C++ jest hybrydowy, gdyż posiada konstrukcje umożliwiające zarówno programowanie obiektowe, jak i programowanie tradycyjne niskiego poziomu. Podobnie systemy obiektowo-relacyjne są również określane jako hybrydowe.

II

Iceberg Pośrednik wymiany obiektów (ORB) wg standardu OMG CORBA, rozwijany i rozpowszechniany przez BEA Systems.

http://www.beasys.com/

IDB Object Database Obiektowy system zarządzania bazą danych zrealizowany przez firmę Persistent Data Systems, Inc.

72


identyfikator (identifier) Patrz: identyfikator obiektu.

identyfikator fizyczny (physical identifier) Adres obiektu w przestrzeni adresowej komputera.

identyfikator krotki (tuple identifier, TID) Identyfikator krotki. Wewnętrzny identyfikator, który jest nadawany automatycznie przez system każdej krotce w relacyjnej bazie danych. Identyfikator krotki jest pojęciem implementacyjnym; użytkownik i programista (teoretycznie) nie musi nic o nim wiedzieć ani odwoływać się do niego w jakikolwiek sposób. Na ogół nie ma gwarancji, że TID będzie unikalny na cały przeciąg życia danej krotki, wobec czego nie może być używany w programie jako referencja lub wskaźnik; tym TID różni się od OID (identyfikatora obiektu). (W nowym standardzie SQL3 TID może mieć charakter unikalnego i trwałego identyfikatora.) Semantyka niektórych konstrukcji SQL jest pośrednio oparta na identyfikatorach krotek, np. semantyka operatora update oraz semantyka kursorów w zanurzonym SQL. TID jest także podstawowym pojęciem przy organizowaniu indeksów.

identyfikator logiczny (logical identifier) Identyfikator obiektu, którego postać i sposób generowania nie zależy od fizycznego miejsca przechowywania obiektu. Patrz: też: identyfikator obiektu.

identyfikator obiektu (object identifier, OID) Unikalna wewnętrzna nazwa obiektu, nadawana automatycznie przez system i nie posiadająca znaczenia w świecie zewnętrznym. Służy do odróżnienia obiektu od innych obiektów oraz do budowy odwołań (referencji, references) lub wskaźników (pointers) prowadzących do obiektu. Często identyfikator obiektu jest logicznie związany z adresem miejsca przechowywania obiektu. Tego rodzaju związek jest uważany za niekorzystny z punktu widzenia elastyczności w zakresie ulokowania obiektu, lecz z drugiej strony bywa konieczny ze względu na wymaganą wydajność (patrz: tablica pośrednia). Pojęcie unikalnego identyfikatora obiektu staje się dość trudne w przypadku istnienia wielu kopii (replik) tego samego obiektu, lub w przypadku istnienia wielu wersji (np. czasowych) obiektu. Unikalne identyfikatory obiektów czynią w zasadzie zbędnym pojęcie klucza (znane z modelu relacyjnego), czyli atrybutu lub zestawu atrybutów, których wartości stanowią unikalną identyfikację obiektu. Patrz też: mrówka.

idiom (idiom) Konwencja, umowa, element folkloru, pewna analogia z powszechną sytuacją, która pozwala na lepsze lub szybsze zrozumienie konstrukcji danego języka programowania (systemu) lub jego użycia. Np. powszechnie przyjętym idiomem jest pisanie słów kluczowych tłustym drukiem.

idiota (idiot) Popularne określenie mało rozgarniętego użytkownika („...mówię mu: naciśnij pan dowolny klawisz, a ten idiota nacisnął Reset...”) lub anonimowego programisty, po którym musimy poprawiać program („...panie dyrektorze, jak to mogło działać, jeżeli jakiś idiota zrobił kast z double * na char *, a potem skopiował to jako string” - „No wie pan, byłem wtedy początkujący, nie byłem jeszcze dyrektorem...”).

IDL [1] (Interface Definition Language) Język definicji interfejsu służący do

73


specyfikacji schematu obiektowego wg standardu OMG CORBA. Wyrażenia IDL opisują interfejsy (inaczej: specyfikacje klas) widziane z pozycji klienta ORB i zaimplementowane po stronie serwera obiektów. IDL jest deklaracyjny i niezależny od języka programowania; umożliwia deklarację interfejsów, a nie ich implementację. Obiekty mogą być tworzone i przetwarzane przez wiele języków programowania: jest to istotne z punktu widzenia heterogeniczności, gdyż na ogół poszczególne platformy sprzętowo-programowe różnią się językami programowania. Interfejs definiuje zbiór operacji (metod), które klient może wywoływać w stosunku do obiektów. Interfejs może mieć atrybuty (prywatne zmienne). Każda z tych zmiennych ma automatycznie przypisane dwie metody: get (daj wartość) oraz set (podstaw wartość). Interfejs może być definiowany z użyciem dziedziczenia lub wielodziedziczenia. W ramach interfejsu deklarowane są także wyjątki, które służą do obsługi błędów (ale mogą mieć także inne zastosowania). IDL wprowadza pewną liczbę typów wbudowanych (long, short, float, char, boolean i inne), typy konstruowane (struct i union) oraz typy wzorcowe (string, wstring i sequence). Współdziałanie z językami programowania wymaga odwzorowania IDL na konstrukcje poszczególnych języków. Dotychczas zdefiniowano odwzorowania dla C, C++, Smalltalk i Ada95; Unix Bourne Shell i OO Cobol są bliskie ukończenia; trwają prace nad odwzorowaniem do Java. Odwzorowania do Perl, Eiffel, Modula-3 i innych języków są opracowywane niezależnie od OMG. IDL został zaproponowany jako standard ANSI oraz ISO. Pewną jego wadą jest to, że nie można w nim wyrazić związków asocjacyjnych (powiązań pomiędzy obiektami); wada ta jest częściowo wyeliminowana przez specjalną usługę w zakresie związków (Relationship Service).

OsobaImięNazwiskoData_Urodzeniawiek()

KierowcaPunkty_KarneNumer_Prawa_JazdyWykroczenie(...)

interface Osoba { attribute string<20> Imię;attribute string<30> Nazwisko;attribute long Data_Urodzenia;short Wiek( void ); ...};

interface Kierowca : Osoba { attribute short Punkty_Karne;attribute long Numer_Prawa_Jazdy;

exception Odebranie_Prawa_Jazdy { ... string <80> Przyczyna; ... };void Wykroczenie( in short punkty ) raises( Odebranie_Prawa_Jazdy ); ... };

Przykład specyfikacji w IDL


IDL [2] (Interface Definition Language) Język definicji interfejsu służący do definiowania pniaków RPC (RPC stubs) w standardzie OSF.

74


IDL [3] (Interface Definition Language) Język definicji interfejsu w standardzie COM firmy Microsoft.

IDP (Iterative Development Process) Patrz: iteracyjny proces rozwoju.

IIOP (Internet Inter-ORB Protocol) Protokół transportowy proponowany w standardzie OMG CORBA. IIOP specyfikuje sposób wymiany komunikatów wg GIOP poprzez transport TCP/IP.

http://www.ansa.co.uk/ANSA/ISF/wwwCorba_1.htmlhttp://www.omg.org

Illustra Obiektowo-relacyjny system zarządzania bazą danych firmy Informix/Illustra Information Technologies, Inc.; wersja systemu Postgres.


ILU (Inter-Language Unification) Pośrednik ORB wg standardu OMG CORBA firmy Xerox Parc.

imperatywny (imperative) Określenie paradygmatu języka, który specyfikuje akcje prowadzące do pewnego celu, a nie sam cel. Przykładami języków imperatywnych są: Fortran, Pascal, C, C++, Smalltalk, Java. Synonim: proceduralny. Antonim: deklaracyjny (np. Prolog i SQL).

implementacja [1] (implementation) Konstrukcja i wdrożenie pewnego programu lub systemu.

implementacja [2] (implementation) Antonim terminu „specyfikacja”. Implementacja klasy lub interfejsu zawiera fizyczny kod deklaracji atrybutów i metod w konkretnym języku programowania.

import (import) Określenie sytuacji, w której pewien byt programistyczny (klasa, moduł, itd.) korzysta z cech zdefiniowanych lub zaimplementowanych w innych bytach programistycznych.

indeks (index) Pomocnicza struktura danych wprowadzana do systemu bazy danych lub systemu plików celem radykalnego zmniejszenia czasu dostępu do danych. Koncepcyjnie, indeks jest zbiorem par <wartość, lokalizacja>, gdzie wartość jest pewną wartością przechowywaną w bazie danych (np. nazwiskiem pracownika), zaś lokalizacja jest zbiorem symboli (np. adresów) wskazujących miejsca ulokowania danych zawierających tę wartość (np. adresy ulokowania obiektów Pracownik posiadających dane nazwisko). Dzięki temu, na podstawie wartości można szybko odszukać wymagane obiekty. W systemach obiektowych indeksy mogą mieć bardziej złożoną budowę, uwzględniającą hierarchiczną strukturę obiektu i jego powiązania z innymi obiektami. Indeksy posiadają organizację umożliwiającą szybkie odszukanie danej pozycji indeksu, o ile znana jest w/w wartość. Najbardziej popularnymi technikami implementacji indeksów są kodowanie mieszające (hash coding) i drzewa zbalansowane (B-tree).

75


indeks główny (primary index) Indeks zorganizowany wg klucza głównego. Indeks taki jest zbiorem par <k, l(k)>, gdzie k jest wartością klucza głównego, zaś l(k) jest lokacją krotki (obiektu) zawierającej wartość klucza głównego k (zwykle jest to TID tej krotki). Indeks główny jest organizowany wg techniki umożliwiającej bardzo efektywne wyszukiwanie, np. tablicy z kodowaniem mieszającym (hash table) lub B-drzewa.

indeks pomocniczy (secondary index) Indeks zorganizowany wg dowolnego atrybutu (lub ich kombinacji) nie będącego kluczem głównym, np. wg zarobku, wieku, itp. Indeks taki jest zbiorem par <w, {l1(w), l2(w), l3(w), ...}>, gdzie w jest wartością danego atrybutu, zaś {l1(w), l2(w), l3(w), ...} jest zbiorem lokacji krotek (obiektów) posiadających dla danego atrybutu wartość w (zwykle lokacje są ustalane przez identyfikatory krotek (TID) lub obiektów (OID)). Indeks pomocniczy jest organizowany wg techniki umożliwiającej bardzo efektywne wyszukiwanie, np. w postaci tablicy z kodowaniem mieszającym (hash table) lub B-drzewa.

indeks ścieżkowy (path index) Indeks, w którym jedna pozycja składa się z pewnej wartości oraz lokalizacji pewnej liczby obiektów powiązanych w hierachię lub poprzez wskaźniki. Indeksy ścieżkowe znacznie polepszają czas ewaluacji wyrażeń ścieżkowych (path expressions). Wadą indeksów ścieżkowych jest kłopotliwa aktualizacja w odpowiedzi na aktualizację zapamiętanych danych.

indeks wtórny (secondary index) Patrz: indeks pomocniczy.

Informix Dynamic Server Nowa, ulepszona wersja systemu Informix Universal Server.


Informix Universal Server Obiektowo-relacyjny SZBD firmy Informix; połączenie systemów Illustra i Informix OnLine. Wspomaga duże obiekty (BLOB-y i CLOB-y), typy (w tym typy nieprzezroczyste i kolekcje), hierarchiczne definiowanie tablic, funkcje i procedury definiowane przez użytkownika, późne wiązanie operatorów i metod, przeciążanie i inne cechy obiektowości. Posiada API, zwane DataBlades, dla języków C i Java.


Ingres Relacyjny system zarządzania bazą danych wprowadzający niektóre elementy obiektowości (np. w postaci abstrakcyjnych typów danych). Pewne elementy obiektowości występują także w językach czwartej generacji zaimplementowanych dla systemu Ingres (np. Ingres Windows 4GL i OpenRoad wprowadzają klasy, metody i dziedziczenie).

http://www.cai.com/

Ingres II Obiektowo-relacyjny system zarządzania bazą danych firmy Computer Associates, nowa wersja systemu Ingres.(Poprzednia nazwa: OpenIngres.)

http://www.cai.com/

instancja (instance) Patrz: wystąpienie.

76


integralność (integrity) Formalna poprawność bazy danych i procesów przetwarzania, wewnętrzna poprawność fizycznej organizacji danych, zgodność ze schematem bazy danych, zgodność z więzami integralności (ograniczeniami), zgodność z regułami dostępu. Integralność nie oznacza, że baza danych wiernie odwzorowuje sytuację w opisywanym przez nią świecie zewnętrznym i procesy biznesowe. Odpowiednim terminem dla tej wierności jest spójność (consistency).

integralność odwołań (referential integrity) W relacyjnych bazach danych integralność odwołań dotyczy sytuacji, kiedy tablica A zawiera obcy klucz (foreign key) będący pierwotnym kluczem (primary key) tablicy B. Warunek integralności odwołań ustala, że dla każdego wiersza tablicy A musi istnieć taki wiersz tablicy B, że wartości kluczy w tych wierszach są jednakowe. Np. dla każdej wartości kolumny NrDziału (obcy klucz) tablicy Pracownik musi istnieć taka sama wartość w kolumnie NrDziału (klucz pierwotny) tablicy Dział. Odpowiednikiem pojęcia integralności odwołań w obiektowości jest unikanie „zwisających” wskaźników (tzn. takich, których wartości nie są identyfikatorami istniejących obiektów).

integralność referencyjna (referential integrity) Patrz: integralność odwołań.

integralność wskaźników (referential integrity) Patrz: integralność odwołań.

inteligentny (intelligent) Termin reklamowy (pozbawiony jednoznacznej semantyki) nawiązujący do sztucznej inteligencji. Zwykle chodzi o pewne cechy, które nie są typowe, dostarczają nowych jakości, mają wymiar wyzwania intelektualnego lub (zdaniem twórców systemów) mają charakter wyjątkowy, epokowy. Dla przykładu, „inteligentnymi” nazywane są elementy zapamiętane w bazie danych, których interpretacja semantyczna należy do systemu, np. procedury bazy danych, perspektywy, aktywne reguły i inne. Termin „inteligentny” określa często interfejs użytkownika, którego twórcy zadbali o jego przyjacielskość i rozsądną reakcję na każdą (również nierozsądną) akcję użytkownika.

interakcyjne zapytanie (interactive query) Patrz: zapytanie ad hoc.

interfejs (interface) Ogólnie, środki służące do komunikacji pomiędzy modułami systemu lub komunikacji systemu z użytkownikiem. W innym znaczeniu (OMG, ODMG) interfejs jest synonimem specyfikacji klasy. Interfejs do obiektu składa się z sygnatur wszystkich metod, które mogą być w stosunku do niego użyte. Operacje na obiekcie mogą odbywać się poprzez wysłanie do niego komunikatu zgodnego z dowolną z sygnatur należących do jego interfejsu. W niektórych koncepcjach (np. MS Repository) obiekty mogą mieć wiele różnych interfejsów, w zależności od roli pełnionej przez obiekty (patrz: rola [1]).

interfejs do programowania aplikacji (Application Programming Interface, API) Patrz: API.

interfejs graficzny użytkownika (Graphical Use Interface, GUI) Patrz: GUI.

77


interfejs poziomu wołania (Call-Level Interface, CLI) Patrz: CLI.

intergalaktyczny język danych (intergalactic dataspeak) Chodzi o SQL. Patrz: manifest.

interoperacyjność (interoperability) Patrz: współdziałanie.

inwariancja (invariancy) Patrz: kowariancja.

inwariant [1] (invariant) Wyrażenie boolowskie, warunek, który musi być spełniony przez zestaw pewnych bytów (np. obiekty pewnej klasy) lub przez stan pewnych procesów, programów, itd. Termin inwariant jest zbliżony do terminów: asercja, ograniczenie, ograniczenie integralnościowe.

inwariant [2] (invariant) Własność, która jest niezmienna dla obiektu i/lub jest taka sama dla pewnej grupy obiektów. Tworzenie klas oraz nadklas można uważać za proces wyodrębniania inwariantów i następnie, gromadzenie ich wewnątrz specjalnego bytu zwanego klasą. Obiekty dziedziczą inwarianty ze swojej klasy oraz ze wszystkich swoich nadklas. Popularne modele obiektowe wprowadzają do klas dwa rodzaje inwariantów obiektów: nazwy i typy atrybutów; nazwy, sygnatury i implementacje metod, które można wykonywać na obiektach.

Możliwe jest wiele innych inwariantów, które mogą być (i często są) wprowadzane do klas: Nazwa, czyli językowy identyfikator obiektu; Powiązania, asocjacje (links, associations) obiektów danej klasy z obiektami innej

lub tej samej klasy; Wartości wspólne dla wszystkich elementów klasy, np. pewne stałe; Informacja o dopuszczalności wartości zerowych (null values); Wartości domyślne (default values) używane przez system w momencie tworzenia

nowego obiektu lub podstawiane w sytuacji, kiedy dany atrybut dla obiektu przyjmuje wartość zerową;

Zdarzenia lub wyjątki, które mogą zajść podczas operacji na obiekcie; Obsługa zdarzeń lub wyjątków; Lista eksportowa lub inny środek określający, które atrybuty lub metody są

dostępne z zewnątrz klasy lub obiektu, a które są prywatne; Lista importowa lub inny środek ustalający, jakie elementy obiektów innych klas

mogą być używane wewnątrz danej klasy; Więzy integralności (integrity constraints), którym musi podlegać każdy obiekt

będący członkiem danej klasy; Atrybuty wyliczalne wraz z ich algorytmami (można je traktować jako szczególny

przypadek metod); Reguły bezpieczeństwa i prywatności; Informacje katalogowe, pomoce;

78


Fizyczne własności obiektów: ich reprezentacja, metody dostępu, obecność indeksów.

Podana lista potencjalnych inwariantów prawdopodobnie nie jest kompletna. Większość języków i systemów implementuje taki model, w którym klasy są przechowalnią inwariantów. Natomiast modele i metodyki obiektowe najczęściej bazują na modelu, w którym semantyką klasy jest jej zakres znaczeniowy (ekstensja). Te dwa rozumienia pojęcia klasy nie są ze sobą zgodne, co jest powodem wielu nieporozumień.

inżynieria odwrotna (reverse engineering) Proces tworzenia modelu logicznego lub pojęciowego na podstawie kodu programu. Inżynieria odwrotna jest często niezbędna do przystosowania starszych systemów (spadkowych, legacy) do nowych technologii lub wymagań.

inżynieria oprogramowania wspomagana komputerem (Computer Aided Software Engineering, CASE) Patrz: CASE.

inżynieria prosta (forward engineering) Produkcja wykonywalnego kodu programu na podstawie modelu (diagramu) pojęciowego lub logicznego. Niekiedy terminem inżynieria prosta określa się także cały cykl rozwoju oprogramowania, od wymagań po implementację.

inżynieria systemów wspomagana komputerem (Computer Aided System Engineering, CASE) Patrz: CASE.

IR (Interface Repository) Patrz: repozytorium interfejsów.

Iris System zarządzania obiektową bazą danych opracowany przez Hewlett-Packard. Początkowo projekt był zorientowany na model funkcjonalny (functional model), ale zmienił orientację na obiektową.

IS (Information System) System informacyjny, system informatyczny.

is-a Częste w literaturze angielskiej oznaczenie związku generalizacji/specjalizacji, np. Student is-a Osoba.

ISO (International Standard Organization) Międzynarodowa Organizacja Standardyzacji.

ISO 9001 Standard ISO (International Standard Organization) określający, w jaki sposób przedsiębiorstwa i organizacje powinny zarządzać programami zapewnienia jakości (quality assurance).

ISO 9003 Standard ISO (International Standard Organization) określający, w jaki sposób przedsiębiorstwa i organizacje powinny zarządzać programami zapewnienia jakości oprogramowania (software quality assurance).

Itasca (wcześniejsza nazwa Orion) Obiektowy system zarządzania bazą danych opracowany w ośrodku MCC w Teksasie, rozwijany przez IBEX Corporation S.A.

79


http://w3.iprolink.ch/ibexcom/products.htm#ITASCA

iteracja (iteration) Kolejny powtarzający się cykl pewnego procesu, np. kolejna iteracja procesu projektowania oznacza powtórzenie pewnych czynności projektowych po uzyskaniu informacji z poprzednich; również określenie jednego obrotu pętli w programie (implikowanej przez zdania repeat, while, for, loop, itd.).

iteracyjny proces (iterative process) Patrz: proces iteracyjny.

iteracyjny proces rozwoju (Iterative Development Process, IDP) Technika rozwoju oprogramowania zakładająca powtarzanie pewnych faz, przy czym poprzednia faza dostarcza informacji wejściowych dla następnej fazy.

iterator (iterator) Zestaw operatorów lub metod, często hermetyzowany w postaci klasy abstrakcyjnej, klasy parametryzowanej lub szablonu, służący do sekwencyjnego przetwarzania (element po elemencie) pewnego zbioru, wielozbioru, sekwencji lub innej wartości masowej (kolekcji).

iterator niestabilny (non-stable iterator) Iterator, który może prowadzić do błędu, utraty integralności lub utraty spójności w sytuacji, gdy w pętli iteratora jest aktualizowany (jest dodawany lub usuwany) obiekt znajdujący się w kolekcji obieganej przez dany iterator. Iterator niestabilny może być używany wyłącznie w sytuacji braku takich aktualizacji.

iterator stabilny (stable iterator) Iterator, który umożliwia poprawną, bezbłędną aktualizację (usuwanie, dodawanie) obiektów znajdujących się w kolekcji obieganej przez dany iterator.

izolacja (isolation) Własność transakcji polegająca na tym, że inne równocześnie działające transakcje nie mają wpływu na daną transakcję i odwrotnie, dowolne zmiany poczynione przez daną transakcję są niewidoczne dla innych transakcji aż do momentu potwierdzenia (commit). Własność izolacji musi być osłabiona w przypadku tzw. długich transakcji. Przykładem (kontrowersyjnym) możliwości osłabienia własności izolacji są tzw. poziomy izolacji (isolation levels) w SQL.

JJ

Jacobson, Ivar Twórca koncepcji analizy i projektowania obiektowego określanej jako przypadki użycia (use cases); także twórca metodyki analizy i projektowania systemów informatycznych Objectory oraz jeden z twórców notacji UML.


Jade [1] Obiektowy system rozwijania rozproszonych aplikacji połączony z obiektową bazą danych.

http://www.jade.co.nz/jadehttp.dll?JWS

80


Jade [2] Język zapytań i programowania aplikacji zrealizowany w systemie Jasmine (nazwa ta została zmieniona z powodu konfliktu z firmą rozwijającą Jade[1]).

Jasmine (występujący również pod nazwą ODB-II) System zarządzania obiektową bazą danych zrealizowany w kooperacji firm Computer Associates i Fujitsu, dobrze przystosowany do przechowywania i przetwarzania danych multimedialnych oraz współpracy z WWW.

http://www.cai.com/products/jasmine.htm

Java IDL Pośrednik ORB przystosowany do współpracy z Java zapewniający: (1) funkcje klienta i serwera wg protokołu IIOP; (2) usługi w zakresie nazw (Naming Service) zgodne z CORBA; (3) środowisko rozwijania aplikacji zawierające kompilator IDL/Java. Nie wspomaga repozytorium interfejsów, z negatywnymi skutkami dla wołań dynamicznych. Wersja beta jest rozpowszechniana bez opłat.

http://www.javasoft.com/http://www.corbajava.engr.sjsu.edu

Java Obiektowy język programowania uważany za kombinację C++, Smalltalka i Objective-C, z obcięciem cech niskiego poziomu (takich jak np. wskaźniki) oraz wyeliminowaniem niektórych ograniczeń i niejasnych własności. Java jest określana przez jej twórców (Sun Microsystems) całym szeregiem entuzjastycznych określeń (simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, multithreaded, dynamic, buzzword-compliant, general-purpose), ale wydaje się, że przy wszystkich zaletach, jest ona językiem dość konwencjonalnym, przynajmniej w stosunku do języków programowania baz danych takich jak SQL i jego pochodne.

Składnia Java jest podobna do C++. Nie posiada ona przeciążania operatorów, wielodziedziczenia i automatycznych koercji. Posiada mocną kontrolę typów oraz mechanizm automatycznego zbierania nieużytków (garbage collection). Posiada także bogatą bibliotekę klas i funkcji, szczególnie do obsługi protokołów TCP/IP, HTTP i FTP. Nowością wprowadzoną w Java jest możliwość definiowania wielu interfejsów do obiektu; wraz z pewnymi dodatkowymi mechanizmami daje to możliwość obejścia braku wielodziedziczenia.

Java powstała jako język przeznaczony do programowania stron WWW, ale nie jest ograniczona tylko do tych zastosowań. Istotną własnością Java jest to, że programy są kompilowane nie do poziomu kodu maszynowego, a do poziomu znakowego języka pośredniego (kodu bajtowego), czyli tzw. apletów (applets), które są następnie interpretowane przez tzw. maszynę wirtualną (Java Virtual Machine, JVM). Aplety mogą być przesyłane w sieci WWW na dowolną platformę. Aplety zapewniają dużą przenaszalność programów oraz zwiększają ochronę i bezpieczeństwo (safety, security), co jest szczególnie istotne w środowiskach rozproszonych, takich jak Internet. Istnieją propozycje rozszerzenia języka Java o zmienne trwałe (PJama).

http://java.sun.com/http://lightyear.ncsa.uiuc.edu/~srp/java/javabooks.htmlhttp://reality.sgi.com/employees/austern/java.htmlhttp://sunsite.net.edu.cn/tutorials/se_java2e/

81


Java Virtual Machine Patrz: JVM.

JavaBeans Pakiet oprogramowania firmy JavaSoft (podporządkowanej Sun Microsystems) pozwalający na interakcję komponentów oprogramowania napisanych w Java. JavaBeans jest pakietem API niezależnym od platformy sprzętowej. Współdziała z ActiveX Microsoftu i pozwala na integrację rozproszonych aplikacji przygotowanych m.in. przy pomocy takich narzędzi jak SybasePowerJ, Borland JBuilder, IBM VisualAge for Java, SunSoft Java Workshop, Symantec VisualCave i innych.

http://www.corbajava.engr.sjsu.eduhttp://www.javasoft.com/beans/http://splash.javasoft.com/beans

Javascript Obiektowy, skryptowy język programowania stron WWW przyjęty przez Netscape. W odróżnieniu od Java (gdzie aplety są odrębnymi plikami), kod w Javascript jest fragmentem strony HTML, nie tworzy apletów ani też samodzielnych aplikacji. Javascript jest językiem znacznie prostszym od Java, ale zapewnia sporo funkcjonalności, m.in. interakcyjny interfejs z użytkownikiem lub zasobami, bez potrzeby odwoływania się do programowania w CGI. Przeglądarka WWW akceptująca aplety Java niekoniecznie jest przystosowana do Javascript, ale (ze względu na dominację Netscape na rynku) prawdopodobnie w niedługim czasie wszystkie przeglądarki będą akceptować zarówno Java, jak i Javascript.

http://www.c2.org/~andreww/javascript

JavaSoft Pośrednik ORB wg standardu CORBA, integrujący technologie komponentowe oparte o Java, RMI i protokół IIOP. Wersja beta jest rozprowadzana bez opłat.

http://www.corbajava.engr.sjsu.eduhttp://www.javasoft.com

JDBC (Java Data Base Connectivity) Standard interfejsu API opracowany przez JavaSoft, służący do połączenia języka Java z relacyjnymi bazami danych. JDBC jest oparty o SQL. Wbrew niektórym sugestiom należy uprzedzić, że JDBC daje możliwość dostępu wyłącznie do relacyjnych baz danych i nie ma nic wspólnego z obiektowymi bazami danych.

http://java.sun.com/products/jdk/1.1/docs/guide/jdbc/index.htmlhttp://www.yoyoweb.com/Javanese/JDBC/FAQ.html

JDK (Java Developer Kit) Środowisko do rozwoju aplikacji w oparciu o język Java. JDK jest rozprowadzane bez opłat dla wielu platform, m.in. Sun Solaris i Microsoft Windows.

http://java.sun.com/products/jdk/1.1/index.htmlhttp://www.corbajava.engr.sjsu.edu

język czwartej generacji (fourth generation language, 4GL) Określenie grupy języków (czy też środowisk programistycznych) do programowania aplikacji z bazą danych. Niektóre z nich (np. CA OpenRoad) wprowadzają elementy obiektowości. Główne cechy języków czwartej generacji są następujące:

82


Wiele środków do programowania interakcji z użytkownikiem, w tym okienka, guziki, menu, przełączniki, zmienne i tablice widoczne na ekranie, obsługa klawiatury i myszy; środki te są dostępne na bardzo wysokim poziomie abstrakcji i agregacji;

Środki służące do sprawnej obsługi bazy danych (wyszukiwanie, wstawianie, usuwanie, aktualizacja, itd.), w tym języki zapytań takie jak SQL;

Programowanie przez zdarzenia (event-driven programming), którego istotą jest równoległa obsługa wielu zdarzeń pojawiających się w trakcie interakcji użytkownika z systemem lub generowanych przez środowisko komputerowe;

Zintegrowane środowisko programistyczne, w którym nie zachowuje się tradycyjnych podziałów na edycję kodu, kompilację, konsolidowanie i wykonanie;

Oddelegowanie bardziej złożonego przetwarzania do procedur napisanych w klasycznych językach programowania, które są dynamicznie wiązane do programu napisanego w języku czwartej generacji;

Programowanie wizyjne, w którym programista komponuje program z elementów graficznych oraz ustala własności programu poprzez wypełnianie formularzy.

Dla większości zastosowań baz danych języki czwartej generacji okazały się bardzo skutecznym, szybkim i niezawodnym narzędziem programistycznym, znacznie skracając czas przygotowania, testowania i wdrażania programów aplikacyjnych. Wygrana w wydajności programisty stała się przyczyną ogromnego komercyjnego sukcesu tych języków. Ogólnym zarzutem w stosunku do języków czwartej generacji jest ich niesystematyczna i eklektyczna konstrukcja, często zaniedbująca zasady i techniki konstrukcji języków programowania, powodująca rozrost ich dokumentacji i przeciążenie ogromem szczegółów, oraz powodująca częste wątpliwości dotyczące semantyki i pragmatyki użycia wprowadzanych w tych językach opcji.

język definicji danych (Data Definition Language, ODL) Patrz: DDL.

język definicji interfejsu (Interface Definition Language, IDL) Patrz: IDL [1], IDL [2], IDL [3].

język definicji obiektów (Object Definition Language, ODL) Patrz: ODL.

język deklaracyjny (declarative language) Patrz: język nieproceduralny.

język imperatywny (imperative language) Patrz: język proceduralny.

język manipulacji danymi (Data Manipulation Language, DML) Patrz: DML.

język manipulacji obiektami (Object Manipulation Language, OML) Patrz: OML.

język nieproceduralny (non-procedural language, declarative language) Inaczej język deklaracyjny. Ogólnie, język w którym programista lub użytkownik określa bezpośrednio cel przetwarzania, a nie akcje komputera lub systemu, które mają do tego celu doprowadzić. Przeciwieństwem języka nieproceduralnego jest język proceduralny albo inaczej - imperatywny. Większość klasycznych języków programowania jest proceduralna; wyjątkiem jest np. Prolog, który uważa się za język deklaracyjny (ale nie

83


do końca). Za nieproceduralne uważa się także języki funkcjonalne, takie jak Lisp i ML. Nieproceduralność w językach programowania musi być wspomagana przez konstrukcje imperatywne, chociażby ze względu na operacje wymagające uwzględnienia osi czasu oraz zmian stanu, np. aktualizacje, programowanie scenariuszy interakcji użytkownika aplikacji, zdarzeń, itp. W bazach danych za nieproceduralne uważa się języki zapytań, np. SQL lub OQL. Nieproceduralny jest także język Datalog, ale - wbrew naciskom teoretyków forsującym koncepcję dedukcyjnych baz danych - nie uzyskał on większego znaczenia w praktyce, z powodu nieakceptowalnych ograniczeń uniwersalności pragmatycznej. Nieproceduralność tych języków ogranicza się do specyfikowania danych, które należy wyszukać w bazie danych. Przetwarzanie wyszukanych danych z reguły odbywa przy pomocy środków imperatywnych. Nieproceduralność (deklaracyjność) jest jednak ważnym paradygmatem z kilku względów: sprawniejszy (krótszy) zapis programu; podniesienie poziomu abstrakcji; możliwość bardzo skutecznej automatycznej optymalizacji czasu wykonania; możliwość przetwarzania przy pomocy wielu równoległych procesorów.

język obiektowy (object-oriented language) Patrz: obiektowy język programowania.

język opisu danych (Data Description Language, DDL) Patrz: DDL.

język proceduralny (procedural language) Określenie wszystkich języków programowania, które wprowadzają pojęcie stanu oraz operacje lub instrukcje pozwalające na zmianę stanu. Program napisany w takim języku jest sekwencją instrukcji, których kolejność jest istotna. Językami proceduralnymi są: Pascal, C, Cobol, Basic, Ada, itd. Przeciwieństwem języków proceduralnych są języki nieproceduralne (deklaracyjne), np. Prolog, Datalog, SQL, oraz języki funkcjonalne, np. Lisp i ML. Języki obiektowe (np. Smalltalk, C++, Java, Eiffel) są uważane przez niektórych ich zwolenników za zupełnie nową klasę języków (z częstym przeciwstawieniem np.: w proceduralnym było A, natomiast w obiektowym jest B), ale w istocie języki obiektowe są podklasą lub rozszerzeniem języków proceduralnych. Istotą obiektowości jest nie to, że zrywa ona z proceduralnością (ponieważ bez wątpienia zachowuje pojęcie stanu), lecz to, że dostarcza nowych, mocnych abstrakcji pojęciowych takich jak obiekt, klasa, dziedziczenie, hermetyzacja i polimorfizm. Synonim: język imperatywny.

język programowania baz danych (Data Base Programming Language, DBPL) Ogólnie, język programowania wprowadzający pewną formę trwałych zmiennych lub obiektów (persistent variables, persistent objects). Trwałą zmienną nazywa się taką zmienną, która ma wszystkie własności zmiennej języka programowania, ale zachowuje swoją wartość pomiędzy kolejnymi uruchomieniami programu. Dzięki tej własności, dowolne bazy danych można traktować jako zestaw trwałych zmiennych lub obiektów.

Językami programowania baz danych są liczne mutacje SQL, wśród nich PL/SQL systemu Oracle oraz SQL3. Z terminem „język programowania baz danych” powszechnie wiąże się grupę języków o statucie eksperymentalnym, m.in. Amber,

84


Galileo, Fibonacci, PS-Algol, DBPL, Napier88, OPAL, Tycoon, Machiavelli, MUMPS i ostatnio PJama (wcześniej Persistent Java lub PJava); wśród nich Galileo, Fibonacci, MUMPS i PJama są obiektowe. Mimo intelektualnego zaawansowania i wielu perspektywicznych koncepcji, które są w nich wprowadzone (takich jak polimorficzny system mocnej kontroli typów, ortogonalna trwałość (orthogonal persistence), ortogonalność konstruktorów typów masowych: zbiorów, wielozbiorów, sekwencji i tablic, i inne), z wielkim trudem torują sobie one drogę w świecie komercyjnym zdominowanym przez SQL, C++ i inne koncepcje znacznie niższych lotów. Niektóre idee, takie jak mocna kontrola typów, zyskały sobie autorytet również w świecie komercyjnym, chociaż najczęściej w uproszczonej i nie zawsze spójnej formie. Koncepcja ortogonalnej trwałości, zakładająca pełną unifikację definicji i środków manipulowania trwałymi i ulotnymi danymi, stanowi ogromny postęp w zakresie abstrakcji i estetycznego domknięcia pojęć. Niestety, koncepcja ta napotyka na opór ze strony środowisk przemysłowych, głównie z tego powodu, że obecne popularne systemy i języki takie jak Smalltalk, C++, Java i SQL nie są do niej przygotowane i wymagają modyfikacji. Wydaje się, że główną przeszkodą w rozwoju tej linii języków programowania jest przesadny nacisk na polimorficzny system mocnej kontroli typów wraz z zaniedbaniem innych zagadnień, takich jak języki zapytań, obiektowość, programowanie wizyjne i zdarzeniowe, oraz integracja ze środowiskiem programistycznym.

język programowania z trwałością (persistent programming language) Język programowania posiadający trwałe zmienne lub trwałe obiekty (tj. takie, których wartość lub stan jest zachowywany pomiędzy poszczególnymi uruchomieniami programu). Patrz: język programowania baz danych.

język trzeciej generacji (third generation language, 3GL) Termin używany w literaturze poświęconej językom czwartej generacji (4GL) dla oznaczenia klasycznych języków programowania takich jak C++ lub Pascal. W terminie „język trzeciej generacji” tkwi element pejoratywny: kodowanie programów w takich językach jest uważane za pracochłonne i wymagające wysoko wykwalifikowanych programistów (w odróżnieniu od programowania w językach 4GL). Ograniczenia w zakresie uniwersalności i wydajności języków 4GL prowadzą jednak do konieczności oddelegowania bardziej złożonego przetwarzania do procedury lub funkcji napisanej w języku 3GL.

język zapytań (query language) Język służący do wyszukiwania danych w bazie danych, spełniający następujące warunki: Wysoki poziom konceptualizacji i abstrakcji (m.in. brak odwołań do elementów

fizycznej organizacji danych); Nieproceduralność lub deklaracyjność (formułowanie bezpośrednio celu

wyszukiwania, a nie środków prowadzących do tego celu); Makroskopowość (jednoczesne działanie - z punktu widzenia użytkownika - na

wielu danych); Naturalność (zbieżność z naturalnym sposobem myślenia użytkownika); Efektywność (przystosowanie do automatycznej optymalizacji, której warunkiem

jest jednorodna koncepcja i jasna semantyka języka).

85


Uniwersalność (zdolność języka zapytań do praktycznie dowolnych operacji wyszukiwania i kojarzenia danych, przy zadanych założeniach dotyczących organizacji struktur danych).

Niezależność od dziedziny zastosowań (brak przypisania do jednej dziedziny aplikacyjnej, umożliwienie realizacji wszystkich potencjalnych zastosowań danego systemu zarządzania bazą danych).

Wykonywanie zapytań w trybie interpretacyjnym (brak fazy kompilacji i konsolidacji zapytań z całością aplikacji; umożliwia to zapytania ad hoc, dynamiczne tworzenie i usuwanie perspektyw, zapamiętywanie procedur i reguł w bazie danych, dynamiczne tworzenie i usuwanie indeksów, itd.).

Język zapytań jest najczęściej używany przez programistów jako interfejs programistyczny bardzo wysokiego poziomu umożliwiający dostęp do bazy danych. Język zapytań może mieć postać interakcyjnego graficznego interfejsu, w szczególności opartego o formularze, np. Query-By-Example lub QBF systemu Ingres. Dość często (np. w SQL) język zapytań jest rozszerzony o operacje aktualizacyjne (create, update, insert, delete), o deklaracje (np. deklarowanie nowych relacji) oraz o różnorodne udogodnienia, takie jak perspektywy, reguły, zapamiętane procedury, przetwarzanie transakcji. Trwałą tendencją języków zapytań jest ich ewolucja w kierunku uniwersalnych języków programowania (PL/SQL systemu Oracle, nowy standard SQL3, lub cała rodzina języków programowania czwartej generacji, np. OpenRoad). Wciąż popularną pozostaje koncepcja eklektycznego łączenia (zanurzania, embedding) języka zapytań z uniwersalnym językiem programowania - negatywny aspekt tego podejścia jest określany jako niezgodność impedancji. Najbardziej znanym przykładem języka zapytań jest SQL. Popularność SQL została w znacznym stopniu wymuszona przez IBM i inne wielkie firmy, ponieważ (jakkolwiek użyteczny) jest on językiem wykazującym liczne wady (brak jasnej semantyki, brak ortogonalności, mała uniwersalność, brak mocnej kontroli typów i inne). Najbardziej znanym obiektowym językiem zapytań jest OQL wg standardu ODMG.

JOE (Java Object Environment) Pakiet integrujący obiekty CORBA z WWW firmy SunSoft; stanowi część pośrednika SunSoft NEO.

JOOP (Journal of Object-Oriented Programming) Czasopismo z zakresu programowania obiektowego.

JVM (Java Virtual Machine) Wirtualna maszyna (interpreter znakowego kodu pośredniego) dla języka Java; implementowana w przeglądarkach WWW.

http://www.javasoft.com/docs/books/vmspec/html/VMSpecTOC.doc.html

KK

kapsułkowanie (encapsulation) Patrz: hermetyzacja.

karta CRC (CRC card) Karta papierowa posiadająca trzy pola nazwane: klasa,

86


odpowiedzialność, współpraca (kolaboracja). Karta ta jest rekwizytem prostej metody („burzy mózgów”), mającej na celu wyjaśnienie kluczowych abstrakcji i mechanizmów w systemie. Kartę taką zapełnia się dla każdej klasy. Wewnątrz karty wpisuje się nazwę klasy, określa się związek tej klasy z procesami zachodzącymi w danej dziedzinie przedmiotowej (odpowiedzialność), oraz określa się związek tej klasy z innymi klasami (współpraca); patrz rysunek poniżej.

Nazwa klasy ZamówienieOdpowiedzialność Współpraca

Sprawdź, czy pozycja jest na składzieOkreśl cenę

Sprawdź możliwości płatnicze klientaWyślij na adres klienta

Pozycja zamówienia

Pozycja zamówienia

Klient

Przykładowa karta CRC

kast (cast) Termin C, C++ i innych interfejsów oznaczający operator konwersji typu. Zwykle przyjmuje postać nazwy typu w nawiasach okrągłych, stawianej przed wielkością podlegającą konwersji typu.

kast w dół (downcast) Konwersja typu na typ stojący niżej w hierarchii (na podtyp).

kast w górę (upcast) Konwersja typu na typ stojący wyżej w hierarchii (na nadtyp).

katalog danych (data dictionary, data dictionary-directory, DDD, system catalog) Metainformacje o danych przechowywanych w bazie danych. Podstawowym zadaniem katalogu jest opis danych dla wewnętrznych celów SZBD, w tym wyszczególnienie tablic i ich lokacji, oraz wyszczególnienie atrybutów tablic i ich typów. Katalog danych może zawierać także inne informacje, np. specyfikację ograniczeń związanych z użyciem danych (ograniczeń integralności, praw dostępu), specyfikację elementów interpretowanych przechowywanych wewnątrz bazy danych (perspektyw, procedur bazy danych, reguł), specyfikację indeksów i innych środków usprawnienia dostępu, wskaźniki wydajnościowe i statystyki dostępu niezbędne dla optymalizacji zapytań, itp. Inne podobne terminy: słownik danych, katalog systemowy, przewodnik po danych.

katalog systemowy (system catalog) Patrz: katalog danych.

Kay, Alan Kierownik grupy w firmie Xerox PARC, która opracowała język Smalltalk.

KBMS (Knowledge Base Management System) Patrz: system zarządzania bazą wiedzy.

87


Kim, Won Czołowy prekursor tematyki obiektowych baz danych, główny autor systemu ITASCA (Orion), prezes firmy zajmującej się rozwojem i dystrybucją systemu UniSQL.

klasa (class) Pojęcie klasy jest używane w trzech dość bliskich znaczeniach: Zbiór obiektów o zbliżonych własnościach (niezbyt ściśle - patrz: ekstensja klasy);

to znaczenie jest (naiwnie) preferowane przez osoby o orientacji matematycznej, którzy mylnie kojarzą pojęcie klasy z zakresem znaczeniowym (denotacją) pewnego pojęcia/nazwy, lub z klasą abstrakcji pewnej relacji równoważności.

Byt semantyczny rozumiany jako miejsce przechowywania takich cech grupy podobnych obiektów, które są dla nich niezmienne (np. zestawu atrybutów, nazwy, metod, ograniczeń dostępu).

Wyrażenie językowe specyfikujące budowę obiektów, dozwolone operacje na obiektach, ograniczenia dostępu, wyjątki, itd.

Klasy są zwykle powiązane poprzez hierarchię (lub inną strukturę) dziedziczenia.

klasa abstrakcyjna (abstract class) Klasa zawierająca własności (np. metody) dziedziczone przez jej podklasy, ale nie posiadająca bezpośrednich wystąpień obiektów. Stanowi ona wyższy poziom abstrakcji przy rozpatrywaniu pewnego zestawu obiektów. Np. klasa OSOBA może być klasą abstrakcyjną, o ile zdefiniowane są jej podklasy PRACOWNIK, STUDENT, EMERYT, itd. Z technicznego punktu widzenia klasę abstrakcyjną można uważać za nazwaną grupę cech, które są „wyciągnięte przed nawias” (factoring out) z pewnego zestawu klas. Klasa abstrakcyjna jest najczęściej używana do zdefiniowania wspólnego interfejsu dla pewnej liczby podklas. Klasa abstrakcyjna może mieć (nie musi) metody (operacje) abstrakcyjne, tj. takie, które są zdefiniowane w tej klasie, ale których implementacja znajduje się (jest oczekiwana) w jej bezpośrednich lub pośrednich podklasach. Pojęcie klasy abstrakcyjnej jest jednym z podstawowych dla obiektowości, wzmacniającym zarówno mechanizmy abstrakcji pojęciowej, jak i możliwości ponownego użycia. Możliwość definiowania klas abstrakcyjnych uważa się za wyróżnik obiektowości danego języka lub systemu.

klasa aktywna (active class) Klasa, której wystąpieniami są aktywne obiekty; której obiekty działają współbieżnie; której obiekty działają bez otrzymania komunikatu.

klasa asocjacji (association class) W OMT i UML klasa, która jest związana z daną asocjacją; klasa, której wystąpienia gromadzą atrybuty asocjacji. Na rysunku poniżej klasa Stanowisko jest klasą asocjacji Pracuje_dla.

88


Firma OsobaPracuje_dla* 1..*

pracodawca pracownik

Stanowiskozarobek

szef

podwładny *0..1

Kieruje

Przykład klasy asocjacji


klasa bazowa (base class) Termin oznaczający (w C++) klasę, która posłużyła jako podstawa definicji innej klasy. Synonimy: nadklasa, klasa macierzysta

klasa biznesowa (business class) Klasa mająca znaczenie dla logiki danego biznesu.

klasa chroniona (protected class) Patrz: klasa zabezpieczona.

klasa generyczna (generic class) Klasa służąca jako wzorzec dla innych klas, klasa parametryzowana, klasa szablonowa.

klasa konkretna (concrete class) Klasa, która może posiadać bezpośrednie wystąpienia obiektów.

klasa kontenerowa (container class) Klasa, której wystąpieniami są kontenery (kolekcje) obiektów. Przykładami klas kontenerowych są stosy, kolejki, listy i tablice.

klasa macierzysta (parent class) Patrz: nadklasa.

klasa mieszana (mixin class) Klasa abstrakcyjna, która jest używana w celu uzupełnienia interfejsu lub funkcjonalności innych klas. Klasa mieszana wymaga wielodziedziczenia.

klasa opóźniona (deferred class) Klasa abstrakcyjna, w której zakłada się, że pewne cechy (atrybuty, operacje) muszą być zdefiniowane lub zaimplementowane w jej specjalizacjach.

klasa parametryzowana (parameterised class) Metaklasa posiadająca parametr (lub parametry) taki jak klasa, atrybut, komunikat, operacja, wyjątek, inwariant. Wyrażenie będące odwołaniem się do klasy parametryzowanej z określonym parametrem aktualnym jest traktowane jako definicja normalnej klasy, która może służyć np. do tworzenia instancji obiektów i do tworzenia klas podrzędnych.

klasa pasywna (passive class) Klasa, której wystąpieniami nie są obiekty aktywne. Obiekty klasy pasywnej nie przejawiają żadnej aktywności do momentu otrzymania komunikatu, zaś po wykonaniu operacji implikowanej przez komunikat nie zmieniają

89


swojego stanu aż do następnego komunikatu. Przeciwieństwo: klasa aktywna.

klasa pochodna (derived class) Termin posiada dwa znaczenia: (1) Klasa, która może być wyliczona lub wydedukowana z innych klas; (2) Klasa będąca specjalizacją innej klasy, podklasa.

klasa potomna (child class) Klasa będąca bezpośrednią specjalizacją danej klasy.

klasa szablonowa (template class) Klasa generyczna, klasa parametryzowana, klasa służąca do konstruowania klas.

klasa trwała (persistent class) Klasa, której wystąpieniami są obiekty trwałe.

klasa wbudowana (built-in class) Dowolna klasa stanowiąca nieodłączną część danego języka programowania.

klasa zabezpieczona (protected class) Klasa, której własności (np. metody) są dostępne wyłącznie dla jej podklas.

klasa zaprzyjaźniona (friend class) Termin języka C++ oznaczający klasę, która posiada dostęp do prywatnych własności innej klasy.

klasa-odpowiedzialność-współpraca (Class-Responsibility-Collaborator CRC) Patrz: CRC.

klaster (cluster) Ogólnie, oznaczenie agregatu pewnych składowych występujące w różnych kontekstach. Inaczej grono.

klasyfikacja (classification) Abstrakcja w danych, gdzie nazwany zbiór obiektów o podobnych własnościach uważa się za obiekt na wyższym poziomie abstrakcji. Klasyfikację określa się także jako tworzenie pewnego bytu (językowego lub programistycznego), gromadzącego niezmienne cechy (inwarianty) pewnego zbioru obiektów.

klasyfikacja dynamiczna (dynamic classification) Patrz: dynamiczna klasyfikacja.

klasyfikacja statyczna (static classification) Patrz: statyczna klasyfikacja.

klient (client) Byt (obiekt, klasa, aplikacja), który wysyła zlecenia na wykonanie pewnych usług.

klient-serwer (client/server, client-server, C/S) Architektura komputerów lub oprogramowania, charakteryzująca się podziałem na część określaną jako serwer, której zadaniem jest realizacja usług (np. dostępu do bazy danych) i część określaną jako klient, która zleca te usługi. Zwykle serwer realizuje dostęp do centralnej bazy danych (np. poprzez SQL), zaś po stronie klienta znajduje się obsługa interfejsu użytkownika. Architektura klient-serwer znacznie podnosi ogólną wydajność systemu i dostępność bazy danych. Istnieje wiele jej odmian, które w różnym stopniu spełniają powyższe

90


kryteria, w szczególności architektura, w której po stronie klienta znajduje się lokalna baza danych (obsługiwana przy pomocy tego samego SZBD), oraz architektura klient-multi-serwer, w której klient może zwracać się ze zleceniami obsługi do wielu serwerów.

klonowanie (cloning) Termin wiązany z ponownym użyciem (reuse): skopiowanie pewnego aktywu ponownego użycia celem jego zmodyfikowania i użycia w innym miejscu.

klub fanów zapytania 2+2 (2+2 query fan club) Klub założony przez P. Bunemana propagujący pogląd, że w dowolnym języku zapytań (w szczególności obiektowym) powinno dać się prosto wyrazić zapytanie 2+2. Powyższe radykalne stanowisko klubu jest ignorowane przez kręgi komercyjne związane z systemami obiektowo-relacyjnymi i z nowym standardem SQL3. Panuje tam pogląd, że dostatecznie wygodnym sposobem realizacji zapytania 2+2 jest: (1) utworzenie nowej relacji R o dowolnej strukturze; (2) wstawienie do relacji R jednej krotki o dowolnej zawartości; (3) napisanie zapytania: select 2+2 from R. Część firm odstąpiła od standardu dopuszczając postać: select 2+2. Podkreśla się jednak, że sugerowana przez klub postać 2+2 jest niedopuszczalna, gdyż brak select, from i where spowoduje totalny mętlik w głowach tysięcy programistów pracujących w SQL. Patrz też: kompozycyjność.

klucz (key) Atrybut lub kilka atrybutów, których wartości identyfikują obiekt w sposób unikalny.

klucz główny (primary key) Klucz kandydujący wybrany przez projektanta lub programistę jako podstawa unikalnej identyfikacji obiektu w świecie zewnętrznym, modelowanym przez bazę danych; np. NumerPESEL dla obiektów ObywatelPolski. Klucz pierwotny jest często podstawą implementacji fizycznej, np. organizacji opartej na kodowaniu mieszającym (hashing).

klucz kandydujący (candidate key) Minimalny zestaw atrybutów, których wartości identyfikują obiekt w sposób unikalny. Może się zdarzyć, że obiekty danej klasy posiadają wiele kluczy kandydujących.

klucz obcy (foreign key) Atrybut tablicy relacyjnej, którego wartość jest wartością klucza głównego (primary key) pewnej tablicy relacyjnej (niekoniecznie innej). Dla przykładu, NR_DZIAŁU (klucz główny tablicy DZIAŁ) jest kluczem obcym dla tablicy PRACOWNIK.

klucz pierwotny (primary key) Patrz: klucz główny.

klucz prosty (simple key) Klucz składający się z pojedynczej wartości (atrybutu)

klucz wtórny (secondary key) Dowolny atrybut (lub ich zestaw) stanowiący podstawę techniki implementacji obiektów lub metod usprawnienia dostępu do obiektów, np. indeksów.

91


klucz złożony (aggregate key, compound key, composite key) Klucz składający się z dwóch lub większej ilości wartości (atrybutów).

kod bajtowy (bytecode) Pośredni kod znakowy powstający w wyniku kompilacji języków takich jak Java. Kod ten jest następnie interpretowany przez maszynę wirtualną, np. JVM. Zasadniczą cechą kodu bajtowego jest jego przenaszalność (portability), czyli pełna niezależność od platformy sprzętowej lub programowej.

koercja (coercion) Określenie funkcji zmieniającej typ pewnej wartości, np. funkcja zmieniająca wartość typu integer na odpowiadającą jej wartość typu string. Niektórzy autorzy nazywają koercją przekształcenia typu dokonywane przez mechanizm językowy implicite, automatycznie; np. jeżeli X jest typu integer, zaś Y typu real, to przy obliczaniu wyrażenia X+Y następuje automatyczna koercja X do typu real. Takie rozumienie koercji kojarzy to pojęcie z polimorfizmem ad hoc.

kohezja (cohesion) Zwartość, spoistość. Terminu tego używa się w odniesieniu do klasy lub modułu na oznaczenie wzajemnego zintegrowania procedur, metod, składowych architektury, itp. Duża kohezja oznacza silną interakcję wewnątrz modułu lub klasy i relatywnie słabszą interakcję z zewnętrzem. Klasy powinna cechować duża kohezja. Kohezja jest również podstawową cechą pozwalającą na wyróżnienie składowych architektonicznych dowolnego systemu.

kolaboracja (collaboration) Związek wewnątrz zestawu klas odzwierciedlający fakt, że jest on przeznaczony do określonego celu. Związkek może mieć charakter asocjacji, agregacji lub przekazywania komunikatów. Synonim: współpraca.

kolekcja (collection, set) Byt programistyczny (np. obiekt) składający się z wielu podobnych elementów o nieznanej z góry liczbie elementów. W terminologii ODMG jest to określenie wartości lub zestawu obiektów utworzonych poprzez zastosowanie konstruktorów typów, takich jak: zbiór, wielozbiór, sekwencja i (dynamiczna) tablica. Patrz też: typ masowy.

kompletność obliczeniowa (computational completeness, Turing completeness, Turing power) Charakterystyka ustalająca moc języka programowania na poziomie ustalonym przez maszynę Turinga. Temat ten pojawił się w obiektowości w związku z brakiem kompletności obliczeniowej języka SQL (prowadzącej do wady określanej jako „niezgodność impedancji”). Autorzy manifestu obiektowych baz danych wprowadzili więc kompletność obliczeniową jako podstawowy postulat obiektowych języków programowania aplikacji. Niestety, jest to konsekwencja dość istotnego nieporozumienia. Problem polega nie na kompletności obliczeniowej (którą w dowolnym języku, również w SQL, można osiągnąć przy pomocy dość standardowych środków), lecz kompletności pragmatycznej, czyli pełnych możliwości w zakresie przetwarzania trwałych i nietrwałych struktur danych, obsługi infrastruktury zewnętrznej systemu oraz dostarczenia wszelkich oczekiwanych przez programistę udogodnień i abstrakcji programistycznych (typów, klas, procedur, funkcji, itd.). Mimo wprowadzenia postulatu kompletności obliczeniowej, obecne systemy obiektowych baz danych opierają się na bardzo podobnym do filozofii SQL eklektycznym połączeniu

92


dwóch lub więcej języków, np. w standardzie ODMG „niekompletnego obliczeniowo” ODL/OQL z „kompletnym obliczeniowo” C++. Pełna kompletność pragmatyczna jest niedefiniowalna i nierealizowalna. Istotnym jej przybliżeniem jest bezszwowa integracja języka zapytań z konstrukcjami programistycznymi, realizowana obecnie np. w SQL3. Synonimy: moc Turinga, kompletność Turinga.

kompletność relacyjna (relational completeness) Wprowadzony przez E.F.Codda wzorzec uniwersalności języków zapytań, oznaczający te możliwości, które daje algebra relacji. Niegdyś systemy miały problemy ze spełnieniem tego warunku, w związku z czym ten wzorzec miał znaczenie w rozwoju języków zapytań. W istocie jednak relacyjna kompletność jest dowolnym (nie umotywowanym jakimkolwiek pragmatycznym kryterium) punktem na wieloaspektowej skali uniwersalności języków zapytań. Języki zrealizowane we współczesnych systemach relacyjnych (np. SQL, SQL3) są znacznie mocniejsze od języków relacyjnie kompletnych, wobec czego ten wzorzec utracił jakiekolwiek znaczenie nawet w obrębie systemów relacyjnych. Istnieją próby ustalenia podobnego wzorca dla obiektowych języków zapytań; nie wydaje się jednak, aby miały one jakiekolwiek znaczenie dla rozwoju tej dziedziny.

kompletność Turinga (Turing completeness) Patrz: kompletność obliczeniowa.

komponent (component) Stosunkowo mały fragment oprogramowania wykonujący specyficzną funkcję, taką jak edytowanie tekstu lub udostępnianie dokumentu. Pojęcie komponentu staje się coraz bardziej popularne w związku z technologiami związanymi ze standardem CORBA, opartym o ten standard OpenDoc, technologią OLE2/COM/DCOM/ActiveX oraz technologią JavaBeans, które umożliwiają tworzenie dużych aplikacji poprzez składanie ich z niezależnych i niezależnie zbudowanych komponentów. Uważa się, że terminy „komponent” i „aktywny obiekt” są synonimiczne, ale niektóre technologie mogą te pojęcia różnicować. Technologie oparte o komponenty i programowanie komponentowe są ostatnio bardzo nagłośnione w literaturze, szczególnie komercyjnej; mowa jest nawet o tym, że komponenty są następnym paradygmatem w informatyce, który zastąpi obiektowość. W tych stwierdzeniach jest nieco przesady, gdyż jak się wydaje, komponenty i obiektowość są pojęciami ortogonalnymi; komponenty mogą istnieć bez obiektowości i vice versa. Należy również zwrócić uwagę, że temat komponentów istniał w informatyce od bardzo dawna pod innymi hasłami (mega-programming, programming-in-the-large), zaś cały problem z tym stylem programowania polega na wypracowaniu standardów łączenia fragmentów oprogramowania. Te standardy stosunkowo łatwo osiągnąć na niskim poziomie abstrakcji, np. na poziomie interfejsów w Java, COM lub CORBA IDL, natomiast bardzo trudno osiągnąć na poziomie wysoko zaawansowanych technologii, takich jak interfejsy do baz danych (włączające modele danych i języki zapytań), wyspecjalizowane biblioteki klas, pakiety statystyczne, hurtownie danych, itd. Z tego powodu obecne nagłośnienie tematu komponentów należy uważać za bardzo pozytywne, gdyż będzie ono sprzyjać rozwojowi w/w standardów, ale nie należy oczekiwać, że komponenty same z siebie automatycznie rozwiążą problem dowolnego łączenia oprogramowania w spójne aplikacje.

http://www.corbajava.engr.sjsu.edu

93


kompozycja (composition) Mocna forma agregacji wprowadzona w UML. Związek kompozycji oznacza, że dana część może należeć tylko do jednej całości. Co więcej, część nie może istnieć bez całości, pojawia się i jest usuwana razem z całością. Klasycznym przykładem związku kompozycji jest zamówienie i pozycja zamówienia: pozycja zamówienia nie występuje oddzielnie (poza zamówieniem), nie podlega przenoszeniu od jednego zamówienia do innego zamówienia i znika w momencie kasowania zamówienia.

Wielobok

Punkt

Stylkolor

czyWypełniony

Okrągpromień

{ordered}

3..*

* *

1 1

1Kompozycja

Agregacja

Przykłady kompozycji i agregacji

Powyższy rysunek ilustruje zastosowanie agregacji (pusty w środku romb) i kompozycji (zaczerniony romb). Każde wystąpienie obiektu Punkt należy albo do obiektu Wielobok, albo do obiektu Okrąg; nie może należeć do dwóch obiektów naraz. Wystąpienie obiektu Styl może być dzielone przez wiele obiektów Wielobok i Okrąg. Usunięcie obiektu Wielobok powoduje kaskadowe usunięcie wszystkich związanych z nim obiektów Punkt, natomiast nie powoduje usunięcia związanego z nim obiektu Styl.


kompozycyjność (compositionality) Zasada lub własność języka (programowania, zapytań, itd.) oznaczająca możliwość budowy dużych wyrażeń z małych składowych syntaktycznych i semantycznych, oraz możliwość dowolnego kombinowania tych wyrażeń poprzez dostępne operatory (ograniczonego jedynie przez typy). Przykładem języka nie spełniającego zasady kompozycyjności jest SQL, gdzie np. nie można zbudować wyrażenia 2+2, pomimo tego, że zarówno stała 2 jak i operator + są elementami tego języka. Kompozycyjność jest szczególnym przypadkiem ortogonalności. Patrz też: klub fanów zapytania 2+2.

komunikat (message) Sygnał skierowany do obiektu wywołujący określoną metodę lub operację, którą należy wykonać na obiekcie. Komunikat może mieć parametry. Komunikat można uważać za wołanie procedury związanej z obiektem, uruchamianej w środowisku (wewnątrz) obiektu i zdefiniowanej i/lub przechowywanej w ramach jego klasy i nadklas. W wielu opracowaniach uważa się, że zarówno komunikat jak nazwy występujące w ciele metody są wiązane dynamicznie, w związku z czym ten sam komunikat może być wysłany do różnych obiektów i może wywołać różne metody (patrz: przesłanianie i polimorfizm). Fakt ten posiada istotne znaczenie dla metod oraz

94


technik projektowania i programowania.

komunikat asynchroniczny (asynchronous message) Komunikat wysłany do obiektu, po którym nadawca komunikatu nie czeka na zrealizowanie operacji implikowanej przez ten komunikat, ale kontynuuje swoje działanie. Skutek wykonania komunikatu asynchronicznego może nie być sprawdzany lub może być sprawdzany w dowolnym późniejszym momencie poprzez inny komunikat, poprzez metodę zwrotną (callback method), lub innymi środkami.

komunikat binarny (binary message) W języku Smalltalk komunikat posiadający jeden argument, gdzie selektorem jest symbol oznaczający operację binarną, np. do obiektu 3 jest wysyłany komunikat binarny + 5 (co w wyniku daje 8).

komunikat kaskadowy (cascaded message) W terminologii języka Smalltalk jednoczesne wysłanie wielu komunikatów do tego samego odbiorcy.

komunikat synchroniczny (synchronous message) Komunikat wywołujący metodę, która blokuje sterowanie innych wątków lub procesów.

komunikat unarny (unary message) Komunikat nie posiadający argumentów.

konceptualny (conceptual) Patrz: pojęciowy.

konflikt nazw (name conflict, name clash) Sytuacja, w której dwa lub więcej bytów programistycznych posiada tę samą nazwę w tym samym zakresie, powodując przy tym niejednoznaczność interpretacji, procesów, wiązania, itd.

konserwacja (maintenance) Patrz: pielęgnacja.

konserwacja oprogramowania (software maintenance) Patrz: pielęgnacja.

konsolidacja (linking) Tworzenie wykonywalnego programu poprzez połączenie półskompilowanych modułów lub plików (zwanych kodem obiektowym (object code)) oraz ustalenie fizycznych adresów alokowanych bytów programów (funkcji, procedur, zmiennych, itd.).

konstruktor (constructor) Operator lub metoda tworząca obiekty.

konstruktor typów (type constructor) Konstrukcja języka programowania lub modelu danych pozwalająca utworzyć typ bardziej złożony z predefiniowanych (wbudowanych) lub już utworzonych typów. Przykłady konstruktorów typów są następujące: struct i union w języku C; array, record, variant i file w języku Pascal; struct, array, sequence, set i bag w ODMG; relation w DBPL i inne. Z reguły, dla danego języka lub modelu zestaw konstruktorów typów jest ustalony (nie może być zmieniony przez programistę). Możliwość definiowania nowych konstruktorów typów posiadają niektóre języki polimorficzne (np. Tycoon).

kontekst kolaboracji (collaboration context) Statyczna struktura obiektów (klas)

95


uczestniczących w kolaboracji, włączając związki, atrybuty i operacje. Patrz też: diagram kolaboracji. Synonim: diagram współpracy.

kontener (container) Agregat (obiekt, ekstensja klasy, itp.) zawierający zestaw obiektów (niekiedy różnych typów). Patrz też: typ masowy i dane masowe.

kontrakt (contract) Dowolna formalna lub półformalna umowa pomiędzy serwerem i jego klientem; precyzyjna specyfikacja usług, odpowiedzialności, asercji, warunków wstępnych i warunków końcowych określająca zobowiązanie pewnego serwera (w tym procedur) wobec jego klientów oraz klientów wobec serwera. Patrz też: projektowanie przez kontrakty.

kontrakt w oprogramowaniu (software contract) Patrz: kontrakt.

kontrawariancja (contravariancy) Przeciwieństwo kowariancji; patrz: kowariancja.

kontrola dostępu (access control) Patrz: sterowanie dostępem.

kontrola dynamiczna (dynamic checking) Kontrola typów podczas czasu wykonania.

kontrola statyczna (static checking) Kontrola typów podczas czasu kompilacji.

kontrola typów (type checking, typing) Oznacza, że każdy deklarowany byt programistyczny musi być wyposażony w deklarację typu. Poprzez tę deklarację programista wyraża swoje oczekiwania co do roli tego bytu w programie. Te oczekiwania są następnie sprawdzane we wszystkich tych miejscach programu, gdzie występuje odwołanie do tego bytu. Np. określając typ zmiennej X jako integer programista ustala, że ta zmienna ma przechowywać wartości całkowite. Dzięki temu możliwe jest sprawdzenie, czy wszystkie odwołania do tej zmiennej w programie mają kontekst, w jakim może być użyta wartość całkowita. Kontrola typów okazała się cechą skutecznie eliminującą błędy popełniane przez programistów. Według typowych szacunków, po wyeliminowaniu błędów syntaktycznych programu około 80% pozostałych błędów jest wychwytywane przez kontrolę typów. Z tego powodu mechanizm ten uzyskał duże znaczenie. Kontrola typów jest często porównywana do sytuacji obserwowanej na tylnej ściance komputera, gdzie znajduje się dużo gniazd o różnym przeznaczeniu. Jeżeli wszystkie miałyby jednakowy format, wówczas bez wątpienia nastąpiłyby pomyłki polegające na wetknięciu wtyczki do niewłaściwego gniazda, np. wtyczki sieciowej do gniazda klawiatury, z dramatycznymi skutkami dla sprzętu. Zróżnicowanie formatów wtyczek uniemożliwia tego rodzaju pomyłki. Analogicznie, brak typu dla procedury (metody, obiektu, atrybutu, itd.) umożliwia użycie jej w nieodpowiednim kontekście, niekiedy z równie dramatycznymi skutkami. Typy uniemożliwiają tego rodzaju sytuacje na zasadzie podobnej do tej, która obowiązuje dla gniazd i wtyczek.

korzeń (root) Najbardziej ogólna klasa w hierarchii dziedziczenia klas, klasa-korzeń. Również obiekt stojący najwyżej w hierarchii obiektów.

96


kostka danych (data cube) Struktura danych stosowana w hurtowniach danych i technologii OLAP; specyficzna reprezentacja relacji umożliwiająca sprawne wykonywanie pewnych operacji, takich przekroje i agregacje danych.

kot (cat) Zgodnie z obserwacjami Jamesa Martina, zwierzę zorientowane obiektowo, czego dowodzi jego umiejętność błyskawicznego rozpoznawania małych szarych obiektów umykających do przeróżnych dziur. Patrz też: pies.

kowariancja (covariancy) Problem dotyczy zgodności typów w przypadku polimorfizmu inkluzyjnego. Załóżmy, że metoda m(A:T), parametryzowana parametrem A typu T, jest zdefiniowana w klasie K. Załóżmy, że klasa K posiada specjalizację (podklasę) K’, w której jest zdefiniowana metoda m(B:T’), parametryzowana parametrem B typu T’; ta nowa metoda przesłania poprzednią. Zakłada się zasadę zamienialności (substitutability) i mocną statyczną kontrolę typów. Powstaje pytanie, jaki ma być stosunek pomiędzy typami T i T’? Istnieją trzy możliwości: inwariancja (C++) oznaczająca, że T musi być identyczny z T’; kowariancja (Eiffel) oznaczająca, że T’ musi być podtypem T (w szczególności

T=T’); kontrawariancja (Sather) oznaczająca, że T’ musi być nadtypem T (w

szczególności T=T’).

Kontrawariancję zaproponował L. Cardelli na podstawie spekulacji teoretycznych dotyczących mocnej kontroli typów i polimorfizmu. Zwolennicy kowariancji uważają, że kontrawariancja jest nienaturalna dla programistów, wobec czego prowadzi do błędów i nieporozumień. Zwolennicy kontrawariancji argumentują, że kowariancja oznacza zmniejszenie skuteczności mocnej statycznej kontroli typów. Wobec różnych kryteriów oceny, często wznawiane dyskusje nie prowadzą do jednoznacznych konkluzji.

kraniec frontowy (front end) Popularne określenie fragmentu systemu obsługującego interfejs użytkownika; inaczej klient wymagający usług od serwera (określanego jako „back end”).

kraniec tylny (back end) Popularne określenie serwera wykonującego usługi na rzecz klienta (określanego jako „front end”).

krata (lattice) Pojęcie matematyczne; zbiór uporządkowany (X, ≤), w którym istnieje pojedynczy element będący kresem górnym i pojedynczy element będący kresem dolnym. Taki zbiór można zaprezentować jako graf acykliczny. Ta wizualna analogia jest pretekstem do (pochopnej) formalizacji, w której graf dziedziczenia klas uwzględniający wielodziedziczenie jest uważany za „kratę” (lub „półkratę”).

krotka (tuple) Element matematycznej relacji (będącej podzbiorem produktu kartezjańskiego pewnych dziedzin) będący ciągiem wartości. Krotka w modelu relacyjnym baz danych odpowiada tradycyjnemu pojęciu zapisu (record). Krotka jest wierszem tablicy w relacyjnej bazie danych. W żargonie osób związanych z językami C, C++ i pochodnych (np. standardu ODMG) termin ten jest również używany

97


wymiennie ze słowem „struktura” (structure).

krotność (multiplicity) Patrz: liczność.

krytyka (critique, flame) Istnieje ogromna liczba uwag krytycznych w stosunku do obecnych pojęć, języków, standardów i systemów obiektowych; patrz np.:

http://minsky.med.virginia.edu/sdm7g/LangCrit/http://gameboy.gia.rwth-aachen.de/odmgbugs/

Patrz też: bzdura.

kryzys oprogramowania (software crisis) Zespół negatywnych zjawisk towarzyszących produkcji, eksploatacji i pielęgnacji oprogramowania. Podkreślane są następujące znamiona tego kryzysu: Sprzeczność pomiędzy ogromną odpowiedzialnością, jaka spoczywa na

współczesnych systemach informatycznych, a ich zawodnością. Złożoność oprogramowania i niedojrzałe metody jego tworzenia i weryfikacji. Ogromne koszty utrzymania oprogramowania. Niska kultura ponownego użycia wytworzonych komponentów projektów i

oprogramowania; niski stopień powtarzalności poszczególnych przedsięwzięć. Długi i kosztowny cykl tworzenia oprogramowania, wysokie prawdopodobieństwo

niepowodzenia projektu programistycznego. Eklektyczny, nieregularny, niesystematyczny zestaw narzędzi i języków

programowania. Nieprzejrzystość wytworzonego oprogramowania; ogromna trudność

przystosowania go do zmieniających się wymagań. Frustracje projektantów oprogramowania i programistów wynikające ze zbyt

szybkiego postępu w zakresie języków, narzędzi i metod oraz uciążliwości i długotrwałości procesów produkcji, utrzymania i pielęgnacji oprogramowania.

Uzależnienie organizacji od systemów komputerowych i przyjętych technologii przetwarzania informacji, które nie są dostatecznie stabilne w długim horyzoncie czasowym.

Problemy współdziałania niezależnie zbudowanego oprogramowania, szczególnie istotne przy dzisiejszych tendencjach integracyjnych.

Problemy systemów „spadkowych” (legacy), czyli przystosowanie istniejących i działających systemów do nowych wymagań, tendencji i platform sprzętowo-programowych.

Główną misją obiektowości jako zjawiska ideologicznego i kulturotwórczego w informatyce jest walka z kryzysem oprogramowania.

kursor (cursor) Wskaźnik przesuwający się wzdłuż pewnej kolekcji elementów i wskazujący element „bieżący” (current); element ten podlega następnie odczytaniu lub przetwarzaniu. Wskaźnik ten często nie występuje explicite (np. w SQL), lecz jest pewną myślową abstrakcją. Wskaźnik jest przesuwany przy pomocy funkcji takich jak DajPierwszyElement, DajNastępnyElement, DajPoprzedniElement, itp. Kursor jest odmianą lub synonimem iteratora.

98


LL

leniwa ewaluacja (lazy evaluation) Ewaluacja pewnego wyrażenia (np. parametru procedury), która jest dokonywana dopiero wtedy, gdy jest to niezbędne do dalszego kontynuowania programu. Patrz też: wołanie poprzez potrzebę.

leniwa inicjalizacja (lazy initialization) Inicjalizacja zmiennej lub obiektu, która jest dokonywana dopiero wtedy, gdy staje się to potrzebne.

Liana Obiektowe środowisko rozwoju oprogramowania oraz obiektowy język programowania podobny do C/C++, ale interpretowany, bardziej elastyczny i łatwiejszy do użycia. Liana jest przeznaczona do programowania w środowisku MS Windows.

liczba kardynalna (cardinality) Pojęcie matematyczne; ilość elementów pewnego zbioru.

liczność (cardinality, multiplicity) Charakterystyka liczbowa kojarzona ze związkiem (asocjacją). Przyjmując, że związek łączy klasy A i B, liczność określa ilość obiektów klasy A, które mogą być powiązane z jednym obiektem klasy B i vice-versa. Liczność jest zwykle wyrażana w postaci pary symboli: minimalnej liczby powiązanych obiektów (zwykle zero lub jeden) oraz maksymalnej ich liczby (zwykle jeden lub dowolnie wiele); np. jeżeli związek A i B charakteryzują liczności [0,1] i [0,n], to oznacza, że z jednym obiektem klasy A może być związane 0 lub dowolna (skończona) liczba obiektów klasy B, zaś z jednym obiektem klasy B może być związane 0 lub 1 obiekt klasy A. Oznaczenia liczności na diagramach są istotną informacją dla technik analizy i projektowania systemów informatycznych. Oznaczenia te przyjmują bardzo różną formę w zależności od przyjętej notacji lub metodyki. Niżej prezentujemy oznaczenia liczności przyjęte w UML.

A B: min = 1, max = 1

Oznaczenia liczności nadiagramie klas:

A A AA A

B B B

A

B

1..*

B A: min = 1, max = n

B B B

A

B

0..*

1..*

A A AA A

B: min = 1, max = nA

A: min = 0, max = nB

B B B

A

B

0..*

0..1

A A AA A

B: min = 0, max = 1A

A: min = 0, max = nB

Oznaczenia liczności w UML

99


linia życia obiektu (object lifeline) W diagramach sekwencji jest to linia (zwykle pionowa) lub wąski prostokąt, gdzie odnotowuje się utworzenie obiektu, zdarzenia lub komunikaty, które on otrzymuje, oraz skasowanie obiektu; patrz: diagram sekwencji.

lista eksportowa (export list) W terminologii niektórych obiektowych i modularnych języków programowania (np. Eiffel lub Modula-3) jest to wyrażenie językowe ustalające, które składowe klasy lub modułu są dostępne z zewnątrz.

lista importowa (import list) W terminologii modularnych języków programowania, lista składowych innych modułów (zmiennych, typów, procedur, itd.), które mogą być używane w danym module.

literal (literal) Patrz: literał.

literał (literal) Zwykle, jednostka leksykalna języka oznaczająca wartość, którą programista wpisuje w tekst programu (np. znak 5 lub string „ach jak przyjemnie”). W standardzie ODMG literałem nazwano dowolną (być może złożoną) wartość, której nie można zmienić (czyli stałą); poza tą cechą, literał nie różni się od obiektu. Taka definicja pojęcia literału wzbudziła kontrowersje ze względu na splątanie czterech różnych bytów syntaktyczno/semantycznych: jednostki leksykalnej tekstu programu, stałej (nieaktualizowalnego obiektu) występującej w programie, atrybutu obiektu i wartości zwracanej przez wyrażenie lub funkcję.

logika biznesu (business logic) Algorytmy, reguły, ograniczenia, metody, operacje itd., które odnoszą się do dziedziny przedmiotowej (dziedziny biznesu, któremu jest dedykowany dany system informatyczny), a nie do wewnętrznych czynności związanych z funkcjonowaniem systemu informatycznego, takich jak obsługa interfejsu użytkownika lub dostęp do bazy danych.

Loglan Obiektowy język programowania zaprojektowany i zaimplementowany w Instytucie Informatyki Uniwersytetu Warszawskiego (rozwijany następnie na Uniwersytecie w Pau, Francja). Służył głównie do celów dydaktycznych. Pierwsza wersja była oznaczona Loglan’82, następna Loglan-88. Loglan posiada klasy, obiekty, korutyny, procesy (są one obiektami, które mogą działać równolegle), dziedziczenie, obsługę wyjątków, dynamiczne tablice, itd. Loglan wspomaga programowanie funkcjonalne i programowanie poprzez reguły.

http://www.univ-pau.fr/~salwicki/loghome.htmhttp://sunsite.icm.edu.pl./pub/programming/loglan/HTML/

Loqis Prototypowy system zarządzania obiektową bazą danych zaprojektowany i zrealizowany w Instytucie Podstaw Informatyki PAN w Warszawie (1990). Wprowadza obiekty oraz dziedziczenie w wersji tzw. wizjerów (odmiana prototypów); oparty w całości o obiektowy język zapytań SBQL zintegrowany z konstrukcjami imperatywnymi i środowiskiem programistycznym. SBQL jest językiem o znacznie większej mocy wyszukiwawczej od SQL i OQL wg standardu ODMG. Koncepcja SBQL opiera się o nową teorię obiektowych języków zapytań określaną jako podejście stosowe (stack-based approach).

100


http://www.ipipan.waw.pl/~subieta

LotusNotes System przechowywania dokumentów elektronicznych i zarządzania dokumentami wspomagający pracę grupową (patrz: CSCW). Posiada niektóre cechy obiektowości. Jest rozpowszechniany przez IBM.

LSP (Liskov Substitution Principle) Zasada zamienialności B.Liskov. Patrz: zamienialność.

luźne powiązanie (loose coupling) Powiązanie pomiędzy językiem zapytań i językiem programowania, w którym występują odrębne przestrzenie nazw dla języka zapytań i dla języka programowania, zaś zapytania są komunikowane jako parametry stringowe dla pewnych procedur lub metod. Ten rodzaj powiązania charakteryzuje interfejsy programistyczne oparte o SQL. Jest także założeniem standardu ODMG. Skutkiem luźnego powiązania jest niezgodność impedancji (występująca w większym lub mniejszym stopniu).

l-wartość (l-value) Synonim referencji, wynik wyrażenia, które po ewaluacji zwraca referencję do pewnego bytu programistycznego (obiektu, zmiennej, atrybutu, itd.). L-wartość może pojawić się po lewej stronie operacji podstawienia (stąd l-wartość, od left), może być obliczonym parametrem aktualnym przy wołaniu poprzez referencję, argumentem operacji delete (usuń), itd. Przeciwieństwem l-wartości jest r-wartość (od słowa right).

MM

magazyn danych (data mart, data warehouse) Patrz: hurtownia danych.

MainstreamObjects Obiektowa metodyka analizy i projektowania systemów informatycznych opracowana przez Yourdona i innych.

manifest (manifesto) Ogólnie, dokument precyzujący założenia, program i hasła pewnej szkoły lub ideologii. Model relacyjny lub obiektowość w swojej istocie mają charakter doktryn ideologicznych postulujących pożądany kierunek rozwoju informatyki. Historię manifestów w dziedzinie baz danych początkuje słynne 12 reguł „prawdziwego” systemu relacyjnego, zredagowane przez jego twórcę E.F.Codda. Jak się okazuje, „prawdziwego” systemu relacyjnego nie ma (i chyba już nigdy nie będzie). Istotną rolę w rozwoju obiektowości odegrał manifest obiektowych systemów baz danych autorów: Atkinson, Bancilhon, DeWitt, Dittrich, Maier, Zdonik, który zrywając z ideologią modelu relacyjnego ustalił ramowe założenia obiektowości w bazach danych. Manifest postulował zachowanie klasycznych cech baz danych (trwałość, zarządzanie pamięcią pomocniczą, współbieżność, transakcje, odtwarzanie, rozproszenie, języki zapytań i inne), przystosowując je do cech obiektowości (złożone obiekty, tożsamość obiektów, hermetyzacja, typy lub klasy, dziedziczenie, przesłanianie połączone z dynamicznym wiązaniem, rozszerzalność). Reakcją na ten manifest był

101


tzw. „manifest systemów baz danych trzeciej generacji” grupy konserwatywnych zwolenników obecnej filozofii systemów relacyjnych (Stonebrakera i innych), postulujący zachowanie wszystkich potwierdzonych w praktyce cech modelu relacyjnego (w szczególności SQL jako „intergalaktycznego języka danych”) i wzmocnienie go o nowe własności, m.in. obiektowe. Dokument cechuje arbitralność wyboru postulowanych cech i nieco demagogiczna retoryka. Do kolekcji manifestów można jeszcze dorzucić tzw. „trzeci manifest” Darwena i Date’a, gdzie autorzy odrzucają zarówno obiektowość jak i SQL, proponując powrót na łono 12-tu reguł i ideologicznie czystego modelu relacyjnego. Dokument zawiera wiele postulatów kontrowersyjnych, pobożnych życzeń i demagogicznych argumentów, jest więc obliczony na raczej słabo zorientowanego czytelnika.

Manifesty w dziedzinie baz danych są odpowiedzią na brak naukowych i technologicznych kryteriów, które mogłyby obiektywnie wyznaczyć kierunki rozwoju tej dyscypliny. W tej sytuacji ekspert lub grupa ekspertów stawia się w roli proroka, próbującego a priori dyktować światu, jak ma budować swoją przyszłość. Niezbywalną cechą wszystkich manifestów - od komunistycznego do obiektowego - jest to, że większość wymienianych w nich postulatów jest rozsądna i zgodna z powszechnym odczuciem dobrego. Jest to psychologiczna baza, na której mogą być przemycone cechy utopijne, kontrowersyjne, lub nieakceptowalne. Zatem w stosunku do wszelkich manifestów należy zachować sporo rezerwy i sceptycyzmu. To właśnie mówi ostatnia doktryna manifestu obiektowych baz danych, nakazująca obowiązek kwestionowania wszystkich poprzednich doktryn tego manifestu.

manifest obiektowych systemów baz danych (Object-Oriented Database System Manifesto) Dokument opracowany przez autorów: Atkinson, Bancilhon, DeWitt, Dittrich, Maier, Zdonik (1989) formułujący podstawowe założenia obiektowych baz danych w postaci charakterystyk, które są podzielone na trzy grupy: Obowiązkowe, czyli takie, które musi posiadać każdy system zarządzania bazą

danych określany mianem „obiektowy”. Do nich należą: złożone obiekty, tożsamość obiektów, hermetyzacja, typy lub klasy, dziedziczenie, przesłanianie wraz z późnym wiązaniem, rozszerzalność, kompletność obliczeniowa, trwałość, zarządzanie pamięcią pomocniczą, współbieżność, odtwarzanie oraz udogodnienia dla zapytań ad hoc.

Opcyjne, czyli takie, które nie są obowiązkowe, ale które mogą podnieść jakość systemu. Do nich zaliczono: wielokrotne dziedziczenie, kontrolę typów i wnioskowanie o typie, rozproszenie bazy danych, transakcje projektowe (długie lub zagnieżdżone) oraz wersje.

Otwarte, czyli takie, gdzie projektanci systemów mają pewną dowolność co do ich wyboru. Do nich zaliczono: paradygmat programowania, system typów, system reprezentacji oraz zuniformizowanie.

Patrz też: manifest.

manifest systemów baz danych trzeciej generacji (Third-Generation Database System Manifesto) Manifest będący reakcją na pojawienie się manifestu obiektowych baz danych zrywającego z założeniami modelu relacyjnego (co, jak można się domyśleć, wprowadziło pewną nerwowość w kręgach dostawców systemów

102


relacyjnych). Został on opracowany przez następujących autorów: Stonebraker, Rowe, Lindsay, Gray, Carey, Brodie, Bernstein, Beach (1990). Manifest systemów baz danych trzeciej generacji (3GDB) zawiera trzy doktryny: 3GDB muszą wspomagać bogatsze struktury danych i reguły. 3GDB muszą posiadać wszystkie pozytywne cechy baz danych drugiej generacji. 3GDB muszą być otwarte dla innych systemów.

oraz 13 postulatów: 3GDB muszą posiadać bogaty system typów. Dziedziczenie jest dobrym pomysłem. Funkcje (w tym zapamiętane procedury i metody) plus hermetyzacja są dobrymi

pomysłami. Unikalne identyfikatory powinny być stosowane wtedy, gdy nie są dostępne klucze

główne. Reguły (wyzwalacze, więzy integralności) staną się główną cechą przyszłych

systemów. Cały dostęp do bazy danych powinien odbywać się poprzez nieproceduralny język

wysokiego poziomu. Kolekcje powinny być specyfikowane zarówno przez ich nazwę, jak i poprzez

zapytanie. Chodzi o to, aby istniała możliwość przetwarzania kolekcji wyprodukowanych przez zapytanie, a nie tylko kolekcji zapamiętanych w bazie danych.

Aktualizowalne perspektywy (views) są istotne. Własności fizyczne nie mają związku z modelem danych i powinny być z niego

usunięte. 3GDB muszą być dostępne z wielu języków wysokiego poziomu. Języki te powinny być wyposażone w cechę trwałości i zintegrowane z językiem

zapytań. Na lepsze i gorsze, SQL jest intergalaktycznym językiem danych. Zapytania i odpowiedzi na zapytania powinny być dolnym poziomem komunikacji

klient-serwer (chodzi o to, aby ten poziom nie ograniczał się do przesyłania fizycznych stron).

Patrz też: manifest.

mapa bitowa (bitmap) Plik lub struktura zawierająca długi ciąg bitów reprezentujący przedstawianą na ekranie (lub na papierze) informację graficzną. Mapą bitową jest np. zdjęcie, zapisaną w pewnym formacie dla reprezentowania obrazów (BMP, TIFF, GIF, JPEG, itd.).

Martin, James Autor książek z zakresu obiektowości; współtwórca metodyki Martin/Odell.

Martin/Odell Obiektowa metodyka analizy i projektowania systemów informatycznych, Patrz: OOAD [2].

103


masowy (bulk) Określenie typu (bulk type), danej (bulk data), atrybutu (bulk attribute), itd., który definiuje lub zawiera zbiór (wielozbiór, sekwencję, tablicę) elementów o nieznanych i nieprzewidywalnych rozmiarach.

maszyna abstrakcyjna (abstract machine) W teorii, formalna (matematyczna) podstawa semantyki operacyjnej pewnego języka, która składa się ze struktury zwanej stanem oraz z zestawu instrukcji (funkcji) zmieniających stan. Semantyka języka jest matematycznym odwzorowaniem struktur składniowych na sekwencje instrukcji maszyny abstrakcyjnej. Ta koncepcja jest przenoszona na grunt praktyczny (np. w Java) poprzez tworzenie języka pośredniego (zwykle znakowego), w którym zapisuje się wynik kompilacji. Kod pośredni jest następnie interpretowany przez maszynę wirtualną, która posiada dobrze zdefiniowane elementy składające się na jej stan, oraz pewien zestaw instrukcji (procedur) o dobrze zdefiniowanej i wyizolowanej semantyce.

maszyna stanowa (state machine) Patrz: maszyna ze stanami.

maszyna wirtualna (virtual machine) Interpreter kodu pośredniego, zwykle znakowego, generowanego jako wynik kompilacji programów w pewnym języku, np. w Java. Termin i metoda są znane od dość dawna, ale ostatnio zyskały popularność w związku z językiem Java i maszynami wirtualnymi (JVM), przystosowanymi do interpretowania kodu pośredniego (apletów) tego języka, wbudowanymi w popularne przeglądarki WWW, np. w Netscape.

maszyna wirtualna języka Java (Java Virtual Machine, JVM) Patrz: maszyna wirtualna.

maszyna ze stanami (state machine) Chodzi o pewną odmianę automatu skończonego lub innego mechanizmu opartego o stany i przejścia pomiędzy stanami.

Matisse Obiektowy system zarządzania bazą danych zrealizowany przez Matisse Software, Inc.

mechanizm obsługi wyjątków (exception handler) Algorytmy, struktury danych oraz inne cechy programistyczne zapewniające rejestrację wyjątków i uruchamianie odpowiednich kodów programów jako reakcji na pojawiające się wyjątki.

mechanizm zbierania nieużytków (garbage collector, GC) Fragment oprogramowania zajmujący się zbieraniem nieużytków; odśmiecacz. Patrz: zbieranie nieużytków.

mediator (mediator) Moduł oprogramowania, którego celem jest rozstrzygnięcie niezgodności w organizacji danych i sposobach/językach dostępu przy łączeniu heterogenicznych baz danych w jedną całość. Zadaniem mediatora jest uproszczenie, wyabstrahowanie, zredukowanie, scalenie, ujednolicenie i wyjaśnienie semantyki danych widzianych w systemie heterogenicznym oraz odpowiednia konwersja funkcji działających na danych, z zachowaniem spójności wszystkich operacji wyszukiwania i aktualizacji. Mediator dokonuje konwersji tych operacji z postaci obowiązującej w

104


danym systemie na operacje w innym systemie, oraz odpowiednio dokonuje konwersji wyników tych operacji uzyskanych w innym systemie na wyniki odpowiednie dla danego systemu. Zasady konstrukcji mediatorów nie są do końca jasne; ich autorzy powołują się np. na metody sztucznej inteligencji (nie precyzując na czym one polegają). Wydaje się, że w większości nietrywialnych przypadków mediator musi być pisany techniką odwołującą się do pojęć dość niskiego poziomu. Pojęciami bardzo zbliżonymi do mediatora są: osłona (wrapper) i perspektywa (view); stosunek znaczeń tych trzech pojęć nie jest jasny i zmienia się w zależności od autora.

Melton, Jim Główny architekt nowo powstającego standardu SQL3 opracowywanego przez ANSI.

metadane (metadata) Wszelkie dane opisujące zawartość bazy danych: schemat, podschematy poszczególnych użytkowników, typy danych, opis semantyki danych, opis rozmieszczenia i organizacji fizycznej danych, liczności i statystyki dotyczące danych i ich wykorzystania, prawa dostępu do danych, itd.

metafora (metaphor) Zestaw pojęć, terminów, wyobrażeń, obiektów, itd. dobrze rozumianych przez ludzi, który służy jak podstawa koncepcji pewnego interfejsu użytkownika, sprzyjając przy tym łatwiejszemu rozumieniu i użyciu funkcji systemu. Np. w systemach opartych o SQL metaforą jest pojęcie tabeli i operacji na tabelach. Metaforą jest również pojęcie obiektu, aktywnego agenta, zdarzenia, nawigacji, itd.

metaklasa (metaclass) Termin języka Smalltalk oznaczający taką klasę, której wystąpieniami są klasy.

metamodel (metamodel) W założeniu, model definiujący składnię, semantykę i pragmatykę wprowadzanego modelu, notacji lub diagramu. Metamodel proponowany przez autorów UML ustala pewne elementy składni diagramów, ograniczenia typologiczne, klasyfikację pojęć oraz związki pomiędzy pojęciami. Analogią może tu służyć „metamodel” BNF, polegający na zapisie notacji BNF w BNF. Metamodel UML nie jest jednak w stanie odwzorować jego semantyki z formalną, „algorytmiczną” precyzją wymaganą przez matematykę lub przez dowolną maszynę. Niemniej, stojąc na stanowisku, że notacje takie jak UML będą służyć głównie do komunikacji pomiędzy ludźmi, metamodel może nieco wyjaśnić i uściślić.


metoda [1] (method) Procedura, funkcja lub operacja przypisana do klasy obiektów i dziedziczona przez jej podklasy. Metoda jest abstrakcją programistyczną tej samej kategorii co procedura lub procedura funkcyjna. Metoda różni się od procedury tym, że działa w środowisku obiektu (wykorzystując jego wewnętrzne informacje, przede wszystkim wartości atrybutów) po wysłaniu do niego komunikatu zawierającego jej nazwę. Zakłada się, że (podobnie do wołania procedury) komunikat składa się z nazwy metody oraz parametrów. Z koncepcyjnego punktu widzenia miejscem przechowywania metody jest odpowiednia klasa; oznacza to, że taka metoda może być zastosowana do dowolnego obiektu będącego (bezpośrednim lub pośrednim) wystąpieniem tej klasy. Można również rozważać metody przechowywane wewnątrz samych obiektów i

105


wywoływane na podobnych zasadach. Zwykle pojęciu metody przypisuje się niezbyt duży stopień skomplikowania („mała procedura”), nie angażowanie zbyt dużych zasobów z zewnątrz klasy oraz brak efektów ubocznych na środowisku spoza wnętrza obiektu. Nie są to jednak formalne ograniczenia, lecz raczej zalecenia dla programistów, które z różnych względów nie zawsze muszą i nie zawsze mogą być przestrzegane.

metoda [2] (method) Synonim metodyki (stosowany m.in. przez twórców UML), lub określenie pewnego sposobu postępowania przy analizie, projektowaniu i konstruowaniu oprogramowania.

metoda abstrakcyjna (abstract method) Metoda, której specyfikacja znajduje się w danej klasie, ale której implementancje (być może różne) znajdują się w podklasach. Poniższy rysunek przedstawia metody/operacje abstrakcyjne środek i objętość zadeklarowane w klasie abstrakcyjnej BRYŁA, których implementacje znajdują się w podklasach.

BRYŁA

środek()objętość()

SZEŚCIANbok

środek() {...}objętość(){...}

STOŻEKpromień_podstawy

wysokośćśrodek() {...}objętość(){...}

KULApromień

środek() {...}objętość(){...}

Operacje abstrakcyjne

Implementacje

Specyfikacja metod/operacji abstrakcyjnych i ich implementacji

metoda fabrykująca (factory method) Metoda tworząca nowe obiekty; konstruktor.

metoda klasowa (class method) Metoda, która działa nie na pojedynczych wystąpieniach klasy (obiektach), lecz na całej ekstensji klasy. Przykładami takich metod dla klasy Pracownik są: UtwórzPracownika, LiczbaPracowników, ŚredniaZarobków, itd. Metody takie są uruchamiane poprzez wysłanie komunikatu do klasy, ekstensji lub kontenera. Synonim: operacja klasowa.

metoda prywatna (private method) Metoda niedostępna z zewnątrz danej klasy.

metoda publiczna (public method) Metoda dostępna z zewnątrz danej klasy.

metoda wystąpienia (instance method) Metoda działająca na pojedynczym obiekcie danej klasy; metoda uruchamiana poprzez wysłanie komunikatu do obiektu.

metoda zwrotna (callback method) Określenie metody m w obiekcie A w sytuacji, kiedy obiekt A po wysłaniu pewnego komunikatu do obiektu B wymaga, aby po zaistnieniu pewnego zdarzenia obiekt B skierował komunikat do obiektu A wywołujący

106


metodę m.

metodologia (methodology) Patrz: metodyka.

metodyka (methodology) Zestaw pojęć, notacji, modeli formalnych, języków i sposobów postępowania służący do analizy rzeczywistości (stanowiącej przedmiot projektowanego systemu informatycznego), oraz do projektowania pojęciowego, logicznego i/lub fizycznego. Zwykle metodyka jest powiązana z odpowiednią notacją (diagramami) służącymi do zapisywania wyniku poszczególnych faz projektu, jako środek wspomagający ludzką pamięć i wyobraźnię, oraz jako środek komunikacji w zespołach oraz pomiędzy projektantami i klientem. Metodyka ustala następujące elementy procesu wytwarzania oprogramowania: Fazy projektu (np. podział na: fazę strategiczną, formułowanie wymagań, analizę,

projektowanie, konstrukcję, testowanie, wdrażanie, pielęgnację). Modele tworzone w każdej z faz. Scenariusze postępowania w każdej z faz. Reguły przechodzenia od fazy do następnej fazy. Notacje, których należy używać podczas tworzenia dokumentacji. Dokumentację powstającą w każdej z faz.

Metodyka dyscyplinuje przebieg procesu analizy i projektowania, pozwalając na w miarę obiektywne rozliczenie (czasowe, finansowe) jego uczestników. Wadą wszystkich proponowanych metodyk jest ich arbitralność, brak głębszego uzasadnienia dla proponowanych modeli, notacji, technik i faz postępowania, oraz idealizacja sytuacji projektowych, które dość często nie pasują do uwarunkowań danego projektu. Nawet najlepsze metodyki i narzędzia CASE nie są w stanie zapewnić wysokiej jakości projektów. Kluczem do dobrego projektu jest zespół doświadczonych, zaangażowanych i kompetentnych osób, dla których metodyka oraz narzędzie CASE mogą służyć jako istotne, lecz drugorzędne wspomaganie.

http://www_trese.cs.utwente.nl/Docs/Methodologies/methodologies.html

metodyka obiektowa (object-oriented methodology) Metodyka wykorzystująca pojęcia obiektowości dla celów modelowania pojęciowego oraz analizy i projektowania systemów informatycznych. Podstawowym składnikiem tych metodyk jest diagram obiektów, będący zwykle wariantem notacyjnym i pewnym rozszerzeniem diagramów encja-związek. Diagram obiektów zawiera takie elementy jak: klasy, w ramach klas specyfikacje atrybutów i metod, strukturę dziedziczenia pomiędzy klasami, związki asocjacji i agregacji, liczności tych związków, różnorodne ograniczenia oraz inne oznaczenia. Uzupełnieniem tego diagramu są inne, np. diagramy dynamiczne uwzględniające stany poszczególnych procesów przetwarzania i przejścia pomiędzy tymi stanami, diagramy zależności pomiędzy wywołaniami metod (np. diagram tropów komunikatów), diagramy fukcjonalne (będące zwykle pewną mutacją diagramów przepływu danych). Ostatnio popularność zdobyła także koncepcja przypadków użycia (use cases), której podstawowym celem i walorem jest odwzorowanie struktury systemu z punktu widzenia jego użytkownika. Istnieje bardzo wiele metodyk lub notacji obiektowych, w szczególności: BON, Catalysis, DOOS(Wirfs/Brock), EROOS,

107


Express, Fusion, Goldberg/Rubin, MainstreamObjects, Martin/Odell, MOSES, Objectory(Jacobson), OMT(Rumbaugh), OOA/OOD(Coad/Yourdon), OODA(Booch), OSA, Sintropy, OOSA(Shlaer/Mellor), UML i inne. Ostatnio na czoło wybija się notacja UML autorstwa znanych metodologów: I.Jacobson, J.Rumbaugh i G.Booch.

http://www.toa.com/pub/html/mcr.lhtmlhttp://www.clark.net/pub/howie/OO/oo_home.htmlhttp://www.objenv.com/cetus/oo_ooa_ood_methods.htmlhttp://www_trese.cs.utwente.nl/Docs/Methodologies/methodologies.htmlhttp://www.iconcomp.com/papers/comp/comp_1.html

metryka (metric) Stosowana w inżynierii oprogramowania charakterystyka liczbowa, pozwalająca na ilościową ocenę produktów programistycznych (projektów, kodu źródłowego, zestawu testów, itd.), procesów wytwarzania oprogramowania (aktywności analizy, przebiegu projektowania, przebiegu programowania, itd.), oraz ludzi uczestniczących w tworzeniu oprogramowania (efektywność osób testujących, efektywność programistów, wydajność projektanta, itd.). W literaturze przedmiotu występuje ogromna liczba metryk (autorzy: McCabe, Halstead, Elshoff, Ejiogue, McClure), wśród nich metryki uwzględniające lub szacujące m.in. następujące aspekty: wrażliwość na błędy, możliwości testowania, częstotliwość występowania awarii, dostępność systemu, propagacja błędów, ilość linii kodu, złożoność kodu, złożoność programu, punkty funkcyjne, złożoność obliczeniową, funkcjonalną, modułową, łatwość implementacji, rozmiar dokumentacji, ilość zadań wykonanych terminowo i po terminie, współzależność zadań, wielkość i koszt projektu, czas trwania projektu, zagrożenia projektu (ryzyko), czas gotowości produktu, kompletność wymagań, kompletność planowania, stabilność wymagań, odpowiedniość posiadanych zasobów sprzętowych, materiałowych i ludzkich, efektywność zespołu, efektywność poszczególnych osób.

Metryki są tworzone na podstawie spekulacji, symulacji, doświadczenia, zdrowego rozsądku, w związku z czym są do pewnego stopnia arbitralne, nie wsparte istotną teorią lub naukową weryfikacją. Pomimo tego, metryki mają ogromne znaczenie w świecie biznesu, gdyż jest praktycznie niemożliwe planowanie i zarządzanie procesami produkcji oprogramowania bez wprowadzenia dobrze zdefiniowanych metryk. Wydaje

108


się jednak, że obecnie metryk jest za dużo, zaś większość z nich jest mało wartościowa z powodu potencjalnie bardzo dużego błędu w oszacowaniu niektórych wartości niezbędnych do ich obliczenia (pobieranie ich „z sufitu”). W literaturze przedmiotu zwraca się uwagę na to, że metryki - jakkolwiek niezbędne - mogą wyrządzić szkodę z powodu sprowadzenia ocen do małej liczby wymiarów i z powodu sprzężenia zwrotnego polegającego na tym, że styl, forma i rezultat pracy analityków, projektantów programistów, itd. może ulec niekorzystnej deformacji z powodu formalistycznego stosowania metryk przy ocenie ich pracy. Zaleca się jednoczesne korzystanie z wielu metryk i, oczywiście, zdrowy rozsadek. Patrz też: metryka obiektowa.

http://www.mccabe.com

metryka obiektowa (object-oriented metric, object-oriented measurement) Charakterystyka liczbowa pozwalająca na ilościową ocenę produktów obiektowych (projektów, kodu źródłowego, zestawu testów, itd.), procesów wytwarzania oprogramowania (aktywności analizy, przebiegu projektowania, przebiegu programowania, itd.), oraz ludzi uczestniczących w tworzeniu oprogramowania (efektywność osób testujących, efektywność programistów, wydajność projektanta, itd.). Metryki obiektowe są szczególnym przypadkiem metryk stosowanych w inżynierii oprogramowania. Wśród nich można wymienić następujące: średnia liczba wystąpień obiektów przypadająca na klasę, liczba klas parametryzowanych, liczba i złożoność metod przypadających na klasę, głębokość drzewa dziedziczenia, średnia liczba specjalizacji dla klas abstrakcyjnych, liczba charakteryzująca gęstość powiązań pomiędzy klasami, średnia długość metody (w liniach kodu), średni czas tworzenia klasy, miara charakteryzująca kohezję klasy i inne. Przykładami najczęściej stosowanych metryk obiektowych są (wg Shyama Chidambera i Chrisa Kemerera): DIT - głębokość drzewa dziedziczenia obiektów, NOC - liczba potomków w ramach dziedziczenia dla konkretnej klasy, CPO - liczba obiektów, dla których analizowany obiekt jest łącznikiem do innych

obiektów, RFC - liczność zbioru metod (lokalnych i z innych obiektów) wywoływanych przez

metody obiektu, LCOM - liczba metod nie wykorzystywanych przez inne metody, WMC - rozmiar metod w konkretnych klasach: zarówno liczba metod, jak i ich

złożoność (liczona na przykład tradycyjnymi metodami dla programów nieobiektowych).

McCabe podaje następujące metryki dla programów obiektowych: Dla hermetyzacji:

PCTPUB - procent danych publicznych. Jest liczony jako stosunek danych publicznych względem danych prywatnych w obiektach,PUBDATA - dostępność danych publicznych. Określany miarą liczby dostępów do danych publicznych.

Dla polimorfizmu:PCTCALL - stosunek liczby nieprzeciążonych wywołań metod do wszystkich wywołań,ROOTCNT - globalna liczba korzeni w hierarchii dziedziczenia klas,

109


FANIN - liczba klas, z których wywodzi się analizowana klasa. Dla projektu programu obiektowego:

MAXV - maksymalna wartość złożoności (tzw. cyklomatycznej) dla metod,MAXEV - maksymalna wartość złożoności struktury kodu dla metod, QUAL - liczba klas uzależnionych od poprawnego funkcjonowania swoich przodków.

http://www.sbu.ac.uk/~csse/publications/OOMetrics.htmlhttp://www.comsoft.southern.edu/http://www.mccabe.comhttp://WWW.rbsc.com/pages/ootbib.html

Meyer, Bertrand Twórca języka Eiffel, metodolog oprogramowania, w szczególności autor metody projektowania poprzez kontrakty (design by contracts), krytyk języków C++ i Java. Postać barwna. Określany przez konkurencję jako „fake scientist” (udawany naukowiec) po tym, jak język Java nazwał „drugą pomyłką ludzkości”. Pierwszą pomyłką był C++, określany przez niego jako „centaur”, z obiektową głową i tułowiem przypominającym assembler.

http://www.eiffel.com

miara (metric) Patrz: metryka.

miara obiektowa (object-oriented measurement) Patrz: metryka obiektowa.

mieszanie (hash) Kodowanie mieszające; metoda fizycznej organizacji zbiorów informacji. Patrz: funkcja mieszająca.

migracja obiektów (object migration) Zwykle termin ten oznacza sytuację, kiedy obiekt zmienia klasę (staje się wystąpieniem innej klasy). W innym znaczeniu termin ten oznacza przesyłanie obiektów w sieci lub pomiędzy różnymi aplikacjami.

MIS (Management Information System) System informatyczny przeznaczony do wspomagania zarządzania.

mobilne programowanie (mobile programming) Programowanie mobilnych agentów; programowanie, którego wynikiem jest mobilny kod.

mobilny agent (mobile agent) Aktywny obiekt przemieszczający się w sieci komputerowej i wykonujący w odległym miejscu usługę na rzecz wysyłającego go klienta. Podstawowa różnica pomiędzy apletem (serwletem) i aktywnym agentem polega na tym, że aktywny agent posiada swój własny stan oraz może ominąć (do pewnego stopnia) bariery bezpieczeństwa i korzystać z zasobów (danych) w miejscu, w którym aktualnie przebywa.

http://www.objenv.com/cetus/oo_mobile_agents.htmlhttp://www.insead.fr/CALT/Encyclopedia/ComputerSciences/Agents/

mobilny kod (mobile code) Kod programu, który można transmitować poprzez sieć i wykonywać w miejscu docelowym. Głównym celem programowania z mobilnym

110


kodem (mobile programming) jest dostarczenie bezpiecznych i rozszerzalnych środków do programowania interakcyjnych aplikacji w sieciach Internet oraz Intranet. Przykładami języków generujących mobilny kod (mobile languages) są: Java, Safe-TCL, Python, Phantom, Scheme48, Guile i Obliq.

moc (power, robustness) Termin oznaczający skalę możliwości funkcjonalnych danego języka, aplikacji, interfejsu lub systemu. Niekiedy termin ten oznacza także uwolnienie pewnego produktu programistycznego od błędów lub możliwość poprawnego funkcjonowania w nienormalnej lub wyjątkowej sytuacji.

moc Turinga (Turing power) Patrz: kompletność obliczeniowa.

mocna kontrola typów (strong type checking, strong typing) Przypisywanie (automatyczne lub nie) typów wszystkim bytom występującym w programie (zmiennym, obiektom, funkcjom, procedurom, metodom, itd.), oraz konsekwentne sprawdzanie zgodności użycia danego bytu w programie z jego zadeklarowanym typem. Zwykle mocna kontrola typów oznacza kontrolę statyczną (podczas kompilacji).

mocny klient (fat client) W architekturze klient-serwer określenie klienta o rozbudowanych funkcjach, który rzadko odwołuje się do usług świadczonych przez serwer. Przeciwieństwem jest chudy (cienki) klient (thin client).

model CRC (CRC model) Kolekcja kart CRC opisująca klasy tworzące system lub pewien jego fragment.

model cyklu życiowego (life-cycle model) Model określający fazy tworzenia oprogramowania, np. model piłki baseballowej, model kaskadowy, model spiralny, itd.

model danych (data model) Pojęcie niezbyt jednoznaczne, którego znaczenie jest wypadkową następujących cech: metajęzyk (pojęcia, terminologia) do mówienia o danych, o systemach baz danych i

o przetwarzaniu danych; sposób rozumienia organizacji danych i ideologiczne lub techniczne ograniczenia w

zakresie konstrukcji, organizacji i dostępu do danych; języki opisu i przetwarzania danych, w szczególności: diagramy struktur danych,

języki opisu danych i języki zapytań; ogólne założenia dotyczące architektury i języków systemu bazy danych; ograniczenia, ideologie lub teorie (matematyczne) dotyczące struktur danych i

dostępu do danych.

Niektóre definicje (podawane przez osoby o preferencjach teoretycznych) określają model danych jako zestaw matematycznych pojęć i definicji dotyczący danych i przetwarzania danych. Takie rozumienie modelu danych spełniają tylko bardzo naiwne (nie implementowane) wersje modelu relacyjnego i jego mutacji (np. modele dedukcyjne). Istnieje wiele modeli danych (np. hierarchiczny, sieciowy, relacyjny, binarnych relacji, obiektowy, funkcjonalny, zagnieżdżonych relacji, encja-związek, dedukcyjny, dedukcyjno-obiektowy, relacyjno-obiektowy, itd.), lecz najczęściej

111


posiadają one luźne ramy formalne oraz mgliste założenia i granice. Przykładowo, model hierarchiczny utożsamia się wyłącznie z drzewiastą strukturą danych (bez dalszych konkretnych założeń dotyczących np. technik dostępu), albo określa się go poprzez egzemplifikację (system IMS firmy IBM). Nie istnieje powszechnie przyjęty i dostatecznie precyzyjny obiektowy model danych. Próbami (niedoskonałymi) stworzenia takiego modelu są prace komitetów OMG i ODMG. Patrz też: model relacyjny, model sieciowy, model funkcjonalny, model obiektowy, model hierarchiczny, model obiektowy ODMG, model encja-związek

model dynamiczny (dynamic model) Model (zwykle w postaci diagramu) odwzorowywujący zdarzenia, stany, czynności i procesy; patrz: diagram stanów.

model encja-związek (entity-relationship model, ERM) Model danych zaliczany do modeli pojęciowych (conceptual data model), zaproponowany przez P. Chena. Podstawowym celem modelu encja-związek jest koncepcyjne odwzorowanie istniejącego, potencjalnego lub wyobrażanego fragmentu świata rzeczywistego modelowanego przez system z bazą danych. Model encja-związek znalazł zastosowanie przy projektowaniu baz danych, m.in. relacyjnych. Jego odmiana jest też często podstawowym składnikiem modeli lub metodyk obiektowych, np. OMT. Jest on także często podstawą systemów CASE. Zasadniczą zaletą modelu jest język wizualnych diagramów (entity-relationship diagrams, ERD) pozwalający poglądowo odwzorować obiekty modelowanej rzeczywistości oraz powiązania pomiędzy nimi w postaci grafu. Model encja-związek wprowadza m.in. następujące pojęcia (w różnych konwencjach graficznych dla ich zapisu): encja (entity) - nazwana grupa obiektów o podobnych własnościach, którą można i

warto wyróżnić w modelowanej rzeczywistości, np. Pracownik, Dział, Kierownik, Pomieszczenie;

związek (relationship) - nazwana grupa powiązań pomiędzy encjami, np. PracujeW (pomiędzy Pracownik i Dział), Kieruje (pomiędzy Dział i Kierownik), oraz MieściSięW (pomiędzy Dział i Pomieszczenie);

atrybut (attribute) - cecha charakteryzująca encję lub związek, np. NrPracownika, Nazwisko, Zarobek. Atrybut może być opcyjny (NazwiskoPanieńskie), powtarzalny (ZawódWyuczony) i/lub złożony, składający się z podatrybutów (Adres);

generalizacja/specjalizacja (generalization/specialization) - zawieranie się grup obiektów, np. Pracownik jest bardziej generalną encją niż Kierownik. Encja będąca specjalizacją innej encji dziedziczy atrybuty i powiązania z encji bardziej ogólnych, ale może posiadać też własne atrybuty i uczestniczyć we własnych związkach;

liczności (cardinalities) - dla danej encji A, określenie minimalnej i maksymalnej liczby obiektów innej encji B, która może być powiązana z jednym obiektem encji A w ramach określonego związku. Dla przykładu, związek MieściSięW od strony encji Dział będzie charakteryzowany przez liczby kardynalne [min = 1, max = n] (gdzie n oznacza „dużo”), zaś od strony Pomieszczenie przez liczby kardynalne [min = 0, max = 1].

Patrz też: diagram encja-zwiazek.

model funkcjonalny [1] (functional model) Zwykle chodzi o model oparty na

112


przepływie danych; patrz: diagram przepływu danych.

model funkcjonalny [2] (functional model) Model danych, w którym struktury danych są modelowane jako matematyczne funkcje. Np. stosunek pomiędzy obiektami Pracownik i atrybutem Zarobek modeluje się jako funkcję

Zarobek: Pracownik integer

zaś związek (asocjacja) PracujeW pomiędzy obiektami Pracownik i obiektami Firma modeluje się jako funkcję

PracujeW: Pracownik Firma

Przykładem modelu funkcjonalnego jest Daplex. Niektórzy autorzy używają modelu funkcjonalnego do modelowania obiektowych baz danych. Istnieją również próby powiązania tego paradygmatu z funkcjonalnymi językami programowania i rachunkiem lambda. Wydaje się jednak, że są to próby dość pochopnej i płytkiej formalizacji. Wadą modeli funkcjonalnych jest słabe uwzględnienie pojęcia stanu i operacji aktualizacyjnych oraz zbytnie uproszczenie koncepcji języków zapytań.

model funkcyjny (functional model) Patrz: model funkcjonalny [1] i model funkcjonalny [2].

model hierarchiczny (hierarchical model) Ogólnie: model danych, w którym dopuszczalnymi strukturami danych są hierarchie (drzewa). Np. na czubku hierarchii są zapisy Dział, poniżej zapisy Pracownik i Klient, poniżej zapisu Klient zapisy Zamówienie, poniżej zapisów Zamówienie zapisy PozycjaZamówienia. Model hierarchiczny był pierwszym modelem danych i wiąże się go prawie wyłącznie z systemem IMS firmy IBM. Językiem manipulacji danymi w tym systemie jest język DL/1, oparty o koncepcję nawigowania od zapisów znajdujących się w górze hierarchii do zapisów podrzędnych. Dla modelowania koncepcyjnego model hierarchiczny posiada zasadnicze wady, w szczególności utrudnia reprezentowanie związków semantycznych wiele-do-wielu, oraz zmusza do często sztucznego i zbędnego nawigowania poprzez zapisy pośrednie.

model kaskadowy (waterfall model) Model cyklu rozwoju oprogramowania, w którym zakłada się, że zakończenie poprzedniej fazy jest warunkiem rozpoczęcia następnej fazy. Zaletą modelu kaskadowego jest łatwość rozliczania i zarządzania projektem. Jego wadą jest duży wpływ błędów popełnionych we wczesnych fazach na końcowy rezultat projektu, oraz brak możliwości wykorzystania w projekcie uwag i opinii jego przyszłych użytkowników. Model kaskadowy ilustruje poniższy przykład.

113


Określeniewymagań

Projektowanie

Implementacja

Testowanie

Konserwacja

Cele i szczegółowe wymagania wobec systemu.

Wersjaeksploatacyjna

Szczegółowy projekt systemuuwzględniający wcześniejsze wymagania.

Wersja alfa

Przykład modelu kaskadowego

model mentalny (mental model) Model problemu budowany w umyśle człowieka (analityka, projektanta), wyznaczający rozumienie i konceptualizację problemu.

model obiektowy (object model, object-oriented model) Model danych, którego podstawą są pojęcia obiektu, klasy, dziedziczenia, polimorfizmu oraz innych cech obiektowości. Dość często model obiektowy jest rozumiany jako wariant modelu encja-związek, gdzie istotnym uzupełnieniem jest przypisanie metod do encji (klas obiektów).

model obiektowy dla komponentów (COM, Component Object Model) Patrz: COM.

model obiektowy ODMG (ODMG object model) Model obiektowy zaproponowany przez grupę standardyzacyjną ODMG, stanowiący rozszerzenie modelu OMG. Model ODMG wprowadza pojęcia obiektu i literału (stałej lub wartości) o dowolnej strukturze hierarchicznej, identyfikatora obiektu, typów obiektów i interfejsów do obiektów powiązanych w graf dziedziczenia, kolekcje, binarne powiązania asocjacyjne pomiędzy obiektami, hermetyzację, mocną kontrolę typów, wyjątki, transakcje i inne cechy.

model obiektów (object model) Zwykle chodzi o diagram przedstawiający obiekty, ich klasy i powiązania pomiędzy nimi.

model piłki baseballowej (baseball model) Sugerowany przez P. Coada model rozwoju systemu zakładający iteracje i współbieżny rozwój. Graficzna reprezentacja modelu zawiera trzy węzły: obiektowa analiza, obiektowe projektowanie i obiektowe programowanie, oraz krawędzie łączące te węzły; przypomina ona piłkę baseballową; patrz rysunek poniżej.

114


Obiektowaanaliza

Obiektoweprojektowanie

Obiektoweprogramowanie

Model piłki baseballowej

model pojęciowy (conceptual model) Model procesów lub model struktury danych odwołujący się do ludzkiej percepcji i wyobraźni, mający za zadanie zrozumienie problemu, udokumentowanie wyniku analizy lub projektu w czytelnej i abstrakcyjnej formie językowej, oraz ułatwienie komunikacji w zespołach ludzkich.

model postrelacyjny (post-relational model) Zwykle chodzi o model rozszerzający model relacyjny lub o pewną wersję modelu obiektowego.

model przepływu danych (data flow model) Model oparty na diagramach przepływu danych; patrz: diagram przepływu danych.

model przypadków użycia (use case model) Diagram dokumentujący zachowanie się systemu jako zestawu przypadków użycia, aktorów zewnętrznych oraz powiązań pomiędzy tymi elementami.

model relacyjny (relational model) Ideologia informatyczna dotycząca organizacji baz danych oparta o pojęcia matematyczne, w szczególności pojęcie relacji, zaproponowana przez E.F.Codda z IBM w 1970 r. Jej podstawowe doktryny można streścić następująco: Struktury danych w bazie danych są relacjami w sensie matematycznym, w których

elementy krotek są atomowe (niepodzielne); jest to tzw. pierwsza forma normalna; Użytkownik lub programista aplikacyjny nie będzie musiał i nie będzie miał

możliwości zajmowania się szczegółami reprezentacji danych; Przetwarzanie danych odbywa się w językach bardzo wysokiego poziomu,

posiadających matematyczne konotacje. Podstawą jest algebra relacji z operacjami takimi jak selekcja, projekcja i złączenie, oraz rachunek relacyjny, będący odmianą rachunku predykatów;

Relacje w bazie danych będą wolne od anomalii aktualizacyjnych związanych z zależnościami funkcyjnymi (i innymi).

115


Retrospektywnie, Codd streścił powyższe założenia w słynnych 12 regułach „prawdziwego” systemu relacyjnego. Uważa się powszechnie, że model relacyjny był istotnym postępem w dziedzinie baz danych. Systemy relacyjne zdominowały współczesny rynek baz danych, uzyskując zarówno sukces finansowy, jak i ogromny autorytet w środowiskach klientów baz danych. Jak w każdym sporze ideologicznym, nie brak również głosów krytycznych: niektórzy specjaliści uważają, że model relacyjny był ślepą uliczką w ewolucji modelu sieciowego do obecnych modeli obiektowych. Są głosy (H.Baker), że model relacyjny opóźnił rozwój przemysłu baz danych o 10 lat. Wady modelu relacyjnego spowodowały obecny zwrot w kierunku obiektowości w bazach danych. Pomimo relacyjnego rodowodu, obecne systemy określane jako „relacyjne” w minimalnym stopniu stosują się do ideologicznej ortodoksji tego modelu („12-tu reguł”); w szczególności, wprowadzają do swoich interfejsów wiele cech obiektowych, zaś wspomagane przez nie struktury danych (tablice) i języki (SQL) posiadają bardzo luźne związki z ich matematycznymi prawzorami. Systemy określane jako postrelacyjne (post-relational) lub obiektowo-relacyjne posiadają cechy na tyle odbiegające od prawzoru bazującego na pojęciu matematycznej relacji, że można kwestionować jakikolwiek sens używania w stosunku do nich określenia „relacyjne”.

model semantyczny (semantic model) Zestaw pojęć, technik i notacji mający na celu odwzorowanie semantyki danych, czyli ich znaczenia w świecie zewnętrznym. Modele semantyczne wprowadzają w tym celu pojęcia, takie jak: generalizacja, specjalizacja, asocjacja, agregacja, klasyfikacja, własności temporalne, zdarzenia, własności behawioralne, itd. Przykładem prostego modelu semantycznego jest model encja-związek. Niekiedy terminem „model semantyczny” określa się również konkretny diagram (lub inną formę językowo-graficzną) odwzorowujący rzeczywistość opisywaną przez dane.

model sieciowy (network model) Model danych, w którym związki asocjacyjne pomiędzy danymi są reprezentowane poprzez powiązania wskaźnikowe. Struktura danych tworzy więc graf, czyli sieć. Najczęściej model sieciowy utożsamia się z propozycją grupy DBTG (Data Base Task Group) komitetu CODASYL, opublikowaną w 1971 r. i potem kilkakrotnie modyfikowaną. Model sieciowy stanowił istotny postęp w stosunku do modelu hierarchicznego zrealizowanego w IBM-owskim systemie IMS. Raport DBTG CODASYL specyfikuje dwa języki: DDL (Data Description Language - język opisu danych) oraz DML (Data Manipulation Language - język manipulacji danymi). Pomysł języka DDL ma swój rodowód w diagramach Bachmana - narzędziu do projektowania baz danych. DML jest uważany za język źle zaprojektowany. Jego podstawową wadą jest obniżenie poziomu programowania do drugorzędnych szczegółów organizacji danych, oraz oparcie jego koncepcji o tzw. wskaźniki bieżące (currency indicators), i w konsekwencji zwiększenie uciążliwości programowania i niską niezależność danych i programów. Wady modelu sieciowego przyczyniły się do rozwoju modelu relacyjnego, który jednak nie spełnił pokładanych w nim nadziei. W ostatnich latach nastąpił renesans koncepcji modelu sieciowego w postaci modelu obiektowego oraz obiektowych SZBD. Niektórzy autorzy uważają model sieciowy za jednego z przodków obiektowości w dziedzinie baz danych.

model spiralny (spiral model) Model cyklu życiowego oprogramowania

116


(zaproponowany przez B.Boehma), zakładający powtórzenie cyklu tworzenia systemu po uzyskaniu informacji z poprzedniego cyklu. Poniżej znajduje się przykład modelu spiralnego. Istnieje wiele odmian tego modelu, z różnym ustawieniem faz podlegających powtórzeniom.

Planowanie: Ustaleniecelów produkcjikolejnej wersjisystemu

Analiza ryzyka(ew. budowa prototypu)

Konstrukcja(model kaskadowy)

Atestowanie (przez klienta). Jeżeli ocena nie jest w pełnipozytywna, rozpoczynany jestkolejny cykl.

Przykład modelu spiralnego

model wodospadowy (waterfall model) Patrz: model kaskadowy.

modelowanie CRC (CRC modeling) Proces tworzenia modelu CRC. Patrz: karta CRC.

modelowanie obiektowe (object-oriented modeling) Budowa modeli odwzorowujących modelowaną rzeczywistość na strukturę (diagram) opisującą obiekty, ich klasy, ich wzajemne powiązania oraz ich zachowanie się i interakcję.

modelowanie pojęciowe (conceptual modeling) Tworzenie modeli pojęciowych. Patrz: model pojęciowy.

modelowanie procesów biznesowych (Business Process Modeling, BPM) Tworzenie modeli opisujących daną dziedzinę przedmiotową.

model-perspektywa-sterownik (Model-View-Controller, MVC) Patrz: MVC.

Modula-3 Obiektowy język programowania, następca Modula-2 i Cedar. Modula-3 została zaprojektowana z myślą o prostocie i bezpieczeństwie. Wprowadza obiekty, generalia (generics), wątki, wyjątki i zbieranie nieużytków. Moduły mogą być deklarowane jako „bezpieczne” i „niebezpieczne” (w zależności od wymaganej kontroli typów). Nie posiada wielodziedziczenia i przeciążania operatorów. Jest oparta na strukturalnej zgodności typów.

http://www.research.digital.com/SRC/modula-3/html/home.htmlhttp://www.vlsi.polymtl.ca/m3/

117


http://www.cmass.com/threads/

modularność (modularity) Możliwość dekomponowania programu lub systemu na części o dobrze określonych granicach oraz o dobrze wyspecyfikowanym interfejsie pomiędzy poszczególnymi częściami.

modularyzacja (modularization) Podział struktury danych lub struktury programu na mniejsze fragmenty o dobrze zdefiniowanych granicach i interfejsie (np. na obiekty lub moduły), którymi można operować w programie tak, jak zamkniętymi jednostkami.

moduł (module) Termin używany w kilku zbliżonych znaczeniach. W modularnych językach programowania, takich jak Modula-2, moduł oznacza fragment programu stanowiący jednostkę przechowywania, kompilacji i konsolidacji (linking). Moduł podlega regułom hermetyzacji (encapsulation) oddzielającym specyfikację modułu od jego implementacji. Dzięki temu każdy moduł może posiadać własną przestrzeń nazw nie kolidującą z przestrzenią nazw innych modułów. Specyfikacja modułu zawiera tzw. listy eksportowe i importowe. Lista eksportowa określa obiekty modułu (dane, typy, procedury), które są widoczne na zewnątrz; lista importowa określa obiekty innych modułów, które można użyć w danym module. W modelach architektury systemów komputerowych moduł oznacza jednostkę strukturalną lub funkcjonalną o dobrze zdefiniowanym interfejsie lub powiązaniu z innymi modułami. W terminologii konkretnych SZBD i metodyk projektowania terminu moduł używa się dla oznaczenia fragmentu aplikacji dotyczącej konkretnej funkcji systemu, np. „moduł obsługi klienta”.

modyfikator (modifier) Funkcja lub operacja zmieniająca stan obiektu; często synonim lub semantyczny równoważnik operacji podstawienia (assignment).

monomorfizm (monomorphism) Brak polimorfizmu, czyli brak możliwości przypisania wielu typów do jednego bytu programistycznego. W językach obiektowych monomorfizm oznacza także brak możliwości dynamicznego wiązania metod. Do języków monomorficznych należy większość klasycznych języków programowania: Pascal, C, Modula-2, PL/I, Fortran, itd.

Montage Obiektowo-relacyjny SZBD, komercyjna wersja systemu Postgres.

MOOSE (Major Object-Oriented SQL Extensions) Obiektowe rozszerzenia języka SQL, wprowadzane w SQL3. Patrz: SQL3.

MOSES (Methodology for Object-oriented Software Engineering of Systems) Obiektowa metodyka analizy i projektowania systemów informatycznych opracowana w ośrodku COTAR (Centre for Object Technology Applications and Research) w Australii. MOSES jest niezależna od języka implementacyjnego, wspomaga zarządzanie projektem (włączając metryki), ponowne użycie, iteracyjny cykl życiowy oraz zadania związane z biznesem. Posiada pełną notację i jest zintegrowana z narzędziem CASE. Jest używana w wielu ośrodkach przemysłowych i akademickich. Istnieje projekt integracji metodyk MOSES, SOMA i Martin/Odell.

http://linus.socs.uts.edu.au/~cotar/moses.html

118


możliwość ponownego użycia (reusability) Określenie stopnia zdolności danej metodyki, języka programowania, systemu, organizacji, itd. do tworzenia i wykorzystania aktywów ponownego użycia.

mrówka (ant) Owad. Niezbyt duży, aktywny obiekt rzeczywisty. Mrówki pełnią pożyteczną rolę przy objaśnianiu różnicy pomiędzy identyfikatorem i tożsamością obiektu. Pomimo tego, że urzędy zaniedbują oznaczanie pojedynczych mrówek unikalnymi identyfikatorami i wydawanie im dowodów tożsamości - przez co są one dla nas praktycznie nieodróżnialne - każda mrówka posiada swoją własną tożsamość, istnieje niezależnie od innych mrówek, ma swoje życie, które kiedyś zaczyna się, trwa, i kiedyś się kończy. Mrówki są argumentem na rzecz tezy, że obiekty mają tożsamość, ale mogą nie posiadać unikalnego identyfikatora. Teza ta może mieć znaczenie w technologiach rozproszonych obiektów, komponentów, mobilnych agentów, federacyjnych baz danych, itd., gdzie istotne staje się pytanie: co to znaczy „unikalny identyfikator obiektu”? To wydawałoby się banalne pytanie prowadzi do niebanalnego: czy warto tworzyć Światowe Biuro Ewidencji Obiektów, które zajmowałoby się centralnym rozdzielnictwem unikalnych identyfikatorów dla wszelkich obiektów, które kiedykolwiek były, są lub będą w zasięgu globalnej sieci komputerowej?

MS Repository Produkt firmy Microsoft stanowiący realizację obiektowego systemu zarządzania bazą danych. MS Repository jest dostarczany jako komponent pakietu VisualBasic (wersja 5.0) i włącza interfejsy wg standardu ActiveX, które projektant może wykorzystać do zdefiniowania modelu informacji oraz do manipulacji danymi. MS Repository jest zbudowany na wierzchołku pakietu Microsoft SQL Server oraz Microsoft Jet i jest kompatybilny z technologią COM/ActiveX/VisualBasic (Automation). Jakkolwiek zaimplementowany na bazie relacyjnej, MS Repository jest systemem obiektowym wprowadzającym pojęcia klasy (z wieloma interfejsami do jednej klasy), metod przypisanych do klas, unikalnego identyfikatora obiektu, dziedziczenia, polimorfizmu i inne. MS Repository wtapia się gładko w rynek produktów Microsoftu, szczególnie rynek VisualBasic i technologii COM/ActiveX. MS Repository jest kolejnym etapem rozwoju technologii OLE-OLE2-COM-DCOM-OLEAutomation-OLEControls-ActiveX i wprowadzenia do niej pojęcia trwałości i niektórych pojęć obiektowości.

http://www.microsoft.com/Repository/whatsnew.htm

MTS (Microsoft Transaction Server) Serwer transakcji Microsoftu.

multimedia (multimedia) Perspektywiczna dziedzina zastosowań obiektowych baz danych, które nie ograniczają formatu struktury obiektów i mogą operować na (dużych) obiektach przechowujących dane multimedialne (wzbogacony tekst, grafika, dźwięk, wideo). Tego rodzaju dane mogą być przechowywane i przetwarzane w systemach obiektowych jak normalne atrybuty (patrz: atrybut multimedialny). Jest to istotna różnica w stosunku do systemów relacyjnych, które tego rodzaju dane przechowywują poza podstawową strukturą danych (patrz: BLOB) i traktują mało systematycznie, przez co wzrasta złożoność interfejsów programistycznych i zawodność oprogramowania aplikacyjnego.

119


multimedialny (multi-media) Termin odnosi się do systemu, który jest zdolny udostępniać, przechowywać lub przetwarzać informacje wizualne, takie jak grafika wektorowa (tworzona poprzez edytory graficzne), grafika bitowa (np. zdjęcia), animację, sekwencje wideo, dźwięk, oraz kombinację tych form. Zastosowania multimedialne, w szczególności udostępnianie informacji multimedialnej w formie hipertekstu (np. zrealizowanego na stronach WWW), są uważane za przyszłość informatyki. Np. interakcyjne wideo oznacza sekwencje klatek wideo,które są zapamiętane na nośnikach laserowych. Klatki/sekwencje posiadają adresy, które mogą być zapamiętane jako wartości atrybutów w bazie danych. Dzięki temu (przy zastosowaniu już dostępnych rozwiązań technicznych) można zbudować prostą aplikację, w której tekst komputerowy jest spleciony z sekwencjami wideo. Nieco trudniejsze problemy są związane ze strukturą, przetwarzaniem i udostępnianiem animacji, takiej jak np. w grach komputerowych. W związku z WWW wiele prac jest ostatnio poświęcone organizacji hipertekstu.

MVC (Model-View-Controller) Model-perspektywa-sterownik. Sposób podziału i rozumienia interakcyjnego oprogramowania. „Model” jest wewnętrznym mechanizmem realizującym zadany algorytm, „perspektywa” określa w jaki sposób stan modelu jest widziany przez użytkownika, zaś „sterownik” jest mechanizmem odwzorowującym akcje użytkownika (wejście) na zmiany stanu modelu. W węższym znaczeniu MVC oznacza zestaw klas służących do budowy interfejsów użytkownika w języku Smalltalk80 wg podanego wyżej sposobu.

http://www.holub.com/goodies/mvc/mvc_sd.out.html

NN

nadawca (sender) Obiekt wysyłający komunikat.

nadklasa (superclass) Klasa bardziej ogólna, usytuowana wyżej w hierarchii dziedziczenia, np. Osoba jest nadklasą klasy Student. Pojęcie nadklasy włącza aspekt zawierania się zakresów znaczeniowych pojęć; przykładowo, zbiór obiektów klasy Osoba jest nadzbiorem zbioru obiektów klasy Student. Innym aspektem jest dziedziczenie inwariantów: nadklasa przekazuje wszystkie swoje inwarianty (definicje atrybutów, definicje metod, itd.) do jej podklas. Dość często nadklasa jest tworzona poprzez zgrupowanie inwariantów jej podklas; w takich sytuacjach nie ma ona bezpośrednich wystąpień obiektów, czyli jest klasą abstrakcyjną. W wielu sytuacjach i dyskusjach dwa różne aspekty pojęcia nadklasy (zawieranie się zakresów znaczeniowych oraz grupowanie inwariantów ) prowadzą do nieporozumień.

nadzbiór (superset) Zbiór zawierający dany zbiór. Terminu tego używa się również dla oznaczenia języka lub systemu o rozszerzonych funkcjach (np. „nadzbiór języka SQL”).

narzędzia do pracy grupowej (groupware) Oprogramowanie usprawniające

120


przechowywanie, udostępnianie i przetwarzanie dokumentów w ramach zespołu. Popularnym narzędziem służącym do tego celu jest Lotus Notes.

naturalne złączenie (natural join) Patrz: złączenie naturalne.

nawigacja (navigation) Technika przechodzenia od obiektów do obiektów bazująca na wskaźnikach (pointers) umieszczonych wewnątrz obiektów; często wykorzystywana przez tzw. wyrażenia ścieżkowe. Nawigacja w obiektowej bazie danych jest naturalnym i efektywnym sposobem realizacji zapytań, które w analogicznej relacyjnej bazie danych wymagałyby złączenia (join). Patrz też: dostęp nawigacyjny.

nawigacyjne złączenie (navigational join) Patrz: zależne złączenie.

nazwa (name) Identyfikator nadawany dla obiektu, związku, atrybutu, asocjacji, roli asocjacji, relacji, metody, procedury, typu, modułu, itd., który pozwala odwołać się do tego bytu w programie. Zazwyczaj nazwa danego bytu posiada określone znaczenie w dziedzinie problemowej, odwołuje do naszego modelu pojęciowego i doświadczenia, nie jest wyłącznie przypadkową sekwencją znaków. Właśnie tym nazwa różni się od wewnętrznego identyfikatora danego bytu, którego budowa jest określona wyłącznie wewnętrznymi kryteriami przechowywania i reprezentacji danego bytu (np. jest to liczba naturalna) i nic nie mówi o tym, co dany byt oznacza. Nazwy bytów mogą być pierwszej i drugiej kategorii (obywatelstwa); to zróżnicowanie jest bardzo często powodem nieporozumień. Nazwy bytów należące do pierwszej kategorii istnieją podczas czasu wykonania, w związku z czym można je dynamicznie utworzyć i następnie zastosować do identyfikacji danego bytu. Nazwy drugiej kategorii istnieją wyłącznie w tekście programu; nie istnieje możliwość odwołania się do tej nazwy podczas czasu wykonania. Np. jeżeli nazwy obiektów są pierwszej kategorii, to wówczas możliwe jest napisanie procedury, która wczytuje nazwę z klawiatury i sprawdza, czy obiekt o tej nazwie jest w bazie danych. Jeżeli nazwy obiektów są drugiej kategorii, wówczas napisanie takiej procedury jest niemożliwe.

nazwa obiektu (object name) Nazwa pozwalająca zidentyfikować obiekt. Zazwyczaj nazwa ta posiada znaczenie w dziedzinie problemowej, np. Pracownik; tym nazwa obiektu różni się od identyfikatora obiektu. Inną różnicą jest to, że w obiektowych bazach danych nazwa obiektu nie musi być unikalna; np. może być wiele obiektów posiadających nazwę Pracownik.

nazwowa równoważność typów (name type equivalence) Patrz: nazwowa zgodność typów.

nazwowa zgodność typów (name type conformance) Reguła zgodności typów ustalająca, że typ T1 bytu programistycznego (np. wyrażenia) wydedukowany na podstawie reguł wnioskowania o typie (type inference rules) jest zgodny z zadeklarowanym typem T2 dla tego bytu (np. deklaracją parametru procedury), o ile nazwa przypisana do typu T1 jest identyczna tekstowo z nazwą przypisaną do typu T2. Nazwowa zgodność typów jest najprostsza w implementacji i jest wykorzystywana przez języki takie jak Pascal. Prowadzi ona jednak do trudności związanych z

121


polimorfizmem, wobec czego często (w obiektowych językach programowania) jest zastępowana przez tzw. strukturalną zgodność typów. Patrz też: typ rozróżniony.

NEOnet Pośrednik ORB wg standardu CORBA firmy SunSoft, składnik rodziny produktów NEO dla systemu operacyjnego Solaris.

NF2, NF2 (Non-First-Normal-Form) Patrz: nieznormalizowane relacje.

nieobiekt (non-object) Coś, co nie jest obiektem. Przykładami nieobiektów są: woda, piasek, lekki zefirek, rozlana zupa, koleiny. Nieobiektowość w informatyce ciągle czeka na swojego odkrywcę, ideologa i guru.

nieproceduralny (non-procedural) Patrz: deklaracyjny.

nieprzejrzysty (opaque) Określenie typu, klasy lub modułu, którego nazwa i przeznaczenie jest znane, ale nieznana jest jego wewnętrzna budowa.

niezależność danych (data independence) Możliwość projektowania, utrzymywania, udostępniania, zmiany nośników, zmiany reprezentacji, itp. działań na danych niezależnie od programów, które na nich operują. Niezależność danych jest osiągana poprzez interfejsy umożliwiające dostęp do danych na odpowiednim poziomie abstrakcji, gdy niewidoczne są szczegóły organizacji i implementacji danych.

niezgodność impedancji (impedance mismatch) Termin wywodzący się z elektrotechniki, oznaczający niezgodność oporności źródła i odbiornika, która powoduje stratę mocy. W bazach danych oznacza on zespół niezgodności powstający w wyniku eklektycznego połączenia (zanurzenia, embedding) języka wysokiego poziomu (np. SQL) z językiem programowania (np. C, Pascal, C++, Smalltalk, Java). Niezgodności mogą dotyczyć następujących aspektów: Składni. Programista musi w jednym tekście programu używać dwóch stylów

językowych i przestrzegać reguł dwóch różnych gramatyk. Systemu typów. Język zapytań operuje na typach zdefiniowanych w schemacie

bazy danych, m.in. relacjach, natomiast język programowania posiada zwykle odmienny system typów, w którym nie występuje typ relacja.

Semantyki i paradygmatów języków. Język zapytań bazuje na stylu deklaracyjnym, podczas gdy języki programowania bazują na stylu imperatywnym.

Pragmatyki użycia. Język zapytań uwalnia programistę od wielu szczegółów organizacji i implementacji danych (np. organizacji zbiorów, obecności lub nieobecności indeksów, itd.), podczas gdy w języku programowania te szczegóły muszą być oprogramowane.

Faz i mechanizmów wiązania. Języki zapytań są oparte o późne wiązanie (są interpretowane), podczas gdy języki programowania zakładają wczesne wiązanie (podczas kompilacji i konsolidacji).

Przestrzeni nazw i reguł zakresu. Język zapytań i język programowania posiadają własne przestrzenie nazw, które mogą zawierać identyczne nazwy o różnych znaczeniach. Odwzorowanie pomiędzy przestrzeniami nazw wymaga dodatkowych

122


środków syntaktycznych i semantycznych. Traktowania wartości zerowych. Bazy danych i języki zapytań posiadają

wyspecjalizowane środki dla przechowywania i przetwarzania wartości zerowych. Środki te nie występują w językach programowania.

Schematów iteracyjnych. W języku zapytań iteracje są wtopione w semantykę operatorów takich jak selekcja, projekcja i złączenie. W języku programowania iteracje muszą być organizowane explicite przy pomocy pętli for, while, repeat lub innych. Przetwarzanie wyników zapytań przy pomocy języka programowania wymaga specjalnych udogodnień takich jak kursory i iteratory.

Traktowania cechy trwałości danych. Języki zapytań przetwarzają wyłącznie trwałe dane (znajdujące się na dysku), podczas gdy języki programowania przetwarzają wyłącznie dane nietrwałe znajdujące się w pamięci operacyjnej. Połączenie obu języków wymaga od programisty użycia specjalnych środków językowych do parametryzacji zapytań przez zmienne języka programowania, oraz środków językowych i architektonicznych służących do transmisji danych z dysku do pamięci operacyjnej i odwrotnie.

Środków programowania ogólnego (generic). Środki te w języku zapytań są oparte o refleksję (patrz np. dynamiczny SQL). Użycie podobnego środka w języku programowania jest zazwyczaj niemożliwe z powodu wczesnego wiązania.

Skutkiem niezgodności impedancji nie są wyłącznie wady estetyczne. Niezgodność impedancji powoduje konieczność istnienia dodatkowej warstwy oprogramowania pośredniczącego pomiędzy językiem zapytań i językiem programowania. Ta warstwa obciąża dodatkowo kod aplikacji (nawet do 30% tego kodu), może być źródłem błędów, zwiększa czas uczenia się danego narzędzia, zwiększa czas wykonania, utrudnia pielęgnację, itd. Postulatem obiektowych baz danych (jak dotąd niezrealizowanym w pełni) było uniknięcie niezgodności impedancji poprzez stworzenie języków zapytań „bezszwowo” zintegrowanych z konstrukcjami proceduralnymi.

Ostatnio terminem niezgodność impedancji określa się również niezgodność paradygmatów obiektowej i relacyjnej bazy danych przy przechodzeniu ze schematu obiektowego na schemat relacyjny. Termin ten jest również stosowany dla określenia dowolnego innego łączenia niezgodnych paradygmatów projektowania, modelowania lub programowania.

niezmienialny (immutable) Obiekt lub inny byt programistyczny (np. stała), do którego nie można zastosować operacji aktualizacyjnej.

niezmienny (invariant) Określenie warunku lub własności, która jest stała dla wszystkich obiektów lub innych bytów pewnej populacji; patrz: inwariant.

nieznormalizowane relacje (non-normalized relations, embedded relations, NF2) Koncepcja modelu danych opartego o pojęcia matematyczne, w której klasyczny model relacyjny jest rozszerzony w taki sposób, aby elementem krotki relacji mogła być relacja (być może również nieznormalizowana). Pojęcie to nawiązuje do złożonych obiektów. Algebra nieznormalizowanych relacji była proponowana jako semantyczna podstawa obiektowych języków zapytań. Okazała się ona jednak zbyt uboga, nie przykrywająca ich witalnych własności i przez to mało użyteczna. Z tego powodu

123


nieznormalizowane relacje nie odegrały w obiektowości istotnej roli, chociaż wielu autorów ciągle używa tego pojęcia jako teoretycznej dekoracji dla niektórych pomysłów związanych z obiektowością.

NIH (Not-Invented-Here) Patrz: syndrom NIH.

NIL Patrz: NULL.

normalizacja (normalization) Proces przekształcania struktur danych prowadzący do uzyskania struktur relacyjnych (tzw. pierwszej formy normalnej, 1NF). Niekiedy pod normalizacją rozumie się także uzyskanie drugiej lub trzeciej formy normalnej (3NF). Proces normalizacji obejmuje: eliminację atrybutów powtarzalnych poprzez zastąpienie ich odrębnymi relacjami; „spłaszczanie” struktury danych poprzez eliminację atrybutów złożonych; zastąpienie związków (relationship) relacjami; ustalenie pierwotnych i obcych kluczy relacji, które reprezentują związki

semantyczne; wyeliminowanie niepożądanych zależności (np. funkcyjnych) pomiędzy

kolumnami relacji poprzez wprowadzenie nowych relacji.

Normalizacja jest podstawowym zabiegiem przy przechodzeniu ze struktury pojęciowej encja-związek (lub struktury obiektowej) do struktury relacyjnej. Struktury znormalizowane posiadają wady (rozproszenie bytów semantycznych w krotkach wielu relacji, zbyt duża ilość relacji utrudniająca modelowanie pojęciowe, i inne), co stało się powodem powstania pojęcia „denormalizacji”, mającej m.in. zastosowanie przy przechodzeniu od spadkowej (legacy) struktury relacyjnej do struktury obiektowej.

normalizacja danych (data normalization) Ogólnie, sprowadzenie danych do pewnego określonego formatu uwzględniającego ograniczenia nakładane na dopuszczalne struktury danych. Najczęściej tym terminem określa się proces sprowadzenia danych do postaci nadającej się do przechowywania w systemie relacyjnym; patrz: normalizacja.

normalizacja klas (class normalization) Proces przekształacania modelu lub diagramu obiektowego, w wyniku którego zwiększa się kohezję wewnątrz klas oraz minimalizuje się związki lub zależności pomiędzy klasami.

notacja (notation) Zestaw symboli graficznych, reguł syntaktycznych dotyczących ich użycia oraz reguł semantycznych dotyczących ich znaczenia służący do rysowania diagramów. Przykładem notacji jest UML, który ma szanse stać się przemysłowym standardem notacyjnym.

nowy (new) Określenie operatora tworzącego nowy obiekt (konstruktora).

NULL Oznaczenie braku wartości, wartości zerowej, wartości niezainicjowanej zmiennej lub wskaźnika, pustego zbioru, itd. Synonim: NIL.

124


OO

O2, O2 Obiektowy system zarządzania bazą danych zrealizowany we Francji przez firmę O2 Technology; prekursor obiektowych baz danych i wzorzec dla standardu ODMG. (We wrześniu 1997 firma O2 Technology połączyła się z firmą UniData i następnie z Ardent Software.)

http://www.ardentsoftware.com/http://www.o2tech.fr/

OA&D (Object Analysis and Design) Analiza i projektowanie obiektowe.

obcy klucz (foreign key) Patrz: klucz obcy.

OBD (ODB) Obiektowa Baza Danych.

Oberon-2 Obiektowe rozszerzenie języka Oberon, następcy języków Pascal i Modula-2. Posiada procedury przypisane do typów (równoważne metodom), eksport zmiennych tylko do czytania, zmienne typu „otwarta tablica” (bez ograniczenia rozmiaru) oraz zdanie „with” z wariantami.

http://www.oberon.ethz.chhttp://www.math.tau.ac.il/~laden/Oberon.htmlhttp://www.cetus-links.org/oo_oberon.html

obiekt (object) Obiekt jest abstrakcyjnym bytem reprezentującym lub opisującym pewną rzecz lub pojęcie obserwowane w świecie rzeczywistym. Obiekt jest odróżnialny od innych obiektów, ma nazwę i dobrze określone granice. Wielu autorów 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 (materialnego) istniejącego w świecie rzeczywistym. Jakkolwiek z metodologicznego punktu widzenia takie rozróżnienie jest konieczne, wynika ono zwykle z kontekstu. Przykładami obiektów są: pracownik Jan Kowalski, miasto Warszawa, dokument zakupu, pozycja tego dokumentu specyfikująca zakupiony towar, model samochodu, samochód Toyota o numerze rejestracyjnym WAP 9369, pogoda w dniu 13 kwietnia 1998 r., itd. Obiektem nie jest śnieg (chyba, że chodzi np. o pobrane próbki śniegu), nie jest nim kosmos, kolor zielony, zachód słońca, moje dzisiejsze myśli, itd. (patrz: nieobiekt).

Obiektem może być także pewna abstrakcja programistyczna. Mogą istnieć obiekty programistyczne nie posiadające odpowiedników w świecie rzeczywistym. Obiektem może być pewien zamknięty fragment oprogramowania (dana, procedura, moduł, dokument, okienko dialogu, i inne), którym programista może operować jak zwartą bryłą, np. wyszukiwać, kopiować, tworzyć, usuwać lub przenosić. Obiekty mogą być dowolnie złożone oraz dowolnie duże. 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. Obiekt może być skojarzony z metodami

125


lub operacjami, które na nim działają; z reguły, są one definiowane/przechowywane w ramach jego klasy oraz jej nadklas.

W zasadniczej swojej intencji obiekt jest tym samym co zmienna języków programowania. Występujące różnice dotyczą rozwoju historycznego, np. w C++ występują zarówno zmienne (przejęte z C), jak i obiekty. Druga różnica polega na tym, że w większości klasycznych języków programowania nie istnieją mechanizmy pozwalające na związanie metod ze zmiennymi (czyli mechanizmy klas lub abstrakcyjnych typów danych).

obiekt aktywny (active object) Patrz: aktywny obiekt.

obiekt biznesowy (business object) Obiekt modelujący pewien istotny aspekt dziedziny przedmiotowej. Intencją terminu „obiekt biznesowy” jest określenie obiektów niezależnych od potencjalnych komputerowych aplikacji, takich jak klient, zamówienie, konkurent, pieniądze, płatność, konto, samochód, pacjent, itd. „Obiekt biznesowy” jest do pewnego stopnia pojęciem relatywnym lub subiektywnym, gdyż zależy od tego, jaką dziedzinę biznesu mamy na myśli i co pod nią rozumiemy. Próby precyzyjnej definicji tego pojęcia są raczej nieudane.

obiekt chwilowy (temporary object) Patrz: obiekt ulotny.

obiekt docelowy (target object) Obiekt będący adresatem (odbiorcą) komunikatu.

obiekt globalny (global object) Obiekt dostępny dla wszystkich bytów programistycznych; obiekt znajdujący się w powszechnie dostępnym środowisku lub zakresie.

obiekt interfejsu (interface object) Obiekt służący do opisu interfejsu oraz do komunikacji systemu z jego środowiskiem zewnętrznym. W terminologii przypadków użycia (use cases): obiekt hermetyzujący funkcje bezpośrednio zależne od zewnętrza systemu lub funkcje służące do komunikowania się z zewnętrznymi aktorami.

obiekt kompozytowy (composed object, composite object) Obiekt składający się z innych obiektów (podobiektów); obiekt złożony. Niekiedy terminem tym określa się grupę powiązanych obiektów, które podlegają jednoczesnemu usuwaniu, kopiowaniu, blokowaniu, itd. oraz stanowią podstawę tworzenia fizycznych gron (clusters).

obiekt kontenerowy (container object) Obiekt będący kolekcją obiektów.

obiekt lokalny (local object) Obiekt (zwykle ulotny), który jest dostępny wyłącznie dla pewnego lokalnego kontekstu lub środowiska, np. treści pewnej metody lub procedury.

obiekt niezmienialny (immutable object) Obiekt, którego stanu nie można zmienić. W Smalltalku niezmiennymi obiektami są np. wartości liczbowe. Synonim: literał.

obiekt pasywny (passive object) Przeciwieństwo obiektu aktywnego, obiekt nie posiadający własnej nitki sterowania. Niekiedy terminem tym określa się również obiekt

126


posiadający atrybuty, ale nie posiadający żadnych przypisanych do niego metod lub operacji.

obiekt rzeczywisty (entity object) W terminologii przypadków użycia (use cases): obiekt, który można zidentyfikować w modelowanej rzeczywistości.

obiekt sterujący (control object) Obiekt, którego funkcją jest sterowanie; z reguły, jest to obiekt ulotny. W terminologii przypadków użycia (use cases), obiekt sterujący hermetyzuje jeden lub kilka przypadków użycia; jest to obiekt reprezentujący zestaw zadań w biznesie. Obiekt sterujący modeluje funkcjonalność, która nie może być przywiązana do jakiegokolwiek innego obiektu.

obiekt trwały (persistent object) Patrz: trwały obiekt.

obiekt ulotny (transient object, transitory object, volatile object, temporary object) Obiekt, którego istnienie ograniczone jest do pojedynczego uruchomienia programu lub pojedynczego wywołania procedury.

obiekt wirtualny (virtual object) Obiekt nie zapamiętany fizycznie, istniejący wyłącznie w postaci definicji; obiekt wyliczany w momencie dostępu; obiekt widziany poprzez pewną obiektową perspektywę (object view).

obiekt współbieżny (concurrent object) Obiekt, który posiada własną nitkę sterowania; inaczej aktywny obiekt.

obiekt zagregowany (aggregate object) Obiekt złożony z obiektów; obiekt kompozytowy.

obiekt zastępczy (proxy object, deputy object) Obiekt reprezentujący pewien obiekt zapamiętany w bazie danych. Jest on przechowywany w pamięci operacyjnej lub na nośniku trwałym. Pojęcie obiektu zastępczego ma przede wszystkim na uwadze optymalizację operacji wykonywanych na obiektach. Obiekt zastępczy posiada z reguły ograniczony zestaw informacji. Komunikat skierowany do obiektu zastępczego może spowodować zastąpienie go obiektem oryginalnym. Niekiedy tym pojęciem określa się także ograniczoną lub odpowiednio zmodyfikowaną kopię obiektu umożliwiającą bardziej sprawne przetwarzanie.

obiekt złożony (complex object, composite object) Obiekt, którego składowymi są obiekty. Z założenia, liczba poziomów hierarchii obiektów złożonych nie jest ograniczona. Może on również zawierać tzw. grupy powtarzalne lub kolekcje (np. Dzieci dla obiektów Pracownik), może być także dowolnie duży (np. zawierać dane multimedialne), oraz może dynamicznie zwiększać lub zmniejszać swoją objętość w zależności od liczby i wielkości przechowywanych wewnątrz niego podobiektów.

obiekt-korzeń (root object) Obiekt stojący najwyżej w hierarchii obiektów; nadobiekt przechowujący referencje do obiektów danej bazy danych; obiekt, od którego rozpoczyna się nawigacja w bazie danych.

127


obiektowa algebra (object algebra) Patrz: algebra obiektowa.

obiektowa analiza (object-oriented analysis, OOA) Metoda analizy problemu, w której wymagania są rozpatrywane w perspektywie klas i obiektów wyróżnionych w danej dziedzinie przedmiotowej. Obiektowa analiza zajmuje się identyfikacją, analizą i specyfikacją wymagań, używając pojęć takich jak: obiekty z tożsamością hermetyzujące własności i operacje, przesyłanie komunikatów, klasy, dziedziczenie, polimorfizm i dynamiczne wiązanie.

obiektowa analiza / obiektowe projektowanie (Object-Oriented Analysis / Object-Oriented Design, OOA/OOD) Patrz: OOA/OOD.

obiektowa analiza i projektowanie (Object-Oriented Analysis & Design, OOAD) Patrz: OOAD.

obiektowa baza danych (object-oriented database, object database, ODB, OODB) Baza danych zawierająca obiekty, utrzymywana i udostępniana przez obiektowy SZBD.

obiektowa notacja dla biznesu (Business Object Notation, BON) Patrz: BON.

obiektowa perspektywa (object view) Patrz: perspektywa obiektowa.

obiektowe programowanie wizyjne (object-oriented visual programming) Połączenie obiektowości z programowaniem wizyjnym. Patrz też: programowanie wizyjne.

http://cbl.leeds.ac.uk/nikos/tex2html/examples/concepts/node74.htmlhttp://www.pictorius.com/pi/products/classic.htmlhttp://www.pictorius.com/pi/products/cpx.html

obiektowe projektowanie (object-oriented design, OOD) Ogólne określenie metod lub metodyk projektowania, które wykorzystują pojęcia obiektowe. Booch wyróżnia cztery fazy obiektowego projektowania: identyfikacja obiektów i ich klas; identyfikacja semantyki obiektów; identyfikacja związków pomiędzy obiektami; identyfikacja interfejsów obiektów i ich implementacji.Istnieje wiele innych scenariuszy postępowania przy obiektowym projektowaniu.

obiektowo zorientowany (object-oriented) W polskiej terminologii staramy się utrzymać konwencję, zgodnie z którą angielski termin object-oriented jest tłumaczony jako „obiektowy” (z odpowiednimi formami fleksyjnymi: „obiektowego”, „obiektowych”, itd.). Patrz: obiektowość.

obiektowo-relacyjny (object-relational) Określenie systemu bazy danych przechowującego zarówno obiekty, jak i tablice znane z systemów relacyjnych. Podstawą ideologiczną tych systemów jest manifest systemów baz danych trzeciej generacji. Motywacją dla tych systemów jest zachowanie sprawdzonych technologii

128


relacyjnych (np. SQL) i wprowadzanie na ich wierzchołku innych własności, w tym obiektowych. W większości przypadków chodzi o ewolucyjną zmianę istniejących systemów relacyjnych posiadających swoją pozycję na rynku i grono klientów. W niektórych przypadkach systemy obiektowo-relacyjne są budowane od nowa. Kluczowymi produktami komercyjnymi tej technologii są systemy: Informix Universal/Dynamic Server (połączenie systemu Illustra, następcy systemu Postgres, i Informix OnLine), DB2 Universal Database (firmy IBM, połączenie Starburst i DB2), Oracle-8, UniSQL/X, OSMOS (firmy Unisys), Ingres II (firmy Computer Associates), Sybase Adaptive Server, Montage, Omniscience, Raima Database Manager, Total ORDB i inne. Systemy obiektowo-relacyjne są wyposażane w atrakcyjne cechy umożliwiające efektywną produkcję aplikacji. Wśród nich można wymienić przystosowanie do multimediów (duże obiekty BLOB, CLOB i pliki binarne), dane przestrzenne (spatial), abstrakcyjne typy danych (ADT), metody (funkcje i procedury) definiowane przez użytkownika w różnych językach (C, C++, VisualBasic, Java), kolekcje (zbiory, wielozbiory, sekwencje, zagnieżdżone tablice, tablice o zmiennej długości), typy referencyjne, przeciążanie funkcji, późne wiązanie i inne. Systemy te zachowują jednocześnie wiele technologii, które sprawdziły się w systemach relacyjnych (takie jak architektura klient/serwer, mechanizmy buforowania i indeksowania, przetwarzanie transakcji, optymalizacja zapytań). Systemy obiektowo-relacyjne nie są oparte na głębszej koncepcji lub teorii; są one tworzone przez praktyków i marketing z myślą o szybkim i pewnym zysku. Ideologiczne zalety obiektowo-relacyjnych baz danych są mało przekonywujące, ponieważ z koncepcyjnego punktu widzenia obiektowe bazy danych włączają struktury relacyjne jako przypadek szczególny. Podstawowy argument na rzecz takich systemów dotyczy zachowania SQL jako „języka intergalaktycznego”. Nie jest jednak jasne, o jaki SQL chodzi, ponieważ systemy te odbiegają od standardu SQL-92 (ze względu na rozbudowę struktur danych) lub powołują się na niedokończony i nie obowiązujący standard SQL3. Brak bazy intelektualnej dla tego rodzaju eklektyzmu budzi częste wątpliwości wśród ludzi wrażliwych na estetykę produktów informatycznych i zasadę nie mnożenia bytów ponad potrzebę (brzytwę Occama). Jednakże hasło „obiektowo-relacyjne” zyskuje licznych zwolenników głównie z powodu pozycji systemów relacyjnych na rynku i odwołania się do ich wiernej klienteli. Systemy obiektowo-relacyjne mają jednak posmak dekadencji, eklektyzmu i kryzysu koncepcji, cech swoistych dla granicy epok.

obiektowo-relacyjny system zarządzania bazą danych, obiektowo-relacyjny SZBD (object-relational database management system, ORDBMS) Patrz: obiektowo-relacyjny.

obiektowo-relacyjny SZBD (object-relational DBMS, ORDBMS) Patrz: obiektowo-relacyjny.

obiektowość (object-orientation, object-orientedness) Teoretyczna, ideologiczna i praktyczna koncepcja bazująca na wyróżnianiu obiektów o dobrze określonych granicach oraz semantyce; dotyczy ona programów, danych i rzeczywistości opisywanej przez dane. Naczelną misją obiektowości jest walka z nadmierną złożonością metodyk, projektów, języków, systemów i zastosowań. Tę misję obiektowość realizuje poprzez

129


nacisk na mechanizmy abstrakcji, mechanizmy kompozycji/dekompozycji złożonych struktur (obiektów), mechanizmy hermetyzacji i ukrywania niepotrzebnej informacji, oraz własności sprzyjające abstrakcji i ponownemu użyciu. Do tych pojęć i mechanizmów zaliczane są obiekty, tożsamość, klasy, typy, hermetyzacja, polimorfizm i późne wiązanie. Uważa się, że dzięki tym mechanizmom obiektowość bardziej sprzyja naturalnym mentalnym i psychologicznym uwarunkowaniom podmiotów rzeczywistości informatycznej (klientów, analityków, projektantów, programistów, użytkowników, itd.).

obiektowość behawioralna (behavioral object-orientation) Określenie modelu obiektowego, w którym występuje pojęcie operacji, metody lub funkcji przypisanej do (klas) obiektów.

obiektowo-zorientowany (object-oriented) Patrz: obiektowo zorientowany.

obiektowy (object-oriented, OO) Określenie pewnego wytworu: języka, standardu, systemu, metodyki, itd., który posiada atrybuty obiektowości. Patrz: obiektowość.

obiektowy CASE (Object-Oriented CASE, OO-CASE) Patrz: obiektowy system CASE.

obiektowy identyfikator (Object IDentifier, OID) Patrz: OID.

obiektowy język programowania (object-oriented programming language) Język programowania wprowadzający pojęcia takie jak: obiekt, klasa, metoda, dziedziczenie, hermetyzacja i polimorfizm; np. Smalltalk, C++, Eiffel, Java, Sather, CLOS, Ada95, OO-Cobol, Beta, Cecil, Dylan, Python, Self, Theta i inne.

obiektowy język zapytań (object query language) Deklaracyjny język wysokiego poziomu umożliwiający wyszukiwanie (oraz niekiedy inne operacje) w obiektowej bazie danych; przykładem jest OQL wg standardu ODMG. Obiektowy język posiada zestaw generycznych operatorów (niezależnych od typu lub klasy), takich jak: selekcja, zależne złączenie, projekcja, nawigacja, grupowanie, uporządkowanie, kwantyfikatory, porównania, funkcje i operatory arytmetyczne, funkcje zagregowane (sum, min, max, avg, count), i inne.

obiektowy system CASE (object-oriented CASE system) System wspomagający analizę, modelowanie i projektowanie systemów informatycznych oparty o pojęcia obiektowości. Systemy te zapewniają środki do rysowania diagramów (zwykle wg popularnych notacji OMT, Booch, Shlaer/Mellor, UML i innych), pewne (zwykle ograniczone) środki do automatycznego generowania kodu oraz inne udogodnienia. Przykładami obiektowych systemów CASE są: 001, AdaVantage, Bachman Data Analyst, BOCS, BridgePoint, EasyCASE, EiffelCase, Envision, Excellerator II, GraphTalk, HOMSuite, HOOD Toolset, IE/O IEF, ILOG KADS Tool, Intelligent OOA, LOV/Object Editor, MacAnalyst&MacDesigner, MetaEdit, Model 5w, ObjectCraft, ObjectDomain, Objecteering, ObjectGEODE, ObjectTime, ObjectMaker, ObjectModeller, ObjectTool, Object Oriented Designer, Objectory, ObjectTeam, OEW,

130


OOTher, OMW, OMTool, OSMOSYS, Paradigm Plus, Prosa/om, Ptech, Rational Rose, S-CASE, Select OMT, SES/Objectbench, Stood, StP, Synchronicity, System Architect, Toolbuilder, TurboCASE, VIEWS-SF, VisualThought, Westmount I-CASE OMT i inne. Patrz też: CASE.

http://iamwww.unibe.ch/~scg/OOinfo/FAQ/oo-faq-S-10.htmlhttp://osiris.sunderland.ac.uk/sst/casehome.htmlhttp://www.qucis.queensu.ca/Department/FAQs/comp.software-eng/case.html

obiektowy system operacyjny (object-oriented operating system) System operacyjny udostępniający i traktujący zasoby komputera jako obiekty. Są to prawie zawsze systemy rozproszone pozwalające na swobodne przekazywanie obiektów pomiędzy komputerami. Jak dotąd, nie są zbyt szeroko rozpowszechnione. Przykładami obiektowych systemów operacyjnych są: Apertos, Chorus, Choices, GEOS, Mach, NachOS, Ouverture, Peace, SOS, Spring i PenPoint OS.

http://mmmc.jaist.ac.jp:8000/projects/object-oriented.html

obiektowy system wspomagania inżynierii oprogramowania (object-oriented CASE system) Patrz: obiektowy system CASE.

obiektowy system zarządzania bazą danych, OSZBD (object database management system, ODBMS) Obiektowy SZBD. System wspomagający zarządzanie, utrzymywanie, zabezpieczanie i udostępnianie obiektowej bazy danych. Obiektowe SZBD zachowują pozytywne własności relacyjnych SZBD, ale przyjmują założenie, że baza danych będzie przechowywała obiekty, a nie tablice (relacje). Z obiektowości przejmują wiele pojęć takich jak: złożone obiekty, tożsamość, klasy, dziedziczenie, hermetyzacja, polimorfizm. Definicję podstawowych własności obiektowych SZBD zawiera manifest obiektowych baz danych. W stosunku do relacyjnych baz danych obiektowa baza danych umożliwia znacznie większą konceptualizację aplikacji, przybliżając schemat bazy danych do schematów pojęciowych. Obiekty w obiektowej bazie danych są dostępne poprzez metody znajdujące się w ich klasach, jak i poprzez zapytania (np. w OQL). Ewaluacja zapytań w obiektowej bazie danych jest zwykle znacznie szybsza od ewaluacji zapytań relacyjnych ze względu na rzadszą konieczność wykonywania kosztownej operacji złączenia (join), która jest tam zastępowana poprzez nawigację wzdłuż powiązania pomiędzy obiektami lub zejście w dół hierarchii obiektu. Obiektowe bazy danych są również znacznie lepiej przystosowane do multimediów. Wiele z nich zapewnia także dobre wspomaganie dla zarządzania wersjami, aktywnych reguł, ograniczeń i rozproszenia.

Przykładami obiektowych SZBD (o statucie komercyjnym) są: ArtBASE, EasyDB, GemStone, IDB Object Database, ITASCA, Matisse, NeoAccess, OBST+, O2, Objectivity/DB, ObjectStore, Ontos (wcześniej Vbase), Odapter, OOFILE, Phyla, POET, Statice, UniSQL, Unisys Universal Repository, Versant, VisualWorks. Istnieje też wiele systemów eksperymentalnych i prototypów, np. Encore, Exodus, Machiavelli, Ode, Orion i inne. Prace badawczo rozwojowe nad obiektowymi SZBD zostały ukierunkowane przez standard ODMG (patrz: ODMG, ODMG 2.0).

http://www.odmg.orghttp://www.well.com/user/ritchie/mini-faq.html

131


http://www.ifi.unizh.ch/groups/dbtg/Various/ODBminiFAQ.htmlhttp://www.cimttz.tu-chemnitz.de/oodb/OODBminiFAQ.htmlhttp://www.objectivity.com/aboutodb/aboutodb.htmlhttp://www.icslab.agh.edu.pl/~jasper/oodb/http://galaxy.uci.agh.edu.pl/~vahe/products.htmhttp://www.odbmsfacts.com/

obiekty jako wartości (objects-by-value) Termin nowego standardu CORBA 3.0. Chodzi o możliwość reprezentacji obiektów jako pewnych wartości (np. ciągów znaków), celem umożliwienia przesyłania obiektów w sieci, zwracania obiektów przez funkcję lub metodę, itd.

obiekty rozproszone (distributed objects) Patrz: rozproszone obiekty.

Object Currents Czasopismo z zakresu obiektowości publikowane na WWW.http://www.sigs.com/objectcurrents/

Object Domain Prosty obiektowy system CASE.http://www.he.tdl.com/~dirkv/domain.htmlhttp://www.object-domain.com/

Object Lisp Obiektowe rozszerzenie języka Lisp.

Object Magazine Online Czasopismo z zakresu obiektowości publikowane na WWW.

http://www.sigs.com/omo/

ObjectBroker Pośrednik wymiany obiektów (ORB) wg standardu OMG CORBA, rozwijany i rozpowszechniany przez BEA Systems.

http://www.beasys.com/http://www-digital.cern.ch/digital-at-cern/joint-project/objectbroker/

objectbroker.html

Objective C Obiektowy język programowania rozszerzający język C o niektóre cechy języka Smalltalk. Nie posiada przeciążania operatorów, wielodziedziczenia i zmiennych klasowych. Posiada dynamiczne wiązanie i dynamiczną kontrolę typów. Jest używany jako język programowania systemowego w projekcie NEXTSTEP.

http://www.batech.com/~dekorte/Objective-C/objc.htmlhttp://www.santafe.edu/~nelson/objective-c.htmlhttp://www.geom.umn.edu/docs/W3Kit/Overview/ObjectiveC.htmlhttp://www.cs.indiana.edu/classes/c304/oop-intro.htmlhttp://www.cis.ohio-state.edu/hypertext/faq/usenet/Objective-C/top.html

Objective Pascal Obiektowe rozszerzenie języka Pascal.

Objectivity/DB Obiektowy system zarządzania bazą danych rozwijany wg standardu ODMG przez firmę Objectivity, Inc.

http://www.objectivity.com/

132


ObjectLOGO Obiektowe rozszerzenie języka LOGO.

Objectory Metodyka obiektowej analizy i projektowania systemów informatycznych zaproponowana przez Jacobsona.

ObjectStore Obiektowy system zarządzania bazą danych oparty na C++, zrealizowany przez firmę Object Design, Inc.

http://www.odi.com/

Object-Z Obiektowa wersja notacji Z służącej do formalnej (matematycznej) specyfikacji oprogramowania. Zaletą formalnych notacji, takich jak Object-Z, jest umożliwienie sformalizowania problemu w takim stopniu, aby można było przeprowadzić (formalne lub półformalne) dowody poprawności przyjętych rozwiązań. Podstawową wadą formalnych specyfikacji jest ich nieprzystosowanie do skali rzeczywistych problemów, co redukuje ich zastosowanie do mało istotnego marginesu.

obsługa wyjątków (exception handling, exception handler) Fragment kodu programu przypisany do wyjątku, który jest uruchamiany w momencie pojawienia się tego wyjątku.

obywatel drugiej kategorii (second-class citizen) Pojęcie języka programowania istniejące wyłącznie w tekście programu (wykorzystywane w fazie analizy statycznej) i niedostępne w czasie wykonania; np. nazwa zmiennej, nazwa parametru, typ, sygnatura procedury, itd.

obywatel pierwszej kategorii (first-class citizen) Określenie odnoszące się do pojęcia języka programowania (np. typu, klasy, modułu, wartości zmiennej, nazwy zmiennej) oznaczające, że dany byt programistyczny istnieje i można nim manipulować w czasie wykonania. Np. wartość atrybutu obiektu jest obywatelem pierwszej kategorii, natomiast nazwa atrybutu zwykle nim nie jest.

obywatelstwo (citizenship) W językach programowania obywatelem pierwszej kategorii nazywa się taki byt programistyczny, który istnieje i którym można manipulować w czasie wykonania. Obywatelem drugiej kategorii nazywa się ten byt, który istnieje tylko w fazie analizy tekstu programu (kompilacji), tzn. nie istnieje lub jest całkowicie niedostępny podczas wykonania. W klasycznych językach programowania większość pojęć ma obywatelstwo drugiej kategorii (np. nazwy zmiennych, typy, moduły, itd.), gdyż programista nie posiada jakichkolwiek możliwości zarządzania nimi w czasie wykonania. Np. nie może w trakcie wykonywania programu zmienić nazwy zmiennej. Tego rodzaju operacja jest możliwa wyłącznie na tekście programu. Istnienie pojęć o drugiej kategorii obywatelstwa sprzyja wydajności i niezawodności, gdyż wszystkie operacje związane z tymi pojęciami (np. kontrola typów) mogą być wykonane w trakcie kompilacji. Z drugiej strony, pojęcia programistyczne przesunięte do pierwszej kategorii obywatelstwa sprzyjają elastyczności, programowaniu generycznemu (generic) i technikom ponownego użycia. Podwyższenie sprawności komputerów spowodowało tendencję do przesuwania pojęć programistycznych do pierwszej kategorii obywatelstwa. Obywatelstwo jest także

133


określane jako „kategoria programistyczna”.

obywatelstwo klasy (class citizenship) Charakterystyka ustalająca, czy klasa w danym języku programowania jest obywatelem pierwszej czy też drugiej kategorii. Np. w Smalltalku klasa (która jest również obiektem) jest obywatelem pierwszej kategorii (można wysłać do niej komunikat), natomiast w C++ klasa jest obywatelem drugiej kategorii - wysłanie komunikatu do klasy jest niemożliwe, ponieważ klasy istnieją wyłącznie w tekście programu i nie są dostępne w czasie wykonania. Klasa należąca do pierwszej kategorii programistycznej jest zbieżna z pojęciem prototypu.

ochrona (security) Przeciwdziałanie świadomym lub nieświadomym akcjom dowolnych osób, które mogłyby doprowadzić do zniszczenia danych, niepożądanych zmian danych, zniekształcenia lub zatrzymania procesów ich przetwarzania, zniszczenia sprzętu i oprogramowania, uniknięcia zapłaty za korzystanie z danych lub usług systemu, itd. Ochrona oznacza środki wprowadzone w systemie, których celem jest działanie przeciwko sabotażowi, wandalizmowi, wirusom, dostępowi hakerów, zniszczeniu poprzez nieuwagę, nadużyciu funkcji systemu, zatrzymaniu lub opóźnieniu pracy systemu, unikaniu płatności, itd. Patrz też: bezpieczeństwo.

Odapter (Java/Depot) Obiektowy system zarządzania bazą danych zrealizowany przez Hewlett-Packard Company.

ODB (Object Data Base) Patrz: obiektowa baza danych.

ODBC (Open DataBase Connectivity) Standard dostępu do różnorodnych baz danych. Istnieją interfejsy ODBC dla VisualBasic, Visual C++, SQL i innych języków. ODBC umożliwia dostęp do systemów Access, Paradox, Dbase, Text, Excel, Btrieve i innych. ODBC używa pewnego dialektu SQL, który następnie odwzorowuje na interfejsy poszczególnych systemów baz danych. ODBC jest zdefiniowany przez konsorcjum SQL Access Group; nie jest wyłącznie standardem Microsoftu, ale Microsoft położył zasadnicze zasługi w jego spopularyzowaniu. Pakiety ODBC (ODBC drivers) są obecnie dostępne dla MS Windows, systemów opartych o Unix, OS/2 i Macintosh.

ODB-II Obiektowy system zarządzania bazą danych (poprzednio Jasmine) firmy Fujitsu.

http://www.fsc.fujitsu.com/fsc/object/

odbiorca (receiver) Obiekt będący adresatem komunikatu.

ODBMS [1] (Object DataBase Management System) Patrz: obiektowy system zarządzania bazą danych.

ODBMS [2] Obiektowy system zarządzania bazą danych zrealizowany przez firmę VC Software, Inc.

Ode Obiektowy system zarządzania bazą danych zrealizowany w AT&T Bell

134


Laboratories. Baza danych utrzymywana przez Ode jest definiowana, przeszukiwana i manipulowana w języku O++, opartym na C++ i posiadającym pewne ograniczone możliwości w zakresie zapytań. Klasy w O++ posiadają własności hermetyzacji i wielokrotnego dziedziczenia (multi-inheritance). Przewidziane są możliwości definiowania wersji obiektów. Z obiektami można skojarzyć wyzwalacze i ograniczenia integralnościowe.

http://www-db.research.bell-labs.com/projects/ode/ode-announce/

ODL (Object Definition Language) Język definicji danych (język opisu danych) wchodzący w skład standardu ODMG. ODL umożliwia definiowanie klas obiektów, atrybutów, powiązań asocjacyjnych między obiektami, hierarchii dziedziczenia, metod oraz innych własności danych przechowywanych w obiektowej bazie danych.

ODMG (Object Database Management Group, Object Data Management Group) Organizacja utworzona przez firmy rozwijające obiektowe bazy danych, stawiająca sobie za cel opracowanie standardu w dziedzinie obiektowych baz danych. W skład ODMG wchodzą przedstawiciele kilkunastu zwykle małych i średnich firm komputerowych, wśród nich O2 Technology (obecnie połączona z Ardent Software i UniData), ObjectDesign, POET Software, GemStone Systems, Versant Object Technology, Objectivity, Sun Microsystems i inne. Poprzednie dwie wersje standardu były oznaczone jako ODMG-93 (grudzień 1993) i ODMG-93 Release 1.2 (styczeń 1996), obecna (sierpień 1997) jest oznaczona jako ODMG 2.0. Jako cel autorzy standardu stawiają przenaszalność (portability) aplikacji pomiędzy niezależnie zbudowanymi systemami.

http://www.odmg.org

ODMG 2.0 Nowa wersja standardu obiektowych baz danych opracowywanego przez ODMG (Object Data Management Group), która pojawiła się w połowie roku 1997. Poniżej prezentujemy ramową architekturę ODMG 2.0.

135


Kompilator jęz. progr.

Konsolidator (linker)

Baza danych

OSZBD,procedury czasu

wykonania (runtime)

Aplikacje w kodziedo konsolidacji

Działający programDostęp do danych

metadane

Deklaracje w ODLlub języku programowania + ODL

Źródłowe aplikacjew języku programowania

( + zapytania OQL jako stringi)

Preprocesor deklaracji

Ramowa architektura ODMG 2.0.

Standard posiada następujące części realizujące założenia przedstawionej architektury: Model obiektowy. Precyzuje znaczenie podstawowych pojęć obiektowości, takich

jak obiekty, klasy, metody, dziedziczenie, hermetyzacja. Ustala również podstawowe założenia dotyczące struktur danych przechowywanych przez system. Takimi strukturami są obiekty, atrybuty i związki (relationships). Klasy obiektów podlegają dziedziczeniu i hermetyzacji. ODMG wprowadza także pojęcie literału, czyli wartości, której nie można modyfikować. Istotnym założeniem modelu obiektowego ODMG jest mocna kontrola typów oraz pełna dowolność w zakresie kombinacji konstruktorów typów, w tym konstruktorów typów masowych (kolekcji), takich jak zbiór, wielozbiór, sekwencja i tablica dynamiczna. Umożliwia to tworzenie obiektów o dowolnej liczbie poziomów hierarchii oraz o dowolnej złożoności. Model obiektowy ODMG jest rozszerzeniem modelu OMG CORBA.

Język definicji obiektów ODL (Object Definition Language). Jest wzorowany na języku IDL wg OMG CORBA. Projektant bazy danych lub programista opisuje w ODL jej strukturę. Jest to niezbędne zarówno do rozumienia znaczenia danych, jak i sposobu, w jaki są one odwzorowane w zapamiętane struktury. Schemat w ODL specyfikuje przechowywane dane na pewnym poziomie abstrakcji poprzez podanie ich typów, klas, powiązań klas w hierarchie dziedziczenia, związków między klasami, metod działających na obiektach i innych elementów. Specyfikacja klasy (zwana interfejsem) jest oddzielona od jej implementacji (zwanej klasą). Standard nie zajmuje się implementacją klas i metod, przyjmując, że tę funkcję będą skutecznie pełnić związane z nim obiektowe języki programowania (C++, Smalltalk i Java).

Format wymiany obiektów. Ustala reprezentację obiektów przy ich wymianie pomiędzy różnymi systemami zarządzania bazą danych.

136


Język zapytań OQL (Object Query Language). Jest przeznaczony do wyszukiwania danych w celu ich dalszego przetwarzania lub wyprowadzenia na zewnątrz. W odróżnieniu od SQL, OQL nie zajmuje się operacjami aktualizacyjnymi, oddelegowując je do języków programowania. OQL jest zgodny z modelem obiektowym oraz językiem ODL. OQL jest językiem o wysokim poziomie abstrakcji, deklaracyjnym (określa cel wyszukiwania, a nie akcje prowadzących do tego celu), makroskopowym (równoległe działanie na wielu obiektach) i naturalnym dla użytkowników.

Wiązanie do języka C++. Określa zasady połączenia ODL i OQL z językiem C++ oraz specyfikuje zestaw klas (interfejsów) umożliwiających takie połączenie. C++ jest językiem bardzo popularnym, będąc jednocześnie mocno krytykowanym za cechy niskiego poziomu (np. arytmetyka wskaźników). Pozwala to przypuszczać, że w dalszej przyszłości wiązanie do C++ straci na znaczeniu, na korzyść rozbudowy języka OQL oraz wiązań do języków takich jak Smalltalk i Java.

Wiązania do języków Smalltalk i Java. Mają założenia podobne do wiązania do C++. W odróżnieniu od C++ występują tu ograniczenia. Smalltalk i Java nie mają wielodziedziczenia, co wymaga okrojenia modelu obiektowego i ODL. Występują także ograniczenia w zakresie definiowania i przetwarzania związków (relationships). Wiązanie do języka Java jest ostatnio przedmiotem szczególnego zainteresowania.

Standard ODMG 2.0 wykazuje liczne braki i wady koncepcji, w związku z czym należy oczekiwać, że zostanie wkrótce zastąpiony przez następną wersję. W stosunku do wersji książkowej dokumentu ostatnie nowelizacje standardu dotyczą wiązania do Java.

http://www.odmg.org

ODMG-93 Starsza wersja standardu ODMG; patrz: ODMG 2.0.

odporność (robustness) Określenie możliwości poprawnego funkcjonowania w nienormalnej lub wyjątkowej sytuacji. Patrz też: moc.

odpowiedzialność (responsibility) Cel, zobowiązanie lub wymagane możliwości obiektu lub klasy. Z reguły odpowiedzialność jest określona jako zestaw usług realizowanych przez obiekt lub klasę oraz jego/jej cech.

odsyłacz (reference) Patrz: referencja.

odśmiecacz (garbage collector, GC) Patrz: zbieranie nieużytków.

odśmiecanie (garbage collection) Patrz: zbieranie nieużytków.

odtwarzanie (recovery) Odtwarzanie stanu bazy danych po awarii na podstawie ostatniej wersji składowanej (back-up) oraz dziennika (log).

odwracanie (rollback) Po zerwaniu transakcji wycofanie się ze wszelkich zmian w bazie danych poczynionych przez tę transakcję.

odwzorowanie językowe (language mapping) Odwzorowanie konstrukcji jednego

137


języka na konstrukcje innego języka; np. odwzorowania wyrażeń IDL CORBA na deklaracje klas w C++.

ograniczenia integralnościowe (integrity constraints) Patrz: więzy integralności.

ograniczenie (constraint) Dowolne ograniczenie wprowadzane do schematu danych, diagramu klas, itd. w postaci formalnej, półformalnej lub nieformalnej. Patrz też: więzy integralności.

ograniczenie Millera (Miller limit) Ograniczenie ludzkiej percepcji i rozumienia wynikające ze złożoności, która staje się istotna przy liczbie elementów siedem plus minus dwa. Popularne zalecenie w projektowaniu graficznych interfejsów użytkownika.

OID (Object Identifier, Object IDentity) Identyfikator obiektu, tożsamość obiektu. Patrz też: mrówka.

OLAP (On Line Analytical Processing) Technologia przetwarzania i udostępniania danych analitycznych i syntetycznych polegająca na gromadzeniu danych z różnych źródeł, zapisaniu ich w pewnym regularnym formacie (np. w postaci tzw. kostki danych, data cube) i następnie analizowaniu ich przy pomocy różnorodnych narzędzi, np. statystycznych. OLAP często kojarzy się z hurtowniami danych (data warehouses) oraz z eksploracją danych (data mining).

http://www.olapcouncil.orghttp://www.access.digex.net/~grimes/olap/http://www.arborsoft.com/papers/finkTOC.html

OLE (Object Linking and Embedding) Standard interfejsu (częściowo) obiektowego, umożliwiający wymianę obiektów pomiędzy różnym oprogramowaniem firmy Microsoft. OLE jest uogólnieniem popularnego „schowka” umożliwiającego kopiowanie fragmentów dokumentów zapisanych w różnych formatach. Obiektami OLE mogą być pliki edytora Word, grafika ze skanera w odpowiednich formatach, grafika wektorowa, tablice, pliki Excela, itd. Patrz też: OLE2 i COM.

OLE Automation Własność standardu OLE2 firmy Microsoft, która umożliwia aplikacji lub obiektowi OLE komunikowanie się z innym obiektem OLE poprzez przesyłanie sekwencji komend, zwykle ustawiających pewne własności lub wykonujących pewne metody. Patrz też: OLE2.

OLE2 Nowsza koncepcja OLE rozszerzona o możliwość jednoczesnej pracy z wieloma aplikacjami działającymi w systemie Windows. OLE2 włącza prosty model komunikacji, który jest używany przez aplikacje do koordynowania dostępu do ekranu. W uzupełnieniu do OLE, OLE2 posiada także mechanizm „przesuń i upuść” (Drag and Drop), umożliwiający przesuwanie obiektów (np. komponentów dokumentów) pomiędzy oknami. OLE2 włącza również pakiet OLE Automation, pozwalający zapisać w aplikacjach sekwencję operacji OLE w postaci skryptu i następnie wykonywać ten skrypt w trybie wsadowym. OLE Automation umożliwia też koordynowanie wielu aplikacji celem wykonania złożonych zadań. Komponenty w C++, VisualBasic i innych

138


językach, które mają zastosowanie w aplikacjach poprzez OLE Automation, są określane jako OLE Controls. Patrz też: COM.

OLTP (On-Line Transaction Processing) Przetwarzanie transakcji on-line; przetwarzanie transakcji w systemie rozproszonym w czasie rzeczywistym. W typowym ustawieniu aplikacja OLTP powtarza wykonanie transakcji z pewnego z góry zdefiniowanego zestawu (z reguły zapisanych w SQL). Transakcje te są nadsyłane równolegle i niezależnie przez klientów aplikacji, przy czym żadna z nich nie może zmonopolizować zasobów komputera lub bazy danych. Technologia OLTP jest często związana z wyrafinowanym dostrajaniem i optymalizacją bazy danych oraz algorytmów przetwarzania pod kątem uzyskania maksymalnej wydajności przy założonym zestawie i profilu transakcji.

OMA (Object Management Architecture) Architektura zarządzania obiektami; termin OMG. OMA jest wizją wysokiego poziomu kompletnego środowiska rozproszonego. OMA składa się z czterech części: dwie systemowe (pośrednik zleceń obiektowych (Object Request Broker, ORB) i usługi obiektowe (Object Services)), oraz dwie zorientowane na aplikacje (obiekty aplikacyjne (Application Objects) i wspólne udogodnienia (Common Facilities)). ORB stanowi podstawę OMA zarządzając całą komunikacją pomiędzy jej składnikami. Umożliwia on interakcję obiektów w środowisku rozproszonym i heterogenicznym, niezależnie od platform sprzętowych, na których znajdują się obiekty, oraz technik, które były użyte do ich implementacji. W tym zadaniu ORB jest wspomagany przez usługi obiektowe, które są odpowiedzialne za ogólne zarządzanie obiektami, w tym tworzenie obiektów, sterowanie dostępem, przesuwanie obiektów, itd. Obiekty aplikacyjne i wspólne udogodnienia znajdują się bliżej użytkownika; ich funkcją jest m.in. wysyłanie zleceń do ORB i usług obiektowych.

Object Request Broker(Pośrednik Zapotrzebowania na Obiekty)

Interfejsyaplikacyjne

Interfejsydziedzinowe

Wspólneudogodnienia

ObiektoweUsługi

“Software Bus”

Architektura OMA

http://www.omg.org

139


Omega Obiektowy język programowania w duchu języków Smalltalk i Self, bazujący na pojęciu prototypu. Omega posiada statyczną kontrolę typów.

OMG (Object Management Group) Organizacja skupiająca wiele czołowych firm komputerowych (aktualnie ponad 800), mająca na celu opracowanie standardu współdziałania pomiędzy heterogenicznymi, rozproszonymi systemami obiektowymi i nieobiektowymi. Propozycja standardu nosi nazwę CORBA. Patrz też: CORBA.

http://www.omg.org

OML (Object Manipulation Language) Język manipulacji obiektami. Termin ODMG oznaczający zestaw klas, metod i interfejsów umożliwiający programowanie obiektowej bazy danych w językach C++, Smalltalk lub Java.

Omniscience Obiektowy system zarządzania bazą danych zrealizowany przez firmę Omniscience Object Technology, Inc.

OMT (Object Modeling Technique) Metodyka analizy i projektowania obiektowego zaproponowana przez J. Rumbaugh i innych autorów. Metodyka identyfikuje trzy zadania: analizę, projektowanie systemu oraz projektowanie obiektowe. Wprowadza trzy perspektywy lub modele systemu: model (klas) obiektów, model dynamiczny oraz model funkcjonalny (wariant modelu przepływu danych). Zawiera także wiele rozważań przydatnych dla projektowania i implementacji. Wyróżnione są następujące pojęcia: klucze kandydujące, ograniczenia, obiekty pochodne, homomorfizm, współbieżność, bezpośrednia (peer-to-peer) komunikacja. OMT jest bardzo (najbardziej?) popularną metodyką obiektową. Charakteryzuje się dużym poziomem abstrakcji, nie schodzi zbytnio na poziom projektowania i implementacji. Stosowana terminologia jest intuicyjna, ale nie zawsze jasna.

Ontos DB Obiektowy system zarządzania bazą danych firmy Ontologic, obecnie ONTOS, Inc.

http://www.ontos.com/tool.htm

OO (Object-Oriented) Obiektowy. Patrz: obiektowość

OOA (Object-Oriented Analysis) Patrz: analiza obiektowa.

OOA/OOD (Object-Oriented Analysis/Object-Oriented Design) Obiektowa metodyka analizy i projektowania systemów informatycznych, inaczej Coad/Yourdon. Wyróżnia pięć aktywności: wyodrębnienie klas i obiektów, wyodrębnienie struktur, wyodrębnienie podmiotów lub dziedzin, określenie atrybutów, określenie usług. Posiada w związku z tym pięć poziomów: podmioty, klasy i obiekty, struktury, atrybuty oraz usługi. Składowymi metody są: interakcja z ludźmi, określenie dziedziny problemu, zarządzanie zadaniami, zarządzanie danymi. Wyróżnialnymi cechami metodyki są: przesyłanie komunikatów, terminologia obiektowa, komponenty projektowe. OOA/OOD jest uważana za metodykę dość złożoną i opartą na zbyt wielu wyrafinowanych pojęciach.

140


OOAD [1] (Object-Oriented Analysis and Design) Patrz: analiza i projektowanie obiektowe.

OOAD [2] (Object-Oriented Analysis and Design) Obiektowa metodyka analizy i projektowania systemów informatycznych, inaczej Martin/Odell. Metodyka bazuje na pojęciach z zakresu logiki i teorii zbiorów. Jest uważana za metodykę wprowadzającą szereg użytecznych pojęć, ale nie obejmującą pełnego procesu analizy i projektowania.

OO-CASE (Object-Oriented CASE) Patrz: obiektowy system CASE.

OO-Cobol (Object-Oriented Cobol) Obiektowy język programowania będący rozszerzeniem języka Cobol. OO-Cobol jest wynikiem prac standardyzacyjnych ANSI, dokument ANSI/X3J4/94-0191.

http://www.tiac.net/users/jsuth/papers/oocobol.htmlhttp://www.mfltd.co.uk/OC/index.html

OOD (object-oriented design) Patrz: obiektowe projektowanie.

OODA (Object-Oriented Design with Applications) Obiektowa metodyka analizy i projektowania systemów informatycznych opracowana przez G. Boocha. OODA jest podzielona na cztery kroki: identyfikacja klas i obiektów; identyfikacja ich semantyki; identyfikacja związków pomiędzy obiektami; implementacja klas i obiektów.

OODA bazuje na siedmiu zasadach: abstrakcji, hermetyzacji, modularności, hierarchii klas i obiektów, kontroli typów, współbieżności i trwałości. Składowe klas są podzielone na trzy typy: publiczne (public), zabezpieczone (protected) i prywatne (private). OODA wprowadza cztery perspektywy systemu: logiczna statyczna, logiczna dynamiczna, fizyczna statyczna i fizyczna dynamiczna. Wprowadza następujące typy diagramów: klas i obiektów, przejść między stanami, modułów i procesów. OODA jest dość silnie uzależniona od struktur językowych C++. Ogólne pojęcia służące do projektowania oraz wprowadzane techniki są dość proste i łatwe do zrozumienia. Poziom projektowania jest bliższy strukturom fizycznym i implementacyjnym, niż to ma miejsce w innych metodykach.

OODB (object-oriented database) Patrz: obiektowa baza danych.

OODBMS (object-oriented database management system) Patrz: obiektowy system zarządzania bazą danych.

OOF (Object-Oriented Fortran) Obiektowa wersja języka Fortran.

OOIS (Object-Oriented Information Systems) Coroczna konferencja nt. obiektowych systemów informacyjnych.

141


OOP (Object-Oriented Programming) Patrz: programowanie obiektowe.

OOPL (Object-Oriented Programming Language) Patrz: obiektowy język programowania.

OOPSLA (Object-Oriented Programming Systems, Languages and Applications) Cykliczna konferencja z zakresu obiektowości.

OORAM Obiektowa metodyka analizy i projektowania systemów informatycznych.http://www.oslonett.no/html/adv/TASKON/prod/OORAM.htmlhttp://www.oslonett.no/html/adv/TASKON/prod/verkt.htmlhttp://www.oslonett.no/html/adv/TASKON/TASKON.html

OOSA (Object Oriented System Analysis) Obiektowa metodyka analizy i projektowania systemów informatycznych, inaczej Shlaer/Mellor. Metodyka jest oparta na technice modelowania informacji i wprowadza trzy modele: model informacyjny, model stanów i model procesów. Model informacyjny definiuje jednostki pojęciowe wyróżnialne w świecie jako obiekty systemu. Model stanów opisuje cykl życiowy tych obiektów. Model procesów uszczegóławia aktywności obiektów w postaci diagramów przepływu danych. Modele te powinny być połączone dla uzyskania zintegrowanej perspektywy systemu. Specyfikacja zewnętrza opisuje funkcje, które wykonują obiekty systemu na bytach zewnętrznych. Metodyka zwraca uwagę na opis wnętrza systemu, ale jest nieco słabsza w zakresie opisu związków pomiędzy obiektami i klasami.

Opal Język programowania aplikacji systemu Gemstone.

opcyjny (optional) Atrybut, wartość, konstrukcja językowa lub inna cecha, która może być nieobecna (nie musi występować w każdym przypadku).

OPEN Metodyka obiektowa oraz notacja, sukcesor metodyki MOSES. Wymieniana niekiedy jako konkurent metodyki OMT i notacji UML. Akronimem OML (OPEN Modeling Language) oznaczony jest metamodel oraz notacja związana z metodyką OPEN. Metodykę OPEN reklamuje się jako uniwersalną, trzeciej generacji, obejmującą pełny cykl rozwoju oprogramowania.

http://www.csse.swin.edu.au/cotar/OPEN/

OpenDoc Oprogramowanie pośredniczące, wieloplatformowa architektura oprogramowania (Apple Macintosh OS, MS Windows, O/S 2, AIX, UNIX) realizująca koncepcję oprogramowania komponentowego. OpenDoc jest rozwijany przez Component Integration Laboratories (CI Labs), niedochodową organizację skupiającą ponad 300 firm, w tym Apple, IBM, Lotus, Adobe, Novell, WordPerfect, Taligent, XSoft/Xerox. OpenDoc umożliwia łączenie wielu komponentów w jedną aplikację (zamiast budowania jednej dużej aplikacji), co znacznie podnosi efektywność tworzenia aplikacji, potencjał ponownego użycia i współdziałania pomiędzy niezależnie zbudowanym oprogramowaniem. Umożliwia także integrację danych multimedialnych (tekst, audio, wideo, grafika bitowa, arkusze kalkulacyjne), integrację aplikacji bazujących na sieci Internet oraz zintegrowany dostęp do zasobów WWW poprzez

142


pakiet/przeglądarkę CyberDog. OpenDoc współdziała z narzędziami i obiektami technologii OLE2. OpenDoc wprowadza dwa główne pojęcia: dokumentu (obiektu o budowie hierarchicznej integrującego informację statyczną, wizualną i proceduralną) oraz komponentu (fundamentalnego bloku oprogramowania), i składa się z pięciu warstw funkcjonalnych: Obsługa złożonych dokumentów; Obsługa komponentów; Obsługa pracy wsadowej (Automation Services); Obsługa zarządzania obiektami; Obsługa współdziałania.

Obsługa zarządzania obiektami bazuje na SOM (System Object Model) firmy IBM, który jest pośrednikiem w zakresie przetwarzania rozproszonych obiektów zgodnym ze standardem OMG CORBA. Również porozumienie Apple z firmą IONA przewiduje przystosowanie pakietów OpenDoc i Orbix do bezpośredniego współdziałania. Przewiduje się także integrację z innymi pakietami ORB w ramach standardu CORBA.

http://www.cilabs.org/

OpenIngres Starsza (obecnie nie podtrzymywana) wersja systemu Ingres II.

OpenRoad Wizyjny obiektowy język programowania czwartej generacji opracowany dla systemu OpenIngres przez firmę Computer Associates. OpenRoad włącza wiele elementów obiektowości, takich jak klasy i metody.

operacja (operation) Funkcja dokonująca przekształcenia danych lub wartości. Synonimy: metoda, funkcja.

operacja abstrakcyjna (abstract operation) Patrz: metoda abstrakcyjna.

operacja klasowa (class operation) Operacja działająca nie na obiektach danej klasy, ale na samej klasie (ściślej, na ekstensji klasy), np. konstruktor lub destruktor. Synonim: metoda klasowa.

operacja obca (foreign operation) Operacja importowana z innego modułu, języka, programu, itd.

operacja pochodna (derived operation) Operacja, którą można wyrazić poprzez proste złożenie (wywołanie) innych operacji.

oprogramowanie aplikacyjne (application software) Oprogramowanie wykonujące bezpośrednio pewne funkcje lub usługi na rzecz danego klienta lub dziedziny przedmiotowej.

oprogramowanie komponentowe (component software, componentware) Dziedzina rozwojowa i praktyczna zmierzająca do budowy standardów oraz wspomagającego je oprogramowania, które pozwoliłoby na składanie dużych aplikacji lub systemów z mniejszych standardowych części - komponentów (na zasadzie

143


podobnej do składania komputera z podzespołów). Niektórzy specjaliści uważają oprogramowanie komponentowe za naturalny rozwój programowania obiektowego oraz perspektywę na bliższą i dalszą przyszłość. Przykładami standardów i systemów oprogramowania komponentowego są: OMG CORBA, OpenDoc firm Apple, IBM i innych, technologia OLE2/COM/DCOM/ActiveX firmy Microsoft oraz pakiet JavaBeans firmy JavaSoft/Sun. W świecie komercyjnym trwa batalia pomiędzy konkurencyjnymi pakietami oprogramowania komponentowego (szczególnie pomiędzy ActiveX i JavaBeans). Pewien sceptycyzm względem oprogramowania komponentowego jest powodowany przez fakt, że tego rodzaju pomysły (określane różnie: mega-programming, programming-in-the-large, itp.) są znane od ok. 30-tu lat, nie przynosząc istotnego postępu w tym zakresie. Zasadniczym powodem są trudności w precyzyjnym i dostatecznie abstrakcyjnym wyspecyfikowaniu interfejsów pomiędzy komponentami, problemy z osiągnięciem akceptowalnej wydajności oraz stały burzliwy postęp w informatyce, powodujący pojawianie się coraz to nowych wymagań na te interfejsy.


oprogramowanie pośredniczące (middleware) Terminem tym określa się wszelkie oprogramowanie, którego zadaniem jest łączenie innego oprogramowania, w szczególności pomosty (gateways) pomiędzy systemami, pośredników (ORB) zbudowanych według standardu OMG CORBA, OpenDoc firm Apple, IBM i innych, technologia COM/DCOM firmy Microsoft, rozproszone systemy operacyjne takie OSF DCE lub ANSA Ware i inne.

http://www.omg.org

oprogramowanie spadkowe (legacy software) Starsze oprogramowanie, które musi być zastąpione lub przystosowane do nowego oprogramowania, nowego sprzętu, itd.

optymalizacja zapytań (query optimization) Dziedzina badawcza i praktyczna zajmująca się metodami, technikami i teoriami służącymi do radykalnego skrócenia czasu wykonywania zapytań. Optymalizator zapytań (query optimizer) jest fragmentem oprogramowania systemu zarządzania bazą danych zajmującym się skróceniem czasu wykonania zapytań. Terminy „optymalizacja” i „optymalizator” są tutaj używane niewłaściwie, ponieważ nie jest rozważane optimum z punktu widzenia jakiegokolwiek formalnego kryterium, a raczej chodzi o osiągnięcie takiego czasu przetwarzania zapytania, który jest akceptowalny z punktu widzenia użytkownika. Metody optymalizacji zapytań można podzielić na następujące grupy: Poziom fizyczny organizacji danych - można tu wyróżnić indeksy (najczęściej

organizowane jako B-drzewa), kodowanie mieszające (hash coding) i powiązania wskaźnikowe (pointer links);

Przekształcenie zapytania na taką semantycznie równoważną postać, która rokuje lepszy czas przetwarzania. Zazwyczaj takie przekształcenie odbywa się na tekście zapytania lub na jego drzewie syntaktycznym; metody te określa się jako przepisywanie (rewriting). Dla języków implementowanych w relacyjnych bazach danych (SQL) istotne efekty daje przesunięcie wykonania operatorów selekcji i

144


projekcji przed operator złączenia; Wysoko wyspecjalizowane algorytmy dla niektórych operatorów, np. realizacja

operatora złączenia przez posortowanie argumentów i „scalenie” (merging), lub poprzez kodowanie mieszające;

Ustalenie optymalnego planu obliczania wyników pośrednich (query execution plan).

Optymalizacja zapytań wymaga precyzyjnego modelu semantyki, skąd wynika nacisk na matematyczną formalizację języków zapytań. W szczególności, niektóre metody są oparte o równoważne przekształcenia wyrażeń algebry relacji, którą uważa się za dobry model formalny dla opisu semantyki relacyjnych języków zapytań, m.in. SQL. Model ten jest jednak bardzo ograniczony i nie zawsze adekwatny, stąd większość metod optymalizacji zapytań jest wynikiem obserwacji i spekulacji praktycznych, eksperymentów i heurystyki. Wiedza dotycząca optymalizacji zapytań jest bardzo mało stabilna, gdyż nowe języki (np. obiektowe) często implikują nowe problemy i metody.

optymalizator zapytań (query optimizer) Moduł lub mechanizm bazy danych dokonujący optymalizacji zapytań.

optymistyczny model transakcji (optimistic transaction model) Model transakcji zakładający, że prawdopodobieństwo niekorzystnych interferencji transakcji (utraty spójności danych lub przetwarzania wskutek jednoczesnego dostępu do tej samej danej) jest niskie. W związku z tym (w odróżnieniu od modelu pesymistycznego) model optymistyczny nie zakłada konieczności blokowania dostępu do danych poprzez zakładanie zamków. Jeżeli jednak pewna dana przetwarzana przez daną transakcję jest jednocześnie przetwarzana przez inną transakcję (transakcje), wówczas traktowane jest to jako konflikt. Efektem jest zerwanie wszystkich transakcji uczestniczących w konflikcie. Metody wykrywania konfliktów są oparte o analizę kolejności dostępu poszczególnych transakcji do poszczególnych danych i/lub o stemple czasowe (stawiane przez transakcje na przetwarzanych przez nie danych). Optymistyczny model transakcji unika problemu zakleszczenia (deadlock), ale może być nieefektywny w przypadku dużej liczby konfliktów.

OQL (Object Query Language) Obiektowy język zapytań wg standardu ODMG. Składnia OQL jest wzorowana na SQL. Pod względem semantyki OQL bazuje na modelu obiektowym ODMG oraz wprowadza mocną kontrolę typów (co zasadniczo różni go od SQL). OQL posiada operatory podobne do operatorów SQL, ale wprowadza także szereg nowych, m.in. zależne złączenie i operatory umożliwiające konstruowanie złożonego wyniku. OQL jest dość mocnym językiem (w zakresie wyszukiwania mocniejszym od SQL); posiada również znacznie bardziej ortogonalną konstrukcję niż SQL. Podstawową wadą OQL jest zbyt luźne zintegrowanie z interfejsami i konstrukcjami programistycznymi, co nieuchronnie prowadzi do efektu określanego jako niezgodność impedancji (ten oczywisty wniosek jest demagogicznie negowany przez twórców OQL). Innymi wadami OQL są: niezbyt precyzyjna semantyka, brak uniwersalności, brak możliwości definiowania perspektyw (views) i abstrakcji proceduralnych takich jak operacje aktualizacyjne, metody, zapamiętane procedury i reguły. Jest prawdopodobne, że w następnych wersjach standardu wady te zostaną

145


usunięte (przynajmniej częściowo). Wydaje się, że zauważalny brak nacisku na rozwój OQL wynika z (kontrowersyjnego i niejawnego) założenia twórców standardu ODMG, że zasadniczo programowanie aplikacji z obiektową bazą danych powinno odbywać się w językach C++, Smalltalk lub Java. Poniżej znajduje się kilka przykładów w OQL.

Operator select wewnątrz from:

select struct( w: x.wiek, p: x.płeć )from (select y from Pracownicy as y where y.gr_zawodowa = 10) as xwhere x.nazwisko = “Nowak”

Zależne złączenie:

select s.nazwisko, w.nazwa_wykładu from Studenci as s, s.zapisany_na as w

Złożone warunki i złączenia:

select d.adres from Osoby as x, x.dzieci as d where x.adres.ulica = “Chrobrego”

and count(x.dzieci) >= 2 and d.adres.miasto != x.adres.miasto

http://www.odmg.org

Oracle-8 Nowa wersja Oracle, relacyjnego systemu zarządzania bazą danych, wprowadzająca niektóre elementy obiektowości. Oracle-8 wprowadza takie cechy jak: duże obiekty (BLOB-y, CLOB-y, pliki binarne), typy obiektów, kolekcje, typy referencyjne, zewnętrzne procedury jako metody obiektów, obiektowe perspektywy, szybką nawigację pomiędzy obiektami, narzędzia do modelowania i rozwijania obiektowych aplikacji, wspomaganie dla niestrukturalnych danych (obrazów, wideo, tekstu, itd.) oraz wspomaganie dla programowania w Java. Oracle-8 jest częściowo oparty na (tworzonym) standardzie SQL3 w zakresie składni do konstruowania i modyfikacji typów obiektów, generowania i przechowywania identyfikatorów obiektów, tworzenia referencji lub wskaźników prowadzących do obiektów oraz modelowania kolekcji podobnych obiektów.

http://www.oracle.com/http://tiburon.us.oracle.com/

ORB (Object Request Broker) Wg standardu OMG CORBA, pośrednik umożliwiający ujednolicony dostęp do obiektów na wysokim poziomie abstrakcji, abstrahujący od geograficznego rozproszenia obiektów i sposobu ich fizycznej implementacji. Niektórzy autorzy używają akronimu ORB i terminu pośrednik (broker) jako ogólne określenie dowolnego obiektowego oprogramowania pośredniczącego (middleware), np. technologii DCOM lub systemów rozproszonych opartych o Internet. Wg standardu CORBA, centralnym składnikiem ORB jest jego rdzeń (ORB core), który zajmuje się całą infrastrukturą niezbędną do identyfikacji i zlokalizowania obiektów, nawiązywaniem połączeń w sieci oraz dostarczaniem danych. Klienci komunikują się z rdzeniem ORB poprzez pniaki (stubs) generowane z wyrażeń języka opisu interfejsu IDL. Pniaki są fragmentami oprogramowania, które są statycznie wiązane do aplikacji klienta. Oprócz tego, ORB umożliwia wołania dynamiczne poprzez tzw. interfejs wołań

146


dynamicznych (Dynamic Invocation Interface, DII). Z drugiej strony, ORB dostarcza zlecenia klientów do implementacji obiektów. Odbywa się to poprzez szkielety (skeletons), które są również generowane z wyrażenia IDL i następnie uzupełniane poprzez kod implementacji metod, oraz poprzez adapter obiektów (Object Adapter), który dostosowuje interfejs specyficzny dla implementacji obiektów na interfejs bardziej abstrakcyjny oczekiwany przez klienta. Patrz też: CORBA.

http://www.omg.org

ORBeline Pośrednik wymiany obiektów (ORB) wg standardu OMG CORBA, rozwijany i rozpowszechniany przez firmę Post Modern.

Orbix Pośrednik wymiany obiektów (ORB) zgodny ze standardem OMG CORBA, rozwijany i rozpowszechniany przez firmę IONA. Orbix jest prawdopodobnie najbardziej zgodną i kompletną implementacją standardu CORBA. Jest on systemem szeroko stosowanym, w szczególności w obiektowych SZBD. Orbix posiada wbudowane możliwości zintegrowania obiektów CORBA z WWW.

http://www.iona.ie/products/

OrbixWeb Beta wersja systemu Orbix współpracująca z Java i protokołem IIOP.http://www.iona.ie/products/http://www.corbajava.engr.sjsu.edu

ORBPlus Pośrednik wymiany obiektów (ORB) wg standardu OMG CORBA, rozwijany i rozpowszechniany przez firmę HP.

ORDBMS (Object-Relational Data Base Management System) Obiektowo-relacyjny system zarządzania bazą danych; patrz: obiektowo-relacyjny.

organizacja gron (clustering) Metody organizacji zbiorów danych polegające na tym, że semantycznie związane dane (np. połączone poprzez wskaźniki) są ulokowane w bezpośrednim sąsiedztwie na nośniku zewnętrznym (np. na dysku). Dzięki temu minimalizuje się czas transmisji danych z dysku do pamięci operacyjnej i odwrotnie.

ORSZBD Obiektowo-Relacyjny System Zarządzania Bazą Danych (Object-Relational Database Management System, ORDBMS). Patrz: obiektowo-relacyjny.

ortogonalna trwałość (orthogonal persistence) Koncepcja lub zasada, zgodnie z którą cecha trwałości obiektu powinna być całkowicie ortogonalna w stosunku do jego typu. Np. baza danych może przechowywać pojedyncze (atomowe) zmienne, zaś zmiennymi lokalnymi procedury mogą być relacje. Ortogonalna trwałość oznacza ujednolicenie środków dostępu i manipulacji trwałymi i ulotnymi danymi (obiektami). Koncepcja ortogonalnej trwałości, jakkolwiek naturalna zarówno z koncepcyjnego jak i z technicznego punktu widzenia, wzbudza obiekcje ze strony twórców systemów baz danych (w tym obiektowych), głównie z tego powodu, że zostały one zaprojektowane bez uwzględnienia tej cechy.

ortogonalność (orthogonality) Zasada dobrego konstruowania języków i systemów

147


oznaczająca nie łączenie pod wspólną czapką syntaktyczną wielu niezależnych od siebie cech. Zasada ta umożliwia znaczne zmniejszenie rozmiaru specyfikacji języka, zwiększenie jego mocy, uproszczenie implementacji oraz zmniejszenie czasu uczenia. Zasada ta wyraża się prostym zdaniem: “Niech rzeczy niezależne pozostaną niezależne” (keep unrelated things unrelated). Zasady ortogonalności nie spełnia SQL, gdyż bazuje na dużym syntaktycznym zlepku wielu operatorów.

ortogonalny (orthogonal) Wzajemnie niezależny, dobrze oddzielony, dający się dowolnie łączyć. Czasami ortogonalny oznacza nierelewantny, nie mający znaczenia dla danej rzeczy lub problemu. Cechy (języka, systemu, interfejsu, itd.) są ortogonalne, jeżeli posiadają odrębne, niezależne od siebie definicje oraz możliwe jest dowolne ich kombinowanie, łączenie lub zanurzanie. Język jest ortogonalny, jeżeli różne jego semantyczne konstrukcje nie są wiązane ze sobą poprzez składnię (można je używać niezależnie i dowolnie ze sobą kombinować). Termin „ortogonalny” pochodzi z matematyki, gdzie oznacza niezależność pewnej cechy od innej cechy.

OS (Object Services) Patrz: usługi obiektowe.

OSA (Object-oriented System Analysis) Obiektowa metodyka analizy i projektowania systemów informatycznych zaproponowana przez D.W. Embley’a i innych.

http://osm7.cs.byu.edu/OSA/tutorial.htmlhttp://osm7.cs.byu.edu/

OSF (Open Software Foundation) Organizacja i fundacja powołana przez kilku czołowych producentów oprogramowania (Apollo, DEC, HP, IBM, Bull, Nixdorf, Philips, Siemens i Hitachi), której celem jest opracowanie i wypromowanie jednolitego systemu operacyjnego i interfejsów (opartych na idei systemów UNIX, systemu X Windows, itd.), który byłby wspólny dla szerokiej gamy różnych architektur sprzętowych. Efektem działalności fundacji jest m.in. propozycja rozproszonego systemu operacyjnego DCE (Distributed Computing Environment).

http://www.dstc.edu.au/AU/research_news/dce/dce.html

osłona (wrapper) Obiekt, zestaw obiektów lub oprogramowanie zapewniające obiektowy interfejs do nieobiektowego oprogramowania lub nieobiektowej bazy danych, np. tzw. spadkowych (legacy) baz danych. Terminu tego używa się również dla oznaczenia oprogramowania dokonującego (wirtualnego) odwzorowania informacji niestrukturalnej (np. tekstów prezentowanych na stronach WWW) na pewien strukturalizowany format (np. obiekty z atrybutami).

osłonowanie (wrapping) Tworzenie osłon, np. do oprogramowania spadkowego. Patrz: osłona.

OSMOS Obiektowo-relacyjny system zarządzania bazą danych zrealizowany przez firmę Unisys Corporation.

http://www.marketplace.unisys.com/urep/osmos/http://www.osmos.com/

148


OSQL (Object SQL) Obiektowe rozszerzenie języka SQL zaimplementowane w systemie Iris firmy HP.

OSZBD (ODBMS, OODBMS) Patrz: obiektowy system zarządzania bazą danych.

OTM (Object Transaction Monitor) Obiektowy monitor transakcji. Synonim, lub generalizacja terminu ORB (Object Request Broker). OTM jest określeniem przyszłego oprogramowania pośredniczącego (middleware), które będzie łączyć krytyczne cechy monitorów przetwarzania transakcyjnego (TP monitors) (takie jak: niezawodność, duża przepustowość, przewidywalny czas odpowiedzi, integralność transakcji, zbalansowanie obciążenia i łatwość zarządzania) z interfejsami obiektowymi oferowanymi poprzez pakiety ORB.

otoczenie (environment) Patrz: środowisko.

otwarta skrzynka (open box) Termin wiązany z ponownym użyciem (reuse), oznaczający taki aktyw ponownego użycia, który można użyć po rozpoznaniu i ewentualnej zmianie wewnętrznej zawartości.

otwarty system (open system) Termin (ostatnio rzadziej używany) oznaczający możliwości współdziałania danego systemu z innymi systemami oraz możliwości pracy w sieciach komputerowych oraz integrację różnych platform sprzętowych, systemów operacyjnych, języków programowania i systemów zarządzania bazami danych. Niekiedy tym terminem określa się także łatwość rozbudowy systemu o owe funkcje.

PP Q

pakiet (package) W niektórych językach programowania (np. Ada) synonim modułu lub abstrakcyjnego typu danych. Powszechnie termin ten oznacza pewien spójny zestaw wzajemnie powiązanych procedur, klas lub innych elementów programistycznych przeznaczonych do realizacji określonego celu.

paradygmat programowania (programming paradigm) Określenie podstawowego stylu i technik, oraz wspomagających je konstrukcji danego języka programowania. Paradygmat proceduralny (procedural) lub imperatywny (imperative) oznacza, że program jest sekwencją instrukcji zmieniających stan zmiennych programu, stan obiektów, stan bazy danych, stan urządzeń wejściowo/wyjściowych, itd. (np. Pascal lub C). Paradygmat deklaracyjny (declarative) oznacza bezpośrednie formułowanie celu przetwarzania, a nie akcji prowadzących do tego celu (np. Prolog lub języki zapytań). Paradygmat funkcjonalny (functional) oznacza język, w którym programowanie polega na używaniu funkcji operujących na wartościach i zwracających wartości (np. Lisp lub ML). Paradygmaty deklaracyjny i funkcjonalny ze względu na brak pojęcia stanu wymagają wspomagania konstrukcjami proceduralnymi. Programowanie obiektowe uważane jest niekiedy za samodzielny paradygmat programowania, ale częściej jest postrzegane jako odmiana paradygmatu proceduralnego (np. R. Martin uważa, że

149


obiektowość wniosła radykalny postęp do analizy i projektowania, ale bardzo małą zmianę do stylu programowania; podobne zdanie ma B. Stroustrup). Inny podział paradygmatów programowania jest zorientowany na styl definicji języka. Rozróżniana jest rodzina języków BCPL (włączająca C i C++) korzeniami tkwiąca w ulepszaniu assemblera, rodzina języków takich jak Lisp, ML, Smalltalk i CLU, które są pochodną spekulacji teoretycznych (w tym formalnych) oraz rodzina języków Algolo-podobnych, takich jak Pascal, Ada, Modula-2, Modula-3 i Oberon. Należy przyznać, że kryteria tego podziału są rozmyte i w gruncie rzeczy oparte na dość powierzchownych cechach, takich jak składnia, słowa kluczowe i jakość kontroli typów.

parametr aktualny (actual parameter) Wyrażenie występujące na miejscu pewnego parametru formalnego procedury, funkcji lub metody, albo wartość parametru obliczona w momencie wywołania procedury, funkcji lub metody. Synonim: argument.

parametr formalny (formal parameter) Nazwa oraz typ parametru metody, funkcji albo procedury określone w ramach jej definicji, deklaracji lub sygnatury.

parametr metody (method parameter) Nazwana wartość, która jest określana w momencie wywołania metody i następnie wykorzystywana wewnątrz jej kodu; np. dla metody ZmieńZarobek parametrem może być wartość liczbowa nazwana NowyZarobek. Istnieje szereg technik i konwencji językowych określania parametrów dla metod; patrz: przekazywanie parametrów.

parametryczny polimorfizm (parametric polymorphism) Patrz: polimorfizm parametryczny.

Pegasus Obiektowy system zarządzania bazą danych firmy Hewlett-Packard, którego intencją jest współdziałanie z innymi systemami, w tym DB2, Informix, Oracle, Sybase, OpenODB i IMS. Pegasus jest oparty na języku zapytań i manipulacji HOSQL (Heterogeneous Object SQL), który jest rozszerzeniem języka OSQL systemu Iris.

Perl-5 Nowa wersja języka Perl wspomagająca programowanie obiektowe.

Persistence Obiektowy system zarządzania bazą danych zrealizowany przez firmę Persistence Software, Inc.

Persistent Java Patrz: PJama.

personifikacja (personification) Przypisywanie obiektom cech ludzkich; synonim: antropomorfizm.

perspektywa (view) W szerszym znaczeniu, obraz pojęciowy danych, który jest przypisany do pojedynczego użytkownika (lub ich grupy) i abstrahuje od danych nieistotnych dla jego działalności. Tak rozumiana perspektywa dokonuje adaptacji (customization) danych dla wygody i/lub przyzwyczajeń użytkownika. W węższym znaczeniu (np. w SQL) perspektywa jest funkcją (procedurą funkcyjną) odwzorowującą zapamiętane dane w dane wirtualne, przy czym (idealistycznie) z punktu widzenia

150


użytkownika dane wirtualne są wyszukiwane i przetwarzane przy pomocy tych samych środków, co dane zapamiętane. Ten ideał zwykle można stosunkowo łatwo osiągnąć dla operacji wyszukiwania, lecz znacznie trudniej dla operacji aktualizacji; patrz: aktualizacja perspektyw. Innym nieco pojęciem jest zmaterializowana perspektywa, czyli dane wyliczone z danych oryginalnych i zapamiętane w bazie danych. Dla takich perspektyw podstawowym problemem jest sprawna aktualizacja zmaterializowanej perspektywy w odpowiedzi na aktualizację oryginalnych danych.

perspektywa bazy danych (database view) Patrz: perspektywa.

perspektywa obiektowa (object view, object-oriented view) Perspektywa zdefiniowana na obiektowej bazie danych, dostarczająca użytkownikowi obraz pojęciowy fragmentu bazy danych w postaci obiektów wirtualnych.

pesymistyczny model transakcji (pessimistic transaction model) Model transakcji zakładający, że prawdopodobieństwo niekorzystnych interferencji transakcji (utraty spójności danych lub przetwarzania wskutek jednoczesnego dostępu do tej samej danej) jest wysokie. W związku z tym każda dana przetwarzana przez transakcję musi mieć założony zamek (lock) uniemożliwiający dostęp do niej przez inne transakcje. Zamki te są zwalniane dopiero wtedy, gdy dana transakcja jest potwierdzona lub zerwana. Pesymistyczny model transakcji prowadzi do problemu zakleszczenia (deadlock).

Phantom Obiektowy, interpretowany język programowania do budowy aplikacji o dużej skali, interakcyjnych i rozproszonych, takich jak np. narzędzia do pracy grupowej. Rdzeń języka bazuje na podzbiorze Modula-3.

pielęgnacja (maintenance) Końcowa faza w cyklu życiowym oprogramowania, w której występują modyfikacje poprawiające (polegające na usuwaniu z oprogramowania błędów popełnionych w fazach wymagań, analizy, projektowania i implementacji), modyfikacje ulepszające (polegające na poprawie jakości oprogramowania), oraz modyfikacje dostosowujące (polegające na dostosowaniu oprogramowania do zmian zachodzących w środowisku jego pracy lub nowych wymagań użytkowników). Faza pielęgnacji oprogramowania jest jedną z najważniejszych i najbardziej kosztownych; niektóre oceny szacują koszty pielęgnacji na 90% ogólnych kosztów wytworzenia oprogramowania. Istnieje tendencja nie doceniania kosztów związanych z tą fazą.

pielęgnacja oprogramowania (software maintenance) Patrz: pielęgnacja.

pielęgnacyjność (maintainability) Ocena stopnia, w jakim dane oprogramowanie jest podatne na pielęgnację lub ocena potencjalnych kosztów pielęgnacji; patrz: pielęgnacja.

pierwsza postać normalna (first normal form, 1NF) Reprezentacja danych, zgodnie z którą wszystkie dane są zapisane w postaci tablic (relacji) o określonej liczbie kolumn i nieokreślonej liczbie wierszy. Elementy tablic muszą być wartościami atomowymi (bez struktury) i nie mogą być odsyłaczami (pointers) do wierszy tablic. W ramach tablicy wiersze nie mogą się powtarzać. Pierwsza forma normalna jest podstawowym

151


założeniem modelu relacyjnego baz danych i wszystkich systemów relacyjnych. Nie jest ona ortodoksyjnie przestrzegana; dotyczy to np. powtarzania wierszy tablic. Warunek pierwszej postaci normalnej nie jest przestrzegany w nowym standardzie SQL3.

pies (dog) Zwierzę posiadające uzdolnienia do rozpoznawania obiektów rzeczywistych (szczególnie kotów). Patrz też: pointer.

PixScript Obiektowe rozszerzenie języka Postscript; używany do zaawansowanego przetwarzania obrazów.

PJama Nowa wersja języka Java opracowana przez Sun Microsystems Laboratories (poprzednie nazwy Persistent Java i PJava). Podstawową cechą PJama jest możliwość deklarowania trwałych obiektów i ortogonalna trwałość. PJama włącza zmodyfikowaną maszynę wirtualną kompatybilną z JDK firmy JavaSoft oraz prosty model przetwarzania transakcji.

http://www.sunlabs.com/research/forest/opj.main.html

PJava Patrz: PJama.

platforma (platform) Konkretny typ sprzętu wraz z zainstalowanym na nim systemem operacyjnym. Np. Pentium Pro + MS Windows NT4, Sun + Solaris, itd.

plik (file) Ogólnie, nazwany zbiór danych zapamiętany na pewnym nośniku, np. dysku, o dużej lub bardzo dużej wielkości i możliwości rozszerzania (do pewnego stopnia). Zwykle intencją tego terminu jest stosunkowo mały stopień zorganizowania danych, np. plik jest ciągiem bitów, bajtów lub zapisów o sztywnym formacie. W porównaniu do baz danych, pliki charakteryzują się także niższym poziomem ochrony i bezpieczeństwa oraz bardziej prymitywnymi środkami dostępu.

płaski plik (flat file) Prosta organizacja danych, w której plik jest sekwencją zapisów nie posiadających wewnętrznej lub zewnętrznej struktury.

pniak (stub) W terminologii standardu OMG CORBA, wiązany statycznie interfejs znajdujący się po stronie klienta, generowany automatycznie z wyrażenia w języku opisu interfejsów IDL.

http://www.omg.org

pniak RPC (RPC stub) Część aplikacji klienta odpowiedzialna za przekazywanie zleceń odległego wołania procedury i odbieranie wyników.

pochodny (derived) Określenie bytu programistycznego (atrybutu, klasy, asocjacji, itp.), który jest lub może być wyliczony lub wydedukowany z innych bytów.

podejście stosowe (stack-based approach) Podejście teoretyczne i praktyczne do semantyki i konstrukcji obiektowych języków zapytań, które zakłada, że języki zapytań są szczególnym przypadkiem języków programowania. W tym podejściu kluczową rolę odgrywa stos środowisk (environment stack), który jest podstawowym mechanizmem

152


zakresu i wiązania większości popularnych języków programowania. Rolą tego stosu jest określenie zakresów nazw i sposobów ich wiązania oraz wprowadzenie dyscypliny w zakresie alokowania dynamicznych bytów programistycznych, w szczególności lokalnych zmiennych i parametrów procedur. W podejściu stosowym szczególną rolę odgrywają tzw. operatory niealgebraiczne (takie jak selekcja, projekcja/nawigacja, zależne złączenie, kwantyfikatory, itd.), których semantyka opiera się na otwieraniu nowego zakresu na stosie środowisk, na zasadzie podobnej do otwierania tego zakresu przez wywołania procedur. Oparcie semantyki języków zapytań na mechanizmie stosu środowisk umożliwia precyzyjne wyjaśnienie ich własności, ustalenie ich związków z pojęciami obiektowości (klasy, dziedziczenie, hermetyzacja, itd.), oraz ich związków z konstrukcjami imperatywnymi języków programowania. Podejście stosowe daje mocną formalną podstawę dla metod optymalizacji zapytań. Na bazie podejścia stosowego został zaprojektowany i zaimplementowany obiektowy język zapytań SBQL (Stack Based Query Language), stanowiący podstawę interfejsu programistycznego systemu Loqis.

podklasa (subclass) Klasa bardziej wyspecjalizowana, usytuowana niżej w hierarchii dziedziczenia; np. Student jest podklasą klasy Osoba. Pojęcie podklasy włącza aspekt zawierania się zakresów znaczeniowych pojęć; przykładowo, zbiór obiektów Student jest podzbiorem zbioru obiektów Osoba. Innym aspektem jest dziedziczenie inwariantów: podklasa posiada wszystkie inwarianty jej nadklasy (definicje atrybutów, definicje metod, itd.) oraz pewne nowe inwarianty; np. podklasa Student ma wszystkie cechy klasy Osoba, plus atrybuty takie jak NrIndeksu, RokStudiów, itd. W wielu sytuacjach te dwa dość różne aspekty pojęcia podklasy mogą prowadzić do nieporozumień.

podnieść wyjątek (raise exception) Spowodować, wygenerować wyjątek; spowodować obecność danego wyjątku w pewnym środowisku lub rejestrze wyjątków.

podobiekt (subobject) Obiekt będący częścią danego obiektu.

podobny do spaghetti (spaghetti-like) Patrz: spaghetti.

podschemat (subschema) Fragment schematu bazy danych odpowiadający pewnej specyficznej aplikacji lub grupie użytkowników. Zwykle pojęcie podschematu obejmuje nie tylko opis fragmentu danych, ale też sposób, w jaki dane opisywane przez schemat są odwzorowane w dane opisywane przez podschemat. Patrz też: perspektywa.

podstan (substate) W diagramach stanów (np. w UML) dowolny „stan” można rozwinąć na bardziej szczegółowy diagram, w którym występują powiązane składowe tego stanu, czyli „podstany”. Ta terminologia jest jednak nieco niewłaściwa i myląca, gdyż to, co nazywa się tam diagramem stanów, w istocie jest diagramem przepływu sterowania (flowchart). W tym sensie „podstan” jest bardziej szczegółową akcją w ramach akcji nadrzędnej („stanu”); patrz rysunek poniżej.

153


ZakupPrzygotowaniewniosku

Akceptacjakierownika

Akceptacjaprezesa

Akceptacjaksięgowości

Dokonaniezakupu

Informacjao odrzuceniu

Zakup

Rozwinięcie stanu Zakup na podstany:

Diagram zawierający dwa stany:

Przygotowaniewniosku

Przykład stanu i jego podstanów

podstawowy adapter obiektów (Basic Object Adapter, BOA) Patrz: BOA.

podtyp (subtype) Typ podrzędny w stosunku do danego typu. Istnieją dwa kryteria ustalania podtypów: (1) ekstensja (zbiór wszystkich wartości) podtypu zawarta jest w ekstensji typu (np. typ integer jest podtypem typu real); (2) podtyp ma co najmniej tyle samo lub więcej atrybutów (np. typ Student jest podtypem typy Osoba, jeżeli Student zawiera wszystkie definicje atrybutów zawarte w typie Osoba plus ewentualnie nowe atrybuty). Relacja typ/podtyp jest wprowadzana w związku z polimorfizmem inkluzyjnym (inclusion polymorphism) oraz zasadą zamienialności (substitutability).

podzbiór (subset) Część danego zbioru. Terminu tego używa się również dla oznaczenia języka lub systemu o zredukowanych, okrojonych funkcjach (np. „podzbiór języka SQL”).

podział (partition) Podział zakresu znaczeniowego (zbioru obiektów) klasy bardziej ogólnej na podzakresy znaczeniowe (podzbiory obiektów) jej podklas.

podział kompletny (complete partition) Sytuacja, w której suma zakresów znaczeniowych podklas jest taka sama, jak zakres znaczeniowy nadklasy. Np. dla klasy Osoba podklasy PłećŻeńska oraz PłećMęska wyznaczają podział kompletny.

podział niekompletny (incomplete partition) Sytuacja, w której suma zakresów znaczeniowych podklas jest mniejsza od zakresu znaczeniowego nadklasy. Np. podklasy Student i Pracownik stanowią niekompletny podział klasy Osoba, ponieważ można w niej wyróżnić obiekty nie będące ani studentem ani pracownikiem.

Poet Obiektowy system zarządzania bazą danych oferowany przez firmę Poet Software oparty o język C++. Poet jest uważany za zgodny ze standardem ODMG, chociaż jak dotąd zaimplementowy został tylko pewien podzbiór języka OQL.

http://www.poet.com

154


pointer (pointer) Wyżeł angielski o krótkiej połyskującej sierści; dobry węch. Mówiło się onegdaj w staropolszczyźnie: „azaliż Waćpan z pointerą polował, że tyle zajęców?”. Po zwietrzeniu zwierzyny pointer staje jak wryty i podniesioną, lekko zgiętą łapką wskazuje myśliwemu interesujący go obiekt. Jest niewłaściwe zachwaszczanie obiektowej mowy neofickim słowem wskaźnik, zamiast stosowania pięknego staropolskiego słowa pointer. Patrz (niestety): wskaźnik.

pojedyncza dyspozycja (single dispatching) Patrz: dyspozycja.

pojedyncze dziedziczenie (single inheritance) Sytuacja, w której każda klasa ma co najwyżej jedną nadklasę.

pojęciowy (conceptual) Odnoszący się do ludzkich wyobrażeń i sposobów myślenia; nie biorący pod uwagę kwestii implementacji komputerowej.

pojęciowy model danych (conceptual data model) Model danych odwołujący się do sposobu myślenia analityka, projektanta, konstruktora oprogramowania; model nie biorący pod uwagę kwestii komputerowej reprezentacji danych. Przykładami modelu pojęciowego są: model encja-związek, model OMT, model UML. Synonim: semantyczny model danych.

pole (field, slot) Fragment obiektu, zapisu, struktury przechowujący pojedynczą wartość. Synonimy: atrybut, wartość atrybutu, zmienna wystąpienia.

pole statyczne (static field) Pole, którego wartość jest wspólna dla pewnego zbioru obiektów, pole niezmienialne, zmienna klasowa, atrybut wspólny.

polimorfizm (polymorphism) Termin używany w dwóch nieco różnych znaczeniach (które są często mylone): (1) w terminologii obiektowej: możliwość istnienia wielu metod o tej samej nazwie, powiązana z możliwością wyboru konkretnej metody podczas czasu wykonania (dynamicznym wiązaniem); (2) w terminologii teorii typów i języków polimorficznych (np. w ML): umożliwienie definiowania funkcji lub procedur, których argumenty i wynik mogą posiadać jednocześnie wiele typów; np. funkcji sort, która może posortować (wg pewnego algorytmu) kolekcję elementów dowolnego typu (o ile określona zostanie metoda porównania elementów). Polimorfizm parametryczny jest często kojarzony z sytuacja określaną jako przypadek typu (typecase), czyli możliwością dynamicznego testowania typu danej wartości lub zmiennej. Powyższe dwa znaczenia pojęcia polimorfizmu są względem siebie ortogonalne: możliwy jest polimorfizm metod w języku nietypowanym (np. Smalltalk), oraz polimorfizm typów w języku nie wprowadzającym wiązania dynamicznego (np. ML).

polimorfizm ad hoc (ad hoc polymorphism) Przypadkowe formy polimorfizmu implementowane w językach programowania (np. przyjęcie zasady, że wszędzie tam, gdzie można użyć wartości typu real, można również użyć wartości typu integer).

polimorfizm inkluzyjny (inclusion polymorphism) Rodzaj polimorfizmu typów, w którym zakłada się istnienie relacji częściowego porządku „jest podtypem” pomiędzy

155


typami; np. typ Student jest podtypem typu Osoba. Polimorfizm inkluzyjny jest ściśle powiązany z zasadą zamienialności (substitutability), która ustala, że o ile w danym miejscu programu można użyć wartości typu A, to w tym samym miejscu można także użyć wartości typu B, o ile B jest podtypem A.

polimorfizm metod (method polymorphism) Możliwość definiowania wielu metod o tej samej nazwie, połączona z możliwością dynamicznego wyboru (wiązania) konkretnej metody podczas czasu wykonania. Polimorfizm metod jest często utożsamiany z przeciążaniem (overloading) i z przesłanianiem (overriding). Niektórzy autorzy (np. Cardelli) uważają, że przeciążanie nie jest polimorfizmem, lecz (specyficzną dla większości języków programowania) homonimią rozstrzygalną poprzez analizę kontekstu jej występowania w tekście programu.

polimorfizm parametryczny (parametric polymorphism) Rodzaj polimorfizmu typów, w którym zakłada się, że typ bytu programistycznego może być parametryzowany innym typem; np. typ tablica (array) jest parametryzowany wartością typu integer oznaczającą rozmiar tablicy. Często polimorfizm parametryczny kojarzy się z sytuacją, kiedy typ parametru pewnej funkcji określa typ jej wyniku.

polimorfizm statyczny (static polymorphism) Patrz: przeciążanie.

polimorfizm typów (type polymorphism) Możliwość deklarowania bytów programistycznych (zmiennych, argumentów, funkcji i innych), których konkretne wystąpienia lub wartości mogą być zgodne z wieloma typami lub różnić się typem. Polimorfizm typów jest uważany za podstawę zdyscyplinowanego i bezpiecznego programowania generycznego (generic). Temat ten pozostaje jednak w strefie akademickiej, ponieważ języki z polimorfizmem typów (w szczególności ML) są uważane za zbyt wyrafinowane dla przeciętnego programisty. Ponadto, polimorfizm typów posiada ograniczenia w stosunku do innych metod programowania generycznego, np. programowania z refleksją.

pomost (gateway) Oprogramowanie umożliwiające dostęp z danego systemu bazy danych do innych (lokalnych lub odległych) baz danych podtrzymywanych przez inny SZBD; np. dostęp do danych podtrzymywanych przez system relacyjny z systemu obiektowego. Pomost powinien zapewniać przezroczystość dostępu (tj. programista nie musi modyfikować programów z powodu dostępu do obcej bazy danych), ale często (najczęściej) ten warunek nie jest spełniony; np. dostęp z systemu obiektowego do systemu relacyjnego jest realizowany explicite poprzez ODBC lub JDBC.

ponowne użycie (reuse) Tworzenie, udostępnianie i wykorzystanie składników projektów, oprogramowania i dokumentacji, które nadają się do wielokrotnego zastosowania w tym samym projekcie lub oprogramowaniu lub w różnych projektach lub oprogramowaniu. Takie składniki nazywają się aktywami (assets) ponownego użycia. Aktywami ponownego użycia są najczęściej składowe oprogramowania, ale mogą być nimi także fragmenty analizy, projektu, dokumentacji technicznej, dokumentacji użytkowej, dokumentacji szkoleniowej, pliki graficzne, ekrany interfejsu użytkownika, formularze, metody testowania, składowe bazy danych, słowniki,

156


katalogi, schematy, itd. Ponowne użycie ma ogromne zalety, wśród nich następujące: Poprawność oprogramowania: przetestowane, już używane składowe

oprogramowania zawierają mniej błędów, niż skonstruowane na nowo. Czas tworzenia oprogramowania oraz koszt rozwoju i utrzymania oprogramowania

jest znacznie mniejszy. Komponenty ponownego użycia pozwalają na poprawienie łatwości użycia

oprogramowania. Jeżeli aktywa mają postać programów realizujących skomplikowane, efektywne

algorytmy, ponowne ich użycie zwiększy efektywność całego systemu. Jeżeli aktywa są przenaszalne pomiędzy poszczególnymi platformami, wówczas

wzrasta potencjał przenaszalności całego oprogramowania.

Temat ponownego użycia towarzyszył od dawna rozwojowi metod tworzenia oprogramowania, zaś pojęcia takie jak moduł, typ, procedura, makro można uważać za konsekwencję dążenia do wzmocnienia potencjału ponownego użycia. Obiektowość wzmacnia dodatkowo ten potencjał poprzez pojęcia takie jak: klasy, dziedziczenie, hermetyzacja i polimorfizm. Pojęcia te sprzyjają ponownemu użyciu, ale to nie oznacza, ze załatwiają problem w sposób automatyczny. Ponowne użycie nie może być traktowane jako efekt uboczny normalnego procesu tworzenia aplikacji. Wymaga ono konkretnych zabiegów oraz inwestycji zmierzających do wytworzenia w danej firmie lub przedsiębiorstwie kultury ponownego użycia, tj. stanu, w którym twórcy oprogramowania posiadają właściwe motywacje do tworzenia i wykorzystywania aktywów ponownego użycia. Przeszkodą dla zaistnienia kultury ponownego użycia jest brak nawyków i motywacji do starannego wyodrębniania, opisywania, katalogowania i rozpropagowania aktywów ponownego użycia, brak nawyków i motywacji dla ich wykorzystania, oraz zjawisko psychologiczne określane jako syndrom NIH (not-invented-here). Temat ponownego użycia jest ściśle związany z tematem wzorców projektowych.

http://www.asset.com/http://pebbles.cs.utk.edu/http://sw-eng.falls-church.va.us/ReuseIC/policy/glossary/glossary.htm

porównanie głębokie (deep comparison) Rekurencyjne porównanie zawartości obiektów, z uwzględnieniem nazw atrybutów i ich wartości. Przy porównaniu głębokim X = Y zmiennych X i Y wynik jest prawdziwy, jeżeli ich aktualne wartości są identyczne. Jeżeli X i Y są pewnymi wyrażeniami zwracającymi identyfikatory obiektów, zaś = jest operatorem porównania głębokiego, wówczas predykat X = Y zwraca wartość boolowską true, jeżeli zestaw atrybutów oraz wartości tak samo nazwanych atrybutów obiektów wskazywanych przez X i Y są takie same; w przeciwnym przypadku zwraca false. W przeciwieństwie do porównania płytkiego, identyfikatory zwracane przez X i Y mogą być różne; w porównaniu głębokim chodzi o identyczność zawartości informacyjnej obiektów. Jeżeli atrybuty obiektu są złożone, porównanie ma charakter rekurencyjny, z uwzględnieniem nazw podatrybutów. Porównanie głębokie może być trudne do jednoznacznego zdefiniowania, jeżeli obiekty zawierają wskaźniki do innych obiektów, gdyż powstaje problem, jak głęboko należy posuwać się w rekurencyjnym porównywaniu. Z tego powodu może być kilka różnych

157


operatorów porównania głębokiego. Języki programowania, np. Java, stosują porównanie głębokie dla typów prymitywnych, natomiast porównanie płytkie dla obiektów; może to tworzyć pewne semantyczne pułapki dla programistów. Patrz także: porównanie płytkie.

porównanie płytkie (shallow comparison) Porównanie identyfikatorów obiektów (referencji) poprzez operator równości. Jeżeli X i Y są pewnymi wyrażeniami zwracającymi identyfikatory obiektów (referencje), zaś = jest operatorem porównania płytkiego, wówczas predykat X = Y zwraca wartość boolowską true, jeżeli identyfikatory zwracane przez X i Y są identyczne (tj. wskazują na ten sam obiekt); w przeciwnym przypadku predykat zwraca false.

postać normalna Boyce-Codda (Boyce-Codd Normal Form, BCNF) Relacja jest w BCNF, jeżeli każdy jej determinant (atrybut lub zestaw atrybutów będący argumentem funkcji w zależności funkcyjnej) jest kluczem kandydującym. BCNF jest mocniejszym warunkiem od 3NF. Mogą istnieć relacje, których nie uda się zdekomponować do postaci BCNF. BCNF jest mało praktycznym produktem teorii normalizacji baz danych. Znaczenie tej postaci normalnej dla rzeczywistego projektowania baz danych jest marginalne.

Postgres System zarządzania bazą danych opracowany na uniwersytecie w Berkeley oparty na modelu określanym jako „rozszerzony relacyjny”. Postgres wprowadza niektóre cechy obiektowości, większy jednak nacisk jest położony na rozszerzenie struktur danych o elementy aktywne, takie jak procedury, perspektywy i reguły.

http://www.postgresql.org/index.html

postrelacyjny (post-relational) Określenie systemu, który rozszerza założenia modelu relacyjnego; patrz też: obiektowo-relacyjny.

pośredni przodek (indirect ancestor) W hierarchii klas nadklasa w stosunku do danej klasy, która jest oddzielona od niej inną klasą.

pośrednik (broker) Termin OMG CORBA, inaczej ORB. Patrz: ORB.http://www.omg.org

pośrednik zleceń obiektowych (Object Request Broker, ORB) Patrz: ORB.

potwierdzenie (commit) W przetwarzaniu transakcji jej faza końcowa, w której następuje fizyczne naniesienie zmian spowodowanych przez transakcję do bazy danych, odblokowanie wszelkich zablokowanych przez transakcję zasobów, skasowanie informacji z dziennika (log) transakcji, oraz usunięcie identyfikatora transakcji z rejestru aktualnie przetwarzanych transakcji.

potwierdzenie transakcji (transaction commit) Patrz: potwierdzenie.

PowerBroker Pośrednik wymiany obiektów (ORB) wg standardu OMG CORBA, rozwijany i rozpowszechniany przez firmę Expertsoft.

158


http://www.expertsoft.com

powiązanie (link) Wskaźnik umieszczony w jednym obiekcie i prowadzący do innego obiektu; patrz przykład poniżej. W metodykach projektowania uważa się, że pojęcie powiązania jest na wyższym poziomie abstrakcji niż pojęcie wskaźnika; jest to pewna abstrakcyjna „nitka” (niekiedy posiadająca więcej niż dwa końce) łącząca obiekty. Końce takich nitek są oznaczone nazwami ról. Powiązanie jest wystąpieniem związku lub asocjacji. Patrz też: asocjacja.

FIRMA

NrFirmy 102030

Nazwa Syntex

PrezesZatrudnia

Zatrudnia

Zatrudnia

PRACOWNIKNazwisko NowakZarobek 1500PracujeW

PRACOWNIKNazwisko BabelZarobek 2000PracujeW

PRACOWNIKNazwisko KowalZarobek 2500PracujeW

Powiązania pomiędzy obiektami

powiązanie dwukierunkowe (bidirectional link) Powiązanie umożliwiające przechodzenie (nawigację) od jednego obiektu do drugiego obiektu, i odwrotnie.

powiązanie jednokierunkowe (unidirectional link) Powiązanie umożliwiające przechodzenie (nawigację) od jednego obiektu do drugiego obiektu, ale nie odwrotnie.

powiązanie pochodne (derived link) Powiązanie, które jest (lub może być) wyprowadzone z innych powiązań i/lub atrybutów.

powiązanie wskaźnikowe (pointer link) Nazwany wskaźnik (pointer) umieszczony w danym obiekcie i prowadzący do innego obiektu

powszechny model obiektowy (COM, Common Object Model) Patrz: COM.

półkrata (semi-lattice) Pojęcie matematyczne; krata, w której istnieje dokładnie jeden kres górny, ale może nie istnieć pojedynczy kres dolny. Półkrata jest teoretycznym stereotypem struktury klas z wielodziedziczeniem; ta analogia jest jednak dość płytka i jałowa.

półstrukturalne (semi-structured) Patrz: dane półstrukturalne.

późne wiązanie (late binding) Patrz: wiązanie dynamiczne.

pragma (pragma) Komentarz o ustalonym formacie, który jest rozpoznawany przez

159


kompilator i może być użyty dla specjalnych celów, np. do optymalizacji programu. Również umożliwienie w języku wysokiego poziomu bezpośredniej kontroli programu lub danych na niskim poziomie (pragma fizyczna).

prawo Demetera (Law of Demeter) Zasada lub zalecenie mające na celu minimalizację ilości komunikatów i zwiększenia kohezji wewnątrz klas. Mówi ono, że dany obiekt może wysłać komunikat wyłącznie do takiego obiektu, którego referencja znajduje się wewnątrz tego obiektu; inaczej, obiekt może wysłać komunikat do obiektu, z którym jest połączony pewnym powiązaniem (link).

predykat (predicate) Określenie warunku (wyrażenia boolowskiego) występującego np. po słowie kluczowym where w językach zapytań takich jak SQL i OQL. Istotą predykatu jest selekcja elementów należących do pewnej kolekcji.

prekompilator (precompiler) Program (z reguły dość prosty) dokonujący wstępnej obróbki tekstów programów, np. rozwinięć użytych makro, zamiany zdań języka zapytań na wołania procedur, zamiany stałych symbolicznych na konkretne wartości, itp. Patrz też: zanurzony.

PRESTO Środowisko bazujące na C++ dla pisania obiektowych równoległych programów w C++.

http://www.netlib.org/presto/index.html

procedura (procedure) Nazwana operacja lub nazwany kod, która nie zwraca wartości. W odróżnieniu od niej, funkcja zwraca pewną wartość (ale używa się także terminu procedura funkcyjna (functional procedure)).

procedura bazy danych (database procedure) Patrz: zapamiętana procedura.

procedura funkcyjna (functional procedure) Procedura zwracająca wartość, dzięki czemu jej wywołanie może być użyte jako wyrażenie.

proceduralny (procedural) Określenie języka lub paradygmatu programowania opierającego się o sekwencje instrukcji, które kolejno są wykonywane przez komputer powodując zmianę stanu programu oraz efekty zewnętrzne.

proces (process) Wykonywany program lub sekwencja czynności. Intencją tego pojęcia jest autonomiczne sterowanie ustalające przebieg procesu, oraz fakt, że wykonuje się on równolegle z innymi procesami. W terminologii systemów operacyjnych i niektórych języków programowania (np. Ada), proces jest bytem programistycznym, dla którego przeznacza się określone zasoby (czas komputera, pamięć, dane), który funkcjonuje niezależnie od innych równolegle działających procesów, i który podlega synchronizacji, tj. przydzielaniu lub podziałowi zasobów krytycznych (wspólnych dla wielu procesów), takich jak pamięć, klawiatura, ekran, porty, itd.

proces iteracyjny (iterative process) Proces zakładający powtórzenia pewnych

160


czynności.

program aplikacyjny (application program) Program należący do pewnej aplikacji, mający bezpośrednich użytkowników w określonej dziedzinie przedmiotowej.

programowanie dynamiczne (dynamic programming) Programowanie z użyciem dynamicznego SQL; programowanie z użyciem techniki refleksji.

programowanie generyczne (generic programming) Technika tworzenia programów operujących nie na konkretnej strukturze danych, ale na szerokiej rodzinie takich struktur. Przykładami programów generycznych są: program sortujący dowolną listę, program tłumaczący dowolny program w języku Pascal na program w C, program przeglądania tablic w bazie danych, w którym nazwa tablicy jest parametrem wczytywanym z klawiatury, itp. Programowanie generyczne sprzyja ponownemu użyciu (reuse). Wiele języków programowania (np. Pascal) nie jest przystosowanych do tego typu programowania. Znanych jest kilka technik programowania generycznego, np.: przejście na niższy poziom językowy (np. assemblera) poprzez operatory konwersji typu, polimorfizm powiązany z procedurami wyższego rzędu (procedurami z parametrami będącymi procedurami), klasy parametryzowane (szablony) oraz wykorzystanie refleksji (reflection) (np. w dynamicznym SQL).

programowanie obiektowe (object-oriented programming) Programowanie, zwykle w obiektowym języku programowania, w którym występuje wyodrębnienie obiektów (jako bytów programistycznych), ich klas oraz metod. Istnieje bardzo wiele języków służących do programowania obiektowego, m.in. SIMULA-67, Smalltalk, C++, Object Pascal, Objective C, DRAGOON, BETA, Emerald, POOL, Eiffel, Self, Oblog, ESP, POLKA, Loops, Java.

http://zgdv.igd.fhg.de/papers/se/oop/http://cuiwww.unige.ch/Chloe/Ooinfohttp://iamwww.unibe.ch/~scg/Ooinfo/FAQ/

programowanie obiektowe wyższego rzędu (higher-order object-oriented programming) Programowanie obiektowe z użyciem typów polimorficznych i funkcji wyższego rzędu; programowanie obiektowe z użyciem techniki refleksji.

programowanie sterowane zdarzeniami (event-driven programming) Patrz: sterowane zdarzeniami.

programowanie wizyjne (visual programming) Technika i narzędzia programistyczne zapewniające komponowanie interfejsu użytkownika i oprogramowania użytkowego z graficznych elementów widocznych na ekranie komputera (przeważnie metodą „przesuń i upuść”, drag and drop). Przykładami narzędzi programowania wizyjnego są: środowisko języka Smalltalk, VisualBasic, IBM VisualAge i CA OpenRoad.

programowanie wyższego rzędu (higher-order programming) Programowanie z użyciem typów polimorficznych i funkcji wyższego rzędu; programowanie z użyciem

161


techniki refleksji.

programowanie zdarzeniowe (event-driven programming) Patrz: sterowane zdarzeniami.

projekcja (projection) Operator algebry relacji lub języka zapytań implementowany w relacyjnych językach zapytań. Operator ten pozwala wyprodukować z zadanej tablicy nową tablicę o zmniejszonej liczbie kolumn. W języku SQL parametry operacji projekcji następują bezpośrednio po słowie kluczowym „select”. Określenie „projekcja” jest także stosowane w bardziej ogólnym sensie (m.in. w obiektowych językach zapytań), jako operacja selekcji atrybutu (atrybutów) z pewnych obiektów lub operacja polegająca na obliczaniu pewnego wyrażenia, którego argumentami są nazwy atrybutów obiektów.

projektowanie (design) Przedmiot lub dziedzina dowolnej inżynierii (w tym inżynierii oprogramowania) zajmująca się wyspecyfikowaniem pewnego wytworu. Jakościowy projekt powinien spełniać cele i kryteria funkcjonalne danego wytworu, jak również uwzględniać wszelkie ograniczenia na wytwór (maksymalny koszt, wydajność, niezawodność, ergonomia, sprzęt, zasoby, czas reakcji, obowiązujące standardy, itd.). Metody projektowanie powinny także uwzględniać własne ograniczenia procesu projektowego, np. maksymalny koszt i czas projektowania, stosowane narzędzia, dostępna kadra, itd.

projektowanie logiczne (logical design) Tworzenie schematu danych (zawartych w bazie danych) zgodnie z regułami syntaktycznymi i semantycznymi konkretnego systemu zarządzania bazą danych (lub pewnej klasy systemów); np. projektowanie schematów relacyjnych w SQL lub schematów obiektowych w ODL. Podstawą projektu logicznego jest projekt pojęciowy zapisany np. w postaci diagramów encja-związek lub pojęciowych diagramów klas obiektów.

projektowanie obiektowe (object-oriented design, OOD) Patrz: obiektowe projektowanie.

projektowanie przez kontrakty (design by contracts) Metoda zaproponowana przez Bertranda Meyera (twórcę języka Eiffel), która traktuje konstruowanie oprogramowania jako proces oparty na kontraktach pomiędzy klientem (np. wołaniem procedury) i dostawcą (np. procedurą). Metoda zakłada określenie wzajemnych zobowiązań pomiędzy klientem i dostawcą. Opiera się na definiowaniu pewnych warunków (asercji), w szczególności inwariantów (invariants), warunków wstępnych (preconditions) i warunków końcowych (postconditions). Patrz też: BON.

http://www.eiffel.com/doc/manuals/technology/contract/index.html

projektowanie wspomagane komputerem (Computer Aided Design, CAD) Dziedzina niestandardowych zastosowań komputerów; potencjalne pole zastosowań obiektowych baz danych.

protokół (protocol) Ogólnie, sposób lub algorytm przekazywania lub przesyłania

162


danych. W obiektowości termin ten oznacza niekiedy sposób, w jaki obiekt reaguje na przesyłane do niego komunikaty.

prototyp [1] (prototype) Obiekt, którego własności (np. atrybuty wraz z wartościami lub metody) są importowane (dziedziczone) przez inne obiekty. Prototyp posiada własności klasy, ale odnosi się bardziej do poziomu realizacyjnego niż pojęciowego. Przykładem języka opartego o koncepcję prototypów jest Self. Poniżej znajduje się przykład prototypu ULUBIENIEC, z którego dziedziczą obiekty PIES i KOT. Prototyp może być także używany do tworzenia nowych obiektów na zasadzie klonowania. Prototyp koncepcyjnie jest równoważny pojęciu klasy, ale umożliwia dziedziczenie dynamiczne, w ramach wystąpień obiektu, przez co struktura obiektowa jest bardziej elastyczna. W szczególności, bez trudu można odłączać obiekty od ich prototypu i przyłączać do innego prototypu.

Łapy 4 Ogon 1

Uszy 2 Oczy 2

ULUBIENIEC

Szczepienie()

Wabi_się Mrusia

Rasa nieznana

KOT

Płeć Ż Uszy 1

Wabi_się Rex

Rasa jamnik

Płeć M

PIES

Udostępnienie informacji z prototypu ULUBIENIEC

prototyp [2] (prototype) Wstępna, próbna, uproszczona, ale działająca wersja projektowanego systemu informatycznego.

prywatny (private) Określenie własności obiektu, która jest hermetyzowana, ukryta, niewidoczna z zewnątrz. Własność prywatna jest dostępna wyłącznie dla metod przypisanych do tego obiektu (w C++ również dla klas zaprzyjaźnionych).

przechwycenie wyjątku (catch an exception, exception catch) Rozpoznanie wyjątku, uruchomienie czynności obsługi wyjątku (bloku reakcji na wyjątek) oraz „skonsumowanie” tego wyjątku (usunięcie go ze środowiska).

przeciążanie (overloading) Sytuacja, w której ta sama nazwa (lub symbol) jest użyta do oznaczenia dwóch lub więcej funkcji (procedur, operatorów lub metod), zaś rozstrzygnięcie tej homonimii następuje na podstawie kontekstu jej użycia (np. typu lub liczby argumentów operacji).

163


przedmiot rozważań (universe of discourse, UoD) Patrz: dziedzina problemu.

przeglądanie (browsing) Przeglądanie struktury klas, atrybutów, obiektów, powiązań, itd., zwykle przy pomocy specjalnego oprogramowania zwanego przeglądarką. (Termin homonimiczny z przeglądaniem stron WWW.)

przeglądarka (browser) Oprogramowanie umożliwiające przeglądanie struktury klas, atrybutów, obiektów, powiązań, itd. (Termin homonimiczny z przeglądarkami stron WWW.)

przejście (transition) Inaczej zmiana stanu powodowana przez pewien sygnał lub zdarzenie.

przekazywanie parametrów (parameter passing) Przekazywanie wartości lub wyrażeń użytych w wołaniu procedury (funkcji, metody) do środowiska wykonania procedury (funkcji, metody). Istnieje kilka technik przekazywania parametrów; największą popularność zdobyło tzw. wołanie przez wartość (call-by-value), gdzie przekazywana jest wartość, oraz tzw. wołanie przez referencję (call-by-reference), gdzie przekazywana jest referencja do zmiennej lub obiektu. Pewną popularność (w kontekście optymalizacji) zdobyły także techniki określane jako wołanie przez nazwę (call-by-name), w istocie oparte na koncepcji makro-definicji, oraz wołanie poprzez potrzebę (call-by-need) (zwaną też inaczej „leniwym wartościowaniem”, lazy evaluation).

przemiana wskaźników (pointer swizzling) Technika implementacji obiektowych baz danych polegająca na tym, że w buforze obiektów (w pamięci operacyjnej) następuje zamiana trwałych wskaźników (identyfikatorów obiektów) prowadzących do obiektów przechowywanych w bazie danych na wskaźniki danego języka programowania (np. C++), prowadzące do kopii tych obiektów w pamięci operacyjnej. Technika ta, w porównaniu do relacyjnych baz danych, pozwala na podwyższenie wydajności niektórych aplikacji nawet tysiąckrotnie.

przenaszalność (portability) Własność języka programowania umożliwiająca przenoszenie programów napisanych w tym języku na różne platformy sprzętowe, pracujące pod różnymi systemami operacyjnymi. Przenaszalność wymaga bardzo precyzyjnego wyspecyfikowania składni i semantyki języka, oraz wyeliminowania z niego wszelkich własności specyficznych dla poszczególnych platform. Przenaszalność jest podstawowym celem standardyzacji, ale wiele standardów nie spełnia tego kryterium z powodu niedospecyfikowania wszystkich własności (szczególnie semantyki), lub niekompletności pragmatycznej języka powodującej dowolne, niestandardowe rozszerzenia. Przykładem może służyć SQL-92, gdzie ponad 90% programów „zgodnych” z tym standardem nie daje się przenieść na inne platformy. Przenaszalność jest celem standardu C++, ale - zdaniem komitetu ANSI powołanego do stworzenia tego standardu - jest to cel, który będzie bardzo trudny do osiągnięcia z powodu bagażu niskiego poziomu odziedziczonego z C. Przenaszalność jest także celem standardów OMG CORBA oraz ODMG, ale sytuacja jest tu podobna do sytuacji z C++: są to jak dotąd pobożne życzenie, a nie realnie osiągnięta własność. Bardzo

164


dobrze przenaszalność realizuje język Java, który nie jest kompilowany do poziomu sprzętowego, a do poziomu pewnego interpretera (zwanego maszyną wirtualną), co daje możliwość uniezależnienia się od konkretnej platformy realizacyjnej. Należy jednak zdawać sobie sprawę, że dotyczy to bardzo ograniczonych funkcjonalności (programowania stron WWW), gdzie skala problemu jest znacznie mniejsza.

przepisywanie (rewriting) Określenie grupy metod optymalizacji zapytań (ogólnie: programów), w których dokonuje się semantycznie równoważnego przekształcenia tekstu zapytania (lub pewnej jego wewnętrznej reprezentacji, np. drzewa syntaktycznego) na taką równoważną semantycznie postać, która rokuje lepszy czas wykonania. Do metod opartych na przepisywaniu należą popularne metody optymalizacji relacyjnych języków zapytań (w tym SQL) polegające na: przesuwaniu selekcji i projekcji przed złączenie, wyciąganiu (factoring out) pewnych podzapytań przed pętlę iteracyjną (np. przed operator where), zamianie zagnieżdżonych zapytań na nie zagnieżdżone, usuwaniu martwych członów zapytań, optymalizacji zapytań odwołujących się do perspektyw techniką określaną jako modyfikacja zapytań (query modification), itd.

przepływ danych (data flow) Patrz: diagram przepływu danych.

przepływ pracy (workflow) Sterowanie i ulepszanie procesów przedsiębiorczości, ich automatyzacja, śledzenie, oraz umożliwienie lub usprawnienie współpracy zespołów. Przepływ pracy obejmuje także organizację operacyjnych aspektów przedsiębiorczości - sekwencję zadań, organizację podmiotów je wykonujących, sterowanie przepływem informacji wspomagającej realizację tych zadań, oraz mechanizmy śledzenia i raportowania, które mierzą i kontrolują wykonanie zadań. Oprogramowanie przepływu pracy ma za zadanie usprawnić procesy przedsiębiorczości poprzez automatyzację następujących aspektów: przekazywanie czynności do wykonania w ramach danego procesu, zgodnie z

określoną ich sekwencją; zapewnienie dostępu do danych i dokumentów wymaganych przez te czynności; śledzenie wszystkich aspektów związanych z wykonaniem procesu.

Głównym celem narzędzi do zarządzania przepływem pracy jest umożliwienie wyodrębnienia i ewentualnej dynamicznej modyfikacji logiki procesów biznesowych wykonywanych w przedsiębiorstwie. Ta logika jest oddzielona od logiki zadań wykonywanych w ramach aplikacji użytkowych, takich jak obsługa interfejsu użytkownika i dostęp do bazy danych. Przepływy pracy są przedmiotem działań standardyzacyjnych w ramach konsorcjum Workflow Management Coalition.

http://www.aiim.org/wfmc/ http://www.insead.fr/CALT/Encyclopedia/ComputerSciences/Groupware/Workflowhttp://www.gold.net/users/ef48/index.html

przepływ sterowania (control flow) Przesuwanie się umownego, wyobrażalnego punktu (zwanego sterowaniem) wzdłuż kodu programu podczas jego analizy lub wykonania. Przesunięcie się tego punktu do danej instrukcji kodu oznacza uruchomienie wykonania tej instrukcji. W językach niskiego poziomu tym punktem jest stan licznika

165


(rejestru) rozkazów. W językach wysokiego poziomu sterowanie przepływa (w wyobraźni programisty) wzdłuż instrukcji wysokiego poziomu, wywoływanych metod, procedur, itd. Niekiedy (w programach współbieżnych, wielowątkowych lub w językach zapytań) sterowanie może „rozszczepić się” na dwa lub więcej równolegle poruszających się punktów. Terminu „przepływ sterowania” używa się w kontekście diagramów przepływu sterowania (flowcharts) i diagramów stanów (statecharts).

przesłanianie (overriding) Odnosi się do sytuacji, kiedy implementacje funkcji (procedur, operatorów, metod) posiadających tę samą nazwę występują na różnych poziomach hierarchii dziedziczenia (co najmniej dwóch). W tej sytuacji do obiektu stosuje się funkcję znajdującą się najniżej w części hierarchii od korzenia do klasy tego obiektu; pozostałe funkcje o tej samej nazwie (z klas bardziej ogólnych, nadklas) są „przesłonięte” przez tę funkcję. Przesłanianie jest realizacją strategii określanej jako „pojedyncza dyspozycja” (single dispatching) i jest ściśle powiązane z polimorfizmem. Przesłanianie wymaga dynamicznego wiązania i jest jednym z ważnych elementów wspomagających ponowne użycie (reuse).

przestrzeń stanów (state space) Zbiór (zwykle bardzo duży lub nieskończony) wszystkich stanów, w których może znaleźć się obiekt, program, proces, baza danych, itd.

przesunięcie (offset) Przy fizycznej reprezentacji obiektu (lub zapisu) przesunięciem jest liczba bajtów od początku obiektu do miejsca zapamiętania danego atrybutu.

przesyłanie komunikatów (message passing) Technika programowania, w której najpierw wyznacza się obiekt będący przedmiotem przetwarzania, następnie formułuje się wyrażenie („komunikat”) określające operację, która ma być wykonana na obiekcie (operacja może być parametryzowana). Składnia odpowiedniej konstrukcji językowej ma często postać <obiekt>.<funkcja>(<parametry>). Z dokładnością do terminologii, przesyłanie komunikatów jest wywołaniem lokalnej funkcji (procedury, operacji, metody), gdzie obiekt, będący adresatem komunikatu, pełni rolę środowiska wykonania tej funkcji. Przesyłanie komunikatów nie ma nic wspólnego z asynchronicznym (równoległym) komunikowaniem się obiektów. (Nb. jest to bardzo ważny, ale w stosunku do przesyłania komunikatów całkowicie ortogonalny problem.) Niestety, ten nieco niefortunny termin doprowadził do wielu tego rodzaju nieporozumień.

przetwarzanie analityczne on-line (On-Line Analytical Processing, OLAP) Patrz: OLAP.

przetwarzanie transakcji on-line (On-Line Transaction Processing, OLTP) Patrz: OLTP.

przezroczystość (transparency) Termin wprowadzony głównie w związku z systemami rozproszonymi. Oznacza on, że programista lub użytkownik podczas dostępu do odległych danych nie musi interesować się różnorodnością środków dostępu, szczegółami transmisji danych, fizyczną implementacją obiektów, konfiguracją sieci, itd. Z jego punktu widzenia, przetwarzanie odległych heterogenicznych danych nie

166


powinno niczym różnić się od przetwarzania lokalnych danych znajdujących się w jego przestrzeni adresowej. Przezroczystość jest podstawową cechą standardu OMG CORBA. Istnieje wiele rodzajów przezroczystości: przezroczystość dostępu, czyli umożliwienie jednorodnych metod operowania na

lokalnych i odległych danych; przezroczystość położenia, czyli uwolnienie użytkowników od konieczności

(również uniemożliwienie) korzystania z informacji, gdzie aktualnie znajdują się dane;

przezroczystość współbieżności, czyli umożliwienie wielu użytkownikom jednoczesnego dostępu do danych bez konieczności uzgodnień i porozumiewania się, przy zapewnieniu podtrzymania pełnej spójności danych i przetwarzania;

przezroczystość skalowalności, czyli umożliwienie dowolnego dodawania lub usuwania elementów bazy danych bez wpływu na pracę użytkowników;

przezroczystość replikacji, czyli umożliwienie tworzenia i usuwania kopii danych w innych miejscach geograficznych z bezpośrednim skutkiem dla efektywności przetwarzania, ale bez jakichkolwiek skutków dla postaci programów użytkowych lub pracy użytkownika końcowego;

przezroczystość wydajności, czyli umożliwienie dodania nowych elementów systemu komputerowego (np. serwerów, dysków) bez wpływu na pracę większości użytkowników rozproszonej bazy danych;

przezroczystość awarii, czyli umożliwienie nieprzerwanej pracy dla większości użytkowników rozproszonej bazy danych w sytuacji, gdy niektóre z jej węzłów lub linie komunikacyjne uległy awarii;

przezroczystość migracji, czyli umożliwienie przenoszenia zasobów danych do innych miejsc bez wpływu na pracę użytkowników.

Prawdopodobnie nie istnieją systemy spełniające wszystkie wymienione wyżej kryteria przezroczystości.

przezroczystość rozproszenia (distribution transparency) Patrz: przezroczystość.

przodek (ancestor) Klasa stojąca wyżej w hierarchii klas (nadklasa) w stosunku do danej klasy.

przodek pośredni (indirect ancestor) Patrz: pośredni przodek.

przyjazność (friendliness, user friendliness) Łatwość, z jaką język lub system może być rozpoznany i użyty przez jego użytkownika.

przypadek typu (typecase) Terminem tym określa się własność języka programowania polegającą na możliwości dynamicznego sprawdzania typu pewnego bytu programistycznego (np. wartości) i uzależnienia sterowania programu od wyniku takiego sprawdzenia. Taka własność jest często niezbędna dla języków wprowadzających pewne formy polimorfizmu.

przypadek użycia (use case) W terminologii Jacobsona i UML przypadkiem użycia

167


jest pewna nazwana lub dobrze określona interakcja pomiędzy użytkownikiem a systemem komputerowym. Przypadek użycia odwzorowuje pewną funkcję systemu w taki sposób, w jaki będą ją widzieć jego przyszli użytkownicy. Podejście do analizy od strony przypadków użycia ma ogromny sens, gdyż pozwala zapomnieć o strukturze i architekturze systemu oraz jego detalach technicznych i skoncentrować się na zewnętrznych funkcjach systemu. Podejście do projektowania od strony przypadków użycia jest uważane za znacznie bardziej zdrowe od podejść „technokratycznych”, ponieważ sprzyja ono punktowi widzenia, w którym centralnym ośrodkiem zainteresowania staje się człowiek - przyszły użytkownik systemu - a nie budowa mechanizmu systemu. Model przypadków użycia pozwala wnioskować o systemie na odpowiednio ogólnym, abstrakcyjnym poziomie. Celem metody opartej na przypadkach użycia jest określenie wymagań na projektowany system, czyli: Głębsze zrozumienie użycia systemu będącego przedmiotem procesu

projektowania. Zwiększenie stopnia świadomości analityków i projektantów co do celów tego

systemu. Umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami

systemu. Weryfikacja poprawności i kompletności projektu. Ustalenie wszystkich strukturalnych i funkcjonalnych własności systemu. Ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu. Dostarczenie podstawy do sporządzenia planu testów systemu.

Istnieją opinie, że przypadki użycia mają niewiele wspólnego z obiektowością i były stosowane wcześniej niż obiektowość stała się paradygmatem analizy i projektowania systemów. Niektóre opinie (np. B. Meyera) głoszą również, że przypadki użycia swoją popularność zawdzięczają trywialności, prostocie, łatwości interakcji z użytkownikiem, ale te cechy mogą stać się niekorzystne w przypadku dużego, odpowiedzialnego projektu i mało doświadczonego zespołu projektowego. Patrz też: diagram przypadków użycia.


przypisany (proprietary) Określenie języka, biblioteki, aplikacji, itp., która jest przystosowana do oprogramowania jednego producenta (np. Microsoftu) i nie jest używana (nie jest kompatybilna) na innych platformach sprzętowo-programowych lub w innym środowisku programistycznym. Np. standard ActiveX jest przypisany do środowisk Windows95 i Windows NT, natomiast standard CORBA nie jest przypisany do jakiejkolwiek konkretnej platformy.

przyrostowy (incremental) Charakterystyka pewnego procesu lub algorytmu, który zmienia (lub dodaje) mały fragment (do) większej całości. Np. przyrostowe projektowanie oznacza projektowanie poprzez małe kroki, elementy lub modyfikacje dodane do już istniejącej całości; przyrostowa aktualizacja zmaterializowanej perspektywy oznacza, że po każdej zmianie bazy danych zmaterializowana perspektywa nie jest usuwana i liczona od początku, lecz modyfikuje się jej małą, lokalną część.

168


pseudoteoretyk (pseudo-theoretician) Osoba rozwijająca lub propagująca pseudoteorie. Patrz: pseudoteoria.

pseudoteoria (pseudo-theory) Próba dokonania wynalazku w dziedzinie informatyki przy użyciu metod matematycznych, wykonana przez osoby posiadające kompetencje matematyczne, ale nie posiadające wiedzy i doświadczeń praktycznych. Pseudoteoria nie jest weryfikowalna praktycznie z powodu utopijności założeń lub uwzględnienia jednego aspektu przy całkowitym zaniedbaniu innych, ważniejszych aspektów. Częstą wadą pseudoteorii jest ignorowanie skali problemu, tworzenie teorii dla mini-przykładów, i następnie sugerowanie, że teoria będzie działać w rzeczywistej skali. Kuriozalnych przykładów dostarcza tu np. VDM. Czynnikiem dyskwalifikującym intelektualną i techniczną wartość pseudoteorii jest ignorowanie mentalnych i psychologicznych uwarunkowań uczestników i odbiorców projektów oprogramowania.

Przykładami pseudoteorii są: matematyczne teorie specyfikacji i weryfikacji oprogramowania, teoria normalizacji relacyjnych baz danych, teorie niekompletnej informacji. Istnieje wiele pseudoteorii rozwijanych w związku z obiektowością; m.in. typowany rachunek lambda, rachunek monoidów, koncepcje „dedukcyjno-obiektowe”, obiektowe algebry. Stosunek pseudoteoretyków do obiektowości jest dwojaki: albo próbują oni walczyć z obiektowością używając do tego celu demagogicznej retoryki („brak podstaw matematycznych”), albo też próbują wnieść wkład w obiektowość poprzez stworzenie dla niej nowej pseudoteorii. Oba przypadki są groźne dla obiektowości, gdyż albo próbuje się odciąć dopływ środków (materialnych lub kadrowych) niezbędnych do rozwoju, albo próbuje się spożytkować te środki dla wspomożenia karier pseudoteoretyków, skierowując przy tym naukę, rozwój i dydaktykę na fałszywe tory.

Pseudoteoria - wbrew popularnym stereotypom - nie jest teorią, ponieważ nie służy do opisu i wnioskowania o istniejącej rzeczywistości. Jest ona raczej zmatematyzowanym zapisem pewnej rzeczywistości wyimaginowanej, urojonej. Twierdzenia osób rozwijających pseudoteorie, że tworzą oni wartości intelektualne, które będą konsumowane przez przyszłe pokolenia są niewiarygodne. Wystarczy przejrzeć teorie rozwijane 30 lat temu (organizacja arytmometru komputera, wyszukiwanie na bębnie magnetycznym, itd.), aby uzmysłowić sobie, że dowolne teorie są odbiciem problemów aktualnych w danym czasie i umierają, kiedy te problemy tracą aktualność. Ponadto pseudoteorie są tworzone przez osoby pozbawione kompetencji w zakresie rzeczywistych problemów. Przypomina to sytuację, kiedy teoria gry na skrzypcach jest tworzona przez osobę, która nigdy nie trzymała instrumentu w ręku i nigdy nie była w sali koncertowej.

Pseudoteorie są poważnym hamulcem postępu, gdyż są powodem straty ogromnego potencjału intelektualnego i materialnego, bez zysków w postaci nowej efektywnej wiedzy. Dość często pseudoteoria ubiera się w piórka super-naukowości, tworzy wielki, samopodtrzymujący się świat naukowych pozorów (wyposażony w niezbędne atrybuty: konferencje, seminaria, sympozja, komitety naukowe, specjalne czasopisma, itd.). Pseudoteorie żerują na odwiecznej ludzkiej skłonności do złudzeń i respektu przed środkami magicznymi, tajemniczymi, hermetycznymi. Z tego punktu widzenia pseudoteorie opierają się o bazę psychologiczną, która jest specyficzna dla pseudonauk, takich jak astrologia, parapsychologia, bioenergoterapeutyka, itd. Różnice dotyczą

169


formy lub środka wyrazu (hermetyczna matematyka w zastępstwie pseudo-naukowej retoryki), zaś łączy je skłonność do eksponowania urojonych zalet i faktów; dotyczy to m.in. kłamliwych zapewnień o „szerokich praktycznych zastosowaniach”. Pseudoteorie, których jedynym autentycznym celem są naukowe kariery (będące często zbiorowym interesem dużych grup osób), są sprzeczne z etyką, celami i etosem nauki. Patrz też: teoretyk, teoretyczny masochista, teoretyczny terrorysta.

pseudozmienna (pseudo-variable) Termin języka Smalltalk; zmienna predefiniowana w danym języku i posiadająca ściśle określone znaczenie i semantykę, np. nil, self, true, false, super.

PSM (Persistent Storage Manager) Patrz: skład trwałych obiektów.

PTR (Persistence Through Reachability) Patrz: trwałość poprzez osiągalność.

publiczny (public) Określenie własności obiektu, która nie jest hermetyzowana; jest ona dostępna z dowolnego miejsca zgodnie z regułami zakresu.

punkt funkcyjny (function point, FP) Patrz: analiza punktów funkcyjnych.

punkt kontrolny (checkpoint) Zapamiętanie bieżącego stanu programu (stanu zmiennych programu, stanu bazy danych, itd.) na pewnym trwałym nośniku. Dzięki temu możliwe jest wznowienie pracy programu od miejsca, w którym wprowadzono do niego punkt kontrolny. Punkty kontrolne są techniką implementacyjną funkcji odwrócenia (undo). W przetwarzaniu transakcji (np. w standardzie ODMG) punktem kontrolnym nazywa się wprowadzenie fizycznych zmian do bazy danych poczynionych przez transakcję, bez zwalniania założonych przez nią zamków. Tę sytuację można interpretować jako rozbicie transakcji na dwie transakcje; punkt kontrolny oznacza zakończenie (potwierdzenie) pierwszej transakcji i natychmiastowe wznowienie następnej transakcji z zamkami założonymi na tych samych obiektach, które były zablokowane przez poprzednią transakcję.

Python Obiektowy, interakcyjny, interpretowany, skryptowy język programowania. Pyton łączy pomysły z języków ABC, C, Modula-3 i Icon. Jest przeznaczony do szybkiej budowy prototypów lub jako język rozszerzający aplikacje napisane w C. Posiada pakiety, moduły, klasy, wyjątki definiowane przez użytkownika, dobry interfejs do C. Zapewnia też dynamiczne ładowanie modułów w C.

http://www.python.org/http://monty.cnri.reston.va.us/grail/

QA (Quality Assurance) Patrz: zapewnienie jakości.

RR

rachunek relacyjny (relational calculus) Wprowadzony przez E.F.Codda język zapytań będący pewnym podzbiorem języka rachunku predykatów. Istotną własnością

170


rachunku relacyjnego miała być jego matematyczna równoważność z algebrą relacji. Rachunek relacyjny był podstawą kilku języków zapytań, m.in. języka Alpha (nie zaimplementowanego) oraz QUEL, historycznego języka systemu Ingres. Rachunek relacyjny posiadał dwie odmiany: krotkowy rachunek relacyjny (tuple relational calculus), gdzie każda zmienna przebiegała wszystkie krotki pewnej relacji, oraz dziedzinowy rachunek relacyjny (domain relational calculus), gdzie każda zmienna przebiegała wszystkie wartości z jednej kolumny pewnej relacji. Niektórzy autorzy uważają dziedzinowy rachunek relacyjny jako podstawę obiektowego języka zapytań OQL, ale twierdzenia te są pozbawione wiarygodności (zważywszy chociażby na zasadnicze różnice w uniwersalności rachunku relacyjnego i uniwersalności OQL). Rachunek relacyjny, wskutek poważnych ograniczeń uniwersalności, nie jest koncepcją dostatecznie nośną, co spowodowało, że znalazł się on, chyba bezpowrotnie, w lamusie przestarzałych koncepcji naukowych. Próby reanimacji rachunku relacyjnego (pewnych jego rozszerzeń) do opisu obiektowych języków zapytań należy traktować jako pseudoteoretyczne zabawy nie posiadające żadnych istotnych konsekwencji.

RAD (Rapid Application Development) Szybkie tworzenie aplikacji. Terminem tym określa się narzędzia i techniki programowania umożliwiające szybką budowę prototypów lub gotowych aplikacji, z reguły oparte o programowanie wizyjne. Termin RAD występuje niekiedy jako synonim języków/środowisk czwartej generacji. Przykładami narzędzi RAD są: Borland Delphi RAD Pack, IBM VisualAge (for Cobol, Java, C++, Smalltalk), Microsoft Access Developer’s Toolkit, Microsoft Visual FoxPro Professional, PowerBuilder Desktop, Power++ i wiele innych.

http://www.riv.nl/origin/company/denhaag/RAD.HTM

Raima Object Manager Obiektowy SZBD wspomagający programowanie w C++.http://www.raima.com/products/rom.cfm

RAP (Rapid Application Prototyping) Szybka budowa prototypów aplikacji. Określenie techniki do szybkiej budowy prototypów; zwykle jest to pewien język czwartej generacji (4GL) lub narzędzie RAD.

RDBMS (Relational Data Base Management System) Patrz: relacyjny system zarządzania bazą danych.

rdzeń ORB (ORB core) Część pośrednika (ORB) odpowiedzialna za komunikację pomiędzy pośrednikami.

referencja (reference) Identyfikator obiektu używany przez program lub zapytanie. (Inaczej: odwołanie, odsyłacz, odnośnik.) Referencja jest pojęciem dość bliskim pojęciu wskaźnika (pointer). Istotna różnica polega na tym, że programista używa wskaźników explicite tak jak wartości, np. może tworzyć zmienną lub atrybut z taką wartością, natomiast referencja jest używana implicite przez niektóre konstrukcje języka programowania lub języka zapytań, np. przez instrukcję podstawienia na zmienną, instrukcję usuwania obiektu, jako parametr procedury komunikowany przez referencję (call-by-reference), itp.

171


refleksja (reflection) Technika programowania, w której programista pisze program generujący kod programu (w tym samym lub w innym języku), składając go ze stałych stringowych, danych, wejścia z klawiatury, metadanych zapamiętanych w pewnym repozytorium, itd. Wygenerowany program (zwykle w postaci ciągu znaków) poddaje się kompilacji i wykonaniu w tym samym programie, który go utworzył. W językach interpretowanych program jest wykonywany bezpośrednio po utworzeniu. Refleksja jest prostą i skuteczną metodą programowania generycznego (generic), o elastyczności i uniwersalności znacznie przekraczających poziom osiągalny przy pomocy systemów z typami polimorficznymi. Jednocześnie jest techniką dość prostą w implementacji i użyciu. Najbardziej znanym (najwcześniejszym) językiem z refleksją jest Lisp. Pewien wariant refleksji został wykorzystany w dynamicznym SQL oraz w wielu interfejsach określanych jako języki czwartej generacji (4GL). Refleksja jest techniką programistyczną w standardzie CORBA, gdzie jest podstawowym środkiem programowania generycznego wykorzystującego DII (Dynamic Invocation Interface) oraz repozytorium interfejsów. Zaawansowane metody refleksji wymagają istnienia odpowiednio skonstruowanej metabazy, gdzie wszelkie informacje niezbędne do składania programu z fragmentów (np. typy, interfejsy, schematy) są przechowywane w odpowiedniej postaci, np. w postaci ciągów znaków i są dobrze zestrukturalizowane. Wadami refleksji są: dość uciążliwe programowanie bardziej skomplikowanych zadań, przystosowanie do języków interpretowanych i późno wiązanych (np. jest nierealizowalna w C++), słabe możliwości w zakresie mocnej kontroli typów (co czyni ją techniką niebezpieczną). Istnieją koncepcje zdyscyplinowania refleksji tak, aby była ona typologicznie bezpieczna; jak dotąd nie wyszły one poza fazę badawczą.

refleksja lingwistyczna (linguistic reflection) Patrz: refleksja.

reguła (rule) Rodzaj danej przechowywanej w bazie danych lub bazie wiedzy, która jest interpretowana lub uruchamiana przez system. Rodowód pojęcia pochodzi od reguł logicznych, np. klauzul Horna, jednak tego rodzaju reguły nie uzyskały jakiegokolwiek znaczenia w rzeczywistych bazach danych. Regułami nazywa się: ograniczenia (więzy) integralności nakładane na wartości danych lub na zmianę wartości danych, ograniczenia dostępu do danych, fragmenty kodu (tzw. aktywne reguły) przypisane do danych, które są automatycznie wyzwalane przez pewne zdarzenia (np. nadejście określonego momentu czasowego lub zdarzenia zachodzące na danych, np. próba aktualizacji danej). Zwrócimy uwagę, że w odróżnieniu od programowania w logice, w systemach baz danych reguły są „obywatelami pierwszej kategorii”, tj. mogą mieć nazwę, określone granice i mogą podlegać manipulacjom, takim np. jak tworzenie, usuwanie oraz zmiana stanu.

reguła biznesowa (business rule) Reguła realizująca pewną powtarzalną sytuację w biznesie lub pewne ograniczenie związane z biznesem. Patrz: też: aktywne reguły.

reguła wnioskowania o typie (type inference rule) Reguła pozwalająca wnioskować o typie wyrażenia występującego w języku programowania na podstawie typu stałych, podwyrażeń, funkcji, operatorów, itd. uczestniczących w tym wyrażeniu. Np. jeżeli wyrażenie ma postać X+Y, gdzie X jest typu integer, a Y jest typu real, to wówczas

172


odpowiednia reguła wnioskowania o typie ustala, że typem X+Y jest real. W bardziej ogólnym przypadku, reguła wnioskowania o typie jest przyporządkowana do danej konstrukcji gramatycznej i ustala na podstawie (wydedukowanych) typów składowych tej konstrukcji, jaki ma być typ wynikowej konstrukcji. Np. reguła może mieć postać:

f :: A B, x :: A

f(x) :: B

co oznacza: jeżeli funkcja f jest typu AB, x jest typu A, to wyrażenie f(x) jest typu B.

reguły zakresu (scope rules, scoping) Reguły określające kolejność rozpatrywania poszczególnych środowisk przechowujących byty programistyczne przy wiązaniu nazw występujących w programie; np. najpierw lokalne środowisko metody, następnie środowisko klasy, w której metoda została zdefiniowana, następnie środowisko obiektu, na którym działa ta metoda, następnie baza danych, następnie biblioteki procedur i na końcu - zmienne środowiskowe systemu komputerowego. W obiektowości reguły zakresu są nietrywialnym tematem rodzącym problemy semantyczne. Reguły zakresu są najczęściej implementowane w postaci tzw. stosu środowisk (environmental stack), gdzie czubek stosu odwzorowuje najbardziej lokalne środowisko, zaś podstawa stosu - najbardziej globalne. Przy wiązaniu nazw stos środowisk jest przeszukiwany od czubka do podstawy. Poniższy rysunek przedstawia przykład pokazujący kolejność wizyt w poszczególnych środowiskach przy wiązaniu nazwy X występującej wewnątrz ciała metody m zdefiniowanej w klasie PRACOWNIK.

Stos środowisk

Parametry i lokalne zmienne metody m

Atrybuty testowanego obiektu PRACOWNIK

Wyeksportowane cechy klasy PRACOWNIK

Wyeksportowane cechy klasy OSOBA

Prywatne cechy klasy PRACOWNIK

Obiekty bazy danych, perspektywy, ...

Globalne procedury, zmienne środowiskowe,...

Kolejność przeszukiwania stosu podczas wiązania nazwy X

Fragment składu obiektów

. . .PRACOWNIK

Nazwisko Nowak

Zarobek 2500 ...

PRACOWNIK

Nazwisko Grzelak

Zarobek 2000 ...

OSOBA........

PRACOWNIK....

m(...)n(...)

Stos środowisk i reguły zakresu

reinżynieria (reengineering, re-engineering) Przegląd, ocena i modyfikacja systemu celem odtworzenia go w nowej formie (lepszej z ekonomicznego i/lub użytkowego punktu widzenia), a następnie ponowna implementacja tego systemu.

http://www.erg.abdn.ac.uk/users/brant/sre/

173


reinżynieria procesów biznesowych (Business Process Reengineering, BPR) Fundamentalne przemyślenie i radykalne przeprojektowanie procesów przedsiębiorczości dla uzyskania dramatycznego usprawnienia wg krytycznych współczesnych miar wydajności, takich jak koszt, jakość, serwis i szybkość. Patrz też: reinżynieria.

rekord (record) Patrz: zapis.

relacja (relation) Pojęcie matematyczne, definiowane jako podzbiór iloczynu kartezjańskiego pewnych dziedzin (zbiorów). Relacja stała się podstawowym pojęciem relacyjnego modelu danych, jednakże w ramach tego modelu nabrała ona nieco innego znaczenia, równoważnego (nieskończonej) rodzinie tablic zawierających pewną liczbę nazwanych kolumn i nieograniczoną liczbę wierszy. Istotną własnością tej rodziny jest obecność klucza, tj. kolumny (kolumn), której (których) elementy w jednoznaczny sposób identyfikują wiersze tablicy. Ze względu na powyższą homonimię, wiele systemów odchodzi od stosowania terminu „relacja” na rzecz terminu „tablica”. Pojęcie relacji jest mało precyzyjnym modelem struktur danych (tablic) implementowanych w relacyjnych bazach danych. Np. bazując na czystym pojęciu relacji nie można zdefiniować operatora złączenia naturalnego (natural join) ani też operatora złączenia zewnętrznego (outer join). SQL robi dalsze odstępstwa od tego pojęcia poprzez wprowadzenie możliwości wstawiania do tablic duplikatów krotek, poprzez możliwość sekwencyjnego uporządkowania krotek, grupowania, itd. Środki przetwarzania tablic muszą być znacznie mocniejsze od środków oferowanych przez typowe formalizmu matematyczne operujące na relacjach, takie jak algebra relacji lub rachunek relacyjny.

relacyjna baza danych (relational database) Baza danych zorganizowana według informatycznej ideologii określanej jako „relacyjny model baz danych”. Ideologię tę zaproponował E.F.Codd w 1970 r., zaś nieco później sformułował jej założenia w postaci tzw. 12 reguły „prawdziwego systemu relacyjnego”. Większość tych reguł jest rozsądna i określa zasady budowy systemów zarządzania bazą danych, które powinny obowiązywać nie tylko dla systemów relacyjnych; np. reguła 3 zwracająca uwagę na konieczność systematycznego traktowania wartości zerowych, lub reguła 8 żądająca niezależności programistycznych interfejsów od fizycznej organizacji danych. Niektóre reguły (np. reguła 0) stanowią manifestację myślenia życzeniowego, w którym zapomina się o fakcie, że środki operacyjne i abstrakcje programistyczne wynalezione przez twórców modelu relacyjnego (np. algebra relacji lub SQL) nie są wystarczająco uniwersalne, aby sprostać wymaganiom wielu zastosowań baz danych. W praktycznych implementacjach założenia te są często modyfikowane lub ignorowane. W związku z tym „prawdziwego systemu relacyjnego” nie ma i chyba już nie będzie. Współczesne relacyjne bazy danych łączy kilka cech. Jedną z nich jest logiczna organizacja bazy danych, która jest widziana jako zbiór nazwanych prostokątnych tablic o nieograniczonej liczbie wierszy i o określonej liczbie nazwanych kolumn. Wartości zapisane w tych tablicach są atomowe (niepodzielne) i nie są odsyłaczami do lokacji maszynowych (adresów w pamięci, adresów dyskowych, itp.) lub wewnętrznych identyfikatorów wierszy (krotek) tych tablic. Drugą cechą jest dostęp do danych poprzez język zapytań wysokiego poziomu, zwykle SQL lub jego mutację. Trzecią

174


cechą jest katalog danych, zorganizowany również w postaci tablic i dostępny z języka wysokiego poziomu. Pozostałe cechy systemów określanych jako „relacyjne” - wielodostęp, perspektywy, języki 4GL, etc. - są silnie zróżnicowane.

relacyjna perspektywa (relational view) Wirtualna tablica utworzona poprzez zapytanie (np. w SQL). Relacyjna perspektywa zawiera dane, które pochodzą z jednej lub kilku zapamiętanych tablic. Perspektywy zwykle nie istnieją fizycznie jako zapamiętane dane; istnieją wyłącznie w postaci definicji. Tym niemniej użytkownik może je do pewnego stopnia traktować tak samo jak zapamiętane tablice, używając ich nazw i przypisanych im atrybutów, np. w zdaniach SQL. W szczególności, może używać perspektyw do wyszukiwania i do definiowania innych perspektyw. W niektórych przypadkach perspektywa jest „materializowana” celem zwiększenia szybkości przetwarzania. Poniżej znajduje się przykład definicji perspektywy w SQL:

create view DobryDostawca( Nr, Nazwisko, Miasto )as

select DNR, NAZWISKO, MIASTO from DOSTAWCAwhere STATUS > 30

W ten sposób została utworzona wirtualna tablica DobryDostawca z atrybutami Nr, Nazwisko, Miasto, która jest (poziomym i pionowym) zawężeniem tablicy DOSTAWCA, poprzez przesłonięcie wierszy, w których status dostawcy jest mniejszy lub równy 30, oraz przesłonięcie niektórych kolumn. Taka perspektywa może być użyta w zapytaniu SQL na normalnych zasadach, np.:

select Nr, Nazwisko from DobryDostawca where Miasto = ‘Kraków’

Negatywnymi cechami relacyjnych perspektyw (definiowanych w SQL) jest ograniczenie funkcjonalności (nie wszystkie wyobrażalne wirtualne tablice dadzą się wyrazić w SQL) oraz nie rozwiązany (w ogólnym przypadku) problem aktualizacji perspektyw.

relacyjny system zarządzania bazą danych, RSZBD (Relational Data Base Management System, RDBMS) Systemy takie jak: Oracle, Sybase, Ingres, DB2, Informix, Progress, Dbase, MS SQL Server, i wiele innych. Patrz: relacyjna baza danych.

relewancja (relevance) Pewna ilościowa lub jakościowa miara określająca precyzję lub odpowiedniość wyniku wyszukiwania, tj. w jakim stopniu rezultat wyszukiwania (tekstów, pozycji bibliograficznych, stron WWW, obiektów, grafiki) odpowiada intencji użytkownika wyrażonej w zapytaniu. Relewancja zależy od precyzji języka zapytań, od naturalności użycia jego konstrukcji dla użytkowników, od metody i jakości opisu (indeksowania) obiektów będących przedmiotem wyszukiwania, oraz od algorytmów ustalających odpowiedniość danego obiektu do danego zapytania. Terminów relewantny/nierelewantny używa się także potocznie jako synonimów odpowiedni/nieodpowiedni dla danej sprawy, problemu, zagadnienia, itp.

175


replikacja (replication, mirror) Kopia danych przechowywana w miejscu odległym od miejsca przechowywania oryginału. Replikacje zmniejszają obciążenie sieci oraz zwiększają dostępność danych, niezawodność i bezpieczeństwo. Poważnym problemem związanym z replikacjami jest konieczność jednoczesnej aktualizacji wszystkich istniejących kopii danych.

replikator (replicator) Moduł systemu zarządzania bazą danych, którego zadaniem jest podtrzymywanie spójnych kopii danych w różnych oddalonych geograficznie miejscach. W przypadku aktualizacji dowolnej z nich, replikator automatycznie aktualizuje pozostałe kopie. Ze względu na koszt transmisji oraz ze względu na autonomię lokalnej bazy danych, nie zawsze jest korzystna natychmiastowa aktualizacja kopii. Większość aplikacji może tolerować pewne opóźnienie w aktualizacji kopii. Z tego względu replikatory posiadają dodatkowe możliwości sterowania opóźnieniem; np. kopie są aktualizowane pod koniec dnia, raz na tydzień, itp. Istnieje kilka modeli replikacji, np. model, w którym aktualizowana może być tylko główna kopia, zaś repliki mogą być tylko czytane.

repozytorium (repository) Skład, magazyn obiektów lub innych danych. Zwykle intencją tego terminu jest skład przechowujący dane różnych typów (dokumenty, klasyczne dane, dane multimedialne, programy, skrypty, reguły, perspektywy) oraz udostępniający je przy pomocy środków wizualnych.

repozytorium implementacji (implementation repository) W terminologii standardu OMG CORBA miejsce przechowywania informacji o implementacji obiektów, wraz z usługami pozwalającymi zidentyfikować oraz zlokalizować obiekt.

http://www.omg.org

repozytorium interfejsów (interface repository, IR) Termin OMG CORBA; miejsce przechowywania definicji interfejsów (specyfikacji klas), które może być przeszukiwane przy pomocy standardowych środków. Repozytorium interfejsów jest zwykle wykorzystywane przy wołaniach dynamicznych (Dynamic Invocation Interface, DII).

http://www.omg.org

REXX Skryptowy uniwersalny język programowania będący integralną częścią systemu operacyjnego OS/2 firmy IBM. Posiada elementy obiektowości.

http://www2.hursley.ibm.com/orexx/http://www2.hursley.ibm.com/rexx/

RFI (Request For Information) Dokument (w postaci ankiety) rozsyłany przez OMG celem ustalenia stopnia zainteresowania członków OMG konkretnym elementem standardu CORBA.

http://www.omg.org

RFP (Request For Proposal) Dokument (w postaci ankiety) rozsyłany przez OMG celem ustalenia szczegółów, propozycji i wymagań dotyczących konkretnego elementu standardu CORBA.

176


http://www.omg.org

RMI (Remote Message Invocation) Wołanie odległej metody. Pośrednik wymiany obiektów (ORB) firmy JavaSoft rozszerzający język Java. Poprzednie wersje nie były kompatybilne ze standardem CORBA; obecnie, w wyniku porozumienia producentów oprogramowania, JavaSoft planuje zaadoptowanie RMI jako pakietu działającego na bazie CORBA/IIOP. RMI służy do integracji aplikacji napisanych w Java.

http://java.sun.com/products/jdk/1.1/docs/guide/rmi/index.htmlhttp://www.corbajava.engr.sjsu.edu

rola [1] (role) Dynamicznie zmieniająca się specjalizacja obiektu. Każdy obiekt może jednocześnie występować w wielu rolach. Rola importuje wszystkie atrybuty wraz z ich wartościami z obiektu będącego jej podmiotem. Każda z ról może należeć do własnej klasy. Np. obiekt OSOBA może być jednocześnie w rolach PRACOWNIK, PACJENT, PODATNIK, itd. Rysunek poniżej przedstawia cztery obiekty OSOBA, które mogą mieć dwie role: PRACOWNIK i STUDENT; każda z ról dziedziczy inwarianty z własnej klasy oraz importuje (strzałka z podwójną linią) atrybuty i ich wartości z obiektu będącego jej podmiotem. Role można traktować jako dynamicznie i równolegle pojawiające się i znikające specjalizacje obiektu. Koncepcja ról umożliwia znacznie bardziej czyste potraktowanie wielu pojęć obiektowości, w szczególności pozwala zrezygnować z zasady zamienialności (substitutability), pozwala na spójne potraktowanie powiązań pomiędzy obiektami, oraz umożliwia opanowanie problemu wielodziedziczenia. Brak pojęcia roli w modelach i systemach obiektowych powoduje ograniczenia i konflikty, które następnie zamieniają się w dość jałowe dyskusje dotyczące metod ich uniknięcia, czego przykładem są dyskusje dookoła pojęcia wielodziedziczenia. Jak dotąd, role nie są implementowane i praktycznie nie występują w metodykach analizy i projektowania. Zamiast nich, autorzy tych metodyk posługują się zbytnio uogólnionym terminem agregacja lub semantycznie mętnym terminem delegacja. Temat ról jest przedmiotem wzorców projektowych (design patterns) (np. wzorca określanego jako decorator). Takie podejście do zagadnienia jest jednak bardziej próbą wynalezienia kolejnej protezy dla ułomnego modelu, niż istotnym wyleczeniem przyczyny ułomności.

177


OSOBANazwisko Abacka

RokUr 1948

OSOBA Nazwisko

RokUrWiek()

PRACOWNIKZarobek

DziałZarobekNetto()

ZmieńZarobek(..)

OSOBANazwisko Kowalska

RokUr 1975

PRACOWNIKZarobek 2500Dział Kredyty

STUDENTSemestr

NrIndeksuWpiszOcenę(...)

ObliczŚredniąOcen()

OSOBANazwisko Nowak

RokUr 1951

PRACOWNIKZarobek 1500Dział Obsługa

STUDENTSemestr 7

NrIndeksu 223344

Klasy

OSOBANazwisko Nowacki

RokUr 1940

STUDENTSemestr 4

NrIndeksu 556677

Obiekty

FIRMANazwa BankSA

pracuje_w pracuje_w

UCZELNIANazwa PW

studiuje_na

UCZELNIANazwa UW

studiuje_najest_klientem

Obiekty i dynamiczne role

rola [2] (role, role name) W diagramach encja-związek (oraz diagramach obiektowych) rola jest nazwą przypisaną do jednej dziedziny związku (asocjacji), np. związek Ślub łączący 3 osoby (mężczyznę, kobietę oraz księdza) posiada trzy nazwane role: PanMłody, PannaMłoda i Ksiądz.

rola [3] (role) W metodykach analizy i projektowania systemów informatycznych rolą określa się kategorię pracownika lub użytkownika, będącego podmiotem systemu informatycznego lub projektu (dyrektor, pracownik, analityk, programista, itd.). Synonim: aktor.

rola asocjacji (association role) Patrz: rola [2].

Rose Narzędzie CASE firmy Rational, stosujące m.in. notację UML.http://www.rational.com/products/rose/

RoughWave Biblioteka klas w C++ oferowana przez firmę Rough Wave Software. Zawiera m.in. standardową bibliotekę C++, klasy do pisania aplikacji wielowątkowych (multithreaded), pomost pomiędzy językami Java i C++, klasy do optymalizacji zarządzania pamięcią, biblioteki funkcji matematycznych, udogodnienia służące do dostępu do relacyjnych baz danych, środki do programowania wizyjnego i konstrukcji graficznych interfejsów użytkownika, środki do programowania aplikacji klient/serwer i innych systemów rozproszonych, środki do współdziałania ze standardem CORBA i

178


inne.

rozproszona baza danych (distributed database) Baza danych, która jest rozproszona geograficznie, ale opisywana przez pewien globalny schemat (zwany niekiedy schematem federacyjnym). Istotą rozproszonej bazy danych (w odróżnieniu od dostępu do odległych zasobów, np. poprzez ODBC lub JDBC) jest jednorodność jej organizacji i przezroczystość rozproszenia. Programista programujący aplikację działającą na rozproszonej bazie danych postępuje tak, jak gdyby baza danych była scentralizowana. Rozproszone bazy danych implikują trudne problemy, m.in. związane z przetwarzaniem i optymalizacją rozproszonych zapytań, optymalizacją obciążenia sieci, uzyskaniem wysokiej niezawodności przetwarzania transakcji w sytuacji zawodnej sieci (patrz np. protokół 2PC) i technologią przetwarzania replikacji (kopii danych).

http://www2.hawaii.edu/~ramesh/ics691.html

rozproszone obiekty (distributed objects) Architektura systemu, w której obiekty są zlokalizowane w różnych, geograficznie oddalonych węzłach sieci komputerowej. Niekiedy z tym terminem wiązana jest możliwość przemieszczania obiektów z danego węzła do innego węzła.

rozproszony powszechny model obiektowy (DCOM, Distributed Common Object Model) Patrz: DCOM.

rozproszony system obiektowy (distributed object system) System zapewniający geograficzne rozproszenie obiektów oraz własność przezroczystości (transparency); tj. programista działający w systemie rozproszonym nie musi zajmować się nawiązywaniem połączeń i protokołami transmisji obiektów. (W tym sensie, aplikację zapewniającą dostęp do odległych obiektów przy pomocy specjalnych komend lub interfejsów kwalifikuje się jako bardzo uproszczone rozproszenie.) Rozproszone systemy obiektowe są przedmiotem szeregu standardów i produktów określanych jako oprogramowanie pośredniczące (middleware); przykładem są pakiety ORB zbudowane wg standardu CORBA, COM, OpenDoc, OSF DCE, RMI, JavaBeans. Odrębnym tematem są obiektowe rozproszone bazy danych. W relacyjnych bazach danych temat ten zaowocował w różnorodne rozwiązania, m.in. pomosty (gateways) do obcych systemów, własne protokoły/pakiety dostępu do odległych baz danych (zwykle oparte o RPC), replikacje, przetwarzanie zapytań w rozproszonych bazach danych, protokoły przetwarzania transakcji w systemach rozproszonych takie jak 2PC, architektura klient/serwer i inne. Należy zwrócić uwagę, że temat rozproszenia powiązany z tematem współdziałania (interoperability) był podejmowany przez wiele środowisk akademickich i przemysłowych, ale (pomimo setek publikacji) jest dość trudno określić jednoznaczne rezultaty tej aktywności (poza dość zgrubnymi hasłami takimi jak „federacyjna baza danych”, „globalny schemat”, „integracja schematów”, itp.). Rynek zdominowały różnorodne rozwiązania ad hoc, niekompatybilne, często obarczone istotnymi wadami. Przyczyną jest prawdopodobnie to, że problem jest bardzo trudny, uwikłany w wiele szczegółów związanych z wydajnością, niezawodnością, bezpieczeństwem, implementacją i infrastrukturą rozproszonych systemów. Poprzez to

179


temat nie poddaje się generalizacjom, spekulacjom, czy teoriom. Temat rozproszonych obiektowych baz danych jest podejmowany przez wiele grup akademickich i przemysłowych, ale jak dotąd, dość trudno stwierdzić, że prace te zaowocowały konkretnymi systemami lub rozwiązaniami na rynku. Pakiety lub standardy takie jak CORBA lub DCOM są ulokowane (z koncepcyjnego punktu widzenia) blisko poziomu systemu operacyjnego. Mogą więc stanowić bazę techniczną dla rozproszonych baz danych, ale nie są w stanie rozwiązać problemów koncepcyjnych, takich jak np. federacyjność i autonomia, aktualizowalne perspektywy (wirtualne schematy), optymalizacja rozproszonych zapytań, czy też przetwarzanie replikacji. Wydaje się, że obiektowe bazy danych będą jeszcze jakiś czas dojrzewać do powyższych tematów.

rozprzestrzenianie (deployment) Przystosowywanie oprogramowania przygotowanego na daną platformę do pracy na innych platformach. Terminem tym określa się również przypisanie składowych danego oprogramowania do elementów architektury sprzętu; patrz: diagram rozprzestrzeniania. Synonim: wdrażanie.

rozszeregowanie (unmarshalling) Wyjaśnienie - patrz: szeregowanie.

rozszerzalność (extensibility) W szerszym znaczeniu, pewna ilościowa lub jakościowa miara określająca łatwość, z jaką dany system lub język można rozszerzyć o nowe funkcje. W węższym znaczeniu zwykle chodzi o możliwość definiowania i nazywania (przez projektanta lub programistę) nowych klas i/lub typów na podstawie klas/typów wbudowanych w system oraz klas/typów już zdefiniowanych i nazwanych.

rozszerzony relacyjny SZBD (extended relational DBMS, extended RDBMS) Relacyjny SZBD rozszerzony o pewne niestandardowe funkcje, np. przetwarzanie multimediów, obiektowość, reguły, abstrakcyjne typy danych, zintegrowanie z WWW, hurtownie danych, itd. Patrz też: obiektowo-relacyjny.

rozszerzony RSZBD (extended RDBMS) Patrz: rozszerzony relacyjny SZBD.

rozwój oprogramowania (software development) Proces analizy, projektowania, konstrukcji, testowania i wdrażania oprogramowania. Synonim: wytwórstwo oprogramowania.

równorzędny (peer) Określenie jednostki sprzętu lub oprogramowania, która w danym systemie lub sieci jest równorzędna w stosunku do innych jednostek; zwykle określenie to występuje w kontraście w stosunku do określeń takich jak klient i serwer.

równorzędny-do-równorzędnego (peer-to-peer) Określenie architektury sprzętu lub oprogramowania (oraz rodzaju komunikacji), w której występują dwie lub więcej jednostek na tym samym poziomie, równorzędnych, komunikujących się przy pomocy tego samego protokołu. Zwykle architekturę tę przeciwstawia się architekturze klient-serwer lub innym zależnościom hierarchicznym pomiędzy jednostkami.

RPC (Remote Procedure Call) Patrz: wołanie odległej procedury.

180


RSZBD (RDBMS, Relational Data Base Management System) Relacyjny System Zarządzania Bazą Danych.

Rumbaugh, James Główny twórca metodyki obiektowej OMT; jeden z twórców notacji Unified Modeling Language, UML.


r-wartość (r-value) Synonim wartości, wynik wyrażenia, które po ewaluacji zwraca wartość, np. 2+2, x+1, sin(x), itd. R-wartość nie może pojawić się po lewej stronie operacji podstawienia, może ono natomiast pojawić się po prawej stronie (stąd r-wartość, od right). Jeżeli wyrażenie zwraca referencję (do zmiennej, atrybutu, itd.) i stoi w miejscu, gdzie oczekiwana jest r-wartość, wówczas automatycznie jest wywoływana operacja dereferencji. R-wartość jest obliczonym parametrem aktualnym przy wołaniu poprzez wartość oraz może parametryzować zdania imperatywne. Przeciwieństwem r-wartości jest l-wartość (l-value, od słowa left).

rzutowanie (cast) Patrz: kast.

SS

samoreferencja (self-reference) Identyfikacja obiektu, do którego został wysłany komunikat. Samoreferencji używa się wewnątrz ciała metody wywoływanej po odebraniu komunikatu; do tego celu służą pseudozmienne, takie jak self lub this.

Sather Obiektowy język programowania, pochodna języka Eiffel. Podstawowymi założeniami tego języka są m.in.: efektywność (maszynowa), elegancja definicji, bogata biblioteka klas, statyczna mocna kontrola typów i możliwość definiowania funkcji wyższego rzędu.

http://http.icsi.berkeley.edu/Sather/

scenariusz (scenario) Pojęcie niektórych metodyk obiektowych, np. MainstreamObjects. Sekwencja czynności lub transakcji realizująca konkretną funkcję użytkową systemu. Pojęcie scenariusza jest bliskie lub tożsame z pojęciem przypadku użycia (use case).

schemat bazy danych (database schema) Obraz zawartości bazy danych, wyrażony w sformalizowanym języku. W obiektowych bazach danych schemat jest formalnym opisem zawartości bazy danych uwzględniającym klasy, specyfikacje atrybutów, specyfikacje metod, typy, powiązania pomiędzy klasami obiektów oraz inne informacje. Schemat może dotyczyć różnych poziomów abstrakcji: schemat logiczny (logical schema) przedstawia budowę struktur danych na

poziomie abstrakcji niezbędnym dla prawidłowego manipulowania danymi przez programistę i użytkownika;

schemat pojęciowy (conceptual schema) ustala klasy obiektów modelowanej

181


rzeczywistości oraz koncepcyjne związki pomiędzy tymi obiektami, przez co ułatwia rozumienie semantyki danych;

schemat fizyczny (physical schema) przedstawia szczegóły organizacyjne dla poszczególnych typów danych (indeksy, tablice mieszające, itp.).

Schemat bazy danych jest niezbędny dla jej użytkowników i programistów do zrozumienia, co baza danych zawiera i jak dane są zorganizowane. Schemat bazy danych jest wykorzystywany przez SZBD dla właściwej organizacji danych, kontroli typów danych oraz wymuszenia niektórych ograniczeń dotyczących danych. Fragment schematu odnoszący się do jednego użytkownika lub jednej aplikacji jest zwany podschematem. Ma on na celu uproszczenie wizji danych oraz ograniczenie dostępu do danych. Zwykle schemat bazy danych jest wyrażeniem języka opisu danych (data description language, DDL), np. ODL wg standardu ODMG.

schemat federacyjny (federated schema) Schemat rozproszonej bazy danych, w którym uwidocznione są te zasoby danych, które autonomiczne węzły sieci komputerowej zadeklarowały jako dostępne dla danego rozproszonego systemu.

schemat fizyczny (physical schema) Przedstawia szczegóły organizacji danych (indeksy, struktury pomocnicze, pliki, wskaźniki, fizyczną organizację zbiorów, itp.) dla poszczególnych elementów schematu logicznego lub pojęciowego.

schemat globalny (global schema) Koncepcja organizacji rozproszonej bazy danych, w której wszystkie miejsca w rozproszonej bazie danych są objęte jednym globalnym schematem, jednakowym dla każdego miejsca. Globalny schemat zakłada przezroczystość rozproszenia, tj. programista nie musi być świadomy tego, gdzie dane są fizycznie przechowywane i nie musi explicite używać komend transmisji danych. Istotną wadą podejścia opartego na globalnym schemacie jest zredukowana możliwość sterowania zakresem autonomii każdego lokalnego systemu.

schemat logiczny (logical schema) Schemat przedstawiający budowę struktur danych na poziomie abstrakcji niezbędnym dla prawidłowego manipulowania danymi przez programistę i użytkownika, bez konieczności odwoływania się do szczegółów implementacyjnych. Zwykle schemat logiczny jest zapisany w języku konkretnego SZBD; patrz: schemat bazy danych.

schemat obiektowy (object schema) Schemat bazy danych zapisany w języku definicji danych systemu obiektowego (DDL, Data Definition Language), np. w ODL wg standardu ODMG.

schemat pojęciowy (conceptual schema) Schemat bazy danych przedstawiony w postaci diagramu pojęciowego klas, ich hierarchii i powiązań. Schemat pojęciowy odwołuje się przede wszystkim do ludzkiego myślenia, percepcji i komunikacji międzyludzkiej, natomiast w drugiej kolejności do realizacji komputerowej.

schemat wewnętrzny (internal schema) Patrz: schemat fizyczny.

sekwencja (sequence) W terminologii obiektowych baz danych (np. standardu

182


ODMG) konstruktor typów lub klas. Wartość lub obiekt typu „sekwencja” jest kontenerem zawierającym wiele (dowolnie dużo) elementów. Wartość typu sekwencja może być dowolnie rozszerzona o nowe elementy oraz można z niej usunąć elementy istniejące. W odróżnieniu od zbioru i wielozbioru, porządek elementów w sekwencji ma znaczenie i jest wykorzystywany przez niektóre operatory, np. DajPierwszy, DajNastępny, CzyOstatni, itp.

selekcja (selection) Operator algebry relacji lub języka zapytań, który tworzy nową relację poprzez wybranie z wejściowej relacji wierszy spełniających pewien warunek (zwany predykatem). W obiektowych językach zapytań analogiczny operator wybiera pewien fragment wejściowej kolekcji obiektów na podstawie określonego warunku.

selektor (selector) Termin języka Smalltalk; część komunikatu ustalająca nazwę metody. Zwykle selektorem nazywa się operację, która odczytuje własność obiektu, ale jej nie zmienia.

Self Obiektowy język programowania oparty o koncepcje prototypów i delegacji, dynamicznego dziedziczenia, behawioru i stanów.

http://self.smli.com

self Słowo kluczowe (Smalltalk) występujące w ciele metody i identyfikujące obiekt, do którego został wysłany komunikat zawierający nazwę tej metody; często używa się także słowa this (np. C++) lub current. Istnieją drobne niuanse semantyczne związane ze znaczeniem tych słów w poszczególnych językach.

semantyczny model danych (semantic data model) Model danych wprowadzający pojęcia takie jak: generalizacja, specjalizacja, asocjacja, agregacja, klasyfikacja, które ułatwiają odwzorowanie modelowanego fragmentu rzeczywistości w jej abstrakcyjny obraz pojęciowy lub zapis (diagram) w pewnej notacji. Przykładem semantycznych modeli danych jest model encja-związek i model obiektowy.

semantyka (semantics) Ogólnie: dział lingwistyki zajmujący się badaniem znaczenia wyrazów, fraz, zdań, etc. W informatyce terminu tego używa się w sytuacjach, kiedy mówimy o znaczeniu tekstu (np. programu), danych, lub struktury formalnej (np. diagramu). W matematyce semantyka oznacza formalne odwzorowanie napisów pewnego języka w obiekty matematyczne; np. odwzorowanie tekstu programu w funkcję określoną na zbiorze stanów. W nieformalnych modelach danych semantyka oznacza odwzorowanie danych lub schematów (diagramów, modeli) w obrazy pojęciowe (koncepcyjne) dotyczące modelowanej rzeczywistości.

semantyka danych (data semantics) Znaczenie danych; odwzorowanie danych w obrazy pojęciowe dotyczące modelowanej rzeczywistości.

semantyka oparta na kopiowaniu (copy semantics) Ogólnie, określenie semantyki pewnej konstrukcji gramatycznej, w której operuje się na kopii argumentu lub składowej tej konstrukcji. Np. iterator

183


for each x in K do p(x)

(gdzie x jest zmienną iteratora, K jest kontenerem obiektów, zaś p(x) jest pewnym programem zależnym od zmiennej x wykonywanym w pętli iteratora) posiada semantykę opartą na kopiowaniu, jeżeli w każdym obrocie pętli iteratora na zmienną x podstawia się kopię kolejnego obiektu z kontenera K. Możliwe są inne konstrukcje, których semantyka jest oparta na kopiowaniu, np. metoda przekazywania parametrów określana jako wołanie poprzez wartość ze zwrotem (call-by-value-return). Semantykę opartą na kopiowaniu przeciwstawia się semantyce opartej na referencjach.

semantyka oparta na referencjach (reference semantics) Ogólnie, określenie semantyki pewnej konstrukcji gramatycznej, w której operuje się na referencji do argumentu lub składowej tej konstrukcji. Np. iterator

for each x in K do p(x)

(gdzie x jest zmienną iteratora, K jest kontenerem obiektów, zaś p(x) jest pewnym programem zależnym od zmiennej x wykonywanym w pętli iteratora) posiada semantykę opartą na referencjach, jeżeli w każdym obrocie pętli iteratora na zmienną x podstawia się referencja do kolejnego obiektu z kontenera K. Możliwe są inne konstrukcje, których semantyka jest oparta na referencjach, np. metoda przekazywania parametrów określana jako wołanie poprzez referencję (call-by-reference). Semantykę opartą na referencjach przeciwstawia się semantyce opartej na kopiowaniu.

serwer (server) Element architektury klient-serwer realizujący zlecenia klientów.

serwer aplikacji (application sever) Składnik trzywarstwowej architektury (three-tier architecture) zbierający zlecenia od klientów, realizujący logikę biznesu, wysyłający zlecenia do serwerów, zbierający wyniki tych zleceń i przekazujący je w odpowiedniej formie do klientów.

serwlet (servlet) Kod języka Java, który jest wykonywany po stronie serwera WWW (w odróżnieniu od apletu, który wykonuje się po stronie klienta) i realizuje zlecenia wysyłane od klienta (np. dostęp do bazy danych znajdującej się na serwerze WWW), przesyłając następnie wyniki do klienta.

http://jeeves.javasoft.com/products/java-server/servlets/index.html

Shlaer-Mellor Obiektowa metodyka analizy, modelowania i projektowania systemów informatycznych integrująca własności strukturalne i behawioralne. Patrz: OOSA.

http://www.projtech.com/smmethod/smmethod.html

SI System Informatyczny, System Informacyjny (Information System, IS).

sieciowy model danych (network data model) Ogólnie: model danych, w którym dane posiadają wewnętrzne identyfikatory (lub adresy), zaś związki semantyczne pomiędzy danymi są reprezentowane poprzez powiązania referencyjne lub wskaźnikowe. Struktura danych tworzy więc graf, czyli sieć. (Termin „sieciowy” nie ma tu związku z sieciami komputerowymi.). Najczęściej model sieciowy jest

184


utożsamiany z propozycją grupy DBTG (Data Base Task Group) komitetu CODASYL, opublikowaną w 1971 r. i potem kilkakrotnie modyfikowaną. Propozycja DBTG CODASYL została zrealizowana w wielu systemach; m.in. w polskim systemie RODAN. Model sieciowy w wersji DBTG obarczony był wadami, m.in. obniżeniem poziomu programowania do detali fizycznej organizacji danych. W ostatnich latach nastąpił renesans podstawowych założeń modelu sieciowego w obiektowych bazach danych.

silnik wyszukiwawczy (search engine) Ogólnie, określenie udogodnienia WWW, które pozwala wyszukiwać informacje na stronach WWW lub w dużych bazach danych tekstowych. Przykładami silników wyszukiwawczych są: Yahoo, AltaVista, Hot Bot, Lycos, Sleuth, i inne. Termin ten występuje także w kontekście oprogramowania przeznaczonego do wyszukiwania pełnotekstowego, takiego jak Search’97 (dawniej Topic) firmy Verity.

Simula-67 Język opracowany w 1967 roku, uważany za przodka obiektowości w programowaniu. Został opracowany w Norweskim Centrum Obliczeniowym w Oslo. Wprowadza klasy, podklasy, wirtualne funkcje i aktywne obiekty.

Sina Współbieżny obiektowy język programowania wykorzystujący model CFOM (Composition Filters Object Model).

http://wwwtrese.cs.utwente.nl/sina/

Sintropy (Syntropy) Obiektowa metodyka analizy i projektowania systemów informatycznych.

http://www.objectdesigners.co.uk/syntropy

skalowalność (scalability) Zdolność oprogramowania lub systemu komputerowego do sprawnego działania w warunkach rosnącej liczby użytkowników, zwiększającej się objętości przetwarzanych danych lub rozrostu ilości węzłów sieci komputerowej. Zwrócimy uwagę, że (wbrew popularnej komercyjnej retoryce) pojęcie skalowalności jest relatywne. W istocie, nie jest właściwe mówienie, że system jest „skalowalny” lub „nie skalowalny”, ponieważ zależy to od aspektu, wg którego definiuje się skalowalność, oraz od zakładanego maksimum tego aspektu. Np. wszystkie systemy „są skalowalne” przyjmując, że maksymalna objętość bazy danych wynosi 100 obiektów, oraz wszystkie „nie są skalowalne” przyjmując, że maksymalna objętość bazy danych wynosi 1000 miliardów obiektów.

skład danych (data store) Struktura danych i pakiet procedur do utrzymywania i zarządzania danymi na poziomie fizycznym na dysku lub w pamięci operacyjnej.

skład obiektów (object store, storage domain) Struktura danych i pakiet procedur do utrzymywania i zarządzania obiektami na poziomie fizycznym na dysku lub w pamięci operacyjnej.

skład trwałych obiektów (persistent object store, persistent storage manager, PSM) Struktura danych i pakiet procedur, klas, metod do utrzymywania i zarządzania

185


trwałymi obiektami na poziomie fizycznym. Z punktu widzenia architektury systemu obiektowej bazy danych zarządca trwałymi obiektami znajduje się na najniższym poziomie, stanowiącym wewnętrzny interfejs pomiędzy zewnętrznymi funkcjami bazy danych a pamięcią dyskową.

składnica danych (data mart) Mała wyspecjalizowana hurtownia danych, stanowiąca fragment większej hurtowni danych.

składowanie (back up) Okresowe tworzenie kopii bazy danych, umożliwiających odtworzenie jej stanu w przypadku awarii systemu lub utraty spójności danych.

skojarzenie (coupling) Określenie stopnia powiązania pomiędzy klasami, np. jak często obiekty jednej klasy występują razem z obiektami innej klasy, jak często obiekty jednej klasy wysyłają komunikaty do obiektów innej klasy, itp. Możliwe jest np. mocne skojarzenie (kiedy klasy tworzą pewien nierozerwalny układ), słabe skojarzenie, brak skojarzenia, itd. Patrz też: kohezja.

słaba kontrola typów (weak typing, weak type checking) Brak kontroli typów lub silnie ograniczona kontrola typów.

słabo typowany (weakly typed) Nie podlegający kontroli typów lub podlegający bardzo ograniczonej kontroli typów.

słoń (elephant) Duży, szary ssak z rzędu trąbowców. Patrz też: mrówka.

słownik (dictionary) Ogólnie, miejsce przechowywania lub baza danych terminów oraz ich wyjaśnień dotyczących pewnej dziedziny działalności związanej np. z analizą i projektowaniem SI. Słownik jest podstawowym elementem narzędzi CASE. Prowadzenie słownika jest zalecane w wielu metodach analizy i projektowania, np. w metodzie opartej na przypadkach użycia.

słownik danych (data dictionary) Repozytorium zawierające opis danych (w szczególności opis klas) przechowywanych w bazie danych, które może być używane przez wiele aplikacji. Synonimy: katalog, metadane.

Smalltalk, SmallTalk Obiektowy język programowania opracowany w latach 1976-83 w Xerox Palo Alto Research Center w Kalifornii. Wprowadza klasy, podklasy, wirtualne funkcje, przesyłanie komunikatów, metaklasy. Jak głosi popularny slogan, w Smalltalku wszystko jest obiektem, w szczególności liczby i klasy (ale jak się okazuje, komunikaty, nazwy, itd. nie są obiektami). Istotą sukcesu Smalltalka jest to, że nie jest on tylko językiem, ale także mocnym zintegrowanym środowiskiem programistycznym z atrakcyjnym interfejsem okienkowym. Prostota, możliwość szybkich dynamicznych zmian, elastyczna natura Smalltalka uczyniła go doskonałym narzędziem do szybkiego tworzenia prototypów.

Składnia Smalltalka jest bardzo prosta. Podstawowa konstrukcja ma postać:

obiekt komunikat

186


lub z parametrami:

obiekt komunikat: parametr1 drugiArg: parametr2 ... n-tyArg: parametr-n

gdzie drugiArg,...n-tyArg są nazwami traktowanymi jako składowa komunikatu.

Smalltalk wprowadza dwie pseudozmienne: self i super. Nie posiada wielodziedziczenia i mocnej (statycznej) kontroli typów. Wyrażenia w Smalltalku takie jak 2+3 uważa się za egzemplifikację paradygmatu przesyłania komunikatów: do obiektu 2 wysyła się komunikat + z parametrem 3; w rezultacie dostajemy oczekiwane 5. Ta egzotyka Smalltalka jest przedmiotem kontrowersji.

http://www.parcplace.comhttp://st-www.cs.uiuc.edu/http://XCF.Berkeley.EDU/pub/misc/smalltalk/FAQ/http://www.oti.com/jeffspg/smaltalk.htmhttp://www.rwi.com/smalltalk/smalltalk.htmlhttp://www-laforia.ibp.fr/~fdp/esug-bookmarks.htmlhttp://www-laforia.ibp.fr/~fdp/esug.htmlhttp://www.info.unicaen.fr/~serge/smalltalk80.htmlhttp://www.cs.iastate.edu/~leavens/larchSmalltalk.html

SOM (System Object Model) Technologia udostępniania bibliotek klas oferowana przez IBM. SOM ustala model obiektowy (zbliżony do OMG CORBA) oraz umożliwia dzielenie bibliotek klas niezależnie od języka, w którym zostały one napisane. Podstawowym celem SOM jest współdziałanie obiektowych i nieobiektowych systemów oraz ponowne użycie. SOM jest podstawą dla technologii OpenDoc. SOM jest teraz częścią produktu nazwanego Component Broker.

http://www.software.ibm.com/objects/somobjects/http://www.software.ibm.com/ad/cb/http://www.austin.ibm.com/somservice/faq.html

SOMA Obiektowa metodyka analizy i projektowania systemów informatycznych.

spadek (legacy) Określenie starszych systemów lub aplikacji, które muszą być przystosowane, zaadoptowane lub zintegrowane z nowszymi systemami lub technologiami bez ponoszenia nadmiernych kosztów i nadmiernego czasu wyłączenia z działania.

spadkowy (legacy) Określenie starszego systemu, patrz: spadek.

spaghetti (spaghetti, spaghetti-like) Pejoratywne określenie kodu programu, projektu, diagramu o bardzo skomplikowanej budowie, której logika jest trudna do zrozumienia lub do zdekomponowania. Patrz też: bizantyjski.

specjalizacja (specialization) Abstrakcja dotycząca danych lub obiektów. Termin jest używany w dwóch podobnych znaczeniach: (1) Specjalizacja oznacza relację pomiędzy daną klasą i jej klasą podrzędną; np. klasa Student jest specjalizacją klasy Osoba. (2) Specjalizacja oznacza utworzenie nowej podklasy z danej klasy. Np. mając klasę Osoba można utworzyć jej specjalizację Student. Przeciwieństwem specjalizacji

187


jest generalizacja.

specyfikacja (specification) Ogólnie, abstrakcyjny opis bytu programistycznego (procedury, modułu, klasy, obiektu, bazy danych, itd.) określający reguły jego użycia lub ustalający podstawowe założenia jego implementacji. Specyfikację przeciwstawia się implementacji. Np. specyfikacja klasy oznacza podanie nazw i typów atrybutów wystąpień tej klasy (obiektów) oraz sygnatur przypisanych do nich metod. Specyfikację klasy utożsamia się niekiedy z jej interfejsem lub z jej typem. Utożsamienie to jest mało precyzyjne, gdyż do użycia danej klasy są to często informacje niewystarczające. Wielu autorów zwraca uwagę, że specyfikacja niektórych bytów programistycznych musi włączać także takie elementy jak: określenie zasobów zewnętrznych, z których dany byt korzysta, określenie skutków ubocznych (np. wyjątków), które powoduje, określenie różnorodnych ograniczeń (asercji, warunków wstępnych, warunków końcowych), przy których działa, określenie innych bytów, z którymi dany byt musi współdziałać, itd.

spowodować wyjątek (raise exception) Patrz: podnieść wyjątek.

spójność (consistency) Zgodność danych i procesów przetwarzania z biznesem, dla którego dedykowany jest system. Spójność jest innym pojęciem niż integralność. Np. baza danych jest integralna (formalnie poprawna), jeżeli pewien haker zmniejszy nasze konto przepisując odpowiednią sumę na swoje konto; natomiast zarówno stan bazy danych, jak i proces, który do tego doprowadził, określa się jako niespójność. Niespójność bazy danych może być skutkiem utraty jej integralności, awarii (błędów), braku ochrony przed przypadkowymi działaniami użytkowników, lub braku ochrony przed celowym działaniem osób zmierzających do pozbawienia jej spójności.

sprawdzian (benchmark) Zestaw testów, danych, próbnych zadań, próbnych przebiegów pozwalający ustalić i porównać parametry eksploatacyjne pewnego sprzętu lub oprogramowania. Zwykle testowana jest ogólna wydajność (szybkość działania), średni czas reakcji systemu na wprowadzone zapytanie, średnia bezawaryjność, itd. Istnieje szereg standardowych sprawdzianów, które były używane np. do oceny szybkości działania systemów zarządzania bazami danych. Terminem sprawdzian określa się także konkretną czynność przeprowadzenia takiej próby. Synonim: benczmark.

http://www.sbu.ac.uk/~csse/publications/OOMetrics.htmlhttp://www.comsoft.southern.edu/http://www.cs.city.ac.uk/homes/akmal/biblio.htmlhttp://www.mccabe.com

sprytny wskaźnik (smart pointer) Termin C++ oznaczający wskaźnik, który zachowuje się jak normalny wskaźnik, ale operacje na takim wskaźniku wykorzystują zdefiniowane przez programistę operatory, które przeciążają (overload) wbudowane operatory działające na wskaźnikach. Sprytne wskaźniki są zwykle implementowane poprzez klasy szablonowe. Przykładem zastosowania sprytnych wskaźników są wskaźniki operujące na obiektowej bazie danych, które z punktu widzenia programisty zachowują się tak samo, jak wskaźniki obiektów w pamięci operacyjnej. Innym

188


przykładem jest zadeklarowanie sprytnego wskaźnika uwzględniającego metodę zliczania referencji; w tym przypadku podstawienie sprytnego wskaźnika na pewną zmienną wskaźnikową X oznacza odjęcie 1 od licznika referencji obiektu, na który wskazywała zmienna X i dodanie 1 do licznika obiektu wskazywanego przez sprytny wskaźnik.

SQA (Software Quality Assurance) Zapewnienie jakości oprogramowania.

SQL (Structured Query Language) Najbardziej znany język zapytań, zaimplementowany w większości systemów relacyjnych, bardzo często stanowiący wzorzec odniesienia w literaturze poświęconej obiektowości. Podstawą języka jest zdanie

select <lista wynikowa> from <ciąg nazw tablic> where <warunek>

gdzie select, from, where są słowami kluczowymi. Semantyka tego zdania jest bardzo prosta: oblicza się produkt kartezjański wszystkich tablic wymienionych po from, odrzuca się z niego te wiersze, które nie spełniają warunku po where, następnie każdy pozostały wiersz skraca się (operator projekcji), pozostawiając tylko elementy wymienione w liście wynikowej po select; np.

select Prac.Nazwisko, Dział.Nazwa from Prac, Dział where Prac.Zawód = ‘tokarz’ and Prac.NrDziału = Dział.NrDziału

Tę podstawową konstrukcję wyposażono w szereg dodatkowych możliwości zwiększających moc wyszukiwawczą, m.in. grupowanie, warunki na grupach, zagnieżdżanie, porządkowanie, funkcje zagregowane, funkcje i operatory arytmetyczne, itd. SQL zawiera także operacje tworzenia i usuwania tablic, wstawiania, usuwania i aktualizacji wierszy, oraz inne operacje na środowisku bazy danych. SQL jest używany jako samodzielny język służący do interakcyjnych zapytań i aktualizacji. Jest również używany w wersji zanurzonej (embedded) w klasyczne języki programowania, np. C, Cobol lub PL/1. Istnieją różnorodne mutacje SQL, np. PL/SQL systemu Oracle lub konstrukcje języków czwartej generacji. SQL jest przedmiotem standardu ANSI oraz ISO. Istnieje kilka wersji tego standardu; starsza (SQL-89), obecna (SQL-92) oraz opracowywana (SQL3). SQL jest rozszerzany dla innych modeli, w szczególności dla obiektowych i obiektowo-relacyjnych baz danych. SQL jest także przedmiotem krytyki dotyczącej jego eklektyzmu (powstałego w konsekwencji oddolnego rozwoju), wielu jego kontrowersyjnych rozwiązań, niepełności opisu semantyki, oraz ubóstwa i nieporadności koncepcyjnej (braku ortogonalności, modularności, programistycznych abstrakcji, statycznej kontroli typów, reguł zakresu dla nazw, oraz innych współczesnych środków programistycznych). Konstrukcje składniowe SQL (a raczej niektóre jego syntaktyczne stereotypy) są wykorzystane w języku zapytań OQL wg standardu ODMG (ale podstawy semantyczne OQL i SQL są zasadniczo różne). Patrz też: SQL3, OQL.

http://www.jcc.com/sql_stnd.htmlhttp://www.mcjones.org/System_R/SQL_Reunion_95/

189


SQL3 Nowy standard języka SQL, opracowywany przez ANSI (American National Standard Institute) oraz ISO, następca i rozszerzenie SQL-92. W założeniu, ma to być uniwersalny język programowania dla relacyjnych baz danych z elementami obiektowości. Specyfikacja SQL3 przewiduje wspomaganie dla zdefiniowanych przez użytkownika abstrakcyjnych typów danych (ADT), włączając w to metody, identyfikatory obiektów, podtypy i dziedziczenie, polimorfizm i integrację z językami zewnętrznymi. Pewne usprawnienia zostały także dodane do konstrukcji definiujących tablice (relacje), w szczególności typy wierszy, identyfikatory wierszy oraz mechanizm dziedziczenia. Dodatkowe udogodnienia włączają struktury sterujące i typy parametryzowane; czyni to z SQL3 uniwersalny język programowania do tworzenia, utrzymywania i wyszukiwania trwałych obiektów. Jednocześnie, deklarowana jest kompatybilność „w dół” ze standardem SQL-92. Każda tablica w SQL3 ma predefiniowaną kolumnę (nazwaną IDENTITY), która zawiera identyfikatory jej wierszy. Daje to możliwość używania tych identyfikatorów w innych tablicach, czyli de facto tworzenia powiązań wskaźnikowych. Abstrakcyjne typy danych oznaczają, że wartości przechowywane w ramach tablic użytkownik może skojarzyć z metodami; w takim przypadku wartości te nie są dostępne bezpośrednio, lecz wyłącznie poprzez te metody, co stanowi istotę hermetyzacji. Metody mogą być pisane w SQL3 lub w innych językach. Możliwe jest deklarowanie atrybutów obliczanych (lub inaczej, metod funkcyjnych). Dla dowolnej zadeklarowanej tablicy można zadeklarować podtablicę, która zawiera wszystkie kolumny macierzystej tablicy plus niektóre nowe kolumny. Jak dotąd, rozszerzenia te są redundantne i niezbyt spójne. Standard znajduje się w fazie opracowywania i będzie gotowy przypuszczalnie w połowie roku 1999 (według ostatnich zapowiedzi).

Kontrowersje wzbudza ogromna objętość tego standardu (obecnie przekracza 1100 stron, plus dodatki), spowodowana nagromadzeniem różnych pomysłów bez klarownie wyartykułowanego modelu danych i podstawy ideologiczno-teoretycznej. Sceptycy podkreślają, że jak dotąd w historii żadna specyfikacja języka przekraczająca 1000 stron nie została w pełni zaimplementowana. Równie kontrowersyjne jest podjęcie prac badawczo-rozwojowych w zakresie konstrukcji języka programowania baz danych przez ciało standardyzacyjne, statutowo powołane do innych celów i posiadające inne kompetencje. Istniała koncepcja integracji języków SQL3 i OQL wg standardu ODMG, ale prace integracyjne zostały zaniechane.

http://www.jcc.com/sql_stnd.html

stan (state) Aktualna kombinacja wartości wszystkich zmiennych (trwałych i ulotnych), wartości wszystkich obiektów (trwałych i ulotnych), wartości zmiennych środowiskowych, wartości licznika instrukcji lub aktualny punkt sterowania programu, zawartości stosu środowisk, itd. W skład stanu wchodzą wszystkie byty programistyczne istniejące w czasie wykonania, które w jakikolwiek sposób mogą wpłynąć na wartość dowolnego wyrażenia, zapytania, funkcji, lub wpłynąć na dalszy przebieg sterowania programu. Dość często abstrahuje się od pewnych składników stanu; np. w diagramach STD abstrahuje się od wszystkich składników stanu, z wyjątkiem aktualnego punktu sterowania programu.

stan końcowy (final state) Określenie stanu w diagramach stanów, w którym

190


następuje zakończenie wszelkich akcji. Może być wiele stanów końcowych.

stan obiektu (object state) Aktualna kombinacja wszystkich wartości przechowywanych wewnątrz obiektu; zmiana dowolnej z nich oznacza zmianę stanu obiektu.

stan początkowy (initial state) Określenie stanu w diagramach stanów, w którym rozpoczyna się działanie opisywane tym diagramem. Zwykle jest jeden stan początkowy.

standard faktyczny (defacto standard) Standard przyjęty nieformalnie, w wyniku porozumienia pomiędzy firmami lub w wyniku narzucenia pewnego rozwiązania przez jedną dominującą firmę. Standardem faktycznym są np. standardy OMG (CORBA), UML, ODMG, COM/DCOM, OpenDoc, gdyż nie zostały one zatwierdzone przez odpowiednie instytucje standardyzacyjne.

standard prawny (dejure standard) Standard zatwierdzony przez instytucje standardyzacyjne takie jak ISO i ANSI. Standardem prawnym jest np. ASCII, SQL-92. Będzie nim też (po zakończeniu prac i zatwierdzeniu) SQL3. Należy podkreślić, że standardy prawne nie muszą wpływać na rynek, gdyż nie istnieją przepisy wykonawcze, które obligowałyby wytwórców oprogramowania do ścisłego trzymania się standardów. Z tego powodu różnica pomiędzy standardem prawnym i faktycznym ma znaczenie drugorzędne, bardziej marketingowo-reklamowe niż prawne. Należy również podkreślić, że wskutek ogromnej złożoności tworów technologii informatycznych (np. języków), standardy nie są w stanie wyspecyfikować z absolutną precyzją ich semantyki; dotyczy to np. SQL. Poważnym zarzutem w stosunku do oficjalnych ciał standardyzacyjnych (takich jak ANSI) jest to, że ich polityka nie jest marketingowo neutralna: jest ona preferencyjna dla niektórych firm komercyjnych, ze szkodą dla innych firm; zarzut ten dotyczy np. rozwoju języka SQL3.

Starburst Prototyp systemu obiektowo-relacyjnego zbudowany przez IBM, nie rozpowszechniany na rynku.

statyczna funkcja członkowska (static member function) Termin C++; statycznie wiązana funkcja zdefiniowana w ramach klasy.

statyczna klasyfikacja (static classification) Przypisywanie obiektu do klasy w momencie jego utworzenia, brak możliwości zmiany klasy obiektu.

statyczna kontrola typów (static type checking, static typing) Kontrola typów mająca miejsce podczas czasu kompilacji; patrz też: mocna kontrola typów.

statyczne wiązanie (static binding) Wiązanie nazw występujących w programie, które ma miejsce podczas kompilacji.

statyczny polimorfizm (static polymorphism) Patrz: przeciążanie.

191


STD (State Transition Diagram) Diagram stanów, diagram zmiany stanów; termin OMT i UML.

stempel czasowy (time stamp) Pole zawarte w pewnym bycie programistycznym (obiekcie, transakcji, zdarzeniu, itd.), do którego wpisywany jest bieżący czas wykonania pewnej operacji. Precyzja stempla czasowego powinna umożliwić rozróżnienie dowolnych dwóch operacji na podstawie wartości stempla. Stemple czasowe są używane w różnych technikach, np. w przetwarzaniu transakcji, dla ustalenia kolejności zdarzeń, momentu ostatniej aktualizacji obiektu, itd.

stereotyp (stereotype) W terminologii UML, metaklasyfikacja elementów modelu, np. klas, posiadająca semantyczne konsekwencje. Np. w metodyce Objectory (Jacobsona) wprowadzono trzy rodzaje obiektów: obiekty interfejsu (interface objects), obiekty sterujące (control objects) i obiekty rzeczywiste (entity objects). Te rodzaje obiektów miały swoje odbicie w graficznych ikonach oznaczających klasy. Pomysł ten został w UML uogólniony. Stereotypy mają tam specjalne oznaczenie (ciągi znaków wewnątrz nawiasów « »; np. «control object»). Stereotypy mogą być predefiniowane lub zdefiniowane przez użytkownika. Są one pewnymi oznaczeniami graficznymi na diagramach, których celem jest podniesienie czytelności i jasności diagramów, przystosowanie ich do konkretnej dziedziny zastosowań (np. medycyny, elektrotechniki, telekomunikacji, CAD, itd.), lub przystosowanie do tradycyjnych oznaczeń już stosowanych w tych dziedzinach. Niżej prezentujemy dwa oznaczenia stereotypów dla obiektów Klient: pierwsze w postaci ciągu znaków «aktor», drugie w postaci ikony.

«aktor»

Klient Klient

Oznaczenia stereotypów


sterowanie dostępem (access control) Mechanizm ograniczający dostęp do zasobów, funkcji lub usług systemu dla poszczególnych użytkowników. Niekiedy tym terminem oznacza się także reguły hermetyzacji (np. dostęp do publicznych zasobów dla wszystkich, do chronionych tylko przez klasy podrzędne, zaś do prywatnych tylko przez klasy zaprzyjaźnione).

sterowanie wersjami (version control) Zarządzanie różnymi odmianami danego produktu programistycznego. Wersje mogą dotyczyć mutacji danego produktu związanych z różnymi platformami, na których ma pracować, mutacji danego produktu związanych z różnicami w wymaganiach użytkowników, oraz mutacji danego produktu związanych z jego rozwojem i pielęgnacją. Sterowanie wersjami powinno odwzorować zależność (np. czasową) pomiędzy poszczególnymi wersjami produktu, zarządzać częściami wspólnymi dla wielu wersji, umożliwić równoległą pracę wielu uczestników projektu tworzących nowe wersje, oraz odwzorować zależność wersji od uczestników projektu, klientów, platform, zastosowań, itd. Sterowanie wersjami uważa się za

192


poważny problem technologiczny. Wiele obiektowych baz danych posiada (lub planuje) specjalne środki wspomagające sterowanie wersjami.

sterowany zdarzeniami (event-driven) Określenie techniki programowania (oraz rodzaju języków programowania) polegającej na wyróżnianiu zdarzeń zachodzących w środowisku programu (np. naciśnięcie klawisza Esc, kliknięcie myszką przycisku OK) oraz przyporządkowywaniu tym zdarzeniom sekwencji instrukcji programu, czyli bloków obsługi zdarzeń. Blok obsługi zdarzenia jest uruchamiany w momencie wystąpienia odpowiadającego mu zdarzenia. Programowanie sterowane zdarzeniami stanowi częsty paradygmat w programowaniu wizyjnym oraz w językach czwartej generacji (4GL).

sterta (heap) Obszar w pamięci operacyjnej służący do dynamicznego alokowania i zwalniania pewnych bloków pamięci. W językach programowania (takich jak C/C++) służy ona do alokowania i zwalniania (funkcje malloc i free) wszystkich takich obszarów, których rozmiar lub struktura nie daje się przewidzieć w momencie pisania programu. Sterta powinna być powiązana z automatycznym zbieraniem nieużytków (garbage collection). Brak tego mechanizmu jest przyczyną tzw. wyciekania pamięci (memory leak), tj. zapełniania sterty już niepotrzebnymi, lecz nie usuniętymi obiektami, przez co program znacznie zwalnia pracę (i w końcu zawiesza się). Uważa się, że sterta jest pojęciem zbyt niskiego poziomu, które powinno być wyeliminowane z języków programowania na rzecz dynamicznego powoływania lokalnych zmiennych w procedurach, metodach itd. (które są następnie automatycznie usuwane po zredukowaniu stosu środowisk). Najczęstszymi przyczynami, z powodu których programiści są zmuszenie do używania sterty, jest brak lub ograniczenie w języku typów/wartości masowych (kolekcji), takich jak zbiór, wielozbiór, sekwencja i tablica dynamiczna, oraz brak typów prymitywnych o zmiennym formacie, takich jak string, bitmap, itd.

stos środowisk (environment stack, environmental stack) Struktura danych będąca podstawowym mechanizmem implementacji większości języków programowania (w tym obiektowych). Stos ten składa się z środowisk lub tzw. rekordów aktywacji (activation records). Każdy rekord aktywacji odpowiada pojedynczemu wywołaniu procedury, funkcji lub metody i może zawierać: (1) pola zawierające wartości aktualnych parametrów; (2) pola zawierające wartości wszystkich lokalnych zmiennych lub obiektów deklarowanych (lub tworzonych) w danej procedurze (funkcji, itd.); (3) ślad wołania, czyli miejsce, do którego ma wrócić sterowanie po zakończeniu danej procedury (funkcji, itd.) (4) referencję do obiektu będącego adresatem komunikatu (wiązanie do pseudozmiennych self lub this). Wywołanie danej procedury (funkcji, itd.) oznacza włożenie na wierzchołek stosu jej rekordu aktywacji (i następnie przekazanie sterowania do jej kodu), zaś zakończenie procedury (funkcji, itd.) oznacza usunięcie z wierzchołka stosu jej rekordu aktywacji (i następnie przekazanie sterowania zgodnie ze śladem zawartym w tym rekordzie). Stos środowisk jest podstawowym mechanizmem ustalania zakresu nazw w programie, bezpiecznego alokowania zmiennych lokalnych, technik przekazywania parametrów oraz wiązania nazw występujących w tekście programu. Jest on prostym i uniwersalnym mechanizmem umożliwiającym realizowanie

193


wołań rekurencyjnych. W podejściu stosowym do obiektowych języków zapytań stos środowisk pełni podstawową rolę, jako mechanizm realizujący semantykę podstawowych operatorów, takich jak selekcja, projekcja, nawigacja, nawigacyjne (zależne) złączenie i kwantyfikatory. Stos środowisk występuje zwykle w dwóch postaciach: stosu statycznego, który jest zarządzany podczas kompilacji w celu ustalenia tzw. zakresu leksykalnego (lexical scope) i statycznego wiązania nazw, oraz stosu dynamicznego, który jest zarządzany w czasie wykonania i zawiera rekordy aktywacji. Patrz też: reguły zakresu.

stos wołań (call stack) Patrz: stos środowisk.

strategia od dołu do góry (bottom-up strategy) „Od szczegółu do ogółu”. Strategia projektowania lub konstruowania oprogramowania polegająca na tym, że początkowe decyzje dotyczą szczegółów, następnie szczegóły zamyka się w coraz większe bryły, podnosząc przy tym poziom abstrakcji. Podstawową wadą strategii od dołu do góry jest konieczność ciągłej weryfikacji szczegółowych ustaleń w momencie integrowania szczegółów w większą całość.

strategia od góry do dołu (top-down strategy) „Od ogółu do szczegółu”. Strategia projektowania lub konstruowania oprogramowania polegająca na tym, że początkowe decyzje dotyczą najbardziej ogólnego, abstrakcyjnego poziomu, który następnie precyzuje się poprzez podejmowanie coraz bardziej szczegółowych decyzji. Strategia od góry do dołu jest (często niejawnym) założeniem lub zaleceniem wielu metodyk projektowania i konstruowania oprogramowania.

strategia od środka na zewnątrz (inside-out strategy) „Od rzeczy najważniejszych do całości”. Strategia projektowania lub konstruowania oprogramowania polegająca na tym, że początkowe decyzje koncentrują się na rzeczach najważniejszych, stanowiących o misji projektowanego systemu lub oprogramowania. Po podjęciu tych decyzji kolejno dołącza się do projektu elementy drugorzędne (jakkolwiek również istotne). Strategia od środka na zewnątrz jest zwykle łączona ze strategią od góry do dołu.

strażnik (guard) Określenie warunku boolowskiego, który zapobiega wejściu programu w nieskończoną pętlę. Często jest to również synonim asercji.

Stroustrup, Bjarne Główny twórca i propagator języka C++.

struktura (structure) Termin C++ na oznaczenie zestawu nazwanych wartości; inaczej zapis lub rekord.

struktura klas (class structure) Graf, którego węzłami są klasy, zaś krawędzie wyznaczają związki dziedziczenia. Patrz też: hierarchia klas, krata klas.

struktura obiektów (object structure) Graf, którego węzłami są obiekty, zaś krawędziami powiązania pomiędzy obiektami.

strukturalna równoważność typów (structural type equivalence) Patrz:

194


strukturalna zgodność typów.

strukturalna zgodność typów (structural type conformance) Reguła zgodności typów ustalająca, że typ T1 bytu programistycznego (np. wyrażenia - parametru aktualnego metody) wydedukowany na podstawie reguł wnioskowania o typie (type inference rules) jest zgodny z zadeklarowanym typem T2 dla tego bytu (np. parametru formalnego metody), o ile dowolny element ekstensji typu T1 (czyli wartość zgodna z T1) należy także do ekstensji typu T2. Przykładowo, jeżeli mamy deklaracje:

typedef T1= int;typedef T2 = int;T1 X; T2 Y = 1;

to wówczas (przy strukturalnej zgodności typów) podstawienie X=Y jest typologicznie poprawne, gdyż T1 i T2 są dokładnie tym samym typem. Strukturalną zgodność typów przeciwstawia się nazwowej zgodności typów, przy której podstawienie X=Y jest niepoprawne, gdyż nazwy typów tych zmiennych są różne. W obiektowości przyjmuje się zwykle strukturalną zgodność typów, jakkolwiek prowadzi ona do anomalii i jest koncepcyjnie wątpliwa.

studium osiągalności (feasibility study) Analiza zmierzająca do stwierdzenia, czy dane przedsięwzięcie organizacyjne lub techniczne jest wykonalne przy założonych środkach, celach i ograniczeniach. Synonim: faza strategiczna.

super W terminologii języka Smalltalk pseudozmienna odwołująca się do nadklasy danego obiektu. W odróżnieniu od self, super oznacza, że poszukiwanie metody zaczyna się nie od klasy obiektu, który otrzymał komunikat, lecz od jej nadklasy.

superklasa (superclass) Patrz: nadklasa.

surogat (surrogate) Identyfikator obiektu generowany przy pomocy algorytmu zapewniającego jego unikalność; inaczej identyfikator logiczny.

Sybase Adaptive Server Obiektowo-relacyjny system zarządzania bazą danych.

sygnatura (signature) Specyfikacja metody lub operacji zawierająca: nazwę; nazwy, typy i kolejność jej parametrów (argumentów); typ zwracanego wyniku; nazwy powodowanych wyjątków.

Sygnatura niekiedy zawiera też inne informacje. Sygnatury mają znaczenie dla modelowania pojęciowego (ustalają wejście i wyjście danej metody lub operacji) oraz są wykorzystywane przez mechanizm mocnej kontroli typów. Niżej podajemy sygnaturę metody wystaw_ocenę (która może być np. fragmentem definicji klasy PROFESOR):

boolean wystaw_ocenę( in short jaką,

195


in Wykład z_czego, inout Student komu )raises( student_nie_był_zapisany );

Typ wyniku metody określony jest jako boolean. Metoda posiada dwa parametry wejściowe (in): jaką i z_czego oraz jeden wejściowy i wyjściowy (inout): komu; typy tych parametrów to odpowiednio short, Wykład i Student. Sygnatura ustala, że ta metoda może spowodować wyjątek o nazwie student_nie_był_zapisany.

synchroniczny (synchronous) Określenie procesu lub wątku (przebiegu), który nie działa równolegle z innymi przebiegami. Przebieg synchroniczny blokuje sterowanie programu aż do swojego zakończenia.

synchronizacja (synchronization) Reguły umożliwiające jednoczesną (równoległą) pracę wielu procesów, których celem jest przeciwdziałanie niekorzystnym interferencjom procesów. Synchronizacja ustala podział zasobów krytycznych środowiska komputerowego (np. danych, pamięci operacyjnej, ekranu, klawiatury, czasu procesora, dostępu do linii transmisyjnych, itd.) pomiędzy poszczególne procesy,

syndrom NIH (Not-Invented-Here syndrome) Syndrom „nie wynaleziono tutaj”. Czynnik psychologiczny przeszkadzający ponownemu użyciu. Polega nad tym, że twórcy oprogramowania świadomie lub podświadomie unikają stosowania aktywów ponownego użycia, które nie powstały w ich zespole.

system aktywny (reactive system, active system) System zawierający aktywne reguły, aktywnych agentów lub aktywne obiekty. Patrz też: aktywny SZBD.

system informacji geograficznej (GIS, Geographic Information System) Geograficzny system informacyjny. System przechowujący informację o pewnym terytorium (zwykle mapy o różnej skali, przeznaczeniu, poziomie szczegółowości i typie odwzorowanej informacji), oraz przetwarzający i udostępniający tę informację w postaci wizualnej. GIS jest potencjalnym polem zastosowań technologii obiektowych.

system otwarty (open system) Patrz: otwarty system.

system zarządzania bazą danych, SZBD (database management system, DBMS) System oprogramowania zawierający w szczególności następujące mechanizmy: środki do gromadzenia, utrzymywania i administrowania trwałymi i masowymi

zbiorami danych; środki zapewniające spójność i bezpieczeństwo danych; sprawny dostęp do danych (zwykle poprzez język zapytań); środki programistyczne służące do aktualizacji/przetwarzania danych (API dla

popularnych języków programowania); jednoczesny dostęp do danych dla wielu użytkowników (z reguły, realizowany

poprzez transakcje); środki pozwalające na regulację dostępu do danych (autoryzację); środki pozwalające na odtworzenie zawartości bazy danych po awarii;

196


środki do zarządzania katalogami, schematami i innymi metadanymi; środki optymalizujące zajętość pamięci oraz czas dostępu (np. indeksy); środki do pracy lub współdziałania w środowiskach rozproszonych.

Systemy zarządzania bazami danych często posiadają wiele innych mechanizmów, np. zarządzanie wersjami i danymi temporalnymi, przechowywanie i udostępnianie danych multimedialnych, wygodne (wizyjne) środowiska do tworzenia aplikacji, pomosty do współpracy z innymi systemami, wspomaganie dla perspektyw, zapamiętanych procedur i aktywnych reguł, pakiety statystyczne, pakiety dla przeprowadzania analiz (eksploracji danych), pakiety do tworzenia hurtowni danych, środki udostępniające bazę danych w sieci Internet, itd.

system zarządzania bazą wiedzy (Knowledge Base Management System, KBMS) System, który oprócz pasywnych danych zawiera także reguły, które są automatycznie wykorzystywane przy realizacji zapytań lub zleceń. Różnica pomiędzy systemem zarządzania bazą wiedzy i systemem zarządzania bazą danych jest oparta na powierzchownych, technicznych cechach, takich jak możliwość zastosowania logiki matematycznej w procesie ewaluowania zapytań. Intelektualna lub „naukowa” przewaga baz wiedzy nad bazami danych (sugerowana przez termin „wiedza”) nie istnieje, ponieważ systemy baz danych od dawna posiadają różnorodne elementy, które można uważać za reguły lub ich równoważniki. Termin „baza wiedzy” jest używany przez osoby zajmujące się sztuczną inteligencją, które zwykle nie są świadome obecnego stanu sztuki w bazach danych. Przez to ulegają złudzeniu, że „bazy wiedzy” są wyższym szczeblem intelektualnego zaawansowania. W istocie, siermiężne, mało uniwersalne i nieefektywne metody (takie jak „reguły dedukcyjne”, „klauzule Horna”, „logiki niemonotoniczne”, itd.) oparte na pomysłach teoretycznych są daleko w tyle za obecnym intelektualnym i technicznym zaawansowaniem systemów baz danych.

szablon (template) Termin C++ na oznaczenie dowolnej parametryzowanej metaklasy lub funkcji. Szablon ustala rodzinę klas. Szablony są jedną z form polimorfizmu parametrycznego i wzmacniają możliwości ponownego użycia. Terminem nieco ogólniejszym od szablonu jest generalium (generics).

SZBD (DBMS) Patrz: System Zarządzania Bazą Danych.

szeregowalność (serializability) Kryterium poprawności mechanizmu transakcji. Szeregowalność oznacza, że współbieżne wykonanie transakcji jest poprawne wtedy i tylko wtedy, jeżeli jego efekt jest dokładnie taki sam jak efekt wykonania tych transakcji pojedynczo po kolei. Istnieje matematyczna teoria szeregowalności transakcji; są jednak opinie, że jest ona mało przydatna, ponieważ dla bardziej skomplikowanych mechanizmów transakcji nic nie da się udowodnić (konieczna jest implementacja i symulacja). Istnieją też opinie, że teoria szeregowalności nie obejmuje ważnych przypadków (takich jak usuwanie danych) oraz jest oparta na zbytnio uproszczonych założeniach. W ostatnich 15-tu latach, mimo wielu nowych propozycji mechanizmów przetwarzania transakcji, nie jest szerzej znany w literaturze dowód ich poprawności korzystający z teorii szeregowalności. Szeregowalność funkcjonuje więc w literaturze (również komercyjnej) wyłącznie jako pewien stereotyp, legenda lub

197


„naukowa” dekoracja.

szeregowanie (marshalling) Zamiana komunikatu lub wołania procedury (wraz z argumentami) na sekwencję znaków w odpowiednim formacie, który jest odpowiedni do przesłania poprzez sieć. Odwrotny proces, który odbywa się w odległym węźle, nazywa się rozszeregowanie (unmarshalling). Szeregowanie i rozszeregowanie jest niezbędne w systemach opartych o wołanie odległej procedury (RPC) oraz przy dostępie do odległych obiektów (np. obiektów znajdujących się pod kontrolą pośrednika wg standardu CORBA).

szkielet [1] (framework) Zestaw klas stanowiący abstrakcyjny projekt odpowiadający rozwiązaniu pewnej grupy podobnych problemów. Termin występuje również jako oznaczenie prefabrykowanych bloków oprogramowania, które programista może używać, rozszerzać lub przystosowywać do specyficznych potrzeb tworzonej aplikacji. Szkielety są jednostką ponownego użycia (reuse). Pojęcia szkieletu i pojęcia biblioteki klas są znaczeniowo dość podobne, z tym, że szkielet przewiduje również opis kontekstu w którym dane klasy mogą być użyte.

http://www.eden.com/~msm/fwlisthttp://www.hk-r.se/ide/frameworks/frameworks.htmlhttp://g.oswego.edu/dl/rp/roles.htmlhttp://st-www.cs.uiuc.edu/users/johnson/frameworks.html

szkielet [2] (skeleton) Termin OMG CORBA. Oznacza automatycznie generowany kod w konkretnym języku programowania (np. w C++) po stronie serwera obiektów; jest on tworzony z wyrażenia IDL. Taki szkielet programista musi zapełnić fragmentami kodu stanowiącymi implementację metod wyspecyfikowanych w tym wyrażeniu IDL.

http://www.omg.org

szklana skrzynka (glass box) Patrz: biała skrzynka.

szybka budowa aplikacji (Rapid Application Development, RAD) Patrz: RAD.

szybka budowa prototypów aplikacji (Rapid Application Prototyping, RAP) Patrz: RAP.

ścieżka dostępu (access path) Ogólnie, metoda fizycznego wyszukania żądanych danych. Np. ścieżką dostępu nazywa się metodę polegającą na kolejnym przeglądaniu elementów pewnego zbioru, dostęp poprzez indeks, poprzez tablicę mieszającą, itd.

ścieżka przejścia (traversal path) Sposób przejścia od pewnych obiektów do innych obiektów wykorzystujący hierarchię obiektów oraz powiązania (referencje) między nimi. Np. ścieżka przejścia pomiędzy obiektem x klasy Pracownik i jego szefem może mieć postać: x.PracujeW.Firma.Szef.Pracownik, gdzie PracujeW i Szef są związkami pomiędzy klasami Pracownik i Firma.

środowisko [1] (environment) Termin ogólny, oznaczający sprzęt, oprogramowanie, narzędzia, biblioteki, usługi, infrastrukturę i organizację niezbędne dla działania pewnej

198


aplikacji. W podobnym sensie, środowisko programistyczne obejmuje kompilator pewnego języka programowania, edytory, debuggery, przeglądarki, biblioteki, itd. umożliwiające efektywną produkcję oprogramowania.

środowisko [2] (environment) W terminologii języków programowania, zestaw zmiennych i innych bytów programistycznych, w których jest wykonywany dany program. Środowiska w programach posiadają hierarchię i organizację: wyróżnia się globalne środowisko, zawierające byty programistyczne dostępne dla wszystkich procedur, środowisko bazy danych zawierające obiekty trwałe, środowisko lokalne danej procedury zawierające (zwykle) jej lokalne zmienne lub obiekty oraz parametry, środowisko modułu, środowisko danej klasy lub obiektu zawierające atrybuty (zmienne wystąpienia) i metody, itd. Zarządzanie istnieniem i dostępem do poszczególnych środowisk, ustalanie zakresu nazw występujących w programie oraz wiązanie tych nazw do bytów programistycznych z różnych środowisk jest zwykle oparte o koncepcję stosu środowisk. Terminologia nie jest tu jednoznaczna, niekiedy środowiskiem nazywa się także całość stosu środowisk lub określony jego fragment.

TT

tabela (table) Struktura danych implementowana w relacyjnych systemach baz danych, często nazywana relacją. Tabela składa się z wierszy lub inaczej krotek. Należy zwrócić uwagę, że pomiędzy relacją (w sensie matematycznym) i tabelą występują dość istotne różnice koncepcyjne; w szczególności, w odróżnieniu od relacji tabela jest wyposażona w nazwy kolumn (które niosą informację semantyczną), tabela może zawierać identyczne wiersze, tabela określa porządek wierszy, oraz dostęp do wiersza tabeli może nastąpić poprzez podanie jego numeru. Różnice te powodują, że teorie relacyjne często są nieadekwatne do konstrukcji relacyjnych baz danych i języków zapytań (SQL i jego pochodnych).

tablica (array, table) Często synonim tabeli w systemach relacyjnych. W językach programowania termin ten oznacza strukturę danych tego samego typu, której elementy są indeksowane liczbami całkowitymi (ale nie jest to reguła, istnieją koncepcje indeksowania tablic dowolnymi typami). Dostęp do elementu tablicy następuje poprzez podanie nazwy tablicy oraz indeksu elementu (indeksów elementu, w przypadku tablicy wielowymiarowej).

tablica asocjacyjna (associative table) Określenie tablicy w schemacie relacyjnym, realizującej związek (relationship, association) pomiędzy dwoma lub więcej tablicami. Tablica taka zawiera zwykle klucze obce (klucze główne innych relacji).

tablica dynamiczna (dynamic array) W standardzie ODMG, kolekcja czyli konstruktor typów masowych. Tablica dynamiczna jest podobna do sekwencji, z możliwością dowolnego rozszerzania na końcu oraz z dostępem poprzez indeks wiersza tablicy.

199


tablica pośrednia (indirection table) Tablica niezbędna do implementacji logicznych identyfikatorów obiektów. Wiersze tej tablicy zawierają pary <identyfikator obiektu, adres obiektu> i umożliwiają odszukanie obiektu w przestrzeni pamięci komputera na podstawie jego identyfikatora logicznego. Wierszy tych musi być tyle, ile jest obiektów. Wadą jest objętość tablicy, która (przy długich identifikatorach i długich adresach) byłaby porównywalna z objętością samych obiektów. Drugą wadą jest wydłużony dostęp do obiektów, który musiałby być podzielony na dwa etapy: dostęp do tablicy i dostęp do samego obiektu. Trzecią wadą jest to, że taka tablica stanowiłaby wąskie gardło dla przetwarzania transakcji, gdyż każda transakcja musiałaby odwoływać się do tej tablicy, zaś w przypadku aktualizacji (wstawiania, usuwania lub przesuwania obiektów) jedna transakcja mogłaby zablokować wiele innych transakcji. Czwartą wadą jest to, że taka tablica musiałaby być przedmiotem składowania (back up) i odtwarzania po awarii (recovery), co oczywiście znacznie skomplikowałoby odpowiednie algorytmy i zmniejszyłoby ogólną efektywność systemu. Podane wady kwalifikują w zasadzie pojęcie identyfikatora logicznego jako niezbyt rozsądne. Jest to zasadniczy powód, dla którego systemy O2, Objectivity/DB i Exodus nie stosują logicznych identyfikatorów. Niemniej wielu autorów uważa identyfikatory logiczne za niezbędną cechę obiektowych baz danych. Systemy Versant, GemStone i ObjectStore stosują logiczne identyfikatory; system Itasca (Orion) stosuje rozwiązanie kompromisowe.

TAPOS (Theoretical And Practial Aspects of Object Systems) Czasopismo z zakresu systemów obiektowych.

technika modelowania obiektów (Object Modeling Technique, OMT) Patrz: OMT.

teoretyczny masochista (theoretical masochist) Termin J. Rumbaugha oznaczający osobę próbującą (bezskutecznie) stosować w inżynierii oprogramowania metody matematyczne.

teoretyczny terrorysta (theoretical terrorist) Osobnik dość utytułowany i wpływowy, którego kariera była oparta na rozwijaniu i propagowaniu zmatematyzowanych teorii (patrz: pseudoteoria). Teorie te nazywa matematycznymi podstawami informatyki i jest przekonany o ich fundamentalnej roli w rozwoju (mimo braku faktów potwierdzających i mimo ewidentnych faktów przeczących tej tezie). Informatykę uważa za jeden z działów matematyki. W jego wyobrażeniu informatyka rozwija się harmonijnie od wielkich matematycznych teorii, poprzez twierdzenia udowadniane w ciszy naukowych gabinetów, poprzez biura projektowe, gdzie zwyczajni rzemieślnicy (nie naukowcy!) przerabiają te twierdzenia na projekty oprogramowania, wreszcie poprzez wytwórców oprogramowania, które zamieniają je w Windows, Corela, UNIXa, Javę, Oracle i Netscape.

Najdłuższy napisany przez niego program ma rozmiar 5-ciu linijek; dla teoretycznego terrorysty jest on wystarczający, aby nauczać, jak należy budować programy mające 5 milionów linijek. W tym celu pisze podręczniki zatytułowane „Podstawy inżynierii oprogramowania”, „Algebraiczna specyfikacja dla programistów”, itp., gdzie umieszcza odpowiednie pojęcia matematyczne, definicje i twierdzenia (patrz:

200


pseudoteoria). Po ich napisaniu uważa się za Wybitnego Specjalistę z zakresu inżynierii oprogramowania (traktowanej oczywiście jako dyscyplina naukowa, a nie bezładna paplanina różnych DeMarków, Yordonów, czy Boochów). Jako Wybitny Specjalista znajduje miejsce w komitetach, radach i redakcjach, gdzie podejmowane są ważne decyzje. Po nich inżynieria oprogramowania na danym terenie staje się naukowo słuszna, co oznacza, że nie ma na nim miejsca dla tych, którzy splamili się napisaniem programu dłuższego niż 5 linijek („...instytucje naukowe nie mogą przejmować roli biur projektowych...”), zaś stan inżynierii oprogramowania rzeczywistej (w odróżnieniu od urojonej) po 15-tu latach od tych decyzji zaczyna przypominać Saharę, szczególnie w zakresie dydaktyki i samodzielnej kadry naukowej.

Teoretyczny terrorysta przybiera często postawę misjonarza grzmiącego z wysokiej ambony na stojący w dole ciemny informatyczny lud, przestrzegając go przed złem płynącym z zaniedbania metod matematycznych. Nie zniża się do tego, aby zejść z ambony na implementacyjną ziemię i osobiście pokazać na dużym projekcie, jak tego rodzaju metody należy stosować w praktyce (patrz: teoretyczny masochista). Na obronach prac magisterskich, doktoratów i habilitacji teoretyczny terrorysta daje się poznać jako mistrzowski wykonawca tzw. sztuczki z trupem: w pewnym momencie wyciąga znienacka jakiegoś teoretycznego trupa (np. trupa teorii informacji, maszyny Turinga, rachunku lambda, itd.) i potrząsa złowieszczo zakurzonym zewłokiem przed zbielałym z przerażenia kandydatem.

teoretyk (theoretician) Określenie osoby budującej zmatematyzowane teorie, w szczególności teorie dotyczące obiektowości. W informatyce jest to ostatnio określenie pejoratywne (patrz: pseudoteoria, teoretyczny terrorysta, teoretyczny masochista) oznaczające osobę pozbawioną właściwych kompetencji w zakresie informatyki rzeczywistej, budującą scholastyczne, nikomu niepotrzebne pseudoteorie, których jedynym autentycznym celem są kariery naukowe (doktorat, habilitacja, profesura, następny artykuł na następną konferencję). Obecny wizerunek teoretyka jest konsekwencją ignorowania przez niektóre osoby ze środowiska akademickiego osiągnięć informatyki rzeczywistej, i w miejsce tego, generowanie koncepcji teoretycznych, których naukowy i intelektualny potencjał jest podważalny, zaś wpływ na obecną i przyszłą informatyczną rzeczywistość jest pomijalny. Rodzi to ogromne straty potencjału intelektualnego, szczególnie groźne dla krajów biedniejszych, takich jak Polska. Angażowania się części kadry naukowej w rozwój pseudoteorii rodzi też duże frustracje, również wśród samych teoretyków. Można ich uważać za ofiary wieloletniego mitu „matematycznych podstaw informatyki”, który sami stworzyli. Frustracje te mają niekiedy skutek pozytywny; przykładem jest D. Knuth, teoretyczny gigant, który zdobył również sławę jako twórca systemu TEX, czy też F. Bancilhon, znakomity teoretyk, który w pewnym momencie zarzucił teorie na rzecz stworzenia pionierskiego obiektowego systemu zarządzania bazą danych O2.

W pozytywnym sensie (który należałoby w informatyce przywrócić) teoretyk jest osobą budującą użyteczne teorie na podstawie wieloletnich doświadczeń praktycznych, analizy i syntezy wielu pojęć, języków, systemów, metod o bezpośrednim znaczeniu praktycznym. Utrwalony obecnie podział na „teoretyków” (czyli tych, którzy nie posiadają kompetencji praktycznych i używają matematyki dla produkcji scholastycznych, bezużytecznych tworów) i „praktyków” (czyli tych, którzy nie używają matematyki, ale są kompetentni i produkują twory użyteczne) należy odrzucić

201


jako błędny i szkodliwy.

terabajt (terabyte) W powszechnym rozumieniu - 1 000 000 000 000 (1000 miliardów) bajtów. W informatyce obowiązuje atawistyczny stereotyp, zgodnie z którym terabajt jest to 240, czyli 1 099 511 627 776 bajtów. Różnica ok. 10% może być źródłem nieporozumień i konfliktów.

Theta Obiektowy język programowania zaimplementowany w obiektowym systemie zarządzania bazą Thor. Posiada mocną statyczną kontrolę typów i automatyczne zbieranie nieużytków.

http://www.pmg.lcs.mit.edu/Theta.html

this Wskazanie adresata komunikatu (ten). Patrz: self.

Thor Obiektowy system zarządzania bazą danych.http://www.pmg.lcs.mit.edu/Thor.html

three amigos Trzej przyjaciele. Często spotykane określenie twórców UML: G. Boocha, I. Jacobsona oraz J. Rumbaugha.

TID (Tuple IDdentifier) Patrz: identyfikator krotki.

tłusty klient (fat klient) Patrz: mocny klient.

TOOLS (Technology of Object-Oriented Languages and Systems) Cykliczna konferencja z zakresu obiektowości, organizowana przez Interactive Software Engineering, firmę zajmującą się rozwojem i promocją języka Eiffel.

tożsamość (identity) Tożsamość obiektu oznacza, że obiekt istnieje i jest odróżnialny od innych obiektów niezależnie od jego aktualnego stanu (wartości atrybutów), który może się zmieniać. Obiektowość nie zakłada konieczności określenia takiego atrybutu obiektu (lub kombinacji atrybutów), który identyfikuje go w sposób unikalny (czyli tzw. „klucza głównego” (primary key), znanego z relacyjnego modelu danych). Tożsamość obiektu jest kategorią filozoficzną, która nie jest wiązana z jakimkolwiek zestawem atrybutów obiektu lub jego aktualnym stanem. Możliwe są dwa różne obiekty o identycznych wartościach atrybutów. Praktycznie, tożsamość oznacza istnienie unikalnego wewnętrznego (nic nie mówiącego dla użytkownika) identyfikatora obiektu, który nie ulega zmianie podczas życia obiektu. Tożsamość obiektu jest niezależna od jego lokacji w świecie rzeczywistym lub w przestrzeni adresowej komputera. Czasami to założenie kłóci się z innymi własnościami, np. z koniecznością jednoczesnego pamiętania wielu wersji czasowych tego samego obiektu lub z wymaganiami dotyczącymi wydajności. Patrz też: mrówka.

transakcja (transaction) Jednostka przetwarzania baz danych posiadająca własności określane skrótem ACID (Atomicity, Consistency, Isolation, Durability): atomowość, spójność, izolacja, trwałość: Atomowość oznacza, że transakcja wykonuje wszystkie czynności, które się na nią

składają, albo też nie wykonuje żadnej z nich. Oznacza to, że po zerwaniu

202


transakcji musi być odtworzony stan sprzed jej działania. Warunek spójności wymaga, aby transakcja pozostawiła bazę danych w spójnym

stanie (chociaż w trakcie transakcji stan ten może być chwilowo niespójny). Izolacja oznacza, że poszczególne transakcje są całkowicie niezależne: przebieg

danej transakcji nie wpływa na przebieg jakichkolwiek innych transakcji (i oczywiście odwrotnie).

Trwałość (trwanie) oznacza, że po potwierdzeniu (commit) transakcji, jej skutki w zakresie zmiany stanu bazy danych są trwałe i nie mogą być zniszczone przez jakiekolwiek zdarzenia (np. poprzez awarię zasilania).

Transakcja może być zerwana (abort); w takim przypadku wszelkie jej skutki są odwracane do stanu sprzed transakcji. Ta własność implikuje konieczność prowadzenia dziennika (log), w którym są zapisywane stany danych przed i po operacjach wykonywanych przez transakcję. W przypadku zerwania, dziennik jest czytany od tyłu celem przywrócenia stanu sprzed transakcji; ta czynność nazywa się odwracanie (rollback). Transakcje zapewniają zwiększenie niezawodności systemu i spójności danych, szczególnie w sytuacji jednoczesnego dostępu wielu użytkowników do tej samej bazy danych. Istnieje wiele technik przetwarzania transakcji, które zwykle dzieli się na pesymistyczne (wymagające zablokowania dostępu do przetwarzanej przez transakcję danej dla innych transakcji) oraz optymistyczne (nie wymagające blokowania; ich zastosowanie jest jednak bardzo ograniczone z powodów zarówno technicznych jak i koncepcyjnych). Obiektowość implikuje nowe techniki przetwarzania transakcji, np. tzw. hierarchiczne blokowanie.

transakcja projektowa (design transaction) Termin oznaczający długą i/lub zagnieżdżoną transakcję.

tranzytywne domknięcie (transitive closure) Termin o rodowodzie matematycznym. Tranzytywne domknięcie R* relacji R jest definiowane następująco:

x R y x R* yx R y and y R* z x R* z

tj. relacja R* zawiera parę <x,y>, jeżeli istnieje dowolnej długości ciąg par <x,a1>, <a1,a2>, <a2,a3>,... , <an,y> należących do R. Typowe zadanie realizowane poprzez tranzytywne domknięcie jest następujące: Niech R reprezentuje drzewo genealogiczne (R zawiera pary <rodzic, potomek> ); znaleźć wszystkich potomków (bezpośrednich lub pośrednich) Kowalskiego.

Tranzytywne domknięcie znalazło zastosowanie w językach zapytań jako istotny operator realizujący pewien typ przetwarzania (patrz: BOM). Często też tranzytywne domknięcie jest argumentem na rzecz tezy, że algebra relacji (w czystej postaci) nie jest dostatecznie uniwersalna: żadna kombinacja operatorów algebry relacji nie jest w stanie osiągnąć efektu osiąganego przez tranzytywne domknięcie. Istnieją uogólnienia tego operatora, np. w standardzie SQL3 oraz w języku SBQL systemu Loqis. Tranzytywne domknięcie jest szczególnym przypadkiem operatora punktu stałego (fixed point operator), tj. operatora realizowanego przez równanie stałopunktowe X = Q(X), gdzie X jest zmienną zwracającą wynik zapytania (np. tabelę), zaś Q jest pewnym zapytaniem zależnym od X. Równanie takie oblicza się podstawiając na początku na X wynik pusty,

203


a następnie podstawiając na X wynik Q(X) aż do momentu, kiedy poprzednia i następna wartość X są identyczne (jest to tzw. najmniejszy punkt stały). Operator punktu stałego ma związek z programowaniem w logice i koncepcją dedukcyjnych baz danych (określaną jako Datalog). Efekt uzyskiwany przez tranzytywne domknięcie można także osiągnąć poprzez rekurencyjne procedury (lub perspektywy) zdefiniowane w języku zapytań.

treść metody (method body) Patrz: ciało metody.

trwała zmienna (persistent variable) Zmienna, która ma wszystkie własności zmiennej języka programowania, ale zachowuje swoją wartość pomiędzy kolejnymi uruchomieniami programu.

trwałość (persistence) Cecha danej, zmiennej lub obiektu oznaczająca zachowywanie jej wartości dłużej niż czas pojedynczego uruchomienia programu (zwykle dowolnie długo). Trwałość jest podstawową własnością danych przechowywanych w bazie danych.

trwałość poprzez dziedziczenie (persistence through inheritance) Założenie organizacji obiektowej bazy danych, w której cecha trwałości jest cechą definiowanej klasy oraz wszystkich jej podklas. Wadą tej koncepcji jest ograniczenie ortogonalności: w szczególności, nie można zdefiniować metod działających identycznie na trwałych i ulotnych danych, co narusza zasadę ortogonalnej trwałości.

trwałość poprzez osiągalność (persistence through reachability, PTR) Organizacja obiektowej bazy danych ustalająca, że każdy obiekt osiągalny z trwałego obiektu (np. podobiekt, obiekt powiązany poprzez wskaźnik) jest również trwały. Zakłada się istnienie tzw. trwałych korzeni (persistent roots), czyli trwałych obiektów danych z definicji. Trwałość poprzez osiągalność implikuje pewne ograniczenia, np. trwały obiekt nie może mieć nietrwałych atrybutów i nie może zawierać wskaźnika prowadzącego do nietrwałego obiektu. Większość obecnych obiektowych systemów zarządzania bazą danych przyjmuje założenie trwałości poprzez osiągalność (w szczególności systemy zbudowane w oparciu o standard ODMG). Trwałość poprzez osiągalność nie jest mocnym ograniczeniem, szczególnie w systemach z mocną kontrolą typów. Można jednak wyobrazić sobie system, w którym cecha trwałości jest całkowicie ortogonalna w stosunku do jakichkolwiek innych cech, np. system, w którym trwały obiekt może mieć ulotne atrybuty. W istocie, taką możliwość zapewnia wiązanie do języka Java w standardzie ODMG, mimo zapewnień, że standard ten jest oparty na koncepcji trwałości poprzez osiągalność.

trwały identyfikator (persistent identifier) Unikalny identyfikator obiektu, który nie zmienia się podczas całego życia obiektu.

trwały korzeń (persistent root) Trwały obiekt stanowiący początek hierarchii lub sieci trwałych obiektów w koncepcji określanej jako „trwałość poprzez osiągalność”.

trwały obiekt (persistent object) Obiekt przechowywany w bazie danych; obiekt nie zmieniający swego stanu pomiędzy kolejnymi uruchomieniami programu

204


aplikacyjnego.

trwanie (durability) Własność transakcji mówiąca o tym, że po potwierdzeniu transakcji jej skutki są trwałe i nie mogą być odwrócone poprzez jakikolwiek przypadek, np. zanik zasilania komputera. Patrz też: transakcja.

tryger (trigger) Inaczej wyzwalacz. Patrz: aktywne reguły.

trzeci manifest (The Third Manifesto) Patrz: manifest.

trzecia postać normalna (3NF, Third Normal Form) Relacja znajduje się w trzeciej formie normalnej, jeżeli nie zawiera tranzytywnych zależności funkcyjnych, tj. takich trzech atrybutów A, B i C, że zachodzi A B oraz B C. Tranzytywne zależności funkcyjne zwykle oznaczają redundancję w danych i są powodem anomalii aktualizacyjnych. Dla przykładu, niech relacja PRACOWNIK zawiera atrybuty NR_PRAC, NR_DZIAŁU oraz NAZWA_DZIAŁU. Jest oczywiste, że NR_DZIAŁU jest zależny funkcyjnie od NR_PRAC, (czyli NR_PRAC NR_DZIAŁU), zaś NAZWA_DZIAŁU jest funkcyjnie zależna od NR_DZIAŁU (czyli NR_DZIAŁU NAZWA_DZIAŁU). Zatem relacja ta nie jest w trzeciej formie normalnej, gdyż istnieją w niej tranzytywne zależności funkcyjne. Oczywista jest też redundancja, gdyż NAZWA_DZIAŁU będzie powtarzana dla wszystkich pracowników pracujących w tym dziale. Proces eliminacji tego rodzaju niekorzystnych własności jest nazwany normalizacją. W przypadku A B, B C oznacza on wyeliminowanie atrybutu C z danej relacji (projekcję) oraz utworzenie nowej relacji zawierającej atrybuty B i C. (W naszym przykładzie, utworzenie nowej relacji DZIAŁ z atrybutami NR_DZIAŁU i NAZWA_DZIAŁU.) Trzecia postać normalna jest pojęciem ważnym, ale oczywistym. Nawet średnio rozgarnięty projektant intuicyjnie unika sytuacji, w których relacja nie jest w trzeciej formie normalnej. Z tego powodu, wbrew początkowym nadziejom twórców modelu relacyjnego, formalizacja tego pojęcia jest raczej drugorzędna dla praktyki projektowania baz danych.

trzywarstwowa architektura (three-tiered architecture) Patrz: architektura trzywarstwowa.

tworzenie wystąpienia (instantiation) Tworzenia nowego obiektu na podstawie szablonu lub wzorca, którym jest klasa lub typ. Niekiedy termin ten oznacza również utworenie klasy poprzez określenie parametru dla klasy parametryzowanej lub szablonu (template).

typ (type) Specyfikacja rodzaju wartości, które może przybierać dany byt programistyczny (zmienna, obiekt, parametr); specyfikacja budowy obiektu; specyfikacja interfejsu procedury lub metody, itd. Typ ogranicza budowę lub ustala zewnętrzny interfejs bytów programu lub bazy danych oraz ogranicza kontekst, w którym może on być użyty w tekście programu. Zasadniczym celem typów jest kontrola formalnej poprawności programów („bezpieczeństwo typologiczne”). W językach z mocnym typowaniem (strong typing), np. w językach Pascal i Modula-2, każdy deklarowany byt programistyczny musi być obowiązkowo wyposażony w deklarację

205


typu. Poprzez tę deklarację programista wyraża swoje oczekiwania co do roli tego bytu w programie. Te oczekiwania są następnie sprawdzane we wszystkich tych miejscach programu, gdzie występuje odwołanie do tego bytu. Np. określając typ zmiennej X jako integer programista ustala, że ta zmienna ma przechowywać wartości całkowite. Dzięki temu możliwe jest sprawdzenie, czy wszystkie odwołania do tej zmiennej w programie mają kontekst, w jakim może być użyta wartość całkowita. Typologiczna kontrola poprawności programów okazała się cechą niezwykle skutecznie eliminującą błędy popełniane przez programistów. Typom przypisuje się także inne role, wśród nich określenie reprezentacji wartości wewnątrz pamięci komputera oraz wspomaganie modelowania pojęciowego.

typ abstrakcyjny (abstract type) Patrz: abstrakcyjny typ danych.

typ atrybutu (attribute type) Wyrażenie pewnego języka programowania dotyczące wartości atrybutu obiektu, które ustala (często implicite) format, długość, zakres wartości, sposób reprezentacji oraz dopuszczalne operatory.

typ kompozytowy (composite type) Typ nieelementarny; typ zdefiniowany przy pomocy konstruktorów typów (np. struct) i innych typów.

typ konkretny (concrete type) Termin występujący w kontekście abstrakcyjnych typów danych, eksponujący fakt, że pojęcie typu (w systemach z mocną kontrolą typów) jest różne od pojęcia abstrakcyjnego typu danych. Typ konkretny przeciwstawia się wtedy typom abstrakcyjnym. Patrz też: typ.

typ konstruowany (constructed type) W standardzie OMG CORBA, konstruktor typów struct, union i enum, umożliwiający konstruowanie bardziej złożonych wyrażeń typologicznych z wyrażeń prostszych.

typ masowy (bulk type) Typ wartości posiadających potencjalnie dużą, nieznaną z góry i nieograniczoną liczbę elementów. Zwykle za typ masowy uważa się sekwencję (sequence) - rozszerzalny ciąg elementów o dowolnej długości, dynamiczną tablicę (dynamic array) - struktura podobna do sekwencji, z dostępem poprzez indeks, wielozbiór (multi-set, bag) - rozszerzalna kolekcja elementów, bez określonej kolejności, z ewentualnymi powtórzeniami, oraz zbiór (set) - rozszerzalna kolekcja elementów, bez określonej kolejności, bez powtórzeń wartości.

typ nieprzejrzysty (opaque type) Typ o określonej nazwie, którego budowa nie jest udostępniona (jest ukryta) dla użytkownika. Np. użytkownik może wiedzieć, że pewien obiekt jest typu Video, ale nie musi wiedzieć, że ten typ jest strukturą zawierającą takie atrybuty jak Długość, Format, SekwencjaBitów, MetodaKompresji, itp. Nieprzejrzystość typu może być częściowa; wtedy użytkownik widzi niektóre składniki typu, pozostałe zaś są ukryte. Przykładem języka z nieprzejrzystymi typami jest Ada95.

typ parametryzowany (parameterized type) Typ parametryzowany pewnym parametrem, zwykle typem lub wartością. Np. typ set (zbiór) jest parametryzowany typem elementu zbioru (np. set(integer)), zaś typ array jest parametryzowany wartością

206


będącą rozmiarem tablicy.

typ pochodny (derived type) Termin C++, oznaczający dowolny typ utworzony na podstawie typu bazowego. W Ada95 termin ten oznacza dowolny typ utworzony na podstawie innego typu. Synonim: typ potomny.

typ podstawowy (basic type) Patrz: typ prymitywny.

typ potomny (child type) Patrz: typ pochodny.

typ prymitywny (primitive type) Typ charakteryzujący wartość, która jest niepodzielna (nie zawiera bardziej prymitywnych wartości). Typy prymitywne w danym języku są wbudowane, lub można je utworzyć na podstawie prostych operacji na typach wbudowanych. Przykładami typów prymitywnych są: unsigned, short, integer, real, char, date, money, float, double, long integer, itd. W niektórych językach typem prymitywnym są również string, decimal, bitmap i inne. Synonim: typ podstawowy.

typ referencyjny (reference type) Typ, którego wartościami są referencje do obiektów, krotek, itd. W SQL3 wartość typu referencyjnego może być zapamiętana w tablicy i następnie użyta jako bezpośrednia referencja (wskaźnik) do krotki (wiersza) w innej tablicy. W efekcie możliwe jest tworzenie powiązań pomiędzy obiektami, tak jak w modelach obiektowych. Zwrócimy uwagę, że w wielu językach i systemach (np. w standardzie ODMG) utożsamia się typ obiektu z typem referencji do obiektu, co z jednej strony daje pewne uproszczenie języka, zaś z drugiej strony prowadzi do niejednoznaczności semantycznych.

typ rozróżniony (distinct type) Typem rozróżnionym jest typ uzyskany poprzez nadanie nowej nazwy dla już zdefiniowanego typu. Nowy typ jest traktowany jako oddzielny (nieporównywalny) typ. Koncepcja typów rozróżnionych jest oparta na nazwowej zgodności typów. Np. w SQL3 można podać następujące deklaracje:

CREATE DISTINCT dolar_usa AS DECIMAL(9,2)CREATE DISTINCT polski_zl AS DECIMAL(9,2)

Po takiej deklaracji porównanie wartości typu dolar_usa z wartością typu polski_zl powoduje błąd typu. W obiektowości typy rozróżnione (i nazwowa zgodność typów) zwykle nie są rozpatrywane ze względu na balast koncepcji teoretycznych, takich jak zasada zamienialności lub pewne formy polimorfizmu. Należy jednak podkreślić, że typy rozróżnione i nazwowa zgodność typów są bardziej koncepcyjnie spójne, niż powszechnie przyjmowana strukturalna zgodność typów.

typ szablonowy (template type) Zwykle chodzi o konstruktor typów masowych, takich jak set, sequence, bag, array. Patrz też: klasa szablonowa.

typ wbudowany (built-in type) Typ predefiniowany w danym języku programowania (np. int, float, char, itd.), stanowiący nieodłączną jego część, skojarzony z predefiniowanymi operacjami (+, =, itd.).

207


typ wyliczeniowy (enumeration type) Typ, którego wartości są explicite wyliczone; np. typ boolean = {true, false} lub typ Zawód = {asystent, adiunkt, docent, profesor}.

UU

UFO [1] (United Functions and Objects) Język programowania łączący paradygmat obiektowy z funkcjonalnym, przeznaczony dla równoległych obliczeń. Zrealizowany na Uniwersytecie w Manchesterze.

UFO [2] (Unidentified Flying Object) Niezidentyfikowany obiekt latający. Istnieją kontrowersje co do tego, czy jest to obiekt rzeczywisty, czy też urojony.

ukrywanie informacji (information hiding) Zasada, zgodnie z którą programista lub użytkownik pewnego składnika oprogramowania może go poprawnie zastosować bez znajomości jego budowy lub implementacji. Zasada ta oznacza, że wszelkie detale pewnego bytu programistycznego, które są nieistotne dla jego użytkowników, powinny być ukryte. Wielu autorów uważa ukrywanie informacji za synonim hermetyzacji (encapsulation). Niektórzy z autorów uważają ukrywanie informacji i hermetyzację za pojęcia różne. Ich zdaniem, hermetyzacja niekoniecznie oznacza ukrywanie informacji, lecz zgromadzenie wielu bytów wewnątrz pewnej granicy, udostępnienie ich poprzez dobrze zdefiniowany interfejs i wydzielenie abstrakcyjnej specyfikacji tego interfejsu. Jest natomiast prawdą, że hermetyzacja sprzyja ukrywaniu informacji.

ulotny (transient, volatile, temporary) Przeciwieństwo trwałego; określenie lokalnego lub chwilowego obiektu, który przestaje istnieć w momencie zakończenia bloku, procedury, funkcji, metody lub programu. Istnieją dwa rodzaje obiektów ulotnych: Obiekty czasowe powoływane na przeciąg całej sesji użytkownika i usuwane po jej

zakończeniu; Obiekty lokalne powoływane po wejściu sterowania do ciała bloku, procedury,

metody lub funkcji, i automatycznie usuwane w momencie, kiedy sterowanie opuszcza to ciało. Takie obiekty są przechowywane w sekcji stosu środowisk właściwej dla danego wołania danej procedury, funkcji metody, itd. Niekiedy (np. w implementacjach języka Java) obiekty ulotne są przechowywane na stercie, zaś odpowiednia sekcja stosu zawiera referencje do tych obiektów.

UML (Unified Modeling Language) Zunifikowany język do modelowania, zawierający pojęcia i notacje służące do obiektowej analizy, modelowania i projektowania. UML został opracowany przez czołowych metodologów, G.Boocha, I.Jacobsona, J.Rumbaugha, i jest rozpowszechniany przez firmę Rational Inc. Jest on następcą OMT, metodyki Boocha oraz metodyki opartej na przypadkach użycia (use cases) Jacobsona. UML jest lansowany jako standard notacyjny, również jako fragment standardu OMG. W notacji UML definiowane są następujące diagramy: Diagramy przypadków użycia (use cases). Są one podstawą metodyki Objectory.

208


Ich głównym celem jest odwzorowanie funkcji projektowanego systemu w taki sposób, w jaki będą je widzieć jego użytkownicy. W metodykach opartych na UML przypadkom użycia przypisuje się szczególne znaczenie środka napędzającego cały proces rozwoju systemu.

Diagramy klas (class diagrams). Są one odmianą dość klasycznych diagramów encja-związek (entity-relationship). Zostały praktycznie bez większych zmian przejęte z OMT. Wprowadzone są rozszerzenia poprawiające czytelność diagramów i przystosowujące je do konkretnej dziedziny zastosowań (np. stereotypy i odpowiadające im ikony). Odmianą diagramów klas są diagramy pakietów (package diagrams).

Diagramy odwzorowujące dynamiczne własności systemu (behavior), w tym:Diagramy sekwencji (szczególny przypadek diagramów interakcji): pokazanie

kolejności komunikatów przesyłanych pomiędzy obiektami dla pewnej sytuacji, np. przypadku użycia.

Diagramy kolaboracji (inaczej diagramy współpracy; szczególny przypadek diagramów interakcji): podobne do diagramów sekwencji, ale z jednoczesnym odwzorowaniem statycznej struktury obiektów.

Diagramy stanów: odwzorowanie istotnych stanów (w których może znaleźć się proces przetwarzania) oraz przejść pomiędzy tymi stanami.

Diagramy aktywności: diagramy przepływu sterowania (flowcharts) uzupełnione o proste środki odwzorowania równoległych procesów.

Diagramy implementacyjne, w tym:Diagramy komponentówDiagramy rozprzestrzeniania (deployment)

Zdaniem autorów UML, diagramy te zapewniają wymaganą mnogość perspektyw systemu podczas jego analizy i rozwoju.

http://www.rational.com/uml/http://www.awl.com/cp/uml/uml.htmlhttp://www.rational.com/HyperMail/otughttp://www.rational.com/ot/uml/faq.html

unia (union) Typ struktury, rekordu lub obiektu, który może mieć alternatywnie dwa lub więcej zestawów atrybutów. Przykładowo, jeżeli właścicielem samochodu może być osoba lub firma, to obiekt Samochód może posiadać alternatywnie albo atrybut NazwiskoWłaściciela, albo atrybut WłasnośćFirmy. Unie są również zwane wariantami. Z unią może być związany dyskryminator (discriminator), tj. atrybut, którego wartość określa, z którym wariantem mamy do czynienia. Może też nie mieć dyskryminatora; wówczas odpowiedzialność za rozróżnianie wariantów spada na programistę (tak jest np. w C i C++). Brak dyskryminatora w unii podkopuje koncepcję mocnej kontroli typów i stwarza okazję do bardzo trudnych błędów (np. jeżeli programista zastosuje selektor atrybutu do niewłaściwego wariantu, wówczas wynik jest nieprzewidywalny i zależy od reprezentacji obiektu). Z kolei unie z dyskryminatorem zmuszają do oddelegowania sprawdzania poprawności typologicznej do czasu wykonania, co ma konsekwencje dla wydajności. Unie stwarzają poważny problem dla języków zapytań; jak dotąd nie istnieje prawdopodobnie koncepcja języka zapytań uwzględniającego unie. (Uwzględnienie tej własności wymagałoby przeniesienia części informacji

209


zawartej w typie (np. nazw atrybutów) do wnętrza reprezentacji obiektów, co miałoby konsekwencje zarówno dla objętości tej reprezentacji, jak i mechanizmów wiązania/dostępu.) Unie z dyskryminatorem są własnością IDL wg standardu CORBA i są własnością ODL wg standardu ODMG, ale nie są traktowane w pozostałych częściach tego standardu, prawdopodobnie wskutek trudności ze spójnym opanowaniem tej własności we wszystkich konstrukcjach. Unie mają ostatnio złą prasę w obiektowej literaturze. Zostały one pominięte w językach Eiffel, Java i Modula3. Twierdzi się, że są one potrzebne wyłącznie z powodu oszczędności pamięci (nisko kwalifikowany motyw), prowadzą do trudności z kontrolą typów i mogą być zastąpione poprzez specjalizacje klas i obiektów. Jest to jednak rozwiązanie pozorne, ponieważ prowadzi do niepotrzebnej eksplozji ilości klas, zmusza do migracji obiektów z klasy do klasy (przy zmianie zestawu jego atrybutów), oraz utrudnia przetwarzanie kolekcji zawierających obiekty o różnym zestawie atrybutów. Mimo ostatnich tendencji należy oczekiwać, że unie jeszcze wrócą do łask wśród projektantów języków i systemów. Synonim: zapis z wariantami.

unia typów (type union) Typ powstały poprzez zsumowanie dwóch lub więcej typów. Jeżeli typ T = T1 + T2, gdzie + jest operatorem unii typów, to wartość x jest zgodna z typem T wtedy i tylko wtedy, jeżeli jest zgodna z typem T1 lub z typem T2. Z reguły unia typów dotyczy zapisów (rekordów) lub struktur; patrz: unia.

unia z dyskryminatorem (discriminated union) Unia typów, w której wyróżnia się atrybut, którego wartość pozwala rozpoznać podczas wykonania, z którym przypadkiem unii mamy aktualnie do czynienia. Patrz: unia.

Unified Modeling Language Patrz: UML.

UniSQL Obiektowo-relacyjny system zarządzania bazą danych, oparty na rozszerzonym SQL; zrealizowany przez firmę UniSQL, Inc; obecnie także wprowadzający standard ODMG. Najnowsza wersja systemu nosi nazwę UniSQL/X. Model danych systemu jest oparty na klasach/tablicach, atrybutach/kolumnach i metodach. Wspomaga typy masowe (kolekcje): zbiory, wielozbiory i listy. Klasy/tablice mogą być organizowane w hierarchię dziedziczenia. Wspomaga statyczne i dynamiczne wiązanie metod. W warstwie implementacyjnej wprowadza technikę przemiany wskaźników, dostęp nawigacyjny i automatyczne zbieranie nieużytków. (We wrześniu 1997 firma UniSQL zakończyła działalność z powodu trudności finansowych.)

http://www.unisql.com

uniwersalny serwer (universal server) Termin określający niektóre systemy obiektowo-relacyjne (DB2, Informix, Oracle), eksponujący fakt, że są one przystosowane do przechowywania i przetwarzania relacji, obiektów, danych przestrzennych, multimedialnych, są zintegrowane z WWW, technologią hurtowni danych, itd.

UoD (Universe of Discourse) Przedmiot rozważań, dziedzina problemu (problem domain) przy analizie i projektowaniu systemu informacyjnego.

210


usługi obiektowe (Object Services, OS) Termin OMG CORBA; element architektury OMA. W obecnym standardzie OMG CORBA zdefiniowano następujące 15 usług obiektowych: Usługa w zakresie cyklu życiowego (Life Cycle Service). Definiuje operacje

tworzenia, kopiowania, przemieszczania, i usuwania komponentów (obiektów) będących pod kontrolą danej aplikacji zintegrowanej poprzez standard CORBA.

Usługa w zakresie trwałości (Persistence Service). Definiuje interfejs do składowania komponentów (obiektów) na trwałych nośnikach, włączając w to obiektowe bazy danych, relacyjne bazy danych i zwykłe pliki.

Usługa w zakresie nazywania (Naming Service). Pozwala nadać komponentom (obiektom) nazwy (o hierarchicznej budowie) oraz odzyskać identyfikatory komponentów (obiektów) na podstawie ich nazw. Usługa pozwala przywiązać komponenty (obiekty) do istniejącego nazewnictwa katalogów systemów operacyjnych lub kontekstów nazwowych wg różnorodnych systemów: ISO X.500, OSF DCE, Sun NIS+, Novell NDS, Internet LDAP.

Usługa w zakresie zdarzeń (Event Service). Pozwala określić, czy dane komponenty mają reagować (nie reagować) na określone zdarzenia.

Usługa w zakresie współbieżności (Concurrency Control Service). Pozwala zakładać/zdejmować zamki na obiekty (lub inne byty) celem przeciwdziałania kolizjom transakcji lub wątków.

Usługa w zakresie transakcji (Transaction Service). Przewiduje koordynację transakcji opartą na dwufazowym potwierdzeniu (2PC) dla prostych i zagnieżdżonych transakcji.

Usługa w zakresie związków (Relationship Service). Przewiduje dynamiczne tworzenie/usuwanie powiązań (związków, asocjacji) pomiędzy obiektami, wymuszanie więzów referencyjnych, oraz nawigację od obiektów do obiektów wg zdefiniowanych dla nich związków.

Usługa w zakresie udostępniania obiektów na zewnątrz (Externalization Service). Przewiduje wstawianie i odczytywanie danych do/z komponentów (obiektów).

Usługa w zakresie zapytań (Query Service). Przewiduje dostęp do obiektów poprzez różnorodne języki zapytań, wśród nich SQL-92, nowo powstający standard SQL3, oraz obiektowy język zapytań (standardu ODMG) OQL.

Usługa w zakresie licencji (Licensing Service). Usługa pozwala na pomiary użycia komponentów (obiektów) oraz wyliczenie opłat za użycie w ramach sesji, węzła sieci, itd.

Usługa w zakresie dodatkowych własności obiektów (Properties Service). Pozwala dynamicznie związać z obiektami dowolne nazwane własności (atrybuty), np. datę utworzenia, datę ostatniej modyfikacji, nazwisko modyfikującego, itd.

Usługa w zakresie czasu (Time Services). Przewiduje interfejsy do synchronizowania czasu w środowisku rozproszonym. Pozwala również definiować zdarzenia wyzwalane przez upływ czasu.

Usługa w zakresie ochrony (Security Service). Zapewnia możliwości pełnej ochrony rozproszonych obiektów. Wspomaga autoryzację, sterowanie dostępem, tajność i przeciwdziałanie unikaniu zapłaty (non-repudiation). Zarządza także oddelegowywaniem uwierzytelnień (credentials).

211


Usługa handlowa (Trader Service). Przewiduje odzyskiwanie informacji o obiektach na podstawie ich własności, publikować informacje o serwisach dostarczanych przez obiekty, itd.

Usługa w zakresie kolekcji (Collection Service). Przewiduje interfejsy do tworzenia najczęściej spotykanych kolekcji (zbiorów, wielozbiorów, sekwencji, itd.) i manipulacji tymi kolekcjami.

Zestaw usług obiektowych jest rozszerzany w planowanym standardzie CORBA 3.0.http://www.omg.org

usuń (delete) Operacja definiowana na bazie języka zapytań (np. w SQL) powodująca usunięcie z danej tablicy wskazanych krotek, np.:

delete Pracownik where Nazwisko = ‘Kowalski’

Operacja jest także definiowana (lub rozważana) w obiektowych językach zapytań.

utrzymanie oprogramowania (software maintenance) Patrz: pielęgnacja.

utwórz (create) Operacja w języku zapytań (np. w SQL) lub języku manipulacji danymi, powodująca utworzenie nowej tablicy, nowego obiektu, nowej krotki, itd.

użytkownik (user) Osoba lub grupa osób stanowiąca podmiot interakcji systemu informatycznego. W zależności od trybu dostępu i celów działalności istnieje wiele kategorii użytkowników, np.: użytkownik końcowy, programista aplikacyjny, administrator bazy danych, administrator systemu.

VV

Vbase Wcześniejsza wersja systemu Ontos, wycofana z rynku.

VC++ Patrz: Visual C++.

VDM++ Obiektowe rozszerzenie notacji VDM-SL (Vienna Development Method Specification Language).

Versant Obiektowy system zarządzania bazą danych zrealizowany przez Versant Object Technology; wprowadza standard ODMG.

http://www.versant.com/prod_f/index.html

VisiBroker Pośrednik ORB wg standardu CORBA firmy Visigenic (przejęty następnie przez firmę Borland). VisiBroker jest ulepszoną wersją pakietu Black Widow ORB firmy PostModern. Istnieją dwie wersje: VisiBroker for Java i VisiBroker for C++. VisiBroker zjednoczył wiele działań przemysłu związanego ze standardem CORBA. Wiele firm włączyło ten pakiet w skład swoich produktów, m.in. Oracle, Hitachi, Netscape, Novell, SunSoft, NetDynamics, Novera, Sybase, Borland, Gemstone, Silicon Graphics, Hummingbird, Cincom i Business Objects. VisiBroker jest obecnie

212


składnikiem każdej przeglądarki Netscape. Również stał się podstawowym składnikiem oprogramowania Borlanda.

http://www.visigenic.com/prodhttp://www.corbajava.engr.sjsu.edu

Visual Age Rodzina produktów - środowisk programistycznych służących do wizyjnego programowania aplikacji z relacyjną bazą danych; zrealizowana i rozpowszechniana przez IBM. Visual Age posiada odmiany zorientowane na poszczególne języki programowania (Smalltalk, C++, Java, Cobol), oraz jest wyposażony w szeroką gamę różnorodnych narzędzi i udogodnień.

Visual Basic Popularny, wizyjny system dla MS Windows wspomagający programowanie zdarzeniowe. Posiada pewne cechy obiektowości.

Visual C++ (VC++) Wizualne środowisko programistyczne dla języka C++ zrealizowane i rozpowszechniane przez Microsoft. Visual C++ wspomaga programowanie obiektowe aplikacji w środowiskach Windows (32 bitowych). Posiada zintegrowane środowisko rozwoju (IDE), kompilator C/C++ oraz bibliotekę klas (MFC).

WW

w locie (on-the-fly) Czynność wykonywana równolegle, w tle innej zasadniczej czynności bez jej zatrzymywania; np. zbieranie nieużytków bez zatrzymywania lub opóźniania zasadniczych przebiegów programu.

wariant (variant) Termin występujący w rodzinie języków Pascal, Modula-2 itd. oznaczający typ zapisu, który ma dwa lub więcej alternatywnych zestawów atrybutów. W literaturze obiektowej częściej jest używany termin unia (union). Patrz: unia.

wartość domyślna (default value) Wartość podstawiana w momencie tworzenie zmiennej lub instancji obiektu. Również wartość zwracana przez pewne wyrażenie lub zapytanie, o ile po jego ewaluacji wynik jest wartością zerową (NULL). Wartości domyślne mogą być predefiniowane w danym języku (np. zero lub pusty string), ale mogą także stanowić fragment definicji obiektu (wchodzić w skład jego klasy).

wartość masowa (bulk value) Wartość złożona z wielu elementów, której rozmiar nie daje się przewidzieć ani sensownie ograniczyć. Synonimy: kolekcja, kontener.

wartość zerowa (null value, NULL, NIL) Wartość atrybutu obiektu, wskaźnika lub innej danej, która jest nierelewantna w danej sytuacji lub z jakichś powodów nie została wpisana lub zainicjalizowana. Zwykle jest oznaczana jako NULL lub NIL. Można wyróżnić wiele powodów pojawiania się wartości zerowych, np.: (1) Pewien atrybut nie ma zastosowania dla konkretnego przypadku, np. atrybut NAZWISKO_PANIEŃSKIE dla mężczyzn; (2) Informacja jest nieznana, np. miejsce, gdzie został pochowany

213


Mozart; (3) Informacja o przyszłości, np. wynik przyszłego meczu piłkarskiego; (4) Informacja jeszcze nie zapełniona; np. po wprowadzeniu danych pracownika jego zarobek jest wartością zerową, gdyż wypełni ją później inny proces; (5) Wartość zerowa jest sygnałem wartości domniemanej, np. jeżeli prawie wszyscy pracownicy są urzędnikami, to pole ZAWÓD wypełnia się tylko dla nie-urzędników. Częstą przyczyną wartości zerowych jest to, że informacja nie zawsze da się idealnie wpasować w ustalony format. Znacznie rzadszą przyczyną jest niekompletność informacji, tj. sytuacja, kiedy informacja istnieje, ale nie jest znana.

Szczególną uwagę poświęca się wartościom zerowym w modelu i systemach relacyjnych, które są oparte na sztywnych formatach danych. Wartości zerowe leżą u podstaw definicji innych pojęć modelu relacyjnego, takich jak zewnętrzne złączenie (outer join). Okazuje się, że wartości zerowe zachowują się zupełnie inaczej, niż inne wartości, wobec czego wiele operacji w bazie danych musi je uwzględnić w postaci wydzielonego przepisu semantycznego.

Wartości zerowe były powodem licznych prac teoretycznych; nie znalazły one jednak zastosowania w rzeczywistych systemach. Większość tych prac przyjmowało założenie, że wartość zerowa pojawia się wskutek niekompletnej informacji, co dla przeważającej ilości rzeczywistych przypadków było założeniem fałszywym. Co za tym idzie, wartości zerowe były powodem powstania wielu pseudoteorii. Ogólnie, próby ustalenia semantyki dla wartości zerowych są nieudane, gdyż w bardzo wielu przypadkach użytkownik lub programista jest jedynym autorytetem, który potrafi je zinterpretować.

Z drugiej strony, doświadczenie pokazuje, że wartości zerowych nie da się uniknąć w żadnym rzeczywistym systemie bazy danych, zaś zastępowanie ich wartościami domyślnymi (default values) (np. 0, spacje lub pusty ciąg) zwiększa skłonność do błędów. Z tych powodów za słuszną trzeba uznać decyzję twórców języka SQL, gdzie podczas definiowania tablic można ustalić, że pewne ich kolumny mogą zawierać wartości zerowe. Takie kolumny należy rozumieć jako kolumny podwójne: w pierwszej kolumnie są przechowywane normalne wartości, zaś w drugiej informacja (boolowska) wskazująca miejsca, w których są wartości zerowe. Ta dychotomia jest przenoszona dalej na wszystkie interfejsy programistyczne: jeżeli taka wartość ma być podstawiona na zmienną, to należy zadeklarować dwie zmienne, jedną dla wartości, drugą (zwaną indicator variable) dla informacji o wartości zerowej. Język SQL jest wyposażony w szereg cech umożliwiających przetwarzanie tak rozumianych wartości zerowych, m.in. w specjalny predykat (is_null) testujący wystąpienie wartości zerowej, specjalną funkcję (if_null) pozwalającą zastąpić wartość zerową poprzez dowolną inną wartość, i specjalne traktowanie wartości zerowych w argumentach funkcji zagregowanych. Rozwiązania dotyczące wartości zerowych w SQL są przedmiotem dość ostrej krytyki (C.J.Date). W obiektowych bazach danych problem ten wydaje się być niedoceniany pomimo jego dużej wagi dla spójności działania systemu.

warunek końcowy (postcondition) Warunek, który musi być spełniony po uruchomieniu pewnej operacji lub metody.

warunek wstępny (precondition) Warunek, który musi być spełniony przed uruchomieniem pewnej operacji lub metody.

214


wątek (thread) „Mały” lub „lekki” proces (jakkolwiek nie istnieją ograniczenia na rozmiar wątków). Systemy operacyjne UNIX konsumują dla każdego procesu sporo zasobów, w szczególności czasu procesora i pamięci operacyjnej. Ta własność powoduje zmniejszenie dostępności systemu, o ile każdy z użytkowników (każde z zadań) miałby być obsługiwany przez oddzielny proces. Wielowątkowość oznacza, że jeden proces może być podzielony (poza systemem operacyjnym) na wiele małych podprocesów, czyli wątków. Ponieważ system operacyjny o nich nie wie, więc nie przydziela im zasobów. Zysk polega na znacznym zwiększeniu możliwości równoległej pracy oraz znacznym zmniejszeniu konsumowanych zasobów, a co za tym idzie, znacznym zwiększeniu szybkości przetwarzania z punktu widzenia każdego z użytkowników. Wątki są więc protezą łagodzącą zbyt ciężkie mechanizmy systemów operacyjnych. Obecna moda na wątki (w języku Java, w standardzie ODMG, itd.) może być jednak uważana za konsekwencję pogoni za doraźnym zyskiem kosztem jakości oprogramowania. Niektórzy specjaliści uważają wątki za „zatrute jabłko” (poison apple), czyli pojęcie, które poprzez zbytnie uproszczenia i brak mechanizmów synchronizacji może zaowocować w wiele trudnych do wykrycia błędów.

wczesne wiązanie (early binding) Patrz: wiązanie statyczne.

wersja (version) Zarejestrowany stan obiektowej bazy danych w przeszłości lub równorzędny, alternatywny stan bazy danych dotyczący pewnego projektu. Zarządzanie wersjami stanowi istotny problem naukowo-techniczny. Wersją obiektu nazywany jest zarejestrowany stan obiektu w przeszłości.

wiązanie [1] (binding) Zamiana nazw występujących w programie lub zapytaniu na byt ze środowiska wykonania programu (np. nazwy zmiennej na adres maszynowy przechowujący wartość tej zmiennej).

wiązanie [2] (binding) (Terminologia OMG i ODMG) Zasady połączenia dwóch systemów językowych, np. standardu ODMG z językiem C++, Smalltalk lub Java.

wiązanie [3] (linking) Patrz: konsolidacja.

wiązanie dynamiczne (dynamic binding) Wiązanie nazw występujących w programie na etapie wykonania programu; inaczej późne wiązanie.

wiązanie późne (late binding) Patrz: wiązanie dynamiczne.

wiązanie statyczne (static binding) Patrz: statyczne wiązanie.

wiązanie wczesne (early binding) Patrz: statyczne wiązanie.

widoczność (visibility) Określenie, na ile dana cecha pewnej abstrakcji (atrybut klasy, metoda klasy) jest widoczna dla innych abstrakcji. Widoczność jest określona przez zakres nazw; patrz: reguły zakresu. W kontekście hermetyzacji termin ten oznacza przypisanie do składowej obiektu kwalifikacji takich jak: publiczna, prywatna, chroniona.

215


widżet (widget) Okienkowy gadżet (window gadget). Mały obiekt graficzny widoczny w interfejsie użytkownika, służący do pewnych manipulacji, wprowadzania, wyprowadzania, lub wyszukiwania danych. Przykładami widżetów są przyciski, pola radiowe, pola menu, suwaki, itd. Termin jest także używany w charakterze symbolicznego dydaktycznego przykładu („Załóżmy, że sprowadziliśmy do magazynu partię widżetów zapakowanych w 100 skrzynkach...”).

wielodostęp (concurrency) Równoległy dostęp, czyli możliwość jednoczesnej pracy wielu użytkowników. Wielodostęp implikuje konieczność zastosowania środków przeciwdziałających niekorzystnym interferencjom pomiędzy użytkownikami, powstającym np. wtedy, gdy kilku z nich próbuje jednocześnie zaktualizować tę samą daną. Skutkiem takiej interferencji jest utrata spójności bazy danych, np. zgubienie pewnych aktualizacji. Powszechnie przyjętą techniką przeciwdziałania takim interferencjom jest blokowanie danych, poddane dyscyplinie określonej jako przetwarzanie transakcji. Transakcje okazały się również bardzo wygodne dla systemów rozproszonych baz danych, ze względu na dodatkową własność przeciwdziałania skutkom przypadkowych awarii systemu.

wielodziedziczenie (multi-inheritance) Patrz: wielokrotne dziedziczenie.

wielokrotna dyspozycja (multiple dispatching) Patrz: dyspozycja.

wielokrotne dziedziczenie (multiple inheritance) Określenie sytuacji, w której obiekt lub klasa może dziedziczyć własności więcej niż jednej klasy. Wielodziedziczenie implikuje bardziej złożoną strukturę klas (acykliczny graf) oraz szereg problemów np. z mocną kontrolą typów. Poniższy rysunek ilustruje wielokrotne dziedziczenie: klasa AMFIBIA dziedziczy zarówno z klasy POJAZD_LĄDOWY, jak i z klasy POJAZD_WODNY.

POJAZDciężar

.....prędkość_eksploat()

POJAZD_LĄDOWYilość_kół

max_prędkość.....

POJAZD_WODNYwyporność

max_prędkość.....

AMFIBIASAMOCHÓD JACHTTRAKTOR ŻAGLÓWKA

Amfibia jako przykład wielokrotnego dziedziczenia

wielokrotne interfejsy (multiple interfaces) Własność języka, systemu, standardu polegająca na możliwości zdefiniowania wielu interfejsów do tego samego obiektu.

216


Wielokrotne interfejsy uważa się za sprzyjające modelowaniu pojęciowemu; jest to również pewien (niedoskonały) sposób obejścia braku wielodziedziczenia. Wielokrotne interfejsy są własnością COM/DCOM oraz Java. Tej własności nie ma C++, Smalltalk oraz standardy CORBA i ODMG. (Są planowane w CORBA 3.0.)

wielowarstwowa architektura (multi-tiered architecture) Patrz: architektura wielowarstwowa.

wielowartościowy atrybut (multi-valued attribute) Patrz: atrybut powtarzalny.

wielowątkowy (multi-threaded) Określenie języka lub systemu umożliwiającego równoległą pracę wielu wątków. Patrz: wątek.

wielozbiór (multiset, bag) W terminologii obiektowych baz danych (np. ODMG) konstruktor typów/klas. Wartość typu wielozbiór można dowolnie zwiększać o nowe elementy, lub usuwać elementy w niej zawarte. Porządek elementów nie ma znaczenia. W odróżnieniu od zbioru, wielozbiór może zawierać identyczne elementy, np. {1,3,3,6,3,1} jest wielozbiorem zawierającym 6 elementów, w tym dwie jedynki, trzy trójki i szóstkę; taki wielozbiór jest równoważny np. {6,3,3,3,1,1}, ale nie jest równoważny wielozbiorowi {1,3,6}.

wiersz (row, tuple) Patrz: krotka.

więzy integralności (integrity constraints) Warunki, które muszą spełniać dane zawarte w bazie danych. Warunki te mogą być dwojakiego rodzaju: statyczne, wykluczające niedopuszczalne wystąpienia bazy danych (np. „wiek ojca musi być większy od wieku syna”) oraz dynamiczne, przeciwdziałające niedopuszczalnym zmianom zawartości bazy danych (np. „zarobek nie może się zmniejszyć”). Ważną klasą więzów integralności w relacyjnych bazach danych są zależności funkcyjne (functional dependencies) oraz integralność odwołań (referential integrity). Więzy integralności są zwykle implementowane w postaci aktywnych reguł. Synonim: ograniczenia integralnościowe.

Wirfs-Brock Metodyka obiektowej analizy i projektowania systemów informatycznych. Patrz: DOOS.

Wirfs-Brock, Rebecca. Autorka metodyki obiektowej Wirfs/Brock.

wirtualny (virtual) Określenie dotyczące dowolnej cechy, dowolnego pojęcia lub dowolnego innego bytu, który posiada istnienie koncepcyjne (jest wyobrażalny i manipulowalny), ale nie posiada istnienia materialnego, fizycznego, lub nie jest bezpośrednio odwzorowany na nośnikach informacji.

wirtualny atrybut (virtual attribute) Patrz: atrybut pochodny.

wizja (view) Patrz: perspektywa.

własności behawioralne (behavioral properties) Elementy schematu pojęciowego

217


lub schematu bazy danych, określające własności dynamiczne lub zachowanie się obiektów. Przykładami własności behawioralnych są zdarzenia, które mogą zajść na obiektach, akcje przypisane do zdarzeń (czyli aktywne reguły), metody przypisane do obiektów lub ich klas, reguły określające dopuszczalne zmiany stanu obiektów.

własność domkniętości (closure property) W modelu relacyjnym jest to własność algebry relacji lub języka zapytań mówiąca o tym, że argumentami wyrażeń algebraicznych lub zapytań są relacje i ich wynikiem są także relacje. Zdaniem niektórych autorów, ta własność umożliwia dowolne zagnieżdżanie zapytań. Własność domkniętości jest także uważana za pożądaną cechę dla obiektowych języków zapytań, przy czym zarówno argumentami jak i wynikiem zapytań powinny być obiekty (kolekcje obiektów). Niestety, zarówno pojęcie domkniętości, jak i sposób rozumowania jego propagatorów, są oparte na formalnym nieporozumieniu, z kilku powodów: Własność domkniętości nie obowiązuje w pełni dla relacyjnych języków zapytań,

gdyż semantyczne własności zapamiętanych relacji są różne od semantycznych własności relacji wygenerowanych przez zapytanie (np. zapamiętana relacja musi mieć nazwę i nazwy dla wszystkich atrybutów, zaś wyprodukowana w zasadzie nie musi; zapamiętaną relację można aktualizować, zaś wyprodukowanej nie można);

Relacyjne języki zapytań włączają do nich byty nie będące relacjami, (np. stałe, zmienne programistyczne, warunki, wołania funkcji) i mogą wygenerować byt nie będący relacją (np. pojedynczą liczbę);

Własność domkniętości nie jest niezbędnym warunkiem do zagnieżdżania zapytań, np. wyrażenia języka programowania, które można dowolnie zagnieżdżać, operują na zmiennych programistycznych, funkcjach i wartościach, ale mogą zwrócić tylko wartości (nie zwracają zmiennych i funkcji).

Formalistyczne przeniesienie własności domkniętości na grunt obiektowych języków zapytań rodzi dyskusje, czy zapytanie ma zwracać „istniejące obiekty” (co bardzo ograniczyłoby moc języka zapytań), czy też ma tworzyć nowe obiekty z nowymi unikalnymi identyfikatorami (co rodzi problemy zarówno koncepcyjne, jak i implementacyjne). Uniknięcie tych pseudoproblemów jest bardzo proste: wystarczy zrezygnować z podanej wyżej własności domkniętości i przyjąć inną: mianowicie, że nazwy występujące w zapytaniu zawsze zwracają referencje do obiektów, zaś dowolne zapytanie zwraca pewną strukturę zbudowaną z referencji, nazw i wartości - nigdy nie zwraca obiektów. Te założenia pozwalają na zbudowanie poprawnej semantyki obiektowego języka zapytań umożliwiającego dowolne zagnieżdżanie zapytań. Reasumując, podejścia do semantyki języków zapytań oparte o własność domkniętości są naiwne, są pseudokoncepcjami nie oddającymi istoty problemu. Dodać należy, że większość formalnych podejść do obiektowych języków zapytań (F-logika, rachunek monoidów, algebry obiektowe) - poza podejściem stosowym (stack-based approach) - przyjmuje mniej lub bardziej explicite własność domkniętości. Jest to wystarczający powód, aby te podejścia były nieadekwatne do opisu semantyki rzeczywistych języków zapytań takich jak OQL.

wołanie odległej metody (remote message invocation, RMI) Patrz: RMI.

218


wołanie odległej procedury (remote procedure call, RPC) Technika wołania procedury znajdującej się poza przestrzenią adresową danego komputera. Dzięki niej lokalny program może wykonywać procedurę na odległym komputerze, przesyłając do niej parametry i pobierając zwrócony przez nią rezultat. System RPC jest zestawem oprogramowania niezbędnego do podtrzymywania technik programowania używających odległych procedur. Jest on podstawową składową środowiska rozproszonego przetwarzania. RPC robi ostatnio karierę w informatyce, w tym również w bazach danych. Istnieje kilka jego standardów, w szczególności: udogodnienia w systemie UNIX, udogodnienia opracowane przez grupę Sun Microsystems’ Open Network Computing (ONC), produkt zwany Distributed Computing Environment (DCE) opracowany przez konsorcjum Open Software Foundation (OSF), produkt ANSAWARE, Courier RPC firmy Xerox, i inne. RPC jest szczególnie przydatne do programowania aplikacji w architekturze klient-serwer. Wołanie odległej procedury znalazło m.in. zastosowanie w systemach relacyjnych (np. Sybase), w rozproszonych systemach operacyjnych (np. OSF DCE), w standardzie DCOM, oraz w standardzie OMG CORBA.

wołanie poprzez nazwę (call-by-name) Technika przekazywania parametrów (po raz pierwszy zastosowana w języku Algol 60) polegająca na tym, że parametru nie oblicza się w momencie wołania metody/procedury, ale przekazuje się go w postaci kodu (tekstu) wyrażenia będącego parametrem aktualnym. Tekst ten zastępuje wszystkie wystąpienia parametru formalnego w ciele metody/procedury (parametr jest traktowany jak „makro”). Specyfiką tej techniki jest to, że środowisko, w którym taki parametr jest ewaluowany, jest środowiskiem wywołania tej metody/procedury, a nie jej środowiskiem lokalnym (co jest konieczne z semantycznego punktu widzenia); jest to zwykle implementowane poprzez przekazanie wskaźnika do kodu/tekstu będącego parametrem aktualnym. Technika jest semantycznie „brudna”, gdyż może powodować efekt, w którym obliczane wartości parametru w poszczególnych miejscach ciała metody/procedury nie są identyczne ze względu na to, że wewnątrz ciała metody mógł ulec zmianie stan, na podstawie którego obliczany jest parametr. Technika ta jest powszechnie stosowana w przypadku parametrów makr. Może ona mieć również znaczenie dla technik optymalizacyjnych (w szczególności, optymalizacji zapytań) opartych na przepisywaniu (rewriting).

wołanie poprzez potrzebę (call-by-need) Technika przekazywania parametrów określana także jako „leniwa ewaluacja” (lazy evaluation). Oznacza opóźnienie wyliczania wartości parametru aktualnego do momentu, kiedy będzie on rzeczywiście potrzebny wewnątrz ciała metody/procedury. Parametr jest ewaluowany tylko raz, w środowisku wywołania metody/procedury. Technika ma na celu optymalizację czasu wykonywania i może być kombinowana z innymi metodami (call-by-value, call-by-reference, itd.). Podobnie do call-by-name, technika ta jest semantycznie „brudna”, gdyż może prowadzić do efektu, w którym wartość wyliczonego parametru jest inna, niż wartość wyliczona w momencie wołania metody/procedury.

wołanie poprzez referencję (call-by-reference) Technika przekazywania argumentu procedury (lub metody) do jej wnętrza, w której przekazywana jest referencja do

219


obiektu. Dzięki temu wewnątrz procedury można dokonać zmiany stanu (aktualizacji) obiektu zewnętrznego w stosunku do tej procedury. Wołanie przez referencję jest kojarzone z własnością zmienności (mutability). Obiekt przekazywany poprzez referencję jest dostępny w ciele procedury nie pod swoją nazwą, lecz pod nazwą jej odpowiedniego parametru formalnego.

wołanie poprzez wartość (call-by-value) Technika przekazywania argumentu procedury (lub metody) do jej wnętrza, w której przekazywana jest wartość argumentu obliczona przed przekazaniem sterowania do wnętrza procedury. Zwykle oznacza to, że wewnątrz procedury tworzy się lokalną zmienną będącą kopią obiektu, wartości lub zmiennej przekazywanej jako argument. Wszelkie operacje wewnątrz procedury dokonywane są na tej kopii; oryginalny obiekt będący argumentem nie jest dostępny pod nazwą odpowiedniego parametru formalnego występującą w ciele procedury.

wołanie poprzez wartość ze zwrotem (call-by-value-return) Wołanie poprzez wartość, w którym wewnątrz ciała procedury tworzy się kopię zmiennej przekazanej jako parametr. Wszelkie operacje wewnątrz ciała następują na tej lokalnej kopii, a nie na oryginalnej zmiennej (różnica z call-by-reference). W momencie zakończenia procedury wartość tej lokalnej zmiennej podstawia się z powrotem na zmienną przekazaną jako parametr.

wskaźnik (pointer) Identyfikator obiektu, adres dyskowy, adres w pamięci operacyjnej lub inny jednoznaczny identyfikator danej, który jest używany przez programistę tak jak wartość, np. zapamiętywany jako wartość zmiennej lub atrybutu. Wskaźniki są podstawowym sposobem implementacji powiązań asocjacyjnych pomiędzy obiektami. Wskaźniki zaimplementowane w C/C++ są przyczyną złej sławy tego pojęcia, głównie dlatego, że prowadzą do fizycznych adresów pamięci, a nie do danych lub obiektów (w sposób logiczny). Poprzez tę własność oraz z powodu zbyt dużych możliwości dostarczanych dla programisty (tzw. arytmetyka wskaźników), wskaźniki mogą być źródłem poważnych błędów. Wskutek tego historycznego dziedzictwa w nowszych propozycjach (np. w Java) termin „wskaźnik” zastąpiono terminem „referencja”. W odróżnieniu od wskaźnika, referencja prowadzi nie do adresu w pamięci, lecz do danej lub obiektu.

Wskaźniki (lub referencje) były tępione przez propagatorów modelu relacyjnego, ponieważ nie pasowały do koncepcji ideologicznej bazującej na pojęciu relacji. W obiektowych bazach danych wskaźniki/referencje wróciły z powrotem do łask, ponieważ są one idealną techniką implementacji koncepcyjnych powiązań pomiędzy obiektami, oraz sprzyjają wydajności i konceptualizacji programów. Wskaźniki i referencje spotykają się również z niechęcią teoretyków, którym nie pasują do koncepcji takich jak programowanie w logice, dedukcyjne bazy danych lub model funkcjonalny (oparty np. na rachunku lambda). Pewne problemy ze wskaźnikami/referencjami powstają również w przypadku obiektów rozproszonych w sieci komputerowej. Synonimy: odsyłacz, pointer.

wspólne udogodnienia (common facilities, CF) Termin OMG CORBA oznaczający udogodnienia przewidziane przez standard CORBA, wspólne dla wielu dziedzin

220


aplikacyjnych. http://www.omg.org

wspólne udogodnienia pionowe (vertical common facilities) Termin OMG CORBA oznaczający udogodnienia oferowane przez standard CORBA dla specyficznych dziedzin aplikacyjnych (medycyna, CAD, finanse, wytwarzanie, telekomunikacja, itd.).

http://www.omg.org

wspólne udogodnienia poziome (horizontal common facilities) Termin OMG CORBA oznaczający udogodnienia oferowane przez standard CORBA wspólne dla wszystkich dziedzin aplikacyjnych.

http://www.omg.org

współbieżność (concurrency) Zdolność systemu do jednoczesnej obsługi wielu użytkowników, transakcji lub procesów.

współdziałanie (interoperability) Dziedzina badawcza i praktyczna zajmująca się umożliwieniem współpracy niezależnie zbudowanych (heterogenicznych) systemów, szczególnie w sieciach komputerowych. Spośród ogromnej liczby aspektów związanych z tym pojęciem można wyróżnić następujące: Budowa otwartych systemów operacyjnych, umożliwiających współdziałanie w

ramach wielu platform sprzętowych; podtrzymywanie przez te systemy odległego wołania procedur (remote procedure calls, RPC) oraz dynamicznego konsolidowania procedur (patrz standardy i systemy operacyjne OSF DCE, ANSAWARE, OMG CORBA, etc.)

Adaptacja/wykorzystanie starszego oprogramowania przez nowsze systemy, czyli tzw. zastosowania spadkowe (legacy applications).

Budowa wspólnego obrazu danych (wizji danych), oraz wspólnego języka dostępu do danych i manipulacji danymi dla heterogenicznego zbioru baz danych.

Dostęp do „obcych” baz danych z danego systemu zarządzania bazą danych. Ten aspekt jest znany pod pojęciem pomostów (gateways).

Automatyczna translacja programów napisanych w języku zapytań lub programowania A, na język zapytań lub programowania B.

Opracowanie różnorodnych standardów, których celem jest przenaszalność (portability) oprogramowania, lub co najmniej zgodność koncepcji, stylu, składni i pragmatyki. Przykładami są: SQL, standardy ODMG, ODBC, JDBC, COM, itd.

Synonim: interoperacyjność.

wstaw (insert) Operator w języku zapytań lub języku manipulacji danymi, którego zadaniem jest wstawienie nowej krotki do danej relacji, wstawienie nowego obiektu do kolekcji obiektów, itd.

wyciąganie mnożnika (factoring, factoring out) Identyfikacja wspólnych cech (inwariantów, np. metod lub definicji atrybutów) dla pewnej grupy obiektów i utworzenie z nich klasy. Również identyfikacja wspólnych cech dla pewnej liczby klas i następnie, utworzenie nadklasy abstrakcyjnej zawierającej te cechy (oraz usunięcie tych

221


wspólnych cech z podklas).

wyciekanie pamięci (memory leak, memory leakage, storage leak) Niekorzystne zjawisko w aplikacjach zbudowanych przy pomocy języków lub systemów nie wyposażonych w automatyczne zbieranie nieużytków (garbage collection), np. C++. Polega ono na tym, że programiści nie zawsze stosują ścisłą dyscyplinę dealokacji obszarów pamięci, które nie są już potrzebne. W ten sposób powstają coraz to nowe bezużyteczne obszary, o których system nie wie, że są bezużyteczne, zaś rozmiar użytecznej pamięci ulega ciągłemu zmniejszaniu. Efektem tego jest zwykle coraz wolniejsze działanie aplikacji, aż do jej całkowitego zawieszenia z powodu pozornego braku pamięci.

wydajność (performance) W większości przypadków chodzi o wydajność maszynową.

wydajność maszynowa (performance) Czas zużyty przez system komputerowy na wykonanie zadania lub operacji.

wydajność wytwarzania (productivity) Sprawność tworzenia projektu i oprogramowania, mierzona np. w osobo-miesiącach.

wyjątek (exception) Specjalny byt programistyczny powodujący przerwanie lub zawieszenie normalnej nitki sterowania programu i przejście do specjalnego fragmentu programu zajmującego się obsługą tego wyjątku. Przejście do obsługi wyjątku oznacza „boczne” wyjście z wielu aktualnie zbudowanych zakresów (scopes). Wyjątki mogą mieć charakter sprzętowy (np. nastąpiło dzielenie przez zero) lub programowy (np. użytkownik nacisnął klawisz Esc). Wyjątki pozwalają na lepszą strukturalizację programów, gdyż programista po zadeklarowaniu wyjątku jest zwolniony z konieczności pisania wielu warunków („strażników”), których celem jest (najczęściej) reakcja na błąd w programie. Wyjątki są także traktowane jako rodzaj lub synonim zdarzenia (event), które są podstawą atrakcyjnego paradygmatu programowania zwanego programowaniem sterowanym zdarzeniami (event-driven programming).

wykres stanów (state chart, statechart) Patrz: diagram stanów.

wyliczalny (derived) Patrz: pochodny.

wymagania (requirements) Zestaw mniej lub bardziej sformalizowanych zdań określający zakres merytoryczny systemu informatycznego (tzw. dziedzinę problemu), jego cel, misję, ograniczenia, którym ma podlegać, oraz jego wskaźniki eksploatacyjno-techniczne.

wymiatanie (scavenging) Metoda zbierania nieużytków (garbage collection) polegająca na obiegnięciu wszystkich obiektów zgodnie z referencjami (jak w metodzie znacz i zamiataj), przepisaniu ich na nowy obszar i następnie skasowanie wszystkich danych w starym obszarze. Metoda ma zastosowanie prawie wyłącznie w pamięci operacyjnej.

222


wyrażenie kropkowe (dot expression) Patrz: wyrażenie ścieżkowe.

wyrażenie ścieżkowe (path expression) Wyrażenie umożliwiające przechodzenie od danych do kolejnych danych poprzez podanie ich nazw. Np. wyrażenie ścieżkowe Adam.PracujeW.Firma.Nazwa przechodzi kolejno od obiektu Adam poprzez powiązanie wskaźnikowe PracujeW do obiektu Firma, a stąd (poprzez zejście w dół hierarchii tego obiektu) do atrybutu Nazwa (firmy). Wyrażenia ścieżkowe umożliwiają konceptualizację dostępu do bazy danych i stanowią istotną cechę obiektowych języków zapytań.

wysłanie komunikatu (sending a message) Przekazanie komunikatu od jego nadawcy do odbiorcy.

wystąpienie (instance) Inaczej obiekt; termin „wystąpienie” podkreśla związek obiektu z jego klasą. Można mówić o bezpośrednich wystąpieniach klasy, czyli obiektach powiązanych z daną klasą bez pośrednictwa innych klas, oraz o pośrednich wystąpieniach klasy, tj. wszystkich obiektach, które w jakikolwiek sposób korzystają z definicji umieszczonych w tej klasie (tego rodzaju wystąpienie jest też określane jako „członek”). Terminu „wystąpienie” używa się także w innych kontekstach, w których istotne jest podkreślenie związku pewnego konkretnego bytu z jego definicją, typem lub deklaracją. W szczególności, wystąpieniem związku (relationship) lub asocjacji (association) jest konkretne powiązanie (link), wystąpieniem przypadku użycia jest konkretna interakcja użytkownika z systemem, wystąpienie procesu jest pewien jego konkretny przebieg, podobnie dla wystąpienia przepływu prac, itd. Często spotykanym synonimem terminu wystąpienie jest instancja (kalka terminu angielskiego).

wystąpienie przypadku użycia (use case instance) Sekwencja akcji wykonywana przez system, której rezultatem jest rezultat obserwowalny dla pewnego aktora. Zwykle scenariusze ilustrują prototypowe wystąpienia przypadków użycia.

wytwarzanie wspomagane komputerem (Computer Aided Manufacturing, CAM) Patrz: CAM.

wytwórstwo oprogramowania (software development) Patrz: rozwój oprogramowania.

wyzwalacz (trigger) Patrz: aktywne reguły. Synonim: tryger.

wyzwolić (fire) Uruchomić pewną akcję, przejście, proces, czynność.

wzorzec (pattern) Patrz: wzorzec projektowy.

wzorzec projektowy (design pattern) Przykładowe lub abstrakcyjne rozwiązanie często występującego problemu programistycznego lub projektowego, które może być bezpośrednio użyte, lub może stanowić pomoc przy rozwiązywaniu innych podobnych problemów. Wzorzec projektowy w systematyczny sposób nazywa, motywuje i wyjaśnia stosunkowo często występujący element projektu lub powtarzającą się

223


sytuację projektową. W obiektowości wzorzec projektowy identyfikuje klasy, ich wystąpienia, role, kolaboracje i odpowiedzialności. Każdy wzorzec projektowy skupia się na pewnym szczególnym problemie projektowym. Opisuje on, kiedy go stosować, jakie są ograniczenia w stosowalności, oraz jakie są konsekwencje i kompromisy przy ich użyciu. Wzorce projektowe w obiektowości zostały spopularyzowane w odniesieniu do języków i systemów obiektowych przez grupę autorów określaną (żartobliwie) jako „banda czworga” (gang of four, GOF): E. Gamma, R. Helm, R. Johnson, J. Vlissides, którzy w szeroko spopularyzowanej książce (Design Patterns) przedstawiają 21 wzorców projektowych. Dopasowanie tych i innych wzorców do konkretnej sytuacji nie zawsze jest jednak oczywiste. Inną wadą spotykanych w literaturze wzorców jest fakt, że często ich motywem jest osłabienie negatywnych skutków złych lub ograniczonych rozwiązań niektórych języków i systemów (np. C++ lub systemów relacyjnych); w wielu przypadkach stałyby się one niepotrzebne, gdyby te języki lub systemy były lepiej zaprojektowane.

http://c2.com/ppr/index.htmlhttp://g.oswego.edu/dl/acs/acs/acs.htmlhttp://g.oswego.edu/dl/ca/ca/ca.htmlhttp://hillside.net/patterns/patterns.htmlhttp://st-www.cs.uiuc.edu/users/johnsonhttp://st-www.cs.uiuc.edu/users/patterns/http://st-www.cs.uiuc.edu/users/patterns/patterns.htmlhttp://www.enteract.com/~bradapp/docs/patterns-intro.htmlhttp://www.planet.net/bwalker/oo.htmlhttp://www.research.att.com/orgs/ssr/people/cope

XX Y Z

Yourdon, Ed. Twórca metodyki obiektowej Coad/Yourdon oraz MainstreamObjects.

Z++ Obiektowe rozszerzenie notacji Z.

zachowanie (behaviour, behavior) Zestaw metod i innych abstrakcji proceduralnych przypisany do (klasy) obiektów. Synonim: behawior.

zagnieżdżone relacje (embedded relations, nested relations) Patrz: nieznormalizowane relacje.

zagnieżdżone transakcje (nested transactions) Koncepcja przetwarzania transakcji, w której transakcja może składać się z podtransakcji. Istnieją dwa podejścia do zagnieżdżonych transakcji: Potwierdzenie podtransakcji nie powoduje fizycznej aktualizacji bazy danych.

Oznacza ono wyłącznie przeniesienie zamków i informacji o zaktualizowanych obiektach do transakcji macierzystej. Dopiero potwierdzenie transakcji stojącej

224


najwyżej w hierarchii powoduje trwałe aktualizacje i usunięcie blokad. Każda podtransakcja jest skojarzona z kodem określanym jako „podtransakcja

kompensująca” (compensation subtransaction). Potwierdzenie podtransakcji oznacza naniesienie trwałych zmian do bazy danych i zwolnienie blokad, ale w przypadku nie potwierdzenia transakcji macierzystej wykonywane są wszystkie odpowiednie podtransakcje kompensujące, których zadaniem jest odwrócenie skutków poczynionych przez potwierdzone podtransakcje. W tej koncepcji nie zakłada się 100% odwrócenia skutków. Np. jeżeli transakcja Podróż zawiera podtransakcję KupnoBiletu, to odpowiednia podtransakcja kompensująca może dawać zwrot kosztów biletu pomniejszonych o ustawowe opłaty manipulacyjne.

zagnieżdżone zapytanie (nested query) Zapytanie będące fragmentem innego zapytania; zapytanie zawierające w sobie inne zapytanie.

zagnieżdżony (nested) Termin ogólny; oznacza coś, co jest zawarte w innym bycie, jest składową innego bytu (np. zagnieżdżone zapytanie, zagnieżdżony moduł, itd.). Niekiedy terminem tym określa także byt zawierający w sobie inne byty (np. zagnieżdżona relacja). Synonim: zanurzony.

zakleszczenie (deadlock) Sytuacja przy przetwarzaniu transakcji, powstająca m.in. wtedy, gdy transakcja T1 blokuje zasoby A i żąda dostępu do zasobów B, podczas gdy transakcja T2 blokuje zasoby B i żąda dostępu do zasobów A; żadna z nich nie może kontynuować swojego przebiegu. Możliwe są zakleszczenia, w których uczestniczy wiele transakcji. Istnieje szereg technik przeciwdziałania zakleszczeniom, w szczególności, nie dopuszczanie do zakleszczeń (np. popularna metoda „czekasz-giń” (wait-die), która automatycznie zrywa transakcję w sytuacji, kiedy musi ona czekać na zasoby), lub metody oparte na wykrywaniu zakleszczeń i zrywaniu jednej z transakcji uczestniczących w zakleszczeniu. Synonim: blokada.

zakres (scope) Chodzi zwykle o zakres widoczności nazwy lub definicji (patrz: widoczność). Zakres jest kontekstem programu, w którym jest widoczna i może być użyta dana nazwa; patrz: reguły zakresu. Zakres może mieć charakter statyczny (inaczej leksykalny), ustalający fragmenty tekstu programu, w których jest widoczna dana nazwa. Podobnie zakres dynamiczny ustala, czy dana nazwa jest widoczna w aktualnie wykonywanym kodzie. Patrz też: zakres leksykalny, zakres dynamiczny.

zakres dynamiczny (dynamic scope) W językach z zakresem dynamicznym dana nazwa jest widoczna poza tekstem sąsiadującym z jej definicją, np. jest widoczna wewnątrz procedur wywoływanych z danej procedury, w której jest zdefiniowana ta nazwa. Zakres dynamiczny jest własnością egzotyczną: daje niewielkie możliwości dodatkowe, zwiększając przy tym istotnie uciążliwość programowania i skłonność do błędów.

zakres leksykalny (lexical scope) Określenie własności języków programowania, zgodnie z którą zakres definiowanej nazwy jest ograniczony do sąsiadującego z tą definicją tekstu programu (modułu, procedury, funkcji). Np. zakres zmiennej definiowanej wewnątrz pewnej procedury jest ograniczony do tekstu tej procedury;

225


zmienna ta jest niewidoczna na zewnątrz. Synonim: zakres statyczny (static scope). Przeciwieństwem jest zakres dynamiczny (dynamic scope), kiedy dana nazwa jest widoczna poza sąsiedztwem jej definicji, np. wewnątrz procedur wywoływanych z danej procedury.

zakres statyczny (static scope) Patrz: zakres leksykalny.

zależne złączenie (dependent join) Konstrukcja lub operator obiektowych języków zapytań takich jak OQL. Łączy on dwa zapytania, z których pierwsze deklaruje pewną zmienną, zaś drugie odwołuje się do tej zmiennej. Wynik stanowi kolekcja, w której każdy element jest kompozycją rezultatu pierwszego zapytania z rezultatem drugiego. Np. jeżeli obiekty Pracownik zawierają atrybuty wskaźnikowe PracujeW prowadzące do obiektów Firma, to złączenie obiektów Pracownik z obiektami Firma można uzyskać (w OQL) poprzez następujące zależne złączenie:

Pracownik as x, x.PracujeW.Firma as y

W porównaniu z SQL, zależne złączenie umożliwia większą konceptualizację i skrócenie zapytań. W odróżnieniu od klasycznego złączenia, zależne złączenie nie jest operatorem algebraicznym, ponieważ zakłada, że ewaluacja drugiego argumentu jest uzależniona od wyniku ewaluacji pierwszego.

zależność funkcyjna (functional dependency) Ograniczenie integralnościowe nakładane z zewnątrz na (nieskończoną) rodzinę relacji o wspólnym zestawie atrybutów, stwierdzające, że dla każdej relacji należącej do tej rodziny każda z wartości atrybutu A jest skojarzona z dokładnie jedną wartością atrybutu B; np. wartość atrybutu NR_PRACOWNIKA wyznacza dokładnie jedną wartość atrybutu NAZWISKO. Jest to zapisywane w postaci A B; mówi się też, że B jest funkcyjnie zależne od A. Zależność funkcyjną można łatwo uogólnić na przypadek, kiedy A i B są zestawami atrybutów. Istnieje aksjomatyka (Armstronga) tworząca prosty system dedukcyjny, pozwalający wnioskować o nowych zależnościach funkcyjnych na podstawie już istniejących zależności funkcyjnych, np. A BC implikuje A B oraz A C. Przy pomocy zależności funkcyjnych można łatwo zapisać i wyjaśnić niektóre anomalie w relacyjnych bazach danych, np. nie spełnienie warunków drugiej i trzeciej formy normalnej. Istniały nadzieje, że teorię zależności funkcyjnych (i innych) uda się wykorzystać do projektowania relacyjnych baz danych. Okazało się jednak, że są one w procesie projektowania praktycznie bezużyteczne, co podważyło sens rozwoju tej teorii.

zamek (lock) Znacznik umieszczany przez daną transakcję na stronie dyskowej, danej, obiekcie, itp. Byt z umieszczonym na nim zamkiem staje się niedostępny dla innych transakcji aż do momentu, gdy dana transakcja zwolni zamek (co zwykle następuje po jej zerwaniu lub potwierdzeniu). Dostęp do samego zamka jest możliwy wyłącznie ze strony tej transakcji, która ten zamek założyła (oraz z programu nadzorującego przebieg wykonania wszystkich transakcji). Zamki mogą określać rodzaj operacji, które są dostępne lub niedostępne dla innych transakcji; np. zamek do czytania oznacza, że inne transakcje mogą czytać informację z danego bytu, ale nie mogą go zmieniać. Zamki są jedną z najprostszych metod synchronizacji równoległych transakcji

226


(procesów); można je uważać za szczególny przypadek semaforów. Zamki są podstawową metodą przetwarzania transakcji w metodach określanych jako 2PL, lub ogólniej, w metodach określanych jako pesymistyczne. Patrz też: transakcja.

zamek do czytania (read lock) Zamek umieszczany przez daną transakcję na pewnym bycie, który oznacza, że inne transakcje mogą czytać informację z tego bytu, ale nie mogą go zmieniać. Patrz też: zamek.

zamek do pisania (write lock) Zamek umieszczany przez daną transakcję na danym bycie programistycznym, który oznacza, że inne transakcje nie mogą czytać informacji z danego bytu, ani też dokonywać w nim jakichkolwiek zmian. Patrz też: zamek.

zamienialność (substitutability) Reguła zgodności typów mówiąca, że jeżeli w pewnym miejscu programu może być użyty byt programistyczny typu (klasy) A, to w tym miejscu może być również użyty dowolny byt programistyczny typu (klasy) B, o ile B jest podtypem (podklasą) A. Np. przy założeniu, że typ Student jest podtypem typu Osoba, reguła zamienialności ustala, że obiekt typu Student może być użyty wszędzie tam, gdzie może być użyty obiekt typu Osoba. Reguła lub zasada zamienialności została sformułowana przez B. Liskov (Liskov Substitutability Principle, LSP). Jakkolwiek wydaje się ona naturalna i oczywista, prowadzi do anomalii, m.in. związanych z operacją podstawienia i z wielodziedziczeniem. Regułę zamienialności można wyeliminować przyjmując semantycznie bardziej konsekwentną koncepcję ról obiektu; patrz: rola[1].

zanurzone zapytanie (embedded query) Patrz: zapytanie zanurzone.

zanurzony (embedded) Dotyczy sytuacji, kiedy konstrukcje języka A (np. SQL) są używane wewnątrz konstrukcji języka B (np. PL/I, Pascal, C, C++, Ada); mówi się wtedy, że język A jest zanurzony w B, zaś B jest językiem-gospodarzem (host language). Technologia przetwarzania zakłada istnienie prekompilatora (precompiler), tj. programu, którego wejściem jest program zakodowany w A+B, zaś wynikiem jest program w B: konstrukcje języka A są zamieniane (zwykle na zasadzie rozwinięć makrosów) na sekwencje instrukcji języka B. Zaletą zanurzenia jest możliwość wykorzystania powiązania popularnego języka programowania z nowymi możliwościami, np. językiem zapytań. Zanurzenie zyskało sobie złą sławę, którą wyraża termin niezgodność impedancji (impedance mismatch). Z tego względu w systemach relacyjnych odchodzi się od koncepcji zanurzenia na rzecz budowy języków czwartej generacji oraz języków zintegrowanych takich jak SQL3. W obiektowych bazach danych (np. w standardzie ODMG) koncepcja zanurzenia jest (niestety) nadal dość popularna (chociaż w nieco zmodyfikowanej postaci).

zapamiętana procedura (stored procedure) Procedura, zwykle napisana w SQL lub innym języku interpretowanym, która jest zapamiętana na dysku jako składnik bazy danych. W obiektowych bazach danych zapamiętane procedury mogłyby przyjąć postać zapamiętanych metod. Ta możliwość nie jest jednak własnością obecnych obiektowych baz danych, gdzie metody odnoszące się do trwałych obiektów są umieszczane poza bazą danych, najczęściej w programach aplikacyjnych. Synonim: procedura bazy

227


danych.

zapewnienie jakości (quality assurance, QA) Zestaw działań, metod, standardów, organizacji mających na celu uzyskanie jakościowego produktu, w szczególności oprogramowania.

zapis (record) Termin używany w wielu starszych językach i systemach na oznaczenia zestawu nazwanych wartości. Synonimem zapisu w rodzinie języków C/C++ jest struktura, w systemach relacyjnych jest nim krotka lub wiersz, zaś w systemach obiektowych pojęcie zapisu jest protoplastą pojęcia obiektu.

zapis z wariantami (record with variants) Patrz: unia.

zapytanie (query) Wyrażenie języka zapytań, takiego jak SQL lub OQL. Zapytania charakteryzuje wysoki poziom abstrakcji (brak odwołań do struktur fizycznych takich jak np. indeksy), deklaracyjność (sformułowanie samego celu, a nie czynności do niego prowadzących), makroskopowość (jednoczesne działanie na wielu danych), naturalność (zgodność z naturalnym sposobem myślenia użytkownika), oraz efektywność (krótki czas wykonania zapewniany poprzez automatyczną optymalizację). Termin „zapytanie” jest często nadużywany, np. „zapytanie w języku C++” nie spełnia żadnego z wymienionych wyżej kryteriów.

zapytanie ad hoc (ad hoc query) Zapytanie, które jest sformułowane interakcyjnie przez użytkownika (bezpośrednio z jego końcówki). Przeciwieństwem jest zapytanie zanurzone (embedded), stanowiące fragment programu aplikacyjnego.

zapytanie interakcyjne (interactive query) Patrz: zapytanie ad hoc.

zapytanie zagnieżdżone (embedded query, nested query) Patrz: zagnieżdżone zapytanie.

zapytanie zanurzone (embedded query) Zapytanie, które stanowi fragment programu aplikacyjnego napisanego w pewnym języku programowania (np. w C). Przeciwieństwem zapytania zanurzonego jest zapytanie ad hoc.

zarządca trwałymi obiektami (Persistent Storage Manager, PSM) Patrz: skład trwałych obiektów.

zarządzanie wersjami (version management) Patrz: sterowanie wersjami.

zasada korespondencji (correspondence principle) Zasada korespondencji mówi, że wraz z wprowadzeniem do języka pewnej cechy X należy precyzyjnie określić inne cechy języka w taki sposób, aby cecha X współdziałała z już istniejącymi konstrukcjami tego języka, została wtopiona w istniejące lub zmodyfikowane mechanizmy nazywania, typowania, zakresu i wiązania, oraz miała zapewnioną uniwersalną obsługę. Przykładowo, jeżeli cechą X jest dynamiczna tablica, to odpowiednimi pytaniami są: czy może ona być składową zapisu (struktury, obiektu), czy może być parametrem

228


procedury, czy może być zwrócona przez procedurę funkcyjną, jakie środki będą przewidziane do typowania, wyszukiwania, aktualizacji, usuwania, dostawiania elementów; itd. Oddolny rozwój niektórych języków (np. SQL) jest przyczyną wielu przypadków łamania zasady korespondencji, co objawia się m.in. tym, że nowo dodawane cechy nie dają się gładko kombinować ze starymi cechami.

zasada otwarte/zamknięte (open/closed principle) Zasada obowiązująca przy konstrukcji obiektowych języków programowania, zgodnie z którą klasa jest otwarta na rozszerzenia (specjalizacje), lecz jest zamknięta na modyfikacje. Konsekwencją tej zasady jest zasada zamienialności.

zasada relatywizmu (relativity principle) Zasada mówiąca, że część pewnego bytu semantycznego powinna mieć takie same ogólne własności jak całość. Relatywizm obiektów oznacza, że dowolny obiekt składa się również z obiektów (podobiektów); pojęcie atrybutu staje się zbędne. Konsekwencją relatywizmu jest istnienie obiektów, które nie posiadają atrybutów (czyli obiektów atomowych), jak również obiektów, dla których nie jest istotne definiowanie klas. Relatywizm obiektów posiada istotne konsekwencje dla modelu danych, języków zapytań, interfejsów programistycznych oraz języków programowania, gdyż pociąga za sobą relatywizm środków definiowania danych i określania ich typów, oraz relatywizm środków dostępu do danych. Dzięki relatywizmowi środki te mogą być uproszczone do minimum. Minimalizacja ilości cech, które muszą być rozpatrywane przy definiowaniu i manipulowaniu obiektami, ma istotne konsekwencje dla prostoty modelu obiektowego, szybkości jego nauczania, rozmiaru dokumentacji, rozmiaru i regularności języków, złożoności modeli formalnych oraz łatwości i ogólności metod implementacyjnych. Jak dotąd, relatywizm obiektów nie jest koncepcją popularną. Metodyki i notacje służące do analizy i projektowania, np. OMT i UML, wyróżniają obiekty i atrybuty obiektów jako różne pojęcia. Podobne założenia przyjmuje większość języków programowania (poza językiem Smalltalk, systemem Loqis i niektórymi innymi koncepcjami).

zasada zamienialności (substitutability principle) Patrz: zamienialność.

zastępowalność (substitutability) Patrz: zamienialność.

zastosowanie spadkowe (legacy application) Zastosowanie oparte o system spadkowy, czyli starszy system ciągle będący w eksploatacji. Synonim: aplikacja spadkowa.

zbieranie nieużytków (garbage collection) Funkcja systemu, której zadaniem jest uzyskanie informacji o nieużytkach w pamięci operacyjnej lub na dysku (tj. o takich obszarach, które nie są wykorzystywane przez aktualnie przechowywane dane) i następnie, przesunięcie tych nieużytków do puli wolnej pamięci, która jest używana przy alokacji nowych danych. Do niedawna automatyczne zbieranie nieużytków uważane było za luksus, na który mogły sobie pozwolić wyłącznie języki o statusie idealizujących akademickich wzorców, takich jak LISP, ML czy CLU. W ostatnich latach ten pogląd uległ zmianie wskutek faktu, że pozostawienie problemu odzyskiwania nieużytków w rękach programistów prowadzi z reguły do błędów (patrz:

229


wyciekanie pamięci). Konstrukcja szeregu języków (np. C++) jest słabo przygotowana do wprowadzenia tej funkcji, głównie ze względu na cechy niskiego poziomu, takie jak wskaźniki. Synonim: odśmiecanie.

zbiór (set) W terminologii obiektowych baz danych (np. ODMG), konstruktor typów/klas nawiązujący do matematycznego pojęcia zbioru. Obiekt lub wartość typu zbiór można dowolnie zwiększać o nowe elementy oraz usuwać z niej elementy; nie może ona jednak zawierać dwóch identycznych elementów (lub równoważnie, istnienie dwóch lub więcej identycznych elementów nie ma znaczenia informacyjnego; duplikaty mogą być usunięte bez żadnych skutków dla przetwarzania). Porządek elementów w zbiorze nie ma znaczenia. W obiektowych bazach danych pojęcie zbioru jest kontrowersyjne, gdyż implikuje automatyczne usuwanie duplikatów (które jest bardzo kosztowne), oraz wymaga precyzyjnego zdefiniowania pojęcia równości elementów (co prowadzi do szeregu problemów semantycznych).

zdarzenie (event) Pojęcie (występujące w metodykach analizy i projektowania oraz w niektórych językach programowania) oznaczające rejestrowalną zmianę stanu otoczenia lub środowiska (np. nadejście partii towaru, naciśnięcie klawisza Esc, itd.), albo nadejście określonego momentu czasowego. Szczególnym przypadkiem zdarzenia jest wyjątek. Zwykle przyjmuje się, że zdarzenie występuje losowo (asynchronicznie) w stosunku do normalnego przepływu sterowania programu i z tego względu jest pojęciem różnym od pojęcia komunikatu. Ostatnio popularny stał się paradygmat programowania sterowanego zdarzeniami (szczególnie w odniesieniu do interfejsów graficznych) w językach określanych jako języki czwartej generacji (4GL).

zdarzenie zegarowe (clock event) Zdarzenie generowane po upływie pewnego odcinka czasu (stoper) lub w pewnym momencie (budzik).

zdarzenie-warunek-akcja (event-condition-action, ECA) Paradygmat aktywnych reguł. Aktywna reguła uaktywnia się w wyniku pojawienia się określonego dla niej zdarzenia; jeżeli po nim spełniony jest określony warunek, to wówczas podejmowana jest akcja. Patrz też: aktywne reguły.

zdjęcie (snapshot) Plik lub inna struktura danych przechowująca pewien chwilowy stan obiektów, stan zmiennych programu lub stan bazy danych. Najczęściej zdjęcie jest kopią bazy danych lub pewnego jej fragmentu (perspektywy), odwzorowującą pewien jej chwilowy stan. W odróżnieniu od składowania (back up) lub zrzutu (dump) zdjęcie może być przetwarzane przez standardowe środki programistyczne (np. przez SQL). Zdjęcia traktuje się często jako synonim zmaterializowanej perspektywy (materialized view); głównym jego celem jest uproszczenie programowania i polepszenie czasów wykonania. Zdjęcie jest również pojęciem stosowanym w technikach replikacji. Synonim: zdjęcie migawkowe.

zdolny do trwałości (persistence-capable) Określenie klasy, której wystąpieniami mogą być zarówno obiekty ulotne, jak i trwałe. Termin występuje w standardzie ODMG (wiązanie do języka Java).

230


zerwanie (abort) Przerwanie wykonania transakcji i odtworzenie stanu bazy danych sprzed początku jej działania. Zerwanie może być konsekwencją nienormalnych warunków zaistniałych podczas działania transakcji, lub może być wynikiem specjalnej komendy wydanej z wnętrza lub spoza danej transakcji.

zerwanie transakcji (transaction abort) Patrz: zerwanie.

zestaw miar (metrix suite) Zestaw wzajemnie uzupełniających się miar, pozwalający na wieloaspektową ocenę jakości lub złożoności oprogramowania, lub też jakości pracy uczestników danego projektu.

zestaw testów (test suite) Zestaw (seria) wzajemnie uzupełniających się testów, pozwalający na wieloaspektową ocenę jakości oprogramowania.

zewnętrzne złączenie (outer join) Złączenie tablic A i B może spowodować utratę informacji zawartej w tych tablicach. Niech np. A jest tablicą MIASTO z atrybutem NAZWA, zaś B jest tablicą PRACOWNIK z atrybutem MIEJSCE_URODZENIA. Złączenie tych dwóch tablic według wymienionych atrybutów spowoduje zgubienie informacji o wszystkich tych miastach, w których nie urodził się żaden pracownik, oraz o wszystkich tych pracownikach, dla których wartością atrybutu MIEJSCE_URODZENIA jest wartość zerowa (NULL). Motywem operatora zewnętrznego złączenia jest takie złączenie, które nie gubi informacji. Koncepcja ta zakłada, że dla każdej „wystającej” krotki, czyli takiej, której nie można złączyć z chociaż jedną krotką drugiej relacji, buduje się wiersz wynikowej tablicy, w którym ta krotka zostaje uzupełniona wartościami zerowymi (NULL values). Wyróżnia się lewostronne, prawostronne lub pełne zewnętrzne złączenie, w zależności od tego, która relacja jest podstawą pętli realizującej złączenie. Zewnętrzne złączenie jest istotne jako abstrakcja pojęciowa służąca do budowania zapytań. Stąd operator ten pojawił się w standardzie SQL-92. Pojęcie zewnętrznego złączenia może mieć także znaczenie w obiektowych językach zapytań.

zgodność typów (type conformance) Reguły i metareguły ustalające, kiedy typ T1 pewnego bytu programistycznego wydedukowany na podstawie reguł wnioskowania o typie (type inference rules) jest zgodny z typem T2, występującym w deklaracji tego typu. Przykładem takich reguł jest zamienialność, kowariancja, kontrawariancja, nazwowa zgodność typów, strukturalna zgodność typów, itd.

ziarnistość (granularity) Termin ten oznacza rodzaj jednostki danych będącej przedmiotem pewnych szczególnych procesów działających na bazie danych. Rozróżnia się ziarnistość blokowania (locking granularity) oznaczającą najmniejszą jednostkę, która może być zablokowana przez transakcję, ziarnistość replikacji (replication granularity) oznaczającą najmniejszą jednostkę, w stosunku do której można utworzyć odległą replikę, ziarnistość autoryzacji (authorization granularity) oznaczającą najmniejszą jednostkę, która może być uwzględniona przez prawa dostępu, itp. W systemach relacyjnych w większości poziom ziarnistości blokowania jest określony poprzez krotkę relacji, lub fizyczną stronę przesyłaną z pamięci zewnętrznej do operacyjnej i odwrotnie. W systemach obiektowych taką jednostką jest zwykle obiekt

231


lub strona fizyczna. Systemy obiektowe mogą być także oparte o koncepcję zmiennej ziarnistości, przy której jednostką blokowania w tym samym systemie może być ekstensja klasy, obiekt, podobiekt, atrybut, itd. Istnieje kontrowersja odnośnie tego, czy ziarnistość ma odnosić się do poziomu logicznego (np. obiektów), czy też fizycznego (np. stron). W systemach relacyjnych ze względów wydajnościowych przyjmowano, że ziarnistość odnosi się do poziomu fizycznego (stron). Przy takim rozwiązania (odległy) serwer obiektów przesyła do klienta strony nie wnikając w ich semantykę, co może zaowocować znacznym wzrostem objętości przesyłanych danych.

zlecenie (request) Dowolny komunikat wysłany do serwera (lub do obiektu) zlecający wykonanie usługi na rzecz klienta (lub innego obiektu).

zlecenie asynchroniczne (asynchronous request) Zlecenie, po którym klient nie czeka na rezultat, lecz wykonuje dalsze czynności. Odpowiedź na takie zlecenie jest nadsyłana przez serwer po pewnym czasie, lub też klient może wysłać do serwera inne zlecenie sprawdzające stan wykonania wysłanego zlecenia asynchronicznego.

zlecenie synchroniczne (synchronous request) Zlecenie, po którym klient czeka na rezultat. Zlecenie synchroniczne jest równoważne (zdalnemu) wołaniu procedury lub metody.

zliczanie referencji (reference count) Metoda stosowana w algorytmach zbierania nieużytków (garbage collection) polegająca na tym, że każdy obiekt jest wyposażony w licznik określający, ile referencji (lub wskaźników) prowadzi do tego obiektu; dodanie nowej referencji zwiększa licznik o 1, usunięcie referencji zmniejsza licznik o 1. Obiekt przestaje istnieć, jeżeli skojarzony z nim licznik wskazuje zero. Zaletą metody jest to, że zbieranie nieużytków można wykonywać „w locie”, bez zawieszania procesów operujących na danych. Wadami metody są: niestabilność (błąd może spowodować, że bezużyteczny obiekt pozostanie na zawsze lub użyteczny zostanie usunięty) oraz niemożliwość wykrycia nieużytków, o ile referencje od bezużytecznych obiektów do bezużytecznych obiektów tworzą cykl.

złączenie (join) Jeden z ważniejszych operatorów występujących w systemach relacyjnych. Umożliwia utworzenie tablicy, która w logiczny sposób łączy informacje zawarte w dwóch (lub więcej) tablicach. Np. dla tablic Dział i Pracownik złączenie tworzy tablicę zawierającą dane z obydwu tablic w ten sposób, że numer działu wewnątrz tablicy Pracownik jest kojarzony z numerem działu wewnątrz tablicy Dział. W języku SQL operator ten nie występuje explicite: jest on złożeniem operatorów produktu kartezjańskiego i selekcji. Operator ten występuje często na poziomie implementacyjnym: istnieje szereg sprawnych metod implementacji operatora złączenia, w szczególności metody oparte o sortowanie obydwu relacji i scalenie (merging), oraz metody oparte o kodowanie mieszające. W obiektowych językach zapytań złączenie odgrywa znacznie mniejszą rolę ze względu na to, że obiektowa struktura danych może zawierać hierarchicznie zbudowane obiekty oraz powiązania wskaźnikowe (które mają charakter predefiniowanych złączeń).

złączenie naturalne (natural join) W modelu relacyjnym, złączenie bazujące na

232


identyczności nazw kolumn złączanych tablic. Np. naturalne złączenie tablic: FIRMA(NrFirmy, Nazwa, Adres) oraz PRACOWNIK(NrPrac, Nazwisko, NrFirmy) utworzy pewną relację R(NrFirmy, Nazwa, Adres, NrPrac, Nazwisko), gdzie warunkiem złączenia będzie identyczność wartości w kolumnach NrFirmy obu tablic. Złączenie naturalne nie występuje w SQL. Nie ma też odpowiedników w obiektowych językach zapytań.

złączenie nawigacyjne (navigational join) Patrz: zależne złączenie.

złączenie zależne (dependent join) Patrz: zależne złączenie.

złączenie zewnętrzne (outer join) Patrz: zewnętrzne złączenie.

złożoność (complexity) Charakterystyka, miara ilościowa lub miara jakościowa odzwierciedlająca stopień skomplikowania danego problemu, poziom trudności rozwiązania problemu, lub stopień skomplikowania pewnego tworu ludzkiej działalności. Próbą formalnego podejścia do problemu złożoności jest złożoność algorytmiczna, badająca zależność pewnego użytkowego aspektu danego algorytmu (najczęściej czasu działania) od rozmiaru danych lub parametrów tego algorytmu; np. zależność czasu sortowania od ilości sortowanych elementów. W analizie i projektowaniu złożoność nie daje się wyrazić w terminach matematycznych; stosowane są miary empiryczne, w dużej mierze subiektywne. Złożoność jest faktem towarzyszącym prawie wszystkim projektom lub produktom informatyki. Jednym z filozoficznych motywów obiektowości jest zredukowanie złożoności tworów informatycznych, procesów ich wytwarzania oraz metod ich utrzymania i modyfikacji.

złożony atrybut (complex attribute, composite attribute) Patrz: atrybut złożony.

złożony obiekt (complex object, composite object) Patrz: obiekt złożony.

zmaterializowana perspektywa (materialized view) Dane lub obiekty pochodne wyliczone na podstawie pewnej definicji. Np. zmaterializowaną perspektywą dla obiektów Pracownik mogą być obiekty StaryPracownik wyliczone na podstawie warunku Wiek > 60. Podstawowym problemem dla realizacji zmaterializowanych perspektyw jest ich jednoczesna (tzw. przyrostowa, incremental) aktualizacja po aktualizacji oryginalnych danych, które stanowiły podstawę utworzenia danej zmaterializowanej perspektywy.

zmienialność (mutability) Własność bytu programistycznego (np. obiektu) oznaczająca możliwość zastosowania operacji aktualizacji; ta własność jest często (nie zawsze) składnikiem typu. Własność zmienialności jest najczęściej wiązana z parametrem procedury lub metody i oznacza, że parametr jest przekazywany przez referencję (call-by-reference).

zmienialny (mutable) Określenie parametru lub innej cechy posiadającej własność zmienialności; patrz: zmienialność.

233


zmienna globalna (global variable) Zmienna dostępna dla wszystkich bytów programistycznych; zmienna znajdująca się w powszechnie dostępnym środowisku lub zakresie.

zmienna klasowa (class variable) Patrz: zmienna klasy.

zmienna klasy (class variable) Zmienna programistyczna umieszczona wewnątrz klasy, której wartość jest wspólna dla wszystkich obiektów (wystąpień) tej klasy. Patrz też: atrybut klasy.

zmienna polowa (field variable) Atrybut obiektu w terminologii języka Java.

zmienna wystąpienia (instance variable) Inne określenie (Smalltalk) atrybutów obiektu. W koncepcji ortodoksyjnej hermetyzacji zmienne wystąpienia są ukryte i dostępne wyłącznie poprzez metody.

zmienność (mutability) Patrz: zmienialność.

znacz i zamiataj (mark and sweep) Metoda stosowana w mechanizmach zbierania nieużytków. Zakłada się, że każdy obiekt jest wyposażony w jednobitowy znacznik. W pierwszej fazie (znacz) następuje wyzerowanie wszystkich znaczników i następnie obiegnięcie całego zestawu obiektów od pewnych obiektów początkowych (korzeni) zgodnie z referencjami (wskaźnikami) prowadzącymi od obiektów do obiektów; w odwiedzanych obiektach znacznik ustawia się na 1. W ten sposób obiekty, do których nie prowadzi żadna referencja, nie zostaną zaznaczone. W drugiej fazie (zamiataj) następuje fizyczne usunięcie nie zaznaczonych obiektów. Zaletą metody jest jej stabilność (mała wrażliwość na niespójności organizacji danych). Wadą metody jest konieczność zawieszenia normalnej pracy systemu na czas działania tego mechanizmu.

zorientowany na wartości (value-oriented, value-based) Określenie modeli danych nie wprowadzających pojęcia wewnętrznego identyfikatora danej; np. model relacyjny, zagnieżdżone relacje, modele funkcjonalne i modele oparte o logikę (dedukcyjne). Niektórzy autorzy bronią tych modeli jako posiadających przewagę nad modelem obiektowym. Z kolei przeciwnicy tej koncepcji eksponują ich fundamentalną wadę polegającą na braku możliwości określenia naturalnej i spójnej definicji operacji aktualizacyjnych (ze względu na brak pojęcia stanu).

zorientowany obiektowo (object-oriented) Inaczej obiektowy; patrz: obiektowość.

zunifikowany język do modelowania (Unified Modeling Language, UML) Patrz: UML.

związek (relationship) W modelu encja-związek, powiązanie asocjacyjne pomiędzy encjami, np. powiązanie PracujeW pomiędzy encją Pracownik i encją Firma. W modelach obiektowych związek taki nosi nazwę asocjacji (association), kompozycji (composition) lub agregacji (aggregation). Związek może być binarny (łączący dwie encje lub obiekty), ternarny (łączący trzy encje lub obiekty), lub wyższego rzędu.

234


Związek posiada nazwę; poszczególne dziedziny związków mogą również posiadać nazwy, zwane rolami. Związek może posiadać własne atrybuty i niekiedy (np. w OMT i UML) może być wystąpieniem własnej klasy. Na diagramach encja-związek lub obiektowych deklarowana jest także liczność związku, określająca minimalną i maksymalną liczbę wystąpień innej klasy, które poprzez ten związek są powiązane z jednym wystąpieniem danej klasy. Synonim: asocjacja.

związek „jest” (is-a relationship) Związek zawierania się zakresów znaczeniowych pojęć (zbiorów obiektów), np. związek pomiędzy pojęciem STUDENT i pojęciem OSOBA: STUDENT „jest” OSOBA. Związek „jest” jest inaczej określany jako generalizacja/specjalizacja. Jest on również praktycznie tożsamy ze związkami dziedziczenia wyznaczającymi hierarchię klas.

związek dwukierunkowy (bidirectional relationship) Związek umożliwiający przechodzenie (nawigację) od jednej klasy do drugiej klasy, i odwrotnie.

związek jednokierunkowy (unidirectional relationship) Związek umożliwiający przechodzenie (nawigację) od jednej klasy do drugiej klasy, ale nie odwrotnie.

związek pochodny (derived relationship) Związek, który wynika z innych związków, lub który można wydedukować z innych informacji, np. atrybutów.

zwisające powiązanie (dangling link) Powiązanie, które prowadzi do nieistniejącego obiektu.

zwisający wskaźnik (dangling pointer) Wskaźnik, który nie jest identyfikatorem aktualnie przechowywanego obiektu, i którego wartość nie jest zerowa (NIL).

zzZZZ

zzzz

235

3. Bibliografia

3. Bibliografia

[ABDD+89] M. Atkinson, F. Bancilhon, D. DeWitt, K. Dittrich, D. Maier, S. Zdonik. The Object-Oriented Database System Manifesto. Proc. of 1st Intl. Conf. on Deductive and Object Oriented Databases 89, Kyoto, Japan, 1989, pp.40-57

[Ambl97] S.W.Ambler. Building Object Applications That Work. SIGS Books, 1997.

[Babel98] BABEL: A Glossary of Computer Oriented Abbreviations and Acronyms. http://www.access.digex.net/~ikind/babel.html#O

[Bana98] L. Banachowski. Bazy Danych - Tworzenie aplikacji. Akademicka Oficyna Wydawnicza PLJ, Warszawa 1998

[BCN92] C. Batini, S. Ceri, S.B. Navathe. Conceptual Database Design: An Entity-Relationship Approach. The Benjamin/Cummings Publishing Company, Inc., 1992

[Biel97] J. Bielecki. Java od podstaw. Intersoftland, 1997.[Booc94] G. Booch. Object-Oriented Analysis and Design with Applications.

Redwood City, CA, Benjamin/Cummings 1994[Catt97] The Object Database Standard ODMG 2.0. R.G.G. Cattel, Ed.,

Morgan Kaufman 1997.[CaWe85] L. Cardelli, P. Wegner. On Understanding Types, Data Abstraction

and Polymorphism. ACM Computing Surveys 17/4, Dec.1985, pp.471-522.

[CoYo94a] P. Coad, E. Yourdon. Analiza obiektowa. Oficyna wydawnicza READ ME, Warszawa, 1994. (tłum. [CoYo91a])

[CoYo94b] P. Coad, E. Yourdon. Projektowanie obiektowe. Oficyna wydawnicza READ ME, Warszawa, 1994. (tłum. [CoYo91b])

[FiEy95] D.G. Firesmith, E.M. Eykhold. Dictionary of Object Technology - The Definitive Desk Reference. SIGS Books, New York, 1995.

[Figu96] D. Figura. Obiektowe bazy danych. Akademicka Oficyna Wydawnicza, Warszawa 1996

[Flas97] M. Flasiński. Wstęp do analitycznych metod projektowania systemów informatycznych. Wydawnictwa Naukowo-Techniczne,

237

3. Bibliografia

1997 [FoSc97] M. Fowler, K. Scott. UML Distilled. Addison-Wesley 1997[Howe98] D. Howe. Free On-line Dictionary of Computing.

http://wombat.doc.ic.uc.uk[Jasz97] A. Jaszkiewicz. Inżynieria Oprogramowania. Wydawnictwo

HELION 1997[Klis94] M. Kliszewski. Inżynieria oprogramowania obiektowego. Cz.1.

Analiza obiektowa. Wydawnictwo Książki Technicznej Respekt, 1994.[Klis97] M. Kliszewski. Inżynieria oprogramowania obiektowego. Cz.2.

Projekt obiektowy. Wydawnictwo Książki Technicznej Respekt, 1997.[Mano95] F. Manola (ed.). X3H7 Object Model Features Matrix. GTE

Laboratories Report X3H7-93-007-v10, 1995[Micro98] Microgold Software Inc. Object-Oriented Programming Glossary.

http://www.microgold.com/Stage/Glossary.html[OMG95] Object Management Group. CORBA: The Common Object Request:

Architecture and Specification, July 1995, Release 2.0.[OrHa98] R. Orfali, D. Herkey. Client/Server Programming with Java and

CORBA. 2nd edition, John Wiley & Sons, 1998[RBPEL91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenson.

Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, New Jersey 07632, 1991

[Simo95] A.R. Simon. Strategic Database Technology: Management for the Year 2000. Morgan Kaufmann 1995.

[Slow80] Słownik poprawnej polszczyzny PWN. PWN, 1980. [SRLG+90] M. Stonebraker, L.A. Rowe, B. Lindsay, J. Gray, M. Carey, M. Brodie,

P. Bernstein, D. Beech. The Committee for Advanced DBMS Function. Third-Generation Data Base System Manifesto. ACM SIGMOD Record 19(3), pp.31-44, 1990.

[Sting98] STING Software Engineering Glossary. http://dxsting.cern.ch/sting/glossary.html

[Subi94] K. Subieta. INGRES - System Zarządzania Relacyjną Bazą Danych. Akademicka Oficyna Wydawnicza PLJ, Warszawa 1994.

[Subi97] K. Subieta. Słownik często spotykanych terminów dotyczących obiektowości. Prace IPI PAN Nr 839, wrzesień 1997.

[Subi98] K. Subieta. Obiektowość w projektowaniu i bazach danych. Akademicka Oficyna Wydawnicza PLJ, Warszawa 1998

[UML97] Unified Modeling Language, version 1.0. Rational Software Corporation, 1997, http://www.rational.com

[Webs88] Webster’s New World Dictionary. Webster’s New World, 1988.[ZdMa90] S.B. Zdonik, D. Maier. Fundamentals of Object-Oriented Databases.

In S.B. Zdonik and D. Maier (Eds.), Readings in Object-Oriented Database Systems, Morgan Kaufman, 1990, pp.1-32

238

3.Słownik -skorowidz angielsko-polski

4. Słownik-skorowidz angielsko-polski

0-91NF (First Normal

Form) 7

149pierwsza postać

normalna2+2 query fan club 89 klub fanów

zapytania 2+22NF (Second Normal

Form) 7

52druga postać

normalna2PC (Two-Phase

Commit) 7

53dwufazowe

potwierdzenie2PL (Two-Phase

Locking) 7

53dwufazowe

blokowanie3GL (Third

Generation Language)

784

język trzeciej generacji

3NF (Third Normal Form)

7202

trzecia postać normalna

4GL (Fourth Generation Language)

781

język czwartej generacji

Aabort 227 zerwanieabstract class 87 klasa abstrakcyjnaabstract data type,

ADT8 abstrakcyjny typ

danychabstract machine 102 maszyna

abstrakcyjnaabstract method 105 metoda

abstrakcyjnaabstract operation 141 operacja abstrakcyjnaabstract type 203 typ abstrakcyjnyabstraction 7 abstrakcjaaccess control 95 kontrola dostępu,

189 sterowanie dostępemaccess path 195 ścieżka dostępu accessor 10 akcesorACID (Atomicity,

Consistency, Isolation, Durability)

820

atomowość, spójność, izolacja, trwałość

action 10 akcjaactivation 11 aktywacjaactive agent 12 aktywny agentactive class 87 klasa aktywnaactive database 12 aktywna baza

danychactive DBMS 12 aktywny SZBDactive object 12

124aktywny obiekt,

obiekt aktywnyactive rules 12 aktywne reguły,

reguły aktywneactive system 193 system aktywnyActiveX 8activity 12

56aktywność, działanie

activity diagram 42 diagram aktywności actor 10 aktoractual argument 17 argument aktualnyactual parameter 148 parametr aktualnyad hoc polymorphism 153 polimorfizm ad hocad hoc query 225 zapytanie ad hocAda95 9ADT (Abstract Data

Type)89

abstrakcyjny typ danych

agent 9 agentaggregate 10 agregat

239


aggregate function 64 funkcja zagregowana

aggregate key 90 klucz złożonyaggregate object 125 obiekt zagregowany aggregation 9 agregacjaaggregation hierarchy 68 hierarchia agregacjiaglet 9 agletAgora 9alias 14 aliasaliasing 14 aliasowaniealpha 12 alfaalpha test 12 test alfaalpha testing 12 testowanie alfaalpha version 12 wersja alfaAmerican National

Standard Institute, ANSI

15 Amerykański Narodowy Instytut Standardyzacji

analysis 14 analizaancestor 165 przodek ANSI (American

National Standard Institute)

15 Amerykański Narodowy Instytut Standardyzacji

ANSI X3H2 15ANSI/SPARC

architecture 16 architektura

ANSI/SPARCant 117 mrówkaanti-pattern 15 antywzorzecantropomorphism 15 antropomorfizmany 15 dowolny API (Application

Programming Interface)

76 interfejs do programowania aplikacji

AppleScript 15applet 15 apletapplication 15 aplikacjaapplication domain 57 dziedzina

aplikacyjnaapplication generator 65 generator aplikacjiapplication

managementzarządzanie aplikacją

(aplikacjami)application program 159 program

aplikacyjnyApplication

Programming Interface, API

76 interfejs do programowania aplikacji

application sever 181 serwer aplikacji application software 141 oprogramowanie

aplikacyjne

architecture 15 architekturaargument 17 argumentAriane 5 17array 196 tablicaartifact dzieło, twór, wytwór,

artefaktassertion 18 asercjaasset 11 aktywassets 11 aktywaassignment podstawienieassociation 18 asocjacjaassociation attrribute 21 atrybut asocjacjiassociation class 87 klasa asocjacjiassociation role 176 rola asocjacjiassociative access 52 asocjacyjny dostęp,

dostęp asocjacyjnyassociative table 196 asocjacyjna tablica,

tablica asocjacyjnaasynchronicity 20 asynchronicznośćasynchronous 20 asynchronicznyasynchronous

message93 asynchroniczny

komunikat, komunikat asynchroniczny

asynchronous request 229 asynchroniczne zlecenie, zlecenie asynchroniczne

atomic 20 atomowyatomic attribute 21 atrybut atomowyatomicity 20 atomowośćAtomicity,

Consistency, Isolation, Durability, ACID

820

atomowość, spójność, izolacja, trwałość

attribute 20 atrybutattribute type 203 typ atrybutuaudit 23 audytauthorization 23 autoryzacjaauthorization

granularityziarnistość autoryzacji

automatic persistence automatyczna trwałość

autonomy autonomia

Bback end 96 kraniec tylnyback up 183 składowaniebag 214 wielozbiór

240


balanced tree, B-tree 24 zbalansowane drzewo, B-drzewo

Bancilhon, Francois 23Barry, Douglas K. 23base class 88 klasa bazowabaseball model 113 model piłki

baseballowejBasic Object Adapter,

BOA26

152podstawowy adapter

obiektówbasic type 204 typ podstawowyBCNF (Boyce-Codd

Normal Form) 24

156postać normalna

Boyce-Coddabean 61 fasolkabehavior 24

221behawior,

zachowaniebehavioral object-

orientation128 obiektowość

behawioralnabehavioral properties 215 własności

behawioralne behaviour 24

221behawior,

zachowaniebenchmark 24

185benczmark,

sprawdzianBETA 24beta 25 beta beta test 25 test betabeta testing 25 testowanie betabeta version 25 wersja betabidirectional

association19 asocjacja

dwukierunkowa, dwukierunkowa asocjacja

bidirectional link 157 dwukierunkowe powiązanie, powiązanie dwukierunkowe

bidirectional relationship

232 dwukierunkowy związek, związek dwukierunkowy

bigot 26 bigotBill-Of-Material,

BOM27 rachunek materiałów

binary association 19 asocjacja binarnabinary large object,

BLOB2653

duży obiekt binarny

binary message 94 komunikat binarnybind wiązaćbinding 212 wiązanie

bitmap 102 mapa bitowablack box 37 czarna skrzynkaBlack Widow 26BLOB (Binary Large

Object)2653

duży obiekt binarny

Blue 26BOA (Basic Object

Adapter)26

152podstawowy adapter

obiektówBOF (Business

Object Framework) 26 szkielet dla obiektów

biznesowychBOM (Bill-Of-

Material) 27 rachunek materiałów

BON (Business Object Notation)

27126

obiektowa notacja dla biznesu

Booch 27Booch, Grady 27bottom-up strategy 191 strategia od dołu do

górybounded

polymorphismpolimorfizm

ograniczonyBoyce-Codd Normal

Form, BCNF24

156postać normalna

Boyce-CoddaBPM (Business

Process Modeling) 27

116modelowanie

procesów biznesowych

BPR (Business Process Reengineering)

27171

reinżynieria procesów biznesowych

broker 156 pośrednikbrowse przeglądaćbrowser 162 przeglądarkabrowsing 161 przeglądanieB-tree (Balanced tree) 24 zbalansowane

drzewo, drzewo zbalansowane, B-drzewo

buffer 28 buforbuild-in class 89 klasa wbudowana build-in type 204 typ wbudowanybulk 102 masowybulk attribute 21 atrybut masowybulk data 38 dane masowebulk type 203 typ masowybulk value 210 wartość masowabusiness class 88 klasa biznesowa business data 38 dane biznesowe,

dane biznesubusiness domain 57 dziedzina biznesu

241


business logic 99 logika biznesubusiness object 124 obiekt biznesowyBusiness Object

Framework, BOF26 szkielet dla obiektów

biznesowychBusiness Object

Notation, BON 27

126obiektowa notacja dla

biznesuBusiness Process

Modeling, BPM27

116modelowanie


Business Process Reengineering, BPR

27171

reinżynieria procesów biznesowych

business rule 170 reguła biznesowabuzzword 28 brzęczydłobytecode 90 kod bajtowybyzantine 26 bizantyjski

CC Language

Integrated Production System, CLIPS

33 zintegrowany system produkcyjny w języku C

C/S (Client/Server) 3089

klient-serwer

C++ 30cache 28 buforCAD (Class

Association Diagram)

3142

diagram asocjacji klas

CAD (Computer Aided Design)

31160

projektowanie wspomagane komputerem

call stack 191 stos wołańcallback method 105 metoda zwrotnacall-by-name 216 wołanie poprzez

nazwęcall-by-need 216 wołanie poprzez

potrzebęcall-by-reference 216 wołanie poprzez

referencjęcall-by-value 217 wołanie poprzez

wartośćcall-by-value-return 217 wołanie poprzez

wartość ze zwrotem

Call-Level Interface, CLI

3376

interfejs poziomu wołania

CAM (Computer Aided Manufacturing)

31220

wytwarzanie wspomagane komputerem

candidate key 90 klucz kandydującyCardelli, Luka 31cardinality 96

98krotność, liczba

kardynalna, liczność

Cartridges 31cascaded message 94 komunikat

kaskadowy CASE (Computer

Aided Software Engineering)

3178

inżynieria oprogramowania wspomagana komputerem

CASE (Computer Aided System Engineering)

3178

inżynieria systemów wspomagana komputerem

cast 86178

kast, rzutowanie

cat 95 kotCatalysis 32catch an exception 161 przechwycenie

wyjątku Cattel, Rick 32Cecil 33CF (Common

Facilities) 33

217wspólne

udogodnieniaCFOM (Composition

Filters Object Model)

33 obiektowy model filtrów kompozycji

character large object, CLOB

3453

duży obiekt znakowy

checkpoint 168 punkt kontrolnyChen, Peter 33Chief Information

Officer, CIO33 główny specjalista d/s

informacjichild class 88 klasa potomnachild type 204 typ potomny Chorus Object-

Oriented Layer, COOL

35 warstwa obiektowa systemu Chorus

CIO (Chief Information Officer)

33 główny specjalista d/s informacji

citizenship 132 obywatelstwoclass 87 klasaclass association

diagram, CAD3142

diagram asocjacji klas

class attribute 21 atrybut klasyclass citizenship 132 obywatelstwo klasyclass diagram 43 diagram klasclass extent 59 ekstensja klasy

242


class hierarchy 68 hierarchia klasclass library 26 biblioteka klasclass method 105 metoda klasowaclass normalization 123 normalizacja klasclass operation 141 operacja klasowaclass structure 192 struktura klas class variable zmienna klasowaclass-based

inheritance57 dziedziczenie oparte

na klasachclassification 89 klasyfikacjaclass-responsibility-

collaborator, CRC89 klasa-

odpowiedzialność-współpraca (kolaboracja)

CLI (Call-Level Interface)

3376


client 89 klientclient/server, client-

server, C/S3089

klient-serwer

client-server architecture

17 architektura klient-serwer

CLIPS (C Language Integrated Production System)

33 zintegrowany system produkcyjny w języku C

CLOB (Character Large Object)

3453

duży obiekt znakowy

clock event 227 zdarzenie zegarowe clone klon, klonowaćcloning 89 klonowanieCLOS (Common

LISP Object System)

34 obiektowy system powszechnego LISP-u

closure property 215 własność domkniętości

CLU 34cluster 66

89grono, klaster,

organizować grona, organizować klastry

clustering 145 organizacja gron, organizacja klastrów

CO2 34Coad, Peter 34Coad/Yourdon 34Cobol Object-

Oriented Language, COOL

35 obiektowy język Cobol

COBRA 34coercion 90 koercjacohesion 91 kohezja

collaboration 91 kolaboracja, współpraca

collaboration context 94 kontekst kolaboracji, kontekst współpracy

collaboration diagram 44 diagram kolaboracji, diagram współpracy

collection 91 kolekcjaCollection Service 209 usługa w zakresie

kolekcjiCOM (Common

Object Model)34

157113

powszechny model obiektowy

COM (Component Object Model)

34157113

model obiektowy dla komponentów

COM+ 35commit 156 potwierdzenieCommon Facilities,

CF33

217wspólne

udogodnieniaCommon LISP Object

System, CLOS34 obiektowy system

powszechnego LISP-u

Common Object Model, COM

34157113

powszechny model obiektowy

Common Object Request Broker Architecture, CORBA

35 architektura powszechnego pośrednika obiektowych zleceń

compensation subtransaction

podtransakcja kompensująca

compile-time 38 czas kompilacjicomplete partition 152 kompletny podział,

podział kompletnycomplex attribute 23

230atrybut złożony,

złożony atrybutcomplex object 126

230obiekt złożony,

złożony obiektcomplexity 230 złożonośćcompliant zgodny (z czymś)component 92 komponentcomponent

architecture17 architektura

komponentowa Component Broker 35component diagram 45 diagram

komponentówComponent Object

Model, COM34

157113

model obiektowy dla komponentów

component software 141 oprogramowanie komponentowe

243


componentware 141 oprogramowanie komponentowe

composed object 125 obiekt kompozytowycomposite attribute 21

23230

atrybut kompozytowy, atrybut złożony, złożony atrybut

composite key 90 klucz złożony, złożony klucz

composite object 125126230

obiekt kompozytowy, obiekt złożony, złożony obiekt

composite type 203 typ kompozytowycomposition 92 kompozycjaComposition Filters

Object Model, CFOM

33 obiektowy model filtrów kompozycji

compositionality 93 kompozycyjnośćcompound key 90 klucz złożony,

złożony kluczcomputational

completeness91 kompletność

obliczeniowaComputer Aided

Design, CAD31

160projektowanie

wspomagane komputerem

Computer Aided Manufacturing, CAM

31220


Computer Aided Software Engineering, CASE

3178

inżynieria oprogramowania wspomagana komputerem

Computer Aided System Engineering, CASE

3178

inżynieria systemów wspomagana komputerem

Computer Supported Cooperative Work, CSCW

37 komputerowe wspomaganie pracy grupowej

conceptual 94153

konceptualny, pojęciowy

conceptual data model 153 pojęciowy model danych

conceptual model 113 model pojęciowyconceptual modeling 116 modelowanie

pojęcioweconceptual schema 180 schemat pojęciowyconcrete class 88 klasa konkretnaconcrete type 203 typ konkretnyconcurrency 218 współbieżnośćConcurrency Control 208 usługa w zakresie

Service współbieżnościconcurrent access 213 wielodostęp concurrent object 125 obiekt współbieżnyConcurrent Object-


35 współbieżny język obiektowy

condition warunek consistency 185 spójnośćconstraint 136 ograniczenieconstructed type 203 typ konstruowanyconstructor 94 konstruktorcontainer 94 kontenercontainer class 88 klasa kontenerowacontainer object 125 obiekt kontenerowycontract 94 kontraktcontravariancy 95 kontrawariancjacontrol flow 163 przepływ sterowaniacontrol flow diagram 48 diagram przepływu

sterowaniacontrol object 125 obiekt sterującyCOOL (Chorus

Object-Oriented Layer)

35 warstwa obiektowa systemu Chorus

COOL (Cobol Object-Oriented Language)

35 obiektowy język Cobol

COOL (Concurrent Object-Oriented Language)

35 współbieżny język obiektowy

copy semantics 181 semantyka oparta na kopiowaniu

CORBA (Common Object Request Broker Architecture)

35 architektura powszechnego pośrednika obiektowych zleceń

CORBA 1.1 37CORBA 2.0 37CORBA 3.0 37correspondence

principle225 zasada

korespondencji couple kojarzyćcoupling 183 skojarzeniecovariancy 95 kowariancjaCRC (Class-

Responsibility-Collaborator)

89 klasa-odpowiedzialność-współpraca (kolaboracja)

CRC card 85 karta CRCCRC model 110 model CRC

244


CRC modeling 116 modelowanie CRC create 209 utwórzCreate, Retrieve,

Update, Delete, CRUD

37 tworzenie, wyszukiwanie, aktualizacja, usuwanie

creating tworzeniecritique 96 krytykaCRUD (Create,

Retrieve, Update, Delete)

37 tworzenie, wyszukiwanie, aktualizacja, usuwanie

CSCW (Computer Supported Cooperative Work)

37 komputerowe wspomaganie pracy grupowej

currency indicator wskaźnik bieżącycursor 97 kursor

D DDAIS 38dangling link 232 powiązanie zwisające,

zwisające powiązanie

dangling pointer 232 wskaźnik zwisający, zwisający wskaźnik

data abstractions 8 abstrakcje danychdata base

administrator, DBA 9 administrator bazy

danych Data Base

Programming Language, DBPL

3983

język programowania baz danych

data base, DB 2339

baza danych

data cube 95 kostka danychData Definition

Language, DDL408283

język definicji danych

Data Description Language, DDL

408283

język opisu danych

data dictionary 86183

katalog danych, słownik danych

data dictionary-directory, DDD

4086

katalog danych, słownik-przewodnik danych

data flow 163 przepływ danychdata flow diagram,

DFD47 diagram przepływu

danych, DPDdata flow model 114 model przepływu

danychdata independence 120 niezależność danychData Manipulation

Language, DML5182

język manipulacji danymi

data mart 71100183

składnica danych, hurtownia danych, magazyn danych

data mining 58 eksploracja danychdata model 110 model danychdata normalization 123 normalizacja danychdata semantics 181 semantyka danych data store 183 skład danychdata warehouse 71

100hurtownia danych,

magazyn danychdatabase management

system, DBMS39

193194

system zarządzania bazą danych, SZBD

database procedure 158 procedura bazy danych

database schema 179 schemat bazy danych

database view 149 perspektywa bazy danych

DataBlades 39DataExtenders 39DB (Data Base) 23

39baza danych

DB2 Universal Database

39

DBA (data base administrator)

939

administrator bazy danych

DBMS (Data Base Management System)

39193194

system zarządzania bazą danych, SZBD

DBPL (Data Base Programming Language)

3983

język programowania baz danych

DCE (Distributed Computing Environment)

39 rozproszone środowisko obliczeniowe

DCOM (Distributed Common Object Model)

39176

rozproszony powszechny model obiektowy

DDD (Data Dictionary-Directory)

4086

katalog danych, słownik-przewodnik danych

DDL (Data Definition Language)

408283

język definicji danych

DDL (Data Description

4082

język opisu danych

245


Language) 83deactivation 40 deaktywacjadeadlock 26

222blokada,

zakleszczenieDecision Support

System, DSS53 system wspomagania

decyzjideclaration 40 deklaracjadeclarative 40 deklaracyjnydeclarative language 82 język deklaracyjnydecomposition 40 dekompozycjaDeductive and

Object-Oriented Databases, DOOD

52 dedukcyjne i obiektowe bazy danych

deductive object-oriented

40 dedukcyjno-obiektowe

deep comparison 155 porównanie głębokiedefacto standard 188 faktyczny standard,

standard faktycznydefault 51 domyślnydefault attribute 21 atrybut domyślnydefault value 210 wartość domyślnadeferred class 88 klasa opóźnionadejure standard 188 standard prawnydelegation 40

41delegacja,

delegowaniedelete 209 usuńdeleting usuwanieDelphi 41denormalization 41 denormalizacjadependent join 223

230zależne złączenie,

złączenie zależnedeployment 177 rozprzestrzenianie,

wdrażaniedeployment diagram 49 diagram

rozprzestrzeniania, diagram wdrożenia, diagram wdrożeniowy

deputy object 125 obiekt zastępczydereference wykonywać

dereferencjędereferencing 41 dereferencjaderivation 42 derywacjaderived 150

219pochodny,

wyliczalnyderived association 19 asocjacja pochodnaderived attribute 21

22atrybut pochodny,

atrybut wyliczalny

derived class 88 klasa pochodnaderived element 59 element pochodnyderived link 157 powiązanie

pochodnederived operation 141 operacja pochodnaderived relationship 232 związek pochodny derived type 204 typ pochodnydesign 160 projektowaniedesign by contracts 160 projektowanie przez

kontraktydesign pattern 220 wzorzec projektowydesign transaction 200 transakcja

projektowa Designing Object-

Oriented Software, DOOS

52 projektowanie obiektowego oprogramowania

destructor 42 destruktorDFD (Data Flow

Diagram) 424752

diagram przepływu danych, DPD

diagram 42 diagramdictionary 183 słownikDII (Dynamic

Invocation Interface)

51 interfejs dynamicznych wołań

dinosaur 51 dinozaurdirect ancestor 25 bezpośredni

przodek, przodek bezpośredni

dirty object 28 brudny obiekt dirty page 27 brudna stronadirty programming 27 brudne

programowanie dirty read 28 brudny odczytdiscriminated union 207 unia z

dyskryminatorem discriminator 55 dyskryminatordispatch dysponowaćdispatching 56 dyspozycjadistinct type 204 typ rozróżnionyDistributed Common

Object Model, DCOM

39176

rozproszony powszechny model obiektowy

Distributed Computing Environment, DCE

39 rozproszone środowisko obliczeniowe

distributed database 176 rozproszona baza danych

Distributed Object 51 rozproszone

246


Environment, DOE środowisko obiektów

Distributed Object Management Environment, DOME

51 rozproszone środowisko zarządzania obiektami

Distributed Object Management Facility, DOMF

51 rozproszone udogodnienie do zarządzania obiektami

distributed object system

176 rozproszony system obiektowy

distributed objects 130176

obiekty rozproszone, rozproszone obiekty

Distributed Smalltalk

51

Distributed Standard Object Model, DSOM

53 rozproszony standardowy model obiektowy

distribution transparency

165 przezroczystość rozproszenia

DML (Data Manipulation Language)

5182


DOE (Distributed Object Environment)

51 rozproszone środowisko obiektów

dog 149 piesdomain 57 dziedzina domain relational

calculusdziedzinowy

rachunek relacyjnydomain-level

frameworksszkielety na poziomie

dziedzinDOME (Distributed

Object Management Environment)

51 rozproszone środowisko zarządzania obiektami

DOMF (Distributed Object Management Facility)

51 rozproszone udogodnienie do zarządzania obiektami

Domino 5.0 51DOOD (Deductive

and Object-Oriented Databases)

52 dedukcyjne i obiektowe bazy danych

DOOS (Designing Object-Oriented Software)

52 projektowanie obiektowego oprogramowania

dot expression 219 wyrażenie kropkowedowncast 86 kast w dół drag and drop przesuń i upuść

DSI (Dynamic Skeleton Interface)

52 interfejs dynamicznego szkieletu

DSOM (Distributed Standard Object Model)

53 rozproszony standardowy model obiektowy

DSS (Decision Support System)

53 system wspomagania decyzji

dump zrzucać, zrzutdumping zrzutdurability 202 trwanieDylan 54dynamic array 197 tablica dynamicznadynamic binding 212 dynamiczne wiązanie,

wiązanie dynamiczne

dynamic checking 95 dynamiczna kontrola, kontrola dynamiczna

dynamic classification 5589

dynamiczna klasyfikacja, klasyfikacja dynamiczna

dynamic dispatching 54 dynamiczna dyspozycja

dynamic inheritance 56 dynamiczne dziedziczenie, dziedziczenie dynamiczne

Dynamic Invocation Interface, DII

51 interfejs dynamicznych wołań

dynamic model 111 model dynamicznydynamic

programming159 programowanie

dynamicznedynamic scope 222 zakres dynamiczny Dynamic Skeleton

Interface, DSI52 interfejs

dynamicznego szkieletu

dynamic SQL 55 dynamiczny SQLdynamic type

checking55 dynamiczna

kontrola typówdynamic typing 55 dynamiczna

kontrola typów

EE 57early binding 212 wczesne wiązanie,

wiązanie wczesneECA (Event-

Condition-Action)58

227zdarzenie-warunek-

247


akcjaeclectic 58 eklektycznyECOOP (European

Conference on Object-Oriented Programming)

58 europejska konferencja programowania obiektowego

EER (Extended Entity-Relationship)

58 rozszerzony model encja-związek

Eiffel 58EIS (Executive

Information Systems)

58 wykonawczy system informacyjny

elephant 183 słońelipse/circle dilemma 54 dylemat elipsy i kołaembed zanurzaćembedded 224 zanurzonyembedded query 224

225zanurzone zapytanie,

zapytanie zanurzone

embedded relations 221 relacje zagnieżdżone, zagnieżdżone relacje

embedding zanurzenieEmerald 59encapsulation 60

6685

enkapsulacja, hermetyzacja, kapsułkowanie

Encore 60entity 59 encjaentity object 125 obiekt rzeczywistyEntity-Relationship

Diagram, ERD42 diagram encja-

związekentity-relationship

model, ERM60

111model encja-związek

Entity-Relationship Object-Oriented Specification, EROOS

60 obiektowa specyfikacja encji-związków

entity-relationship, ER

60 encja-związek

enumeration type 205 typ wyliczeniowy environment 147

196otoczenie,

środowiskoenvironment stack 190 stos środowiskenvironmental stack 190 stos środowiskowyEnvironment-Specific

Inter-ORB Protocols, ESIOP

60 protokół pomiędzy ORB-ami specyficzny dla środowiska

ER (Entity- 60 encja-związek

Relationship)ERD (Entity-

Relationship Diagram)

42 diagram encja-związek

ERM (Entity-Relationship Model)

60111

model encja-związek

EROOS (Entity-Relationship Object-Oriented Specification)

60 obiektowa specyfikacja encji-związków

ESIOP (Environment-Specific Inter-ORB Protocols)

60 protokół pomiędzy ORB-ami specyficzny dla środowiska

European Conference on Object-Oriented Programming, ECOOP

58 europejska konferencja programowania obiektowego

event 227 zdarzenieevent attribute 22 atrybut zdarzeniaEvent Service 208 usługa w zakresie

zdarzeńEvent-Condition-

Action, ECA58

227zdarzenie-warunek-

akcjaevent-driven 190 sterowany

zdarzeniamievent-driven

programming159160

programowanie sterowane zdarzeniami, programowanie zdarzeniowe

event-trace diagram 50 diagram tropów zdarzeń

exception 219 wyjątekexception attribute 22 atrybut wyjątkuexception catch 161 przechwycenie

wyjątkuexception handler 103 mechanizm obsługi

wyjątkówexception handling 131 obsługa wyjątkówexchange format 62 format wymianyExecutive

Information Systems, EIS

58 wykonawczy system informacyjny

Exodus 60Expertsoft 60export 59 eksportexport list 98 lista eksportowaexported feature 32 cecha eksportowanaExpress 60

248


Extended Entity-Relationship, EER

58 rozszerzony model encja-związek

extended RDBMS 178 rozszerzony RSZBDextended relational

DBMS 177 rozszerzony

relacyjny SZBDextends rozszerzaextensibility 177 rozszerzalnośćextension 59 ekstensjaextent 59 ekstensjaexternal attribute 22 atrybut zewnętrznyExternalization

Service208 usługa w zakresie

udostępniania na zewnątrz

F Ffactor (out) wyciągać mnożnikfactor (out) wyciągać przed

nawiasfactoring (out) 218 wyciąganie

mnożnikafactoring (out) 218 wyciąganie przed

nawiasfactory 61 fabrykafactory method 105 metoda fabrykująca FAQ (Frequently

Asked Questions) 61 często zadawane

pytaniafat client 110 mocny klient, tłusty

klientfeasibility study 192 studium osiągalnościfederated database 62 federacyjna baza

danychfederated schema 179 schemat federacyjny Fibonacci 62field 153 polefield variable 231 zmienna polowafile 150 plikfinal state 188 stan końcowyfire 220 wyzwolić, uruchomićFirst Normal Form,

1NF7

149pierwsza postać

normalnafirst-class citizen 131 obywatel pierwszej

kategoriifixed format 62 format stałyfixed-point operator operator punktu

stałegoflame 96 krytyka,

nieuprzejmośćflat file 150 płaski plik

flexibility 59 elastyczność F-logic 62flowchart 48 diagram blokowy,

diagram przepływu sterowania

foreign key 90123

klucz obcy, obcy klucz

foreign operation 141 operacja obcaform 62 formularzformal argument 17 argument formalnyformal parameter 148 parametr formalnyforward engineering 78 inżynieria prostaFourth Generation

Language, 4GL7

81język czwartej

generacjiFP (Function Point) 62

168punkt funkcyjny

FPA (Function Point Analysis)

1462

analiza punktów funkcyjnych

framework 195 szkieletFrequently Asked

Questions, FAQ61 często zadawane

pytaniaFresco 62friend class 89 klasa

zaprzyjaźnionafriend function 64 funkcja

zaprzyjaźnionafriendliness 165 przyjaznośćfront end 96 kraniec frontowyfunction 63 funkcjaFunction Point

Analysis, FPA1462


Function Point, FP 62168

punkt funkcyjny

functional funkcjonalny, funkcyjny

functional funkcyjnyfunctional

dependency223 zależność funkcyjna

functional model 111112

model funkcjonalny, model funkcyjny

functional procedure 158 procedura funkcyjna

Fusion 64

Ggang of four, GOF 23 banda czworgagarbage collection 135

226odśmiecanie,

zbieranie nieużytków

249


garbage collector, GC 64103135

mechanizm zbierania nieużytków, odśmiecacz

Garbage In - Garbage Out, GIGO

65 śmiecie na wejściu - śmiecie na wyjściu

gateway 154 pomostGC (Garbage

Collector)64

103135

mechanizm zbierania nieużytków, odśmiecacz

GCC 64GemORB 64Gemstone 64General Inter-ORB

Protocol, GIOP65 ogólny protokół

między pakietami ORB

generalization 65 generalizacjageneric 65 generycznygeneric class 88 klasa generycznageneric function 63

65funkcja generyczna,

generyczna funkcjageneric programming 65

159generyczne

programowanie, programowanie generyczne

generics 64 generalia, generaliumGeographic

Information System, GIS

65193

system informacji geograficznej

gigabyte 65 gigabajt GIGO (Garbage In -

Garbage Out) 65 śmiecie na wejściu -

śmiecie na wyjściu GIOP (General Inter-

ORB Protocol)65 ogólny protokół

między pakietami ORB

GIS (Geographic Information System)

65193

system informacji geograficznej

glass box 195 szklana skrzynka global object 124 obiekt globalnyglobal schema 179 schemat globalny global variable 65

230globalna zmienna,

zmienna globalnaGNU E 66GOF (Gang Of Four) 23

66banda czworga

Goldberg, Adele 66granularity 228 ziarnistośćgraphical user 66 graficzny interfejs

interface, GUI 76 użytkownika, interfejs graficzny użytkownika

groupware 119 narzędzia do pracy grupowej

guard 191 strażnikGUI (Graphical User

Interface)6676

graficzny interfejs użytkownika, interfejs graficzny użytkownika

HHAD

(Heterogeneous, Autonomous, Distributed)

6668

heterogeniczny, autonomiczny, rozproszony

Harel diagram 43 diagram Harelahash 109 mieszać, mieszaniehash coding kodowanie

mieszającehash function 63 funkcja mieszającahash table tablica z kodowaniem

mieszającymhashing kodowanie

mieszająceheap 190 stertaHenderson-Sellers,

Brian66

heterogeneous 68 heterogenicznyheterogeneous

database68 heterogeniczna baza

danaheterogeneous,

autonomous, distributed, HAD

6668

heterogeniczny, autonomiczny, rozproszony

hierarchical library 69 biblioteka hierarchiczna, hierarchiczna biblioteka

hierarchical model 112 model hierarchicznyHierarchical Music

Specification Language, HMSL

69 hierarchiczny język do specyfikacji muzyki

higher-order function 63 funkcja wyższego rzędu

higher-order object-oriented programming

159 programowanie obiektowe wyższego rzędu

higher-order programming

159 programowanie wyższego rzędu

HMSL (Hierarchical Music Specification

69 hierarchiczny język do specyfikacji

250


Language) muzykihomomorphism 69 homomorfizmhomonimic 69 homonimicznyhorizontal common

facilities218 wspólne

udogodnienia poziome

host language język-gospodarzhost variable zmienna gospodarzahybrid 71 hybrydowy

IIceberg 71IDB Object

Database 71

identifier 71 identyfikatoridentity 199 tożsamośćidiom 72 idiom idiot 72 idiotaIDL (Interface

Definition Language)

7282

język definicji interfejsu

IDP (Iterative Development Process)

7379

iteracyjny proces rozwoju

IIOP (Internet Inter-ORB Protocol)

73 internetowy protokół między pakietami ORB

IIOP firewall support wspomaganie dla zapory ogniowej protokółu IIOP

Illustra 74ILU (Inter-Language

Unification) 74 unifikacja

międzyjęzykowaimmutable 122 niezmienialnyimmutable object 125 obiekt niezmienialnyimpedance mismatch 120 niezgodność

impedancjiimperative 74 imperatywnyimperative language 82 język imperatywny implementation 74 implementacjaimplementation

inheritance56 dziedziczenie

implementacjiimplementation

repository174 repozytorium

implementacji import 74 importimport list 99 lista importowainclusion

polymorphism153 polimorfizm

inkluzyjny

incomplete partition 152 podział niekompletny

incremental 166 przyrostowyindex 74 indeksindices 74 indeksyindirect ancestor 156

165pośredni przodek,

przodek pośredniindirection table 197 tablica pośrednia,

tablica przejśćinformation hiding 205 ukrywanie

informacjiinformation system,

IS78

182system informacyjny,

SIInformix Dynamic

Server 75

Informix Universal Server

75

Ingres 75Ingres II 75inheritance 56 dziedziczenieinheritance graph 66 graf dziedziczeniainheritance hierarchy 68 hierarchia

dziedziczeniainitial state 188 stan początkowyinsert 218 wstaw, wstawiaćinserting wstawianieinside-out strategy 191 strategia od środka

na zewnątrzinstance 75

220instancja,

wystąpienieinstance attribute 22 atrybut wystąpieniainstance method 105 metoda wystąpieniainstance variable 231 zmienna wystąpieniainstatiation 202 tworzenie

wystąpienia, tworzenie wystąpień

integrity 75 integralnośćintegrity constraints 136

214ograniczenia

integralnościowe, więzy integralności

intelligent 76 inteligentny interaction diagram 43 diagram interakcjiinteractive query 76

225interakcyjne

zapytanie, zapytanie interakcyjne

interface 76 interfejsInterface Definition

Language, IDL7282


interface inheritance 57 dziedziczenie

251


interfejsuinterface object 124 obiekt interfejsuinterface repository,

IR78

174repozytorium

interfejsówintergalactic

dataspeak76 intergalaktyczny

język danych Inter-Language

Unification, ILU74 unifikacja

międzyjęzykowainternal attribute 22 atrybut wewnętrznyinternal schema 180 schemat wewnętrzny International Standard

Organization, ISO78 Międzynarodowa

Organizacja Standardyzacji

Internet Inter-ORB Protocol, IIOP

73 internetowy protokół między pakietami ORB

interoperability 76218

interoperacyjność, współdziałanie

intersection przecięcieinvariancy 77 inwariancjainvariant 77

122inwariant,

niezmiennyIR (Interface

Repository) 78

174repozytorium

interfejsów Iris 78IS (Information

System)78

182system informacyjny,

system informatyczny, SI

is-a 78is-a relationship 231 związek „jest”ISO (International

Standard Organization)

78 Międzynarodowa Organizacja Standardyzacji

ISO 9001 78ISO 9003 78isolation 79 izolacjaisolation levels poziomy izolacjiItasca 78iteration 78 iteracjaiterative development

process, IDP7379

iteracyjny proces rozwoju

iterative process 79158

iteracyjny proces, proces iteracyjny

iterator 79 iterator

JJacobson, Ivar 79Jade 79

Jasmine 79Java 80Java binding wiązanie do JavaJava Data Base

Connectivity, JDBC81 połączenie do baz

danych z JavaJava Developer Kit,

JDK81 zestaw rozwoju

oprogramowania w Java

Java IDL 80Java Object

Environment, JOE85 środowisko

obiektowe JavaJava Virtual Machine,

JVM8085

103

maszyna wirtualna języka Java

JavaBeans 80Javascript 81JavaSoft 81JDBC (Java Data

Base Connectivity) 81 połączenie do baz

danych z JavaJDK (Java Developer

Kit) 81 zestaw rozwoju


JOE (Java Object Environment)

85 środowisko obiektowe Java

join 229 złączeniejoin dependency zależność

złączeniowaJOOP (Journal of

Object-Oriented Programming)

85 czasopismo z zakresu programowania obiektowego

Journal of Object-Oriented Programming, JOOP

85 czasopismo z zakresu programowania obiektowego

JVM (Java Virtual Machine)

85103

maszyna wirtualna języka Java

KKay, Alan 86KBMS (Knowledge

Base Management System)

86194

system zarządzania bazą wiedzy

key 90 kluczKim, Won 86knowledge base 23 baza wiedzyKnowledge Base

Management System, KBMS

86194

system zarządzania bazą wiedzy

252


Llanguage mapping 136 odwzorowanie

językowelate binding 157

212późne wiązanie,

wiązanie późnelattice 96 kratalaw of Demeter 158 prawo Demeteralazy evaluation 97 leniwa ewaluacjalazy initialization 98 leniwa inicjalizacjalegacy 184

185spadek, spadkowy

legacy application 15226

aplikacja spadkowa, zastosowanie spadkowe

legacy software 142 oprogramowanie spadkowe

lexical scope 222 zakres leksykalny Liana 98Licensing Service 208 usługa w zakresie

licencjiLife Cycle Service 208 usługa w zakresie

cyklu życiowegolife-cycle model 110 model cyklu

życiowegolinguistic reflection 170 refleksja

lingwistycznalink 157 powiązać,

powiązanielink attribute 21 atrybut powiązanialinking 94

212konsolidacja,

wiązanieLiskov Substitution

Principle, LSP99 zasada zamienialności

Liskovliteral 99 literal, literałlocal object 125 obiekt lokalnylock 26

223blokada, zablokować,

zamek, zamknąćlocking granularity ziarnistość

blokowania, ziarnistość zamykania

log 57 dzienniklogical design 160 projektowanie

logicznelogical identifier 72 identyfikator

logicznylogical schema 180 schemat logicznyLoglan 99

long transaction 51 długa transakcjaloose coupling 100 luźne powiązanieLoqis 99LotusNotes 99LSP (Liskov

Substitution Principle)

99 zasada zamienialności Liskov

l-value 100 l-wartość

MMainstreamObjects 100maintainability 149 pielęgnacyjnośćmaintenance 94

149konserwacja,

pielęgnacja, utrzymanie

Major Object-Oriented SQL Extensions, MOOSE

117 główne obiektowe rozszerzenia SQL

management information system, MIS

109 system informatyczny do zarządzania

manifesto 100 manifestmap odwzorowaćmapping odwzorowaniemark and sweep 231 znacz i zamiatajmarshalling 195 szeregowanieMartin, James 102Martin/Odell 102materialized view 230 zmaterializowana

perspektywaMatisse 103mediator 103 mediatorMelton, Jim 104member 38 członekmember function 63 funkcja członkowskamemory leak 219 wyciekanie pamięcimemory leakage 219 wyciekanie pamięcimental model 113 model mentalnymerge połączyć, zlać, scalićmerging połączenie, zlanie,

scaleniemessage 93 komunikatmessage passing 164 przesyłanie

komunikatówmessaging obsługa komunikatówmetaclass 104 metaklasa

253


metadata 104 metadanemetamodel 104 metamodelmetaphor 104 metaforamethod 104 metodamethod body 33

201ciało metody, treść

metodymethod parameter 148 parametr metodymethod

polymorphism154 polimorfizm metod

methodology 105 metodologia, metodyka

Methodology for Object-oriented Software Engineering of Systems, MOSES

117 metodyka dla obiektowej inżynierii oprogramowania systemów

metric 107109

metryka, miara

metrix suite 228 zestaw miar Meyer, Bertrand 109Microsoft Repository 117 repozytorium

MicrosoftuMicrosoft Transaction

Server, MTS118 serwer transakcji

Microsoftumiddleware 142 oprogramowanie

pośrednicząceMiller limit 136 ograniczenie Milleramirror 173 kopia, replikacjaMIS (Management

Information System)

109 system informatyczny do zarządzania

mixin class 88 klasa mieszanamobile agent 109 mobilny agentmobile code 109 mobilny kodmobile programming 109 mobilne

programowaniemobile workflow mobilny przepływ

prac model model, modelowaćModel-View-

Controller, MVC116 model-perspektywa-

sterownikmodifier 117 modyfikatorModula-3 116modularity 116 modularnośćmodularization 116 modularyzacjamodule 116 modułmodule diagram 46 diagram modułówmonomorphism 117 monomorfizm

Montage 117MOOSE (Major

Object-Oriented SQL Extensions)

117 główne obiektowe rozszerzenia SQL

MOSES (Methodology for Object-oriented Software Engineering of Systems)

117 metodyka dla obiektowej inżynierii oprogramowania systemów

MS Repository 117 repozytorium Microsoftu

MTS (Microsoft Transaction Server)

118 serwer transakcji Microsoftu

multi-inheritance 213 wielodziedziczeniemultimedia attribute 21 atrybut

multimedialnymultimedia, multi-

media118 multimedia,

multimedialnymultiple dispatching 213 wielokrotna

dyspozycjamultiple inheritance 213 wielokrotne

dziedziczeniemultiple interfaces 214 wielokrotne

interfejsymultiplicity 96

98krotność, liczność

multiset, multi-set 214 wielozbiórmulti-threaded 214 wielowątkowy multi-tiered

architecture17

214architektura

wielowarstwowa, wielowarstwowa architektura

multi-valued attribute 22214

atrybut wielowartościowy, wielowartościowy atrybut

multi-valued dependency

zależność wielowartościowa

mutability 230231

zmienialność, zmienność

mutable 230 zmienialnyMVC (Model-View-

Controller)116118

model-perspektywa-sterownik

Nname 119 nazwaname clash 94 konflikt nazwname conflict 94 konflikt nazw name type

conformance120 nazwowa zgodność

typów

254


name type equivalence

120 nazwowa równoważność typów

Naming Service 208 usługa w zakresie nazywania

n-ary association 19 asocjacja n-arnanatural join 119

229naturalne złączenie,

złączenie naturalnenavigation 119 nawigacjanavigational access 52 dostęp nawigacyjnynavigational join 119

229nawigacyjne

złączenie, złączenie nawigacyjne

NEOnet 120nest zagnieżdżaćnested 222

224zagnieżdżony,

zanurzonynested query 222

225zagnieżdżone

zapytanie, zapytanie zagnieżdżone

nested relations 221 relacje zagnieżdżone, zagnieżdżone relacje

nested transactions 221 transakcje zagnieżdżone, zagnieżdżone transakcje

nesting zagnieżdżanie network data model 182 sieciowy model

danych network model 115 model sieciowynew 123 nowyNF2, NF2 (Non-First-

Normal-Form) 120122

nieznormalizowane relacje, relacje nieznormalizowane

NIH (Not-Invented-Here)

122 nie wynalezione tutaj

NIH syndrome 193 syndrom NIH NIL (null value) 122

210NIL (wartość zerowa)

Non-First-Normal-Form, NF2, NF2

120122

nieznormalizowane relacje

non-normalized relations

120122


non-object 120 nieobiektnon-procedural 120 nieproceduralnynon-procedural

language82 język

nieproceduralnynonsense 28 bzdura, nonsens

255


non-stable iterator 79 iterator niestabilnynormalization 122 normalizacjanotation 123 notacjanotifier powiadamiający,

powiadomienieNot-Invented-Here,

NIH122 nie wynalezione tutaj

NULL (null value) 123210

NULL (wartość zerowa)

null value, NIL, NULL

123210

wartość zerowa, NIL, NULL

OO2, O2 123OA&D (Object

Analysis and Design)

14123126139

analiza i projektowanie obiektowe

Oberon-2 123object 123 obiektobject adapter 9 adapter obiektówobject algebra 12

126algebra obiektowa,

obiektowa algebraobject analysis and

design, OA&D14

123126139


object base 23 baza obiektówobject code kod do konsolidacji,

kod obiektowyObject Currents 130Object Data

Management Group, ODMG

133 grupa (komitet) zarządzania obiektowymi danymi

Object Database Management Group, ODMG

133 grupa (komitet) zarządzania obiektową bazą danych

object database management system, ODBMS

129139147

obiektowy system zarządzania bazą danych, OSZBD

object database, ODB 126132

obiektowa baza danych

Object Definition Language, ODL

82133

język definicji obiektów

object diagram 46 diagram obiektówObject Domain 130object hierarchy 69 hierarchia obiektu object identifier, OID 72

136identyfikator

obiektu, obiektowy

identyfikatorobject identity, OID 72

136tożsamość obiektu

object interaction diagram

43 diagram interakcji obiektów

object life cycle 37 cykl życia obiektuobject lifeline 98 linia życia obiektuobject lifetime 38 czas życia obiektuObject Linking and

Embedding, OLE136 wiązanie i

zagnieżdżanie obiektów

Object Lisp 130Object Magazine

Online130

Object Management Architecture, OMA

137 architektura zarządzania obiektami

Object Management Group, OMG

138 grupa (komitet) zarządzania obiektami

Object Manipulation Language, OML

82138

język manipulacji obiektami

object migration 109 migracja obiektówobject model 113 model obiektów,

model obiektowyObject Modeling

Technique, OMT138197

technika modelowania obiektów

object name 120 nazwa obiektuobject query

language, OQL128143

obiektowy język zapytań

Object Request Broker, ORB

144156

pośrednik zleceń obiektowych

object schema 180 schemat obiektowyObject Services, OS 146

208usługi obiektowe

object SQL, OSQL 146 obiektowy SQLobject state 188 stan obiektuobject store 183 skład obiektówobject structure 192 struktura obiektów object structure

diagram50 diagram struktury

obiektówObject Transaction

Monitor, OTM147 obiektowy monitor

transakcjiobject view 126

149obiektowa

perspektywa, perspektywa obiektowa

object-based 24 bazujący na obiektach

256


ObjectBroker 130Objective C 131Objective Pascal 131Objectivity/DB 131ObjectLOGO 131object-orientation 128 obiektowośćobject-oriented

analysis & design, OOAD

14123126139

analiza i projektowanie obiektowe, obiektowa analiza i projektowanie

Object-Oriented Analysis / Object-Oriented Design, OOA/OOD

126138

obiektowa analiza / obiektowe projektowanie

object-oriented analysis and design, OOAD

14123126139


object-oriented analysis, OOA

14126138

analiza obiektowa, obiektowa analiza

object-oriented CASE system

129 obiektowy system CASE, obiektowy system wspomagania inżynierii oprogramowania

object-oriented CASE, OO-CASE

128 obiektowy CASE

Object-Oriented Cobol, OO-Cobol

139 obiektowy COBOL

object-oriented data base management system, OODBMS

129139147


Object-Oriented Database System Manifesto

101 manifest obiektowych systemów baz danych

object-oriented database, OODB

126139


Object-Oriented Design with Applications, OODA

139 obiektowe projektowanie z aplikacjami

object-oriented design, OOD

127139160

obiektowe projektowanie, projektowanie obiektowe

Object-Oriented Fortran, OOF

139 obiektowy Fortran

object-oriented humour

69 humor obiektowy

Object-Oriented Information Systems, OOIS

139 obiektowe systemy informacyjne

object-oriented language

83 język obiektowy

object-oriented measurements

109 miara obiektowa

object-oriented methodology

106 metodyka obiektowa

object-oriented metric 108 metryka obiektowaobject-oriented model 113 model obiektowyobject-oriented

modeling116 modelowanie

obiektoweobject-oriented

operating system129 obiektowy system

operacyjnyobject-oriented

programming language, OOPL

128140

obiektowy język programowania

Object-Oriented Programming Systems, Languages and Applications, OOPSLA

140 obiektowe systemy programowania, języki i zastosowania

object-oriented programming, OOP

140159

programowanie obiektowe

object-oriented query language

128 obiektowy język zapytań

Object-Oriented System Analysis, OOSA

140 obiektowa analiza systemów

Object-oriented System Analysis, OSA


object-oriented view 149 perspektywa obiektowa

object-oriented visual programming

126 obiektowe programowanie wizyjne

object-oriented, OO 127138231

obiektowo zorientowany, obiektowy, zorientowany obiektowo

object-orientedness 128 obiektowośćObjectory 131object-relational 127 obiektowo-relacyjnyObject-Relational

Database Management System, ORDBMS

128145

obiektowo-relacyjny system zarządzania bazą danych, ORSZBD

object-relational DBMS

128145

obiektowo-relacyjny SZBD

257


objects-by-value 130 obiekty jako wartości

ObjectStore 131Object-Z 131Occam’s razor 28 brzytwa OccamaOdapter 132ODB (Object Data

Base)126132

obiektowa baza danych, OBD

ODBC (Open Data Base Connectivity)

132 otwarte połączenie do baz danych

ODB-II 133ODBMS (Object

DataBase Management System)

129133139147


Ode 133ODL (Object


82133


ODMG (Object Data Management Group)

133 grupa (komitet) zarządzania obiektowymi danymi

ODMG (Object Database Management Group)

133 grupa (komitet) zarządzania obiektową bazą danych

ODMG 2.0 133ODMG object model 113 model obiektowy

ODMGODMG-93 135offset 164 przesunięcieOID (Object

Identifier)72

136identyfikator

obiektu, obiektowy identyfikator

OID (Object Identity) 72136

tożsamość obiektu

OLAP (On Line Analytical Processing)

136164

przetwarzanie analityczne on-line

OLE (Object Linking and Embedding)

136 wiązanie i zagnieżdżanie obiektów

OLE Automation 136OLE2 136OLTP (On-Line

Transaction Processing)

137164

przetwarzanie transakcji on-line

OMA (Object Management Architecture)

137 architektura zarządzania obiektami

Omega 138OMG (Object

Management Group)

138 grupa (komitet) zarządzania obiektami

OML (Object Manipulation Language)

82138


Omniscience 138OMT (Object

Modeling Technique)

138197


On Line Analytical Processing, OLAP

136164


On-Line Transaction Processing, OLTP

137164


on-the-fly 210 w locieOntos DB 138OO (Object-Oriented) 127

138obiektowo

zorientowany, obiektowy, zorientowany obiektowo

OOA (Object-Oriented Analysis)

14126138

analiza obiektowa, obiektowa analiza

OOA/OOD (Object-Oriented Analysis / Object-Oriented Design)

126138


OOAD (Object-Oriented Analysis & Design)

14123126139

analiza i projektowanie obiektowe, obiektowa analiza i projektowanie

OO-CASE (Object-Oriented CASE)

128139

obiektowy CASE

OO-Cobol (Object-Oriented Cobol)

139 obiektowy COBOL

OOD (Object-Oriented Design)

127139160

obiektowe projektowanie, projektowanie obiektowe

OODA (Object-Oriented Design with Applications)

139 obiektowe projektowanie z aplikacjami

OODB (Object-Oriented DataBase)

126139


OODBMS (Object-Oriented Data Base Management System)

129139147


OOF (Object-Oriented Fortran)

139 obiektowy Fortran

258


OOIS (Object-Oriented Information Systems)

139 obiektowe systemy informacyjne

OOP (Object-Oriented Programming)

140159


OOPL (Object-Oriented Programming Language)

128140


OOPSLA (Object-Oriented Programming Systems, Languages and Applications)

140 obiektowe systemy programowania, języki i zastosowania

OORAM 140OOSA (Object-

Oriented System Analysis)


Opal 140opaque 120 nieprzejrzystyopaque type 203 typ nieprzejrzystyOPEN 140open box 147 otwarta skrzynkaOpen Data Base

Connectivity, ODBC

132 otwarte połączenie do baz danych

Open Software Foundation, OSF

146 fundacja otwartego oprogramowania

open system 147193

otwarty system, system otwarty

open/closed principle 226 zasada otwarte/zamknięte

OpenDoc 140OpenIngres 141OpenRoad 141operation 141 operacjaoptimistic transaction

model143 optymistyczny

model transakcjioptional 140 opcyjnyoptional attribute 21 atrybut opcyjnyOQL (Object Query

Language)128143


Oracle-8 144ORB (Object Request

Broker)144156

pośrednik zleceń obiektowych

ORB core 169 rdzeń ORBORBeline 145Orbix 145

OrbixWeb 145ORBPlus 145ORDBMS (Object-

Relational Data Base Management System)

128145

obiektowo-relacyjny system zarządzania bazą danych, ORSZBD

orthogonal 146 ortogonalnyorthogonal

persistence145 ortogonalna

trwałośćorthogonality 145 ortogonalnośćOS (Object Services) 146

208usługi obiektowe

OSA (Object-oriented System Analysis)


OSF (Open Software Foundation)

146 fundacja otwartego oprogramowania

OSMOS 146OSQL (Object SQL) 146 obiektowy SQLOTM (Object

Transaction Monitor)

147 obiektowy monitor transakcji

outer join 222230

zewnętrzne złączenie, złączenie zewnętrzne

overload przeciążaćoverloading 161 przeciążanieoverride przesłaniaćoverriding 164 przesłanianieown variable zmienna własna

Ppackage 147 pakietpackage diagram 46 diagram pakietówparameter passing 162 przekazywanie

parametrówparameterised class 88 klasa

parametryzowanaparameterized type 204 typ

parametryzowany parametric

polymorphism148154

parametryczny polimorfizm, polimorfizm parametryczny

parent class 88 klasa macierzystapartition 152 podziałpassive class 88 klasa pasywna passive object 125 obiekt pasywnypath expression 220 wyrażenie ścieżkowepath index 75 indeks ścieżkowy

259


pattern 220 wzorzecpeer 178 równorzędnypeer-to-peer 178 równorzędny-do-

równorzędnegoPegasus 148performance 219 wydajnośćperformance 219 wydajność

maszynowaPerl-5 148Persistence 148persistence 201 trwałośćPersistence Service 208 usługa w zakresie

trwałościpersistence through

inheritance201 trwałość poprzez

dziedziczeniepersistence through

reachability, PTR168201

trwałość poprzez osiągalność

persistence-capable 227 zdolny do trwałościpersistent class 88 klasa trwałapersistent identifier 201 trwały identyfikatorPersistent Java 148 Java z trwałościąpersistent object 125

202obiekt trwały, trwały

obiektpersistent object store 168

183225

skład trwałych obiektów

persistent programming language

84 język programowania z trwałością

persistent root 202 trwały korzeńPersistent Storage

Manager, PSM168183225

skład trwałych obiektów, zarządca trwałymi obiektami

persistent variable 201 trwała zmienna, zmienna trwała

personification 148 personifikacjapessimistic

transaction model149 pesymistyczny

model transakcjiPhantom 149physical identifier 71 identyfikator

fizycznyphysical schema 179 schemat fizycznyPixScript 150Pjama 150Pjava 150platform 150 platformaPoet 152point odsyłać, punkt,

wskazywać

pointer 135153217

odsyłacz, pointer, wskaźnik

pointer attribute 22 atrybut referencyjny, atrybut wskaźnikowy

pointer link 157 powiązanie wskaźnikowe

pointer swizzling 162 przemiana wskaźników

polymorphism 153 polimorfizmportability 162 przenaszalnośćpostcondition 211 warunek końcowyPostgres 156post-relational 156 postrelacyjnypost-relational model 114 model postrelacyjnypower 109 mocPowerBroker 156pragma 157 pragma precompiler 158 prekompilatorprecondition 212 warunek wstępny,

wstępny warunekpredicate 158 predykat PRESTO 158primary index 74 indeks głównyprimary key 90 klucz główny, klucz

pierwotnyprimitive type 204 typ prymitywnyprivate 161 prywatnyprivate method 105 metoda prywatnaproblem domain 57 dziedzina problemuprocedural 158 proceduralnyprocedural abstraction 7 abstrakcja

proceduralnaprocedural language 83 język proceduralnyprocedure 158 proceduraprocess 158 procesprocess diagram 47 diagram procesówproductivity 219 wydajność

wytwarzaniaprogramming

paradigm147 paradygmat

programowaniaprojection 160 projekcjaProperties Service 208 usługa w zakresie

własnościproprietary 166 przypisanyprotected 33 chroniony,

zabezpieczony

260


protected class 8889

klasa chroniona, klasa zabezpieczona

protocol 160 protokółprototype 161 prototypproxy object 125 obiekt zastępczy pseudo-theoretician 166 pseudoteoretyk pseudo-theory 166 pseudoteoria pseudo-variable 168 pseudozmiennaPSM (Persistent

Storage Manager)168183225

skład trwałych obiektów, zarządca trwałymi obiektami

PTR (Persistence Through Reachability)

168201

trwałość poprzez osiągalność

public 168 publicznypublic method 105 metoda publicznaPython 168

QQA (Quality

Assurance) 168224

zapewnienie jakości

qualified association 19 asocjacja kwalifikowana

quality assurance, QA 168224

zapewnienie jakości

query 225 kwerenda, zadawać pytanie, zapytanie

query execution plan plan wykonania zapytania

query language 84 język zapytańquery modification modyfikacja zapytańquery optimization 142 optymalizacja

zapytańquery optimizer 143 optymalizator

zapytańQuery Service 208 usługa w zakresie

zapytań

RRAD (Rapid

Application Development)

169195

szybka budowa aplikacji

Raima Object Manager

169

raise exception 151185

podnieść wyjątek, spowodować wyjątek

RAP (Rapid 169 szybka budowa

Application Prototyping)

195 prototypów aplikacji

rapid application development, RAD

169195

szybka budowa aplikacji

rapid application prototyping, RAP

169195

szybka budowa prototypów aplikacji

RDBMS (Relational Data Base Management System)

169173178

relacyjny system zarządzania bazą danych, RSZBD

reactive database 12 aktywna baza danych

reactive system 193 system aktywnyread lock 223 zamek do czytania receiver 133 odbiorcarecord 171

225rekord, zapis,

zapisywaćrecord with variants 225 zapis z wariantami recovery 135 odtwarzanierecursive aggregate 10 agregat

rekurencyjnyreengineering, re-

engineering171 reinżynieria

reference 135169

odsyłacz, referencja

reference count 229 zliczanie referencjireference semantics 181 semantyka oparta na

referencjachreference type 204 typ referencyjnyreferential integrity 76 integralność

odwołań, integralność referencyjna

reflection 169 refleksjarelation 171 relacjarelational algebra 13 algebra relacyjna relational calculus 168 rachunek relacyjny relational

completeness91 kompletność

relacyjnaRelational Data Base

Management System, RDBMS

169173178


relational database 172 relacyjna baza danych

relational model 114 model relacyjnyrelational view 172 perspektywa

relacyjna, relacyjna perspektywa

relationship 231 związekRelationship Service 208 usługa w zakresie

261


związkówrelativity principle 226 zasada relatywizmu relevance 173 relewancja remote message

invocation, RMI174216

wołanie odległej metody

remote procedure call, RPC

178216

wołanie odległej procedury

repeating attribute 21 atrybut powtarzalnyreplication 173 replikacjareplication granularity ziarnistość replikacjireplicator 173 replikatorrepository 174 repozytoriumrequest 229 zlecenieRequest For

Information, RFI174 prośba o informację

Request For Proposal, RFP

174 prośba o propozycję

requirements 219 wymaganiaresponsibility 135 odpowiedzialnośćreusability 117 możliwość

ponownego użyciareuse 154 ponowne użycie,

ponownie używaćreverse engineering 78 inżynieria odwrotnarewrite przepisywaćrewriting 163 przepisywanieREXX 174RFI (Request For

Information) 174 prośba o informację

RFP (Request For Proposal)

174 prośba o propozycję

rich klient 27 bogaty klientRMI (Remote

Message Invocation)

174216


robustness 109135

moc, odporność

role 174 rolarollback, roll-back 135 odwracanieroot 95 korzeńroot object 126 obiekt-korzeńRose 176RoughWave 176row 96

214krotka, wiersz

RPC (Remote Procedure Call)

178216


RPC stub 150 pniak RPC

rubbish 28 bzdura, nonsensrule 170 regułaRumbaugh, James 178runtime, run-time 38 czas wykonaniar-value 178 r-wartość

Ssafety 25 bezpieczeństwoSather 178scalability 182 skalowalnośćscavenging 219 wymiataniescenario 179 scenariuszschema evolution 60 ewolucja schematuscope 222 zakres scope rules 171 reguły zakresuscoping 171 reguły zakresuscoping rules 171 reguły zakresuseamless 25 bezszwowyseamless integration 25 bezszwowa

integracjasearch engine 182 silnik

wyszukiwawczysecond normal form,

2NF 7

52druga postać

normalna secondary index 75 indeks pomocniczy,

indeks wtórnysecondary key 90 klucz wtórnysecond-class citizen 131 obywatel drugiej

kategoriisecurity 132 ochrona Security Service 209 usługa w zakresie

ochronyselection 180 selekcjaselector 180 selektorSelf 180self 180 samself-reference 178 samoreferencjasemantic data model 180 semantyczny model

danych semantic model 114 model semantycznysemantics 181 semantykasemilattice, semi-

lattice157 półkrata

semistructured data 38 dane półstrukturalne

semistructured, semi-structured

157 półstrukturalne

262


sending a message 220 wysłanie komunikatu

sender 119 nadawcasequence 180 sekwencjasequence diagram 49 diagram sekwencjiserializability 194 szeregowalnośćserver 181 serwer server portability przenaszalność

serweraservlet 181 serwletset 91

226kolekcja, ustawiać,

zbiórshallow comparison 156 porównanie płytkieshared 57 dzielonyshared attribute 21 atrybut dzielonyShlaer-Mellor 182side effect 58 efekt ubocznysignature 192 sygnaturasimple attribute 22 atrybut prostysimple key 90 klucz prostySimula-67 182Sina 182single dispatching 153 pojedyncza

dyspozycjasingle inheritance 57

153dziedziczenie

pojedyncze, pojedyncze dziedziczenie

Sintropy 182site lokacjaskeleton 195 szkieletslot 153 poleSmalltalk, 184smart pointer 186 sprytny wskaźniksnapshot 227 zdjęcie, zdjęcie

migawkowesoftware contract 95 kontrakt w

oprogramowaniusoftware contracting wykorzystanie

kontraktów w oprogramowaniu

software crisis 97 kryzys oprogramowania

software development 178220

rozwój oprogramowania, wytwórstwo oprogramowania

software maintenance 94 konserwacja

149209

oprogramowania, pielęgnacja oprogramowania, utrzymanie oprogramowania

software quality assurance, SQA

186 zapewnienie jakości oprogramowania

SOM (System Object Model)

184 systemowy model obiektowy

SOMA 184spaghetti 185 spaghettispaghetti-like 151 podobny do spaghettispatial data 39 dane przestrzennespecialization 185 specjalizacjaspecification 185 specyfikacjaspiral model 115 model spiralny SQA (Software

Quality Assurance) 186 zapewnienie jakości

oprogramowaniaSQL (Structured

Query Language) 186 strukturalny język

zapytańSQL3 187stability stabilnośćstable iterator 79 iterator stabilnystack-based approach 150 podejście stosoweStarburst 188state 188 stanstate chart 219 wykres stanówstate diagram 50 diagram stanówstate machine 103 maszyna stanowa,

maszyna ze stanami

state space 164 przestrzeń stanówstate transition

diagram, STD4751

189

diagram przejść pomiędzy stanami, diagram zmiany stanów

statechart 50219

diagram stanów, wykres stanów

state-machine diagram

50 diagram stanów

static attribute 22 atrybut statycznystatic binding 189

212statyczne wiązanie,

wiązanie statycznestatic checking 95 kontrola statycznastatic classification 89

189klasyfikacja

statyczna, statyczna klasyfikacja

static field 153 pole statycznestatic inheritance 57 dziedziczenie

263


statycznestatic member

function188 statyczna funkcja

członkowskastatic polymorphism 154

189polimorfizm

statyczny, statyczny polimorfizm

static scope 223 zakres statyczny static type checking 189 statyczna kontrola

typówstatic typing 189 statyczna kontrola

typówSTD (State Transition

Diagram) 4751

189

diagram przejść pomiędzy stanami

STD (State Transition Diagram)

4751

189

diagram zmiany stanów

stereotype 189 stereotypstorage domain 183 skład obiektówstorage leak 219 wyciekanie pamięcistored procedure 224 zapamiętana

procedurastrategic phase 62 faza strategicznastream strumieństrong type checking 110 mocna kontrola

typówstrong typing 110 mocna kontrola

typów, mocne typowanie

Stroustrup, Bjarne 191structural type

conformance192 strukturalna

zgodność typówstructural type

equivalence192 strukturalna

równoważność typów

structure 191 strukturaStructured Query

Language, SQL186 strukturalny język

zapytaństub 150 pniak, pieńsubclass 151 podklasasubobject 151 podobiektsubschema 151 podschematsubset 152 podzbiórsubstate 151 podstansubstitutability 224

226zamienialność,

zastępowalnośćsubstitutability

principle226 zasada zamienialności

subtype 152 podtypsuper 192 super

superclass 119192

nadklasa, superklasa

superset 119 nadzbiórsurrogate 192 surogatswizzle przemieniaćSybase Adaptive

Server 192

synchronization 193 synchronizacjasynchronous 193 synchronicznysynchronous message 94 komunikat

synchronicznysynchronous request 229 zlecenie

synchronicznesystem catalog 86 katalog systemowySystem Object Model,

SOM184 systemowy model

obiektowy

Ttable 196 tabela, tablicatagged type typ etykietowanyTAPOS (Theoretical

And Practical Aspects of Object Systems)

197 teoretyczne i praktyczne aspekty systemów obiektowych

target object 124 obiekt docelowyTechnology of

Object-Oriented Languages and Systems, TOOLS

199 technologia obiektowych języków i systemów

template 194 szablontemplate class 88 klasa szablonowatemplate type 204 typ szablonowytemporal data 39 dane temporalnetemporary 205 ulotnytemporary object 124

125obiekt chwilowy,

obiekt ulotnyterabyte 199 terabajt ternary association 20 asocjacja ternarna test suite 228 zestaw testówTheoretical And

Practical Aspects of Object Systems, TAPOS

197 teoretyczne i praktyczne aspekty systemów obiektowych

theoretical masochist 197 teoretyczny masochista

theoretical terrorist 197 teoretyczny terrorysta

theoretician 198 teoretykTheta 199

264


thin client 33 chudy klient, cienki klient, słaby klient

Third Generation Language, 3GL

784


Third Manifesto 202 trzeci manifest Third Normal Form,

3NF7

202trzecia postać

normalnaThird-Generation

Database System Manifesto

101 manifest systemów baz danych trzeciej generacji

this 199 tenThor 199thread 212 wątekthree amigos 199 trzej przyjacielethree-tier architecture 17 architektura

trzywarstwowa, architektura trzypiętrowa

three-tiered architecture

architektura trzypiętrowa

three-tiered architecture

17 architektura trzywarstwowa, architektura trzypiętrowa

TID (Tuple Identifier) 72199

identyfikator krotki

Time Services 208 usługa w zakresie czasu

time stamp 189 stempel czasowyTOOLS (Technology

of Object-Oriented Languages and Systems)

199 technologia obiektowych języków i systemów

top-down strategy 191 strategia od góry do dołu

Trader Service 209 usługa handlowatransaction 200 transakcjatransaction abort 227 zerwanie transakcjitransaction commit 156 potwierdzenie

transakcjiTransaction Service 208 usługa w zakresie

transakcjitransient 205 ulotnytransient object 125 obiekt ulotnytransition 162 przejścietransitive closure 200 tranzytywne

domknięcie transitory object 125 obiekt ulotnytransparency 164 przezroczystośćtraversal path 195 ścieżka przejścia

trigger 202220

tryger, wyzwalacz

tuple 96214

krotka, wiersz

tuple identifier, TID 72199

identyfikator krotki

tuple relational calculus

krotkowy rachunek relacyjny

Turing completeness 92 kompletność TuringaTuring power 110 moc Turingatwo-phase commit,

2PC7

53dwufazowe

potwierdzenietwo-phase locking,

2PL7

53dwufazowe

blokowanietype 202 typtype checking 95 kontrola typówtype conformance 228 zgodność typówtype constructor 94 konstruktor typówtype extent 59 ekstensja typu type hierarchy 69 hierarchia typówtype inference rule 170 reguła

wnioskowania o typie

type polymorphism 154 polimorfizm typówtype safety 25 bezpieczeństwo

typologicznetype union 207 unia typówtypecase 165 przypadek typutyping 95 kontrola typów

UUFO (Unidentified

Flying Object) 205 niezidentyfikowany

obiekt latającyUFO (United

Functions and Objects)

205 zunifikowane funkcje i obiekty

UML (Unified Modeling Language)

205231

zunifikowany język do modelowania

unary message 94 komunikat unarnyunbounded


nieograniczonyundo cofnięcie, odwrócenieUnidentified Flying

Object, UFO205 niezidentyfikowany

obiekt latającyunidirectional

association19 asocjacja

jednokierunkowa unidirectional link 157 powiązanie

jednokierunkowe unidirectional 232 związek

265


relationship jednokierunkowy Unified Modeling

Language, UML205231

zunifikowany język do modelowania

union 206 unia, suma zbiorówUniSQL 207United Functions and

Objects, UFO205 zunifikowane funkcje

i obiektyuniversal server 207 uniwersalny serweruniverse of discourse,

UoD161207

przedmiot rozważań

unmarshalling 177 rozszeregowanieunnest rozgnieżdżaćunnesting rozgnieżdżanie unstructured data 38 dane niestrukturalneUoD (Universe of

Discourse)161207

przedmiot rozważań

upcast 86 kast w górę update 11 aktualizuj,

aktualizowaćupdating 11 aktualizacjause case 165 przypadek użyciause case diagram 48 diagram

przypadków użyciause case instance 220 wystąpienie

przypadku użyciause case model 114 model przypadków

użyciauser 209 użytkownikuser friendliness 165 przyjaznośćuser friendly przyjaznyuses używa

Vvalue-based 24 bazujący na

wartościach, oparty na wartościach

value-oriented 231 zorientowany na wartości

variable format 62 format zmiennyvariant 210 wariantVbase 209VC++ (Visual C++) 209

210wizyjny C++

VDM++ (Vienna Development Method++)

209 wiedeńska metoda rozwoju++

VDM-SL (Vienna Development Method -

wiedeńska metoda rozwoju - język specyfikacji

Specification Language)

Versant 209version 212 wersjaversion control 190 sterowanie

wersjami, kontrola wersji

version management 225 zarządzanie wersjamivertical common

facilities218 wspólne

udogodnienia pionowe

Vienna Development Method Specification Language, VDM-SL

wiedeńska metoda rozwoju - język specyfikacji

Vienna Development Method++, VDM++

209 wiedeńska metoda rozwoju++

view 148214

perspektywa, wizja

view updating 11 aktualizacja perspektyw

virtual 214 wirtualnyvirtual attribute 22

214atrybut wirtualny,

wirtualny atrybutvirtual data 39 dane wirtualnevirtual function 63 funkcja wirtualnavirtual machine 103 maszyna wirtualnavirtual object 125 obiekt wirtualnyvisibility 212 widocznośćVisiBroker 209visual wizyjnyVisual Age 210Visual Basic 210Visual C++ 210Visual C++, VC++ 209

210wizyjny C++

visual programming 159 programowanie wizyjne

volatile 205 ulotnyvolatile object 125 obiekt ulotny

Wwait-die czekasz-giń waterfall model 112

116model kaskadowy,

model wodospadowy

weak type checking 183 słaba kontrola typówweak typing 183 słaba kontrola typów weakly typed 183 słabo typowany

266


white box 25 biała skrzynkawidget 213 widżet Wirfs-Brock 214Wirfs-Brock,

Rebecca214

workflow 163 przepływ pracywrap osłaniaćwrapper 146 osłonawrapping 146 osłonowaniewrite lock 224 zamek do pisania

X Y ZYourdon, Ed 221Z++ 221

267

4.Słownik -skorowidz polsko-angielski

5. Słownik-skorowidz polsko-angielski

0-9

1NF 7149

1NF (First Normal Form)

2NF 752

2NF (Second Normal Form)

2PC 753

2PC (Two-Phase Commit)

2PL 753

2PL (Two-Phase Locking)

3GL 784

3GL (Third Generation Language)

3NF 7202

3NF (Third Normal Form)

4GL 781

4GL (Fourth Generation Language)

Aabstrakcja 7 abstractionabstrakcja

proceduralna7 procedural abstraction

abstrakcje danych 8 data abstractionsabstrakcyjny typ

danych89

abstract data type, ADT

ACID 820

ACID (Atomicity, Consistency, Isolation, Durability)

ActiveX 8Ada95 9adapter obiektów 9 object adapter

administrator bazy danych

939

data base administrator, DBA

ADT 89

ADT (Abstract Data Type)

agent 9 agentaglet 9 aglet Agora 9agregacja 9 aggregationagregat 10 aggregateagregat

rekurencyjny10 recursive aggregate

akcesor 10 accessorakcja 10 actionaktor 10 actoraktualizacja 11 updatingaktualizacja

perspektyw11 view updating

aktualizować updateaktualizuj 11 updateaktyw 11 assetaktywa 11 assetsaktywacja 11 activationaktywna baza

danych12 active database,

reactive databaseaktywne reguły 12 active rulesaktywność 12 activityaktywny agent 12 active agentaktywny obiekt 12 active objectaktywny SZBD 12 active DBMSalfa 12 alphaalgebra obiektowa 12

126object algebra

algebra relacyjna 13 relational algebra

269


alias 14 aliasaliasowanie 14 aliasingAmerykański

Narodowy Instytut Standardyzacji

15 American National Standard Institute, ANSI

analiza 14 analysisanaliza i

projektowanie obiektowe

14123126139

object analysis and design, object-oriented analysis & design, OOAD, OA&D

analiza obiektowa 14138



1462

Function Point Analysis, FPA

ANSI 15 ANSI (American National Standard Institute)

ANSI X3H2 15antropomorfizm 15 antropomorphismantywzorzec 15 anti-patternaplet 15 appletaplikacja 15 applicationaplikacja spadkowa 15 legacy applicationAppleScript 15architektura 15 architecturearchitektura

ANSI/SPARC16 ANSI/SPARC

architecture architektura klient-

serwer17 client-server

architecturearchitektura

komponentowa 17 component

architecturearchitektura

powszechnego pośrednika obiektowych zleceń

35 Common Object Request Broker Architecture, CORBA

architektura trzypiętrowa

three-tier architecture, three-tiered architecture

architektura trzywarstwowa

17 three-tier architecture, three-tiered architecture

architektura wielowarstwowa

17 multi-tiered architecture

architektura zarządzania obiektami

137 Object Management Architecture, OMA

argument 17 argumentargument aktualny 17 actual argumentargument formalny 17 formal argument

Ariane 5 17artefakt artifactasercja 18 assertionasocjacja 18 associationasocjacja binarna 19 binary associationasocjacja

dwukierunkowa 19 bidirectional

associationasocjacja

jednokierunkowa 19 unidirectional

associationasocjacja

kwalifikowana19 qualified association

asocjacja n-arna 19 n-ary associationasocjacja pochodna 19 derived associationasocjacja ternarna 20 ternary associationasocjacyjna tablica 196 associative tableasocjacyjny dostęp 52 associative accessasynchroniczne

zlecenie229 asynchronous request

asynchroniczność 20 asynchronicityasynchroniczny 20 asynchronousasynchroniczny

komunikat93 asynchronous

messageatomowość 20 atomicityatomowość,

spójność, izolacja, trwałość

820

Atomicity, Consistency, Isolation, Durability, ACID

atomowy 20 atomicatrybut 20 attributeatrybut asocjacji 21 association attrributeatrybut atomowy 21 atomic attributeatrybut domyślny 21 default attributeatrybut dzielony 21 shared attributeatrybut klasy 21 class attributeatrybut

kompozytowy21 composite attribute

atrybut masowy 21 bulk attributeatrybut

multimedialny21 multimedia attribute

atrybut opcyjny 21 optional attributeatrybut pochodny 21 derived attributeatrybut powiązania 21 link attributeatrybut powtarzalny 21 repeating attributeatrybut prosty 22 simple attribute atrybut referencyjny 22 pointer attributeatrybut statyczny 22 static attributeatrybut wewnętrzny 22 internal attribute

270


atrybut wielowartościowy

22 multi-valued attribute

atrybut wirtualny 22 virtual attributeatrybut

wskaźnikowy22 pointer attribute

atrybut wyjątku 22 exception attributeatrybut wyliczalny 22 derived attributeatrybut wystąpienia 22 instance attributeatrybut zdarzenia 22 event attributeatrybut zewnętrzny 22 external attributeatrybut złożony 23 complex attribute,

composite attributeaudyt 23 auditautomatyczna

trwałośćautomatic persistence

autonomia autonomyautoryzacja 23 authorization

BBancilhon, Francois 23banda czworga 23

66gang of four, GOF

Barry, Douglas K. 23baza danych 23

39data base, DB

baza obiektów 23 object basebaza wiedzy 23 knowledge basebazujący na

obiektach24 object-based

bazujący na wartościach

24 value-based

BCNF 24156

BCNF (Boyce-Codd Normal Form)

B-drzewo 24 balanced tree, B-treebehawior 24 behaviour, behaviorbenczmark 24 benchmarkBETA 24beta 25 beta bezpieczeństwo 25 safetybezpieczeństwo

typologiczne25 type safety

bezpośredni przodek 25 direct ancestorbezszwowa

integracja25 seamless integration

bezszwowy 25 seamlessbiała skrzynka 25 white boxbiblioteka

hierarchiczna69 hierarchical library

biblioteka klas 26 class librarybigot 26 bigotbizantyjski 26 byzantineBlack Widow 26BLOB 26

53BLOB (Binary Large

Object)blokada 26 deadlockblokada 26 lockBlue 26BOA 26

152BOA (Basic Object

Adapter)BOF 26 BOF (Business

Object Framework) bogaty klient 27 rich klientBOM 27 BOM (Bill-Of-

Material) BON 27

126BON (Business

Object Notation) Booch 27Booch, Grady 27BPM 27

116BPM (Business

Process Modeling)BPR 27

171BPR (Business

Process Reengineering)

brudna strona 27 dirty pagebrudne

programowanie 27 dirty programming

brudny obiekt 28 dirty object brudny odczyt 28 dirty readbrzęczydło 28 buzzwordbrzytwa Occama 28 Occam’s razorbufor 28 buffer, cachebzdura 28 nonsense, rubbish

CC/S 30

89C/S (Client/Server)

C++ 30CAD 31

42160

CAD (Class Association Diagram, Computer Aided Design)

CAM 31220

CAM (Computer Aided Manufacturing)

Cardelli, Luka 31Cartridges 31

271


CASE 3178

CASE (Computer Aided Software Engineering, Computer Aided System Engineering)

Catalysis 32Cattel, Rick 32cecha eksportowana 32 exported featureCecil 33CF 33

217CF (Common

Facilities) CFOM 33 CFOM (Composition

Filters Object Model)

Chen, Peter 33chroniony 33 protectedchudy klient 33 thin clientciało metody 33 method bodycienki klient 33 thin clientCIO 33 CIO (Chief

Information Officer) CLI 33

76CLI (Call-Level

Interface) CLIPS 33 CLIPS (C Language

Integrated Production System)

CLOB 3453

CLOB (Character Large Object)

CLOS 34 CLOS (Common LISP Object System)

CLU 34CO2 34Coad, Peter 34Coad/Yourdon 34COBRA 34cofnięcie undoCOM 34

157113

COM (Common Object Model)

COM+ 35Component Broker 35COOL 35 COOL (Chorus

Object-Oriented Layer)

CORBA 35 CORBA (Common Object Request Broker Architecture)

CORBA 1.1 37CORBA 2.0 37CORBA 3.0 37CRC 37 CRC (Class-

Responsibility-Collaborator)

CRUD 37 CRUD (Create, Retrieve, Update, Delete)

CSCW 37 CSCW (Computer Supported Cooperative Work)

cykl życia obiektu 37 object life cycleczarna skrzynka 37 black boxczas kompilacji 38 compile-timeczas wykonania 38 runtime, run-timeczas życia obiektu 38 object lifetimeczasopismo z zakresu

programowania obiektowego

85 Journal of Object-Oriented Programming, JOOP

czekasz-giń wait-dieczęsto zadawane

pytania61 Frequently Asked

Questions, FAQczłonek 38 member

DDAIS 38dane biznesowe 38 business datadane biznesu 38 business datadane masowe 38 bulk datadane niestrukturalne 38 unstructured datadane

półstrukturalne 38 semistructured data

dane przestrzenne 39 spatial datadane temporalne 39 temporal datadane wirtualne 39 virtual dataDataBlades 39DataExtenders 39DB 23

39DB (Data Base)

DB2 Universal Database

39

DBA 939

DBA (data base administrator)

DBMS 39193194


DBPL 39 DBPL (Data Base

272


83 Programming Language)

DCE 39 DCE (Distributed Computing Environment)

DCOM 39176

DCOM (Distributed Common Object Model)

DDD 4086

DDD (Data Dictionary-Directory)

DDL 408283

DDL (Data Definition Language)

deaktywacja 40 deactivationdedukcyjne i

obiektowe bazy danych

52 Deductive and Object-Oriented Databases, DOOD

dedukcyjno-obiektowe

40 deductive object-oriented

deklaracja 40 declarationdeklaracyjny 40 declarativedekompozycja 40 decompositiondelegacja 40 delegationdelegowanie 41 delegationDelphi 41denormalizacja 41 denormalizationdereferencja 41 dereferencingderywacja 42 derivationdestruktor 42 destructorDFD 42

4752

DFD (Data Flow Diagram)

diagram 42 diagramdiagram aktywności 42 activity diagram diagram asocjacji klas 31

42class association

diagram, CADdiagram blokowy 48 flowchartdiagram encja-

związek42 Entity-Relationship

Diagram, ERDdiagram Harela 43 Harel diagramdiagram interakcji 43 interaction diagramdiagram interakcji

obiektów43 object interaction

diagramdiagram klas 43 class diagramdiagram kolaboracji 44 collaboration diagramdiagram

komponentów45 component diagram

diagram modułów 46 module diagram

diagram obiektów 46 object diagramdiagram pakietów 46 package diagramdiagram procesów 47 process diagramdiagram przejść

pomiędzy stanami4751

189

state transition diagram, STD

diagram przepływu danych, DPD

424752

data flow diagram, DFD

diagram przepływu sterowania

48 control flow diagram, flowchart

diagram przypadków użycia

48 use case diagram

diagram rozprzestrzeniania

49 deployment diagram

diagram sekwencji 49 sequence diagramdiagram stanów 50 state diagram,

statechart, state-machine diagram

diagram struktury obiektów

50 object structure diagram

diagram tropów zdarzeń

50 event-trace diagram

diagram wdrożenia 49 deployment diagramdiagram wdrożeniowy 49 deployment diagramdiagram współpracy 44 collaboration diagramdiagram zmiany

stanów4751

189

state transition diagram, STD

DII 51 DII (Dynamic Invocation Interface)

dinozaur 51 dinosaurDistributed

Smalltalk 51

długa transakcja 51 long transactionDML 51

82DML (Data

Manipulation Language)

DOE 51 DOE (Distributed Object Environment)

DOME 51 DOME (Distributed Object Management Environment)

DOMF 51 DOMF (Distributed Object Management Facility)

Domino 5.0 51domyślny 51 defaultDOOD 52 DOOD (Deductive

273


and Object-Oriented Databases)

DOOS 52 DOOS (Designing Object-Oriented Software)

dostęp asocjacyjny 52 associative accessdostęp nawigacyjny 52 navigational accessdowolny 15 any DPD (Diagram

Przepływu Danych)

424752

DFD (Data Flow Diagram)

druga postać normalna

752

second normal form, 2NF

drzewo zbalansowane, B-drzewo

24 balanced tree, B-tree

DSI 52 DSI (Dynamic Skeleton Interface)

DSOM 53 DSOM (Distributed Standard Object Model)

DSS 53 DSS (Decision Support System)

duży obiekt binarny 2653

binary large object, BLOB

duży obiekt znakowy 3453

character large object, CLOB

dwufazowe blokowanie

753

two-phase locking, 2PL

dwufazowe potwierdzenie

753

two-phase commit, 2PC

dwukierunkowa asocjacja

19 bidirectional association

dwukierunkowe powiązanie

157 bidirectional link

dwukierunkowy związek

232 bidirectional relationship

Dylan 54dylemat elipsy i koła 54 elipse/circle dilemmadynamiczna

dyspozycja54 dynamic dispatching

dynamiczna klasyfikacja

55 dynamic classification

dynamiczna kontrola dynamic checkingdynamiczna

kontrola typów55 dynamic type

checking, dynamic typing

dynamiczne dziedziczenie

56 dynamic inheritance

dynamiczne wiązanie 212 dynamic binding

dynamiczny SQL 55 dynamic SQLdyskryminator 55 discriminatordysponować dispatchdyspozycja 56 dispatchingdziałanie 56 activitydziedziczenie 56 inheritancedziedziczenie

dynamiczne56 dynamic inheritance

dziedziczenie implementacji

56 implementation inheritance

dziedziczenie interfejsu

57 interface inheritance

dziedziczenie oparte na klasach

57 class-based inheritance

dziedziczenie pojedyncze

57 single inheritance

dziedziczenie statyczne

57 static inheritance

dziedzina 57 domaindziedzina

aplikacyjna57 application domain

dziedzina biznesu 57 business domaindziedzina problemu 57 problem domaindziedzinowy

rachunek relacyjnydomain relational

calculusdzielony 57 shareddzieło artifactdziennik 57 log

EE 57ECA 58

227ECA (Event-

Condition-Action)ECOOP 58 ECOOP (European

Conference on Object-Oriented Programming)

EER 58 EER (Extended Entity-Relationship)

efekt uboczny 58 side effectEiffel 58EIS 58 EIS (Executive

Information Systems)

eklektyczny 58 eclecticeksploracja danych 58 data miningeksport 59 exportekstensja 59 extent, extension

274


ekstensja klasy 59 class extentekstensja typu 59 type extentelastyczność 59 flexibilityelement pochodny 59 derived elementEmerald 59encja 59 entityencja-związek 60 entity-relationship,

EREncore 60enkapsulacja 60 encapsulationER 60 ER (Entity-

Relationship)ERD 60 ERD (Entity-

Relationship Diagram)

ERM 60111

ERM (Entity-Relationship Model)

EROOS 60 EROOS (Entity-Relationship Object-Oriented Specification)

ESIOP 60 ESIOP (Environment-Specific Inter-ORB Protocols)

europejska konferencja programowania obiektowego

58 European Conference on Object-Oriented Programming, ECOOP

ewolucja schematu 60 schema evolutionExodus 60Expertsoft 60Express 60

Ffabryka 61 factoryfaktyczny standard 188 defacto standardFAQ 61 FAQ (Frequently

Asked Questions) fasolka 61 beanfaza strategiczna 62 strategic phasefederacyjna baza

danych62 federated database

Fibonacci 62F-logic 62format stały 62 fixed formatformat wymiany 62 exchange formatformat zmienny 62 variable format

formularz 62 formFP 62

168FP (Function Point)

FPA 1462

FPA (Function Point Analysis)

Fresco 62fundacja otwartego

oprogramowania146 Open Software

Foundation, OSFfunkcja 63 functionfunkcja członkowska 63 member functionfunkcja generyczna 63 generic functionfunkcja mieszająca 63 hash functionfunkcja wirtualna 63 virtual functionfunkcja wyższego

rzędu63 higher-order function

funkcja zagregowana

64 aggregate function

funkcja zaprzyjaźniona

64 friend function

funkcjonalny functionalfunkcyjny functionalFusion 64

GGC 64

103135

GC (Garbage Collector)

GCC 64GemORB 64Gemstone 64generalia 64 genericsgeneralium 64 genericsgeneralizacja 65 generalizationgenerator aplikacji 65 application generatorgeneryczna funkcja 65 generic functiongeneryczne

programowanie65

159generic programming

generyczny 65 genericgigabajt 65 gigabyte GIGO 65 GIGO (Garbage In -

Garbage Out) GIOP 65 GIOP (General Inter-

ORB Protocol)GIS 65

193GIS (Geographic

Information System)

globalna zmienna 65 global variabległówne obiektowe 117 Major Object-

275


rozszerzenia SQL Oriented SQL Extensions, MOOSE

główny specjalista d/s informacji

33 Chief Information Officer, CIO

GNU E 66GOF 23

66GOF (Gang Of Four)

Goldberg, Adele 66graf dziedziczenia 66 inheritance graphgraficzny interfejs

użytkownika6676

graphical user interface, GUI

grono 66 clustergrupa (komitet)

zarządzania obiektami

138 Object Management Group, OMG

grupa (komitet) zarządzania obiektową bazą danych

133 Object Database Management Group, ODMG

grupa (komitet) zarządzania obiektowymi danymi

133 Object Data Management Group, ODMG

GUI 6676

GUI (Graphical User Interface)

HHAD 66

68HAD

(Heterogeneous, Autonomous, Distributed)

Henderson-Sellers, Brian

66

hermetyzacja 66 encapsulationheterogeniczna baza

dana68 heterogeneous

databaseheterogeniczny 68 heterogeneousheterogeniczny,

autonomiczny, rozproszony

6668

heterogeneous, autonomous, distributed, HAD

hierarchia agregacji 68 aggregation hierarchyhierarchia

dziedziczenia68 inheritance hierarchy

hierarchia klas 68 class hierarchyhierarchia obiektu 69 object hierarchyhierarchia typów 69 type hierarchyhierarchiczna

biblioteka69 hierarchical library

hierarchiczny język do specyfikacji

69 Hierarchical Music Specification

muzyki Language, HMSLHMSL 69 HMSL (Hierarchical

Music Specification Language)

homomorfizm 69 homomorphismhomonimiczny 69 homonimichumor obiektowy 69 object-oriented

humourhurtownia danych 71 data warehouse, data

marthybrydowy 71 hybrid

IIceberg 71IDB Object

Database 71

identyfikator 71 identifieridentyfikator

fizyczny71 physical identifier

identyfikator krotki 72199

tuple identifier, TID

identyfikator logiczny

72 logical identifier

identyfikator obiektu

72136

object identifier, OID

idiom 72 idiomidiota 72 idiotIDL 72

82IDL (Interface


IDP 7379

IDP (Iterative Development Process)

IIOP 73 IIOP (Internet Inter-ORB Protocol)

Illustra 74ILU 74 ILU (Inter-Language

Unification) imperatywny 74 imperativeimplementacja 74 implementationimport 74 import indeks 74 indexindeks główny 74 primary indexindeks pomocniczy 75 secondary indexindeks ścieżkowy 75 path indexindeks wtórny 75 secondary indexindeksy 74 indices

276


Informix Dynamic Server

75

Informix Universal Server

75

Ingres 75Ingres II 75instancja 75 instanceintegralność 75 integrityintegralność

odwołań76 referential integrity

integralność referencyjna

76 referential integrity

integralność wskaźników

76 referential integrity

inteligentny 76 intelligentinterakcyjne

zapytanie76 interactive query

interfejs 76 interfaceinterfejs do

programowania aplikacji

76 API (Application Programming Interface)

interfejs do programowania aplikacji

76 Application Programming Interface, API

interfejs dynamicznego szkieletu

52 Dynamic Skeleton Interface, DSI

interfejs dynamicznych wołań

51 Dynamic Invocation Interface, DII

interfejs graficzny użytkownika

6676

graphical user interface, GUI


3376

Call-Level Interface, CLI

intergalaktyczny język danych

76 intergalactic dataspeak

internetowy protokół między pakietami ORB

73 Internet Inter-ORB Protocol, IIOP

interoperacyjność 76 interoperabilityinwariancja 77 invariancyinwariant 77 invariantinżynieria odwrotna 78 reverse engineeringinżynieria

oprogramowania wspomagana komputerem

3178

Computer Aided Software Engineering, CASE

inżynieria prosta 78 forward engineeringinżynieria systemów

wspomagana 3178

Computer Aided System

komputerem Engineering, CASEIR 78

174IR (Interface

Repository) Iris 78IS 78

182IS (Information

System)is-a 78ISO 78 ISO (International

Standard Organization)

ISO 9001 78ISO 9003 78Itasca 78iteracja 78 iteration iteracyjny proces 79 iterative processiteracyjny proces

rozwoju7379

iterative development process, IDP

iterator 79 iteratoriterator niestabilny 79 non-stable iteratoriterator stabilny 79 stable iteratorizolacja 79 isolation

JJacobson, Ivar 79Jade 79Jasmine 79Java 80Java IDL 80Java Virtual Machine 80Java z trwałością 148 Persistent Java JavaBeans 80Javascript 81JavaSoft 81JDBC 81 JDBC (Java Data

Base Connectivity) JDK 81 JDK (Java Developer

Kit) język czwartej

generacji7

81Fourth Generation

Language, 4GLjęzyk definicji danych 40

8283

Data Definition Language, DDL


7282

Interface Definition Language, IDL


82133

Object Definition Language, ODL

język deklaracyjny 82 declarative languagejęzyk imperatywny 82 imperative language

277



5182

Data Manipulation Language, DML


82138

Object Manipulation Language, OML

język nieproceduralny

82 non-procedural language

język obiektowy 83 object-oriented language

język opisu danych 408283

Data Description Language, DDL

język proceduralny 83 procedural languagejęzyk

programowania baz danych

3983

Data Base Programming Language, DBPL

język programowania z trwałością

84 persistent programming language


784

Third Generation Language, 3GL

język zapytań 84 query languagejęzyk-gospodarz host languageJOE 85 JOE (Java Object

Environment) JOOP 85 JOOP (Journal of

Object-Oriented Programming)

JVM 85103

JVM (Java Virtual Machine)

Kkapsułkowanie 85 encapsulationkarta CRC 85 CRC cardkast 86 castkast w dół 86 downcastkast w górę 86 upcastkatalog danych 40

86data dictionary, data

dictionary-directory, DDD

katalog systemowy 86 system catalogKay, Alan 86KBMS 86

194KBMS (Knowledge

Base Management System)

Kim, Won 86klasa 87 classklasa abstrakcyjna 87 abstract classklasa aktywna 87 active class

klasa asocjacji 87 association classklasa bazowa 88 base classklasa biznesowa 88 business classklasa chroniona 88 protected classklasa generyczna 88 generic classklasa konkretna 88 concrete classklasa kontenerowa 88 container classklasa macierzysta 88 parent classklasa mieszana 88 mixin classklasa opóźniona 88 deferred classklasa

parametryzowana88 parameterised class

klasa pasywna 88 passive classklasa pochodna 88 derived classklasa potomna 88 child classklasa szablonowa 88 template classklasa trwała 88 persistent classklasa wbudowana 89 build-in classklasa zabezpieczona 89 protected classklasa

zaprzyjaźniona89 friend class

klasa-odpowiedzialność-współpraca (kolaboracja)

89 class-responsibility-collaborator, CRC

klaster 89 clusterklasyfikacja 89 classificationklasyfikacja

dynamiczna89 dynamic classification

klasyfikacja statyczna 89 static classificationklient 89 clientklient-serwer 30

89client/server, client-

server, C/Sklon cloneklonować cloneklonowanie 89 cloningklub fanów

zapytania 2+289 2+2 query fan club

klucz 90 keyklucz główny 90 primary keyklucz kandydujący 90 candidate keyklucz obcy 90 foreign keyklucz pierwotny 90 primary keyklucz prosty 90 simple keyklucz wtórny 90 secondary keyklucz złożony 90 aggregate key,

278


composite key, compound key

kod bajtowy 90 bytecodekod do konsolidacji object codekod obiektowy object codekodowanie

mieszającehash coding, hashing

koercja 90 coercionkohezja 91 cohesionkojarzyć couplekolaboracja 91 collaborationkolekcja 91 collection, setkompletność

obliczeniowa91 computational

completenesskompletność

relacyjna91 relational

completenesskompletność Turinga 92 Turing completenesskompletny podział 152 complete partitionkomponent 92 componentkompozycja 92 compositionkompozycyjność 93 compositionalitykomputerowe

wspomaganie pracy grupowej

37 Computer Supported Cooperative Work, CSCW

komunikat 93 messagekomunikat

asynchroniczny93 asynchronous

messagekomunikat binarny 94 binary messagekomunikat

kaskadowy 94 cascaded message

komunikat synchroniczny

94 synchronous message

komunikat unarny 94 unary messagekonceptualny 94 conceptualkonflikt nazw 94 name clash, name

conflictkonserwacja 94 maintenancekonserwacja

oprogramowania94 software maintenance

konsolidacja 94 linkingkonstruktor 94 constructorkonstruktor typów 94 type constructorkontekst kolaboracji 94 collaboration contextkontekst współpracy 94 collaboration contextkontener 94 containerkontrakt 94 contractkontrakt w 95 software contract

oprogramowaniukontrawariancja 95 contravariancykontrola dostępu 95 access controlkontrola

dynamiczna95 dynamic checking

kontrola statyczna 95 static checkingkontrola typów 95 type checking, typingkontrola wersji version controlkopia mirrorkorzeń 95 rootkostka danych 95 data cubekot 95 catkowariancja 95 covariancykraniec frontowy 96 front end kraniec tylny 96 back end krata 96 latticekrotka 96 tuple, rowkrotkowy rachunek

relacyjnytuple relational

calculuskrotność 96 cardinality,

multiplicitykrytyka 96 critique, flamekryzys

oprogramowania97 software crisis

kursor 97 cursorkwerenda query

Lleniwa ewaluacja 97 lazy evaluationleniwa inicjalizacja 98 lazy initializationLiana 98liczba kardynalna 98 cardinalityliczność 98 cardinality,

multiplicitylinia życia obiektu 98 object lifelinelista eksportowa 98 export listlista importowa 99 import listliteral 99 literalliterał 99 literallogika biznesu 99 business logicLoglan 99lokacja siteLoqis 99LotusNotes 99LSP 99 LSP (Liskov

Substitution

279


Principle) luźne powiązanie 100 loose couplingl-wartość 100 l-value

Mmagazyn danych 100 data warehouse, data

martMainstreamObjects 100manifest 100 manifestomanifest

obiektowych systemów baz danych

101 Object-Oriented Database System Manifesto

manifest systemów baz danych trzeciej generacji

101 Third-Generation Database System Manifesto

mapa bitowa 102 bitmapMartin, James 102Martin/Odell 102masowy 102 bulkmaszyna

abstrakcyjna102 abstract machine

maszyna stanowa 103 state machinemaszyna wirtualna 103 virtual machinemaszyna wirtualna

języka Java85

103Java Virtual Machine,

JVMmaszyna ze stanami 103 state machineMatisse 103mechanizm obsługi

wyjątków103 exception handler

mechanizm zbierania nieużytków

64103135

garbage collector, GC

mediator 103 mediatorMelton, Jim 104metadane 104 metadatametafora 104 metaphormetaklasa 104 metaclassmetamodel 104 metamodelmetoda 104 methodmetoda

abstrakcyjna105 abstract method

metoda fabrykująca 105 factory methodmetoda klasowa 105 class methodmetoda prywatna 105 private methodmetoda publiczna 105 public methodmetoda wystąpienia 105 instance method

metoda zwrotna 105 callback methodmetodologia 105 methodologymetodyka 105 methodologymetodyka dla

obiektowej inżynierii oprogramowania systemów

117 Methodology for Object-oriented Software Engineering of Systems, MOSES

metodyka obiektowa 106 object-oriented methodology

metryka 107 metricmetryka obiektowa 108 object-oriented metricMeyer, Bertrand 109miara 109 metricmiara obiektowa 109 object-oriented

measurementsmieszać hashmieszanie 109 hashMiędzynarodowa

Organizacja Standardyzacji

78 International Standard Organization, ISO

migracja obiektów 109 object migrationMIS 109 MIS (Management

Information System)

mobilne programowanie

109 mobile programming

mobilny agent 109 mobile agentmobilny kod 109 mobile codemobilny przepływ

prac mobile workflow

moc 109 power, robustnessmoc Turinga 110 Turing powermocna kontrola

typów110 strong type checking,

strong typingmocne typowanie strong typingmocny klient 110 fat clientmodel modelmodel CRC 110 CRC modelmodel cyklu

życiowego110 life-cycle model

model danych 110 data modelmodel dynamiczny 111 dynamic modelmodel encja-związek 60

111entity-relationship

model, ERMmodel funkcjonalny 111 functional modelmodel funkcyjny 112 functional modelmodel hierarchiczny 112 hierarchical model

280


model kaskadowy 112 waterfall modelmodel mentalny 113 mental modelmodel obiektowy 113 object model, object-

oriented modelmodel obiektowy dla

komponentów34

157113

Component Object Model, COM

model obiektowy ODMG

113 ODMG object model

model obiektów 113 object model model piłki

baseballowej113 baseball model

model pojęciowy 113 conceptual modelmodel postrelacyjny 114 post-relational modelmodel przepływu

danych114 data flow model

model przypadków użycia

114 use case model

model relacyjny 114 relational modelmodel semantyczny 114 semantic modelmodel sieciowy 115 network modelmodel spiralny 115 spiral modelmodel wodospadowy 116 waterfall modelmodelować modelmodelowanie CRC 116 CRC modelingmodelowanie

obiektowe116 object-oriented

modelingmodelowanie

pojęciowe116 conceptual modeling

modelowanie procesów biznesowych

27116

Business Process Modeling, BPM

model-perspektywa-sterownik

116118

Model-View-Controller, MVC

Modula-3 116modularność 116 modularitymodularyzacja 116 modularizationmoduł 116 modulemodyfikacja zapytań query modificationmodyfikator 117 modifiermonomorfizm 117 monomorphismMontage 117MOOSE 117 MOOSE (Major

Object-Oriented SQL Extensions)

MOSES 117 MOSES (Methodology for Object-oriented Software

Engineering of Systems)

możliwość ponownego użycia

117 reusability

mrówka 117 antMS Repository 117 MS RepositoryMTS 118 MTS (Microsoft

Transaction Server)multimedia 118 multimedia, multi-

mediamultimedialny 118 multimedia, multi-

mediaMVC 116

118MVC (Model-View-

Controller)

Nnadawca 119 sendernadklasa 119 superclassnadzbiór 119 supersetnarzędzia do pracy

grupowej119 groupware

naturalne złączenie 119 natural joinnawigacja 119 navigationnawigacyjne

złączenie119 navigational join

nazwa 119 namenazwa obiektu 120 object namenazwowa


120 name type equivalence

nazwowa zgodność typów

120 name type conformance

NEOnet 120NF2 120

122NF2, NF2 (Non-First-

Normal-Form) nie wynalezione tutaj 122 Not-Invented-Here,

NIHnieobiekt 120 non-objectnieproceduralny 120 non-proceduralnieprzejrzysty 120 opaquenieuprzejmość 96 flameniezależność danych 120 data independenceniezgodność

impedancji120 impedance mismatch

niezidentyfikowany obiekt latający

205 Unidentified Flying Object, UFO

niezmienialny 122 immutableniezmienny 122 invariant

281



120122

Non-First-Normal-Form, NF2, NF2, non-normalized relations

NIH 122 NIH (Not-Invented-Here)

NIL (wartość zerowa) 122210

NIL (null value)

nonsens nonsense, rubbishnormalizacja 122 normalizationnormalizacja danych 123 data normalizationnormalizacja klas 123 class normalizationnotacja 123 notationnowy 123 newNULL (wartość

zerowa)123210

NULL (null value)

OO2, O2 123OA&D 14

123OA&D (Object

Analysis and Design)

obcy klucz 123 foreign keyOBD 123 ODBOberon-2 123obiekt 123 objectobiekt aktywny 124 active objectobiekt biznesowy 124 business objectobiekt chwilowy 124 temporary objectobiekt docelowy 124 target objectobiekt globalny 124 global objectobiekt interfejsu 124 interface objectobiekt kompozytowy 125 composed object,

composite objectobiekt kontenerowy 125 container objectobiekt lokalny 125 local objectobiekt niezmienialny 125 immutable objectobiekt pasywny 125 passive objectobiekt rzeczywisty 125 entity objectobiekt sterujący 125 control objectobiekt trwały 125

202persistent object

obiekt ulotny 125 temporary object, transient object, transitory object, volatile object

obiekt wirtualny 125 virtual objectobiekt współbieżny 125 concurrent object

obiekt zagregowany 125 aggregate objectobiekt zastępczy 125 deputy object, proxy

objectobiekt złożony 126 complex object,

composite objectobiekt-korzeń 126 root objectobiektowa algebra 12

126object algebra

obiektowa analiza 14126138



126138

Object-Oriented Analysis / Object-Oriented Design, OOA/OOD

obiektowa analiza i projektowanie

14126139

Object-Oriented Analysis & Design, OOAD

obiektowa analiza systemów

140146

Object-Oriented System Analysis, OOSA, Object-oriented System Analysis, OSA


126132139

object database, ODB, object-oriented database, OODB

obiektowa notacja dla biznesu

27126

Business Object Notation, BON

obiektowa perspektywa

126149

object view

obiektowa specyfikacja encji-związków

60 Entity-Relationship Object-Oriented Specification, EROOS

obiektowe programowanie wizyjne

126 object-oriented visual programming

obiektowe projektowanie

127139160


obiektowe projektowanie z aplikacjami

139 Object-Oriented Design with Applications, OODA

obiektowe systemy informacyjne

139 Object-Oriented Information Systems, OOIS

obiektowe systemy programowania, języki i zastosowania

140 Object-Oriented Programming Systems, Languages and Applications, OOPSLA

obiektowo zorientowany

127138

object-oriented, OO

282


obiektowo-relacyjny 127 object-relationalobiektowo-relacyjny

system zarządzania bazą danych, ORSZBD

128145

Object-Relational Database Management System, ORDBMS

obiektowo-relacyjny SZBD

128145

object-relational DBMS

obiektowość 128 object-orientation, object-orientedness

obiektowość behawioralna

128 behavioral object-orientation

obiektowy 127138

object-oriented, OO

obiektowy CASE 128139

object-oriented CASE, OO-CASE

obiektowy COBOL 139 Object-Oriented Cobol, OO-Cobol

obiektowy Fortran 139 Object-Oriented Fortran, OOF

obiektowy identyfikator

72136

object identifier, OID

obiektowy język Cobol

35 Cobol Object-Oriented Language, COOL


128140

object-oriented programming language, OOPL


128143

object query language, OQL, object-oriented query language

obiektowy model filtrów kompozycji

33 Composition Filters Object Model, CFOM

obiektowy monitor transakcji

147 Object Transaction Monitor, OTM

obiektowy SQL 146 object SQL, OSQLobiektowy system

CASE129 object-oriented CASE

systemobiektowy system

operacyjny129 object-oriented

operating systemobiektowy system

powszechnego LISP-u

34 Common LISP Object System, CLOS

obiektowy system wspomagania inżynierii oprogramowania

129 object-oriented CASE system


129139147

object database management system, ODBMS, object-oriented data

base management system, OODBMS

obiekty jako wartości

130 objects-by-value

obiekty rozproszone 130 distributed objectsObject Currents 130Object Domain 130Object Lisp 130Object Magazine

Online130

ObjectBroker 130Objective C 131Objective Pascal 131Objectivity/DB 131ObjectLOGO 131Objectory 131ObjectStore 131Object-Z 131obsługa komunikatów messagingobsługa wyjątków 131 exception handlingobywatel drugiej

kategorii131 second-class citizen

obywatel pierwszej kategorii

131 first-class citizen

obywatelstwo 132 citizenshipobywatelstwo klasy 132 class citizenshipochrona 132 securityOdapter 132ODB 126

132ODB (Object Data

Base)ODBC 132 ODBC (Open Data

Base Connectivity) ODB-II 133odbiorca 133 receiverODBMS 133 ODBMS (Object

DataBase Management System)

Ode 133ODL 82

133ODL (Object


ODMG 133 ODMG (Object Database Management Group, Object Data Management Group)

283


ODMG 2.0 133ODMG-93 135odporność 135 robustnessodpowiedzialność 135 responsibilityodsyłacz 135

153217

pointer, reference

odsyłać pointodśmiecacz 64

103135

garbage collector, GC

odśmiecanie 135 garbage collection odtwarzanie 135 recoveryodwracanie 135 rollback, roll-backodwrócenie undoodwzorować mapodwzorowanie mappingodwzorowanie

językowe136 language mapping

ogólny protokół między pakietami ORB

65 General Inter-ORB Protocol, GIOP

ograniczenia integralnościowe

136 integrity constraints

ograniczenie 136 constraintograniczenie Millera 136 Miller limitOID 72

136OID (Object

Identifier, Object Identity)

OLAP 136164

OLAP (On Line Analytical Processing)

OLE 136 OLE (Object Linking and Embedding)

OLE Automation 136OLE2 136OLTP 137

164OLTP (On-Line

Transaction Processing)

OMA 137 OMA (Object Management Architecture)

Omega 138OMG 138 OMG (Object

Management Group)

OML 82138

OML (Object Manipulation Language)

Omniscience 138

OMT 138197

OMT (Object Modeling Technique)

Ontos DB 138OO 127

138OO (Object-Oriented)

OOA 14138

OOA (Object-Oriented Analysis)

OOA/OOD 126138

OOA/OOD (Object-Oriented Analysis / Object-Oriented Design)

OOAD 14126139

OOAD (Object-Oriented Analysis & Design)

OO-CASE 128139

OO-CASE (Object-Oriented CASE)

OO-Cobol 139 OO-Cobol (Object-Oriented Cobol)

OOD 127139

OOD (Object-Oriented Design)

OODA 139 OODA (Object-Oriented Design with Applications)

OODB 126139

OODB (Object-Oriented DataBase)

OODBMS 129139147

OODBMS (Object-Oriented Data Base Management System)

OOF 139 OOF (Object-Oriented Fortran)

OOIS 139 OOIS (Object-Oriented Information Systems)

OOP 140159

OOP (Object-Oriented Programming)

OOPL 128140

OOPL (Object-Oriented Programming Language)

OOPSLA 140 OOPSLA (Object-Oriented Programming Systems, Languages and Applications)

OORAM 140OOSA 140 OOSA (Object-

Oriented System Analysis)

Opal 140

284


oparty na wartościach value-basedopcyjny 140 optionalOPEN 140OpenDoc 140OpenIngres 141OpenRoad 141operacja 141 operationoperacja abstrakcyjna 141 abstract operationoperacja klasowa 141 class operationoperacja obca 141 foreign operationoperacja pochodna 141 derived operationoperator punktu

stałegofixed-point operator

oprogramowanie aplikacyjne

141 application software

oprogramowanie komponentowe

141 component software, componentware

oprogramowanie pośredniczące

142 middleware

oprogramowanie spadkowe

142 legacy software

optymalizacja zapytań

142 query optimization

optymalizator zapytań

143 query optimizer

optymistyczny model transakcji

143 optimistic transaction model

OQL 128143

OQL (Object Query Language)

Oracle-8 144ORB 144

156ORB (Object Request

Broker)ORBeline 145Orbix 145OrbixWeb 145ORBPlus 145ORDBMS 128

145ORDBMS (Object-

Relational Data Base Management System)

organizacja gron 145 clusteringorganizacja klastrów clusteringorganizować grona clusterorganizować klastry cluster

ORSZBD (Obiektowo-Relacyjny System Zarządzania Bazą Danych)

128145

ORDBMS (Object-Relational Data Base Management System)

ortogonalna trwałość

145 orthogonal persistence

ortogonalność 145 orthogonalityortogonalny 146 orthogonalOS 146

208OS (Object Services)

OSA 146 OSA (Object-oriented System Analysis)

OSF 146 OSF (Open Software Foundation)

osłaniać wraposłona 146 wrapperosłonowanie 146 wrappingOSMOS 146OSQL 146 OSQL (Object SQL) OSZBD (Obiektowy

System Zarządzania Bazą Danych)

129139147

ODBMS (Object Data Base Management System), OODBMS (Object-Oriented Data Base Management System)

OTM 147 OTM (Object Transaction Monitor)

otoczenie 147 environmentotwarta skrzynka 147 open boxotwarte połączenie do

baz danych132 Open Data Base

Connectivity, ODBC

otwarty system 147 open system

Ppakiet 147 packageparadygmat

programowania147 programming

paradigmparametr aktualny 148 actual parameterparametr formalny 148 formal parameterparametr metody 148 method parameterparametryczny

polimorfizm148154

parametric polymorphism

Pegasus 148Perl-5 148Persistence 148

285


Persistent Java 148personifikacja 148 personificationperspektywa 148 viewperspektywa bazy

danych 149 database view

perspektywa obiektowa

126149

object view, object-oriented view

perspektywa relacyjna 172 relational viewpesymistyczny

model transakcji149 pessimistic

transaction modelPhantom 149pielęgnacja 149 maintenancepielęgnacja

oprogramowania149 software maintenance

pielęgnacyjność 149 maintainabilitypień stubpierwsza postać

normalna7

149First Normal Form,

1NFpies 149 dogPixScript 150Pjama 150Pjava 150plan wykonania

zapytaniaquery execution plan

platforma 150 platformplik 150 filepłaski plik 150 flat filepniak 150 stubpniak RPC 150 RPC stub pochodny 150 derivedpodejście stosowe 150 stack-based approachpodklasa 151 subclasspodnieść wyjątek 151 raise exceptionpodobiekt 151 subobjectpodobny do spaghetti 151 spaghetti-likepodschemat 151 subschemapodstan 151 substatepodstawienie assignmentpodstawowy adapter

obiektów26

152Basic Object Adapter,

BOApodtransakcja

kompensującacompensation

subtransactionpodtyp 152 subtypepodzbiór 152 subsetpodział 152 partitionpodział kompletny 152 complete partition

podział niekompletny

152 incomplete partition

Poet 152pointer 135

153217

pointer

pojedyncza dyspozycja

153 single dispatching

pojedyncze dziedziczenie

153 single inheritance

pojęciowy 153 conceptualpojęciowy model

danych153 conceptual data model

pole 153 field, slotpole statyczne 153 static fieldpolimorfizm 153 polymorphismpolimorfizm ad hoc 153 ad hoc polymorphismpolimorfizm

inkluzyjny153 inclusion

polymorphismpolimorfizm metod 154 method


nieograniczonyunbounded


ograniczonybounded


parametryczny148154

parametric polymorphism

polimorfizm statyczny

154 static polymorphism

polimorfizm typów 154 type polymorphismpołączenie mergingpołączenie do baz

danych z Java81 Java Data Base

Connectivity, JDBCpołączyć mergepomost 154 gatewayponowne użycie 154 reuseponownie używać reuseporównanie głębokie 155 deep comparisonporównanie płytkie 156 shallow comparisonpostać normalna

Boyce-Codda24

156Boyce-Codd Normal

Form, BCNFPostgres 156postrelacyjny 156 post-relationalpośredni przodek 156 indirect ancestorpośrednik 156 brokerpośrednik zleceń

obiektowych144156

Object Request Broker, ORB

potwierdzenie 156 commit

286


potwierdzenie transakcji

156 transaction commit

PowerBroker 156powiadamiający notifierpowiadomienie notifierpowiązać linkpowiązanie 157 linkpowiązanie

dwukierunkowe 157 bidirectional link

powiązanie jednokierunkowe

157 unidirectional link

powiązanie pochodne

157 derived link

powiązanie wskaźnikowe

157 pointer link

powiązanie zwisające 232 dangling linkpowszechny model

obiektowy34

157113

Common Object Model, COM

poziomy izolacji isolation levelspółkrata 157 semilattice, semi-

latticepółstrukturalne 157 semistructured, semi-

structuredpóźne wiązanie 157 late bindingpragma 157 pragma prawo Demetera 158 law of Demeterpredykat 158 predicateprekompilator 158 precompilerPRESTO 158procedura 158 procedureprocedura bazy

danych158 database procedure

procedura funkcyjna

158 functional procedure

proceduralny 158 proceduralproces 158 processproces iteracyjny 158 iterative processprogram

aplikacyjny159 application program

programowanie dynamiczne

159 dynamic programming

programowanie generyczne

65159

generic programming


140159

object-oriented programming, OOP

programowanie obiektowe wyższego rzędu

159 higher-order object-oriented programming

programowanie sterowane zdarzeniami

159 event-driven programming

programowanie wizyjne

159 visual programming

programowanie wyższego rzędu

159 higher-order programming

programowanie zdarzeniowe

160 event-driven programming

projekcja 160 projectionprojektowanie 160 designprojektowanie

logiczne160 logical design

projektowanie obiektowe

127139160


projektowanie obiektowego oprogramowania

52 Designing Object-Oriented Software, DOOS

projektowanie przez kontrakty

160 design by contracts

projektowanie wspomagane komputerem

31160

Computer Aided Design, CAD

prośba o informację 174 Request For Information, RFI

prośba o propozycję 174 Request For Proposal, RFP

protokół 160 protocolprotokół pomiędzy

ORB-ami specyficzny dla środowiska

60 Environment-Specific Inter-ORB Protocols, ESIOP

prototyp 161 prototypeprywatny 161 privateprzechwycenie

wyjątku 161 catch an exception,

exception catchprzeciążać overloadprzeciążanie 161 overloadingprzecięcie intersectionprzedmiot rozważań 161

207universe of discourse,

UoDprzeglądać browseprzeglądanie 161 browsingprzeglądarka 162 browserprzejście 162 transitionprzekazywanie

parametrów162 parameter passing

przemiana wskaźników

162 pointer swizzling

287


przemieniać swizzleprzenaszalność 162 portabilityprzenaszalność

serweraserver portability

przepisywać rewriteprzepisywanie 163 rewritingprzepływ danych 163 data flowprzepływ pracy 163 workflowprzepływ sterowania 163 control flowprzesłaniać overrideprzesłanianie 164 overridingprzestrzeń stanów 164 state spaceprzesunięcie 164 offsetprzesuń i upuść drag and dropprzesyłanie

komunikatów164 message passing


136164

On Line Analytical Processing, OLAP


137164

On-Line Transaction Processing, OLTP

przezroczystość 164 transparencyprzezroczystość

rozproszenia165 distribution

transparencyprzodek 165 ancestorprzodek bezpośredni direct ancestorprzodek pośredni 165 indirect ancestorprzyjazność 165 friendliness, user

friendlinessprzyjazny user friendlyprzypadek typu 165 typecaseprzypadek użycia 165 use caseprzypisany 166 proprietaryprzyrostowy 166 incrementalpseudoteoretyk 166 pseudo-theoreticianpseudoteoria 166 pseudo-theorypseudozmienna 168 pseudo-variablePSM 168

183225

PSM (Persistent Storage Manager)

PTR 168201

PTR (Persistence Through Reachability)

publiczny 168 publicpunkt pointpunkt funkcyjny 62

168Function Point, FP

punkt kontrolny 168 checkpoint

Python 168

QQA 168

224QA (Quality

Assurance)

Rrachunek materiałów 27 Bill-Of-Material,

BOMrachunek relacyjny 168 relational calculus RAD 169

195RAD (Rapid

Application Development)

Raima Object Manager

169

RAP 169195

RAP (Rapid Application Prototyping)

RDBMS 169173178


rdzeń ORB 169 ORB corereferencja 169 referencerefleksja 169 reflectionrefleksja

lingwistyczna170 linguistic reflection

reguła 170 rulereguła biznesowa 170 business rulereguła

wnioskowania o typie

170 type inference rule

reguły aktywne 12 active rulesreguły zakresu 171 scope rules, scoping,

scoping rulesreinżynieria 171 reengineering, re-

engineeringreinżynieria


27171

Business Process Reengineering, BPR

rekord 171 recordrelacja 171 relationrelacje

nieznormalizowane120122

Non-First-Normal-Form, NF2, NF2, non-normalized relations

relacje zagnieżdżone 221 embedded relations, nested relations

288


relacyjna baza danych

172 relational database

relacyjna perspektywa

172 relational view


169173178

Relational Data Base Management System, RDBMS

relewancja 173 relevancereplikacja 173 mirror, replicationreplikator 173 replicatorrepozytorium 174 repositoryrepozytorium

implementacji 174 implementation

repositoryrepozytorium

interfejsów78

174interface repository,

IRrepozytorium

Microsoftu117 Microsoft Repository,

MS Repository REXX 174RFI 174 RFI (Request For

Information) RFP 174 RFP (Request For

Proposal) RMI 174

216RMI (Remote

Message Invocation)

rola 174 rolerola asocjacji 176 association roleRose 176RoughWave 176rozgnieżdżać unnestrozgnieżdżanie unnestingrozproszona baza

danych176 distributed database

rozproszone obiekty 176 distributed objectsrozproszone

środowisko obiektów

51 Distributed Object Environment, DOE

rozproszone środowisko obliczeniowe

39 Distributed Computing Environment, DCE

rozproszone środowisko zarządzania obiektami

51 Distributed Object Management Environment, DOME

rozproszone udogodnienie do zarządzania obiektami

51 Distributed Object Management Facility, DOMF

rozproszony powszechny model

39176

Distributed Common Object Model,

obiektowy DCOMrozproszony

standardowy model obiektowy

53 Distributed Standard Object Model, DSOM

rozproszony system obiektowy

176 distributed object system

rozprzestrzenianie 177 deploymentrozszeregowanie 177 unmarshallingrozszerza extendsrozszerzalność 177 extensibilityrozszerzony model

encja-związek58 Extended Entity-

Relationship, EERrozszerzony

relacyjny SZBD177 extended relational

DBMS rozszerzony RSZBD 178 extended RDBMSrozwój

oprogramowania178 software development

równorzędny 178 peerrównorzędny-do-

równorzędnego178 peer-to-peer

RPC 178216

RPC (Remote Procedure Call)

RSZBD (Relacyjny System Zarządzania Bazą Danych)

169173178


Rumbaugh, James 178r-wartość 178 r-valuerzutowanie 178 cast

Ssam 180 self samoreferencja 178 self-referenceSather 178scalenie mergingscalić mergescenariusz 179 scenarioschemat bazy

danych179 database schema

schemat federacyjny 179 federated schemaschemat fizyczny 179 physical schemaschemat globalny 179 global schemaschemat logiczny 180 logical schemaschemat obiektowy 180 object schemaschemat pojęciowy 180 conceptual schemaschemat wewnętrzny 180 internal schemasekwencja 180 sequence

289


selekcja 180 selectionselektor 180 selectorSelf 180semantyczny model

danych 180 semantic data model

semantyka 181 semanticssemantyka danych 181 data semanticssemantyka oparta na

kopiowaniu181 copy semantics

semantyka oparta na referencjach

181 reference semantics

serwer 181 serverserwer aplikacji 181 application sever serwer transakcji

Microsoftu118 Microsoft Transaction

Server, MTSserwlet 181 servlet Shlaer-Mellor 182SI (System

Informacyjny)78

182IS (Information

System)SI (System

Informatyczny)78

182IS (Information

System)sieciowy model

danych 182 network data model

silnik wyszukiwawczy

182 search engine

Simula-67 182Sina 182Sintropy 182skalowalność 182 scalabilityskład danych 183 data storeskład obiektów 183 object store, storage

domainskład trwałych

obiektów168183225

Persistent Storage Manager, PSM, persistent object store

składnica danych 183 data martskładowanie 183 back upskojarzenie 183 couplingsłaba kontrola typów 183 weak type checking,

weak typingsłaba kontrola typów 183 weak typingsłabo typowany 183 weakly typedsłaby klient thin clientsłoń 183 elephantsłownik 183 dictionarysłownik danych 183 data dictionarysłownik-przewodnik 40 data dictionary-

danych 86 directory, DDDSmalltalk 184SOM 184 SOM (System Object

Model) SOMA 184spadek 184 legacyspadkowy 185 legacyspaghetti 185 spaghetti specjalizacja 185 specializationspecyfikacja 185 specificationspowodować wyjątek 185 raise exceptionspójność 185 consistencysprawdzian 185 benchmarksprytny wskaźnik 186 smart pointerSQA 186 SQA (Software

Quality Assurance) SQL 186 SQL (Structured

Query Language) SQL3 187stabilność stabilitystan 188 statestan końcowy 188 final statestan obiektu 188 object statestan początkowy 188 initial statestandard faktyczny 188 defacto standardstandard prawny 188 dejure standardStarburst 188statyczna funkcja

członkowska188 static member

functionstatyczna

klasyfikacja189 static classification

statyczna kontrola typów

189 static type checking, static typing

statyczne wiązanie 189 static bindingstatyczny

polimorfizm189 static polymorphism

STD 4751

189

STD (State Transition Diagram)

stempel czasowy 189 time stampstereotyp 189 stereotypesterowanie dostępem 189 access controlsterowanie wersjami 190 version controlsterowany

zdarzeniami190 event-driven

sterta 190 heapstos środowisk 190 environment stack

290


stos środowiskowy 190 environmental stackstos wołań 191 call stackstrategia od dołu do

góry191 bottom-up strategy

strategia od góry do dołu

191 top-down strategy

strategia od środka na zewnątrz

191 inside-out strategy

strażnik 191 guardStroustrup, Bjarne 191struktura 191 structurestruktura klas 192 class structurestruktura obiektów 192 object structurestrukturalna


192 structural type equivalence

strukturalna zgodność typów

192 structural type conformance

strukturalny język zapytań

186 Structured Query Language, SQL

strumień streamstudium osiągalności 192 feasibility studysuma zbiorów union super 192 super superklasa 192 superclasssurogat 192 surrogateSybase Adaptive

Server 192

sygnatura 192 signaturesynchroniczny 193 synchronoussynchronizacja 193 synchronizationsyndrom NIH 193 NIH syndromesystem aktywny 193 active system,

reactive systemsystem informacji

geograficznej65

193Geographic

Information System, GIS

system informacyjny, SI

78182

information system, IS

system informatyczny do zarządzania

109 management information system, MIS

system informatyczny, SI

78182

information system, IS

system otwarty 193 open systemsystem wspomagania

decyzji53 Decision Support

System, DSSsystem zarządzania

bazą danych, 39

193database management

SZBD 194 system, DBMSsystem zarządzania

bazą wiedzy86

194Knowledge Base

Management System, KBMS

systemowy model obiektowy

184 System Object Model, SOM

szablon 194 templateSZBD (System

Zarządzania Bazą Danych)

39193194


szeregowalność 194 serializabilityszeregowanie 195 marshallingszkielet 195 framework, skeletonszkielet dla obiektów

biznesowych26 Business Object

Framework, BOFszkielety na poziomie

dziedzindomain-level

frameworksszklana skrzynka 195 glass boxszybka budowa

aplikacji 169195

rapid application development, RAD

szybka budowa prototypów aplikacji

169195

rapid application prototyping, RAP

ścieżka dostępu 195 access pathścieżka przejścia 195 traversal pathśmiecie na wejściu -

śmiecie na wyjściu65 Garbage In - Garbage

Out, GIGOśrodowisko 196 environmentśrodowisko

obiektowe Java85 Java Object

Environment, JOE

Ttabela 196 tabletablica 196 array, tabletablica asocjacyjna 196 associative tabletablica dynamiczna 197 dynamic arraytablica pośrednia 197 indirection tabletablica przejść indirection tabletablica z kodowaniem

mieszającymhash table

TAPOS 197 TAPOS (Theoretical And Practical Aspects of Object Systems)


138197

Object Modeling Technique, OMT

technologia obiektowych języków i systemów

199 Technology of Object-Oriented Languages and

291


Systems, TOOLSten 199 this teoretyczne i

praktyczne aspekty systemów obiektowych

197 Theoretical And Practical Aspects of Object Systems, TAPOS

teoretyczny masochista

197 theoretical masochist

teoretyczny terrorysta

197 theoretical terrorist

teoretyk 198 theoreticianterabajt 199 terabytetest alfa 12 alpha testtest beta 25 beta testtestowanie alfa 12 alpha testingtestowanie beta 25 beta testingTheta 199this 199Thor 199three amigos 199TID 72

199TID (Tuple

IDentifier)tłusty klient 199 fat clientTOOLS 199 TOOLS (Technology

of Object-Oriented Languages and Systems)

tożsamość 199 identitytożsamość obiektu 72

136object identity, OID

transakcja 200 transactiontransakcja

projektowa 200 design transaction

transakcje zagnieżdżone

nested transactions

tranzytywne domknięcie

200 transitive closure

treść metody 201 method bodytrwała zmienna 201 persistent variabletrwałość 201 persistencetrwałość poprzez

dziedziczenie201 persistence through

inheritancetrwałość poprzez

osiągalność168201

persistence through reachability, PTR

trwały identyfikator 201 persistent identifiertrwały korzeń 202 persistent roottrwały obiekt 125

202persistent object

trwanie 202 durability

tryger 202 triggertrzeci manifest 202 Third Manifestotrzecia postać

normalna7

202Third Normal Form,

3NFtrzej przyjaciele 199 three amigostrzywarstwowa

architektura202 three-tiered

architecturetworzenie creatingtworzenie

wystąpienia202 instatiation

tworzenie wystąpień 202 instatiationtworzenie,

wyszukiwanie, aktualizacja, usuwanie

37 Create, Retrieve, Update, Delete, CRUD

twór artifacttyp 202 typetyp abstrakcyjny 203 abstract typetyp atrybutu 203 attribute typetyp etykietowany tagged typetyp kompozytowy 203 composite typetyp konkretny 203 concrete typetyp konstruowany 203 constructed typetyp masowy 203 bulk typetyp nieprzejrzysty 203 opaque typetyp

parametryzowany 204 parameterized type

typ pochodny 204 derived typetyp podstawowy 204 basic typetyp potomny 204 child typetyp prymitywny 204 primitive typetyp referencyjny 204 reference typetyp rozróżniony 204 distinct typetyp szablonowy 204 template typetyp wbudowany 204 build-in typetyp wyliczeniowy 205 enumeration type

UUFO 205 UFO (Unidentified

Flying Object, United Functions and Objects)

ukrywanie informacji

205 information hiding

ulotny 205 temporary, transient, volatile

UML 205231

UML (Unified Modeling

292


Language)unia 206 union unia typów 207 type unionunia z

dyskryminatorem 207 discriminated union

unifikacja międzyjęzykowa

74 Inter-Language Unification, ILU

UniSQL 207uniwersalny serwer 207 universal serverUoD 161

207UoD (Universe of

Discourse)uruchomić fireusługa handlowa 209 Trader Serviceusługa w zakresie

cyklu życiowego208 Life Cycle Service

usługa w zakresie czasu

208 Time Services

usługa w zakresie kolekcji

209 Collection Service

usługa w zakresie licencji

208 Licensing Service

usługa w zakresie nazywania

208 Naming Service

usługa w zakresie ochrony

209 Security Service

usługa w zakresie transakcji

208 Transaction Service

usługa w zakresie trwałości

208 Persistence Service

usługa w zakresie udostępniania na zewnątrz

208 Externalization Service

usługa w zakresie własności

208 Properties Service

usługa w zakresie współbieżności

208 Concurrency Control Service

usługa w zakresie zapytań

208 Query Service

usługa w zakresie zdarzeń

208 Event Service

usługa w zakresie związków

208 Relationship Service

usługi obiektowe 146208

Object Services, OS

ustawiać setusuń 209 deleteusuwanie deletingutrzymanie maintenance

utrzymanie oprogramowania

209 software maintenance

utwórz 209 createużytkownik 209 userużywa uses

VVbase 209VC++ 209 VC++ (Visual C++)VDM++ 209 VDM++ (Vienna

Development Method++)

Versant 209VisiBroker 209Visual Age 210Visual Basic 210Visual C++ 210

Ww locie 210 on-the-flywariant 210 variantwarstwa obiektowa

systemu Chorus35 Chorus Object-

Oriented Layer, COOL

wartość domyślna 210 default valuewartość masowa 210 bulk valuewartość zerowa,

NIL, NULL122123210

null value, NIL, NULL

warunek conditionwarunek końcowy 211 postconditionwarunek wstępny 212 preconditionwątek 212 threadwczesne wiązanie 212 early bindingwdrażanie 177 deploymentwersja 212 versionwersja alfa 12 alpha versionwersja beta 25 beta versionwiązać bindwiązanie 212 binding, linkingwiązanie do Java Java bindingwiązanie

dynamiczne212 dynamic binding

wiązanie i zagnieżdżanie obiektów

136 Object Linking and Embedding, OLE

wiązanie późne 212 late binding

293


wiązanie statyczne 212 static bindingwiązanie wczesne 212 early bindingwidoczność 212 visibilitywidżet 213 widget wiedeńska metoda

rozwoju - język specyfikacji

Vienna Development Method Specification Language, VDM-SL

wiedeńska metoda rozwoju++

209 Vienna Development Method++, VDM++

wielodostęp 213 concurrent accesswielodziedziczenie 213 multi-inheritancewielokrotna

dyspozycja213 multiple dispatching

wielokrotne dziedziczenie

213 multiple inheritance

wielokrotne interfejsy

214 multiple interfaces

wielowarstwowa architektura

214 multi-tiered architecture

wielowartościowy atrybut

214 multi-valued attribute

wielowątkowy 214 multi-threadedwielozbiór 214 bag, multiset, multi-

setwiersz 214 row, tuplewięzy integralności 214 integrity constraintsWirfs-Brock 214Wirfs-Brock,

Rebecca214

wirtualny 214 virtualwirtualny atrybut 214 virtual attributewizja 214 viewwizyjny visualwizyjny C++ 209

210Visual C++, VC++

własności behawioralne

215 behavioral properties

własność domkniętości

215 closure property


174216

remote message invocation, RMI


178216

remote procedure call, RPC

wołanie poprzez nazwę

216 call-by-name

wołanie poprzez potrzebę

216 call-by-need

wołanie poprzez 216 call-by-reference

referencjęwołanie poprzez

wartość217 call-by-value

wołanie poprzez wartość ze zwrotem

217 call-by-value-return

wskazywać pointwskaźnik 135

153217

pointer

wskaźnik bieżący currency indicatorwskaźnik zwisający 232 dangling pointerwspomaganie dla

zapory ogniowej protokółu IIOP

IIOP firewall support

wspólne udogodnienia

33217

Common Facilities, CF

wspólne udogodnienia pionowe

218 vertical common facilities

wspólne udogodnienia poziome

218 horizontal common facilities

współbieżność 218 concurrencywspółbieżny język

obiektowy 35 Concurrent Object-


współdziałanie 218 interoperabilitywspółpraca 91 collaborationwstaw 218 insertwstawiać insertwstawianie insertingwstępny warunek 212 preconditionwyciągać mnożnik factor (out)wyciągać przed

nawiasfactor (out)

wyciąganie mnożnika

218 factoring (out)

wyciąganie przed nawias

218 factoring (out)

wyciekanie pamięci 219 memory leak, memory leakage, storage leak

wydajność 219 performancewydajność

maszynowa219 performance

wydajność wytwarzania

219 productivity

wyjątek 219 exceptionwykonawczy system 58 Executive

294


informacyjny Information Systems, EIS

wykonywać dereferencję

dereference

wykorzystanie kontraktów w oprogramowaniu

software contracting

wykres stanów 219 state chart, statechartwyliczalny 219 derivedwymagania 219 requirementswymiatanie 219 scavengingwyrażenie kropkowe 219 dot expressionwyrażenie ścieżkowe 220 path expressionwysłanie

komunikatu220 sending a message

wystąpienie 220 instancewystąpienie

przypadku użycia220 use case instance


31220

Computer Aided Manufacturing, CAM

wytwór artifactwytwórstwo

oprogramowania220 software development

wyzwalacz 220 triggerwyzwolić 220 firewzorzec 220 patternwzorzec projektowy 220 design pattern

X Y ZYourdon, Ed 221Z++ 221zabezpieczony protectedzablokować lockzachowanie 221 behaviour, behaviorzadawać pytanie queryzagnieżdżać nestzagnieżdżanie nesting zagnieżdżone relacje 221 nested relations,

embedded relationszagnieżdżone

transakcje 221 nested transactions

zagnieżdżone zapytanie

222 nested query

zagnieżdżony 222 nestedzakleszczenie 222 deadlockzakres 222 scope

zakres dynamiczny 222 dynamic scopezakres leksykalny 222 lexical scope zakres statyczny 223 static scopezależne złączenie 223 dependent joinzależność funkcyjna 223 functional

dependencyzależność

wielowartościowamulti-valued

dependencyzależność

złączeniowajoin dependency

zamek 223 lockzamek do czytania 223 read lockzamek do pisania 224 write lockzamienialność 224 substitutabilityzamknąć lockzanurzać embedzanurzenie embeddingzanurzone zapytanie 224 embedded query zanurzony 224 embedded, nestedzapamiętana

procedura224 stored procedure

zapewnienie jakości 168224

quality assurance, QA

zapewnienie jakości oprogramowania

186 software quality assurance, SQA

zapis 225 recordzapis z wariantami 225 record with variantszapisywać recordzapytanie 225 queryzapytanie ad hoc 225 ad hoc queryzapytanie

interakcyjne225 interactive query

zapytanie zagnieżdżone

225 nested query

zapytanie zanurzone 225 embedded query zarządca trwałymi

obiektami168183225

Persistent Storage Manager, PSM

zarządzanie aplikacją (aplikacjami)

application management

zarządzanie wersjami 225 version managementzasada

korespondencji 225 correspondence

principlezasada

otwarte/zamknięte 226 open/closed principle

zasada relatywizmu 226 relativity principlezasada zamienialności 226 substitutability

principle

295


zasada zamienialności Liskov

99 Liskov Substitution Principle, LSP

zastępowalność 226 substitutabilityzastosowanie

spadkowe226 legacy application

zbalansowane drzewo, B-drzewo

24 balanced tree, B-tree

zbieranie nieużytków

226 garbage collection

zbiór 226 setzdarzenie 227 eventzdarzenie zegarowe 227 clock eventzdarzenie-warunek-

akcja58

227Event-Condition-

Action, ECAzdjęcie 227 snapshotzdjęcie migawkowe snapshotzdolny do trwałości 227 persistence-capablezerwanie 227 abortzerwanie transakcji 227 transaction abortzestaw miar 228 metrix suitezestaw rozwoju


81 Java Developer Kit, JDK

zestaw testów 228 test suitezewnętrzne złączenie 222

230outer join

zgodność typów 228 type conformancezgodny (z czymś) compliantziarnistość 228 granularityziarnistość autoryzacji authorization

granularityziarnistość

blokowanialocking granularity

ziarnistość replikacji replication granularityziarnistość zamykania locking granularityzintegrowany system

produkcyjny w języku C

33 C Language Integrated Production System, CLIPS

zlać mergezlanie mergingzlecenie 229 requestzlecenie

asynchroniczne229 asynchronous request

zlecenie synchroniczne

229 synchronous request

zliczanie referencji 229 reference countzłączenie 229 join

złączenie naturalne 229 natural joinzłączenie

nawigacyjne229 navigational join

złączenie zależne 230 dependent joinzłączenie zewnętrzne 222

230outer join

złożoność 230 complexityzłożony atrybut 230 complex attribute,

composite attributezłożony klucz 90 composite key,

compound keyzłożony obiekt 230 complex object,

composite objectzmaterializowana

perspektywa230 materialized view

zmienialność 230 mutabilityzmienialny 230 mutablezmienna globalna 230 global variablezmienna gospodarza host variablezmienna klasowa class variablezmienna klasy 230 class variablezmienna polowa 231 field variablezmienna trwała 201 persistent variablezmienna własna own variablezmienna wystąpienia 231 instance variablezmienność 231 mutabilityznacz i zamiataj 231 mark and sweepzorientowany na

wartości231 value-oriented

zorientowany obiektowo

127138231

object-oriented, OO

zrzucać dumpzrzut dump, dumpingzunifikowane funkcje

i obiekty205 United Functions and

Objects, UFOzunifikowany język

do modelowania205231

Unified Modeling Language, UML

związek 231 relationshipzwiązek „jest” 231 is-a relationshipzwiązek

dwukierunkowy232 bidirectional

relationshipzwiązek

jednokierunkowy 232 unidirectional

relationshipzwiązek pochodny 232 derived relationshipzwisające

powiązanie 232 dangling link

zwisający wskaźnik 232 dangling pointer

296

Problemy Współczesnej NaukiTeoria i Zastosowania

Informatyka

Wykaz książek, które ukazały się w tej serii:

1. A. Mykowiecka, Podstawy przetwarzania języka naturalnego. Metody generowania tekstów 2. E. Dobryjanowicz, Podstawy przetwarzania języka naturalnego. Wybrane metody analizy składniowej 3. L. Bolc, A. Mykowiecka, Podstawy przetwarzania języka naturalnego. Wybrane metody formalnego zapisu składni 4. L. Bolc, J. Zaremba, Wprowadzenie do uczenia się maszyn 5. A. Szałas, Zarys dedukcyjnych metod automatycznego wnioskowania 6. R. Tadeusiewicz, Sieci neuronowe 7. W. Mokrzycki, Encyklopedia przetwarzania obrazów 8. M. Muraszkiewicz, H. Rybiński, Bazy danych 9. W. Skarbek, Metody reprezentacji obrazów cyfrowych10. E. Gatnar, Metody modelowania jakościowego11. M. Byrska, Ochrona programu komputerowego w nowym prawie autorskim12. K. Subieta, Ingres - system zarządzania relacyjną bazą danych13. J. Korbicz, A. Obuchowicz, D. Uciński, Sztuczne sieci neuronowe - podstawa i zastosowania14. Z. Suraj, B. Komarek, GRAF - Graficzny system konstruowania i symulowania sieci Petriego15. J. Chromiec, E. Strzemieczna, Sztuczna inteligencja. Metody konstrukcji i analizy systemów eksperckich16. J. Cytowski, Algorytmy genetyczne17. A. Wakulicz-Deja, Podstawy systemów wyszukiwania informacji. Analiza metod18. L. Polkowski, M. Szczuka, Elementy matematyki dla studentów kierunków informatycznych19. L. Bolc, K. Dziewicki, P. Rychlik, A. Szałas, Wnioskowanie w logikach nieklasycznych. Podstawy teoretyczne20. Z. Vetulani, W. Abramowicz, G. Vetulani, Język i technologia21. G. Bryll, Metody odrzucania wyrażeń22. E. Rafajłowicz, W. Myszka, LATEX - zaawansowane narzędzia23. D. Figura, Obiektowe bazy danych24. E. Hajnicz, Reprezentacja logiczna wiedzy zmieniającej się w czasie25. D. Rutkowska, Inteligentne systemy obliczeniowe. Algorytmy genetyczne i sieci neuronowe w systemach rozmytych

26. L. Banachowski, Bazy danych. Tworzenie aplikacji27. W. Skarbek (Red.), Multimedia. Algorytmy i standardy kompresji28. P. Zieliński, Systemy informatyczne dla bankowości w zarysie29. P. Adamczewski, Wdrożeniowe uwarunkowania zintegrowanych systemów informatycznych30. K. Wojciechowski, System z niepewnością ograniczoną. Model, analiza i modyfikacja. Podejmowanie decyzji i reguły decyzyjne 31. A. Czyżewski, Dźwięk cyfrowy. Wybrane zagadnienia teoretyczne, technologia, zastosowania32. R. Tadeusiewicz, Elementarne wprowadzenie do techniki sieci neurono- wych z przykładowymi programami33. K. Subieta, Obiektowość w projektowaniu i bazach danych 34. L. Bolc, K. Dziewicki, P. Rychlik, A. Szałas, Wnioskowanie w logikach nieklasycznych. Automatyzacja wnioskowania35. M. Nieniewski, Morfologia matematyczna w przetwarzaniu obrazów

Statystyka

Wykaz książek, które ukazały się w tej serii:

1. J.R. Thompson, J. Koronacki, Statystyczne sterowanie procesem. Metoda Deminga etapowej optymalizacji jakości2. E. Rafajłowicz, Algorytmy planowania eksperymentu z implementacjami w środowisku MATHEMATICA

W przygotowaniu znajdują się następujące pozycje:

1. J. Doroszewski, Struktura wiedzy i rozwiązywania problemów medycz- nych 2. M.A. Kłopotek, Konstrukcja systemów bazodanowych w światowej sieci komputerowej WWW 3. J. Kulikowski, Komputerowe przetwarzanie obrazów biomedycznych 4. E. Lipowska-Nadolska, M. Morawski, Tablice systoliczne. Problemy wybrane 5. A. Mrózek, Zastosowanie zbiorów przybliżonych 6. A. Piegat, Modelowanie i sterowanie rozmyte 7. R. Pruchnik, Algorytmy odwracalnej kompresji danych 8. A. Skowron, Podstawy sztucznej inteligencji 9. J. Wywiał, Elementy metody reprezentacyjnej z wykorzystaniem statys- tycznego pakietu SPSS

Obiektowość - ipipan.waw.plsubieta/artykuly/slownik_obiektowosci/slownik.doc · Web...

Documents

Transcript of Obiektowość - ipipan.waw.plsubieta/artykuly/slownik_obiektowosci/slownik.doc · Web...