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.

A

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

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

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

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

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

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

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

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

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

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

http://www.activex.org/

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

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

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

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

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

http://www.omg.org

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

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

agent (agent) Patrz: aktywny agent.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

update Pracownik

set Zarobek = Zarobek+100

where Nazwisko = ‘Nowak’;

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

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

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

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

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

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

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

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

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

algebra obiektowa (object algebra) Z założenia, matematyczna podstawa semantyki obiektowych języków zapytań wzorująca się na algebrze relacji. Obiektowa algebra wprowadza operatory takie jak: złączenie, selekcja, projekcja, grupowanie, zagnieżdżanie (nesting), rozgnieżdżanie (unnesting) i inne. W odróżnieniu od algebry relacyjnej operatory te działają na zbiorach obiektów i zwracają zbiory obiektów. Powodem prac nad obiektowymi algebrami jest potrzeba takiego sformalizowania modelu obiektowego i semantyki języków zapytań, aby można było przeprowadzać dowody poprawności technik optymalizacji zapytań. Niestety, cel ten nie został jak dotąd osiągnięty. Z reguły, algebry te są niespójne koncepcyjnie, dość skomplikowane, niedostatecznie uniwersalne i mające luźne związki z rygorystyczną matematyką (przez co jakikolwiek „dowód” jest niewiarygodny). Obiektowe algebry są w gruncie rzeczy słabo sformalizowanymi językami (udekorowanymi symbolami i pojęciami matematycznymi), uważanymi przez ich autorów (bezpodstawnie) za dobrze przystosowane do wewnętrznego przetwarzania zapytań w obiektowej bazie danych, zgodnie z odwzorowaniami: 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.

B

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

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.

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

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

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

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

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

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

D

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

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

F

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

G

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 230, czyli 1 073 741 824 bajtów.

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

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

H

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.

I

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, {l1(w), l2(w), l3(w), ...}>, gdzie w jest wartością danego atrybutu, zaś {l1(w), l2(w), l3(w), ...} jest zbiorem lokacji krotek (obiektów) posiadających dla danego atrybutu wartość w (zwykle lokacje są ustalane przez identyfikatory krotek (TID) lub obiektów (OID)). Indeks pomocniczy jest organizowany wg techniki umożliwiającej bardzo efektywne wyszukiwanie, np. w postaci tablicy z kodowaniem mieszającym (hash table) lub B-drzewa.

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

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

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

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.

J

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

K

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.

L

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

M

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.

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

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

mediator (mediator) Moduł oprogramowania, którego celem jest rozstrzygnięcie niezgodności w organizacji danych i sposobach/językach dostępu przy łączeniu heterogenicznych baz danych w jedną całość. Zadaniem mediatora jest uproszczenie, wyabstrahowanie, zredukowanie, scalenie, ujednolicenie i wyjaśnienie semantyki danych widzianych w systemie heterogenicznym oraz odpowiednia konwersja funkcji działających na danych, z zachowaniem spójności wszystkich operacji wyszukiwania i aktualizacji. Mediator dokonuje konwersji tych operacji z postaci obowiązującej w danym systemie na operacje w innym systemie, oraz odpowiednio dokonuje konwersji wyników tych operacji uzyskanych w innym systemie na wyniki odpowiednie dla danego systemu. Zasady konstrukcji mediatorów nie są do końca jasne; ich autorzy powołują się np. na metody sztucznej inteligencji (nie precyzując na czym one polegają). Wydaje się, że w większości nietrywialnych przypadków mediator musi być pisany techniką odwołującą się do pojęć dość niskiego poziomu. Pojęciami bardzo zbliżonymi do mediatora są: osłona (wrapper) i perspektywa (view); stosunek znaczeń tych trzech pojęć nie jest jasny i zmienia się w zależności od autora.

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

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

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

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

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

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

metoda [1] (method) Procedura, funkcja lub operacja przypisana do klasy obiektów i dziedziczona przez jej podklasy. Metoda jest abstrakcją programistyczną tej samej kategorii co procedura lub procedura funkcyjna. Metoda różni się od procedury tym, że działa w środowisku obiektu (wykorzystując jego wewnętrzne informacje, przede wszystkim wartości atrybutów) po wysłaniu do niego komunikatu zawierającego jej nazwę. Zakłada się, że (podobnie do wołania procedury) komunikat składa się z nazwy metody oraz parametrów. Z koncepcyjnego punktu widzenia miejscem przechowywania metody jest odpowiednia klasa; oznacza to, że taka metoda może być zastosowana do dowolnego obiektu będącego (bezpośrednim lub pośrednim) wystąpieniem tej klasy. Można również rozważać metody przechowywane wewnątrz samych obiektów i wywoływane na podobnych zasadach. Zwykle pojęciu metody przypisuje się niezbyt duży stopień skomplikowania („mała procedura”), nie angażowanie zbyt dużych zasobów z zewnątrz klasy oraz brak efektów ubocznych na środowisku spoza wnętrza obiektu. Nie są to jednak formalne ograniczenia, lecz raczej zalecenia dla programistów, które z różnych względów nie zawsze muszą i nie zawsze mogą być przestrzegane.

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

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

Specyfikacja metod/operacji abstrakcyjnych i ich implementacji

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

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

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

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

metoda wystąpienia (instance method) Metoda działająca na pojedynczym obiekcie danej klasy; metoda uruchamiana poprzez wysłanie komunikatu do obiektu.

metoda zwrotna (callback method) Określenie metody m w obiekcie A w sytuacji, kiedy obiekt A po wysłaniu pewnego komunikatu do obiektu B wymaga, aby po zaistnieniu pewnego zdarzenia obiekt B skierował komunikat do obiektu A wywołujący metodę m.

metodologia (methodology) Patrz: metodyka.

metodyka (methodology) Zestaw pojęć, notacji, modeli formalnych, języków i sposobów postępowania służący do analizy rzeczywistości (stanowiącej przedmiot projektowanego systemu informatycznego), oraz do projektowania pojęciowego, logicznego i/lub fizycznego. Zwykle metodyka jest powiązana z odpowiednią notacją (diagramami) służącymi do zapisywania wyniku poszczególnych faz projektu, jako środek wspomagający ludzką pamięć i wyobraźnię, oraz jako środek komunikacji w zespołach oraz pomiędzy projektantami i klientem. Metodyka ustala następujące elementy procesu wytwarzania oprogramowania:

  • Fazy projektu (np. podział na: fazę strategiczną, formułowanie wymagań, analizę, projektowanie, konstrukcję, testowanie, wdrażanie, pielęgnację).
  • Modele tworzone w każdej z faz.
  • Scenariusze postępowania w każdej z faz.
  • Reguły przechodzenia od fazy do następnej fazy.
  • Notacje, których należy używać podczas tworzenia dokumentacji.
  • Dokumentację powstającą w każdej z faz.

Metodyka dyscyplinuje przebieg procesu analizy i projektowania, pozwalając na w miarę obiektywne rozliczenie (czasowe, finansowe) jego uczestników. Wadą wszystkich proponowanych metodyk jest ich arbitralność, brak głębszego uzasadnienia dla proponowanych modeli, notacji, technik i faz postępowania, oraz idealizacja sytuacji projektowych, które dość często nie pasują do uwarunkowań danego projektu. Nawet najlepsze metodyki i narzędzia CASE nie są w stanie zapewnić wysokiej jakości projektów. Kluczem do dobrego projektu jest zespół doświadczonych, zaangażowanych i kompetentnych osób, dla których metodyka oraz narzędzie CASE mogą służyć jako istotne, lecz drugorzędne wspomaganie.

http://www_trese.cs.utwente.nl/Docs/Methodologies/methodologies.html

metodyka obiektowa (object-oriented methodology) Metodyka wykorzystująca pojęcia obiektowości dla celów modelowania pojęciowego oraz analizy i projektowania systemów informatycznych. Podstawowym składnikiem tych metodyk jest diagram obiektów, będący zwykle wariantem notacyjnym i pewnym rozszerzeniem diagramów encja-związek. Diagram obiektów zawiera takie elementy jak: klasy, w ramach klas specyfikacje atrybutów i metod, strukturę dziedziczenia pomiędzy klasami, związki asocjacji i agregacji, liczności tych związków, różnorodne ograniczenia oraz inne oznaczenia. Uzupełnieniem tego diagramu są inne, np. diagramy dynamiczne uwzględniające stany poszczególnych procesów przetwarzania i przejścia pomiędzy tymi stanami, diagramy zależności pomiędzy wywołaniami metod (np. diagram tropów komunikatów), diagramy fukcjonalne (będące zwykle pewną mutacją diagramów przepływu danych). Ostatnio popularność zdobyła także koncepcja przypadków użycia (use cases), której podstawowym celem i walorem jest odwzorowanie struktury systemu z punktu widzenia jego użytkownika. Istnieje bardzo wiele metodyk lub notacji obiektowych, w szczególności: BON, Catalysis, DOOS(Wirfs/Brock), EROOS, Express, Fusion, Goldberg/Rubin, MainstreamObjects, Martin/Odell, MOSES, Objectory(Jacobson), OMT(Rumbaugh), OOA/OOD(Coad/Yourdon), OODA(Booch), OSA, Sintropy, OOSA(Shlaer/Mellor), UML i inne. Ostatnio na czoło wybija się notacja UML autorstwa znanych metodologów: I.Jacobson, J.Rumbaugh i G.Booch.

http://www.toa.com/pub/html/mcr.lhtml

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

http://www.objenv.com/cetus/oo_ooa_ood_methods.html

http://www_trese.cs.utwente.nl/Docs/Methodologies/methodologies.html

http://www.iconcomp.com/papers/comp/comp_1.html

metryka (metric) Stosowana w inżynierii oprogramowania charakterystyka liczbowa, pozwalająca na ilościową ocenę produktów programistycznych (projektów, kodu źródłowego, zestawu testów, itd.), procesów wytwarzania oprogramowania (aktywności analizy, przebiegu projektowania, przebiegu programowania, itd.), oraz ludzi uczestniczących w tworzeniu oprogramowania (efektywność osób testujących, efektywność programistów, wydajność projektanta, itd.). W literaturze przedmiotu występuje ogromna liczba metryk (autorzy: McCabe, Halstead, Elshoff, Ejiogue, McClure), wśród nich metryki uwzględniające lub szacujące m.in. następujące aspekty:

  • wrażliwość na błędy,
  • możliwości testowania,
  • częstotliwość występowania awarii,
  • dostępność systemu,
  • propagacja błędów,
  • ilość linii kodu, złożoność kodu, złożoność programu,
  • punkty funkcyjne,
  • złożoność obliczeniową, funkcjonalną, modułową,
  • łatwość implementacji,
  • rozmiar dokumentacji,
  • ilość zadań wykonanych terminowo i po terminie,
  • współzależność zadań,
  • wielkość i koszt projektu,
  • czas trwania projektu,
  • zagrożenia projektu (ryzyko),
  • czas gotowości produktu,
  • kompletność wymagań, kompletność planowania,
  • stabilność wymagań,
  • odpowiedniość posiadanych zasobów sprzętowych, materiałowych i ludzkich,
  • efektywność zespołu, efektywność poszczególnych osób.

Metryki są tworzone na podstawie spekulacji, symulacji, doświadczenia, zdrowego rozsądku, w związku z czym są do pewnego stopnia arbitralne, nie wsparte istotną teorią lub naukową weryfikacją. Pomimo tego, metryki mają ogromne znaczenie w świecie biznesu, gdyż jest praktycznie niemożliwe planowanie i zarządzanie procesami produkcji oprogramowania bez wprowadzenia dobrze zdefiniowanych metryk. Wydaje się jednak, że obecnie metryk jest za dużo, zaś większość z nich jest mało wartościowa z powodu potencjalnie bardzo dużego błędu w oszacowaniu niektórych wartości niezbędnych do ich obliczenia (pobieranie ich „z sufitu”). W literaturze przedmiotu zwraca się uwagę na to, że metryki - jakkolwiek niezbędne - mogą wyrządzić szkodę z powodu sprowadzenia ocen do małej liczby wymiarów i z powodu sprzężenia zwrotnego polegającego na tym, że styl, forma i rezultat pracy analityków, projektantów programistów, itd. może ulec niekorzystnej deformacji z powodu formalistycznego stosowania metryk przy ocenie ich pracy. Zaleca się jednoczesne korzystanie z wielu metryk i, oczywiście, zdrowy rozsadek. Patrz też: metryka obiektowa.

http://www.mccabe.com

metryka obiektowa (object-oriented metric, object-oriented measurement) Charakterystyka liczbowa pozwalająca na ilościową ocenę produktów obiektowych (projektów, kodu źródłowego, zestawu testów, itd.), procesów wytwarzania oprogramowania (aktywności analizy, przebiegu projektowania, przebiegu programowania, itd.), oraz ludzi uczestniczących w tworzeniu oprogramowania (efektywność osób testujących, efektywność programistów, wydajność projektanta, itd.). Metryki obiektowe są szczególnym przypadkiem metryk stosowanych w inżynierii oprogramowania. Wśród nich można wymienić następujące: średnia liczba wystąpień obiektów przypadająca na klasę, liczba klas parametryzowanych, liczba i złożoność metod przypadających na klasę, głębokość drzewa dziedziczenia, średnia liczba specjalizacji dla klas abstrakcyjnych, liczba charakteryzująca gęstość powiązań pomiędzy klasami, średnia długość metody (w liniach kodu), średni czas tworzenia klasy, miara charakteryzująca kohezję klasy i inne. Przykładami najczęściej stosowanych metryk obiektowych są (wg Shyama Chidambera i Chrisa Kemerera):

  • DIT - głębokość drzewa dziedziczenia obiektów,
  • NOC - liczba potomków w ramach dziedziczenia dla konkretnej klasy,
  • CPO - liczba obiektów, dla których analizowany obiekt jest łącznikiem do innych obiektów,
  • RFC - liczność zbioru metod (lokalnych i z innych obiektów) wywoływanych przez metody obiektu,
  • LCOM - liczba metod nie wykorzystywanych przez inne metody,
  • WMC - rozmiar metod w konkretnych klasach: zarówno liczba metod, jak i ich złożoność (liczona na przykład tradycyjnymi metodami dla programów nieobiektowych).

McCabe podaje następujące metryki dla programów obiektowych:

  • Dla hermetyzacji:

PCTPUB - procent danych publicznych. Jest liczony jako stosunek danych publicznych względem danych prywatnych w obiektach,

PUBDATA - dostępność danych publicznych. Określany miarą liczby dostępów do danych publicznych.

  • Dla polimorfizmu:

PCTCALL - stosunek liczby nieprzeciążonych wywołań metod do wszystkich wywołań,

ROOTCNT - globalna liczba korzeni w hierarchii dziedziczenia klas,

FANIN - liczba klas, z których wywodzi się analizowana klasa.

  • Dla projektu programu obiektowego:

MAXV - maksymalna wartość złożoności (tzw. cyklomatycznej) dla metod,

MAXEV - maksymalna wartość złożoności struktury kodu dla metod,

QUAL - liczba klas uzależnionych od poprawnego funkcjonowania swoich przodków.

http://www.sbu.ac.uk/~csse/publications/OOMetrics.html

http://www.comsoft.southern.edu/

http://www.mccabe.com

http://WWW.rbsc.com/pages/ootbib.html

Meyer, Bertrand Twórca języka Eiffel, metodolog oprogramowania, w szczególności autor metody projektowania poprzez kontrakty (design by contracts), krytyk języków C++ i Java. Postać barwna. Określany przez konkurencję jako „fake scientist” (udawany naukowiec) po tym, jak język Java nazwał „drugą pomyłką ludzkości”. Pierwszą pomyłką był C++, określany przez niego jako „centaur”, z obiektową głową i tułowiem przypominającym assembler.

http://www.eiffel.com

miara (metric) Patrz: metryka.

miara obiektowa (object-oriented measurement) Patrz: metryka obiektowa.

mieszanie (hash) Kodowanie mieszające; metoda fizycznej organizacji zbiorów informacji. Patrz: funkcja mieszająca.

migracja obiektów (object migration) Zwykle termin ten oznacza sytuację, kiedy obiekt zmienia klasę (staje się wystąpieniem innej klasy). W innym znaczeniu termin ten oznacza przesyłanie obiektów w sieci lub pomiędzy różnymi aplikacjami.

MIS (Management Information System) System informatyczny przeznaczony do wspomagania zarządzania.

mobilne programowanie (mobile programming) Programowanie mobilnych agentów; programowanie, którego wynikiem jest mobilny kod.

mobilny agent (mobile agent) Aktywny obiekt przemieszczający się w sieci komputerowej i wykonujący w odległym miejscu usługę na rzecz wysyłającego go klienta. Podstawowa różnica pomiędzy apletem (serwletem) i aktywnym agentem polega na tym, że aktywny agent posiada swój własny stan oraz może ominąć (do pewnego stopnia) bariery bezpieczeństwa i korzystać z zasobów (danych) w miejscu, w którym aktualnie przebywa.

http://www.objenv.com/cetus/oo_mobile_agents.html

http://www.insead.fr/CALT/Encyclopedia/ComputerSciences/Agents/

mobilny kod (mobile code) Kod programu, który można transmitować poprzez sieć i wykonywać w miejscu docelowym. Głównym celem programowania z mobilnym kodem (mobile programming) jest dostarczenie bezpiecznych i rozszerzalnych środków do programowania interakcyjnych aplikacji w sieciach Internet oraz Intranet. Przykładami języków generujących mobilny kod (mobile languages) są: Java, Safe-TCL, Python, Phantom, Scheme48, Guile i Obliq.

moc (power, robustness) Termin oznaczający skalę możliwości funkcjonalnych danego języka, aplikacji, interfejsu lub systemu. Niekiedy termin ten oznacza także uwolnienie pewnego produktu programistycznego od błędów lub możliwość poprawnego funkcjonowania w nienormalnej lub wyjątkowej sytuacji.

moc Turinga (Turing power) Patrz: kompletność obliczeniowa.

mocna kontrola typów (strong type checking, strong typing) Przypisywanie (automatyczne lub nie) typów wszystkim bytom występującym w programie (zmiennym, obiektom, funkcjom, procedurom, metodom, itd.), oraz konsekwentne sprawdzanie zgodności użycia danego bytu w programie z jego zadeklarowanym typem. Zwykle mocna kontrola typów oznacza kontrolę statyczną (podczas kompilacji).

mocny klient (fat client) W architekturze klient-serwer określenie klienta o rozbudowanych funkcjach, który rzadko odwołuje się do usług świadczonych przez serwer. Przeciwieństwem jest chudy (cienki) klient (thin client).

model CRC (CRC model) Kolekcja kart CRC opisująca klasy tworzące system lub pewien jego fragment.

model cyklu życiowego (life-cycle model) Model określający fazy tworzenia oprogramowania, np. model piłki baseballowej, model kaskadowy, model spiralny, itd.

model danych (data model) Pojęcie niezbyt jednoznaczne, którego znaczenie jest wypadkową następujących cech:

  • metajęzyk (pojęcia, terminologia) do mówienia o danych, o systemach baz danych i o przetwarzaniu danych;
  • sposób rozumienia organizacji danych i ideologiczne lub techniczne ograniczenia w zakresie konstrukcji, organizacji i dostępu do danych;
  • języki opisu i przetwarzania danych, w szczególności: diagramy struktur danych, języki opisu danych i języki zapytań;
  • ogólne założenia dotyczące architektury i języków systemu bazy danych;
  • ograniczenia, ideologie lub teorie (matematyczne) dotyczące struktur danych i dostępu do danych.

Niektóre definicje (podawane przez osoby o preferencjach teoretycznych) określają model danych jako zestaw matematycznych pojęć i definicji dotyczący danych i przetwarzania danych. Takie rozumienie modelu danych spełniają tylko bardzo naiwne (nie implementowane) wersje modelu relacyjnego i jego mutacji (np. modele dedukcyjne). Istnieje wiele modeli danych (np. hierarchiczny, sieciowy, relacyjny, binarnych relacji, obiektowy, funkcjonalny, zagnieżdżonych relacji, encja-związek, dedukcyjny, dedukcyjno-obiektowy, relacyjno-obiektowy, itd.), lecz najczęściej posiadają one luźne ramy formalne oraz mgliste założenia i granice. Przykładowo, model hierarchiczny utożsamia się wyłącznie z drzewiastą strukturą danych (bez dalszych konkretnych założeń dotyczących np. technik dostępu), albo określa się go poprzez egzemplifikację (system IMS firmy IBM). Nie istnieje powszechnie przyjęty i dostatecznie precyzyjny obiektowy model danych. Próbami (niedoskonałymi) stworzenia takiego modelu są prace komitetów OMG i ODMG. Patrz też: model relacyjny, model sieciowy, model funkcjonalny, model obiektowy, model hierarchiczny, model obiektowy ODMG, model encja-związek

model dynamiczny (dynamic model) Model (zwykle w postaci diagramu) odwzorowywujący zdarzenia, stany, czynności i procesy; patrz: diagram stanów.

model encja-związek (entity-relationship model, ERM) Model danych zaliczany do modeli pojęciowych (conceptual data model), zaproponowany przez P. Chena. Podstawowym celem modelu encja-związek jest koncepcyjne odwzorowanie istniejącego, potencjalnego lub wyobrażanego fragmentu świata rzeczywistego modelowanego przez system z bazą danych. Model encja-związek znalazł zastosowanie przy projektowaniu baz danych, m.in. relacyjnych. Jego odmiana jest też często podstawowym składnikiem modeli lub metodyk obiektowych, np. OMT. Jest on także często podstawą systemów CASE. Zasadniczą zaletą modelu jest język wizualnych diagramów (entity-relationship diagrams, ERD) pozwalający poglądowo odwzorować obiekty modelowanej rzeczywistości oraz powiązania pomiędzy nimi w postaci grafu. Model encja-związek wprowadza m.in. następujące pojęcia (w różnych konwencjach graficznych dla ich zapisu):

  • encja (entity) - nazwana grupa obiektów o podobnych własnościach, którą można i warto wyróżnić w modelowanej rzeczywistości, np. Pracownik, Dział, Kierownik, Pomieszczenie;
  • związek (relationship) - nazwana grupa powiązań pomiędzy encjami, np. PracujeW (pomiędzy Pracownik i Dział), Kieruje (pomiędzy Dział i Kierownik), oraz MieściSięW (pomiędzy Dział i Pomieszczenie);
  • atrybut (attribute) - cecha charakteryzująca encję lub związek, np. NrPracownika, Nazwisko, Zarobek. Atrybut może być opcyjny (NazwiskoPanieńskie), powtarzalny (ZawódWyuczony) i/lub złożony, składający się z podatrybutów (Adres);
  • generalizacja/specjalizacja (generalization/specialization) - zawieranie się grup obiektów, np. Pracownik jest bardziej generalną encją niż Kierownik. Encja będąca specjalizacją innej encji dziedziczy atrybuty i powiązania z encji bardziej ogólnych, ale może posiadać też własne atrybuty i uczestniczyć we własnych związkach;
  • liczności (cardinalities) - dla danej encji A, określenie minimalnej i maksymalnej liczby obiektów innej encji B, która może być powiązana z jednym obiektem encji A w ramach określonego związku. Dla przykładu, związek MieściSięW od strony encji Dział będzie charakteryzowany przez liczby kardynalne [min = 1, max = n] (gdzie n oznacza „dużo”), zaś od strony Pomieszczenie przez liczby kardynalne [min = 0, max = 1].

Patrz też: diagram encja-zwiazek.

model funkcjonalny [1] (functional model) Zwykle chodzi o model oparty na przepływie danych; patrz: diagram przepływu danych.

model funkcjonalny [2] (functional model) Model danych, w którym struktury danych są modelowane jako matematyczne funkcje. Np. stosunek pomiędzy obiektami Pracownik i atrybutem Zarobek modeluje się jako funkcję

Zarobek: Pracownik ® integer

zaś związek (asocjacja) PracujeW pomiędzy obiektami Pracownik i obiektami Firma modeluje się jako funkcję

PracujeW: Pracownik ® Firma

Przykładem modelu funkcjonalnego jest Daplex. Niektórzy autorzy używają modelu funkcjonalnego do modelowania obiektowych baz danych. Istnieją również próby powiązania tego paradygmatu z funkcjonalnymi językami programowania i rachunkiem lambda. Wydaje się jednak, że są to próby dość pochopnej i płytkiej formalizacji. Wadą modeli funkcjonalnych jest słabe uwzględnienie pojęcia stanu i operacji aktualizacyjnych oraz zbytnie uproszczenie koncepcji języków zapytań.

model funkcyjny (functional model) Patrz: model funkcjonalny [1] i model funkcjonalny [2].

model hierarchiczny (hierarchical model) Ogólnie: model danych, w którym dopuszczalnymi strukturami danych są hierarchie (drzewa). Np. na czubku hierarchii są zapisy Dział, poniżej zapisy Pracownik i Klient, poniżej zapisu Klient zapisy Zamówienie, poniżej zapisów Zamówienie zapisy PozycjaZamówienia. Model hierarchiczny był pierwszym modelem danych i wiąże się go prawie wyłącznie z systemem IMS firmy IBM. Językiem manipulacji danymi w tym systemie jest język DL/1, oparty o koncepcję nawigowania od zapisów znajdujących się w górze hierarchii do zapisów podrzędnych. Dla modelowania koncepcyjnego model hierarchiczny posiada zasadnicze wady, w szczególności utrudnia reprezentowanie związków semantycznych wiele-do-wielu, oraz zmusza do często sztucznego i zbędnego nawigowania poprzez zapisy pośrednie.

model kaskadowy (waterfall model) Model cyklu rozwoju oprogramowania, w którym zakłada się, że zakończenie poprzedniej fazy jest warunkiem rozpoczęcia następnej fazy. Zaletą modelu kaskadowego jest łatwość rozliczania i zarządzania projektem. Jego wadą jest duży wpływ błędów popełnionych we wczesnych fazach na końcowy rezultat projektu, oraz brak możliwości wykorzystania w projekcie uwag i opinii jego przyszłych użytkowników. Model kaskadowy ilustruje poniższy przykład.

Przykład modelu kaskadowego

model mentalny (mental model) Model problemu budowany w umyśle człowieka (analityka, projektanta), wyznaczający rozumienie i konceptualizację problemu.

model obiektowy (object model, object-oriented model) Model danych, którego podstawą są pojęcia obiektu, klasy, dziedziczenia, polimorfizmu oraz innych cech obiektowości. Dość często model obiektowy jest rozumiany jako wariant modelu encja-związek, gdzie istotnym uzupełnieniem jest przypisanie metod do encji (klas obiektów).

model obiektowy dla komponentów (COM, Component Object Model) Patrz: COM.

model obiektowy ODMG (ODMG object model) Model obiektowy zaproponowany przez grupę standardyzacyjną ODMG, stanowiący rozszerzenie modelu OMG. Model ODMG wprowadza pojęcia obiektu i literału (stałej lub wartości) o dowolnej strukturze hierarchicznej, identyfikatora obiektu, typów obiektów i interfejsów do obiektów powiązanych w graf dziedziczenia, kolekcje, binarne powiązania asocjacyjne pomiędzy obiektami, hermetyzację, mocną kontrolę typów, wyjątki, transakcje i inne cechy.

model obiektów (object model) Zwykle chodzi o diagram przedstawiający obiekty, ich klasy i powiązania pomiędzy nimi.

model piłki baseballowej (baseball model) Sugerowany przez P. Coada model rozwoju systemu zakładający iteracje i współbieżny rozwój. Graficzna reprezentacja modelu zawiera trzy węzły: obiektowa analiza, obiektowe projektowanie i obiektowe programowanie, oraz krawędzie łączące te węzły; przypomina ona piłkę baseballową; patrz rysunek poniżej.

Model piłki baseballowej

model pojęciowy (conceptual model) Model procesów lub model struktury danych odwołujący się do ludzkiej percepcji i wyobraźni, mający za zadanie zrozumienie problemu, udokumentowanie wyniku analizy lub projektu w czytelnej i abstrakcyjnej formie językowej, oraz ułatwienie komunikacji w zespołach ludzkich.

model postrelacyjny (post-relational model) Zwykle chodzi o model rozszerzający model relacyjny lub o pewną wersję modelu obiektowego.

model przepływu danych (data flow model) Model oparty na diagramach przepływu danych; patrz: diagram przepływu danych.

model przypadków użycia (use case model) Diagram dokumentujący zachowanie się systemu jako zestawu przypadków użycia, aktorów zewnętrznych oraz powiązań pomiędzy tymi elementami.

model relacyjny (relational model) Ideologia informatyczna dotycząca organizacji baz danych oparta o pojęcia matematyczne, w szczególności pojęcie relacji, zaproponowana przez E.F.Codda z IBM w 1970 r. Jej podstawowe doktryny można streścić następująco:

  • Struktury danych w bazie danych są relacjami w sensie matematycznym, w których elementy krotek są atomowe (niepodzielne); jest to tzw. pierwsza forma normalna;
  • Użytkownik lub programista aplikacyjny nie będzie musiał i nie będzie miał możliwości zajmowania się szczegółami reprezentacji danych;
  • Przetwarzanie danych odbywa się w językach bardzo wysokiego poziomu, posiadających matematyczne konotacje. Podstawą jest algebra relacji z operacjami takimi jak selekcja, projekcja i złączenie, oraz rachunek relacyjny, będący odmianą rachunku predykatów;
  • Relacje w bazie danych będą wolne od anomalii aktualizacyjnych związanych z zależnościami funkcyjnymi (i innymi).

Retrospektywnie, Codd streścił powyższe założenia w słynnych 12 regułach „prawdziwego” systemu relacyjnego. Uważa się powszechnie, że model relacyjny był istotnym postępem w dziedzinie baz danych. Systemy relacyjne zdominowały współczesny rynek baz danych, uzyskując zarówno sukces finansowy, jak i ogromny autorytet w środowiskach klientów baz danych. Jak w każdym sporze ideologicznym, nie brak również głosów krytycznych: niektórzy specjaliści uważają, że model relacyjny był ślepą uliczką w ewolucji modelu sieciowego do obecnych modeli obiektowych. Są głosy (H.Baker), że model relacyjny opóźnił rozwój przemysłu baz danych o 10 lat. Wady modelu relacyjnego spowodowały obecny zwrot w kierunku obiektowości w bazach danych. Pomimo relacyjnego rodowodu, obecne systemy określane jako „relacyjne” w minimalnym stopniu stosują się do ideologicznej ortodoksji tego modelu („12-tu reguł”); w szczególności, wprowadzają do swoich interfejsów wiele cech obiektowych, zaś wspomagane przez nie struktury danych (tablice) i języki (SQL) posiadają bardzo luźne związki z ich matematycznymi prawzorami. Systemy określane jako postrelacyjne (post-relational) lub obiektowo-relacyjne posiadają cechy na tyle odbiegające od prawzoru bazującego na pojęciu matematycznej relacji, że można kwestionować jakikolwiek sens używania w stosunku do nich określenia „relacyjne”.

model semantyczny (semantic model) Zestaw pojęć, technik i notacji mający na celu odwzorowanie semantyki danych, czyli ich znaczenia w świecie zewnętrznym. Modele semantyczne wprowadzają w tym celu pojęcia, takie jak: generalizacja, specjalizacja, asocjacja, agregacja, klasyfikacja, własności temporalne, zdarzenia, własności behawioralne, itd. Przykładem prostego modelu semantycznego jest model encja-związek. Niekiedy terminem „model semantyczny” określa się również konkretny diagram (lub inną formę językowo-graficzną) odwzorowujący rzeczywistość opisywaną przez dane.

model sieciowy (network model) Model danych, w którym związki asocjacyjne pomiędzy danymi są reprezentowane poprzez powiązania wskaźnikowe. Struktura danych tworzy więc graf, czyli sieć. Najczęściej model sieciowy utożsamia się z propozycją grupy DBTG (Data Base Task Group) komitetu CODASYL, opublikowaną w 1971 r. i potem kilkakrotnie modyfikowaną. Model sieciowy stanowił istotny postęp w stosunku do modelu hierarchicznego zrealizowanego w IBM-owskim systemie IMS. Raport DBTG CODASYL specyfikuje dwa języki: DDL (Data Description Language - język opisu danych) oraz DML (Data Manipulation Language - język manipulacji danymi). Pomysł języka DDL ma swój rodowód w diagramach Bachmana - narzędziu do projektowania baz danych. DML jest uważany za język źle zaprojektowany. Jego podstawową wadą jest obniżenie poziomu programowania do drugorzędnych szczegółów organizacji danych, oraz oparcie jego koncepcji o tzw. wskaźniki bieżące (currency indicators), i w konsekwencji zwiększenie uciążliwości programowania i niską niezależność danych i programów. Wady modelu sieciowego przyczyniły się do rozwoju modelu relacyjnego, który jednak nie spełnił pokładanych w nim nadziei. W ostatnich latach nastąpił renesans koncepcji modelu sieciowego w postaci modelu obiektowego oraz obiektowych SZBD. Niektórzy autorzy uważają model sieciowy za jednego z przodków obiektowości w dziedzinie baz danych.

model spiralny (spiral model) Model cyklu życiowego oprogramowania (zaproponowany przez B.Boehma), zakładający powtórzenie cyklu tworzenia systemu po uzyskaniu informacji z poprzedniego cyklu. Poniżej znajduje się przykład modelu spiralnego. Istnieje wiele odmian tego modelu, z różnym ustawieniem faz podlegających powtórzeniom.

Przykład modelu spiralnego

model wodospadowy (waterfall model) Patrz: model kaskadowy.

modelowanie CRC (CRC modeling) Proces tworzenia modelu CRC. Patrz: karta CRC.

modelowanie obiektowe (object-oriented modeling) Budowa modeli odwzorowujących modelowaną rzeczywistość na strukturę (diagram) opisującą obiekty, ich klasy, ich wzajemne powiązania oraz ich zachowanie się i interakcję.

modelowanie pojęciowe (conceptual modeling) Tworzenie modeli pojęciowych. Patrz: model pojęciowy.

modelowanie procesów biznesowych (Business Process Modeling, BPM) Tworzenie modeli opisujących daną dziedzinę przedmiotową.

model-perspektywa-sterownik (Model-View-Controller, MVC) Patrz: MVC.

Modula-3 Obiektowy język programowania, następca Modula-2 i Cedar. Modula-3 została zaprojektowana z myślą o prostocie i bezpieczeństwie. Wprowadza obiekty, generalia (generics), wątki, wyjątki i zbieranie nieużytków. Moduły mogą być deklarowane jako „bezpieczne” i „niebezpieczne” (w zależności od wymaganej kontroli typów). Nie posiada wielodziedziczenia i przeciążania operatorów. Jest oparta na strukturalnej zgodności typów.

http://www.research.digital.com/SRC/modula-3/html/home.html

http://www.vlsi.polymtl.ca/m3/

http://www.cmass.com/threads/

modularność (modularity) Możliwość dekomponowania programu lub systemu na części o dobrze określonych granicach oraz o dobrze wyspecyfikowanym interfejsie pomiędzy poszczególnymi częściami.

modularyzacja (modularization) Podział struktury danych lub struktury programu na mniejsze fragmenty o dobrze zdefiniowanych granicach i interfejsie (np. na obiekty lub moduły), którymi można operować w programie tak, jak zamkniętymi jednostkami.

moduł (module) Termin używany w kilku zbliżonych znaczeniach. W modularnych językach programowania, takich jak Modula-2, moduł oznacza fragment programu stanowiący jednostkę przechowywania, kompilacji i konsolidacji (linking). Moduł podlega regułom hermetyzacji (encapsulation) oddzielającym specyfikację modułu od jego implementacji. Dzięki temu każdy moduł może posiadać własną przestrzeń nazw nie kolidującą z przestrzenią nazw innych modułów. Specyfikacja modułu zawiera tzw. listy eksportowe i importowe. Lista eksportowa określa obiekty modułu (dane, typy, procedury), które są widoczne na zewnątrz; lista importowa określa obiekty innych modułów, które można użyć w danym module. W modelach architektury systemów komputerowych moduł oznacza jednostkę strukturalną lub funkcjonalną o dobrze zdefiniowanym interfejsie lub powiązaniu z innymi modułami. W terminologii konkretnych SZBD i metodyk projektowania terminu moduł używa się dla oznaczenia fragmentu aplikacji dotyczącej konkretnej funkcji systemu, np. „moduł obsługi klienta”.

modyfikator (modifier) Funkcja lub operacja zmieniająca stan obiektu; często synonim lub semantyczny równoważnik operacji podstawienia (assignment).

monomorfizm (monomorphism) Brak polimorfizmu, czyli brak możliwości przypisania wielu typów do jednego bytu programistycznego. W językach obiektowych monomorfizm oznacza także brak możliwości dynamicznego wiązania metod. Do języków monomorficznych należy większość klasycznych języków programowania: Pascal, C, Modula-2, PL/I, Fortran, itd.

Montage Obiektowo-relacyjny SZBD, komercyjna wersja systemu Postgres.

MOOSE (Major Object-Oriented SQL Extensions) Obiektowe rozszerzenia języka SQL, wprowadzane w SQL3. Patrz: SQL3.

MOSES (Methodology for Object-oriented Software Engineering of Systems) Obiektowa metodyka analizy i projektowania systemów informatycznych opracowana w ośrodku COTAR (Centre for Object Technology Applications and Research) w Australii. MOSES jest niezależna od języka implementacyjnego, wspomaga zarządzanie projektem (włączając metryki), ponowne użycie, iteracyjny cykl życiowy oraz zadania związane z biznesem. Posiada pełną notację i jest zintegrowana z narzędziem CASE. Jest używana w wielu ośrodkach przemysłowych i akademickich. Istnieje projekt integracji metodyk MOSES, SOMA i Martin/Odell.

http://linus.socs.uts.edu.au/~cotar/moses.html

możliwość ponownego użycia (reusability) Określenie stopnia zdolności danej metodyki, języka programowania, systemu, organizacji, itd. do tworzenia i wykorzystania aktywów ponownego użycia.

mrówka (ant) Owad. Niezbyt duży, aktywny obiekt rzeczywisty. Mrówki pełnią pożyteczną rolę przy objaśnianiu różnicy pomiędzy identyfikatorem i tożsamością obiektu. Pomimo tego, że urzędy zaniedbują oznaczanie pojedynczych mrówek unikalnymi identyfikatorami i wydawanie im dowodów tożsamości - przez co są one dla nas praktycznie nieodróżnialne - każda mrówka posiada swoją własną tożsamość, istnieje niezależnie od innych mrówek, ma swoje życie, które kiedyś zaczyna się, trwa, i kiedyś się kończy. Mrówki są argumentem na rzecz tezy, że obiekty mają tożsamość, ale mogą nie posiadać unikalnego identyfikatora. Teza ta może mieć znaczenie w technologiach rozproszonych obiektów, komponentów, mobilnych agentów, federacyjnych baz danych, itd., gdzie istotne staje się pytanie: co to znaczy „unikalny identyfikator obiektu”? To wydawałoby się banalne pytanie prowadzi do niebanalnego: czy warto tworzyć Światowe Biuro Ewidencji Obiektów, które zajmowałoby się centralnym rozdzielnictwem unikalnych identyfikatorów dla wszelkich obiektów, które kiedykolwiek były, są lub będą w zasięgu globalnej sieci komputerowej?

MS Repository Produkt firmy Microsoft stanowiący realizację obiektowego systemu zarządzania bazą danych. MS Repository jest dostarczany jako komponent pakietu VisualBasic (wersja 5.0) i włącza interfejsy wg standardu ActiveX, które projektant może wykorzystać do zdefiniowania modelu informacji oraz do manipulacji danymi. MS Repository jest zbudowany na wierzchołku pakietu Microsoft SQL Server oraz Microsoft Jet i jest kompatybilny z technologią COM/ActiveX/VisualBasic (Automation). Jakkolwiek zaimplementowany na bazie relacyjnej, MS Repository jest systemem obiektowym wprowadzającym pojęcia klasy (z wieloma interfejsami do jednej klasy), metod przypisanych do klas, unikalnego identyfikatora obiektu, dziedziczenia, polimorfizmu i inne. MS Repository wtapia się gładko w rynek produktów Microsoftu, szczególnie rynek VisualBasic i technologii COM/ActiveX. MS Repository jest kolejnym etapem rozwoju technologii OLE-OLE2-COM-DCOM-OLEAutomation-OLEControls-ActiveX i wprowadzenia do niej pojęcia trwałości i niektórych pojęć obiektowości.

http://www.microsoft.com/Repository/whatsnew.htm

MTS (Microsoft Transaction Server) Serwer transakcji Microsoftu.

multimedia (multimedia) Perspektywiczna dziedzina zastosowań obiektowych baz danych, które nie ograniczają formatu struktury obiektów i mogą operować na (dużych) obiektach przechowujących dane multimedialne (wzbogacony tekst, grafika, dźwięk, wideo). Tego rodzaju dane mogą być przechowywane i przetwarzane w systemach obiektowych jak normalne atrybuty (patrz: atrybut multimedialny). Jest to istotna różnica w stosunku do systemów relacyjnych, które tego rodzaju dane przechowywują poza podstawową strukturą danych (patrz: BLOB) i traktują mało systematycznie, przez co wzrasta złożoność interfejsów programistycznych i zawodność oprogramowania aplikacyjnego.

multimedialny (multi-media) Termin odnosi się do systemu, który jest zdolny udostępniać, przechowywać lub przetwarzać informacje wizualne, takie jak grafika wektorowa (tworzona poprzez edytory graficzne), grafika bitowa (np. zdjęcia), animację, sekwencje wideo, dźwięk, oraz kombinację tych form. Zastosowania multimedialne, w szczególności udostępnianie informacji multimedialnej w formie hipertekstu (np. zrealizowanego na stronach WWW), są uważane za przyszłość informatyki. Np. interakcyjne wideo oznacza sekwencje klatek wideo,które są zapamiętane na nośnikach laserowych. Klatki/sekwencje posiadają adresy, które mogą być zapamiętane jako wartości atrybutów w bazie danych. Dzięki temu (przy zastosowaniu już dostępnych rozwiązań technicznych) można zbudować prostą aplikację, w której tekst komputerowy jest spleciony z sekwencjami wideo. Nieco trudniejsze problemy są związane ze strukturą, przetwarzaniem i udostępnianiem animacji, takiej jak np. w grach komputerowych. W związku z WWW wiele prac jest ostatnio poświęcone organizacji hipertekstu.

MVC (Model-View-Controller) Model-perspektywa-sterownik. Sposób podziału i rozumienia interakcyjnego oprogramowania. „Model” jest wewnętrznym mechanizmem realizującym zadany algorytm, „perspektywa” określa w jaki sposób stan modelu jest widziany przez użytkownika, zaś „sterownik” jest mechanizmem odwzorowującym akcje użytkownika (wejście) na zmiany stanu modelu. W węższym znaczeniu MVC oznacza zestaw klas służących do budowy interfejsów użytkownika w języku Smalltalk80 wg podanego wyżej sposobu.

http://www.holub.com/goodies/mvc/mvc_sd.out.html

N

nadawca (sender) Obiekt wysyłający komunikat.

nadklasa (superclass) Klasa bardziej ogólna, usytuowana wyżej w hierarchii dziedziczenia, np. Osoba jest nadklasą klasy Student. Pojęcie nadklasy włącza aspekt zawierania się zakresów znaczeniowych pojęć; przykładowo, zbiór obiektów klasy Osoba jest nadzbiorem zbioru obiektów klasy Student. Innym aspektem jest dziedziczenie inwariantów: nadklasa przekazuje wszystkie swoje inwarianty (definicje atrybutów, definicje metod, itd.) do jej podklas. Dość często nadklasa jest tworzona poprzez zgrupowanie inwariantów jej podklas; w takich sytuacjach nie ma ona bezpośrednich wystąpień obiektów, czyli jest klasą abstrakcyjną. W wielu sytuacjach i dyskusjach dwa różne aspekty pojęcia nadklasy (zawieranie się zakresów znaczeniowych oraz grupowanie inwariantów ) prowadzą do nieporozumień.

nadzbiór (superset) Zbiór zawierający dany zbiór. Terminu tego używa się również dla oznaczenia języka lub systemu o rozszerzonych funkcjach (np. „nadzbiór języka SQL”).

narzędzia do pracy grupowej (groupware) Oprogramowanie usprawniające przechowywanie, udostępnianie i przetwarzanie dokumentów w ramach zespołu. Popularnym narzędziem służącym do tego celu jest Lotus Notes.

naturalne złączenie (natural join) Patrz: złączenie naturalne.

nawigacja (navigation) Technika przechodzenia od obiektów do obiektów bazująca na wskaźnikach (pointers) umieszczonych wewnątrz obiektów; często wykorzystywana przez tzw. wyrażenia ścieżkowe. Nawigacja w obiektowej bazie danych jest naturalnym i efektywnym sposobem realizacji zapytań, które w analogicznej relacyjnej bazie danych wymagałyby złączenia (join). Patrz też: dostęp nawigacyjny.

nawigacyjne złączenie (navigational join) Patrz: zależne złączenie.

nazwa (name) Identyfikator nadawany dla obiektu, związku, atrybutu, asocjacji, roli asocjacji, relacji, metody, procedury, typu, modułu, itd., który pozwala odwołać się do tego bytu w programie. Zazwyczaj nazwa danego bytu posiada określone znaczenie w dziedzinie problemowej, odwołuje do naszego modelu pojęciowego i doświadczenia, nie jest wyłącznie przypadkową sekwencją znaków. Właśnie tym nazwa różni się od wewnętrznego identyfikatora danego bytu, którego budowa jest określona wyłącznie wewnętrznymi kryteriami przechowywania i reprezentacji danego bytu (np. jest to liczba naturalna) i nic nie mówi o tym, co dany byt oznacza. Nazwy bytów mogą być pierwszej i drugiej kategorii (obywatelstwa); to zróżnicowanie jest bardzo często powodem nieporozumień. Nazwy bytów należące do pierwszej kategorii istnieją podczas czasu wykonania, w związku z czym można je dynamicznie utworzyć i następnie zastosować do identyfikacji danego bytu. Nazwy drugiej kategorii istnieją wyłącznie w tekście programu; nie istnieje możliwość odwołania się do tej nazwy podczas czasu wykonania. Np. jeżeli nazwy obiektów są pierwszej kategorii, to wówczas możliwe jest napisanie procedury, która wczytuje nazwę z klawiatury i sprawdza, czy obiekt o tej nazwie jest w bazie danych. Jeżeli nazwy obiektów są drugiej kategorii, wówczas napisanie takiej procedury jest niemożliwe.

nazwa obiektu (object name) Nazwa pozwalająca zidentyfikować obiekt. Zazwyczaj nazwa ta posiada znaczenie w dziedzinie problemowej, np. Pracownik; tym nazwa obiektu różni się od identyfikatora obiektu. Inną różnicą jest to, że w obiektowych bazach danych nazwa obiektu nie musi być unikalna; np. może być wiele obiektów posiadających nazwę Pracownik.

nazwowa równoważność typów (name type equivalence) Patrz: nazwowa zgodność typów.

nazwowa zgodność typów (name type conformance) Reguła zgodności typów ustalająca, że typ T1 bytu programistycznego (np. wyrażenia) wydedukowany na podstawie reguł wnioskowania o typie (type inference rules) jest zgodny z zadeklarowanym typem T2 dla tego bytu (np. deklaracją parametru procedury), o ile nazwa przypisana do typu T1 jest identyczna tekstowo z nazwą przypisaną do typu T2. Nazwowa zgodność typów jest najprostsza w implementacji i jest wykorzystywana przez języki takie jak Pascal. Prowadzi ona jednak do trudności związanych z polimorfizmem, wobec czego często (w obiektowych językach programowania) jest zastępowana przez tzw. strukturalną zgodność typów. Patrz też: typ rozróżniony.

NEOnet Pośrednik ORB wg standardu CORBA firmy SunSoft, składnik rodziny produktów NEO dla systemu operacyjnego Solaris.

NF2, NF2 (Non-First-Normal-Form) Patrz: nieznormalizowane relacje.

nieobiekt (non-object) Coś, co nie jest obiektem. Przykładami nieobiektów są: woda, piasek, lekki zefirek, rozlana zupa, koleiny. Nieobiektowość w informatyce ciągle czeka na swojego odkrywcę, ideologa i guru.

nieproceduralny (non-procedural) Patrz: deklaracyjny.

nieprzejrzysty (opaque) Określenie typu, klasy lub modułu, którego nazwa i przeznaczenie jest znane, ale nieznana jest jego wewnętrzna budowa.

niezależność danych (data independence) Możliwość projektowania, utrzymywania, udostępniania, zmiany nośników, zmiany reprezentacji, itp. działań na danych niezależnie od programów, które na nich operują. Niezależność danych jest osiągana poprzez interfejsy umożliwiające dostęp do danych na odpowiednim poziomie abstrakcji, gdy niewidoczne są szczegóły organizacji i implementacji danych.

niezgodność impedancji (impedance mismatch) Termin wywodzący się z elektrotechniki, oznaczający niezgodność oporności źródła i odbiornika, która powoduje stratę mocy. W bazach danych oznacza on zespół niezgodności powstający w wyniku eklektycznego połączenia (zanurzenia, embedding) języka wysokiego poziomu (np. SQL) z językiem programowania (np. C, Pascal, C++, Smalltalk, Java). Niezgodności mogą dotyczyć następujących aspektów:

  • Składni. Programista musi w jednym tekście programu używać dwóch stylów językowych i przestrzegać reguł dwóch różnych gramatyk.
  • Systemu typów. Język zapytań operuje na typach zdefiniowanych w schemacie bazy danych, m.in. relacjach, natomiast język programowania posiada zwykle odmienny system typów, w którym nie występuje typ relacja.
  • Semantyki i paradygmatów języków. Język zapytań bazuje na stylu deklaracyjnym, podczas gdy języki programowania bazują na stylu imperatywnym.
  • Pragmatyki użycia. Język zapytań uwalnia programistę od wielu szczegółów organizacji i implementacji danych (np. organizacji zbiorów, obecności lub nieobecności indeksów, itd.), podczas gdy w języku programowania te szczegóły muszą być oprogramowane.
  • Faz i mechanizmów wiązania. Języki zapytań są oparte o późne wiązanie (są interpretowane), podczas gdy języki programowania zakładają wczesne wiązanie (podczas kompilacji i konsolidacji).
  • Przestrzeni nazw i reguł zakresu. Język zapytań i język programowania posiadają własne przestrzenie nazw, które mogą zawierać identyczne nazwy o różnych znaczeniach. Odwzorowanie pomiędzy przestrzeniami nazw wymaga dodatkowych środków syntaktycznych i semantycznych.
  • Traktowania wartości zerowych. Bazy danych i języki zapytań posiadają wyspecjalizowane środki dla przechowywania i przetwarzania wartości zerowych. Środki te nie występują w językach programowania.
  • Schematów iteracyjnych. W języku zapytań iteracje są wtopione w semantykę operatorów takich jak selekcja, projekcja i złączenie. W języku programowania iteracje muszą być organizowane explicite przy pomocy pętli for, while, repeat lub innych. Przetwarzanie wyników zapytań przy pomocy języka programowania wymaga specjalnych udogodnień takich jak kursory i iteratory.
  • Traktowania cechy trwałości danych. Języki zapytań przetwarzają wyłącznie trwałe dane (znajdujące się na dysku), podczas gdy języki programowania przetwarzają wyłącznie dane nietrwałe znajdujące się w pamięci operacyjnej. Połączenie obu języków wymaga od programisty użycia specjalnych środków językowych do parametryzacji zapytań przez zmienne języka programowania, oraz środków językowych i architektonicznych służących do transmisji danych z dysku do pamięci operacyjnej i odwrotnie.
  • Środków programowania ogólnego (generic). Środki te w języku zapytań są oparte o refleksję (patrz np. dynamiczny SQL). Użycie podobnego środka w języku programowania jest zazwyczaj niemożliwe z powodu wczesnego wiązania.

Skutkiem niezgodności impedancji nie są wyłącznie wady estetyczne. Niezgodność impedancji powoduje konieczność istnienia dodatkowej warstwy oprogramowania pośredniczącego pomiędzy językiem zapytań i językiem programowania. Ta warstwa obciąża dodatkowo kod aplikacji (nawet do 30% tego kodu), może być źródłem błędów, zwiększa czas uczenia się danego narzędzia, zwiększa czas wykonania, utrudnia pielęgnację, itd. Postulatem obiektowych baz danych (jak dotąd niezrealizowanym w pełni) było uniknięcie niezgodności impedancji poprzez stworzenie języków zapytań „bezszwowo” zintegrowanych z konstrukcjami proceduralnymi.

Ostatnio terminem niezgodność impedancji określa się również niezgodność paradygmatów obiektowej i relacyjnej bazy danych przy przechodzeniu ze schematu obiektowego na schemat relacyjny. Termin ten jest również stosowany dla określenia dowolnego innego łączenia niezgodnych paradygmatów projektowania, modelowania lub programowania.

niezmienialny (immutable) Obiekt lub inny byt programistyczny (np. stała), do którego nie można zastosować operacji aktualizacyjnej.

niezmienny (invariant) Określenie warunku lub własności, która jest stała dla wszystkich obiektów lub innych bytów pewnej populacji; patrz: inwariant.

nieznormalizowane relacje (non-normalized relations, embedded relations, NF2) Koncepcja modelu danych opartego o pojęcia matematyczne, w której klasyczny model relacyjny jest rozszerzony w taki sposób, aby elementem krotki relacji mogła być relacja (być może również nieznormalizowana). Pojęcie to nawiązuje do złożonych obiektów. Algebra nieznormalizowanych relacji była proponowana jako semantyczna podstawa obiektowych języków zapytań. Okazała się ona jednak zbyt uboga, nie przykrywająca ich witalnych własności i przez to mało użyteczna. Z tego powodu nieznormalizowane relacje nie odegrały w obiektowości istotnej roli, chociaż wielu autorów ciągle używa tego pojęcia jako teoretycznej dekoracji dla niektórych pomysłów związanych z obiektowością.

NIH (Not-Invented-Here) Patrz: syndrom NIH.

NIL Patrz: NULL.

normalizacja (normalization) Proces przekształcania struktur danych prowadzący do uzyskania struktur relacyjnych (tzw. pierwszej formy normalnej, 1NF). Niekiedy pod normalizacją rozumie się także uzyskanie drugiej lub trzeciej formy normalnej (3NF). Proces normalizacji obejmuje:

  • eliminację atrybutów powtarzalnych poprzez zastąpienie ich odrębnymi relacjami;
  • „spłaszczanie” struktury danych poprzez eliminację atrybutów złożonych;
  • zastąpienie związków (relationship) relacjami;
  • ustalenie pierwotnych i obcych kluczy relacji, które reprezentują związki semantyczne;
  • wyeliminowanie niepożądanych zależności (np. funkcyjnych) pomiędzy kolumnami relacji poprzez wprowadzenie nowych relacji.

Normalizacja jest podstawowym zabiegiem przy przechodzeniu ze struktury pojęciowej encja-związek (lub struktury obiektowej) do struktury relacyjnej. Struktury znormalizowane posiadają wady (rozproszenie bytów semantycznych w krotkach wielu relacji, zbyt duża ilość relacji utrudniająca modelowanie pojęciowe, i inne), co stało się powodem powstania pojęcia „denormalizacji”, mającej m.in. zastosowanie przy przechodzeniu od spadkowej (legacy) struktury relacyjnej do struktury obiektowej.

normalizacja danych (data normalization) Ogólnie, sprowadzenie danych do pewnego określonego formatu uwzględniającego ograniczenia nakładane na dopuszczalne struktury danych. Najczęściej tym terminem określa się proces sprowadzenia danych do postaci nadającej się do przechowywania w systemie relacyjnym; patrz: normalizacja.

normalizacja klas (class normalization) Proces przekształacania modelu lub diagramu obiektowego, w wyniku którego zwiększa się kohezję wewnątrz klas oraz minimalizuje się związki lub zależności pomiędzy klasami.

notacja (notation) Zestaw symboli graficznych, reguł syntaktycznych dotyczących ich użycia oraz reguł semantycznych dotyczących ich znaczenia służący do rysowania diagramów. Przykładem notacji jest UML, który ma szanse stać się przemysłowym standardem notacyjnym.

nowy (new) Określenie operatora tworzącego nowy obiekt (konstruktora).

NULL Oznaczenie braku wartości, wartości zerowej, wartości niezainicjowanej zmiennej lub wskaźnika, pustego zbioru, itd. Synonim: NIL.

O

O2, O2 Obiektowy system zarządzania bazą danych zrealizowany we Francji przez firmę O2 Technology; prekursor obiektowych baz danych i wzorzec dla standardu ODMG. (We wrześniu 1997 firma O2 Technology połączyła się z firmą UniData i następnie z Ardent Software.)

http://www.ardentsoftware.com/

http://www.o2tech.fr/

OA&D (Object Analysis and Design) Analiza i projektowanie obiektowe.

obcy klucz (foreign key) Patrz: klucz obcy.

OBD (ODB) Obiektowa Baza Danych.

Oberon-2 Obiektowe rozszerzenie języka Oberon, następcy języków Pascal i Modula-2. Posiada procedury przypisane do typów (równoważne metodom), eksport zmiennych tylko do czytania, zmienne typu „otwarta tablica" (bez ograniczenia rozmiaru) oraz zdanie „with" z wariantami.

http://www.oberon.ethz.ch

http://www.math.tau.ac.il/~laden/Oberon.html

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

obiekt (object) Obiekt jest abstrakcyjnym bytem reprezentującym lub opisującym pewną rzecz lub pojęcie obserwowane w świecie rzeczywistym. Obiekt jest odróżnialny od innych obiektów, ma nazwę i dobrze określone granice. Wielu autorów nie różnicuje pojęcia obiektu jako pewnej abstrakcji pojęciowej lub informacyjnej, struktury danych określanej jako „obiekt” przechowywanej wewnątrz komputera, oraz konkretnego obiektu (materialnego) istniejącego w świecie rzeczywistym. Jakkolwiek z metodologicznego punktu widzenia takie rozróżnienie jest konieczne, wynika ono zwykle z kontekstu. Przykładami obiektów są: pracownik Jan Kowalski, miasto Warszawa, dokument zakupu, pozycja tego dokumentu specyfikująca zakupiony towar, model samochodu, samochód Toyota o numerze rejestracyjnym WAP 9369, pogoda w dniu 13 kwietnia 1998 r., itd. Obiektem nie jest śnieg (chyba, że chodzi np. o pobrane próbki śniegu), nie jest nim kosmos, kolor zielony, zachód słońca, moje dzisiejsze myśli, itd. (patrz: nieobiekt).

Obiektem może być także pewna abstrakcja programistyczna. Mogą istnieć obiekty programistyczne nie posiadające odpowiedników w świecie rzeczywistym. Obiektem może być pewien zamknięty fragment oprogramowania (dana, procedura, moduł, dokument, okienko dialogu, i inne), którym programista może operować jak zwartą bryłą, np. wyszukiwać, kopiować, tworzyć, usuwać lub przenosić. Obiekty mogą być dowolnie złożone oraz dowolnie duże. Obiektom przypisuje się cechy takie jak tożsamość, stan i operacje. Obiekt posiada nazwę, jednoznaczną identyfikację, określone granice, atrybuty i inne własności. Obiekt może być skojarzony z metodami lub operacjami, które na nim działają; z reguły, są one definiowane/przechowywane w ramach jego klasy oraz jej nadklas.

W zasadniczej swojej intencji obiekt jest tym samym co zmienna języków programowania. Występujące różnice dotyczą rozwoju historycznego, np. w C++ występują zarówno zmienne (przejęte z C), jak i obiekty. Druga różnica polega na tym, że w większości klasycznych języków programowania nie istnieją mechanizmy pozwalające na związanie metod ze zmiennymi (czyli mechanizmy klas lub abstrakcyjnych typów danych).

obiekt aktywny (active object) Patrz: aktywny obiekt.

obiekt biznesowy (business object) Obiekt modelujący pewien istotny aspekt dziedziny przedmiotowej. Intencją terminu „obiekt biznesowy” jest określenie obiektów niezależnych od potencjalnych komputerowych aplikacji, takich jak klient, zamówienie, konkurent, pieniądze, płatność, konto, samochód, pacjent, itd. „Obiekt biznesowy” jest do pewnego stopnia pojęciem relatywnym lub subiektywnym, gdyż zależy od tego, jaką dziedzinę biznesu mamy na myśli i co pod nią rozumiemy. Próby precyzyjnej definicji tego pojęcia są raczej nieudane.

obiekt chwilowy (temporary object) Patrz: obiekt ulotny.

obiekt docelowy (target object) Obiekt będący adresatem (odbiorcą) komunikatu.

obiekt globalny (global object) Obiekt dostępny dla wszystkich bytów programistycznych; obiekt znajdujący się w powszechnie dostępnym środowisku lub zakresie.

obiekt interfejsu (interface object) Obiekt służący do opisu interfejsu oraz do komunikacji systemu z jego środowiskiem zewnętrznym. W terminologii przypadków użycia (use cases): obiekt hermetyzujący funkcje bezpośrednio zależne od zewnętrza systemu lub funkcje służące do komunikowania się z zewnętrznymi aktorami.

obiekt kompozytowy (composed object, composite object) Obiekt składający się z innych obiektów (podobiektów); obiekt złożony. Niekiedy terminem tym określa się grupę powiązanych obiektów, które podlegają jednoczesnemu usuwaniu, kopiowaniu, blokowaniu, itd. oraz stanowią podstawę tworzenia fizycznych gron (clusters).

obiekt kontenerowy (container object) Obiekt będący kolekcją obiektów.

obiekt lokalny (local object) Obiekt (zwykle ulotny), który jest dostępny wyłącznie dla pewnego lokalnego kontekstu lub środowiska, np. treści pewnej metody lub procedury.

obiekt niezmienialny (immutable object) Obiekt, którego stanu nie można zmienić. W Smalltalku niezmiennymi obiektami są np. wartości liczbowe. Synonim: literał.

obiekt pasywny (passive object) Przeciwieństwo obiektu aktywnego, obiekt nie posiadający własnej nitki sterowania. Niekiedy terminem tym określa się również obiekt posiadający atrybuty, ale nie posiadający żadnych przypisanych do niego metod lub operacji.

obiekt rzeczywisty (entity object) W terminologii przypadków użycia (use cases): obiekt, który można zidentyfikować w modelowanej rzeczywistości.

obiekt sterujący (control object) Obiekt, którego funkcją jest sterowanie; z reguły, jest to obiekt ulotny. W terminologii przypadków użycia (use cases), obiekt sterujący hermetyzuje jeden lub kilka przypadków użycia; jest to obiekt reprezentujący zestaw zadań w biznesie. Obiekt sterujący modeluje funkcjonalność, która nie może być przywiązana do jakiegokolwiek innego obiektu.

obiekt trwały (persistent object) Patrz: trwały obiekt.

obiekt ulotny (transient object, transitory object, volatile object, temporary object) Obiekt, którego istnienie ograniczone jest do pojedynczego uruchomienia programu lub pojedynczego wywołania procedury.

obiekt wirtualny (virtual object) Obiekt nie zapamiętany fizycznie, istniejący wyłącznie w postaci definicji; obiekt wyliczany w momencie dostępu; obiekt widziany poprzez pewną obiektową perspektywę (object view).

obiekt współbieżny (concurrent object) Obiekt, który posiada własną nitkę sterowania; inaczej aktywny obiekt.

obiekt zagregowany (aggregate object) Obiekt złożony z obiektów; obiekt kompozytowy.

obiekt zastępczy (proxy object, deputy object) Obiekt reprezentujący pewien obiekt zapamiętany w bazie danych. Jest on przechowywany w pamięci operacyjnej lub na nośniku trwałym. Pojęcie obiektu zastępczego ma przede wszystkim na uwadze optymalizację operacji wykonywanych na obiektach. Obiekt zastępczy posiada z reguły ograniczony zestaw informacji. Komunikat skierowany do obiektu zastępczego może spowodować zastąpienie go obiektem oryginalnym. Niekiedy tym pojęciem określa się także ograniczoną lub odpowiednio zmodyfikowaną kopię obiektu umożliwiającą bardziej sprawne przetwarzanie.

obiekt złożony (complex object, composite object) Obiekt, którego składowymi są obiekty. Z założenia, liczba poziomów hierarchii obiektów złożonych nie jest ograniczona. Może on również zawierać tzw. grupy powtarzalne lub kolekcje (np. Dzieci dla obiektów Pracownik), może być także dowolnie duży (np. zawierać dane multimedialne), oraz może dynamicznie zwiększać lub zmniejszać swoją objętość w zależności od liczby i wielkości przechowywanych wewnątrz niego podobiektów.

obiekt-korzeń (root object) Obiekt stojący najwyżej w hierarchii obiektów; nadobiekt przechowujący referencje do obiektów danej bazy danych; obiekt, od którego rozpoczyna się nawigacja w bazie danych.

obiektowa algebra (object algebra) Patrz: algebra obiektowa.

obiektowa analiza (object-oriented analysis, OOA) Metoda analizy problemu, w której wymagania są rozpatrywane w perspektywie klas i obiektów wyróżnionych w danej dziedzinie przedmiotowej. Obiektowa analiza zajmuje się identyfikacją, analizą i specyfikacją wymagań, używając pojęć takich jak: obiekty z tożsamością hermetyzujące własności i operacje, przesyłanie komunikatów, klasy, dziedziczenie, polimorfizm i dynamiczne wiązanie.

obiektowa analiza / obiektowe projektowanie (Object-Oriented Analysis / Object-Oriented Design, OOA/OOD) Patrz: OOA/OOD.

obiektowa analiza i projektowanie (Object-Oriented Analysis & Design, OOAD) Patrz: OOAD.

obiektowa baza danych (object-oriented database, object database, ODB, OODB) Baza danych zawierająca obiekty, utrzymywana i udostępniana przez obiektowy SZBD.

obiektowa notacja dla biznesu (Business Object Notation, BON) Patrz: BON.

obiektowa perspektywa (object view) Patrz: perspektywa obiektowa.

obiektowe programowanie wizyjne (object-oriented visual programming) Połączenie obiektowości z programowaniem wizyjnym. Patrz też: programowanie wizyjne.

http://cbl.leeds.ac.uk/nikos/tex2html/examples/concepts/node74.html

http://www.pictorius.com/pi/products/classic.html

http://www.pictorius.com/pi/products/cpx.html

obiektowe projektowanie (object-oriented design, OOD) Ogólne określenie metod lub metodyk projektowania, które wykorzystują pojęcia obiektowe. Booch wyróżnia cztery fazy obiektowego projektowania:

  • identyfikacja obiektów i ich klas;
  • identyfikacja semantyki obiektów;
  • identyfikacja związków pomiędzy obiektami;
  • identyfikacja interfejsów obiektów i ich implementacji.

Istnieje wiele innych scenariuszy postępowania przy obiektowym projektowaniu.

obiektowo zorientowany (object-oriented) W polskiej terminologii staramy się utrzymać konwencję, zgodnie z którą angielski termin object-oriented jest tłumaczony jako „obiektowy” (z odpowiednimi formami fleksyjnymi: „obiektowego”, „obiektowych”, itd.). Patrz: obiektowość.

obiektowo-relacyjny (object-relational) Określenie systemu bazy danych przechowującego zarówno obiekty, jak i tablice znane z systemów relacyjnych. Podstawą ideologiczną tych systemów jest manifest systemów baz danych trzeciej generacji. Motywacją dla tych systemów jest zachowanie sprawdzonych technologii relacyjnych (np. SQL) i wprowadzanie na ich wierzchołku innych własności, w tym obiektowych. W większości przypadków chodzi o ewolucyjną zmianę istniejących systemów relacyjnych posiadających swoją pozycję na rynku i grono klientów. W niektórych przypadkach systemy obiektowo-relacyjne są budowane od nowa. Kluczowymi produktami komercyjnymi tej technologii są systemy: Informix Universal/Dynamic Server (połączenie systemu Illustra, następcy systemu Postgres, i Informix OnLine), DB2 Universal Database (firmy IBM, połączenie Starburst i DB2), Oracle-8, UniSQL/X, OSMOS (firmy Unisys), Ingres II (firmy Computer Associates), Sybase Adaptive Server, Montage, Omniscience, Raima Database Manager, Total ORDB i inne. Systemy obiektowo-relacyjne są wyposażane w atrakcyjne cechy umożliwiające efektywną produkcję aplikacji. Wśród nich można wymienić przystosowanie do multimediów (duże obiekty BLOB, CLOB i pliki binarne), dane przestrzenne (spatial), abstrakcyjne typy danych (ADT), metody (funkcje i procedury) definiowane przez użytkownika w różnych językach (C, C++, VisualBasic, Java), kolekcje (zbiory, wielozbiory, sekwencje, zagnieżdżone tablice, tablice o zmiennej długości), typy referencyjne, przeciążanie funkcji, późne wiązanie i inne. Systemy te zachowują jednocześnie wiele technologii, które sprawdziły się w systemach relacyjnych (takie jak architektura klient/serwer, mechanizmy buforowania i indeksowania, przetwarzanie transakcji, optymalizacja zapytań). Systemy obiektowo-relacyjne nie są oparte na głębszej koncepcji lub teorii; są one tworzone przez praktyków i marketing z myślą o szybkim i pewnym zysku. Ideologiczne zalety obiektowo-relacyjnych baz danych są mało przekonywujące, ponieważ z koncepcyjnego punktu widzenia obiektowe bazy danych włączają struktury relacyjne jako przypadek szczególny. Podstawowy argument na rzecz takich systemów dotyczy zachowania SQL jako „języka intergalaktycznego”. Nie jest jednak jasne, o jaki SQL chodzi, ponieważ systemy te odbiegają od standardu SQL-92 (ze względu na rozbudowę struktur danych) lub powołują się na niedokończony i nie obowiązujący standard SQL3. Brak bazy intelektualnej dla tego rodzaju eklektyzmu budzi częste wątpliwości wśród ludzi wrażliwych na estetykę produktów informatycznych i zasadę nie mnożenia bytów ponad potrzebę (brzytwę Occama). Jednakże hasło „obiektowo-relacyjne” zyskuje licznych zwolenników głównie z powodu pozycji systemów relacyjnych na rynku i odwołania się do ich wiernej klienteli. Systemy obiektowo-relacyjne mają jednak posmak dekadencji, eklektyzmu i kryzysu koncepcji, cech swoistych dla granicy epok.

obiektowo-relacyjny system zarządzania bazą danych, obiektowo-relacyjny SZBD (object-relational database management system, ORDBMS) Patrz: obiektowo-relacyjny.

obiektowo-relacyjny SZBD (object-relational DBMS, ORDBMS) Patrz: obiektowo-relacyjny.

obiektowość (object-orientation, object-orientedness) Teoretyczna, ideologiczna i praktyczna koncepcja bazująca na wyróżnianiu obiektów o dobrze określonych granicach oraz semantyce; dotyczy ona programów, danych i rzeczywistości opisywanej przez dane. Naczelną misją obiektowości jest walka z nadmierną złożonością metodyk, projektów, języków, systemów i zastosowań. Tę misję obiektowość realizuje poprzez nacisk na mechanizmy abstrakcji, mechanizmy kompozycji/dekompozycji złożonych struktur (obiektów), mechanizmy hermetyzacji i ukrywania niepotrzebnej informacji, oraz własności sprzyjające abstrakcji i ponownemu użyciu. Do tych pojęć i mechanizmów zaliczane są obiekty, tożsamość, klasy, typy, hermetyzacja, polimorfizm i późne wiązanie. Uważa się, że dzięki tym mechanizmom obiektowość bardziej sprzyja naturalnym mentalnym i psychologicznym uwarunkowaniom podmiotów rzeczywistości informatycznej (klientów, analityków, projektantów, programistów, użytkowników, itd.).

obiektowość behawioralna (behavioral object-orientation) Określenie modelu obiektowego, w którym występuje pojęcie operacji, metody lub funkcji przypisanej do (klas) obiektów.

obiektowo-zorientowany (object-oriented) Patrz: obiektowo zorientowany.

obiektowy (object-oriented, OO) Określenie pewnego wytworu: języka, standardu, systemu, metodyki, itd., który posiada atrybuty obiektowości. Patrz: obiektowość.

obiektowy CASE (Object-Oriented CASE, OO-CASE) Patrz: obiektowy system CASE.

obiektowy identyfikator (Object IDentifier, OID) Patrz: OID.

obiektowy język programowania (object-oriented programming language) Język programowania wprowadzający pojęcia takie jak: obiekt, klasa, metoda, dziedziczenie, hermetyzacja i polimorfizm; np. Smalltalk, C++, Eiffel, Java, Sather, CLOS, Ada95, OO-Cobol, Beta, Cecil, Dylan, Python, Self, Theta i inne.

obiektowy język zapytań (object query language) Deklaracyjny język wysokiego poziomu umożliwiający wyszukiwanie (oraz niekiedy inne operacje) w obiektowej bazie danych; przykładem jest OQL wg standardu ODMG. Obiektowy język posiada zestaw generycznych operatorów (niezależnych od typu lub klasy), takich jak: selekcja, zależne złączenie, projekcja, nawigacja, grupowanie, uporządkowanie, kwantyfikatory, porównania, funkcje i operatory arytmetyczne, funkcje zagregowane (sum, min, max, avg, count), i inne.

obiektowy system CASE (object-oriented CASE system) System wspomagający analizę, modelowanie i projektowanie systemów informatycznych oparty o pojęcia obiektowości. Systemy te zapewniają środki do rysowania diagramów (zwykle wg popularnych notacji OMT, Booch, Shlaer/Mellor, UML i innych), pewne (zwykle ograniczone) środki do automatycznego generowania kodu oraz inne udogodnienia. Przykładami obiektowych systemów CASE są: 001, AdaVantage, Bachman Data Analyst, BOCS, BridgePoint, EasyCASE, EiffelCase, Envision, Excellerator II, GraphTalk, HOMSuite, HOOD Toolset, IE/O IEF, ILOG KADS Tool, Intelligent OOA, LOV/Object Editor, MacAnalyst&MacDesigner, MetaEdit, Model 5w, ObjectCraft, ObjectDomain, Objecteering, ObjectGEODE, ObjectTime, ObjectMaker, ObjectModeller, ObjectTool, Object Oriented Designer, Objectory, ObjectTeam, OEW, OOTher, OMW, OMTool, OSMOSYS, Paradigm Plus, Prosa/om, Ptech, Rational Rose, S-CASE, Select OMT, SES/Objectbench, Stood, StP, Synchronicity, System Architect, Toolbuilder, TurboCASE, VIEWS-SF, VisualThought, Westmount I-CASE OMT i inne. Patrz też: CASE.

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

http://osiris.sunderland.ac.uk/sst/casehome.html

http://www.qucis.queensu.ca/Department/FAQs/comp.software-eng/case.html

obiektowy system operacyjny (object-oriented operating system) System operacyjny udostępniający i traktujący zasoby komputera jako obiekty. Są to prawie zawsze systemy rozproszone pozwalające na swobodne przekazywanie obiektów pomiędzy komputerami. Jak dotąd, nie są zbyt szeroko rozpowszechnione. Przykładami obiektowych systemów operacyjnych są: Apertos, Chorus, Choices, GEOS, Mach, NachOS, Ouverture, Peace, SOS, Spring i PenPoint OS.

http://mmmc.jaist.ac.jp:8000/projects/object-oriented.html

obiektowy system wspomagania inżynierii oprogramowania (object-oriented CASE system) Patrz: obiektowy system CASE.

obiektowy system zarządzania bazą danych, OSZBD (object database management system, ODBMS) Obiektowy SZBD. System wspomagający zarządzanie, utrzymywanie, zabezpieczanie i udostępnianie obiektowej bazy danych. Obiektowe SZBD zachowują pozytywne własności relacyjnych SZBD, ale przyjmują założenie, że baza danych będzie przechowywała obiekty, a nie tablice (relacje). Z obiektowości przejmują wiele pojęć takich jak: złożone obiekty, tożsamość, klasy, dziedziczenie, hermetyzacja, polimorfizm. Definicję podstawowych własności obiektowych SZBD zawiera manifest obiektowych baz danych. W stosunku do relacyjnych baz danych obiektowa baza danych umożliwia znacznie większą konceptualizację aplikacji, przybliżając schemat bazy danych do schematów pojęciowych. Obiekty w obiektowej bazie danych są dostępne poprzez metody znajdujące się w ich klasach, jak i poprzez zapytania (np. w OQL). Ewaluacja zapytań w obiektowej bazie danych jest zwykle znacznie szybsza od ewaluacji zapytań relacyjnych ze względu na rzadszą konieczność wykonywania kosztownej operacji złączenia (join), która jest tam zastępowana poprzez nawigację wzdłuż powiązania pomiędzy obiektami lub zejście w dół hierarchii obiektu. Obiektowe bazy danych są również znacznie lepiej przystosowane do multimediów. Wiele z nich zapewnia także dobre wspomaganie dla zarządzania wersjami, aktywnych reguł, ograniczeń i rozproszenia.

Przykładami obiektowych SZBD (o statucie komercyjnym) są: ArtBASE, EasyDB, GemStone, IDB Object Database, ITASCA, Matisse, NeoAccess, OBST+, O2, Objectivity/DB, ObjectStore, Ontos (wcześniej Vbase), Odapter, OOFILE, Phyla, POET, Statice, UniSQL, Unisys Universal Repository, Versant, VisualWorks. Istnieje też wiele systemów eksperymentalnych i prototypów, np. Encore, Exodus, Machiavelli, Ode, Orion i inne. Prace badawczo rozwojowe nad obiektowymi SZBD zostały ukierunkowane przez standard ODMG (patrz: ODMG, ODMG 2.0).

http://www.odmg.org

http://www.well.com/user/ritchie/mini-faq.html

http://www.ifi.unizh.ch/groups/dbtg/Various/ODBminiFAQ.html

http://www.cimttz.tu-chemnitz.de/oodb/OODBminiFAQ.html

http://www.objectivity.com/aboutodb/aboutodb.html

http://www.icslab.agh.edu.pl/~jasper/oodb/

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

http://www.odbmsfacts.com/

obiekty jako wartości (objects-by-value) Termin nowego standardu CORBA 3.0. Chodzi o możliwość reprezentacji obiektów jako pewnych wartości (np. ciągów znaków), celem umożliwienia przesyłania obiektów w sieci, zwracania obiektów przez funkcję lub metodę, itd.

obiekty rozproszone (distributed objects) Patrz: rozproszone obiekty.

Object Currents Czasopismo z zakresu obiektowości publikowane na WWW.

http://www.sigs.com/objectcurrents/

Object Domain Prosty obiektowy system CASE.

http://www.he.tdl.com/~dirkv/domain.html

http://www.object-domain.com/

Object Lisp Obiektowe rozszerzenie języka Lisp.

Object Magazine Online Czasopismo z zakresu obiektowości publikowane na WWW.

http://www.sigs.com/omo/

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

http://www.beasys.com/

http://www-digital.cern.ch/digital-at-cern/joint-project/objectbroker/

objectbroker.html

Objective C Obiektowy język programowania rozszerzający język C o niektóre cechy języka Smalltalk. Nie posiada przeciążania operatorów, wielodziedziczenia i zmiennych klasowych. Posiada dynamiczne wiązanie i dynamiczną kontrolę typów. Jest używany jako język programowania systemowego w projekcie NEXTSTEP.

http://www.batech.com/~dekorte/Objective-C/objc.html

http://www.santafe.edu/~nelson/objective-c.html

http://www.geom.umn.edu/docs/W3Kit/Overview/ObjectiveC.html

http://www.cs.indiana.edu/classes/c304/oop-intro.html

http://www.cis.ohio-state.edu/hypertext/faq/usenet/Objective-C/top.html

Objective Pascal Obiektowe rozszerzenie języka Pascal.

Objectivity/DB Obiektowy system zarządzania bazą danych rozwijany wg standardu ODMG przez firmę Objectivity, Inc.

http://www.objectivity.com/

ObjectLOGO Obiektowe rozszerzenie języka LOGO.

Objectory Metodyka obiektowej analizy i projektowania systemów informatycznych zaproponowana przez Jacobsona.

ObjectStore Obiektowy system zarządzania bazą danych oparty na C++, zrealizowany przez firmę Object Design, Inc.

http://www.odi.com/

Object-Z Obiektowa wersja notacji Z służącej do formalnej (matematycznej) specyfikacji oprogramowania. Zaletą formalnych notacji, takich jak Object-Z, jest umożliwienie sformalizowania problemu w takim stopniu, aby można było przeprowadzić (formalne lub półformalne) dowody poprawności przyjętych rozwiązań. Podstawową wadą formalnych specyfikacji jest ich nieprzystosowanie do skali rzeczywistych problemów, co redukuje ich zastosowanie do mało istotnego marginesu.

obsługa wyjątków (exception handling, exception handler) Fragment kodu programu przypisany do wyjątku, który jest uruchamiany w momencie pojawienia się tego wyjątku.

obywatel drugiej kategorii (second-class citizen) Pojęcie języka programowania istniejące wyłącznie w tekście programu (wykorzystywane w fazie analizy statycznej) i niedostępne w czasie wykonania; np. nazwa zmiennej, nazwa parametru, typ, sygnatura procedury, itd.

obywatel pierwszej kategorii (first-class citizen) Określenie odnoszące się do pojęcia języka programowania (np. typu, klasy, modułu, wartości zmiennej, nazwy zmiennej) oznaczające, że dany byt programistyczny istnieje i można nim manipulować w czasie wykonania. Np. wartość atrybutu obiektu jest obywatelem pierwszej kategorii, natomiast nazwa atrybutu zwykle nim nie jest.

obywatelstwo (citizenship) W językach programowania obywatelem pierwszej kategorii nazywa się taki byt programistyczny, który istnieje i którym można manipulować w czasie wykonania. Obywatelem drugiej kategorii nazywa się ten byt, który istnieje tylko w fazie analizy tekstu programu (kompilacji), tzn. nie istnieje lub jest całkowicie niedostępny podczas wykonania. W klasycznych językach programowania większość pojęć ma obywatelstwo drugiej kategorii (np. nazwy zmiennych, typy, moduły, itd.), gdyż programista nie posiada jakichkolwiek możliwości zarządzania nimi w czasie wykonania. Np. nie może w trakcie wykonywania programu zmienić nazwy zmiennej. Tego rodzaju operacja jest możliwa wyłącznie na tekście programu. Istnienie pojęć o drugiej kategorii obywatelstwa sprzyja wydajności i niezawodności, gdyż wszystkie operacje związane z tymi pojęciami (np. kontrola typów) mogą być wykonane w trakcie kompilacji. Z drugiej strony, pojęcia programistyczne przesunięte do pierwszej kategorii obywatelstwa sprzyjają elastyczności, programowaniu generycznemu (generic) i technikom ponownego użycia. Podwyższenie sprawności komputerów spowodowało tendencję do przesuwania pojęć programistycznych do pierwszej kategorii obywatelstwa. Obywatelstwo jest także określane jako „kategoria programistyczna".

obywatelstwo klasy (class citizenship) Charakterystyka ustalająca, czy klasa w danym języku programowania jest obywatelem pierwszej czy też drugiej kategorii. Np. w Smalltalku klasa (która jest również obiektem) jest obywatelem pierwszej kategorii (można wysłać do niej komunikat), natomiast w C++ klasa jest obywatelem drugiej kategorii - wysłanie komunikatu do klasy jest niemożliwe, ponieważ klasy istnieją wyłącznie w tekście programu i nie są dostępne w czasie wykonania. Klasa należąca do pierwszej kategorii programistycznej jest zbieżna z pojęciem prototypu.

ochrona (security) Przeciwdziałanie świadomym lub nieświadomym akcjom dowolnych osób, które mogłyby doprowadzić do zniszczenia danych, niepożądanych zmian danych, zniekształcenia lub zatrzymania procesów ich przetwarzania, zniszczenia sprzętu i oprogramowania, uniknięcia zapłaty za korzystanie z danych lub usług systemu, itd. Ochrona oznacza środki wprowadzone w systemie, których celem jest działanie przeciwko sabotażowi, wandalizmowi, wirusom, dostępowi hakerów, zniszczeniu poprzez nieuwagę, nadużyciu funkcji systemu, zatrzymaniu lub opóźnieniu pracy systemu, unikaniu płatności, itd. Patrz też: bezpieczeństwo.

Odapter (Java/Depot) Obiektowy system zarządzania bazą danych zrealizowany przez Hewlett-Packard Company.

ODB (Object Data Base) Patrz: obiektowa baza danych.

ODBC (Open DataBase Connectivity) Standard dostępu do różnorodnych baz danych. Istnieją interfejsy ODBC dla VisualBasic, Visual C++, SQL i innych języków. ODBC umożliwia dostęp do systemów Access, Paradox, Dbase, Text, Excel, Btrieve i innych. ODBC używa pewnego dialektu SQL, który następnie odwzorowuje na interfejsy poszczególnych systemów baz danych. ODBC jest zdefiniowany przez konsorcjum SQL Access Group; nie jest wyłącznie standardem Microsoftu, ale Microsoft położył zasadnicze zasługi w jego spopularyzowaniu. Pakiety ODBC (ODBC drivers) są obecnie dostępne dla MS Windows, systemów opartych o Unix, OS/2 i Macintosh.

ODB-II Obiektowy system zarządzania bazą danych (poprzednio Jasmine) firmy Fujitsu.

http://www.fsc.fujitsu.com/fsc/object/

odbiorca (receiver) Obiekt będący adresatem komunikatu.

ODBMS [1] (Object DataBase Management System) Patrz: obiektowy system zarządzania bazą danych.

ODBMS [2] Obiektowy system zarządzania bazą danych zrealizowany przez firmę VC Software, Inc.

Ode Obiektowy system zarządzania bazą danych zrealizowany w AT&T Bell Laboratories. Baza danych utrzymywana przez Ode jest definiowana, przeszukiwana i manipulowana w języku O++, opartym na C++ i posiadającym pewne ograniczone możliwości w zakresie zapytań. Klasy w O++ posiadają własności hermetyzacji i wielokrotnego dziedziczenia (multi-inheritance). Przewidziane są możliwości definiowania wersji obiektów. Z obiektami można skojarzyć wyzwalacze i ograniczenia integralnościowe.

http://www-db.research.bell-labs.com/projects/ode/ode-announce/

ODL (Object Definition Language) Język definicji danych (język opisu danych) wchodzący w skład standardu ODMG. ODL umożliwia definiowanie klas obiektów, atrybutów, powiązań asocjacyjnych między obiektami, hierarchii dziedziczenia, metod oraz innych własności danych przechowywanych w obiektowej bazie danych.

ODMG (Object Database Management Group, Object Data Management Group) Organizacja utworzona przez firmy rozwijające obiektowe bazy danych, stawiająca sobie za cel opracowanie standardu w dziedzinie obiektowych baz danych. W skład ODMG wchodzą przedstawiciele kilkunastu zwykle małych i średnich firm komputerowych, wśród nich O2 Technology (obecnie połączona z Ardent Software i UniData), ObjectDesign, POET Software, GemStone Systems, Versant Object Technology, Objectivity, Sun Microsystems i inne. Poprzednie dwie wersje standardu były oznaczone jako ODMG-93 (grudzień 1993) i ODMG-93 Release 1.2 (styczeń 1996), obecna (sierpień 1997) jest oznaczona jako ODMG 2.0. Jako cel autorzy standardu stawiają przenaszalność (portability) aplikacji pomiędzy niezależnie zbudowanymi systemami.

http://www.odmg.org

ODMG 2.0 Nowa wersja standardu obiektowych baz danych opracowywanego przez ODMG (Object Data Management Group), która pojawiła się w połowie roku 1997. Poniżej prezentujemy ramową architekturę ODMG 2.0.

Ramowa architektura ODMG 2.0.

Standard posiada następujące części realizujące założenia przedstawionej architektury:

  • Model obiektowy. Precyzuje znaczenie podstawowych pojęć obiektowości, takich jak obiekty, klasy, metody, dziedziczenie, hermetyzacja. Ustala również podstawowe założenia dotyczące struktur danych przechowywanych przez system. Takimi strukturami są obiekty, atrybuty i związki (relationships). Klasy obiektów podlegają dziedziczeniu i hermetyzacji. ODMG wprowadza także pojęcie literału, czyli wartości, której nie można modyfikować. Istotnym założeniem modelu obiektowego ODMG jest mocna kontrola typów oraz pełna dowolność w zakresie kombinacji konstruktorów typów, w tym konstruktorów typów masowych (kolekcji), takich jak zbiór, wielozbiór, sekwencja i tablica dynamiczna. Umożliwia to tworzenie obiektów o dowolnej liczbie poziomów hierarchii oraz o dowolnej złożoności. Model obiektowy ODMG jest rozszerzeniem modelu OMG CORBA.
  • Język definicji obiektów ODL (Object Definition Language). Jest wzorowany na języku IDL wg OMG CORBA. Projektant bazy danych lub programista opisuje w ODL jej strukturę. Jest to niezbędne zarówno do rozumienia znaczenia danych, jak i sposobu, w jaki są one odwzorowane w zapamiętane struktury. Schemat w ODL specyfikuje przechowywane dane na pewnym poziomie abstrakcji poprzez podanie ich typów, klas, powiązań klas w hierarchie dziedziczenia, związków między klasami, metod działających na obiektach i innych elementów. Specyfikacja klasy (zwana interfejsem) jest oddzielona od jej implementacji (zwanej klasą). Standard nie zajmuje się implementacją klas i metod, przyjmując, że tę funkcję będą skutecznie pełnić związane z nim obiektowe języki programowania (C++, Smalltalk i Java).
  • Format wymiany obiektów. Ustala reprezentację obiektów przy ich wymianie pomiędzy różnymi systemami zarządzania bazą danych.
  • Język zapytań OQL (Object Query Language). Jest przeznaczony do wyszukiwania danych w celu ich dalszego przetwarzania lub wyprowadzenia na zewnątrz. W odróżnieniu od SQL, OQL nie zajmuje się operacjami aktualizacyjnymi, oddelegowując je do języków programowania. OQL jest zgodny z modelem obiektowym oraz językiem ODL. OQL jest językiem o wysokim poziomie abstrakcji, deklaracyjnym (określa cel wyszukiwania, a nie akcje prowadzących do tego celu), makroskopowym (równoległe działanie na wielu obiektach) i naturalnym dla użytkowników.
  • Wiązanie do języka C++. Określa zasady połączenia ODL i OQL z językiem C++ oraz specyfikuje zestaw klas (interfejsów) umożliwiających takie połączenie. C++ jest językiem bardzo popularnym, będąc jednocześnie mocno krytykowanym za cechy niskiego poziomu (np. arytmetyka wskaźników). Pozwala to przypuszczać, że w dalszej przyszłości wiązanie do C++ straci na znaczeniu, na korzyść rozbudowy języka OQL oraz wiązań do języków takich jak Smalltalk i Java.
  • Wiązania do języków Smalltalk i Java. Mają założenia podobne do wiązania do C++. W odróżnieniu od C++ występują tu ograniczenia. Smalltalk i Java nie mają wielodziedziczenia, co wymaga okrojenia modelu obiektowego i ODL. Występują także ograniczenia w zakresie definiowania i przetwarzania związków (relationships). Wiązanie do języka Java jest ostatnio przedmiotem szczególnego zainteresowania.

Standard ODMG 2.0 wykazuje liczne braki i wady koncepcji, w związku z czym należy oczekiwać, że zostanie wkrótce zastąpiony przez następną wersję. W stosunku do wersji książkowej dokumentu ostatnie nowelizacje standardu dotyczą wiązania do Java.

http://www.odmg.org

ODMG-93 Starsza wersja standardu ODMG; patrz: ODMG 2.0.

odporność (robustness) Określenie możliwości poprawnego funkcjonowania w nienormalnej lub wyjątkowej sytuacji. Patrz też: moc.

odpowiedzialność (responsibility) Cel, zobowiązanie lub wymagane możliwości obiektu lub klasy. Z reguły odpowiedzialność jest określona jako zestaw usług realizowanych przez obiekt lub klasę oraz jego/jej cech.

odsyłacz (reference) Patrz: referencja.

odśmiecacz (garbage collector, GC) Patrz: zbieranie nieużytków.

odśmiecanie (garbage collection) Patrz: zbieranie nieużytków.

odtwarzanie (recovery) Odtwarzanie stanu bazy danych po awarii na podstawie ostatniej wersji składowanej (back-up) oraz dziennika (log).

odwracanie (rollback) Po zerwaniu transakcji wycofanie się ze wszelkich zmian w bazie danych poczynionych przez tę transakcję.

odwzorowanie językowe (language mapping) Odwzorowanie konstrukcji jednego języka na konstrukcje innego języka; np. odwzorowania wyrażeń IDL CORBA na deklaracje klas w C++.

ograniczenia integralnościowe (integrity constraints) Patrz: więzy integralności.

ograniczenie (constraint) Dowolne ograniczenie wprowadzane do schematu danych, diagramu klas, itd. w postaci formalnej, półformalnej lub nieformalnej. Patrz też: więzy integralności.

ograniczenie Millera (Miller limit) Ograniczenie ludzkiej percepcji i rozumienia wynikające ze złożoności, która staje się istotna przy liczbie elementów siedem plus minus dwa. Popularne zalecenie w projektowaniu graficznych interfejsów użytkownika.

OID (Object Identifier, Object IDentity) Identyfikator obiektu, tożsamość obiektu. Patrz też: mrówka.

OLAP (On Line Analytical Processing) Technologia przetwarzania i udostępniania danych analitycznych i syntetycznych polegająca na gromadzeniu danych z różnych źródeł, zapisaniu ich w pewnym regularnym formacie (np. w postaci tzw. kostki danych, data cube) i następnie analizowaniu ich przy pomocy różnorodnych narzędzi, np. statystycznych. OLAP często kojarzy się z hurtowniami danych (data warehouses) oraz z eksploracją danych (data mining).

http://www.olapcouncil.org

http://www.access.digex.net/~grimes/olap/

http://www.arborsoft.com/papers/finkTOC.html

OLE (Object Linking and Embedding) Standard interfejsu (częściowo) obiektowego, umożliwiający wymianę obiektów pomiędzy różnym oprogramowaniem firmy Microsoft. OLE jest uogólnieniem popularnego „schowka” umożliwiającego kopiowanie fragmentów dokumentów zapisanych w różnych formatach. Obiektami OLE mogą być pliki edytora Word, grafika ze skanera w odpowiednich formatach, grafika wektorowa, tablice, pliki Excela, itd. Patrz też: OLE2 i COM.

OLE Automation Własność standardu OLE2 firmy Microsoft, która umożliwia aplikacji lub obiektowi OLE komunikowanie się z innym obiektem OLE poprzez przesyłanie sekwencji komend, zwykle ustawiających pewne własności lub wykonujących pewne metody. Patrz też: OLE2.

OLE2 Nowsza koncepcja OLE rozszerzona o możliwość jednoczesnej pracy z wieloma aplikacjami działającymi w systemie Windows. OLE2 włącza prosty model komunikacji, który jest używany przez aplikacje do koordynowania dostępu do ekranu. W uzupełnieniu do OLE, OLE2 posiada także mechanizm „przesuń i upuść” (Drag and Drop), umożliwiający przesuwanie obiektów (np. komponentów dokumentów) pomiędzy oknami. OLE2 włącza również pakiet OLE Automation, pozwalający zapisać w aplikacjach sekwencję operacji OLE w postaci skryptu i następnie wykonywać ten skrypt w trybie wsadowym. OLE Automation umożliwia też koordynowanie wielu aplikacji celem wykonania złożonych zadań. Komponenty w C++, VisualBasic i innych językach, które mają zastosowanie w aplikacjach poprzez OLE Automation, są określane jako OLE Controls. Patrz też: COM.

OLTP (On-Line Transaction Processing) Przetwarzanie transakcji on-line; przetwarzanie transakcji w systemie rozproszonym w czasie rzeczywistym. W typowym ustawieniu aplikacja OLTP powtarza wykonanie transakcji z pewnego z góry zdefiniowanego zestawu (z reguły zapisanych w SQL). Transakcje te są nadsyłane równolegle i niezależnie przez klientów aplikacji, przy czym żadna z nich nie może zmonopolizować zasobów komputera lub bazy danych. Technologia OLTP jest często związana z wyrafinowanym dostrajaniem i optymalizacją bazy danych oraz algorytmów przetwarzania pod kątem uzyskania maksymalnej wydajności przy założonym zestawie i profilu transakcji.

OMA (Object Management Architecture) Architektura zarządzania obiektami; termin OMG. OMA jest wizją wysokiego poziomu kompletnego środowiska rozproszonego. OMA składa się z czterech części: dwie systemowe (pośrednik zleceń obiektowych (Object Request Broker, ORB) i usługi obiektowe (Object Services)), oraz dwie zorientowane na aplikacje (obiekty aplikacyjne (Application Objects) i wspólne udogodnienia (Common Facilities)). ORB stanowi podstawę OMA zarządzając całą komunikacją pomiędzy jej składnikami. Umożliwia on interakcję obiektów w środowisku rozproszonym i heterogenicznym, niezależnie od platform sprzętowych, na których znajdują się obiekty, oraz technik, które były użyte do ich implementacji. W tym zadaniu ORB jest wspomagany przez usługi obiektowe, które są odpowiedzialne za ogólne zarządzanie obiektami, w tym tworzenie obiektów, sterowanie dostępem, przesuwanie obiektów, itd. Obiekty aplikacyjne i wspólne udogodnienia znajdują się bliżej użytkownika; ich funkcją jest m.in. wysyłanie zleceń do ORB i usług obiektowych.

Architektura OMA

http://www.omg.org

Omega Obiektowy język programowania w duchu języków Smalltalk i Self, bazujący na pojęciu prototypu. Omega posiada statyczną kontrolę typów.

OMG (Object Management Group) Organizacja skupiająca wiele czołowych firm komputerowych (aktualnie ponad 800), mająca na celu opracowanie standardu współdziałania pomiędzy heterogenicznymi, rozproszonymi systemami obiektowymi i nieobiektowymi. Propozycja standardu nosi nazwę CORBA. Patrz też: CORBA.

http://www.omg.org

OML (Object Manipulation Language) Język manipulacji obiektami. Termin ODMG oznaczający zestaw klas, metod i interfejsów umożliwiający programowanie obiektowej bazy danych w językach C++, Smalltalk lub Java.

Omniscience Obiektowy system zarządzania bazą danych zrealizowany przez firmę Omniscience Object Technology, Inc.

OMT (Object Modeling Technique) Metodyka analizy i projektowania obiektowego zaproponowana przez J. Rumbaugh i innych autorów. Metodyka identyfikuje trzy zadania: analizę, projektowanie systemu oraz projektowanie obiektowe. Wprowadza trzy perspektywy lub modele systemu: model (klas) obiektów, model dynamiczny oraz model funkcjonalny (wariant modelu przepływu danych). Zawiera także wiele rozważań przydatnych dla projektowania i implementacji. Wyróżnione są następujące pojęcia: klucze kandydujące, ograniczenia, obiekty pochodne, homomorfizm, współbieżność, bezpośrednia (peer-to-peer) komunikacja. OMT jest bardzo (najbardziej?) popularną metodyką obiektową. Charakteryzuje się dużym poziomem abstrakcji, nie schodzi zbytnio na poziom projektowania i implementacji. Stosowana terminologia jest intuicyjna, ale nie zawsze jasna.

Ontos DB Obiektowy system zarządzania bazą danych firmy Ontologic, obecnie ONTOS, Inc.

http://www.ontos.com/tool.htm

OO (Object-Oriented) Obiektowy. Patrz: obiektowość

OOA (Object-Oriented Analysis) Patrz: analiza obiektowa.

OOA/OOD (Object-Oriented Analysis/Object-Oriented Design) Obiektowa metodyka analizy i projektowania systemów informatycznych, inaczej Coad/Yourdon. Wyróżnia pięć aktywności: wyodrębnienie klas i obiektów, wyodrębnienie struktur, wyodrębnienie podmiotów lub dziedzin, określenie atrybutów, określenie usług. Posiada w związku z tym pięć poziomów: podmioty, klasy i obiekty, struktury, atrybuty oraz usługi. Składowymi metody są: interakcja z ludźmi, określenie dziedziny problemu, zarządzanie zadaniami, zarządzanie danymi. Wyróżnialnymi cechami metodyki są: przesyłanie komunikatów, terminologia obiektowa, komponenty projektowe. OOA/OOD jest uważana za metodykę dość złożoną i opartą na zbyt wielu wyrafinowanych pojęciach.

OOAD [1] (Object-Oriented Analysis and Design) Patrz: analiza i projektowanie obiektowe.

OOAD [2] (Object-Oriented Analysis and Design) Obiektowa metodyka analizy i projektowania systemów informatycznych, inaczej Martin/Odell. Metodyka bazuje na pojęciach z zakresu logiki i teorii zbiorów. Jest uważana za metodykę wprowadzającą szereg użytecznych pojęć, ale nie obejmującą pełnego procesu analizy i projektowania.

OO-CASE (Object-Oriented CASE) Patrz: obiektowy system CASE.

OO-Cobol (Object-Oriented Cobol) Obiektowy język programowania będący rozszerzeniem języka Cobol. OO-Cobol jest wynikiem prac standardyzacyjnych ANSI, dokument ANSI/X3J4/94-0191.

http://www.tiac.net/users/jsuth/papers/oocobol.html

http://www.mfltd.co.uk/OC/index.html

OOD (object-oriented design) Patrz: obiektowe projektowanie.

OODA (Object-Oriented Design with Applications) Obiektowa metodyka analizy i projektowania systemów informatycznych opracowana przez G. Boocha. OODA jest podzielona na cztery kroki:

  • identyfikacja klas i obiektów;
  • identyfikacja ich semantyki;
  • identyfikacja związków pomiędzy obiektami;
  • implementacja klas i obiektów.

OODA bazuje na siedmiu zasadach: abstrakcji, hermetyzacji, modularności, hierarchii klas i obiektów, kontroli typów, współbieżności i trwałości. Składowe klas są podzielone na trzy typy: publiczne (public), zabezpieczone (protected) i prywatne (private). OODA wprowadza cztery perspektywy systemu: logiczna statyczna, logiczna dynamiczna, fizyczna statyczna i fizyczna dynamiczna. Wprowadza następujące typy diagramów: klas i obiektów, przejść między stanami, modułów i procesów. OODA jest dość silnie uzależniona od struktur językowych C++. Ogólne pojęcia służące do projektowania oraz wprowadzane techniki są dość proste i łatwe do zrozumienia. Poziom projektowania jest bliższy strukturom fizycznym i implementacyjnym, niż to ma miejsce w innych metodykach.

OODB (object-oriented database) Patrz: obiektowa baza danych.

OODBMS (object-oriented database management system) Patrz: obiektowy system zarządzania bazą danych.

OOF (Object-Oriented Fortran) Obiektowa wersja języka Fortran.

OOIS (Object-Oriented Information Systems) Coroczna konferencja nt. obiektowych systemów informacyjnych.

OOP (Object-Oriented Programming) Patrz: programowanie obiektowe.

OOPL (Object-Oriented Programming Language) Patrz: obiektowy język programowania.

OOPSLA (Object-Oriented Programming Systems, Languages and Applications) Cykliczna konferencja z zakresu obiektowości.

OORAM Obiektowa metodyka analizy i projektowania systemów informatycznych.

http://www.oslonett.no/html/adv/TASKON/prod/OORAM.html

http://www.oslonett.no/html/adv/TASKON/prod/verkt.html

http://www.oslonett.no/html/adv/TASKON/TASKON.html

OOSA (Object Oriented System Analysis) Obiektowa metodyka analizy i projektowania systemów informatycznych, inaczej Shlaer/Mellor. Metodyka jest oparta na technice modelowania informacji i wprowadza trzy modele: model informacyjny, model stanów i model procesów. Model informacyjny definiuje jednostki pojęciowe wyróżnialne w świecie jako obiekty systemu. Model stanów opisuje cykl życiowy tych obiektów. Model procesów uszczegóławia aktywności obiektów w postaci diagramów przepływu danych. Modele te powinny być połączone dla uzyskania zintegrowanej perspektywy systemu. Specyfikacja zewnętrza opisuje funkcje, które wykonują obiekty systemu na bytach zewnętrznych. Metodyka zwraca uwagę na opis wnętrza systemu, ale jest nieco słabsza w zakresie opisu związków pomiędzy obiektami i klasami.

Opal Język programowania aplikacji systemu Gemstone.

opcyjny (optional) Atrybut, wartość, konstrukcja językowa lub inna cecha, która może być nieobecna (nie musi występować w każdym przypadku).

OPEN Metodyka obiektowa oraz notacja, sukcesor metodyki MOSES. Wymieniana niekiedy jako konkurent metodyki OMT i notacji UML. Akronimem OML (OPEN Modeling Language) oznaczony jest metamodel oraz notacja związana z metodyką OPEN. Metodykę OPEN reklamuje się jako uniwersalną, trzeciej generacji, obejmującą pełny cykl rozwoju oprogramowania.

http://www.csse.swin.edu.au/cotar/OPEN/

OpenDoc Oprogramowanie pośredniczące, wieloplatformowa architektura oprogramowania (Apple Macintosh OS, MS Windows, O/S 2, AIX, UNIX) realizująca koncepcję oprogramowania komponentowego. OpenDoc jest rozwijany przez Component Integration Laboratories (CI Labs), niedochodową organizację skupiającą ponad 300 firm, w tym Apple, IBM, Lotus, Adobe, Novell, WordPerfect, Taligent, XSoft/Xerox. OpenDoc umożliwia łączenie wielu komponentów w jedną aplikację (zamiast budowania jednej dużej aplikacji), co znacznie podnosi efektywność tworzenia aplikacji, potencjał ponownego użycia i współdziałania pomiędzy niezależnie zbudowanym oprogramowaniem. Umożliwia także integrację danych multimedialnych (tekst, audio, wideo, grafika bitowa, arkusze kalkulacyjne), integrację aplikacji bazujących na sieci Internet oraz zintegrowany dostęp do zasobów WWW poprzez pakiet/przeglądarkę CyberDog. OpenDoc współdziała z narzędziami i obiektami technologii OLE2. OpenDoc wprowadza dwa główne pojęcia: dokumentu (obiektu o budowie hierarchicznej integrującego informację statyczną, wizualną i proceduralną) oraz komponentu (fundamentalnego bloku oprogramowania), i składa się z pięciu warstw funkcjonalnych:

  • Obsługa złożonych dokumentów;
  • Obsługa komponentów;
  • Obsługa pracy wsadowej (Automation Services);
  • Obsługa zarządzania obiektami;
  • Obsługa współdziałania.

Obsługa zarządzania obiektami bazuje na SOM (System Object Model) firmy IBM, który jest pośrednikiem w zakresie przetwarzania rozproszonych obiektów zgodnym ze standardem OMG CORBA. Również porozumienie Apple z firmą IONA przewiduje przystosowanie pakietów OpenDoc i Orbix do bezpośredniego współdziałania. Przewiduje się także integrację z innymi pakietami ORB w ramach standardu CORBA.

http://www.cilabs.org/

OpenIngres Starsza (obecnie nie podtrzymywana) wersja systemu Ingres II.

OpenRoad Wizyjny obiektowy język programowania czwartej generacji opracowany dla systemu OpenIngres przez firmę Computer Associates. OpenRoad włącza wiele elementów obiektowości, takich jak klasy i metody.

operacja (operation) Funkcja dokonująca przekształcenia danych lub wartości. Synonimy: metoda, funkcja.

operacja abstrakcyjna (abstract operation) Patrz: metoda abstrakcyjna.

operacja klasowa (class operation) Operacja działająca nie na obiektach danej klasy, ale na samej klasie (ściślej, na ekstensji klasy), np. konstruktor lub destruktor. Synonim: metoda klasowa.

operacja obca (foreign operation) Operacja importowana z innego modułu, języka, programu, itd.

operacja pochodna (derived operation) Operacja, którą można wyrazić poprzez proste złożenie (wywołanie) innych operacji.

oprogramowanie aplikacyjne (application software) Oprogramowanie wykonujące bezpośrednio pewne funkcje lub usługi na rzecz danego klienta lub dziedziny przedmiotowej.

oprogramowanie komponentowe (component software, componentware) Dziedzina rozwojowa i praktyczna zmierzająca do budowy standardów oraz wspomagającego je oprogramowania, które pozwoliłoby na składanie dużych aplikacji lub systemów z mniejszych standardowych części - komponentów (na zasadzie podobnej do składania komputera z podzespołów). Niektórzy specjaliści uważają oprogramowanie komponentowe za naturalny rozwój programowania obiektowego oraz perspektywę na bliższą i dalszą przyszłość. Przykładami standardów i systemów oprogramowania komponentowego są: OMG CORBA, OpenDoc firm Apple, IBM i innych, technologia OLE2/COM/DCOM/ActiveX firmy Microsoft oraz pakiet JavaBeans firmy JavaSoft/Sun. W świecie komercyjnym trwa batalia pomiędzy konkurencyjnymi pakietami oprogramowania komponentowego (szczególnie pomiędzy ActiveX i JavaBeans). Pewien sceptycyzm względem oprogramowania komponentowego jest powodowany przez fakt, że tego rodzaju pomysły (określane różnie: mega-programming, programming-in-the-large, itp.) są znane od ok. 30-tu lat, nie przynosząc istotnego postępu w tym zakresie. Zasadniczym powodem są trudności w precyzyjnym i dostatecznie abstrakcyjnym wyspecyfikowaniu interfejsów pomiędzy komponentami, problemy z osiągnięciem akceptowalnej wydajności oraz stały burzliwy postęp w informatyce, powodujący pojawianie się coraz to nowych wymagań na te interfejsy.

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

http://www.omg.org

oprogramowanie pośredniczące (middleware) Terminem tym określa się wszelkie oprogramowanie, którego zadaniem jest łączenie innego oprogramowania, w szczególności pomosty (gateways) pomiędzy systemami, pośredników (ORB) zbudowanych według standardu OMG CORBA, OpenDoc firm Apple, IBM i innych, technologia COM/DCOM firmy Microsoft, rozproszone systemy operacyjne takie OSF DCE lub ANSA Ware i inne.

http://www.omg.org

oprogramowanie spadkowe (legacy software) Starsze oprogramowanie, które musi być zastąpione lub przystosowane do nowego oprogramowania, nowego sprzętu, itd.

optymalizacja zapytań (query optimization) Dziedzina badawcza i praktyczna zajmująca się metodami, technikami i teoriami służącymi do radykalnego skrócenia czasu wykonywania zapytań. Optymalizator zapytań (query optimizer) jest fragmentem oprogramowania systemu zarządzania bazą danych zajmującym się skróceniem czasu wykonania zapytań. Terminy „optymalizacja” i „optymalizator” są tutaj używane niewłaściwie, ponieważ nie jest rozważane optimum z punktu widzenia jakiegokolwiek formalnego kryterium, a raczej chodzi o osiągnięcie takiego czasu przetwarzania zapytania, który jest akceptowalny z punktu widzenia użytkownika. Metody optymalizacji zapytań można podzielić na następujące grupy:

  • Poziom fizyczny organizacji danych - można tu wyróżnić indeksy (najczęściej organizowane jako B-drzewa), kodowanie mieszające (hash coding) i powiązania wskaźnikowe (pointer links);
  • Przekształcenie zapytania na taką semantycznie równoważną postać, która rokuje lepszy czas przetwarzania. Zazwyczaj takie przekształcenie odbywa się na tekście zapytania lub na jego drzewie syntaktycznym; metody te określa się jako przepisywanie (rewriting). Dla języków implementowanych w relacyjnych bazach danych (SQL) istotne efekty daje przesunięcie wykonania operatorów selekcji i projekcji przed operator złączenia;
  • Wysoko wyspecjalizowane algorytmy dla niektórych operatorów, np. realizacja operatora złączenia przez posortowanie argumentów i „scalenie” (merging), lub poprzez kodowanie mieszające;
  • Ustalenie optymalnego planu obliczania wyników pośrednich (query execution plan).

Optymalizacja zapytań wymaga precyzyjnego modelu semantyki, skąd wynika nacisk na matematyczną formalizację języków zapytań. W szczególności, niektóre metody są oparte o równoważne przekształcenia wyrażeń algebry relacji, którą uważa się za dobry model formalny dla opisu semantyki relacyjnych języków zapytań, m.in. SQL. Model ten jest jednak bardzo ograniczony i nie zawsze adekwatny, stąd większość metod optymalizacji zapytań jest wynikiem obserwacji i spekulacji praktycznych, eksperymentów i heurystyki. Wiedza dotycząca optymalizacji zapytań jest bardzo mało stabilna, gdyż nowe języki (np. obiektowe) często implikują nowe problemy i metody.

optymalizator zapytań (query optimizer) Moduł lub mechanizm bazy danych dokonujący optymalizacji zapytań.

optymistyczny model transakcji (optimistic transaction model) Model transakcji zakładający, że prawdopodobieństwo niekorzystnych interferencji transakcji (utraty spójności danych lub przetwarzania wskutek jednoczesnego dostępu do tej samej danej) jest niskie. W związku z tym (w odróżnieniu od modelu pesymistycznego) model optymistyczny nie zakłada konieczności blokowania dostępu do danych poprzez zakładanie zamków. Jeżeli jednak pewna dana przetwarzana przez daną transakcję jest jednocześnie przetwarzana przez inną transakcję (transakcje), wówczas traktowane jest to jako konflikt. Efektem jest zerwanie wszystkich transakcji uczestniczących w konflikcie. Metody wykrywania konfliktów są oparte o analizę kolejności dostępu poszczególnych transakcji do poszczególnych danych i/lub o stemple czasowe (stawiane przez transakcje na przetwarzanych przez nie danych). Optymistyczny model transakcji unika problemu zakleszczenia (deadlock), ale może być nieefektywny w przypadku dużej liczby konfliktów.

OQL (Object Query Language) Obiektowy język zapytań wg standardu ODMG. Składnia OQL jest wzorowana na SQL. Pod względem semantyki OQL bazuje na modelu obiektowym ODMG oraz wprowadza mocną kontrolę typów (co zasadniczo różni go od SQL). OQL posiada operatory podobne do operatorów SQL, ale wprowadza także szereg nowych, m.in. zależne złączenie i operatory umożliwiające konstruowanie złożonego wyniku. OQL jest dość mocnym językiem (w zakresie wyszukiwania mocniejszym od SQL); posiada również znacznie bardziej ortogonalną konstrukcję niż SQL. Podstawową wadą OQL jest zbyt luźne zintegrowanie z interfejsami i konstrukcjami programistycznymi, co nieuchronnie prowadzi do efektu określanego jako niezgodność impedancji (ten oczywisty wniosek jest demagogicznie negowany przez twórców OQL). Innymi wadami OQL są: niezbyt precyzyjna semantyka, brak uniwersalności, brak możliwości definiowania perspektyw (views) i abstrakcji proceduralnych takich jak operacje aktualizacyjne, metody, zapamiętane procedury i reguły. Jest prawdopodobne, że w następnych wersjach standardu wady te zostaną usunięte (przynajmniej częściowo). Wydaje się, że zauważalny brak nacisku na rozwój OQL wynika z (kontrowersyjnego i niejawnego) założenia twórców standardu ODMG, że zasadniczo programowanie aplikacji z obiektową bazą danych powinno odbywać się w językach C++, Smalltalk lub Java. Poniżej znajduje się kilka przykładów w OQL.

Operator select wewnątrz from:

select struct( w: x.wiek, p: x.płeć )

from (select y from Pracownicy as y where y.gr_zawodowa = 10) as x

where x.nazwisko = "Nowak"

Zależne złączenie:

select s.nazwisko, w.nazwa_wykładu from Studenci as s, s.zapisany_na as w

Złożone warunki i złączenia:

select d.adres

from Osoby as x, x.dzieci as d

where x.adres.ulica = "Chrobrego"

and count(x.dzieci) >= 2 and d.adres.miasto != x.adres.miasto

http://www.odmg.org

Oracle-8 Nowa wersja Oracle, relacyjnego systemu zarządzania bazą danych, wprowadzająca niektóre elementy obiektowości. Oracle-8 wprowadza takie cechy jak: duże obiekty (BLOB-y, CLOB-y, pliki binarne), typy obiektów, kolekcje, typy referencyjne, zewnętrzne procedury jako metody obiektów, obiektowe perspektywy, szybką nawigację pomiędzy obiektami, narzędzia do modelowania i rozwijania obiektowych aplikacji, wspomaganie dla niestrukturalnych danych (obrazów, wideo, tekstu, itd.) oraz wspomaganie dla programowania w Java. Oracle-8 jest częściowo oparty na (tworzonym) standardzie SQL3 w zakresie składni do konstruowania i modyfikacji typów obiektów, generowania i przechowywania identyfikatorów obiektów, tworzenia referencji lub wskaźników prowadzących do obiektów oraz modelowania kolekcji podobnych obiektów.

http://www.oracle.com/

http://tiburon.us.oracle.com/

ORB (Object Request Broker) Wg standardu OMG CORBA, pośrednik umożliwiający ujednolicony dostęp do obiektów na wysokim poziomie abstrakcji, abstrahujący od geograficznego rozproszenia obiektów i sposobu ich fizycznej implementacji. Niektórzy autorzy używają akronimu ORB i terminu pośrednik (broker) jako ogólne określenie dowolnego obiektowego oprogramowania pośredniczącego (middleware), np. technologii DCOM lub systemów rozproszonych opartych o Internet. Wg standardu CORBA, centralnym składnikiem ORB jest jego rdzeń (ORB core), który zajmuje się całą infrastrukturą niezbędną do identyfikacji i zlokalizowania obiektów, nawiązywaniem połączeń w sieci oraz dostarczaniem danych. Klienci komunikują się z rdzeniem ORB poprzez pniaki (stubs) generowane z wyrażeń języka opisu interfejsu IDL. Pniaki są fragmentami oprogramowania, które są statycznie wiązane do aplikacji klienta. Oprócz tego, ORB umożliwia wołania dynamiczne poprzez tzw. interfejs wołań dynamicznych (Dynamic Invocation Interface, DII). Z drugiej strony, ORB dostarcza zlecenia klientów do implementacji obiektów. Odbywa się to poprzez szkielety (skeletons), które są również generowane z wyrażenia IDL i następnie uzupełniane poprzez kod implementacji metod, oraz poprzez adapter obiektów (Object Adapter), który dostosowuje interfejs specyficzny dla implementacji obiektów na interfejs bardziej abstrakcyjny oczekiwany przez klienta. Patrz też: CORBA.

http://www.omg.org

ORBeline Pośrednik wymiany obiektów (ORB) wg standardu OMG CORBA, rozwijany i rozpowszechniany przez firmę Post Modern.

Orbix Pośrednik wymiany obiektów (ORB) zgodny ze standardem OMG CORBA, rozwijany i rozpowszechniany przez firmę IONA. Orbix jest prawdopodobnie najbardziej zgodną i kompletną implementacją standardu CORBA. Jest on systemem szeroko stosowanym, w szczególności w obiektowych SZBD. Orbix posiada wbudowane możliwości zintegrowania obiektów CORBA z WWW.

http://www.iona.ie/products/

OrbixWeb Beta wersja systemu Orbix współpracująca z Java i protokołem IIOP.

http://www.iona.ie/products/

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

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

ORDBMS (Object-Relational Data Base Management System) Obiektowo-relacyjny system zarządzania bazą danych; patrz: obiektowo-relacyjny.

organizacja gron (clustering) Metody organizacji zbiorów danych polegające na tym, że semantycznie związane dane (np. połączone poprzez wskaźniki) są ulokowane w bezpośrednim sąsiedztwie na nośniku zewnętrznym (np. na dysku). Dzięki temu minimalizuje się czas transmisji danych z dysku do pamięci operacyjnej i odwrotnie.

ORSZBD Obiektowo-Relacyjny System Zarządzania Bazą Danych (Object-Relational Database Management System, ORDBMS). Patrz: obiektowo-relacyjny.

ortogonalna trwałość (orthogonal persistence) Koncepcja lub zasada, zgodnie z którą cecha trwałości obiektu powinna być całkowicie ortogonalna w stosunku do jego typu. Np. baza danych może przechowywać pojedyncze (atomowe) zmienne, zaś zmiennymi lokalnymi procedury mogą być relacje. Ortogonalna trwałość oznacza ujednolicenie środków dostępu i manipulacji trwałymi i ulotnymi danymi (obiektami). Koncepcja ortogonalnej trwałości, jakkolwiek naturalna zarówno z koncepcyjnego jak i z technicznego punktu widzenia, wzbudza obiekcje ze strony twórców systemów baz danych (w tym obiektowych), głównie z tego powodu, że zostały one zaprojektowane bez uwzględnienia tej cechy.

ortogonalność (orthogonality) Zasada dobrego konstruowania języków i systemów oznaczająca nie łączenie pod wspólną czapką syntaktyczną wielu niezależnych od siebie cech. Zasada ta umożliwia znaczne zmniejszenie rozmiaru specyfikacji języka, zwiększenie jego mocy, uproszczenie implementacji oraz zmniejszenie czasu uczenia. Zasada ta wyraża się prostym zdaniem: “Niech rzeczy niezależne pozostaną niezależne” (keep unrelated things unrelated). Zasady ortogonalności nie spełnia SQL, gdyż bazuje na dużym syntaktycznym zlepku wielu operatorów.

ortogonalny (orthogonal) Wzajemnie niezależny, dobrze oddzielony, dający się dowolnie łączyć. Czasami ortogonalny oznacza nierelewantny, nie mający znaczenia dla danej rzeczy lub problemu. Cechy (języka, systemu, interfejsu, itd.) są ortogonalne, jeżeli posiadają odrębne, niezależne od siebie definicje oraz możliwe jest dowolne ich kombinowanie, łączenie lub zanurzanie. Język jest ortogonalny, jeżeli różne jego semantyczne konstrukcje nie są wiązane ze sobą poprzez składnię (można je używać niezależnie i dowolnie ze sobą kombinować). Termin „ortogonalny” pochodzi z matematyki, gdzie oznacza niezależność pewnej cechy od innej cechy.

OS (Object Services) Patrz: usługi obiektowe.

OSA (Object-oriented System Analysis) Obiektowa metodyka analizy i projektowania systemów informatycznych zaproponowana przez D.W. Embley’a i innych.

http://osm7.cs.byu.edu/OSA/tutorial.html

http://osm7.cs.byu.edu/

OSF (Open Software Foundation) Organizacja i fundacja powołana przez kilku czołowych producentów oprogramowania (Apollo, DEC, HP, IBM, Bull, Nixdorf, Philips, Siemens i Hitachi), której celem jest opracowanie i wypromowanie jednolitego systemu operacyjnego i interfejsów (opartych na idei systemów UNIX, systemu X Windows, itd.), który byłby wspólny dla szerokiej gamy różnych architektur sprzętowych. Efektem działalności fundacji jest m.in. propozycja rozproszonego systemu operacyjnego DCE (Distributed Computing Environment).

http://www.dstc.edu.au/AU/research_news/dce/dce.html

osłona (wrapper) Obiekt, zestaw obiektów lub oprogramowanie zapewniające obiektowy interfejs do nieobiektowego oprogramowania lub nieobiektowej bazy danych, np. tzw. spadkowych (legacy) baz danych. Terminu tego używa się również dla oznaczenia oprogramowania dokonującego (wirtualnego) odwzorowania informacji niestrukturalnej (np. tekstów prezentowanych na stronach WWW) na pewien strukturalizowany format (np. obiekty z atrybutami).

osłonowanie (wrapping) Tworzenie osłon, np. do oprogramowania spadkowego. Patrz: osłona.

OSMOS Obiektowo-relacyjny system zarządzania bazą danych zrealizowany przez firmę Unisys Corporation.

http://www.marketplace.unisys.com/urep/osmos/

http://www.osmos.com/

OSQL (Object SQL) Obiektowe rozszerzenie języka SQL zaimplementowane w systemie Iris firmy HP.

OSZBD (ODBMS, OODBMS) Patrz: obiektowy system zarządzania bazą danych.

OTM (Object Transaction Monitor) Obiektowy monitor transakcji. Synonim, lub generalizacja terminu ORB (Object Request Broker). OTM jest określeniem przyszłego oprogramowania pośredniczącego (middleware), które będzie łączyć krytyczne cechy monitorów przetwarzania transakcyjnego (TP monitors) (takie jak: niezawodność, duża przepustowość, przewidywalny czas odpowiedzi, integralność transakcji, zbalansowanie obciążenia i łatwość zarządzania) z interfejsami obiektowymi oferowanymi poprzez pakiety ORB.

otoczenie (environment) Patrz: środowisko.

otwarta skrzynka (open box) Termin wiązany z ponownym użyciem (reuse), oznaczający taki aktyw ponownego użycia, który można użyć po rozpoznaniu i ewentualnej zmianie wewnętrznej zawartości.

otwarty system (open system) Termin (ostatnio rzadziej używany) oznaczający możliwości współdziałania danego systemu z innymi systemami oraz możliwości pracy w sieciach komputerowych oraz integrację różnych platform sprzętowych, systemów operacyjnych, języków programowania i systemów zarządzania bazami danych. Niekiedy tym terminem określa się także łatwość rozbudowy systemu o owe funkcje.

P Q

pakiet (package) W niektórych językach programowania (np. Ada) synonim modułu lub abstrakcyjnego typu danych. Powszechnie termin ten oznacza pewien spójny zestaw wzajemnie powiązanych procedur, klas lub innych elementów programistycznych przeznaczonych do realizacji określonego celu.

paradygmat programowania (programming paradigm) Określenie podstawowego stylu i technik, oraz wspomagających je konstrukcji danego języka programowania. Paradygmat proceduralny (procedural) lub imperatywny (imperative) oznacza, że program jest sekwencją instrukcji zmieniających stan zmiennych programu, stan obiektów, stan bazy danych, stan urządzeń wejściowo/wyjściowych, itd. (np. Pascal lub C). Paradygmat deklaracyjny (declarative) oznacza bezpośrednie formułowanie celu przetwarzania, a nie akcji prowadzących do tego celu (np. Prolog lub języki zapytań). Paradygmat funkcjonalny (functional) oznacza język, w którym programowanie polega na używaniu funkcji operujących na wartościach i zwracających wartości (np. Lisp lub ML). Paradygmaty deklaracyjny i funkcjonalny ze względu na brak pojęcia stanu wymagają wspomagania konstrukcjami proceduralnymi. Programowanie obiektowe uważane jest niekiedy za samodzielny paradygmat programowania, ale częściej jest postrzegane jako odmiana paradygmatu proceduralnego (np. R. Martin uważa, że obiektowość wniosła radykalny postęp do analizy i projektowania, ale bardzo małą zmianę do stylu programowania; podobne zdanie ma B. Stroustrup). Inny podział paradygmatów programowania jest zorientowany na styl definicji języka. Rozróżniana jest rodzina języków BCPL (włączająca C i C++) korzeniami tkwiąca w ulepszaniu assemblera, rodzina języków takich jak Lisp, ML, Smalltalk i CLU, które są pochodną spekulacji teoretycznych (w tym formalnych) oraz rodzina języków Algolo-podobnych, takich jak Pascal, Ada, Modula-2, Modula-3 i Oberon. Należy przyznać, że kryteria tego podziału są rozmyte i w gruncie rzeczy oparte na dość powierzchownych cechach, takich jak składnia, słowa kluczowe i jakość kontroli typów.

parametr aktualny (actual parameter) Wyrażenie występujące na miejscu pewnego parametru formalnego procedury, funkcji lub metody, albo wartość parametru obliczona w momencie wywołania procedury, funkcji lub metody. Synonim: argument.

parametr formalny (formal parameter) Nazwa oraz typ parametru metody, funkcji albo procedury określone w ramach jej definicji, deklaracji lub sygnatury.

parametr metody (method parameter) Nazwana wartość, która jest określana w momencie wywołania metody i następnie wykorzystywana wewnątrz jej kodu; np. dla metody ZmieńZarobek parametrem może być wartość liczbowa nazwana NowyZarobek. Istnieje szereg technik i konwencji językowych określania parametrów dla metod; patrz: przekazywanie parametrów.

parametryczny polimorfizm (parametric polymorphism) Patrz: polimorfizm parametryczny.

Pegasus Obiektowy system zarządzania bazą danych firmy Hewlett-Packard, którego intencją jest współdziałanie z innymi systemami, w tym DB2, Informix, Oracle, Sybase, OpenODB i IMS. Pegasus jest oparty na języku zapytań i manipulacji HOSQL (Heterogeneous Object SQL), który jest rozszerzeniem języka OSQL systemu Iris.

Perl-5 Nowa wersja języka Perl wspomagająca programowanie obiektowe.

Persistence Obiektowy system zarządzania bazą danych zrealizowany przez firmę Persistence Software, Inc.

Persistent Java Patrz: PJama.

personifikacja (personification) Przypisywanie obiektom cech ludzkich; synonim: antropomorfizm.

perspektywa (view) W szerszym znaczeniu, obraz pojęciowy danych, który jest przypisany do pojedynczego użytkownika (lub ich grupy) i abstrahuje od danych nieistotnych dla jego działalności. Tak rozumiana perspektywa dokonuje adaptacji (customization) danych dla wygody i/lub przyzwyczajeń użytkownika. W węższym znaczeniu (np. w SQL) perspektywa jest funkcją (procedurą funkcyjną) odwzorowującą zapamiętane dane w dane wirtualne, przy czym (idealistycznie) z punktu widzenia użytkownika dane wirtualne są wyszukiwane i przetwarzane przy pomocy tych samych środków, co dane zapamiętane. Ten ideał zwykle można stosunkowo łatwo osiągnąć dla operacji wyszukiwania, lecz znacznie trudniej dla operacji aktualizacji; patrz: aktualizacja perspektyw. Innym nieco pojęciem jest zmaterializowana perspektywa, czyli dane wyliczone z danych oryginalnych i zapamiętane w bazie danych. Dla takich perspektyw podstawowym problemem jest sprawna aktualizacja zmaterializowanej perspektywy w odpowiedzi na aktualizację oryginalnych danych.

perspektywa bazy danych (database view) Patrz: perspektywa.

perspektywa obiektowa (object view, object-oriented view) Perspektywa zdefiniowana na obiektowej bazie danych, dostarczająca użytkownikowi obraz pojęciowy fragmentu bazy danych w postaci obiektów wirtualnych.

pesymistyczny model transakcji (pessimistic transaction model) Model transakcji zakładający, że prawdopodobieństwo niekorzystnych interferencji transakcji (utraty spójności danych lub przetwarzania wskutek jednoczesnego dostępu do tej samej danej) jest wysokie. W związku z tym każda dana przetwarzana przez transakcję musi mieć założony zamek (lock) uniemożliwiający dostęp do niej przez inne transakcje. Zamki te są zwalniane dopiero wtedy, gdy dana transakcja jest potwierdzona lub zerwana. Pesymistyczny model transakcji prowadzi do problemu zakleszczenia (deadlock).

Phantom Obiektowy, interpretowany język programowania do budowy aplikacji o dużej skali, interakcyjnych i rozproszonych, takich jak np. narzędzia do pracy grupowej. Rdzeń języka bazuje na podzbiorze Modula-3.

pielęgnacja (maintenance) Końcowa faza w cyklu życiowym oprogramowania, w której występują modyfikacje poprawiające (polegające na usuwaniu z oprogramowania błędów popełnionych w fazach wymagań, analizy, projektowania i implementacji), modyfikacje ulepszające (polegające na poprawie jakości oprogramowania), oraz modyfikacje dostosowujące (polegające na dostosowaniu oprogramowania do zmian zachodzących w środowisku jego pracy lub nowych wymagań użytkowników). Faza pielęgnacji oprogramowania jest jedną z najważniejszych i najbardziej kosztownych; niektóre oceny szacują koszty pielęgnacji na 90% ogólnych kosztów wytworzenia oprogramowania. Istnieje tendencja nie doceniania kosztów związanych z tą fazą.

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

pielęgnacyjność (maintainability) Ocena stopnia, w jakim dane oprogramowanie jest podatne na pielęgnację lub ocena potencjalnych kosztów pielęgnacji; patrz: pielęgnacja.

pierwsza postać normalna (first normal form, 1NF) Reprezentacja danych, zgodnie z którą wszystkie dane są zapisane w postaci tablic (relacji) o określonej liczbie kolumn i nieokreślonej liczbie wierszy. Elementy tablic muszą być wartościami atomowymi (bez struktury) i nie mogą być odsyłaczami (pointers) do wierszy tablic. W ramach tablicy wiersze nie mogą się powtarzać. Pierwsza forma normalna jest podstawowym założeniem modelu relacyjnego baz danych i wszystkich systemów relacyjnych. Nie jest ona ortodoksyjnie przestrzegana; dotyczy to np. powtarzania wierszy tablic. Warunek pierwszej postaci normalnej nie jest przestrzegany w nowym standardzie SQL3.

pies (dog) Zwierzę posiadające uzdolnienia do rozpoznawania obiektów rzeczywistych (szczególnie kotów). Patrz też: pointer.

PixScript Obiektowe rozszerzenie języka Postscript; używany do zaawansowanego przetwarzania obrazów.

PJama Nowa wersja języka Java opracowana przez Sun Microsystems Laboratories (poprzednie nazwy Persistent Java i PJava). Podstawową cechą PJama jest możliwość deklarowania trwałych obiektów i ortogonalna trwałość. PJama włącza zmodyfikowaną maszynę wirtualną kompatybilną z JDK firmy JavaSoft oraz prosty model przetwarzania transakcji.

http://www.sunlabs.com/research/forest/opj.main.html

PJava Patrz: PJama.

platforma (platform) Konkretny typ sprzętu wraz z zainstalowanym na nim systemem operacyjnym. Np. Pentium Pro + MS Windows NT4, Sun + Solaris, itd.

plik (file) Ogólnie, nazwany zbiór danych zapamiętany na pewnym nośniku, np. dysku, o dużej lub bardzo dużej wielkości i możliwości rozszerzania (do pewnego stopnia). Zwykle intencją tego terminu jest stosunkowo mały stopień zorganizowania danych, np. plik jest ciągiem bitów, bajtów lub zapisów o sztywnym formacie. W porównaniu do baz danych, pliki charakteryzują się także niższym poziomem ochrony i bezpieczeństwa oraz bardziej prymitywnymi środkami dostępu.

płaski plik (flat file) Prosta organizacja danych, w której plik jest sekwencją zapisów nie posiadających wewnętrznej lub zewnętrznej struktury.

pniak (stub) W terminologii standardu OMG CORBA, wiązany statycznie interfejs znajdujący się po stronie klienta, generowany automatycznie z wyrażenia w języku opisu interfejsów IDL.

http://www.omg.org

pniak RPC (RPC stub) Część aplikacji klienta odpowiedzialna za przekazywanie zleceń odległego wołania procedury i odbieranie wyników.

pochodny (derived) Określenie bytu programistycznego (atrybutu, klasy, asocjacji, itp.), który jest lub może być wyliczony lub wydedukowany z innych bytów.

podejście stosowe (stack-based approach) Podejście teoretyczne i praktyczne do semantyki i konstrukcji obiektowych języków zapytań, które zakłada, że języki zapytań są szczególnym przypadkiem języków programowania. W tym podejściu kluczową rolę odgrywa stos środowisk (environment stack), który jest podstawowym mechanizmem zakresu i wiązania większości popularnych języków programowania. Rolą tego stosu jest określenie zakresów nazw i sposobów ich wiązania oraz wprowadzenie dyscypliny w zakresie alokowania dynamicznych bytów programistycznych, w szczególności lokalnych zmiennych i parametrów procedur. W podejściu stosowym szczególną rolę odgrywają tzw. operatory niealgebraiczne (takie jak selekcja, projekcja/nawigacja, zależne złączenie, kwantyfikatory, itd.), których semantyka opiera się na otwieraniu nowego zakresu na stosie środowisk, na zasadzie podobnej do otwierania tego zakresu przez wywołania procedur. Oparcie semantyki języków zapytań na mechanizmie stosu środowisk umożliwia precyzyjne wyjaśnienie ich własności, ustalenie ich związków z pojęciami obiektowości (klasy, dziedziczenie, hermetyzacja, itd.), oraz ich związków z konstrukcjami imperatywnymi języków programowania. Podejście stosowe daje mocną formalną podstawę dla metod optymalizacji zapytań. Na bazie podejścia stosowego został zaprojektowany i zaimplementowany obiektowy język zapytań SBQL (Stack Based Query Language), stanowiący podstawę interfejsu programistycznego systemu Loqis.

podklasa (subclass) Klasa bardziej wyspecjalizowana, usytuowana niżej w hierarchii dziedziczenia; np. Student jest podklasą klasy Osoba. Pojęcie podklasy włącza aspekt zawierania się zakresów znaczeniowych pojęć; przykładowo, zbiór obiektów Student jest podzbiorem zbioru obiektów Osoba. Innym aspektem jest dziedziczenie inwariantów: podklasa posiada wszystkie inwarianty jej nadklasy (definicje atrybutów, definicje metod, itd.) oraz pewne nowe inwarianty; np. podklasa Student ma wszystkie cechy klasy Osoba, plus atrybuty takie jak NrIndeksu, RokStudiów, itd. W wielu sytuacjach te dwa dość różne aspekty pojęcia podklasy mogą prowadzić do nieporozumień.

podnieść wyjątek (raise exception) Spowodować, wygenerować wyjątek; spowodować obecność danego wyjątku w pewnym środowisku lub rejestrze wyjątków.

podobiekt (subobject) Obiekt będący częścią danego obiektu.

podobny do spaghetti (spaghetti-like) Patrz: spaghetti.

podschemat (subschema) Fragment schematu bazy danych odpowiadający pewnej specyficznej aplikacji lub grupie użytkowników. Zwykle pojęcie podschematu obejmuje nie tylko opis fragmentu danych, ale też sposób, w jaki dane opisywane przez schemat są odwzorowane w dane opisywane przez podschemat. Patrz też: perspektywa.

podstan (substate) W diagramach stanów (np. w UML) dowolny „stan” można rozwinąć na bardziej szczegółowy diagram, w którym występują powiązane składowe tego stanu, czyli „podstany”. Ta terminologia jest jednak nieco niewłaściwa i myląca, gdyż to, co nazywa się tam diagramem stanów, w istocie jest diagramem przepływu sterowania (flowchart). W tym sensie „podstan” jest bardziej szczegółową akcją w ramach akcji nadrzędnej („stanu”); patrz rysunek poniżej.

Przykład stanu i jego podstanów

podstawowy adapter obiektów (Basic Object Adapter, BOA) Patrz: BOA.

podtyp (subtype) Typ podrzędny w stosunku do danego typu. Istnieją dwa kryteria ustalania podtypów: (1) ekstensja (zbiór wszystkich wartości) podtypu zawarta jest w ekstensji typu (np. typ integer jest podtypem typu real); (2) podtyp ma co najmniej tyle samo lub więcej atrybutów (np. typ Student jest podtypem typy Osoba, jeżeli Student zawiera wszystkie definicje atrybutów zawarte w typie Osoba plus ewentualnie nowe atrybuty). Relacja typ/podtyp jest wprowadzana w związku z polimorfizmem inkluzyjnym (inclusion polymorphism) oraz zasadą zamienialności (substitutability).

podzbiór (subset) Część danego zbioru. Terminu tego używa się również dla oznaczenia języka lub systemu o zredukowanych, okrojonych funkcjach (np. „podzbiór języka SQL”).

podział (partition) Podział zakresu znaczeniowego (zbioru obiektów) klasy bardziej ogólnej na podzakresy znaczeniowe (podzbiory obiektów) jej podklas.

podział kompletny (complete partition) Sytuacja, w której suma zakresów znaczeniowych podklas jest taka sama, jak zakres znaczeniowy nadklasy. Np. dla klasy Osoba podklasy PłećŻeńska oraz PłećMęska wyznaczają podział kompletny.

podział niekompletny (incomplete partition) Sytuacja, w której suma zakresów znaczeniowych podklas jest mniejsza od zakresu znaczeniowego nadklasy. Np. podklasy Student i Pracownik stanowią niekompletny podział klasy Osoba, ponieważ można w niej wyróżnić obiekty nie będące ani studentem ani pracownikiem.

Poet Obiektowy system zarządzania bazą danych oferowany przez firmę Poet Software oparty o język C++. Poet jest uważany za zgodny ze standardem ODMG, chociaż jak dotąd zaimplementowy został tylko pewien podzbiór języka OQL.

http://www.poet.com

pointer (pointer) Wyżeł angielski o krótkiej połyskującej sierści; dobry węch. Mówiło się onegdaj w staropolszczyźnie: „azaliż Waćpan z pointerą polował, że tyle zajęców?". Po zwietrzeniu zwierzyny pointer staje jak wryty i podniesioną, lekko zgiętą łapką wskazuje myśliwemu interesujący go obiekt. Jest niewłaściwe zachwaszczanie obiektowej mowy neofickim słowem wskaźnik, zamiast stosowania pięknego staropolskiego słowa pointer. Patrz (niestety): wskaźnik.

pojedyncza dyspozycja (single dispatching) Patrz: dyspozycja.

pojedyncze dziedziczenie (single inheritance) Sytuacja, w której każda klasa ma co najwyżej jedną nadklasę.

pojęciowy (conceptual) Odnoszący się do ludzkich wyobrażeń i sposobów myślenia; nie biorący pod uwagę kwestii implementacji komputerowej.

pojęciowy model danych (conceptual data model) Model danych odwołujący się do sposobu myślenia analityka, projektanta, konstruktora oprogramowania; model nie biorący pod uwagę kwestii komputerowej reprezentacji danych. Przykładami modelu pojęciowego są: model encja-związek, model OMT, model UML. Synonim: semantyczny model danych.

pole (field, slot) Fragment obiektu, zapisu, struktury przechowujący pojedynczą wartość. Synonimy: atrybut, wartość atrybutu, zmienna wystąpienia.

pole statyczne (static field) Pole, którego wartość jest wspólna dla pewnego zbioru obiektów, pole niezmienialne, zmienna klasowa, atrybut wspólny.

polimorfizm (polymorphism) Termin używany w dwóch nieco różnych znaczeniach (które są często mylone): (1) w terminologii obiektowej: możliwość istnienia wielu metod o tej samej nazwie, powiązana z możliwością wyboru konkretnej metody podczas czasu wykonania (dynamicznym wiązaniem); (2) w terminologii teorii typów i języków polimorficznych (np. w ML): umożliwienie definiowania funkcji lub procedur, których argumenty i wynik mogą posiadać jednocześnie wiele typów; np. funkcji sort, która może posortować (wg pewnego algorytmu) kolekcję elementów dowolnego typu (o ile określona zostanie metoda porównania elementów). Polimorfizm parametryczny jest często kojarzony z sytuacja określaną jako przypadek typu (typecase), czyli możliwością dynamicznego testowania typu danej wartości lub zmiennej. Powyższe dwa znaczenia pojęcia polimorfizmu są względem siebie ortogonalne: możliwy jest polimorfizm metod w języku nietypowanym (np. Smalltalk), oraz polimorfizm typów w języku nie wprowadzającym wiązania dynamicznego (np. ML).

polimorfizm ad hoc (ad hoc polymorphism) Przypadkowe formy polimorfizmu implementowane w językach programowania (np. przyjęcie zasady, że wszędzie tam, gdzie można użyć wartości typu real, można również użyć wartości typu integer).

polimorfizm inkluzyjny (inclusion polymorphism) Rodzaj polimorfizmu typów, w którym zakłada się istnienie relacji częściowego porządku „jest podtypem” pomiędzy typami; np. typ Student jest podtypem typu Osoba. Polimorfizm inkluzyjny jest ściśle powiązany z zasadą zamienialności (substitutability), która ustala, że o ile w danym miejscu programu można użyć wartości typu A, to w tym samym miejscu można także użyć wartości typu B, o ile B jest podtypem A.

polimorfizm metod (method polymorphism) Możliwość definiowania wielu metod o tej samej nazwie, połączona z możliwością dynamicznego wyboru (wiązania) konkretnej metody podczas czasu wykonania. Polimorfizm metod jest często utożsamiany z przeciążaniem (overloading) i z przesłanianiem (overriding). Niektórzy autorzy (np. Cardelli) uważają, że przeciążanie nie jest polimorfizmem, lecz (specyficzną dla większości języków programowania) homonimią rozstrzygalną poprzez analizę kontekstu jej występowania w tekście programu.

polimorfizm parametryczny (parametric polymorphism) Rodzaj polimorfizmu typów, w którym zakłada się, że typ bytu programistycznego może być parametryzowany innym typem; np. typ tablica (array) jest parametryzowany wartością typu integer oznaczającą rozmiar tablicy. Często polimorfizm parametryczny kojarzy się z sytuacją, kiedy typ parametru pewnej funkcji określa typ jej wyniku.

polimorfizm statyczny (static polymorphism) Patrz: przeciążanie.

polimorfizm typów (type polymorphism) Możliwość deklarowania bytów programistycznych (zmiennych, argumentów, funkcji i innych), których konkretne wystąpienia lub wartości mogą być zgodne z wieloma typami lub różnić się typem. Polimorfizm typów jest uważany za podstawę zdyscyplinowanego i bezpiecznego programowania generycznego (generic). Temat ten pozostaje jednak w strefie akademickiej, ponieważ języki z polimorfizmem typów (w szczególności ML) są uważane za zbyt wyrafinowane dla przeciętnego programisty. Ponadto, polimorfizm typów posiada ograniczenia w stosunku do innych metod programowania generycznego, np. programowania z refleksją.

pomost (gateway) Oprogramowanie umożliwiające dostęp z danego systemu bazy danych do innych (lokalnych lub odległych) baz danych podtrzymywanych przez inny SZBD; np. dostęp do danych podtrzymywanych przez system relacyjny z systemu obiektowego. Pomost powinien zapewniać przezroczystość dostępu (tj. programista nie musi modyfikować programów z powodu dostępu do obcej bazy danych), ale często (najczęściej) ten warunek nie jest spełniony; np. dostęp z systemu obiektowego do systemu relacyjnego jest realizowany explicite poprzez ODBC lub JDBC.

ponowne użycie (reuse) Tworzenie, udostępnianie i wykorzystanie składników projektów, oprogramowania i dokumentacji, które nadają się do wielokrotnego zastosowania w tym samym projekcie lub oprogramowaniu lub w różnych projektach lub oprogramowaniu. Takie składniki nazywają się aktywami (assets) ponownego użycia. Aktywami ponownego użycia są najczęściej składowe oprogramowania, ale mogą być nimi także fragmenty analizy, projektu, dokumentacji technicznej, dokumentacji użytkowej, dokumentacji szkoleniowej, pliki graficzne, ekrany interfejsu użytkownika, formularze, metody testowania, składowe bazy danych, słowniki, katalogi, schematy, itd. Ponowne użycie ma ogromne zalety, wśród nich następujące:

  • Poprawność oprogramowania: przetestowane, już używane składowe oprogramowania zawierają mniej błędów, niż skonstruowane na nowo.
  • Czas tworzenia oprogramowania oraz koszt rozwoju i utrzymania oprogramowania jest znacznie mniejszy.
  • Komponenty ponownego użycia pozwalają na poprawienie łatwości użycia oprogramowania.
  • Jeżeli aktywa mają postać programów realizujących skomplikowane, efektywne algorytmy, ponowne ich użycie zwiększy efektywność całego systemu.
  • Jeżeli aktywa są przenaszalne pomiędzy poszczególnymi platformami, wówczas wzrasta potencjał przenaszalności całego oprogramowania.

Temat ponownego użycia towarzyszył od dawna rozwojowi metod tworzenia oprogramowania, zaś pojęcia takie jak moduł, typ, procedura, makro można uważać za konsekwencję dążenia do wzmocnienia potencjału ponownego użycia. Obiektowość wzmacnia dodatkowo ten potencjał poprzez pojęcia takie jak: klasy, dziedziczenie, hermetyzacja i polimorfizm. Pojęcia te sprzyjają ponownemu użyciu, ale to nie oznacza, ze załatwiają problem w sposób automatyczny. Ponowne użycie nie może być traktowane jako efekt uboczny normalnego procesu tworzenia aplikacji. Wymaga ono konkretnych zabiegów oraz inwestycji zmierzających do wytworzenia w danej firmie lub przedsiębiorstwie kultury ponownego użycia, tj. stanu, w którym twórcy oprogramowania posiadają właściwe motywacje do tworzenia i wykorzystywania aktywów ponownego użycia. Przeszkodą dla zaistnienia kultury ponownego użycia jest brak nawyków i motywacji do starannego wyodrębniania, opisywania, katalogowania i rozpropagowania aktywów ponownego użycia, brak nawyków i motywacji dla ich wykorzystania, oraz zjawisko psychologiczne określane jako syndrom NIH (not-invented-here). Temat ponownego użycia jest ściśle związany z tematem wzorców projektowych.

http://www.asset.com/

http://pebbles.cs.utk.edu/

http://sw-eng.falls-church.va.us/ReuseIC/policy/glossary/glossary.htm

porównanie głębokie (deep comparison) Rekurencyjne porównanie zawartości obiektów, z uwzględnieniem nazw atrybutów i ich wartości. Przy porównaniu głębokim X = Y zmiennych X i Y wynik jest prawdziwy, jeżeli ich aktualne wartości są identyczne. Jeżeli X i Y są pewnymi wyrażeniami zwracającymi identyfikatory obiektów, zaś = jest operatorem porównania głębokiego, wówczas predykat X = Y zwraca wartość boolowską true, jeżeli zestaw atrybutów oraz wartości tak samo nazwanych atrybutów obiektów wskazywanych przez X i Y są takie same; w przeciwnym przypadku zwraca false. W przeciwieństwie do porównania płytkiego, identyfikatory zwracane przez X i Y mogą być różne; w porównaniu głębokim chodzi o identyczność zawartości informacyjnej obiektów. Jeżeli atrybuty obiektu są złożone, porównanie ma charakter rekurencyjny, z uwzględnieniem nazw podatrybutów. Porównanie głębokie może być trudne do jednoznacznego zdefiniowania, jeżeli obiekty zawierają wskaźniki do innych obiektów, gdyż powstaje problem, jak głęboko należy posuwać się w rekurencyjnym porównywaniu. Z tego powodu może być kilka różnych operatorów porównania głębokiego. Języki programowania, np. Java, stosują porównanie głębokie dla typów prymitywnych, natomiast porównanie płytkie dla obiektów; może to tworzyć pewne semantyczne pułapki dla programistów. Patrz także: porównanie płytkie.

porównanie płytkie (shallow comparison) Porównanie identyfikatorów obiektów (referencji) poprzez operator równości. Jeżeli X i Y są pewnymi wyrażeniami zwracającymi identyfikatory obiektów (referencje), zaś = jest operatorem porównania płytkiego, wówczas predykat X = Y zwraca wartość boolowską true, jeżeli identyfikatory zwracane przez X i Y są identyczne (tj. wskazują na ten sam obiekt); w przeciwnym przypadku predykat zwraca false.

postać normalna Boyce-Codda (Boyce-Codd Normal Form, BCNF) Relacja jest w BCNF, jeżeli każdy jej determinant (atrybut lub zestaw atrybutów będący argumentem funkcji w zależności funkcyjnej) jest kluczem kandydującym. BCNF jest mocniejszym warunkiem od 3NF. Mogą istnieć relacje, których nie uda się zdekomponować do postaci BCNF. BCNF jest mało praktycznym produktem teorii normalizacji baz danych. Znaczenie tej postaci normalnej dla rzeczywistego projektowania baz danych jest marginalne.

Postgres System zarządzania bazą danych opracowany na uniwersytecie w Berkeley oparty na modelu określanym jako „rozszerzony relacyjny”. Postgres wprowadza niektóre cechy obiektowości, większy jednak nacisk jest położony na rozszerzenie struktur danych o elementy aktywne, takie jak procedury, perspektywy i reguły.

http://www.postgresql.org/index.html

postrelacyjny (post-relational) Określenie systemu, który rozszerza założenia modelu relacyjnego; patrz też: obiektowo-relacyjny.

pośredni przodek (indirect ancestor) W hierarchii klas nadklasa w stosunku do danej klasy, która jest oddzielona od niej inną klasą.

pośrednik (broker) Termin OMG CORBA, inaczej ORB. Patrz: ORB.

http://www.omg.org

pośrednik zleceń obiektowych (Object Request Broker, ORB) Patrz: ORB.

potwierdzenie (commit) W przetwarzaniu transakcji jej faza końcowa, w której następuje fizyczne naniesienie zmian spowodowanych przez transakcję do bazy danych, odblokowanie wszelkich zablokowanych przez transakcję zasobów, skasowanie informacji z dziennika (log) transakcji, oraz usunięcie identyfikatora transakcji z rejestru aktualnie przetwarzanych transakcji.

potwierdzenie transakcji (transaction commit) Patrz: potwierdzenie.

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

http://www.expertsoft.com

powiązanie (link) Wskaźnik umieszczony w jednym obiekcie i prowadzący do innego obiektu; patrz przykład poniżej. W metodykach projektowania uważa się, że pojęcie powiązania jest na wyższym poziomie abstrakcji niż pojęcie wskaźnika; jest to pewna abstrakcyjna „nitka” (niekiedy posiadająca więcej niż dwa końce) łącząca obiekty. Końce takich nitek są oznaczone nazwami ról. Powiązanie jest wystąpieniem związku lub asocjacji. Patrz też: asocjacja.

Powiązania pomiędzy obiektami

powiązanie dwukierunkowe (bidirectional link) Powiązanie umożliwiające przechodzenie (nawigację) od jednego obiektu do drugiego obiektu, i odwrotnie.

powiązanie jednokierunkowe (unidirectional link) Powiązanie umożliwiające przechodzenie (nawigację) od jednego obiektu do drugiego obiektu, ale nie odwrotnie.

powiązanie pochodne (derived link) Powiązanie, które jest (lub może być) wyprowadzone z innych powiązań i/lub atrybutów.

powiązanie wskaźnikowe (pointer link) Nazwany wskaźnik (pointer) umieszczony w danym obiekcie i prowadzący do innego obiektu

powszechny model obiektowy (COM, Common Object Model) Patrz: COM.

półkrata (semi-lattice) Pojęcie matematyczne; krata, w której istnieje dokładnie jeden kres górny, ale może nie istnieć pojedynczy kres dolny. Półkrata jest teoretycznym stereotypem struktury klas z wielodziedziczeniem; ta analogia jest jednak dość płytka i jałowa.

półstrukturalne (semi-structured) Patrz: dane półstrukturalne.

późne wiązanie (late binding) Patrz: wiązanie dynamiczne.

pragma (pragma) Komentarz o ustalonym formacie, który jest rozpoznawany przez kompilator i może być użyty dla specjalnych celów, np. do optymalizacji programu. Również umożliwienie w języku wysokiego poziomu bezpośredniej kontroli programu lub danych na niskim poziomie (pragma fizyczna).

prawo Demetera (Law of Demeter) Zasada lub zalecenie mające na celu minimalizację ilości komunikatów i zwiększenia kohezji wewnątrz klas. Mówi ono, że dany obiekt może wysłać komunikat wyłącznie do takiego obiektu, którego referencja znajduje się wewnątrz tego obiektu; inaczej, obiekt może wysłać komunikat do obiektu, z którym jest połączony pewnym powiązaniem (link).

predykat (predicate) Określenie warunku (wyrażenia boolowskiego) występującego np. po słowie kluczowym where w językach zapytań takich jak SQL i OQL. Istotą predykatu jest selekcja elementów należących do pewnej kolekcji.

prekompilator (precompiler) Program (z reguły dość prosty) dokonujący wstępnej obróbki tekstów programów, np. rozwinięć użytych makro, zamiany zdań języka zapytań na wołania procedur, zamiany stałych symbolicznych na konkretne wartości, itp. Patrz też: zanurzony.

PRESTO Środowisko bazujące na C++ dla pisania obiektowych równoległych programów w C++.

http://www.netlib.org/presto/index.html

procedura (procedure) Nazwana operacja lub nazwany kod, która nie zwraca wartości. W odróżnieniu od niej, funkcja zwraca pewną wartość (ale używa się także terminu procedura funkcyjna (functional procedure)).

procedura bazy danych (database procedure) Patrz: zapamiętana procedura.

procedura funkcyjna (functional procedure) Procedura zwracająca wartość, dzięki czemu jej wywołanie może być użyte jako wyrażenie.

proceduralny (procedural) Określenie języka lub paradygmatu programowania opierającego się o sekwencje instrukcji, które kolejno są wykonywane przez komputer powodując zmianę stanu programu oraz efekty zewnętrzne.

proces (process) Wykonywany program lub sekwencja czynności. Intencją tego pojęcia jest autonomiczne sterowanie ustalające przebieg procesu, oraz fakt, że wykonuje się on równolegle z innymi procesami. W terminologii systemów operacyjnych i niektórych języków programowania (np. Ada), proces jest bytem programistycznym, dla którego przeznacza się określone zasoby (czas komputera, pamięć, dane), który funkcjonuje niezależnie od innych równolegle działających procesów, i który podlega synchronizacji, tj. przydzielaniu lub podziałowi zasobów krytycznych (wspólnych dla wielu procesów), takich jak pamięć, klawiatura, ekran, porty, itd.

proces iteracyjny (iterative process) Proces zakładający powtórzenia pewnych czynności.

program aplikacyjny (application program) Program należący do pewnej aplikacji, mający bezpośrednich użytkowników w określonej dziedzinie przedmiotowej.

programowanie dynamiczne (dynamic programming) Programowanie z użyciem dynamicznego SQL; programowanie z użyciem techniki refleksji.

programowanie generyczne (generic programming) Technika tworzenia programów operujących nie na konkretnej strukturze danych, ale na szerokiej rodzinie takich struktur. Przykładami programów generycznych są: program sortujący dowolną listę, program tłumaczący dowolny program w języku Pascal na program w C, program przeglądania tablic w bazie danych, w którym nazwa tablicy jest parametrem wczytywanym z klawiatury, itp. Programowanie generyczne sprzyja ponownemu użyciu (reuse). Wiele języków programowania (np. Pascal) nie jest przystosowanych do tego typu programowania. Znanych jest kilka technik programowania generycznego, np.: przejście na niższy poziom językowy (np. assemblera) poprzez operatory konwersji typu, polimorfizm powiązany z procedurami wyższego rzędu (procedurami z parametrami będącymi procedurami), klasy parametryzowane (szablony) oraz wykorzystanie refleksji (reflection) (np. w dynamicznym SQL).

programowanie obiektowe (object-oriented programming) Programowanie, zwykle w obiektowym języku programowania, w którym występuje wyodrębnienie obiektów (jako bytów programistycznych), ich klas oraz metod. Istnieje bardzo wiele języków służących do programowania obiektowego, m.in. SIMULA-67, Smalltalk, C++, Object Pascal, Objective C, DRAGOON, BETA, Emerald, POOL, Eiffel, Self, Oblog, ESP, POLKA, Loops, Java.

http://zgdv.igd.fhg.de/papers/se/oop/

http://cuiwww.unige.ch/Chloe/Ooinfo

http://iamwww.unibe.ch/~scg/Ooinfo/FAQ/

programowanie obiektowe wyższego rzędu (higher-order object-oriented programming) Programowanie obiektowe z użyciem typów polimorficznych i funkcji wyższego rzędu; programowanie obiektowe z użyciem techniki refleksji.

programowanie sterowane zdarzeniami (event-driven programming) Patrz: sterowane zdarzeniami.

programowanie wizyjne (visual programming) Technika i narzędzia programistyczne zapewniające komponowanie interfejsu użytkownika i oprogramowania użytkowego z graficznych elementów widocznych na ekranie komputera (przeważnie metodą „przesuń i upuść”, drag and drop). Przykładami narzędzi programowania wizyjnego są: środowisko języka Smalltalk, VisualBasic, IBM VisualAge i CA OpenRoad.

programowanie wyższego rzędu (higher-order programming) Programowanie z użyciem typów polimorficznych i funkcji wyższego rzędu; programowanie z użyciem techniki refleksji.

programowanie zdarzeniowe (event-driven programming) Patrz: sterowane zdarzeniami.

projekcja (projection) Operator algebry relacji lub języka zapytań implementowany w relacyjnych językach zapytań. Operator ten pozwala wyprodukować z zadanej tablicy nową tablicę o zmniejszonej liczbie kolumn. W języku SQL parametry operacji projekcji następują bezpośrednio po słowie kluczowym „select”. Określenie „projekcja” jest także stosowane w bardziej ogólnym sensie (m.in. w obiektowych językach zapytań), jako operacja selekcji atrybutu (atrybutów) z pewnych obiektów lub operacja polegająca na obliczaniu pewnego wyrażenia, którego argumentami są nazwy atrybutów obiektów.

projektowanie (design) Przedmiot lub dziedzina dowolnej inżynierii (w tym inżynierii oprogramowania) zajmująca się wyspecyfikowaniem pewnego wytworu. Jakościowy projekt powinien spełniać cele i kryteria funkcjonalne danego wytworu, jak również uwzględniać wszelkie ograniczenia na wytwór (maksymalny koszt, wydajność, niezawodność, ergonomia, sprzęt, zasoby, czas reakcji, obowiązujące standardy, itd.). Metody projektowanie powinny także uwzględniać własne ograniczenia procesu projektowego, np. maksymalny koszt i czas projektowania, stosowane narzędzia, dostępna kadra, itd.

projektowanie logiczne (logical design) Tworzenie schematu danych (zawartych w bazie danych) zgodnie z regułami syntaktycznymi i semantycznymi konkretnego systemu zarządzania bazą danych (lub pewnej klasy systemów); np. projektowanie schematów relacyjnych w SQL lub schematów obiektowych w ODL. Podstawą projektu logicznego jest projekt pojęciowy zapisany np. w postaci diagramów encja-związek lub pojęciowych diagramów klas obiektów.

projektowanie obiektowe (object-oriented design, OOD) Patrz: obiektowe projektowanie.

projektowanie przez kontrakty (design by contracts) Metoda zaproponowana przez Bertranda Meyera (twórcę języka Eiffel), która traktuje konstruowanie oprogramowania jako proces oparty na kontraktach pomiędzy klientem (np. wołaniem procedury) i dostawcą (np. procedurą). Metoda zakłada określenie wzajemnych zobowiązań pomiędzy klientem i dostawcą. Opiera się na definiowaniu pewnych warunków (asercji), w szczególności inwariantów (invariants), warunków wstępnych (preconditions) i warunków końcowych (postconditions). Patrz też: BON.

http://www.eiffel.com/doc/manuals/technology/contract/index.html

projektowanie wspomagane komputerem (Computer Aided Design, CAD) Dziedzina niestandardowych zastosowań komputerów; potencjalne pole zastosowań obiektowych baz danych.

protokół (protocol) Ogólnie, sposób lub algorytm przekazywania lub przesyłania danych. W obiektowości termin ten oznacza niekiedy sposób, w jaki obiekt reaguje na przesyłane do niego komunikaty.

prototyp [1] (prototype) Obiekt, którego własności (np. atrybuty wraz z wartościami lub metody) są importowane (dziedziczone) przez inne obiekty. Prototyp posiada własności klasy, ale odnosi się bardziej do poziomu realizacyjnego niż pojęciowego. Przykładem języka opartego o koncepcję prototypów jest Self. Poniżej znajduje się przykład prototypu ULUBIENIEC, z którego dziedziczą obiekty PIES i KOT. Prototyp może być także używany do tworzenia nowych obiektów na zasadzie klonowania. Prototyp koncepcyjnie jest równoważny pojęciu klasy, ale umożliwia dziedziczenie dynamiczne, w ramach wystąpień obiektu, przez co struktura obiektowa jest bardziej elastyczna. W szczególności, bez trudu można odłączać obiekty od ich prototypu i przyłączać do innego prototypu.

Udostępnienie informacji z prototypu ULUBIENIEC

prototyp [2] (prototype) Wstępna, próbna, uproszczona, ale działająca wersja projektowanego systemu informatycznego.

prywatny (private) Określenie własności obiektu, która jest hermetyzowana, ukryta, niewidoczna z zewnątrz. Własność prywatna jest dostępna wyłącznie dla metod przypisanych do tego obiektu (w C++ również dla klas zaprzyjaźnionych).

przechwycenie wyjątku (catch an exception, exception catch) Rozpoznanie wyjątku, uruchomienie czynności obsługi wyjątku (bloku reakcji na wyjątek) oraz „skonsumowanie” tego wyjątku (usunięcie go ze środowiska).

przeciążanie (overloading) Sytuacja, w której ta sama nazwa (lub symbol) jest użyta do oznaczenia dwóch lub więcej funkcji (procedur, operatorów lub metod), zaś rozstrzygnięcie tej homonimii następuje na podstawie kontekstu jej użycia (np. typu lub liczby argumentów operacji).

przedmiot rozważań (universe of discourse, UoD) Patrz: dziedzina problemu.

przeglądanie (browsing) Przeglądanie struktury klas, atrybutów, obiektów, powiązań, itd., zwykle przy pomocy specjalnego oprogramowania zwanego przeglądarką. (Termin homonimiczny z przeglądaniem stron WWW.)

przeglądarka (browser) Oprogramowanie umożliwiające przeglądanie struktury klas, atrybutów, obiektów, powiązań, itd. (Termin homonimiczny z przeglądarkami stron WWW.)

przejście (transition) Inaczej zmiana stanu powodowana przez pewien sygnał lub zdarzenie.

przekazywanie parametrów (parameter passing) Przekazywanie wartości lub wyrażeń użytych w wołaniu procedury (funkcji, metody) do środowiska wykonania procedury (funkcji, metody). Istnieje kilka technik przekazywania parametrów; największą popularność zdobyło tzw. wołanie przez wartość (call-by-value), gdzie przekazywana jest wartość, oraz tzw. wołanie przez referencję (call-by-reference), gdzie przekazywana jest referencja do zmiennej lub obiektu. Pewną popularność (w kontekście optymalizacji) zdobyły także techniki określane jako wołanie przez nazwę (call-by-name), w istocie oparte na koncepcji makro-definicji, oraz wołanie poprzez potrzebę (call-by-need) (zwaną też inaczej „leniwym wartościowaniem”, lazy evaluation).

przemiana wskaźników (pointer swizzling) Technika implementacji obiektowych baz danych polegająca na tym, że w buforze obiektów (w pamięci operacyjnej) następuje zamiana trwałych wskaźników (identyfikatorów obiektów) prowadzących do obiektów przechowywanych w bazie danych na wskaźniki danego języka programowania (np. C++), prowadzące do kopii tych obiektów w pamięci operacyjnej. Technika ta, w porównaniu do relacyjnych baz danych, pozwala na podwyższenie wydajności niektórych aplikacji nawet tysiąckrotnie.

przenaszalność (portability) Własność języka programowania umożliwiająca przenoszenie programów napisanych w tym języku na różne platformy sprzętowe, pracujące pod różnymi systemami operacyjnymi. Przenaszalność wymaga bardzo precyzyjnego wyspecyfikowania składni i semantyki języka, oraz wyeliminowania z niego wszelkich własności specyficznych dla poszczególnych platform. Przenaszalność jest podstawowym celem standardyzacji, ale wiele standardów nie spełnia tego kryterium z powodu niedospecyfikowania wszystkich własności (szczególnie semantyki), lub niekompletności pragmatycznej języka powodującej dowolne, niestandardowe rozszerzenia. Przykładem może służyć SQL-92, gdzie ponad 90% programów „zgodnych” z tym standardem nie daje się przenieść na inne platformy. Przenaszalność jest celem standardu C++, ale - zdaniem komitetu ANSI powołanego do stworzenia tego standardu - jest to cel, który będzie bardzo trudny do osiągnięcia z powodu bagażu niskiego poziomu odziedziczonego z C. Przenaszalność jest także celem standardów OMG CORBA oraz ODMG, ale sytuacja jest tu podobna do sytuacji z C++: są to jak dotąd pobożne życzenie, a nie realnie osiągnięta własność. Bardzo dobrze przenaszalność realizuje język Java, który nie jest kompilowany do poziomu sprzętowego, a do poziomu pewnego interpretera (zwanego maszyną wirtualną), co daje możliwość uniezależnienia się od konkretnej platformy realizacyjnej. Należy jednak zdawać sobie sprawę, że dotyczy to bardzo ograniczonych funkcjonalności (programowania stron WWW), gdzie skala problemu jest znacznie mniejsza.

przepisywanie (rewriting) Określenie grupy metod optymalizacji zapytań (ogólnie: programów), w których dokonuje się semantycznie równoważnego przekształcenia tekstu zapytania (lub pewnej jego wewnętrznej reprezentacji, np. drzewa syntaktycznego) na taką równoważną semantycznie postać, która rokuje lepszy czas wykonania. Do metod opartych na przepisywaniu należą popularne metody optymalizacji relacyjnych języków zapytań (w tym SQL) polegające na: przesuwaniu selekcji i projekcji przed złączenie, wyciąganiu (factoring out) pewnych podzapytań przed pętlę iteracyjną (np. przed operator where), zamianie zagnieżdżonych zapytań na nie zagnieżdżone, usuwaniu martwych członów zapytań, optymalizacji zapytań odwołujących się do perspektyw techniką określaną jako modyfikacja zapytań (query modification), itd.

przepływ danych (data flow) Patrz: diagram przepływu danych.

przepływ pracy (workflow) Sterowanie i ulepszanie procesów przedsiębiorczości, ich automatyzacja, śledzenie, oraz umożliwienie lub usprawnienie współpracy zespołów. Przepływ pracy obejmuje także organizację operacyjnych aspektów przedsiębiorczości - sekwencję zadań, organizację podmiotów je wykonujących, sterowanie przepływem informacji wspomagającej realizację tych zadań, oraz mechanizmy śledzenia i raportowania, które mierzą i kontrolują wykonanie zadań. Oprogramowanie przepływu pracy ma za zadanie usprawnić procesy przedsiębiorczości poprzez automatyzację następujących aspektów:

  • przekazywanie czynności do wykonania w ramach danego procesu, zgodnie z określoną ich sekwencją;
  • zapewnienie dostępu do danych i dokumentów wymaganych przez te czynności;
  • śledzenie wszystkich aspektów związanych z wykonaniem procesu.

Głównym celem narzędzi do zarządzania przepływem pracy jest umożliwienie wyodrębnienia i ewentualnej dynamicznej modyfikacji logiki procesów biznesowych wykonywanych w przedsiębiorstwie. Ta logika jest oddzielona od logiki zadań wykonywanych w ramach aplikacji użytkowych, takich jak obsługa interfejsu użytkownika i dostęp do bazy danych. Przepływy pracy są przedmiotem działań standardyzacyjnych w ramach konsorcjum Workflow Management Coalition.

http://www.aiim.org/wfmc/

http://www.insead.fr/CALT/Encyclopedia/ComputerSciences/Groupware/Workflow

http://www.gold.net/users/ef48/index.html

przepływ sterowania (control flow) Przesuwanie się umownego, wyobrażalnego punktu (zwanego sterowaniem) wzdłuż kodu programu podczas jego analizy lub wykonania. Przesunięcie się tego punktu do danej instrukcji kodu oznacza uruchomienie wykonania tej instrukcji. W językach niskiego poziomu tym punktem jest stan licznika (rejestru) rozkazów. W językach wysokiego poziomu sterowanie przepływa (w wyobraźni programisty) wzdłuż instrukcji wysokiego poziomu, wywoływanych metod, procedur, itd. Niekiedy (w programach współbieżnych, wielowątkowych lub w językach zapytań) sterowanie może „rozszczepić się” na dwa lub więcej równolegle poruszających się punktów. Terminu „przepływ sterowania” używa się w kontekście diagramów przepływu sterowania (flowcharts) i diagramów stanów (statecharts).

przesłanianie (overriding) Odnosi się do sytuacji, kiedy implementacje funkcji (procedur, operatorów, metod) posiadających tę samą nazwę występują na różnych poziomach hierarchii dziedziczenia (co najmniej dwóch). W tej sytuacji do obiektu stosuje się funkcję znajdującą się najniżej w części hierarchii od korzenia do klasy tego obiektu; pozostałe funkcje o tej samej nazwie (z klas bardziej ogólnych, nadklas) są „przesłonięte” przez tę funkcję. Przesłanianie jest realizacją strategii określanej jako „pojedyncza dyspozycja” (single dispatching) i jest ściśle powiązane z polimorfizmem. Przesłanianie wymaga dynamicznego wiązania i jest jednym z ważnych elementów wspomagających ponowne użycie (reuse).

przestrzeń stanów (state space) Zbiór (zwykle bardzo duży lub nieskończony) wszystkich stanów, w których może znaleźć się obiekt, program, proces, baza danych, itd.

przesunięcie (offset) Przy fizycznej reprezentacji obiektu (lub zapisu) przesunięciem jest liczba bajtów od początku obiektu do miejsca zapamiętania danego atrybutu.

przesyłanie komunikatów (message passing) Technika programowania, w której najpierw wyznacza się obiekt będący przedmiotem przetwarzania, następnie formułuje się wyrażenie („komunikat”) określające operację, która ma być wykonana na obiekcie (operacja może być parametryzowana). Składnia odpowiedniej konstrukcji językowej ma często postać <obiekt>.<funkcja>(<parametry>). Z dokładnością do terminologii, przesyłanie komunikatów jest wywołaniem lokalnej funkcji (procedury, operacji, metody), gdzie obiekt, będący adresatem komunikatu, pełni rolę środowiska wykonania tej funkcji. Przesyłanie komunikatów nie ma nic wspólnego z asynchronicznym (równoległym) komunikowaniem się obiektów. (Nb. jest to bardzo ważny, ale w stosunku do przesyłania komunikatów całkowicie ortogonalny problem.) Niestety, ten nieco niefortunny termin doprowadził do wielu tego rodzaju nieporozumień.

przetwarzanie analityczne on-line (On-Line Analytical Processing, OLAP) Patrz: OLAP.

przetwarzanie transakcji on-line (On-Line Transaction Processing, OLTP) Patrz: OLTP.

przezroczystość (transparency) Termin wprowadzony głównie w związku z systemami rozproszonymi. Oznacza on, że programista lub użytkownik podczas dostępu do odległych danych nie musi interesować się różnorodnością środków dostępu, szczegółami transmisji danych, fizyczną implementacją obiektów, konfiguracją sieci, itd. Z jego punktu widzenia, przetwarzanie odległych heterogenicznych danych nie powinno niczym różnić się od przetwarzania lokalnych danych znajdujących się w jego przestrzeni adresowej. Przezroczystość jest podstawową cechą standardu OMG CORBA. Istnieje wiele rodzajów przezroczystości:

  • przezroczystość dostępu, czyli umożliwienie jednorodnych metod operowania na lokalnych i odległych danych;
  • przezroczystość położenia, czyli uwolnienie użytkowników od konieczności (również uniemożliwienie) korzystania z informacji, gdzie aktualnie znajdują się dane;
  • przezroczystość współbieżności, czyli umożliwienie wielu użytkownikom jednoczesnego dostępu do danych bez konieczności uzgodnień i porozumiewania się, przy zapewnieniu podtrzymania pełnej spójności danych i przetwarzania;
  • przezroczystość skalowalności, czyli umożliwienie dowolnego dodawania lub usuwania elementów bazy danych bez wpływu na pracę użytkowników;
  • przezroczystość replikacji, czyli umożliwienie tworzenia i usuwania kopii danych w innych miejscach geograficznych z bezpośrednim skutkiem dla efektywności przetwarzania, ale bez jakichkolwiek skutków dla postaci programów użytkowych lub pracy użytkownika końcowego;
  • przezroczystość wydajności, czyli umożliwienie dodania nowych elementów systemu komputerowego (np. serwerów, dysków) bez wpływu na pracę większości użytkowników rozproszonej bazy danych;
  • przezroczystość awarii, czyli umożliwienie nieprzerwanej pracy dla większości użytkowników rozproszonej bazy danych w sytuacji, gdy niektóre z jej węzłów lub linie komunikacyjne uległy awarii;
  • przezroczystość migracji, czyli umożliwienie przenoszenia zasobów danych do innych miejsc bez wpływu na pracę użytkowników.

Prawdopodobnie nie istnieją systemy spełniające wszystkie wymienione wyżej kryteria przezroczystości.

przezroczystość rozproszenia (distribution transparency) Patrz: przezroczystość.

przodek (ancestor) Klasa stojąca wyżej w hierarchii klas (nadklasa) w stosunku do danej klasy.

przodek pośredni (indirect ancestor) Patrz: pośredni przodek.

przyjazność (friendliness, user friendliness) Łatwość, z jaką język lub system może być rozpoznany i użyty przez jego użytkownika.

przypadek typu (typecase) Terminem tym określa się własność języka programowania polegającą na możliwości dynamicznego sprawdzania typu pewnego bytu programistycznego (np. wartości) i uzależnienia sterowania programu od wyniku takiego sprawdzenia. Taka własność jest często niezbędna dla języków wprowadzających pewne formy polimorfizmu.

przypadek użycia (use case) W terminologii Jacobsona i UML przypadkiem użycia jest pewna nazwana lub dobrze określona interakcja pomiędzy użytkownikiem a systemem komputerowym. Przypadek użycia odwzorowuje pewną funkcję systemu w taki sposób, w jaki będą ją widzieć jego przyszli użytkownicy. Podejście do analizy od strony przypadków użycia ma ogromny sens, gdyż pozwala zapomnieć o strukturze i architekturze systemu oraz jego detalach technicznych i skoncentrować się na zewnętrznych funkcjach systemu. Podejście do projektowania od strony przypadków użycia jest uważane za znacznie bardziej zdrowe od podejść „technokratycznych”, ponieważ sprzyja ono punktowi widzenia, w którym centralnym ośrodkiem zainteresowania staje się człowiek - przyszły użytkownik systemu - a nie budowa mechanizmu systemu. Model przypadków użycia pozwala wnioskować o systemie na odpowiednio ogólnym, abstrakcyjnym poziomie. Celem metody opartej na przypadkach użycia jest określenie wymagań na projektowany system, czyli:

  • Głębsze zrozumienie użycia systemu będącego przedmiotem procesu projektowania.
  • Zwiększenie stopnia świadomości analityków i projektantów co do celów tego systemu.
  • Umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu.
  • Weryfikacja poprawności i kompletności projektu.
  • Ustalenie wszystkich strukturalnych i funkcjonalnych własności systemu.
  • Ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu.
  • Dostarczenie podstawy do sporządzenia planu testów systemu.

Istnieją opinie, że przypadki użycia mają niewiele wspólnego z obiektowością i były stosowane wcześniej niż obiektowość stała się paradygmatem analizy i projektowania systemów. Niektóre opinie (np. B. Meyera) głoszą również, że przypadki użycia swoją popularność zawdzięczają trywialności, prostocie, łatwości interakcji z użytkownikiem, ale te cechy mogą stać się niekorzystne w przypadku dużego, odpowiedzialnego projektu i mało doświadczonego zespołu projektowego. Patrz też: diagram przypadków użycia.

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

przypisany (proprietary) Określenie języka, biblioteki, aplikacji, itp., która jest przystosowana do oprogramowania jednego producenta (np. Microsoftu) i nie jest używana (nie jest kompatybilna) na innych platformach sprzętowo-programowych lub w innym środowisku programistycznym. Np. standard ActiveX jest przypisany do środowisk Windows95 i Windows NT, natomiast standard CORBA nie jest przypisany do jakiejkolwiek konkretnej platformy.

przyrostowy (incremental) Charakterystyka pewnego procesu lub algorytmu, który zmienia (lub dodaje) mały fragment (do) większej całości. Np. przyrostowe projektowanie oznacza projektowanie poprzez małe kroki, elementy lub modyfikacje dodane do już istniejącej całości; przyrostowa aktualizacja zmaterializowanej perspektywy oznacza, że po każdej zmianie bazy danych zmaterializowana perspektywa nie jest usuwana i liczona od początku, lecz modyfikuje się jej małą, lokalną część.

pseudoteoretyk (pseudo-theoretician) Osoba rozwijająca lub propagująca pseudoteorie. Patrz: pseudoteoria.

pseudoteoria (pseudo-theory) Próba dokonania wynalazku w dziedzinie informatyki przy użyciu metod matematycznych, wykonana przez osoby posiadające kompetencje matematyczne, ale nie posiadające wiedzy i doświadczeń praktycznych. Pseudoteoria nie jest weryfikowalna praktycznie z powodu utopijności założeń lub uwzględnienia jednego aspektu przy całkowitym zaniedbaniu innych, ważniejszych aspektów. Częstą wadą pseudoteorii jest ignorowanie skali problemu, tworzenie teorii dla mini-przykładów, i następnie sugerowanie, że teoria będzie działać w rzeczywistej skali. Kuriozalnych przykładów dostarcza tu np. VDM. Czynnikiem dyskwalifikującym intelektualną i techniczną wartość pseudoteorii jest ignorowanie mentalnych i psychologicznych uwarunkowań uczestników i odbiorców projektów oprogramowania.

Przykładami pseudoteorii są: matematyczne teorie specyfikacji i weryfikacji oprogramowania, teoria normalizacji relacyjnych baz danych, teorie niekompletnej informacji. Istnieje wiele pseudoteorii rozwijanych w związku z obiektowością; m.in. typowany rachunek lambda, rachunek monoidów, koncepcje „dedukcyjno-obiektowe”, obiektowe algebry. Stosunek pseudoteoretyków do obiektowości jest dwojaki: albo próbują oni walczyć z obiektowością używając do tego celu demagogicznej retoryki („brak podstaw matematycznych”), albo też próbują wnieść wkład w obiektowość poprzez stworzenie dla niej nowej pseudoteorii. Oba przypadki są groźne dla obiektowości, gdyż albo próbuje się odciąć dopływ środków (materialnych lub kadrowych) niezbędnych do rozwoju, albo próbuje się spożytkować te środki dla wspomożenia karier pseudoteoretyków, skierowując przy tym naukę, rozwój i dydaktykę na fałszywe tory.

Pseudoteoria - wbrew popularnym stereotypom - nie jest teorią, ponieważ nie służy do opisu i wnioskowania o istniejącej rzeczywistości. Jest ona raczej zmatematyzowanym zapisem pewnej rzeczywistości wyimaginowanej, urojonej. Twierdzenia osób rozwijających pseudoteorie, że tworzą oni wartości intelektualne, które będą konsumowane przez przyszłe pokolenia są niewiarygodne. Wystarczy przejrzeć teorie rozwijane 30 lat temu (organizacja arytmometru komputera, wyszukiwanie na bębnie magnetycznym, itd.), aby uzmysłowić sobie, że dowolne teorie są odbiciem problemów aktualnych w danym czasie i umierają, kiedy te problemy tracą aktualność. Ponadto pseudoteorie są tworzone przez osoby pozbawione kompetencji w zakresie rzeczywistych problemów. Przypomina to sytuację, kiedy teoria gry na skrzypcach jest tworzona przez osobę, która nigdy nie trzymała instrumentu w ręku i nigdy nie była w sali koncertowej.

Pseudoteorie są poważnym hamulcem postępu, gdyż są powodem straty ogromnego potencjału intelektualnego i materialnego, bez zysków w postaci nowej efektywnej wiedzy. Dość często pseudoteoria ubiera się w piórka super-naukowości, tworzy wielki, samopodtrzymujący się świat naukowych pozorów (wyposażony w niezbędne atrybuty: konferencje, seminaria, sympozja, komitety naukowe, specjalne czasopisma, itd.). Pseudoteorie żerują na odwiecznej ludzkiej skłonności do złudzeń i respektu przed środkami magicznymi, tajemniczymi, hermetycznymi. Z tego punktu widzenia pseudoteorie opierają się o bazę psychologiczną, która jest specyficzna dla pseudonauk, takich jak astrologia, parapsychologia, bioenergoterapeutyka, itd. Różnice dotyczą formy lub środka wyrazu (hermetyczna matematyka w zastępstwie pseudo-naukowej retoryki), zaś łączy je skłonność do eksponowania urojonych zalet i faktów; dotyczy to m.in. kłamliwych zapewnień o „szerokich praktycznych zastosowaniach”. Pseudoteorie, których jedynym autentycznym celem są naukowe kariery (będące często zbiorowym interesem dużych grup osób), są sprzeczne z etyką, celami i etosem nauki. Patrz też: teoretyk, teoretyczny masochista, teoretyczny terrorysta.

pseudozmienna (pseudo-variable) Termin języka Smalltalk; zmienna predefiniowana w danym języku i posiadająca ściśle określone znaczenie i semantykę, np. nil, self, true, false, super.

PSM (Persistent Storage Manager) Patrz: skład trwałych obiektów.

PTR (Persistence Through Reachability) Patrz: trwałość poprzez osiągalność.

publiczny (public) Określenie własności obiektu, która nie jest hermetyzowana; jest ona dostępna z dowolnego miejsca zgodnie z regułami zakresu.

punkt funkcyjny (function point, FP) Patrz: analiza punktów funkcyjnych.

punkt kontrolny (checkpoint) Zapamiętanie bieżącego stanu programu (stanu zmiennych programu, stanu bazy danych, itd.) na pewnym trwałym nośniku. Dzięki temu możliwe jest wznowienie pracy programu od miejsca, w którym wprowadzono do niego punkt kontrolny. Punkty kontrolne są techniką implementacyjną funkcji odwrócenia (undo). W przetwarzaniu transakcji (np. w standardzie ODMG) punktem kontrolnym nazywa się wprowadzenie fizycznych zmian do bazy danych poczynionych przez transakcję, bez zwalniania założonych przez nią zamków. Tę sytuację można interpretować jako rozbicie transakcji na dwie transakcje; punkt kontrolny oznacza zakończenie (potwierdzenie) pierwszej transakcji i natychmiastowe wznowienie następnej transakcji z zamkami założonymi na tych samych obiektach, które były zablokowane przez poprzednią transakcję.

Python Obiektowy, interakcyjny, interpretowany, skryptowy język programowania. Pyton łączy pomysły z języków ABC, C, Modula-3 i Icon. Jest przeznaczony do szybkiej budowy prototypów lub jako język rozszerzający aplikacje napisane w C. Posiada pakiety, moduły, klasy, wyjątki definiowane przez użytkownika, dobry interfejs do C. Zapewnia też dynamiczne ładowanie modułów w C.

http://www.python.org/

http://monty.cnri.reston.va.us/grail/

QA (Quality Assurance) Patrz: zapewnienie jakości.

R

rachunek relacyjny (relational calculus) Wprowadzony przez E.F.Codda język zapytań będący pewnym podzbiorem języka rachunku predykatów. Istotną własnością rachunku relacyjnego miała być jego matematyczna równoważność z algebrą relacji. Rachunek relacyjny był podstawą kilku języków zapytań, m.in. języka Alpha (nie zaimplementowanego) oraz QUEL, historycznego języka systemu Ingres. Rachunek relacyjny posiadał dwie odmiany: krotkowy rachunek relacyjny (tuple relational calculus), gdzie każda zmienna przebiegała wszystkie krotki pewnej relacji, oraz dziedzinowy rachunek relacyjny (domain relational calculus), gdzie każda zmienna przebiegała wszystkie wartości z jednej kolumny pewnej relacji. Niektórzy autorzy uważają dziedzinowy rachunek relacyjny jako podstawę obiektowego języka zapytań OQL, ale twierdzenia te są pozbawione wiarygodności (zważywszy chociażby na zasadnicze różnice w uniwersalności rachunku relacyjnego i uniwersalności OQL). Rachunek relacyjny, wskutek poważnych ograniczeń uniwersalności, nie jest koncepcją dostatecznie nośną, co spowodowało, że znalazł się on, chyba bezpowrotnie, w lamusie przestarzałych koncepcji naukowych. Próby reanimacji rachunku relacyjnego (pewnych jego rozszerzeń) do opisu obiektowych języków zapytań należy traktować jako pseudoteoretyczne zabawy nie posiadające żadnych istotnych konsekwencji.

RAD (Rapid Application Development) Szybkie tworzenie aplikacji. Terminem tym określa się narzędzia i techniki programowania umożliwiające szybką budowę prototypów lub gotowych aplikacji, z reguły oparte o programowanie wizyjne. Termin RAD występuje niekiedy jako synonim języków/środowisk czwartej generacji. Przykładami narzędzi RAD są: Borland Delphi RAD Pack, IBM VisualAge (for Cobol, Java, C++, Smalltalk), Microsoft Access Developer’s Toolkit, Microsoft Visual FoxPro Professional, PowerBuilder Desktop, Power++ i wiele innych.

http://www.riv.nl/origin/company/denhaag/RAD.HTM

Raima Object Manager Obiektowy SZBD wspomagający programowanie w C++.

http://www.raima.com/products/rom.cfm

RAP (Rapid Application Prototyping) Szybka budowa prototypów aplikacji. Określenie techniki do szybkiej budowy prototypów; zwykle jest to pewien język czwartej generacji (4GL) lub narzędzie RAD.

RDBMS (Relational Data Base Management System) Patrz: relacyjny system zarządzania bazą danych.

rdzeń ORB (ORB core) Część pośrednika (ORB) odpowiedzialna za komunikację pomiędzy pośrednikami.

referencja (reference) Identyfikator obiektu używany przez program lub zapytanie. (Inaczej: odwołanie, odsyłacz, odnośnik.) Referencja jest pojęciem dość bliskim pojęciu wskaźnika (pointer). Istotna różnica polega na tym, że programista używa wskaźników explicite tak jak wartości, np. może tworzyć zmienną lub atrybut z taką wartością, natomiast referencja jest używana implicite przez niektóre konstrukcje języka programowania lub języka zapytań, np. przez instrukcję podstawienia na zmienną, instrukcję usuwania obiektu, jako parametr procedury komunikowany przez referencję (call-by-reference), itp.

refleksja (reflection) Technika programowania, w której programista pisze program generujący kod programu (w tym samym lub w innym języku), składając go ze stałych stringowych, danych, wejścia z klawiatury, metadanych zapamiętanych w pewnym repozytorium, itd. Wygenerowany program (zwykle w postaci ciągu znaków) poddaje się kompilacji i wykonaniu w tym samym programie, który go utworzył. W językach interpretowanych program jest wykonywany bezpośrednio po utworzeniu. Refleksja jest prostą i skuteczną metodą programowania generycznego (generic), o elastyczności i uniwersalności znacznie przekraczających poziom osiągalny przy pomocy systemów z typami polimorficznymi. Jednocześnie jest techniką dość prostą w implementacji i użyciu. Najbardziej znanym (najwcześniejszym) językiem z refleksją jest Lisp. Pewien wariant refleksji został wykorzystany w dynamicznym SQL oraz w wielu interfejsach określanych jako języki czwartej generacji (4GL). Refleksja jest techniką programistyczną w standardzie CORBA, gdzie jest podstawowym środkiem programowania generycznego wykorzystującego DII (Dynamic Invocation Interface) oraz repozytorium interfejsów. Zaawansowane metody refleksji wymagają istnienia odpowiednio skonstruowanej metabazy, gdzie wszelkie informacje niezbędne do składania programu z fragmentów (np. typy, interfejsy, schematy) są przechowywane w odpowiedniej postaci, np. w postaci ciągów znaków i są dobrze zestrukturalizowane. Wadami refleksji są: dość uciążliwe programowanie bardziej skomplikowanych zadań, przystosowanie do języków interpretowanych i późno wiązanych (np. jest nierealizowalna w C++), słabe możliwości w zakresie mocnej kontroli typów (co czyni ją techniką niebezpieczną). Istnieją koncepcje zdyscyplinowania refleksji tak, aby była ona typologicznie bezpieczna; jak dotąd nie wyszły one poza fazę badawczą.

refleksja lingwistyczna (linguistic reflection) Patrz: refleksja.

reguła (rule) Rodzaj danej przechowywanej w bazie danych lub bazie wiedzy, która jest interpretowana lub uruchamiana przez system. Rodowód pojęcia pochodzi od reguł logicznych, np. klauzul Horna, jednak tego rodzaju reguły nie uzyskały jakiegokolwiek znaczenia w rzeczywistych bazach danych. Regułami nazywa się: ograniczenia (więzy) integralności nakładane na wartości danych lub na zmianę wartości danych, ograniczenia dostępu do danych, fragmenty kodu (tzw. aktywne reguły) przypisane do danych, które są automatycznie wyzwalane przez pewne zdarzenia (np. nadejście określonego momentu czasowego lub zdarzenia zachodzące na danych, np. próba aktualizacji danej). Zwrócimy uwagę, że w odróżnieniu od programowania w logice, w systemach baz danych reguły są „obywatelami pierwszej kategorii”, tj. mogą mieć nazwę, określone granice i mogą podlegać manipulacjom, takim np. jak tworzenie, usuwanie oraz zmiana stanu.

reguła biznesowa (business rule) Reguła realizująca pewną powtarzalną sytuację w biznesie lub pewne ograniczenie związane z biznesem. Patrz: też: aktywne reguły.

reguła wnioskowania o typie (type inference rule) Reguła pozwalająca wnioskować o typie wyrażenia występującego w języku programowania na podstawie typu stałych, podwyrażeń, funkcji, operatorów, itd. uczestniczących w tym wyrażeniu. Np. jeżeli wyrażenie ma postać X+Y, gdzie X jest typu integer, a Y jest typu real, to wówczas odpowiednia reguła wnioskowania o typie ustala, że typem X+Y jest real. W bardziej ogólnym przypadku, reguła wnioskowania o typie jest przyporządkowana do danej konstrukcji gramatycznej i ustala na podstawie (wydedukowanych) typów składowych tej konstrukcji, jaki ma być typ wynikowej konstrukcji. Np. reguła może mieć postać:

co oznacza: jeżeli funkcja f jest typu A® B, x jest typu A, to wyrażenie f(x) jest typu B.

reguły zakresu (scope rules, scoping) Reguły określające kolejność rozpatrywania poszczególnych środowisk przechowujących byty programistyczne przy wiązaniu nazw występujących w programie; np. najpierw lokalne środowisko metody, następnie środowisko klasy, w której metoda została zdefiniowana, następnie środowisko obiektu, na którym działa ta metoda, następnie baza danych, następnie biblioteki procedur i na końcu - zmienne środowiskowe systemu komputerowego. W obiektowości reguły zakresu są nietrywialnym tematem rodzącym problemy semantyczne. Reguły zakresu są najczęściej implementowane w postaci tzw. stosu środowisk (environmental stack), gdzie czubek stosu odwzorowuje najbardziej lokalne środowisko, zaś podstawa stosu - najbardziej globalne. Przy wiązaniu nazw stos środowisk jest przeszukiwany od czubka do podstawy. Poniższy rysunek przedstawia przykład pokazujący kolejność wizyt w poszczególnych środowiskach przy wiązaniu nazwy X występującej wewnątrz ciała metody m zdefiniowanej w klasie PRACOWNIK.

Stos środowisk i reguły zakresu

reinżynieria (reengineering, re-engineering) Przegląd, ocena i modyfikacja systemu celem odtworzenia go w nowej formie (lepszej z ekonomicznego i/lub użytkowego punktu widzenia), a następnie ponowna implementacja tego systemu.

http://www.erg.abdn.ac.uk/users/brant/sre/

reinżynieria procesów biznesowych (Business Process Reengineering, BPR) Fundamentalne przemyślenie i radykalne przeprojektowanie procesów przedsiębiorczości dla uzyskania dramatycznego usprawnienia wg krytycznych współczesnych miar wydajności, takich jak koszt, jakość, serwis i szybkość. Patrz też: reinżynieria.

rekord (record) Patrz: zapis.

relacja (relation) Pojęcie matematyczne, definiowane jako podzbiór iloczynu kartezjańskiego pewnych dziedzin (zbiorów). Relacja stała się podstawowym pojęciem relacyjnego modelu danych, jednakże w ramach tego modelu nabrała ona nieco innego znaczenia, równoważnego (nieskończonej) rodzinie tablic zawierających pewną liczbę nazwanych kolumn i nieograniczoną liczbę wierszy. Istotną własnością tej rodziny jest obecność klucza, tj. kolumny (kolumn), której (których) elementy w jednoznaczny sposób identyfikują wiersze tablicy. Ze względu na powyższą homonimię, wiele systemów odchodzi od stosowania terminu „relacja” na rzecz terminu „tablica”. Pojęcie relacji jest mało precyzyjnym modelem struktur danych (tablic) implementowanych w relacyjnych bazach danych. Np. bazując na czystym pojęciu relacji nie można zdefiniować operatora złączenia naturalnego (natural join) ani też operatora złączenia zewnętrznego (outer join). SQL robi dalsze odstępstwa od tego pojęcia poprzez wprowadzenie możliwości wstawiania do tablic duplikatów krotek, poprzez możliwość sekwencyjnego uporządkowania krotek, grupowania, itd. Środki przetwarzania tablic muszą być znacznie mocniejsze od środków oferowanych przez typowe formalizmu matematyczne operujące na relacjach, takie jak algebra relacji lub rachunek relacyjny.

relacyjna baza danych (relational database) Baza danych zorganizowana według informatycznej ideologii określanej jako „relacyjny model baz danych”. Ideologię tę zaproponował E.F.Codd w 1970 r., zaś nieco później sformułował jej założenia w postaci tzw. 12 reguły „prawdziwego systemu relacyjnego”. Większość tych reguł jest rozsądna i określa zasady budowy systemów zarządzania bazą danych, które powinny obowiązywać nie tylko dla systemów relacyjnych; np. reguła 3 zwracająca uwagę na konieczność systematycznego traktowania wartości zerowych, lub reguła 8 żądająca niezależności programistycznych interfejsów od fizycznej organizacji danych. Niektóre reguły (np. reguła 0) stanowią manifestację myślenia życzeniowego, w którym zapomina się o fakcie, że środki operacyjne i abstrakcje programistyczne wynalezione przez twórców modelu relacyjnego (np. algebra relacji lub SQL) nie są wystarczająco uniwersalne, aby sprostać wymaganiom wielu zastosowań baz danych. W praktycznych implementacjach założenia te są często modyfikowane lub ignorowane. W związku z tym „prawdziwego systemu relacyjnego” nie ma i chyba już nie będzie. Współczesne relacyjne bazy danych łączy kilka cech. Jedną z nich jest logiczna organizacja bazy danych, która jest widziana jako zbiór nazwanych prostokątnych tablic o nieograniczonej liczbie wierszy i o określonej liczbie nazwanych kolumn. Wartości zapisane w tych tablicach są atomowe (niepodzielne) i nie są odsyłaczami do lokacji maszynowych (adresów w pamięci, adresów dyskowych, itp.) lub wewnętrznych identyfikatorów wierszy (krotek) tych tablic. Drugą cechą jest dostęp do danych poprzez język zapytań wysokiego poziomu, zwykle SQL lub jego mutację. Trzecią cechą jest katalog danych, zorganizowany również w postaci tablic i dostępny z języka wysokiego poziomu. Pozostałe cechy systemów określanych jako „relacyjne” - wielodostęp, perspektywy, języki 4GL, etc. - są silnie zróżnicowane.

relacyjna perspektywa (relational view) Wirtualna tablica utworzona poprzez zapytanie (np. w SQL). Relacyjna perspektywa zawiera dane, które pochodzą z jednej lub kilku zapamiętanych tablic. Perspektywy zwykle nie istnieją fizycznie jako zapamiętane dane; istnieją wyłącznie w postaci definicji. Tym niemniej użytkownik może je do pewnego stopnia traktować tak samo jak zapamiętane tablice, używając ich nazw i przypisanych im atrybutów, np. w zdaniach SQL. W szczególności, może używać perspektyw do wyszukiwania i do definiowania innych perspektyw. W niektórych przypadkach perspektywa jest „materializowana” celem zwiększenia szybkości przetwarzania. Poniżej znajduje się przykład definicji perspektywy w SQL:

create view DobryDostawca( Nr, Nazwisko, Miasto )

as

select DNR, NAZWISKO, MIASTO

from DOSTAWCA

where STATUS > 30

W ten sposób została utworzona wirtualna tablica DobryDostawca z atrybutami Nr, Nazwisko, Miasto, która jest (poziomym i pionowym) zawężeniem tablicy DOSTAWCA, poprzez przesłonięcie wierszy, w których status dostawcy jest mniejszy lub równy 30, oraz przesłonięcie niektórych kolumn. Taka perspektywa może być użyta w zapytaniu SQL na normalnych zasadach, np.:

select Nr, Nazwisko from DobryDostawca where Miasto = ‘Kraków’

Negatywnymi cechami relacyjnych perspektyw (definiowanych w SQL) jest ograniczenie funkcjonalności (nie wszystkie wyobrażalne wirtualne tablice dadzą się wyrazić w SQL) oraz nie rozwiązany (w ogólnym przypadku) problem aktualizacji perspektyw.

relacyjny system zarządzania bazą danych, RSZBD (Relational Data Base Management System, RDBMS) Systemy takie jak: Oracle, Sybase, Ingres, DB2, Informix, Progress, Dbase, MS SQL Server, i wiele innych. Patrz: relacyjna baza danych.

relewancja (relevance) Pewna ilościowa lub jakościowa miara określająca precyzję lub odpowiedniość wyniku wyszukiwania, tj. w jakim stopniu rezultat wyszukiwania (tekstów, pozycji bibliograficznych, stron WWW, obiektów, grafiki) odpowiada intencji użytkownika wyrażonej w zapytaniu. Relewancja zależy od precyzji języka zapytań, od naturalności użycia jego konstrukcji dla użytkowników, od metody i jakości opisu (indeksowania) obiektów będących przedmiotem wyszukiwania, oraz od algorytmów ustalających odpowiedniość danego obiektu do danego zapytania. Terminów relewantny/nierelewantny używa się także potocznie jako synonimów odpowiedni/nieodpowiedni dla danej sprawy, problemu, zagadnienia, itp.

replikacja (replication, mirror) Kopia danych przechowywana w miejscu odległym od miejsca przechowywania oryginału. Replikacje zmniejszają obciążenie sieci oraz zwiększają dostępność danych, niezawodność i bezpieczeństwo. Poważnym problemem związanym z replikacjami jest konieczność jednoczesnej aktualizacji wszystkich istniejących kopii danych.

replikator (replicator) Moduł systemu zarządzania bazą danych, którego zadaniem jest podtrzymywanie spójnych kopii danych w różnych oddalonych geograficznie miejscach. W przypadku aktualizacji dowolnej z nich, replikator automatycznie aktualizuje pozostałe kopie. Ze względu na koszt transmisji oraz ze względu na autonomię lokalnej bazy danych, nie zawsze jest korzystna natychmiastowa aktualizacja kopii. Większość aplikacji może tolerować pewne opóźnienie w aktualizacji kopii. Z tego względu replikatory posiadają dodatkowe możliwości sterowania opóźnieniem; np. kopie są aktualizowane pod koniec dnia, raz na tydzień, itp. Istnieje kilka modeli replikacji, np. model, w którym aktualizowana może być tylko główna kopia, zaś repliki mogą być tylko czytane.

repozytorium (repository) Skład, magazyn obiektów lub innych danych. Zwykle intencją tego terminu jest skład przechowujący dane różnych typów (dokumenty, klasyczne dane, dane multimedialne, programy, skrypty, reguły, perspektywy) oraz udostępniający je przy pomocy środków wizualnych.

repozytorium implementacji (implementation repository) W terminologii standardu OMG CORBA miejsce przechowywania informacji o implementacji obiektów, wraz z usługami pozwalającymi zidentyfikować oraz zlokalizować obiekt.

http://www.omg.org

repozytorium interfejsów (interface repository, IR) Termin OMG CORBA; miejsce przechowywania definicji interfejsów (specyfikacji klas), które może być przeszukiwane przy pomocy standardowych środków. Repozytorium interfejsów jest zwykle wykorzystywane przy wołaniach dynamicznych (Dynamic Invocation Interface, DII).

http://www.omg.org

REXX Skryptowy uniwersalny język programowania będący integralną częścią systemu operacyjnego OS/2 firmy IBM. Posiada elementy obiektowości.

http://www2.hursley.ibm.com/orexx/

http://www2.hursley.ibm.com/rexx/

RFI (Request For Information) Dokument (w postaci ankiety) rozsyłany przez OMG celem ustalenia stopnia zainteresowania członków OMG konkretnym elementem standardu CORBA.

http://www.omg.org

RFP (Request For Proposal) Dokument (w postaci ankiety) rozsyłany przez OMG celem ustalenia szczegółów, propozycji i wymagań dotyczących konkretnego elementu standardu CORBA.

http://www.omg.org

RMI (Remote Message Invocation) Wołanie odległej metody. Pośrednik wymiany obiektów (ORB) firmy JavaSoft rozszerzający język Java. Poprzednie wersje nie były kompatybilne ze standardem CORBA; obecnie, w wyniku porozumienia producentów oprogramowania, JavaSoft planuje zaadoptowanie RMI jako pakietu działającego na bazie CORBA/IIOP. RMI służy do integracji aplikacji napisanych w Java.

http://java.sun.com/products/jdk/1.1/docs/guide/rmi/index.html

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

rola [1] (role) Dynamicznie zmieniająca się specjalizacja obiektu. Każdy obiekt może jednocześnie występować w wielu rolach. Rola importuje wszystkie atrybuty wraz z ich wartościami z obiektu będącego jej podmiotem. Każda z ról może należeć do własnej klasy. Np. obiekt OSOBA może być jednocześnie w rolach PRACOWNIK, PACJENT, PODATNIK, itd. Rysunek poniżej przedstawia cztery obiekty OSOBA, które mogą mieć dwie role: PRACOWNIK i STUDENT; każda z ról dziedziczy inwarianty z własnej klasy oraz importuje (strzałka z podwójną linią) atrybuty i ich wartości z obiektu będącego jej podmiotem. Role można traktować jako dynamicznie i równolegle pojawiające się i znikające specjalizacje obiektu. Koncepcja ról umożliwia znacznie bardziej czyste potraktowanie wielu pojęć obiektowości, w szczególności pozwala zrezygnować z zasady zamienialności (substitutability), pozwala na spójne potraktowanie powiązań pomiędzy obiektami, oraz umożliwia opanowanie problemu wielodziedziczenia. Brak pojęcia roli w modelach i systemach obiektowych powoduje ograniczenia i konflikty, które następnie zamieniają się w dość jałowe dyskusje dotyczące metod ich uniknięcia, czego przykładem są dyskusje dookoła pojęcia wielodziedziczenia. Jak dotąd, role nie są implementowane i praktycznie nie występują w metodykach analizy i projektowania. Zamiast nich, autorzy tych metodyk posługują się zbytnio uogólnionym terminem agregacja lub semantycznie mętnym terminem delegacja. Temat ról jest przedmiotem wzorców projektowych (design patterns) (np. wzorca określanego jako decorator). Takie podejście do zagadnienia jest jednak bardziej próbą wynalezienia kolejnej protezy dla ułomnego modelu, niż istotnym wyleczeniem przyczyny ułomności.

Obiekty i dynamiczne role

rola [2] (role, role name) W diagramach encja-związek (oraz diagramach obiektowych) rola jest nazwą przypisaną do jednej dziedziny związku (asocjacji), np. związek Ślub łączący 3 osoby (mężczyznę, kobietę oraz księdza) posiada trzy nazwane role: PanMłody, PannaMłoda i Ksiądz.

rola [3] (role) W metodykach analizy i projektowania systemów informatycznych rolą określa się kategorię pracownika lub użytkownika, będącego podmiotem systemu informatycznego lub projektu (dyrektor, pracownik, analityk, programista, itd.). Synonim: aktor.

rola asocjacji (association role) Patrz: rola [2].

Rose Narzędzie CASE firmy Rational, stosujące m.in. notację UML.

http://www.rational.com/products/rose/

RoughWave Biblioteka klas w C++ oferowana przez firmę Rough Wave Software. Zawiera m.in. standardową bibliotekę C++, klasy do pisania aplikacji wielowątkowych (multithreaded), pomost pomiędzy językami Java i C++, klasy do optymalizacji zarządzania pamięcią, biblioteki funkcji matematycznych, udogodnienia służące do dostępu do relacyjnych baz danych, środki do programowania wizyjnego i konstrukcji graficznych interfejsów użytkownika, środki do programowania aplikacji klient/serwer i innych systemów rozproszonych, środki do współdziałania ze standardem CORBA i inne.

rozproszona baza danych (distributed database) Baza danych, która jest rozproszona geograficznie, ale opisywana przez pewien globalny schemat (zwany niekiedy schematem federacyjnym). Istotą rozproszonej bazy danych (w odróżnieniu od dostępu do odległych zasobów, np. poprzez ODBC lub JDBC) jest jednorodność jej organizacji i przezroczystość rozproszenia. Programista programujący aplikację działającą na rozproszonej bazie danych postępuje tak, jak gdyby baza danych była scentralizowana. Rozproszone bazy danych implikują trudne problemy, m.in. związane z przetwarzaniem i optymalizacją rozproszonych zapytań, optymalizacją obciążenia sieci, uzyskaniem wysokiej niezawodności przetwarzania transakcji w sytuacji zawodnej sieci (patrz np. protokół 2PC) i technologią przetwarzania replikacji (kopii danych).

http://www2.hawaii.edu/~ramesh/ics691.html

rozproszone obiekty (distributed objects) Architektura systemu, w której obiekty są zlokalizowane w różnych, geograficznie oddalonych węzłach sieci komputerowej. Niekiedy z tym terminem wiązana jest możliwość przemieszczania obiektów z danego węzła do innego węzła.

rozproszony powszechny model obiektowy (DCOM, Distributed Common Object Model) Patrz: DCOM.

rozproszony system obiektowy (distributed object system) System zapewniający geograficzne rozproszenie obiektów oraz własność przezroczystości (transparency); tj. programista działający w systemie rozproszonym nie musi zajmować się nawiązywaniem połączeń i protokołami transmisji obiektów. (W tym sensie, aplikację zapewniającą dostęp do odległych obiektów przy pomocy specjalnych komend lub interfejsów kwalifikuje się jako bardzo uproszczone rozproszenie.) Rozproszone systemy obiektowe są przedmiotem szeregu standardów i produktów określanych jako oprogramowanie pośredniczące (middleware); przykładem są pakiety ORB zbudowane wg standardu CORBA, COM, OpenDoc, OSF DCE, RMI, JavaBeans. Odrębnym tematem są obiektowe rozproszone bazy danych. W relacyjnych bazach danych temat ten zaowocował w różnorodne rozwiązania, m.in. pomosty (gateways) do obcych systemów, własne protokoły/pakiety dostępu do odległych baz danych (zwykle oparte o RPC), replikacje, przetwarzanie zapytań w rozproszonych bazach danych, protokoły przetwarzania transakcji w systemach rozproszonych takie jak 2PC, architektura klient/serwer i inne. Należy zwrócić uwagę, że temat rozproszenia powiązany z tematem współdziałania (interoperability) był podejmowany przez wiele środowisk akademickich i przemysłowych, ale (pomimo setek publikacji) jest dość trudno określić jednoznaczne rezultaty tej aktywności (poza dość zgrubnymi hasłami takimi jak „federacyjna baza danych”, „globalny schemat”, „integracja schematów”, itp.). Rynek zdominowały różnorodne rozwiązania ad hoc, niekompatybilne, często obarczone istotnymi wadami. Przyczyną jest prawdopodobnie to, że problem jest bardzo trudny, uwikłany w wiele szczegółów związanych z wydajnością, niezawodnością, bezpieczeństwem, implementacją i infrastrukturą rozproszonych systemów. Poprzez to temat nie poddaje się generalizacjom, spekulacjom, czy teoriom. Temat rozproszonych obiektowych baz danych jest podejmowany przez wiele grup akademickich i przemysłowych, ale jak dotąd, dość trudno stwierdzić, że prace te zaowocowały konkretnymi systemami lub rozwiązaniami na rynku. Pakiety lub standardy takie jak CORBA lub DCOM są ulokowane (z koncepcyjnego punktu widzenia) blisko poziomu systemu operacyjnego. Mogą więc stanowić bazę techniczną dla rozproszonych baz danych, ale nie są w stanie rozwiązać problemów koncepcyjnych, takich jak np. federacyjność i autonomia, aktualizowalne perspektywy (wirtualne schematy), optymalizacja rozproszonych zapytań, czy też przetwarzanie replikacji. Wydaje się, że obiektowe bazy danych będą jeszcze jakiś czas dojrzewać do powyższych tematów.

rozprzestrzenianie (deployment) Przystosowywanie oprogramowania przygotowanego na daną platformę do pracy na innych platformach. Terminem tym określa się również przypisanie składowych danego oprogramowania do elementów architektury sprzętu; patrz: diagram rozprzestrzeniania. Synonim: wdrażanie.

rozszeregowanie (unmarshalling) Wyjaśnienie - patrz: szeregowanie.

rozszerzalność (extensibility) W szerszym znaczeniu, pewna ilościowa lub jakościowa miara określająca łatwość, z jaką dany system lub język można rozszerzyć o nowe funkcje. W węższym znaczeniu zwykle chodzi o możliwość definiowania i nazywania (przez projektanta lub programistę) nowych klas i/lub typów na podstawie klas/typów wbudowanych w system oraz klas/typów już zdefiniowanych i nazwanych.

rozszerzony relacyjny SZBD (extended relational DBMS, extended RDBMS) Relacyjny SZBD rozszerzony o pewne niestandardowe funkcje, np. przetwarzanie multimediów, obiektowość, reguły, abstrakcyjne typy danych, zintegrowanie z WWW, hurtownie danych, itd. Patrz też: obiektowo-relacyjny.

rozszerzony RSZBD (extended RDBMS) Patrz: rozszerzony relacyjny SZBD.

rozwój oprogramowania (software development) Proces analizy, projektowania, konstrukcji, testowania i wdrażania oprogramowania. Synonim: wytwórstwo oprogramowania.

równorzędny (peer) Określenie jednostki sprzętu lub oprogramowania, która w danym systemie lub sieci jest równorzędna w stosunku do innych jednostek; zwykle określenie to występuje w kontraście w stosunku do określeń takich jak klient i serwer.

równorzędny-do-równorzędnego (peer-to-peer) Określenie architektury sprzętu lub oprogramowania (oraz rodzaju komunikacji), w której występują dwie lub więcej jednostek na tym samym poziomie, równorzędnych, komunikujących się przy pomocy tego samego protokołu. Zwykle architekturę tę przeciwstawia się architekturze klient-serwer lub innym zależnościom hierarchicznym pomiędzy jednostkami.

RPC (Remote Procedure Call) Patrz: wołanie odległej procedury.

RSZBD (RDBMS, Relational Data Base Management System) Relacyjny System Zarządzania Bazą Danych.

Rumbaugh, James Główny twórca metodyki obiektowej OMT; jeden z twórców notacji Unified Modeling Language, UML.

http://www.rational.com/

r-wartość (r-value) Synonim wartości, wynik wyrażenia, które po ewaluacji zwraca wartość, np. 2+2, x+1, sin(x), itd. R-wartość nie może pojawić się po lewej stronie operacji podstawienia, może ono natomiast pojawić się po prawej stronie (stąd r-wartość, od right). Jeżeli wyrażenie zwraca referencję (do zmiennej, atrybutu, itd.) i stoi w miejscu, gdzie oczekiwana jest r-wartość, wówczas automatycznie jest wywoływana operacja dereferencji. R-wartość jest obliczonym parametrem aktualnym przy wołaniu poprzez wartość oraz może parametryzować zdania imperatywne. Przeciwieństwem r-wartości jest l-wartość (l-value, od słowa left).

rzutowanie (cast) Patrz: kast.

S

samoreferencja (self-reference) Identyfikacja obiektu, do którego został wysłany komunikat. Samoreferencji używa się wewnątrz ciała metody wywoływanej po odebraniu komunikatu; do tego celu służą pseudozmienne, takie jak self lub this.

Sather Obiektowy język programowania, pochodna języka Eiffel. Podstawowymi założeniami tego języka są m.in.: efektywność (maszynowa), elegancja definicji, bogata biblioteka klas, statyczna mocna kontrola typów i możliwość definiowania funkcji wyższego rzędu.

http://http.icsi.berkeley.edu/Sather/

scenariusz (scenario) Pojęcie niektórych metodyk obiektowych, np. MainstreamObjects. Sekwencja czynności lub transakcji realizująca konkretną funkcję użytkową systemu. Pojęcie scenariusza jest bliskie lub tożsame z pojęciem przypadku użycia (use case).

schemat bazy danych (database schema) Obraz zawartości bazy danych, wyrażony w sformalizowanym języku. W obiektowych bazach danych schemat jest formalnym opisem zawartości bazy danych uwzględniającym klasy, specyfikacje atrybutów, specyfikacje metod, typy, powiązania pomiędzy klasami obiektów oraz inne informacje. Schemat może dotyczyć różnych poziomów abstrakcji:

  • schemat logiczny (logical schema) przedstawia budowę struktur danych na poziomie abstrakcji niezbędnym dla prawidłowego manipulowania danymi przez programistę i użytkownika;
  • schemat pojęciowy (conceptual schema) ustala klasy obiektów modelowanej rzeczywistości oraz koncepcyjne związki pomiędzy tymi obiektami, przez co ułatwia rozumienie semantyki danych;
  • schemat fizyczny (physical schema) przedstawia szczegóły organizacyjne dla poszczególnych typów danych (indeksy, tablice mieszające, itp.).

Schemat bazy danych jest niezbędny dla jej użytkowników i programistów do zrozumienia, co baza danych zawiera i jak dane są zorganizowane. Schemat bazy danych jest wykorzystywany przez SZBD dla właściwej organizacji danych, kontroli typów danych oraz wymuszenia niektórych ograniczeń dotyczących danych. Fragment schematu odnoszący się do jednego użytkownika lub jednej aplikacji jest zwany podschematem. Ma on na celu uproszczenie wizji danych oraz ograniczenie dostępu do danych. Zwykle schemat bazy danych jest wyrażeniem języka opisu danych (data description language, DDL), np. ODL wg standardu ODMG.

schemat federacyjny (federated schema) Schemat rozproszonej bazy danych, w którym uwidocznione są te zasoby danych, które autonomiczne węzły sieci komputerowej zadeklarowały jako dostępne dla danego rozproszonego systemu.

schemat fizyczny (physical schema) Przedstawia szczegóły organizacji danych (indeksy, struktury pomocnicze, pliki, wskaźniki, fizyczną organizację zbiorów, itp.) dla poszczególnych elementów schematu logicznego lub pojęciowego.

schemat globalny (global schema) Koncepcja organizacji rozproszonej bazy danych, w której wszystkie miejsca w rozproszonej bazie danych są objęte jednym globalnym schematem, jednakowym dla każdego miejsca. Globalny schemat zakłada przezroczystość rozproszenia, tj. programista nie musi być świadomy tego, gdzie dane są fizycznie przechowywane i nie musi explicite używać komend transmisji danych. Istotną wadą podejścia opartego na globalnym schemacie jest zredukowana możliwość sterowania zakresem autonomii każdego lokalnego systemu.

schemat logiczny (logical schema) Schemat przedstawiający budowę struktur danych na poziomie abstrakcji niezbędnym dla prawidłowego manipulowania danymi przez programistę i użytkownika, bez konieczności odwoływania się do szczegółów implementacyjnych. Zwykle schemat logiczny jest zapisany w języku konkretnego SZBD; patrz: schemat bazy danych.

schemat obiektowy (object schema) Schemat bazy danych zapisany w języku definicji danych systemu obiektowego (DDL, Data Definition Language), np. w ODL wg standardu ODMG.

schemat pojęciowy (conceptual schema) Schemat bazy danych przedstawiony w postaci diagramu pojęciowego klas, ich hierarchii i powiązań. Schemat pojęciowy odwołuje się przede wszystkim do ludzkiego myślenia, percepcji i komunikacji międzyludzkiej, natomiast w drugiej kolejności do realizacji komputerowej.

schemat wewnętrzny (internal schema) Patrz: schemat fizyczny.

sekwencja (sequence) W terminologii obiektowych baz danych (np. standardu ODMG) konstruktor typów lub klas. Wartość lub obiekt typu „sekwencja” jest kontenerem zawierającym wiele (dowolnie dużo) elementów. Wartość typu sekwencja może być dowolnie rozszerzona o nowe elementy oraz można z niej usunąć elementy istniejące. W odróżnieniu od zbioru i wielozbioru, porządek elementów w sekwencji ma znaczenie i jest wykorzystywany przez niektóre operatory, np. DajPierwszy, DajNastępny, CzyOstatni, itp.

selekcja (selection) Operator algebry relacji lub języka zapytań, który tworzy nową relację poprzez wybranie z wejściowej relacji wierszy spełniających pewien warunek (zwany predykatem). W obiektowych językach zapytań analogiczny operator wybiera pewien fragment wejściowej kolekcji obiektów na podstawie określonego warunku.

selektor (selector) Termin języka Smalltalk; część komunikatu ustalająca nazwę metody. Zwykle selektorem nazywa się operację, która odczytuje własność obiektu, ale jej nie zmienia.

Self Obiektowy język programowania oparty o koncepcje prototypów i delegacji, dynamicznego dziedziczenia, behawioru i stanów.

http://self.smli.com

self Słowo kluczowe (Smalltalk) występujące w ciele metody i identyfikujące obiekt, do którego został wysłany komunikat zawierający nazwę tej metody; często używa się także słowa this (np. C++) lub current. Istnieją drobne niuanse semantyczne związane ze znaczeniem tych słów w poszczególnych językach.

semantyczny model danych (semantic data model) Model danych wprowadzający pojęcia takie jak: generalizacja, specjalizacja, asocjacja, agregacja, klasyfikacja, które ułatwiają odwzorowanie modelowanego fragmentu rzeczywistości w jej abstrakcyjny obraz pojęciowy lub zapis (diagram) w pewnej notacji. Przykładem semantycznych modeli danych jest model encja-związek i model obiektowy.

semantyka (semantics) Ogólnie: dział lingwistyki zajmujący się badaniem znaczenia wyrazów, fraz, zdań, etc. W informatyce terminu tego używa się w sytuacjach, kiedy mówimy o znaczeniu tekstu (np. programu), danych, lub struktury formalnej (np. diagramu). W matematyce semantyka oznacza formalne odwzorowanie napisów pewnego języka w obiekty matematyczne; np. odwzorowanie tekstu programu w funkcję określoną na zbiorze stanów. W nieformalnych modelach danych semantyka oznacza odwzorowanie danych lub schematów (diagramów, modeli) w obrazy pojęciowe (koncepcyjne) dotyczące modelowanej rzeczywistości.

semantyka danych (data semantics) Znaczenie danych; odwzorowanie danych w obrazy pojęciowe dotyczące modelowanej rzeczywistości.

semantyka oparta na kopiowaniu (copy semantics) Ogólnie, określenie semantyki pewnej konstrukcji gramatycznej, w której operuje się na kopii argumentu lub składowej tej konstrukcji. Np. iterator

for each x in K do p(x)

(gdzie x jest zmienną iteratora, K jest kontenerem obiektów, zaś p(x) jest pewnym programem zależnym od zmiennej x wykonywanym w pętli iteratora) posiada semantykę opartą na kopiowaniu, jeżeli w każdym obrocie pętli iteratora na zmienną x podstawia się kopię kolejnego obiektu z kontenera K. Możliwe są inne konstrukcje, których semantyka jest oparta na kopiowaniu, np. metoda przekazywania parametrów określana jako wołanie poprzez wartość ze zwrotem (call-by-value-return). Semantykę opartą na kopiowaniu przeciwstawia się semantyce opartej na referencjach.

semantyka oparta na referencjach (reference semantics) Ogólnie, określenie semantyki pewnej konstrukcji gramatycznej, w której operuje się na referencji do argumentu lub składowej tej konstrukcji. Np. iterator

for each x in K do p(x)

(gdzie x jest zmienną iteratora, K jest kontenerem obiektów, zaś p(x) jest pewnym programem zależnym od zmiennej x wykonywanym w pętli iteratora) posiada semantykę opartą na referencjach, jeżeli w każdym obrocie pętli iteratora na zmienną x podstawia się referencja do kolejnego obiektu z kontenera K. Możliwe są inne konstrukcje, których semantyka jest oparta na referencjach, np. metoda przekazywania parametrów określana jako wołanie poprzez referencję (call-by-reference). Semantykę opartą na referencjach przeciwstawia się semantyce opartej na kopiowaniu.

serwer (server) Element architektury klient-serwer realizujący zlecenia klientów.

serwer aplikacji (application sever) Składnik trzywarstwowej architektury (three-tier architecture) zbierający zlecenia od klientów, realizujący logikę biznesu, wysyłający zlecenia do serwerów, zbierający wyniki tych zleceń i przekazujący je w odpowiedniej formie do klientów.

serwlet (servlet) Kod języka Java, który jest wykonywany po stronie serwera WWW (w odróżnieniu od apletu, który wykonuje się po stronie klienta) i realizuje zlecenia wysyłane od klienta (np. dostęp do bazy danych znajdującej się na serwerze WWW), przesyłając następnie wyniki do klienta.

http://jeeves.javasoft.com/products/java-server/servlets/index.html

Shlaer-Mellor Obiektowa metodyka analizy, modelowania i projektowania systemów informatycznych integrująca własności strukturalne i behawioralne. Patrz: OOSA.

http://www.projtech.com/smmethod/smmethod.html

SI System Informatyczny, System Informacyjny (Information System, IS).

sieciowy model danych (network data model) Ogólnie: model danych, w którym dane posiadają wewnętrzne identyfikatory (lub adresy), zaś związki semantyczne pomiędzy danymi są reprezentowane poprzez powiązania referencyjne lub wskaźnikowe. Struktura danych tworzy więc graf, czyli sieć. (Termin „sieciowy” nie ma tu związku z sieciami komputerowymi.). Najczęściej model sieciowy jest utożsamiany z propozycją grupy DBTG (Data Base Task Group) komitetu CODASYL, opublikowaną w 1971 r. i potem kilkakrotnie modyfikowaną. Propozycja DBTG CODASYL została zrealizowana w wielu systemach; m.in. w polskim systemie RODAN. Model sieciowy w wersji DBTG obarczony był wadami, m.in. obniżeniem poziomu programowania do detali fizycznej organizacji danych. W ostatnich latach nastąpił renesans podstawowych założeń modelu sieciowego w obiektowych bazach danych.

silnik wyszukiwawczy (search engine) Ogólnie, określenie udogodnienia WWW, które pozwala wyszukiwać informacje na stronach WWW lub w dużych bazach danych tekstowych. Przykładami silników wyszukiwawczych są: Yahoo, AltaVista, Hot Bot, Lycos, Sleuth, i inne. Termin ten występuje także w kontekście oprogramowania przeznaczonego do wyszukiwania pełnotekstowego, takiego jak Search’97 (dawniej Topic) firmy Verity.

Simula-67 Język opracowany w 1967 roku, uważany za przodka obiektowości w programowaniu. Został opracowany w Norweskim Centrum Obliczeniowym w Oslo. Wprowadza klasy, podklasy, wirtualne funkcje i aktywne obiekty.

Sina Współbieżny obiektowy język programowania wykorzystujący model CFOM (Composition Filters Object Model).

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

Sintropy (Syntropy) Obiektowa metodyka analizy i projektowania systemów informatycznych.

http://www.objectdesigners.co.uk/syntropy

skalowalność (scalability) Zdolność oprogramowania lub systemu komputerowego do sprawnego działania w warunkach rosnącej liczby użytkowników, zwiększającej się objętości przetwarzanych danych lub rozrostu ilości węzłów sieci komputerowej. Zwrócimy uwagę, że (wbrew popularnej komercyjnej retoryce) pojęcie skalowalności jest relatywne. W istocie, nie jest właściwe mówienie, że system jest „skalowalny” lub „nie skalowalny”, ponieważ zależy to od aspektu, wg którego definiuje się skalowalność, oraz od zakładanego maksimum tego aspektu. Np. wszystkie systemy „są skalowalne” przyjmując, że maksymalna objętość bazy danych wynosi 100 obiektów, oraz wszystkie „nie są skalowalne” przyjmując, że maksymalna objętość bazy danych wynosi 1000 miliardów obiektów.

skład danych (data store) Struktura danych i pakiet procedur do utrzymywania i zarządzania danymi na poziomie fizycznym na dysku lub w pamięci operacyjnej.

skład obiektów (object store, storage domain) Struktura danych i pakiet procedur do utrzymywania i zarządzania obiektami na poziomie fizycznym na dysku lub w pamięci operacyjnej.

skład trwałych obiektów (persistent object store, persistent storage manager, PSM) Struktura danych i pakiet procedur, klas, metod do utrzymywania i zarządzania trwałymi obiektami na poziomie fizycznym. Z punktu widzenia architektury systemu obiektowej bazy danych zarządca trwałymi obiektami znajduje się na najniższym poziomie, stanowiącym wewnętrzny interfejs pomiędzy zewnętrznymi funkcjami bazy danych a pamięcią dyskową.

składnica danych (data mart) Mała wyspecjalizowana hurtownia danych, stanowiąca fragment większej hurtowni danych.

składowanie (back up) Okresowe tworzenie kopii bazy danych, umożliwiających odtworzenie jej stanu w przypadku awarii systemu lub utraty spójności danych.

skojarzenie (coupling) Określenie stopnia powiązania pomiędzy klasami, np. jak często obiekty jednej klasy występują razem z obiektami innej klasy, jak często obiekty jednej klasy wysyłają komunikaty do obiektów innej klasy, itp. Możliwe jest np. mocne skojarzenie (kiedy klasy tworzą pewien nierozerwalny układ), słabe skojarzenie, brak skojarzenia, itd. Patrz też: kohezja.

słaba kontrola typów (weak typing, weak type checking) Brak kontroli typów lub silnie ograniczona kontrola typów.

słabo typowany (weakly typed) Nie podlegający kontroli typów lub podlegający bardzo ograniczonej kontroli typów.

słoń (elephant) Duży, szary ssak z rzędu trąbowców. Patrz też: mrówka.

słownik (dictionary) Ogólnie, miejsce przechowywania lub baza danych terminów oraz ich wyjaśnień dotyczących pewnej dziedziny działalności związanej np. z analizą i projektowaniem SI. Słownik jest podstawowym elementem narzędzi CASE. Prowadzenie słownika jest zalecane w wielu metodach analizy i projektowania, np. w metodzie opartej na przypadkach użycia.

słownik danych (data dictionary) Repozytorium zawierające opis danych (w szczególności opis klas) przechowywanych w bazie danych, które może być używane przez wiele aplikacji. Synonimy: katalog, metadane.

Smalltalk, SmallTalk Obiektowy język programowania opracowany w latach 1976-83 w Xerox Palo Alto Research Center w Kalifornii. Wprowadza klasy, podklasy, wirtualne funkcje, przesyłanie komunikatów, metaklasy. Jak głosi popularny slogan, w Smalltalku wszystko jest obiektem, w szczególności liczby i klasy (ale jak się okazuje, komunikaty, nazwy, itd. nie są obiektami). Istotą sukcesu Smalltalka jest to, że nie jest on tylko językiem, ale także mocnym zintegrowanym środowiskiem programistycznym z atrakcyjnym interfejsem okienkowym. Prostota, możliwość szybkich dynamicznych zmian, elastyczna natura Smalltalka uczyniła go doskonałym narzędziem do szybkiego tworzenia prototypów.

Składnia Smalltalka jest bardzo prosta. Podstawowa konstrukcja ma postać:

obiekt komunikat

lub z parametrami:

obiekt komunikat: parametr1 drugiArg: parametr2 ... n-tyArg: parametr-n

gdzie drugiArg,...n-tyArg są nazwami traktowanymi jako składowa komunikatu.

Smalltalk wprowadza dwie pseudozmienne: self i super. Nie posiada wielodziedziczenia i mocnej (statycznej) kontroli typów. Wyrażenia w Smalltalku takie jak 2+3 uważa się za egzemplifikację paradygmatu przesyłania komunikatów: do obiektu 2 wysyła się komunikat + z parametrem 3; w rezultacie dostajemy oczekiwane 5. Ta egzotyka Smalltalka jest przedmiotem kontrowersji.

http://www.parcplace.com

http://st-www.cs.uiuc.edu/

http://XCF.Berkeley.EDU/pub/misc/smalltalk/FAQ/

http://www.oti.com/jeffspg/smaltalk.htm

http://www.rwi.com/smalltalk/smalltalk.html

http://www-laforia.ibp.fr/~fdp/esug-bookmarks.html

http://www-laforia.ibp.fr/~fdp/esug.html

http://www.info.unicaen.fr/~serge/smalltalk80.html

http://www.cs.iastate.edu/~leavens/larchSmalltalk.html

SOM (System Object Model) Technologia udostępniania bibliotek klas oferowana przez IBM. SOM ustala model obiektowy (zbliżony do OMG CORBA) oraz umożliwia dzielenie bibliotek klas niezależnie od języka, w którym zostały one napisane. Podstawowym celem SOM jest współdziałanie obiektowych i nieobiektowych systemów oraz ponowne użycie. SOM jest podstawą dla technologii OpenDoc. SOM jest teraz częścią produktu nazwanego Component Broker.

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

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

http://www.austin.ibm.com/somservice/faq.html

SOMA Obiektowa metodyka analizy i projektowania systemów informatycznych.

spadek (legacy) Określenie starszych systemów lub aplikacji, które muszą być przystosowane, zaadoptowane lub zintegrowane z nowszymi systemami lub technologiami bez ponoszenia nadmiernych kosztów i nadmiernego czasu wyłączenia z działania.

spadkowy (legacy) Określenie starszego systemu, patrz: spadek.

spaghetti (spaghetti, spaghetti-like) Pejoratywne określenie kodu programu, projektu, diagramu o bardzo skomplikowanej budowie, której logika jest trudna do zrozumienia lub do zdekomponowania. Patrz też: bizantyjski.

specjalizacja (specialization) Abstrakcja dotycząca danych lub obiektów. Termin jest używany w dwóch podobnych znaczeniach: (1) Specjalizacja oznacza relację pomiędzy daną klasą i jej klasą podrzędną; np. klasa Student jest specjalizacją klasy Osoba. (2) Specjalizacja oznacza utworzenie nowej podklasy z danej klasy. Np. mając klasę Osoba można utworzyć jej specjalizację Student. Przeciwieństwem specjalizacji jest generalizacja.

specyfikacja (specification) Ogólnie, abstrakcyjny opis bytu programistycznego (procedury, modułu, klasy, obiektu, bazy danych, itd.) określający reguły jego użycia lub ustalający podstawowe założenia jego implementacji. Specyfikację przeciwstawia się implementacji. Np. specyfikacja klasy oznacza podanie nazw i typów atrybutów wystąpień tej klasy (obiektów) oraz sygnatur przypisanych do nich metod. Specyfikację klasy utożsamia się niekiedy z jej interfejsem lub z jej typem. Utożsamienie to jest mało precyzyjne, gdyż do użycia danej klasy są to często informacje niewystarczające. Wielu autorów zwraca uwagę, że specyfikacja niektórych bytów programistycznych musi włączać także takie elementy jak: określenie zasobów zewnętrznych, z których dany byt korzysta, określenie skutków ubocznych (np. wyjątków), które powoduje, określenie różnorodnych ograniczeń (asercji, warunków wstępnych, warunków końcowych), przy których działa, określenie innych bytów, z którymi dany byt musi współdziałać, itd.

spowodować wyjątek (raise exception) Patrz: podnieść wyjątek.

spójność (consistency) Zgodność danych i procesów przetwarzania z biznesem, dla którego dedykowany jest system. Spójność jest innym pojęciem niż integralność. Np. baza danych jest integralna (formalnie poprawna), jeżeli pewien haker zmniejszy nasze konto przepisując odpowiednią sumę na swoje konto; natomiast zarówno stan bazy danych, jak i proces, który do tego doprowadził, określa się jako niespójność. Niespójność bazy danych może być skutkiem utraty jej integralności, awarii (błędów), braku ochrony przed przypadkowymi działaniami użytkowników, lub braku ochrony przed celowym działaniem osób zmierzających do pozbawienia jej spójności.

sprawdzian (benchmark) Zestaw testów, danych, próbnych zadań, próbnych przebiegów pozwalający ustalić i porównać parametry eksploatacyjne pewnego sprzętu lub oprogramowania. Zwykle testowana jest ogólna wydajność (szybkość działania), średni czas reakcji systemu na wprowadzone zapytanie, średnia bezawaryjność, itd. Istnieje szereg standardowych sprawdzianów, które były używane np. do oceny szybkości działania systemów zarządzania bazami danych. Terminem sprawdzian określa się także konkretną czynność przeprowadzenia takiej próby. Synonim: benczmark.

http://www.sbu.ac.uk/~csse/publications/OOMetrics.html

http://www.comsoft.southern.edu/

http://www.cs.city.ac.uk/homes/akmal/biblio.html

http://www.mccabe.com

sprytny wskaźnik (smart pointer) Termin C++ oznaczający wskaźnik, który zachowuje się jak normalny wskaźnik, ale operacje na takim wskaźniku wykorzystują zdefiniowane przez programistę operatory, które przeciążają (overload) wbudowane operatory działające na wskaźnikach. Sprytne wskaźniki są zwykle implementowane poprzez klasy szablonowe. Przykładem zastosowania sprytnych wskaźników są wskaźniki operujące na obiektowej bazie danych, które z punktu widzenia programisty zachowują się tak samo, jak wskaźniki obiektów w pamięci operacyjnej. Innym przykładem jest zadeklarowanie sprytnego wskaźnika uwzględniającego metodę zliczania referencji; w tym przypadku podstawienie sprytnego wskaźnika na pewną zmienną wskaźnikową X oznacza odjęcie 1 od licznika referencji obiektu, na który wskazywała zmienna X i dodanie 1 do licznika obiektu wskazywanego przez sprytny wskaźnik.

SQA (Software Quality Assurance) Zapewnienie jakości oprogramowania.

SQL (Structured Query Language) Najbardziej znany język zapytań, zaimplementowany w większości systemów relacyjnych, bardzo często stanowiący wzorzec odniesienia w literaturze poświęconej obiektowości. Podstawą języka jest zdanie

select <lista wynikowa> from <ciąg nazw tablic> where <warunek>

gdzie select, from, where są słowami kluczowymi. Semantyka tego zdania jest bardzo prosta: oblicza się produkt kartezjański wszystkich tablic wymienionych po from, odrzuca się z niego te wiersze, które nie spełniają warunku po where, następnie każdy pozostały wiersz skraca się (operator projekcji), pozostawiając tylko elementy wymienione w liście wynikowej po select; np.

select Prac.Nazwisko, Dział.Nazwa

from Prac, Dział

where Prac.Zawód = ‘tokarz’ and Prac.NrDziału = Dział.NrDziału

Tę podstawową konstrukcję wyposażono w szereg dodatkowych możliwości zwiększających moc wyszukiwawczą, m.in. grupowanie, warunki na grupach, zagnieżdżanie, porządkowanie, funkcje zagregowane, funkcje i operatory arytmetyczne, itd. SQL zawiera także operacje tworzenia i usuwania tablic, wstawiania, usuwania i aktualizacji wierszy, oraz inne operacje na środowisku bazy danych. SQL jest używany jako samodzielny język służący do interakcyjnych zapytań i aktualizacji. Jest również używany w wersji zanurzonej (embedded) w klasyczne języki programowania, np. C, Cobol lub PL/1. Istnieją różnorodne mutacje SQL, np. PL/SQL systemu Oracle lub konstrukcje języków czwartej generacji. SQL jest przedmiotem standardu ANSI oraz ISO. Istnieje kilka wersji tego standardu; starsza (SQL-89), obecna (SQL-92) oraz opracowywana (SQL3). SQL jest rozszerzany dla innych modeli, w szczególności dla obiektowych i obiektowo-relacyjnych baz danych. SQL jest także przedmiotem krytyki dotyczącej jego eklektyzmu (powstałego w konsekwencji oddolnego rozwoju), wielu jego kontrowersyjnych rozwiązań, niepełności opisu semantyki, oraz ubóstwa i nieporadności koncepcyjnej (braku ortogonalności, modularności, programistycznych abstrakcji, statycznej kontroli typów, reguł zakresu dla nazw, oraz innych współczesnych środków programistycznych). Konstrukcje składniowe SQL (a raczej niektóre jego syntaktyczne stereotypy) są wykorzystane w języku zapytań OQL wg standardu ODMG (ale podstawy semantyczne OQL i SQL są zasadniczo różne). Patrz też: SQL3, OQL.

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

http://www.mcjones.org/System_R/SQL_Reunion_95/

SQL3 Nowy standard języka SQL, opracowywany przez ANSI (American National Standard Institute) oraz ISO, następca i rozszerzenie SQL-92. W założeniu, ma to być uniwersalny język programowania dla relacyjnych baz danych z elementami obiektowości. Specyfikacja SQL3 przewiduje wspomaganie dla zdefiniowanych przez użytkownika abstrakcyjnych typów danych (ADT), włączając w to metody, identyfikatory obiektów, podtypy i dziedziczenie, polimorfizm i integrację z językami zewnętrznymi. Pewne usprawnienia zostały także dodane do konstrukcji definiujących tablice (relacje), w szczególności typy wierszy, identyfikatory wierszy oraz mechanizm dziedziczenia. Dodatkowe udogodnienia włączają struktury sterujące i typy parametryzowane; czyni to z SQL3 uniwersalny język programowania do tworzenia, utrzymywania i wyszukiwania trwałych obiektów. Jednocześnie, deklarowana jest kompatybilność „w dół” ze standardem SQL-92. Każda tablica w SQL3 ma predefiniowaną kolumnę (nazwaną IDENTITY), która zawiera identyfikatory jej wierszy. Daje to możliwość używania tych identyfikatorów w innych tablicach, czyli de facto tworzenia powiązań wskaźnikowych. Abstrakcyjne typy danych oznaczają, że wartości przechowywane w ramach tablic użytkownik może skojarzyć z metodami; w takim przypadku wartości te nie są dostępne bezpośrednio, lecz wyłącznie poprzez te metody, co stanowi istotę hermetyzacji. Metody mogą być pisane w SQL3 lub w innych językach. Możliwe jest deklarowanie atrybutów obliczanych (lub inaczej, metod funkcyjnych). Dla dowolnej zadeklarowanej tablicy można zadeklarować podtablicę, która zawiera wszystkie kolumny macierzystej tablicy plus niektóre nowe kolumny. Jak dotąd, rozszerzenia te są redundantne i niezbyt spójne. Standard znajduje się w fazie opracowywania i będzie gotowy przypuszczalnie w połowie roku 1999 (według ostatnich zapowiedzi).

Kontrowersje wzbudza ogromna objętość tego standardu (obecnie przekracza 1100 stron, plus dodatki), spowodowana nagromadzeniem różnych pomysłów bez klarownie wyartykułowanego modelu danych i podstawy ideologiczno-teoretycznej. Sceptycy podkreślają, że jak dotąd w historii żadna specyfikacja języka przekraczająca 1000 stron nie została w pełni zaimplementowana. Równie kontrowersyjne jest podjęcie prac badawczo-rozwojowych w zakresie konstrukcji języka programowania baz danych przez ciało standardyzacyjne, statutowo powołane do innych celów i posiadające inne kompetencje. Istniała koncepcja integracji języków SQL3 i OQL wg standardu ODMG, ale prace integracyjne zostały zaniechane.

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

stan (state) Aktualna kombinacja wartości wszystkich zmiennych (trwałych i ulotnych), wartości wszystkich obiektów (trwałych i ulotnych), wartości zmiennych środowiskowych, wartości licznika instrukcji lub aktualny punkt sterowania programu, zawartości stosu środowisk, itd. W skład stanu wchodzą wszystkie byty programistyczne istniejące w czasie wykonania, które w jakikolwiek sposób mogą wpłynąć na wartość dowolnego wyrażenia, zapytania, funkcji, lub wpłynąć na dalszy przebieg sterowania programu. Dość często abstrahuje się od pewnych składników stanu; np. w diagramach STD abstrahuje się od wszystkich składników stanu, z wyjątkiem aktualnego punktu sterowania programu.

stan końcowy (final state) Określenie stanu w diagramach stanów, w którym następuje zakończenie wszelkich akcji. Może być wiele stanów końcowych.

stan obiektu (object state) Aktualna kombinacja wszystkich wartości przechowywanych wewnątrz obiektu; zmiana dowolnej z nich oznacza zmianę stanu obiektu.

stan początkowy (initial state) Określenie stanu w diagramach stanów, w którym rozpoczyna się działanie opisywane tym diagramem. Zwykle jest jeden stan początkowy.

standard faktyczny (defacto standard) Standard przyjęty nieformalnie, w wyniku porozumienia pomiędzy firmami lub w wyniku narzucenia pewnego rozwiązania przez jedną dominującą firmę. Standardem faktycznym są np. standardy OMG (CORBA), UML, ODMG, COM/DCOM, OpenDoc, gdyż nie zostały one zatwierdzone przez odpowiednie instytucje standardyzacyjne.

standard prawny (dejure standard) Standard zatwierdzony przez instytucje standardyzacyjne takie jak ISO i ANSI. Standardem prawnym jest np. ASCII, SQL-92. Będzie nim też (po zakończeniu prac i zatwierdzeniu) SQL3. Należy podkreślić, że standardy prawne nie muszą wpływać na rynek, gdyż nie istnieją przepisy wykonawcze, które obligowałyby wytwórców oprogramowania do ścisłego trzymania się standardów. Z tego powodu różnica pomiędzy standardem prawnym i faktycznym ma znaczenie drugorzędne, bardziej marketingowo-reklamowe niż prawne. Należy również podkreślić, że wskutek ogromnej złożoności tworów technologii informatycznych (np. języków), standardy nie są w stanie wyspecyfikować z absolutną precyzją ich semantyki; dotyczy to np. SQL. Poważnym zarzutem w stosunku do oficjalnych ciał standardyzacyjnych (takich jak ANSI) jest to, że ich polityka nie jest marketingowo neutralna: jest ona preferencyjna dla niektórych firm komercyjnych, ze szkodą dla innych firm; zarzut ten dotyczy np. rozwoju języka SQL3.

Starburst Prototyp systemu obiektowo-relacyjnego zbudowany przez IBM, nie rozpowszechniany na rynku.

statyczna funkcja członkowska (static member function) Termin C++; statycznie wiązana funkcja zdefiniowana w ramach klasy.

statyczna klasyfikacja (static classification) Przypisywanie obiektu do klasy w momencie jego utworzenia, brak możliwości zmiany klasy obiektu.

statyczna kontrola typów (static type checking, static typing) Kontrola typów mająca miejsce podczas czasu kompilacji; patrz też: mocna kontrola typów.

statyczne wiązanie (static binding) Wiązanie nazw występujących w programie, które ma miejsce podczas kompilacji.

statyczny polimorfizm (static polymorphism) Patrz: przeciążanie.

STD (State Transition Diagram) Diagram stanów, diagram zmiany stanów; termin OMT i UML.

stempel czasowy (time stamp) Pole zawarte w pewnym bycie programistycznym (obiekcie, transakcji, zdarzeniu, itd.), do którego wpisywany jest bieżący czas wykonania pewnej operacji. Precyzja stempla czasowego powinna umożliwić rozróżnienie dowolnych dwóch operacji na podstawie wartości stempla. Stemple czasowe są używane w różnych technikach, np. w przetwarzaniu transakcji, dla ustalenia kolejności zdarzeń, momentu ostatniej aktualizacji obiektu, itd.

stereotyp (stereotype) W terminologii UML, metaklasyfikacja elementów modelu, np. klas, posiadająca semantyczne konsekwencje. Np. w metodyce Objectory (Jacobsona) wprowadzono trzy rodzaje obiektów: obiekty interfejsu (interface objects), obiekty sterujące (control objects) i obiekty rzeczywiste (entity objects). Te rodzaje obiektów miały swoje odbicie w graficznych ikonach oznaczających klasy. Pomysł ten został w UML uogólniony. Stereotypy mają tam specjalne oznaczenie (ciągi znaków wewnątrz nawiasów « »; np. «control object»). Stereotypy mogą być predefiniowane lub zdefiniowane przez użytkownika. Są one pewnymi oznaczeniami graficznymi na diagramach, których celem jest podniesienie czytelności i jasności diagramów, przystosowanie ich do konkretnej dziedziny zastosowań (np. medycyny, elektrotechniki, telekomunikacji, CAD, itd.), lub przystosowanie do tradycyjnych oznaczeń już stosowanych w tych dziedzinach. Niżej prezentujemy dwa oznaczenia stereotypów dla obiektów Klient: pierwsze w postaci ciągu znaków «aktor», drugie w postaci ikony.

Oznaczenia stereotypów

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

sterowanie dostępem (access control) Mechanizm ograniczający dostęp do zasobów, funkcji lub usług systemu dla poszczególnych użytkowników. Niekiedy tym terminem oznacza się także reguły hermetyzacji (np. dostęp do publicznych zasobów dla wszystkich, do chronionych tylko przez klasy podrzędne, zaś do prywatnych tylko przez klasy zaprzyjaźnione).

sterowanie wersjami (version control) Zarządzanie różnymi odmianami danego produktu programistycznego. Wersje mogą dotyczyć mutacji danego produktu związanych z różnymi platformami, na których ma pracować, mutacji danego produktu związanych z różnicami w wymaganiach użytkowników, oraz mutacji danego produktu związanych z jego rozwojem i pielęgnacją. Sterowanie wersjami powinno odwzorować zależność (np. czasową) pomiędzy poszczególnymi wersjami produktu, zarządzać częściami wspólnymi dla wielu wersji, umożliwić równoległą pracę wielu uczestników projektu tworzących nowe wersje, oraz odwzorować zależność wersji od uczestników projektu, klientów, platform, zastosowań, itd. Sterowanie wersjami uważa się za poważny problem technologiczny. Wiele obiektowych baz danych posiada (lub planuje) specjalne środki wspomagające sterowanie wersjami.

sterowany zdarzeniami (event-driven) Określenie techniki programowania (oraz rodzaju języków programowania) polegającej na wyróżnianiu zdarzeń zachodzących w środowisku programu (np. naciśnięcie klawisza Esc, kliknięcie myszką przycisku OK) oraz przyporządkowywaniu tym zdarzeniom sekwencji instrukcji programu, czyli bloków obsługi zdarzeń. Blok obsługi zdarzenia jest uruchamiany w momencie wystąpienia odpowiadającego mu zdarzenia. Programowanie sterowane zdarzeniami stanowi częsty paradygmat w programowaniu wizyjnym oraz w językach czwartej generacji (4GL).

sterta (heap) Obszar w pamięci operacyjnej służący do dynamicznego alokowania i zwalniania pewnych bloków pamięci. W językach programowania (takich jak C/C++) służy ona do alokowania i zwalniania (funkcje malloc i free) wszystkich takich obszarów, których rozmiar lub struktura nie daje się przewidzieć w momencie pisania programu. Sterta powinna być powiązana z automatycznym zbieraniem nieużytków (garbage collection). Brak tego mechanizmu jest przyczyną tzw. wyciekania pamięci (memory leak), tj. zapełniania sterty już niepotrzebnymi, lecz nie usuniętymi obiektami, przez co program znacznie zwalnia pracę (i w końcu zawiesza się). Uważa się, że sterta jest pojęciem zbyt niskiego poziomu, które powinno być wyeliminowane z języków programowania na rzecz dynamicznego powoływania lokalnych zmiennych w procedurach, metodach itd. (które są następnie automatycznie usuwane po zredukowaniu stosu środowisk). Najczęstszymi przyczynami, z powodu których programiści są zmuszenie do używania sterty, jest brak lub ograniczenie w języku typów/wartości masowych (kolekcji), takich jak zbiór, wielozbiór, sekwencja i tablica dynamiczna, oraz brak typów prymitywnych o zmiennym formacie, takich jak string, bitmap, itd.

stos środowisk (environment stack, environmental stack) Struktura danych będąca podstawowym mechanizmem implementacji większości języków programowania (w tym obiektowych). Stos ten składa się z środowisk lub tzw. rekordów aktywacji (activation records). Każdy rekord aktywacji odpowiada pojedynczemu wywołaniu procedury, funkcji lub metody i może zawierać: (1) pola zawierające wartości aktualnych parametrów; (2) pola zawierające wartości wszystkich lokalnych zmiennych lub obiektów deklarowanych (lub tworzonych) w danej procedurze (funkcji, itd.); (3) ślad wołania, czyli miejsce, do którego ma wrócić sterowanie po zakończeniu danej procedury (funkcji, itd.) (4) referencję do obiektu będącego adresatem komunikatu (wiązanie do pseudozmiennych self lub this). Wywołanie danej procedury (funkcji, itd.) oznacza włożenie na wierzchołek stosu jej rekordu aktywacji (i następnie przekazanie sterowania do jej kodu), zaś zakończenie procedury (funkcji, itd.) oznacza usunięcie z wierzchołka stosu jej rekordu aktywacji (i następnie przekazanie sterowania zgodnie ze śladem zawartym w tym rekordzie). Stos środowisk jest podstawowym mechanizmem ustalania zakresu nazw w programie, bezpiecznego alokowania zmiennych lokalnych, technik przekazywania parametrów oraz wiązania nazw występujących w tekście programu. Jest on prostym i uniwersalnym mechanizmem umożliwiającym realizowanie wołań rekurencyjnych. W podejściu stosowym do obiektowych języków zapytań stos środowisk pełni podstawową rolę, jako mechanizm realizujący semantykę podstawowych operatorów, takich jak selekcja, projekcja, nawigacja, nawigacyjne (zależne) złączenie i kwantyfikatory. Stos środowisk występuje zwykle w dwóch postaciach: stosu statycznego, który jest zarządzany podczas kompilacji w celu ustalenia tzw. zakresu leksykalnego (lexical scope) i statycznego wiązania nazw, oraz stosu dynamicznego, który jest zarządzany w czasie wykonania i zawiera rekordy aktywacji. Patrz też: reguły zakresu.

stos wołań (call stack) Patrz: stos środowisk.

strategia od dołu do góry (bottom-up strategy) „Od szczegółu do ogółu”. Strategia projektowania lub konstruowania oprogramowania polegająca na tym, że początkowe decyzje dotyczą szczegółów, następnie szczegóły zamyka się w coraz większe bryły, podnosząc przy tym poziom abstrakcji. Podstawową wadą strategii od dołu do góry jest konieczność ciągłej weryfikacji szczegółowych ustaleń w momencie integrowania szczegółów w większą całość.

strategia od góry do dołu (top-down strategy) „Od ogółu do szczegółu”. Strategia projektowania lub konstruowania oprogramowania polegająca na tym, że początkowe decyzje dotyczą najbardziej ogólnego, abstrakcyjnego poziomu, który następnie precyzuje się poprzez podejmowanie coraz bardziej szczegółowych decyzji. Strategia od góry do dołu jest (często niejawnym) założeniem lub zaleceniem wielu metodyk projektowania i konstruowania oprogramowania.

strategia od środka na zewnątrz (inside-out strategy) „Od rzeczy najważniejszych do całości”. Strategia projektowania lub konstruowania oprogramowania polegająca na tym, że początkowe decyzje koncentrują się na rzeczach najważniejszych, stanowiących o misji projektowanego systemu lub oprogramowania. Po podjęciu tych decyzji kolejno dołącza się do projektu elementy drugorzędne (jakkolwiek również istotne). Strategia od środka na zewnątrz jest zwykle łączona ze strategią od góry do dołu.

strażnik (guard) Określenie warunku boolowskiego, który zapobiega wejściu programu w nieskończoną pętlę. Często jest to również synonim asercji.

Stroustrup, Bjarne Główny twórca i propagator języka C++.

struktura (structure) Termin C++ na oznaczenie zestawu nazwanych wartości; inaczej zapis lub rekord.

struktura klas (class structure) Graf, którego węzłami są klasy, zaś krawędzie wyznaczają związki dziedziczenia. Patrz też: hierarchia klas, krata klas.

struktura obiektów (object structure) Graf, którego węzłami są obiekty, zaś krawędziami powiązania pomiędzy obiektami.

strukturalna równoważność typów (structural type equivalence) Patrz: strukturalna zgodność typów.

strukturalna zgodność typów (structural type conformance) Reguła zgodności typów ustalająca, że typ T1 bytu programistycznego (np. wyrażenia - parametru aktualnego metody) wydedukowany na podstawie reguł wnioskowania o typie (type inference rules) jest zgodny z zadeklarowanym typem T2 dla tego bytu (np. parametru formalnego metody), o ile dowolny element ekstensji typu T1 (czyli wartość zgodna z T1) należy także do ekstensji typu T2. Przykładowo, jeżeli mamy deklaracje:

typedef T1= int;

typedef T2 = int;

T1 X;

T2 Y = 1;

to wówczas (przy strukturalnej zgodności typów) podstawienie X=Y jest typologicznie poprawne, gdyż T1 i T2 są dokładnie tym samym typem. Strukturalną zgodność typów przeciwstawia się nazwowej zgodności typów, przy której podstawienie X=Y jest niepoprawne, gdyż nazwy typów tych zmiennych są różne. W obiektowości przyjmuje się zwykle strukturalną zgodność typów, jakkolwiek prowadzi ona do anomalii i jest koncepcyjnie wątpliwa.

studium osiągalności (feasibility study) Analiza zmierzająca do stwierdzenia, czy dane przedsięwzięcie organizacyjne lub techniczne jest wykonalne przy założonych środkach, celach i ograniczeniach. Synonim: faza strategiczna.

super W terminologii języka Smalltalk pseudozmienna odwołująca się do nadklasy danego obiektu. W odróżnieniu od self, super oznacza, że poszukiwanie metody zaczyna się nie od klasy obiektu, który otrzymał komunikat, lecz od jej nadklasy.

superklasa (superclass) Patrz: nadklasa.

surogat (surrogate) Identyfikator obiektu generowany przy pomocy algorytmu zapewniającego jego unikalność; inaczej identyfikator logiczny.

Sybase Adaptive Server Obiektowo-relacyjny system zarządzania bazą danych.

sygnatura (signature) Specyfikacja metody lub operacji zawierająca:

  • nazwę;
  • nazwy, typy i kolejność jej parametrów (argumentów);
  • typ zwracanego wyniku;
  • nazwy powodowanych wyjątków.

Sygnatura niekiedy zawiera też inne informacje. Sygnatury mają znaczenie dla modelowania pojęciowego (ustalają wejście i wyjście danej metody lub operacji) oraz są wykorzystywane przez mechanizm mocnej kontroli typów. Niżej podajemy sygnaturę metody wystaw_ocenę (która może być np. fragmentem definicji klasy PROFESOR):

boolean wystaw_ocenę(     in short jaką,

                                                              in Wykład z_czego,

                                                              inout Student komu )

                                              raises( student_nie_był_zapisany );

Typ wyniku metody określony jest jako boolean. Metoda posiada dwa parametry wejściowe (in): jaką i z_czego oraz jeden wejściowy i wyjściowy (inout): komu; typy tych parametrów to odpowiednio short, Wykład i Student. Sygnatura ustala, że ta metoda może spowodować wyjątek o nazwie student_nie_był_zapisany.

synchroniczny (synchronous) Określenie procesu lub wątku (przebiegu), który nie działa równolegle z innymi przebiegami. Przebieg synchroniczny blokuje sterowanie programu aż do swojego zakończenia.

synchronizacja (synchronization) Reguły umożliwiające jednoczesną (równoległą) pracę wielu procesów, których celem jest przeciwdziałanie niekorzystnym interferencjom procesów. Synchronizacja ustala podział zasobów krytycznych środowiska komputerowego (np. danych, pamięci operacyjnej, ekranu, klawiatury, czasu procesora, dostępu do linii transmisyjnych, itd.) pomiędzy poszczególne procesy,

syndrom NIH (Not-Invented-Here syndrome) Syndrom „nie wynaleziono tutaj”. Czynnik psychologiczny przeszkadzający ponownemu użyciu. Polega nad tym, że twórcy oprogramowania świadomie lub podświadomie unikają stosowania aktywów ponownego użycia, które nie powstały w ich zespole.

system aktywny (reactive system, active system) System zawierający aktywne reguły, aktywnych agentów lub aktywne obiekty. Patrz też: aktywny SZBD.

system informacji geograficznej (GIS, Geographic Information System) Geograficzny system informacyjny. System przechowujący informację o pewnym terytorium (zwykle mapy o różnej skali, przeznaczeniu, poziomie szczegółowości i typie odwzorowanej informacji), oraz przetwarzający i udostępniający tę informację w postaci wizualnej. GIS jest potencjalnym polem zastosowań technologii obiektowych.

system otwarty (open system) Patrz: otwarty system.

system zarządzania bazą danych, SZBD (database management system, DBMS) System oprogramowania zawierający w szczególności następujące mechanizmy:

  • środki do gromadzenia, utrzymywania i administrowania trwałymi i masowymi zbiorami danych;
  • środki zapewniające spójność i bezpieczeństwo danych;
  • sprawny dostęp do danych (zwykle poprzez język zapytań);
  • środki programistyczne służące do aktualizacji/przetwarzania danych (API dla popularnych języków programowania);
  • jednoczesny dostęp do danych dla wielu użytkowników (z reguły, realizowany poprzez transakcje);
  • środki pozwalające na regulację dostępu do danych (autoryzację);
  • środki pozwalające na odtworzenie zawartości bazy danych po awarii;
  • środki do zarządzania katalogami, schematami i innymi metadanymi;
  • środki optymalizujące zajętość pamięci oraz czas dostępu (np. indeksy);
  • środki do pracy lub współdziałania w środowiskach rozproszonych.

Systemy zarządzania bazami danych często posiadają wiele innych mechanizmów, np. zarządzanie wersjami i danymi temporalnymi, przechowywanie i udostępnianie danych multimedialnych, wygodne (wizyjne) środowiska do tworzenia aplikacji, pomosty do współpracy z innymi systemami, wspomaganie dla perspektyw, zapamiętanych procedur i aktywnych reguł, pakiety statystyczne, pakiety dla przeprowadzania analiz (eksploracji danych), pakiety do tworzenia hurtowni danych, środki udostępniające bazę danych w sieci Internet, itd.

system zarządzania bazą wiedzy (Knowledge Base Management System, KBMS) System, który oprócz pasywnych danych zawiera także reguły, które są automatycznie wykorzystywane przy realizacji zapytań lub zleceń. Różnica pomiędzy systemem zarządzania bazą wiedzy i systemem zarządzania bazą danych jest oparta na powierzchownych, technicznych cechach, takich jak możliwość zastosowania logiki matematycznej w procesie ewaluowania zapytań. Intelektualna lub „naukowa” przewaga baz wiedzy nad bazami danych (sugerowana przez termin „wiedza”) nie istnieje, ponieważ systemy baz danych od dawna posiadają różnorodne elementy, które można uważać za reguły lub ich równoważniki. Termin „baza wiedzy” jest używany przez osoby zajmujące się sztuczną inteligencją, które zwykle nie są świadome obecnego stanu sztuki w bazach danych. Przez to ulegają złudzeniu, że „bazy wiedzy” są wyższym szczeblem intelektualnego zaawansowania. W istocie, siermiężne, mało uniwersalne i nieefektywne metody (takie jak „reguły dedukcyjne”, „klauzule Horna”, „logiki niemonotoniczne”, itd.) oparte na pomysłach teoretycznych są daleko w tyle za obecnym intelektualnym i technicznym zaawansowaniem systemów baz danych.

szablon (template) Termin C++ na oznaczenie dowolnej parametryzowanej metaklasy lub funkcji. Szablon ustala rodzinę klas. Szablony są jedną z form polimorfizmu parametrycznego i wzmacniają możliwości ponownego użycia. Terminem nieco ogólniejszym od szablonu jest generalium (generics).

SZBD (DBMS) Patrz: System Zarządzania Bazą Danych.

szeregowalność (serializability) Kryterium poprawności mechanizmu transakcji. Szeregowalność oznacza, że współbieżne wykonanie transakcji jest poprawne wtedy i tylko wtedy, jeżeli jego efekt jest dokładnie taki sam jak efekt wykonania tych transakcji pojedynczo po kolei. Istnieje matematyczna teoria szeregowalności transakcji; są jednak opinie, że jest ona mało przydatna, ponieważ dla bardziej skomplikowanych mechanizmów transakcji nic nie da się udowodnić (konieczna jest implementacja i symulacja). Istnieją też opinie, że teoria szeregowalności nie obejmuje ważnych przypadków (takich jak usuwanie danych) oraz jest oparta na zbytnio uproszczonych założeniach. W ostatnich 15-tu latach, mimo wielu nowych propozycji mechanizmów przetwarzania transakcji, nie jest szerzej znany w literaturze dowód ich poprawności korzystający z teorii szeregowalności. Szeregowalność funkcjonuje więc w literaturze (również komercyjnej) wyłącznie jako pewien stereotyp, legenda lub „naukowa" dekoracja.

szeregowanie (marshalling) Zamiana komunikatu lub wołania procedury (wraz z argumentami) na sekwencję znaków w odpowiednim formacie, który jest odpowiedni do przesłania poprzez sieć. Odwrotny proces, który odbywa się w odległym węźle, nazywa się rozszeregowanie (unmarshalling). Szeregowanie i rozszeregowanie jest niezbędne w systemach opartych o wołanie odległej procedury (RPC) oraz przy dostępie do odległych obiektów (np. obiektów znajdujących się pod kontrolą pośrednika wg standardu CORBA).

szkielet [1] (framework) Zestaw klas stanowiący abstrakcyjny projekt odpowiadający rozwiązaniu pewnej grupy podobnych problemów. Termin występuje również jako oznaczenie prefabrykowanych bloków oprogramowania, które programista może używać, rozszerzać lub przystosowywać do specyficznych potrzeb tworzonej aplikacji. Szkielety są jednostką ponownego użycia (reuse). Pojęcia szkieletu i pojęcia biblioteki klas są znaczeniowo dość podobne, z tym, że szkielet przewiduje również opis kontekstu w którym dane klasy mogą być użyte.

http://www.eden.com/~msm/fwlist

http://www.hk-r.se/ide/frameworks/frameworks.html

http://g.oswego.edu/dl/rp/roles.html

http://st-www.cs.uiuc.edu/users/johnson/frameworks.html

szkielet [2] (skeleton) Termin OMG CORBA. Oznacza automatycznie generowany kod w konkretnym języku programowania (np. w C++) po stronie serwera obiektów; jest on tworzony z wyrażenia IDL. Taki szkielet programista musi zapełnić fragmentami kodu stanowiącymi implementację metod wyspecyfikowanych w tym wyrażeniu IDL.

http://www.omg.org

szklana skrzynka (glass box) Patrz: biała skrzynka.

szybka budowa aplikacji (Rapid Application Development, RAD) Patrz: RAD.

szybka budowa prototypów aplikacji (Rapid Application Prototyping, RAP) Patrz: RAP.

ścieżka dostępu (access path) Ogólnie, metoda fizycznego wyszukania żądanych danych. Np. ścieżką dostępu nazywa się metodę polegającą na kolejnym przeglądaniu elementów pewnego zbioru, dostęp poprzez indeks, poprzez tablicę mieszającą, itd.

ścieżka przejścia (traversal path) Sposób przejścia od pewnych obiektów do innych obiektów wykorzystujący hierarchię obiektów oraz powiązania (referencje) między nimi. Np. ścieżka przejścia pomiędzy obiektem x klasy Pracownik i jego szefem może mieć postać: x.PracujeW.Firma.Szef.Pracownik, gdzie PracujeW i Szef związkami pomiędzy klasami Pracownik i Firma.

środowisko [1] (environment) Termin ogólny, oznaczający sprzęt, oprogramowanie, narzędzia, biblioteki, usługi, infrastrukturę i organizację niezbędne dla działania pewnej aplikacji. W podobnym sensie, środowisko programistyczne obejmuje kompilator pewnego języka programowania, edytory, debuggery, przeglądarki, biblioteki, itd. umożliwiające efektywną produkcję oprogramowania.

środowisko [2] (environment) W terminologii języków programowania, zestaw zmiennych i innych bytów programistycznych, w których jest wykonywany dany program. Środowiska w programach posiadają hierarchię i organizację: wyróżnia się globalne środowisko, zawierające byty programistyczne dostępne dla wszystkich procedur, środowisko bazy danych zawierające obiekty trwałe, środowisko lokalne danej procedury zawierające (zwykle) jej lokalne zmienne lub obiekty oraz parametry, środowisko modułu, środowisko danej klasy lub obiektu zawierające atrybuty (zmienne wystąpienia) i metody, itd. Zarządzanie istnieniem i dostępem do poszczególnych środowisk, ustalanie zakresu nazw występujących w programie oraz wiązanie tych nazw do bytów programistycznych z różnych środowisk jest zwykle oparte o koncepcję stosu środowisk. Terminologia nie jest tu jednoznaczna, niekiedy środowiskiem nazywa się także całość stosu środowisk lub określony jego fragment.

T

tabela (table) Struktura danych implementowana w relacyjnych systemach baz danych, często nazywana relacją. Tabela składa się z wierszy lub inaczej krotek. Należy zwrócić uwagę, że pomiędzy relacją (w sensie matematycznym) i tabelą występują dość istotne różnice koncepcyjne; w szczególności, w odróżnieniu od relacji tabela jest wyposażona w nazwy kolumn (które niosą informację semantyczną), tabela może zawierać identyczne wiersze, tabela określa porządek wierszy, oraz dostęp do wiersza tabeli może nastąpić poprzez podanie jego numeru. Różnice te powodują, że teorie relacyjne często są nieadekwatne do konstrukcji relacyjnych baz danych i języków zapytań (SQL i jego pochodnych).

tablica (array, table) Często synonim tabeli w systemach relacyjnych. W językach programowania termin ten oznacza strukturę danych tego samego typu, której elementy są indeksowane liczbami całkowitymi (ale nie jest to reguła, istnieją koncepcje indeksowania tablic dowolnymi typami). Dostęp do elementu tablicy następuje poprzez podanie nazwy tablicy oraz indeksu elementu (indeksów elementu, w przypadku tablicy wielowymiarowej).

tablica asocjacyjna (associative table) Określenie tablicy w schemacie relacyjnym, realizującej związek (relationship, association) pomiędzy dwoma lub więcej tablicami. Tablica taka zawiera zwykle klucze obce (klucze główne innych relacji).

tablica dynamiczna (dynamic array) W standardzie ODMG, kolekcja czyli konstruktor typów masowych. Tablica dynamiczna jest podobna do sekwencji, z możliwością dowolnego rozszerzania na końcu oraz z dostępem poprzez indeks wiersza tablicy.

tablica pośrednia (indirection table) Tablica niezbędna do implementacji logicznych identyfikatorów obiektów. Wiersze tej tablicy zawierają pary <identyfikator obiektu, adres obiektu> i umożliwiają odszukanie obiektu w przestrzeni pamięci komputera na podstawie jego identyfikatora logicznego. Wierszy tych musi być tyle, ile jest obiektów. Wadą jest objętość tablicy, która (przy długich identifikatorach i długich adresach) byłaby porównywalna z objętością samych obiektów. Drugą wadą jest wydłużony dostęp do obiektów, który musiałby być podzielony na dwa etapy: dostęp do tablicy i dostęp do samego obiektu. Trzecią wadą jest to, że taka tablica stanowiłaby wąskie gardło dla przetwarzania transakcji, gdyż każda transakcja musiałaby odwoływać się do tej tablicy, zaś w przypadku aktualizacji (wstawiania, usuwania lub przesuwania obiektów) jedna transakcja mogłaby zablokować wiele innych transakcji. Czwartą wadą jest to, że taka tablica musiałaby być przedmiotem składowania (back up) i odtwarzania po awarii (recovery), co oczywiście znacznie skomplikowałoby odpowiednie algorytmy i zmniejszyłoby ogólną efektywność systemu. Podane wady kwalifikują w zasadzie pojęcie identyfikatora logicznego jako niezbyt rozsądne. Jest to zasadniczy powód, dla którego systemy O2, Objectivity/DB i Exodus nie stosują logicznych identyfikatorów. Niemniej wielu autorów uważa identyfikatory logiczne za niezbędną cechę obiektowych baz danych. Systemy Versant, GemStone i ObjectStore stosują logiczne identyfikatory; system Itasca (Orion) stosuje rozwiązanie kompromisowe.

TAPOS (Theoretical And Practial Aspects of Object Systems) Czasopismo z zakresu systemów obiektowych.

technika modelowania obiektów (Object Modeling Technique, OMT) Patrz: OMT.

teoretyczny masochista (theoretical masochist) Termin J. Rumbaugha oznaczający osobę próbującą (bezskutecznie) stosować w inżynierii oprogramowania metody matematyczne.

teoretyczny terrorysta (theoretical terrorist) Osobnik dość utytułowany i wpływowy, którego kariera była oparta na rozwijaniu i propagowaniu zmatematyzowanych teorii (patrz: pseudoteoria). Teorie te nazywa matematycznymi podstawami informatyki i jest przekonany o ich fundamentalnej roli w rozwoju (mimo braku faktów potwierdzających i mimo ewidentnych faktów przeczących tej tezie). Informatykę uważa za jeden z działów matematyki. W jego wyobrażeniu informatyka rozwija się harmonijnie od wielkich matematycznych teorii, poprzez twierdzenia udowadniane w ciszy naukowych gabinetów, poprzez biura projektowe, gdzie zwyczajni rzemieślnicy (nie naukowcy!) przerabiają te twierdzenia na projekty oprogramowania, wreszcie poprzez wytwórców oprogramowania, które zamieniają je w Windows, Corela, UNIXa, Javę, Oracle i Netscape.

Najdłuższy napisany przez niego program ma rozmiar 5-ciu linijek; dla teoretycznego terrorysty jest on wystarczający, aby nauczać, jak należy budować programy mające 5 milionów linijek. W tym celu pisze podręczniki zatytułowane „Podstawy inżynierii oprogramowania”, „Algebraiczna specyfikacja dla programistów”, itp., gdzie umieszcza odpowiednie pojęcia matematyczne, definicje i twierdzenia (patrz: pseudoteoria). Po ich napisaniu uważa się za Wybitnego Specjalistę z zakresu inżynierii oprogramowania (traktowanej oczywiście jako dyscyplina naukowa, a nie bezładna paplanina różnych DeMarków, Yordonów, czy Boochów). Jako Wybitny Specjalista znajduje miejsce w komitetach, radach i redakcjach, gdzie podejmowane są ważne decyzje. Po nich inżynieria oprogramowania na danym terenie staje się naukowo słuszna, co oznacza, że nie ma na nim miejsca dla tych, którzy splamili się napisaniem programu dłuższego niż 5 linijek („...instytucje naukowe nie mogą przejmować roli biur projektowych...”), zaś stan inżynierii oprogramowania rzeczywistej (w odróżnieniu od urojonej) po 15-tu latach od tych decyzji zaczyna przypominać Saharę, szczególnie w zakresie dydaktyki i samodzielnej kadry naukowej.

Teoretyczny terrorysta przybiera często postawę misjonarza grzmiącego z wysokiej ambony na stojący w dole ciemny informatyczny lud, przestrzegając go przed złem płynącym z zaniedbania metod matematycznych. Nie zniża się do tego, aby zejść z ambony na implementacyjną ziemię i osobiście pokazać na dużym projekcie, jak tego rodzaju metody należy stosować w praktyce (patrz: teoretyczny masochista). Na obronach prac magisterskich, doktoratów i habilitacji teoretyczny terrorysta daje się poznać jako mistrzowski wykonawca tzw. sztuczki z trupem: w pewnym momencie wyciąga znienacka jakiegoś teoretycznego trupa (np. trupa teorii informacji, maszyny Turinga, rachunku lambda, itd.) i potrząsa złowieszczo zakurzonym zewłokiem przed zbielałym z przerażenia kandydatem.

teoretyk (theoretician) Określenie osoby budującej zmatematyzowane teorie, w szczególności teorie dotyczące obiektowości. W informatyce jest to ostatnio określenie pejoratywne (patrz: pseudoteoria, teoretyczny terrorysta, teoretyczny masochista) oznaczające osobę pozbawioną właściwych kompetencji w zakresie informatyki rzeczywistej, budującą scholastyczne, nikomu niepotrzebne pseudoteorie, których jedynym autentycznym celem są kariery naukowe (doktorat, habilitacja, profesura, następny artykuł na następną konferencję). Obecny wizerunek teoretyka jest konsekwencją ignorowania przez niektóre osoby ze środowiska akademickiego osiągnięć informatyki rzeczywistej, i w miejsce tego, generowanie koncepcji teoretycznych, których naukowy i intelektualny potencjał jest podważalny, zaś wpływ na obecną i przyszłą informatyczną rzeczywistość jest pomijalny. Rodzi to ogromne straty potencjału intelektualnego, szczególnie groźne dla krajów biedniejszych, takich jak Polska. Angażowania się części kadry naukowej w rozwój pseudoteorii rodzi też duże frustracje, również wśród samych teoretyków. Można ich uważać za ofiary wieloletniego mitu „matematycznych podstaw informatyki”, który sami stworzyli. Frustracje te mają niekiedy skutek pozytywny; przykładem jest D. Knuth, teoretyczny gigant, który zdobył również sławę jako twórca systemu TEX, czy też F. Bancilhon, znakomity teoretyk, który w pewnym momencie zarzucił teorie na rzecz stworzenia pionierskiego obiektowego systemu zarządzania bazą danych O2.

W pozytywnym sensie (który należałoby w informatyce przywrócić) teoretyk jest osobą budującą użyteczne teorie na podstawie wieloletnich doświadczeń praktycznych, analizy i syntezy wielu pojęć, języków, systemów, metod o bezpośrednim znaczeniu praktycznym. Utrwalony obecnie podział na „teoretyków” (czyli tych, którzy nie posiadają kompetencji praktycznych i używają matematyki dla produkcji scholastycznych, bezużytecznych tworów) i „praktyków” (czyli tych, którzy nie używają matematyki, ale są kompetentni i produkują twory użyteczne) należy odrzucić jako błędny i szkodliwy.

terabajt (terabyte) W powszechnym rozumieniu - 1 000 000 000 000 (1000 miliardów) bajtów. W informatyce obowiązuje atawistyczny stereotyp, zgodnie z którym terabajt jest to 240, czyli 1 099 511 627 776 bajtów. Różnica ok. 10% może być źródłem nieporozumień i konfliktów.

Theta Obiektowy język programowania zaimplementowany w obiektowym systemie zarządzania bazą Thor. Posiada mocną statyczną kontrolę typów i automatyczne zbieranie nieużytków.

http://www.pmg.lcs.mit.edu/Theta.html

this Wskazanie adresata komunikatu (ten). Patrz: self.

Thor Obiektowy system zarządzania bazą danych.

http://www.pmg.lcs.mit.edu/Thor.html

three amigos Trzej przyjaciele. Często spotykane określenie twórców UML: G. Boocha, I. Jacobsona oraz J. Rumbaugha.

TID (Tuple IDdentifier) Patrz: identyfikator krotki.

tłusty klient (fat klient) Patrz: mocny klient.

TOOLS (Technology of Object-Oriented Languages and Systems) Cykliczna konferencja z zakresu obiektowości, organizowana przez Interactive Software Engineering, firmę zajmującą się rozwojem i promocją języka Eiffel.

tożsamość (identity) Tożsamość obiektu oznacza, że obiekt istnieje i jest odróżnialny od innych obiektów niezależnie od jego aktualnego stanu (wartości atrybutów), który może się zmieniać. Obiektowość nie zakłada konieczności określenia takiego atrybutu obiektu (lub kombinacji atrybutów), który identyfikuje go w sposób unikalny (czyli tzw. „klucza głównego" (primary key), znanego z relacyjnego modelu danych). Tożsamość obiektu jest kategorią filozoficzną, która nie jest wiązana z jakimkolwiek zestawem atrybutów obiektu lub jego aktualnym stanem. Możliwe są dwa różne obiekty o identycznych wartościach atrybutów. Praktycznie, tożsamość oznacza istnienie unikalnego wewnętrznego (nic nie mówiącego dla użytkownika) identyfikatora obiektu, który nie ulega zmianie podczas życia obiektu. Tożsamość obiektu jest niezależna od jego lokacji w świecie rzeczywistym lub w przestrzeni adresowej komputera. Czasami to założenie kłóci się z innymi własnościami, np. z koniecznością jednoczesnego pamiętania wielu wersji czasowych tego samego obiektu lub z wymaganiami dotyczącymi wydajności. Patrz też: mrówka.

transakcja (transaction) Jednostka przetwarzania baz danych posiadająca własności określane skrótem ACID (Atomicity, Consistency, Isolation, Durability): atomowość, spójność, izolacja, trwałość:

  • Atomowość oznacza, że transakcja wykonuje wszystkie czynności, które się na nią składają, albo też nie wykonuje żadnej z nich. Oznacza to, że po zerwaniu transakcji musi być odtworzony stan sprzed jej działania.
  • Warunek spójności wymaga, aby transakcja pozostawiła bazę danych w spójnym stanie (chociaż w trakcie transakcji stan ten może być chwilowo niespójny).
  • Izolacja oznacza, że poszczególne transakcje są całkowicie niezależne: przebieg danej transakcji nie wpływa na przebieg jakichkolwiek innych transakcji (i oczywiście odwrotnie).
  • Trwałość (trwanie) oznacza, że po potwierdzeniu (commit) transakcji, jej skutki w zakresie zmiany stanu bazy danych są trwałe i nie mogą być zniszczone przez jakiekolwiek zdarzenia (np. poprzez awarię zasilania).

Transakcja może być zerwana (abort); w takim przypadku wszelkie jej skutki są odwracane do stanu sprzed transakcji. Ta własność implikuje konieczność prowadzenia dziennika (log), w którym są zapisywane stany danych przed i po operacjach wykonywanych przez transakcję. W przypadku zerwania, dziennik jest czytany od tyłu celem przywrócenia stanu sprzed transakcji; ta czynność nazywa się odwracanie (rollback). Transakcje zapewniają zwiększenie niezawodności systemu i spójności danych, szczególnie w sytuacji jednoczesnego dostępu wielu użytkowników do tej samej bazy danych. Istnieje wiele technik przetwarzania transakcji, które zwykle dzieli się na pesymistyczne (wymagające zablokowania dostępu do przetwarzanej przez transakcję danej dla innych transakcji) oraz optymistyczne (nie wymagające blokowania; ich zastosowanie jest jednak bardzo ograniczone z powodów zarówno technicznych jak i koncepcyjnych). Obiektowość implikuje nowe techniki przetwarzania transakcji, np. tzw. hierarchiczne blokowanie.

transakcja projektowa (design transaction) Termin oznaczający długą i/lub zagnieżdżoną transakcję.

tranzytywne domknięcie (transitive closure) Termin o rodowodzie matematycznym. Tranzytywne domknięcie R* relacji R jest definiowane następująco:

x R y Þ x R* y

x R y and y R* z Þ x R* z

tj. relacja R* zawiera parę <x,y>, jeżeli istnieje dowolnej długości ciąg par <x,a1>, <a1,a2>, <a2,a3>,... , <an,y> należących do R. Typowe zadanie realizowane poprzez tranzytywne domknięcie jest następujące: Niech R reprezentuje drzewo genealogiczne (R zawiera pary <rodzic, potomek> ); znaleźć wszystkich potomków (bezpośrednich lub pośrednich) Kowalskiego.

Tranzytywne domknięcie znalazło zastosowanie w językach zapytań jako istotny operator realizujący pewien typ przetwarzania (patrz: BOM). Często też tranzytywne domknięcie jest argumentem na rzecz tezy, że algebra relacji (w czystej postaci) nie jest dostatecznie uniwersalna: żadna kombinacja operatorów algebry relacji nie jest w stanie osiągnąć efektu osiąganego przez tranzytywne domknięcie. Istnieją uogólnienia tego operatora, np. w standardzie SQL3 oraz w języku SBQL systemu Loqis. Tranzytywne domknięcie jest szczególnym przypadkiem operatora punktu stałego (fixed point operator), tj. operatora realizowanego przez równanie stałopunktowe X = Q(X), gdzie X jest zmienną zwracającą wynik zapytania (np. tabelę), zaś Q jest pewnym zapytaniem zależnym od X. Równanie takie oblicza się podstawiając na początku na X wynik pusty, a następnie podstawiając na X wynik Q(X) aż do momentu, kiedy poprzednia i następna wartość X są identyczne (jest to tzw. najmniejszy punkt stały). Operator punktu stałego ma związek z programowaniem w logice i koncepcją dedukcyjnych baz danych (określaną jako Datalog). Efekt uzyskiwany przez tranzytywne domknięcie można także osiągnąć poprzez rekurencyjne procedury (lub perspektywy) zdefiniowane w języku zapytań.

treść metody (method body) Patrz: ciało metody.

trwała zmienna (persistent variable) Zmienna, która ma wszystkie własności zmiennej języka programowania, ale zachowuje swoją wartość pomiędzy kolejnymi uruchomieniami programu.

trwałość (persistence) Cecha danej, zmiennej lub obiektu oznaczająca zachowywanie jej wartości dłużej niż czas pojedynczego uruchomienia programu (zwykle dowolnie długo). Trwałość jest podstawową własnością danych przechowywanych w bazie danych.

trwałość poprzez dziedziczenie (persistence through inheritance) Założenie organizacji obiektowej bazy danych, w której cecha trwałości jest cechą definiowanej klasy oraz wszystkich jej podklas. Wadą tej koncepcji jest ograniczenie ortogonalności: w szczególności, nie można zdefiniować metod działających identycznie na trwałych i ulotnych danych, co narusza zasadę ortogonalnej trwałości.

trwałość poprzez osiągalność (persistence through reachability, PTR) Organizacja obiektowej bazy danych ustalająca, że każdy obiekt osiągalny z trwałego obiektu (np. podobiekt, obiekt powiązany poprzez wskaźnik) jest również trwały. Zakłada się istnienie tzw. trwałych korzeni (persistent roots), czyli trwałych obiektów danych z definicji. Trwałość poprzez osiągalność implikuje pewne ograniczenia, np. trwały obiekt nie może mieć nietrwałych atrybutów i nie może zawierać wskaźnika prowadzącego do nietrwałego obiektu. Większość obecnych obiektowych systemów zarządzania bazą danych przyjmuje założenie trwałości poprzez osiągalność (w szczególności systemy zbudowane w oparciu o standard ODMG). Trwałość poprzez osiągalność nie jest mocnym ograniczeniem, szczególnie w systemach z mocną kontrolą typów. Można jednak wyobrazić sobie system, w którym cecha trwałości jest całkowicie ortogonalna w stosunku do jakichkolwiek innych cech, np. system, w którym trwały obiekt może mieć ulotne atrybuty. W istocie, taką możliwość zapewnia wiązanie do języka Java w standardzie ODMG, mimo zapewnień, że standard ten jest oparty na koncepcji trwałości poprzez osiągalność.

trwały identyfikator (persistent identifier) Unikalny identyfikator obiektu, który nie zmienia się podczas całego życia obiektu.

trwały korzeń (persistent root) Trwały obiekt stanowiący początek hierarchii lub sieci trwałych obiektów w koncepcji określanej jako „trwałość poprzez osiągalność”.

trwały obiekt (persistent object) Obiekt przechowywany w bazie danych; obiekt nie zmieniający swego stanu pomiędzy kolejnymi uruchomieniami programu aplikacyjnego.

trwanie (durability) Własność transakcji mówiąca o tym, że po potwierdzeniu transakcji jej skutki są trwałe i nie mogą być odwrócone poprzez jakikolwiek przypadek, np. zanik zasilania komputera. Patrz też: transakcja.

tryger (trigger) Inaczej wyzwalacz. Patrz: aktywne reguły.

trzeci manifest (The Third Manifesto) Patrz: manifest.

trzecia postać normalna (3NF, Third Normal Form) Relacja znajduje się w trzeciej formie normalnej, jeżeli nie zawiera tranzytywnych zależności funkcyjnych, tj. takich trzech atrybutów A, B i C, że zachodzi A ® B oraz B ® C. Tranzytywne zależności funkcyjne zwykle oznaczają redundancję w danych i są powodem anomalii aktualizacyjnych. Dla przykładu, niech relacja PRACOWNIK zawiera atrybuty NR_PRAC, NR_DZIAŁU oraz NAZWA_DZIAŁU. Jest oczywiste, że NR_DZIAŁU jest zależny funkcyjnie od NR_PRAC, (czyli NR_PRAC ® NR_DZIAŁU), zaś NAZWA_DZIAŁU jest funkcyjnie zależna od NR_DZIAŁU (czyli NR_DZIAŁU ® NAZWA_DZIAŁU). Zatem relacja ta nie jest w trzeciej formie normalnej, gdyż istnieją w niej tranzytywne zależności funkcyjne. Oczywista jest też redundancja, gdyż NAZWA_DZIAŁU będzie powtarzana dla wszystkich pracowników pracujących w tym dziale. Proces eliminacji tego rodzaju niekorzystnych własności jest nazwany normalizacją. W przypadku A ® B, B ® C oznacza on wyeliminowanie atrybutu C z danej relacji (projekcję) oraz utworzenie nowej relacji zawierającej atrybuty B i C. (W naszym przykładzie, utworzenie nowej relacji DZIAŁ z atrybutami NR_DZIAŁU i NAZWA_DZIAŁU.) Trzecia postać normalna jest pojęciem ważnym, ale oczywistym. Nawet średnio rozgarnięty projektant intuicyjnie unika sytuacji, w których relacja nie jest w trzeciej formie normalnej. Z tego powodu, wbrew początkowym nadziejom twórców modelu relacyjnego, formalizacja tego pojęcia jest raczej drugorzędna dla praktyki projektowania baz danych.

trzywarstwowa architektura (three-tiered architecture) Patrz: architektura trzywarstwowa.

tworzenie wystąpienia (instantiation) Tworzenia nowego obiektu na podstawie szablonu lub wzorca, którym jest klasa lub typ. Niekiedy termin ten oznacza również utworenie klasy poprzez określenie parametru dla klasy parametryzowanej lub szablonu (template).

typ (type) Specyfikacja rodzaju wartości, które może przybierać dany byt programistyczny (zmienna, obiekt, parametr); specyfikacja budowy obiektu; specyfikacja interfejsu procedury lub metody, itd. Typ ogranicza budowę lub ustala zewnętrzny interfejs bytów programu lub bazy danych oraz ogranicza kontekst, w którym może on być użyty w tekście programu. Zasadniczym celem typów jest kontrola formalnej poprawności programów („bezpieczeństwo typologiczne”). W językach z mocnym typowaniem (strong typing), np. w językach Pascal i Modula-2, każdy deklarowany byt programistyczny musi być obowiązkowo wyposażony w deklarację typu. Poprzez tę deklarację programista wyraża swoje oczekiwania co do roli tego bytu w programie. Te oczekiwania są następnie sprawdzane we wszystkich tych miejscach programu, gdzie występuje odwołanie do tego bytu. Np. określając typ zmiennej X jako integer programista ustala, że ta zmienna ma przechowywać wartości całkowite. Dzięki temu możliwe jest sprawdzenie, czy wszystkie odwołania do tej zmiennej w programie mają kontekst, w jakim może być użyta wartość całkowita. Typologiczna kontrola poprawności programów okazała się cechą niezwykle skutecznie eliminującą błędy popełniane przez programistów. Typom przypisuje się także inne role, wśród nich określenie reprezentacji wartości wewnątrz pamięci komputera oraz wspomaganie modelowania pojęciowego.

typ abstrakcyjny (abstract type) Patrz: abstrakcyjny typ danych.

typ atrybutu (attribute type) Wyrażenie pewnego języka programowania dotyczące wartości atrybutu obiektu, które ustala (często implicite) format, długość, zakres wartości, sposób reprezentacji oraz dopuszczalne operatory.

typ kompozytowy (composite type) Typ nieelementarny; typ zdefiniowany przy pomocy konstruktorów typów (np. struct) i innych typów.

typ konkretny (concrete type) Termin występujący w kontekście abstrakcyjnych typów danych, eksponujący fakt, że pojęcie typu (w systemach z mocną kontrolą typów) jest różne od pojęcia abstrakcyjnego typu danych. Typ konkretny przeciwstawia się wtedy typom abstrakcyjnym. Patrz też: typ.

typ konstruowany (constructed type) W standardzie OMG CORBA, konstruktor typów struct, union i enum, umożliwiający konstruowanie bardziej złożonych wyrażeń typologicznych z wyrażeń prostszych.

typ masowy (bulk type) Typ wartości posiadających potencjalnie dużą, nieznaną z góry i nieograniczoną liczbę elementów. Zwykle za typ masowy uważa się sekwencję (sequence) - rozszerzalny ciąg elementów o dowolnej długości, dynamiczną tablicę (dynamic array) - struktura podobna do sekwencji, z dostępem poprzez indeks, wielozbiór (multi-set, bag) - rozszerzalna kolekcja elementów, bez określonej kolejności, z ewentualnymi powtórzeniami, oraz zbiór (set) - rozszerzalna kolekcja elementów, bez określonej kolejności, bez powtórzeń wartości.

typ nieprzejrzysty (opaque type) Typ o określonej nazwie, którego budowa nie jest udostępniona (jest ukryta) dla użytkownika. Np. użytkownik może wiedzieć, że pewien obiekt jest typu Video, ale nie musi wiedzieć, że ten typ jest strukturą zawierającą takie atrybuty jak Długość, Format, SekwencjaBitów, MetodaKompresji, itp. Nieprzejrzystość typu może być częściowa; wtedy użytkownik widzi niektóre składniki typu, pozostałe zaś są ukryte. Przykładem języka z nieprzejrzystymi typami jest Ada95.

typ parametryzowany (parameterized type) Typ parametryzowany pewnym parametrem, zwykle typem lub wartością. Np. typ set (zbiór) jest parametryzowany typem elementu zbioru (np. set(integer)), zaś typ array jest parametryzowany wartością będącą rozmiarem tablicy.

typ pochodny (derived type) Termin C++, oznaczający dowolny typ utworzony na podstawie typu bazowego. W Ada95 termin ten oznacza dowolny typ utworzony na podstawie innego typu. Synonim: typ potomny.

typ podstawowy (basic type) Patrz: typ prymitywny.

typ potomny (child type) Patrz: typ pochodny.

typ prymitywny (primitive type) Typ charakteryzujący wartość, która jest niepodzielna (nie zawiera bardziej prymitywnych wartości). Typy prymitywne w danym języku są wbudowane, lub można je utworzyć na podstawie prostych operacji na typach wbudowanych. Przykładami typów prymitywnych są: unsigned, short, integer, real, char, date, money, float, double, long integer, itd. W niektórych językach typem prymitywnym są również string, decimal, bitmap i inne. Synonim: typ podstawowy.

typ referencyjny (reference type) Typ, którego wartościami są referencje do obiektów, krotek, itd. W SQL3 wartość typu referencyjnego może być zapamiętana w tablicy i następnie użyta jako bezpośrednia referencja (wskaźnik) do krotki (wiersza) w innej tablicy. W efekcie możliwe jest tworzenie powiązań pomiędzy obiektami, tak jak w modelach obiektowych. Zwrócimy uwagę, że w wielu językach i systemach (np. w standardzie ODMG) utożsamia się typ obiektu z typem referencji do obiektu, co z jednej strony daje pewne uproszczenie języka, zaś z drugiej strony prowadzi do niejednoznaczności semantycznych.

typ rozróżniony (distinct type) Typem rozróżnionym jest typ uzyskany poprzez nadanie nowej nazwy dla już zdefiniowanego typu. Nowy typ jest traktowany jako oddzielny (nieporównywalny) typ. Koncepcja typów rozróżnionych jest oparta na nazwowej zgodności typów. Np. w SQL3 można podać następujące deklaracje:

CREATE DISTINCT dolar_usa AS DECIMAL(9,2)

CREATE DISTINCT polski_zl AS DECIMAL(9,2)

Po takiej deklaracji porównanie wartości typu dolar_usa z wartością typu polski_zl powoduje błąd typu. W obiektowości typy rozróżnione (i nazwowa zgodność typów) zwykle nie są rozpatrywane ze względu na balast koncepcji teoretycznych, takich jak zasada zamienialności lub pewne formy polimorfizmu. Należy jednak podkreślić, że typy rozróżnione i nazwowa zgodność typów są bardziej koncepcyjnie spójne, niż powszechnie przyjmowana strukturalna zgodność typów.

typ szablonowy (template type) Zwykle chodzi o konstruktor typów masowych, takich jak set, sequence, bag, array. Patrz też: klasa szablonowa.

typ wbudowany (built-in type) Typ predefiniowany w danym języku programowania (np. int, float, char, itd.), stanowiący nieodłączną jego część, skojarzony z predefiniowanymi operacjami (+, =, itd.).

typ wyliczeniowy (enumeration type) Typ, którego wartości są explicite wyliczone; np. typ boolean = {true, false} lub typ Zawód = {asystent, adiunkt, docent, profesor}.

U

UFO [1] (United Functions and Objects) Język programowania łączący paradygmat obiektowy z funkcjonalnym, przeznaczony dla równoległych obliczeń. Zrealizowany na Uniwersytecie w Manchesterze.

UFO [2] (Unidentified Flying Object) Niezidentyfikowany obiekt latający. Istnieją kontrowersje co do tego, czy jest to obiekt rzeczywisty, czy też urojony.

ukrywanie informacji (information hiding) Zasada, zgodnie z którą programista lub użytkownik pewnego składnika oprogramowania może go poprawnie zastosować bez znajomości jego budowy lub implementacji. Zasada ta oznacza, że wszelkie detale pewnego bytu programistycznego, które są nieistotne dla jego użytkowników, powinny być ukryte. Wielu autorów uważa ukrywanie informacji za synonim hermetyzacji (encapsulation). Niektórzy z autorów uważają ukrywanie informacji i hermetyzację za pojęcia różne. Ich zdaniem, hermetyzacja niekoniecznie oznacza ukrywanie informacji, lecz zgromadzenie wielu bytów wewnątrz pewnej granicy, udostępnienie ich poprzez dobrze zdefiniowany interfejs i wydzielenie abstrakcyjnej specyfikacji tego interfejsu. Jest natomiast prawdą, że hermetyzacja sprzyja ukrywaniu informacji.

ulotny (transient, volatile, temporary) Przeciwieństwo trwałego; określenie lokalnego lub chwilowego obiektu, który przestaje istnieć w momencie zakończenia bloku, procedury, funkcji, metody lub programu. Istnieją dwa rodzaje obiektów ulotnych:

  • Obiekty czasowe powoływane na przeciąg całej sesji użytkownika i usuwane po jej zakończeniu;
  • Obiekty lokalne powoływane po wejściu sterowania do ciała bloku, procedury, metody lub funkcji, i automatycznie usuwane w momencie, kiedy sterowanie opuszcza to ciało. Takie obiekty są przechowywane w sekcji stosu środowisk właściwej dla danego wołania danej procedury, funkcji metody, itd. Niekiedy (np. w implementacjach języka Java) obiekty ulotne są przechowywane na stercie, zaś odpowiednia sekcja stosu zawiera referencje do tych obiektów.

UML (Unified Modeling Language) Zunifikowany język do modelowania, zawierający pojęcia i notacje służące do obiektowej analizy, modelowania i projektowania. UML został opracowany przez czołowych metodologów, G.Boocha, I.Jacobsona, J.Rumbaugha, i jest rozpowszechniany przez firmę Rational Inc. Jest on następcą OMT, metodyki Boocha oraz metodyki opartej na przypadkach użycia (use cases) Jacobsona. UML jest lansowany jako standard notacyjny, również jako fragment standardu OMG. W notacji UML definiowane są następujące diagramy:

  • Diagramy przypadków użycia (use cases). Są one podstawą metodyki Objectory. Ich głównym celem jest odwzorowanie funkcji projektowanego systemu w taki sposób, w jaki będą je widzieć jego użytkownicy. W metodykach opartych na UML przypadkom użycia przypisuje się szczególne znaczenie środka napędzającego cały proces rozwoju systemu.
  • Diagramy klas (class diagrams). Są one odmianą dość klasycznych diagramów encja-związek (entity-relationship). Zostały praktycznie bez większych zmian przejęte z OMT. Wprowadzone są rozszerzenia poprawiające czytelność diagramów i przystosowujące je do konkretnej dziedziny zastosowań (np. stereotypy i odpowiadające im ikony). Odmianą diagramów klas są diagramy pakietów (package diagrams).
  • Diagramy odwzorowujące dynamiczne własności systemu (behavior), w tym:

Diagramy sekwencji (szczególny przypadek diagramów interakcji): pokazanie kolejności komunikatów przesyłanych pomiędzy obiektami dla pewnej sytuacji, np. przypadku użycia.

Diagramy kolaboracji (inaczej diagramy współpracy; szczególny przypadek diagramów interakcji): podobne do diagramów sekwencji, ale z jednoczesnym odwzorowaniem statycznej struktury obiektów.

Diagramy stanów: odwzorowanie istotnych stanów (w których może znaleźć się proces przetwarzania) oraz przejść pomiędzy tymi stanami.

Diagramy aktywności: diagramy przepływu sterowania (flowcharts) uzupełnione o proste środki odwzorowania równoległych procesów.

  • Diagramy implementacyjne, w tym:

Diagramy komponentów

Diagramy rozprzestrzeniania (deployment)

Zdaniem autorów UML, diagramy te zapewniają wymaganą mnogość perspektyw systemu podczas jego analizy i rozwoju.

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

http://www.awl.com/cp/uml/uml.html

http://www.rational.com/HyperMail/otug

http://www.rational.com/ot/uml/faq.html

unia (union) Typ struktury, rekordu lub obiektu, który może mieć alternatywnie dwa lub więcej zestawów atrybutów. Przykładowo, jeżeli właścicielem samochodu może być osoba lub firma, to obiekt Samochód może posiadać alternatywnie albo atrybut NazwiskoWłaściciela, albo atrybut WłasnośćFirmy. Unie są również zwane wariantami. Z unią może być związany dyskryminator (discriminator), tj. atrybut, którego wartość określa, z którym wariantem mamy do czynienia. Może też nie mieć dyskryminatora; wówczas odpowiedzialność za rozróżnianie wariantów spada na programistę (tak jest np. w C i C++). Brak dyskryminatora w unii podkopuje koncepcję mocnej kontroli typów i stwarza okazję do bardzo trudnych błędów (np. jeżeli programista zastosuje selektor atrybutu do niewłaściwego wariantu, wówczas wynik jest nieprzewidywalny i zależy od reprezentacji obiektu). Z kolei unie z dyskryminatorem zmuszają do oddelegowania sprawdzania poprawności typologicznej do czasu wykonania, co ma konsekwencje dla wydajności. Unie stwarzają poważny problem dla języków zapytań; jak dotąd nie istnieje prawdopodobnie koncepcja języka zapytań uwzględniającego unie. (Uwzględnienie tej własności wymagałoby przeniesienia części informacji zawartej w typie (np. nazw atrybutów) do wnętrza reprezentacji obiektów, co miałoby konsekwencje zarówno dla objętości tej reprezentacji, jak i mechanizmów wiązania/dostępu.) Unie z dyskryminatorem są własnością IDL wg standardu CORBA i są własnością ODL wg standardu ODMG, ale nie są traktowane w pozostałych częściach tego standardu, prawdopodobnie wskutek trudności ze spójnym opanowaniem tej własności we wszystkich konstrukcjach. Unie mają ostatnio złą prasę w obiektowej literaturze. Zostały one pominięte w językach Eiffel, Java i Modula3. Twierdzi się, że są one potrzebne wyłącznie z powodu oszczędności pamięci (nisko kwalifikowany motyw), prowadzą do trudności z kontrolą typów i mogą być zastąpione poprzez specjalizacje klas i obiektów. Jest to jednak rozwiązanie pozorne, ponieważ prowadzi do niepotrzebnej eksplozji ilości klas, zmusza do migracji obiektów z klasy do klasy (przy zmianie zestawu jego atrybutów), oraz utrudnia przetwarzanie kolekcji zawierających obiekty o różnym zestawie atrybutów. Mimo ostatnich tendencji należy oczekiwać, że unie jeszcze wrócą do łask wśród projektantów języków i systemów. Synonim: zapis z wariantami.

unia typów (type union) Typ powstały poprzez zsumowanie dwóch lub więcej typów. Jeżeli typ T = T1 + T2, gdzie + jest operatorem unii typów, to wartość x jest zgodna z typem T wtedy i tylko wtedy, jeżeli jest zgodna z typem T1 lub z typem T2. Z reguły unia typów dotyczy zapisów (rekordów) lub struktur; patrz: unia.

unia z dyskryminatorem (discriminated union) Unia typów, w której wyróżnia się atrybut, którego wartość pozwala rozpoznać podczas wykonania, z którym przypadkiem unii mamy aktualnie do czynienia. Patrz: unia.

Unified Modeling Language Patrz: UML.

UniSQL Obiektowo-relacyjny system zarządzania bazą danych, oparty na rozszerzonym SQL; zrealizowany przez firmę UniSQL, Inc; obecnie także wprowadzający standard ODMG. Najnowsza wersja systemu nosi nazwę UniSQL/X. Model danych systemu jest oparty na klasach/tablicach, atrybutach/kolumnach i metodach. Wspomaga typy masowe (kolekcje): zbiory, wielozbiory i listy. Klasy/tablice mogą być organizowane w hierarchię dziedziczenia. Wspomaga statyczne i dynamiczne wiązanie metod. W warstwie implementacyjnej wprowadza technikę przemiany wskaźników, dostęp nawigacyjny i automatyczne zbieranie nieużytków. (We wrześniu 1997 firma UniSQL zakończyła działalność z powodu trudności finansowych.)

http://www.unisql.com

uniwersalny serwer (universal server) Termin określający niektóre systemy obiektowo-relacyjne (DB2, Informix, Oracle), eksponujący fakt, że są one przystosowane do przechowywania i przetwarzania relacji, obiektów, danych przestrzennych, multimedialnych, są zintegrowane z WWW, technologią hurtowni danych, itd.

UoD (Universe of Discourse) Przedmiot rozważań, dziedzina problemu (problem domain) przy analizie i projektowaniu systemu informacyjnego.

usługi obiektowe (Object Services, OS) Termin OMG CORBA; element architektury OMA. W obecnym standardzie OMG CORBA zdefiniowano następujące 15 usług obiektowych:

  • Usługa w zakresie cyklu życiowego (Life Cycle Service). Definiuje operacje tworzenia, kopiowania, przemieszczania, i usuwania komponentów (obiektów) będących pod kontrolą danej aplikacji zintegrowanej poprzez standard CORBA.
  • Usługa w zakresie trwałości (Persistence Service). Definiuje interfejs do składowania komponentów (obiektów) na trwałych nośnikach, włączając w to obiektowe bazy danych, relacyjne bazy danych i zwykłe pliki.
  • Usługa w zakresie nazywania (Naming Service). Pozwala nadać komponentom (obiektom) nazwy (o hierarchicznej budowie) oraz odzyskać identyfikatory komponentów (obiektów) na podstawie ich nazw. Usługa pozwala przywiązać komponenty (obiekty) do istniejącego nazewnictwa katalogów systemów operacyjnych lub kontekstów nazwowych wg różnorodnych systemów: ISO X.500, OSF DCE, Sun NIS+, Novell NDS, Internet LDAP.
  • Usługa w zakresie zdarzeń (Event Service). Pozwala określić, czy dane komponenty mają reagować (nie reagować) na określone zdarzenia.
  • Usługa w zakresie współbieżności (Concurrency Control Service). Pozwala zakładać/zdejmować zamki na obiekty (lub inne byty) celem przeciwdziałania kolizjom transakcji lub wątków.
  • Usługa w zakresie transakcji (Transaction Service). Przewiduje koordynację transakcji opartą na dwufazowym potwierdzeniu (2PC) dla prostych i zagnieżdżonych transakcji.
  • Usługa w zakresie związków (Relationship Service). Przewiduje dynamiczne tworzenie/usuwanie powiązań (związków, asocjacji) pomiędzy obiektami, wymuszanie więzów referencyjnych, oraz nawigację od obiektów do obiektów wg zdefiniowanych dla nich związków.
  • Usługa w zakresie udostępniania obiektów na zewnątrz (Externalization Service). Przewiduje wstawianie i odczytywanie danych do/z komponentów (obiektów).
  • Usługa w zakresie zapytań (Query Service). Przewiduje dostęp do obiektów poprzez różnorodne języki zapytań, wśród nich SQL-92, nowo powstający standard SQL3, oraz obiektowy język zapytań (standardu ODMG) OQL.
  • Usługa w zakresie licencji (Licensing Service). Usługa pozwala na pomiary użycia komponentów (obiektów) oraz wyliczenie opłat za użycie w ramach sesji, węzła sieci, itd.
  • Usługa w zakresie dodatkowych własności obiektów (Properties Service). Pozwala dynamicznie związać z obiektami dowolne nazwane własności (atrybuty), np. datę utworzenia, datę ostatniej modyfikacji, nazwisko modyfikującego, itd.
  • Usługa w zakresie czasu (Time Services). Przewiduje interfejsy do synchronizowania czasu w środowisku rozproszonym. Pozwala również definiować zdarzenia wyzwalane przez upływ czasu.
  • Usługa w zakresie ochrony (Security Service). Zapewnia możliwości pełnej ochrony rozproszonych obiektów. Wspomaga autoryzację, sterowanie dostępem, tajność i przeciwdziałanie unikaniu zapłaty (non-repudiation). Zarządza także oddelegowywaniem uwierzytelnień (credentials).
  • Usługa handlowa (Trader Service). Przewiduje odzyskiwanie informacji o obiektach na podstawie ich własności, publikować informacje o serwisach dostarczanych przez obiekty, itd.
  • Usługa w zakresie kolekcji (Collection Service). Przewiduje interfejsy do tworzenia najczęściej spotykanych kolekcji (zbiorów, wielozbiorów, sekwencji, itd.) i manipulacji tymi kolekcjami.

Zestaw usług obiektowych jest rozszerzany w planowanym standardzie CORBA 3.0.

http://www.omg.org

usuń (delete) Operacja definiowana na bazie języka zapytań (np. w SQL) powodująca usunięcie z danej tablicy wskazanych krotek, np.:

delete Pracownik where Nazwisko = ‘Kowalski’

Operacja jest także definiowana (lub rozważana) w obiektowych językach zapytań.

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

utwórz (create) Operacja w języku zapytań (np. w SQL) lub języku manipulacji danymi, powodująca utworzenie nowej tablicy, nowego obiektu, nowej krotki, itd.

użytkownik (user) Osoba lub grupa osób stanowiąca podmiot interakcji systemu informatycznego. W zależności od trybu dostępu i celów działalności istnieje wiele kategorii użytkowników, np.: użytkownik końcowy, programista aplikacyjny, administrator bazy danych, administrator systemu.

V

Vbase Wcześniejsza wersja systemu Ontos, wycofana z rynku.

VC++ Patrz: Visual C++.

VDM++ Obiektowe rozszerzenie notacji VDM-SL (Vienna Development Method Specification Language).

Versant Obiektowy system zarządzania bazą danych zrealizowany przez Versant Object Technology; wprowadza standard ODMG.

http://www.versant.com/prod_f/index.html

VisiBroker Pośrednik ORB wg standardu CORBA firmy Visigenic (przejęty następnie przez firmę Borland). VisiBroker jest ulepszoną wersją pakietu Black Widow ORB firmy PostModern. Istnieją dwie wersje: VisiBroker for Java i VisiBroker for C++. VisiBroker zjednoczył wiele działań przemysłu związanego ze standardem CORBA. Wiele firm włączyło ten pakiet w skład swoich produktów, m.in. Oracle, Hitachi, Netscape, Novell, SunSoft, NetDynamics, Novera, Sybase, Borland, Gemstone, Silicon Graphics, Hummingbird, Cincom i Business Objects. VisiBroker jest obecnie składnikiem każdej przeglądarki Netscape. Również stał się podstawowym składnikiem oprogramowania Borlanda.

http://www.visigenic.com/prod

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

Visual Age Rodzina produktów - środowisk programistycznych służących do wizyjnego programowania aplikacji z relacyjną bazą danych; zrealizowana i rozpowszechniana przez IBM. Visual Age posiada odmiany zorientowane na poszczególne języki programowania (Smalltalk, C++, Java, Cobol), oraz jest wyposażony w szeroką gamę różnorodnych narzędzi i udogodnień.

Visual Basic Popularny, wizyjny system dla MS Windows wspomagający programowanie zdarzeniowe. Posiada pewne cechy obiektowości.

Visual C++ (VC++) Wizualne środowisko programistyczne dla języka C++ zrealizowane i rozpowszechniane przez Microsoft. Visual C++ wspomaga programowanie obiektowe aplikacji w środowiskach Windows (32 bitowych). Posiada zintegrowane środowisko rozwoju (IDE), kompilator C/C++ oraz bibliotekę klas (MFC).

W

w locie (on-the-fly) Czynność wykonywana równolegle, w tle innej zasadniczej czynności bez jej zatrzymywania; np. zbieranie nieużytków bez zatrzymywania lub opóźniania zasadniczych przebiegów programu.

wariant (variant) Termin występujący w rodzinie języków Pascal, Modula-2 itd. oznaczający typ zapisu, który ma dwa lub więcej alternatywnych zestawów atrybutów. W literaturze obiektowej częściej jest używany termin unia (union). Patrz: unia.

wartość domyślna (default value) Wartość podstawiana w momencie tworzenie zmiennej lub instancji obiektu. Również wartość zwracana przez pewne wyrażenie lub zapytanie, o ile po jego ewaluacji wynik jest wartością zerową (NULL). Wartości domyślne mogą być predefiniowane w danym języku (np. zero lub pusty string), ale mogą także stanowić fragment definicji obiektu (wchodzić w skład jego klasy).

wartość masowa (bulk value) Wartość złożona z wielu elementów, której rozmiar nie daje się przewidzieć ani sensownie ograniczyć. Synonimy: kolekcja, kontener.

wartość zerowa (null value, NULL, NIL) Wartość atrybutu obiektu, wskaźnika lub innej danej, która jest nierelewantna w danej sytuacji lub z jakichś powodów nie została wpisana lub zainicjalizowana. Zwykle jest oznaczana jako NULL lub NIL. Można wyróżnić wiele powodów pojawiania się wartości zerowych, np.: (1) Pewien atrybut nie ma zastosowania dla konkretnego przypadku, np. atrybut NAZWISKO_PANIEŃSKIE dla mężczyzn; (2) Informacja jest nieznana, np. miejsce, gdzie został pochowany Mozart; (3) Informacja o przyszłości, np. wynik przyszłego meczu piłkarskiego; (4) Informacja jeszcze nie zapełniona; np. po wprowadzeniu danych pracownika jego zarobek jest wartością zerową, gdyż wypełni ją później inny proces; (5) Wartość zerowa jest sygnałem wartości domniemanej, np. jeżeli prawie wszyscy pracownicy są urzędnikami, to pole ZAWÓD wypełnia się tylko dla nie-urzędników. Częstą przyczyną wartości zerowych jest to, że informacja nie zawsze da się idealnie wpasować w ustalony format. Znacznie rzadszą przyczyną jest niekompletność informacji, tj. sytuacja, kiedy informacja istnieje, ale nie jest znana.

Szczególną uwagę poświęca się wartościom zerowym w modelu i systemach relacyjnych, które są oparte na sztywnych formatach danych. Wartości zerowe leżą u podstaw definicji innych pojęć modelu relacyjnego, takich jak zewnętrzne złączenie (outer join). Okazuje się, że wartości zerowe zachowują się zupełnie inaczej, niż inne wartości, wobec czego wiele operacji w bazie danych musi je uwzględnić w postaci wydzielonego przepisu semantycznego.

Wartości zerowe były powodem licznych prac teoretycznych; nie znalazły one jednak zastosowania w rzeczywistych systemach. Większość tych prac przyjmowało założenie, że wartość zerowa pojawia się wskutek niekompletnej informacji, co dla przeważającej ilości rzeczywistych przypadków było założeniem fałszywym. Co za tym idzie, wartości zerowe były powodem powstania wielu pseudoteorii. Ogólnie, próby ustalenia semantyki dla wartości zerowych są nieudane, gdyż w bardzo wielu przypadkach użytkownik lub programista jest jedynym autorytetem, który potrafi je zinterpretować.

Z drugiej strony, doświadczenie pokazuje, że wartości zerowych nie da się uniknąć w żadnym rzeczywistym systemie bazy danych, zaś zastępowanie ich wartościami domyślnymi (default values) (np. 0, spacje lub pusty ciąg) zwiększa skłonność do błędów. Z tych powodów za słuszną trzeba uznać decyzję twórców języka SQL, gdzie podczas definiowania tablic można ustalić, że pewne ich kolumny mogą zawierać wartości zerowe. Takie kolumny należy rozumieć jako kolumny podwójne: w pierwszej kolumnie są przechowywane normalne wartości, zaś w drugiej informacja (boolowska) wskazująca miejsca, w których są wartości zerowe. Ta dychotomia jest przenoszona dalej na wszystkie interfejsy programistyczne: jeżeli taka wartość ma być podstawiona na zmienną, to należy zadeklarować dwie zmienne, jedną dla wartości, drugą (zwaną indicator variable) dla informacji o wartości zerowej. Język SQL jest wyposażony w szereg cech umożliwiających przetwarzanie tak rozumianych wartości zerowych, m.in. w specjalny predykat (is_null) testujący wystąpienie wartości zerowej, specjalną funkcję (if_null) pozwalającą zastąpić wartość zerową poprzez dowolną inną wartość, i specjalne traktowanie wartości zerowych w argumentach funkcji zagregowanych. Rozwiązania dotyczące wartości zerowych w SQL są przedmiotem dość ostrej krytyki (C.J.Date). W obiektowych bazach danych problem ten wydaje się być niedoceniany pomimo jego dużej wagi dla spójności działania systemu.

warunek końcowy (postcondition) Warunek, który musi być spełniony po uruchomieniu pewnej operacji lub metody.

warunek wstępny (precondition) Warunek, który musi być spełniony przed uruchomieniem pewnej operacji lub metody.

wątek (thread) „Mały” lub „lekki” proces (jakkolwiek nie istnieją ograniczenia na rozmiar wątków). Systemy operacyjne UNIX konsumują dla każdego procesu sporo zasobów, w szczególności czasu procesora i pamięci operacyjnej. Ta własność powoduje zmniejszenie dostępności systemu, o ile każdy z użytkowników (każde z zadań) miałby być obsługiwany przez oddzielny proces. Wielowątkowość oznacza, że jeden proces może być podzielony (poza systemem operacyjnym) na wiele małych podprocesów, czyli wątków. Ponieważ system operacyjny o nich nie wie, więc nie przydziela im zasobów. Zysk polega na znacznym zwiększeniu możliwości równoległej pracy oraz znacznym zmniejszeniu konsumowanych zasobów, a co za tym idzie, znacznym zwiększeniu szybkości przetwarzania z punktu widzenia każdego z użytkowników. Wątki są więc protezą łagodzącą zbyt ciężkie mechanizmy systemów operacyjnych. Obecna moda na wątki (w języku Java, w standardzie ODMG, itd.) może być jednak uważana za konsekwencję pogoni za doraźnym zyskiem kosztem jakości oprogramowania. Niektórzy specjaliści uważają wątki za „zatrute jabłko” (poison apple), czyli pojęcie, które poprzez zbytnie uproszczenia i brak mechanizmów synchronizacji może zaowocować w wiele trudnych do wykrycia błędów.

wczesne wiązanie (early binding) Patrz: wiązanie statyczne.

wersja (version) Zarejestrowany stan obiektowej bazy danych w przeszłości lub równorzędny, alternatywny stan bazy danych dotyczący pewnego projektu. Zarządzanie wersjami stanowi istotny problem naukowo-techniczny. Wersją obiektu nazywany jest zarejestrowany stan obiektu w przeszłości.

wiązanie [1] (binding) Zamiana nazw występujących w programie lub zapytaniu na byt ze środowiska wykonania programu (np. nazwy zmiennej na adres maszynowy przechowujący wartość tej zmiennej).

wiązanie [2] (binding) (Terminologia OMG i ODMG) Zasady połączenia dwóch systemów językowych, np. standardu ODMG z językiem C++, Smalltalk lub Java.

wiązanie [3] (linking) Patrz: konsolidacja.

wiązanie dynamiczne (dynamic binding) Wiązanie nazw występujących w programie na etapie wykonania programu; inaczej późne wiązanie.

wiązanie późne (late binding) Patrz: wiązanie dynamiczne.

wiązanie statyczne (static binding) Patrz: statyczne wiązanie.

wiązanie wczesne (early binding) Patrz: statyczne wiązanie.

widoczność (visibility) Określenie, na ile dana cecha pewnej abstrakcji (atrybut klasy, metoda klasy) jest widoczna dla innych abstrakcji. Widoczność jest określona przez zakres nazw; patrz: reguły zakresu. W kontekście hermetyzacji termin ten oznacza przypisanie do składowej obiektu kwalifikacji takich jak: publiczna, prywatna, chroniona.

widżet (widget) Okienkowy gadżet (window gadget). Mały obiekt graficzny widoczny w interfejsie użytkownika, służący do pewnych manipulacji, wprowadzania, wyprowadzania, lub wyszukiwania danych. Przykładami widżetów są przyciski, pola radiowe, pola menu, suwaki, itd.