Kazimierz Subieta: Słownik terminów z zakresu obiektowości

Kazimierz Subieta: Słownik terminów z zakresu obiektowości. Akademicka Oficyna Wydawnicza PLJ, Warszawa 1999, ISBN 83-7101-407-4, stron 290.

Książka jest już prawdopodobnie niedostępna w księgarniach. Osoby zainteresowane mogą skorzystać z pełnej wersji elektronicznej. Słownik ten w nieco okrojonej postaci znajduje się również na portalu Hoga. Angielsko-polski słowniczek do książki jest tutaj.

Hasła słownika

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.

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

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

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

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

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

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

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

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

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

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

http://www.activex.org/

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

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

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

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

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

http://www.omg.org

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

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

agent (agent) Patrz: aktywny agent.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

update Pracownik

set Zarobek = Zarobek+100

where Nazwisko = ‘Nowak’;

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

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

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

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

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

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

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

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

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

algebra obiektowa (object algebra) Z założenia, matematyczna podstawa semantyki obiektowych języków zapytań wzorująca się na algebrze relacji. Obiektowa algebra wprowadza operatory takie jak: złączenie, selekcja, projekcja, grupowanie, zagnieżdżanie (nesting), rozgnieżdżanie (unnesting) i inne. W odróżnieniu od algebry relacyjnej operatory te działają na zbiorach obiektów i zwracają zbiory obiektów. Powodem prac nad obiektowymi algebrami jest potrzeba takiego sformalizowania modelu obiektowego i semantyki języków zapytań, aby można było przeprowadzać dowody poprawności technik optymalizacji zapytań. Niestety, cel ten nie został jak dotąd osiągnięty. Z reguły, algebry te są niespójne koncepcyjnie, dość skomplikowane, niedostatecznie uniwersalne i mające luźne związki z rygorystyczną matematyką (przez co jakikolwiek „dowód” jest niewiarygodny). Obiektowe algebry są w gruncie rzeczy słabo sformalizowanymi językami (udekorowanymi symbolami i pojęciami matematycznymi), uważanymi przez ich autorów (bezpodstawnie) za dobrze przystosowane do wewnętrznego przetwarzania zapytań w obiektowej bazie danych, zgodnie z odwzorowaniami: 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 o orientacji teoretycznej) przypisują algebrze relacji zasadniczą rolę w optymalizacji zapytań, poprzez odkrycie praw umożliwiających np. wykonywanie (tańszych) operatorów selekcji i projekcji przed (droższymi) operatorami złączenia i produktu kartezjańskiego. Z kilku powodów tego rodzaju opinie są podważalne: (1) analogiczne prawa zostały zrealizowane (np. w systemie Ingres) na długo przedtem, niż pojawiło się ich algebraiczne „uzasadnienie”; (2) struktury danych przechowywane w systemach relacyjnych (tablice) różnią się semantycznie od struktur przetwarzanych przez algebrę relacyjną (relacji), wobec czego dowolne twierdzenie dotyczące algebry relacji nie musi być prawdziwe dla struktur danych systemów relacyjnych i wymaga istotnej weryfikacji praktycznej; (3) metody optymalizacyjne sugerowane przez algebrę relacji są fragmentem (niekoniecznie najważniejszym) zestawu metod optymalizacyjnych stosowanych w rzeczywistych systemach. Istnieje bardzo wiele prób przeniesienia koncepcji algebry relacji na grunt obiektowości; jak dotąd są one raczej nieudane. Patrz też: algebra obiektowa.

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

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

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

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

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

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

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

http://www.ansi.org

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

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

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

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

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

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

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

aplikacja spadkowa (legacy application) Patrz: zastosowanie spadkowe.

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

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

Architektura OSZBD

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

Architektura ANSI/SPARC

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.

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

http://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.

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

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 Zamówienie+produkt jest związana z co najwyżej jednym obiektem WierszZamówienia.

Przykład asocjacji kwalifikowanej

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

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.

Przykład asocjacji pochodnej

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

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

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

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.

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

http://www.o2tech.fr/

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

http://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).

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.

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

http://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/BoochReferenz

http://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 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 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ę 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.

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++.html

http://www.icce.rug.nl/docs/cplusplus/cplusplus.html

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

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.

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.

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 podstawianej wartości. CLU posiada zmienne własne (own variables) oraz wielokrotne podstawienie.

CO₂ Obiektowy język programowania (oparty o C) dla systemu O₂ (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/com

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

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.

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

http://www.acl.lanl.gov/CORBA/

http://www.acl.lanl.gov/cgi-bin/doclist.pl

http://www.cs.wustl.edu/~schmidt/corba.html

http://plato.cis.nctu.edu.tw/CORBA/idl.htm

http://www.sw-technologies.com/corba/

http://www.acl.lanl.gov/~reverbel/orb_odbms.html

http://adams.patriot.net/~tvalesky/freecorba.html

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

http://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.

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.

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

http://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 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 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.

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.

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.

Przykład diagramu aktywności w UML

http://www.rational.com/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.

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

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

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

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

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

diagram kolaboracji (collaboration diagram) Istotą diagramów kolaboracji jest przedstawienie przepływu komunikatów pomiędzy obiektami. Kolaboracja pomiędzy 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.

Przykładowy diagram kolaboracji

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

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.

Przykładowy diagram komponentów

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

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

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 przykładowy diagram pakietów w UML dla systemu okienkowego włączającego pewien edytor.

Przykładowy diagram pakietów

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

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.

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.

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

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.

Przykładowy diagram sekwencji

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.

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

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.

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

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

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

diagram tropów zdarzeń (event-trace diagram) Diagram pokazujący byty 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 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 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 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.

Dwufazowe potwierdzenie

Dylan Obiektowy język programowania firmy Apple.

http://www.cambridge.apple.com/dylan/dylan.html

http://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 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ć 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.

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.

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.

E Rozszerzenie C++ o typy właściwe dla baz danych oraz obiekty trwałe. E jest 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.com

http://hepunx.rl.ac.uk/atlas/oo/eiffel/intro.html

http://www.cm.cf.ac.uk/CLE/index.html

http://outback.eiffel.com/eiffel/index.html

http://www.sigs.com/publications/docs/oc/9604/oc9604.c.meyer.html

http://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ę 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.

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/

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

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

http://iamwww.unibe.ch/~scg/OOinfo/FAQ/index.html

http://info.gte.com/ftp/doc/activities/x3h7.html

http://morannon.fido.de/~mj/links/l_oo.html

http://swss00.isbe.ch/~bach/oo.html

http://wombat.doc.ic.ac.uk/

http://www.aisys.com/objectGate/people/ooFolk.html

http://www.cera.com/object.htm

http://www.cetus-links.org/

http://www.clark.net/pub/howie/OO/oo_home.html

http://www.cyberdyne-object-sys.com/oofaq/

http://www.enteract.com/~bradapp/links/oo-links.html#OO

http://www.fokus.gmd.de/ovma/dooos/

http://www.mtjeff.com/~calvin/devhbook/objectori.html

http://www.next-objects.com/ooanluc.htm

http://www.next-objects.com/ooanly/index.htm

http://www.next-objects.com/tutpage.htm

http://www.objfocus.com/object.html

http://www.odbmsfacts.com/

http://www.planet.net/bwalker/oo.html

http://www.rai.com/soft_eng/indexes/oop.html

http://www.rhein-neckar.de/~cetus/oo_entry.html

http://www.sigs.com/resources.html

http://www.sigs.com/omo/dot/index.html

http://www.soft-design.com/softinfo/objects.html

http://www.tiac.net/users/chasb/c-ot.html

http://www.tiac.net/users/jsuth

http://www.toa.com/shnn?htmldocs

http://www.toa.com/shnn?onlinedocs

http://www.well.com/user/ritchie/oo.html

http://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.

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

http://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 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/fusion

http://arkhp1.kek.jp/managers/computing/activities/OO_CollectInfor/

Methodologies/Fusion/fusionBook/fusionBookContents.html

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

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 2³⁰, 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.

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

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

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.

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.

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

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.

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.

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.

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

Przykład specyfikacji w IDL

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

http://www.omg.org

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

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

http://www.omg.org

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

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

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

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, {l₁(w), l₂(w), l₃(w), ...}>, gdzie w jest wartością danego atrybutu, zaś {l₁(w), l₂(w), l₃(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.

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

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.

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

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.

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.

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

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.

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.

http://www.rational.com/

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

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

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

http://reality.sgi.com/employees/austern/java.html

http://sunsite.net.edu.cn/tutorials/se_java2e/

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

http://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.edu

http://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.html

http://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.html

http://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:

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 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, 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).
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

kapsułkowanie (encapsulation) Patrz: hermetyzacja.

karta CRC (CRC card) Karta papierowa posiadająca trzy pola nazwane: klasa, 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.

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.

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.

Przykład klasy asocjacji

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

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

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

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.

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.

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

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

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

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.

Oznaczenia liczności w UML

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

http://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).

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

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ł 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 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].

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.