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:
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ą:
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:
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:
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/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:
|
|
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:
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:
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:
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:
Możliwe jest wiele innych inwariantów,
które mogą być (i często są) wprowadzane do klas:
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:
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:
|
|
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:
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:
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:
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:
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:
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:
oraz 13 postulatów:
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:
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:
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):
McCabe podaje następujące metryki dla
programów obiektowych:
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.
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.
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:
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):
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:
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:
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:
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:
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:
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:
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 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:
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:
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:
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:
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:
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 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:
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:
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 są związkami pomiędzy klasami Pracownik i Firma. |
|
środowisko [1] (environment) Termin ogólny, oznaczający sprzęt, oprogramowanie, narzędzia, biblioteki, usługi, infrastrukturę i organizację niezbędne dla działania pewnej 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ść:
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:
|
|
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
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 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:
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. Termin jest także używany w charakterze symbolicznego dydaktycznego przykładu („Załóżmy, że sprowadziliśmy do magazynu partię widżetów zapakowanych w 100 skrzynkach...”). |
|
wielodostęp (concurrency) Równoległy dostęp, czyli możliwość jednoczesnej pracy wielu użytkowników. Wielodostęp implikuje konieczność zastosowania środków przeciwdziałających niekorzystnym interferencjom pomiędzy użytkownikami, powstającym np. wtedy, gdy kilku z nich próbuje jednocześnie zaktualizować tę samą daną. Skutkiem takiej interferencji jest utrata spójności bazy danych, np. zgubienie pewnych aktualizacji. Powszechnie przyjętą techniką przeciwdziałania takim interferencjom jest blokowanie danych, poddane dyscyplinie określonej jako przetwarzanie transakcji. Transakcje okazały się również bardzo wygodne dla systemów rozproszonych baz danych, ze względu na dodatkową własność przeciwdziałania skutkom przypadkowych awarii systemu. |
|
wielodziedziczenie (multi-inheritance) Patrz: wielokrotne dziedziczenie. |
|
wielokrotna dyspozycja (multiple dispatching) Patrz: dyspozycja. |
|
wielokrotne dziedziczenie (multiple inheritance) Określenie sytuacji,
w której obiekt lub klasa może dziedziczyć własności więcej niż jednej klasy.
Wielodziedziczenie implikuje bardziej złożoną strukturę klas (acykliczny
graf) oraz szereg problemów np. z mocną kontrolą typów. Poniższy rysunek
ilustruje wielokrotne dziedziczenie: klasa AMFIBIA dziedziczy zarówno
z klasy POJAZD_LĄDOWY, jak i z klasy POJAZD_WODNY.
Amfibia jako przykład wielokrotnego dziedziczenia |
|
wielokrotne interfejsy (multiple interfaces) Własność języka, systemu, standardu polegająca na możliwości zdefiniowania wielu interfejsów do tego samego obiektu. Wielokrotne interfejsy uważa się za sprzyjające modelowaniu pojęciowemu; jest to również pewien (niedoskonały) sposób obejścia braku wielodziedziczenia. Wielokrotne interfejsy są własnością COM/DCOM oraz Java. Tej własności nie ma C++, Smalltalk oraz standardy CORBA i ODMG. (Są planowane w CORBA 3.0.) |
|
wielowarstwowa architektura (multi-tiered architecture) Patrz: architektura wielowarstwowa. |
|
wielowartościowy atrybut (multi-valued attribute) Patrz: atrybut powtarzalny. |
|
wielowątkowy (multi-threaded) Określenie języka lub systemu umożliwiającego równoległą pracę wielu wątków. Patrz: wątek. |
|
wielozbiór (multiset, bag) W terminologii obiektowych baz danych (np. ODMG) konstruktor typów/klas. Wartość typu wielozbiór można dowolnie zwiększać o nowe elementy, lub usuwać elementy w niej zawarte. Porządek elementów nie ma znaczenia. W odróżnieniu od zbioru, wielozbiór może zawierać identyczne elementy, np. {1,3,3,6,3,1} jest wielozbiorem zawierającym 6 elementów, w tym dwie jedynki, trzy trójki i szóstkę; taki wielozbiór jest równoważny np. {6,3,3,3,1,1}, ale nie jest równoważny wielozbiorowi {1,3,6}. |
|
wiersz (row, tuple) Patrz: krotka. |
|
więzy integralności (integrity constraints) Warunki, które muszą spełniać dane zawarte w bazie danych. Warunki te mogą być dwojakiego rodzaju: statyczne, wykluczające niedopuszczalne wystąpienia bazy danych (np. „wiek ojca musi być większy od wieku syna") oraz dynamiczne, przeciwdziałające niedopuszczalnym zmianom zawartości bazy danych (np. „zarobek nie może się zmniejszyć”). Ważną klasą więzów integralności w relacyjnych bazach danych są zależności funkcyjne (functional dependencies) oraz integralność odwołań (referential integrity). Więzy integralności są zwykle implementowane w postaci aktywnych reguł. Synonim: ograniczenia integralnościowe. |
|
Wirfs-Brock Metodyka obiektowej analizy i projektowania systemów informatycznych. Patrz: DOOS. |
|
Wirfs-Brock, Rebecca. Autorka metodyki obiektowej Wirfs/Brock. |
|
wirtualny (virtual) Określenie dotyczące dowolnej cechy, dowolnego pojęcia lub dowolnego innego bytu, który posiada istnienie koncepcyjne (jest wyobrażalny i manipulowalny), ale nie posiada istnienia materialnego, fizycznego, lub nie jest bezpośrednio odwzorowany na nośnikach informacji. |
|
wirtualny atrybut (virtual attribute) Patrz: atrybut pochodny. |
|
wizja (view) Patrz: perspektywa. |
|
własności behawioralne (behavioral properties) Elementy schematu pojęciowego lub schematu bazy danych, określające własności dynamiczne lub zachowanie się obiektów. Przykładami własności behawioralnych są zdarzenia, które mogą zajść na obiektach, akcje przypisane do zdarzeń (czyli aktywne reguły), metody przypisane do obiektów lub ich klas, reguły określające dopuszczalne zmiany stanu obiektów. |
|
własność domkniętości (closure property) W modelu relacyjnym jest
to własność algebry relacji lub języka zapytań mówiąca o tym, że argumentami
wyrażeń algebraicznych lub zapytań są relacje i ich wynikiem są także
relacje. Zdaniem niektórych autorów, ta własność umożliwia dowolne
zagnieżdżanie zapytań. Własność domkniętości jest także uważana za pożądaną
cechę dla obiektowych języków zapytań, przy czym zarówno argumentami jak i
wynikiem zapytań powinny być obiekty (kolekcje obiektów). Niestety, zarówno
pojęcie domkniętości, jak i sposób rozumowania jego propagatorów, są oparte
na formalnym nieporozumieniu, z kilku powodów:
Formalistyczne przeniesienie własności domkniętości na grunt obiektowych języków zapytań rodzi dyskusje, czy zapytanie ma zwracać „istniejące obiekty” (co bardzo ograniczyłoby moc języka zapytań), czy też ma tworzyć nowe obiekty z nowymi unikalnymi identyfikatorami (co rodzi problemy zarówno koncepcyjne, jak i implementacyjne). Uniknięcie tych pseudoproblemów jest bardzo proste: wystarczy zrezygnować z podanej wyżej własności domkniętości i przyjąć inną: mianowicie, że nazwy występujące w zapytaniu zawsze zwracają referencje do obiektów, zaś dowolne zapytanie zwraca pewną strukturę zbudowaną z referencji, nazw i wartości - nigdy nie zwraca obiektów. Te założenia pozwalają na zbudowanie poprawnej semantyki obiektowego języka zapytań umożliwiającego dowolne zagnieżdżanie zapytań. Reasumując, podejścia do semantyki języków zapytań oparte o własność domkniętości są naiwne, są pseudokoncepcjami nie oddającymi istoty problemu. Dodać należy, że większość formalnych podejść do obiektowych języków zapytań (F-logika, rachunek monoidów, algebry obiektowe) - poza podejściem stosowym (stack-based approach) - przyjmuje mniej lub bardziej explicite własność domkniętości. Jest to wystarczający powód, aby te podejścia były nieadekwatne do opisu semantyki rzeczywistych języków zapytań takich jak OQL. |
|
wołanie odległej metody (remote message invocation, RMI) Patrz: RMI. |
|
wołanie odległej procedury (remote procedure call, RPC) Technika wołania procedury znajdującej się poza przestrzenią adresową danego komputera. Dzięki niej lokalny program może wykonywać procedurę na odległym komputerze, przesyłając do niej parametry i pobierając zwrócony przez nią rezultat. System RPC jest zestawem oprogramowania niezbędnego do podtrzymywania technik programowania używających odległych procedur. Jest on podstawową składową środowiska rozproszonego przetwarzania. RPC robi ostatnio karierę w informatyce, w tym również w bazach danych. Istnieje kilka jego standardów, w szczególności: udogodnienia w systemie UNIX, udogodnienia opracowane przez grupę Sun Microsystems’ Open Network Computing (ONC), produkt zwany Distributed Computing Environment (DCE) opracowany przez konsorcjum Open Software Foundation (OSF), produkt ANSAWARE, Courier RPC firmy Xerox, i inne. RPC jest szczególnie przydatne do programowania aplikacji w architekturze klient-serwer. Wołanie odległej procedury znalazło m.in. zastosowanie w systemach relacyjnych (np. Sybase), w rozproszonych systemach operacyjnych (np. OSF DCE), w standardzie DCOM, oraz w standardzie OMG CORBA. |
|
wołanie poprzez nazwę (call-by-name) Technika przekazywania parametrów (po raz pierwszy zastosowana w języku Algol 60) polegająca na tym, że parametru nie oblicza się w momencie wołania metody/procedury, ale przekazuje się go w postaci kodu (tekstu) wyrażenia będącego parametrem aktualnym. Tekst ten zastępuje wszystkie wystąpienia parametru formalnego w ciele metody/procedury (parametr jest traktowany jak „makro”). Specyfiką tej techniki jest to, że środowisko, w którym taki parametr jest ewaluowany, jest środowiskiem wywołania tej metody/procedury, a nie jej środowiskiem lokalnym (co jest konieczne z semantycznego punktu widzenia); jest to zwykle implementowane poprzez przekazanie wskaźnika do kodu/tekstu będącego parametrem aktualnym. Technika jest semantycznie „brudna”, gdyż może powodować efekt, w którym obliczane wartości parametru w poszczególnych miejscach ciała metody/procedury nie są identyczne ze względu na to, że wewnątrz ciała metody mógł ulec zmianie stan, na podstawie którego obliczany jest parametr. Technika ta jest powszechnie stosowana w przypadku parametrów makr. Może ona mieć również znaczenie dla technik optymalizacyjnych (w szczególności, optymalizacji zapytań) opartych na przepisywaniu (rewriting). |
|
wołanie poprzez potrzebę (call-by-need) Technika przekazywania parametrów określana także jako „leniwa ewaluacja" (lazy evaluation). Oznacza opóźnienie wyliczania wartości parametru aktualnego do momentu, kiedy będzie on rzeczywiście potrzebny wewnątrz ciała metody/procedury. Parametr jest ewaluowany tylko raz, w środowisku wywołania metody/procedury. Technika ma na celu optymalizację czasu wykonywania i może być kombinowana z innymi metodami (call-by-value, call-by-reference, itd.). Podobnie do call-by-name, technika ta jest semantycznie „brudna”, gdyż może prowadzić do efektu, w którym wartość wyliczonego parametru jest inna, niż wartość wyliczona w momencie wołania metody/procedury. |
|
wołanie poprzez referencję (call-by-reference) Technika przekazywania argumentu procedury (lub metody) do jej wnętrza, w której przekazywana jest referencja do obiektu. Dzięki temu wewnątrz procedury można dokonać zmiany stanu (aktualizacji) obiektu zewnętrznego w stosunku do tej procedury. Wołanie przez referencję jest kojarzone z własnością zmienności (mutability). Obiekt przekazywany poprzez referencję jest dostępny w ciele procedury nie pod swoją nazwą, lecz pod nazwą jej odpowiedniego parametru formalnego. |
|
wołanie poprzez wartość (call-by-value) Technika przekazywania argumentu procedury (lub metody) do jej wnętrza, w której przekazywana jest wartość argumentu obliczona przed przekazaniem sterowania do wnętrza procedury. Zwykle oznacza to, że wewnątrz procedury tworzy się lokalną zmienną będącą kopią obiektu, wartości lub zmiennej przekazywanej jako argument. Wszelkie operacje wewnątrz procedury dokonywane są na tej kopii; oryginalny obiekt będący argumentem nie jest dostępny pod nazwą odpowiedniego parametru formalnego występującą w ciele procedury. |
|
wołanie poprzez wartość ze zwrotem (call-by-value-return) Wołanie poprzez wartość, w którym wewnątrz ciała procedury tworzy się kopię zmiennej przekazanej jako parametr. Wszelkie operacje wewnątrz ciała następują na tej lokalnej kopii, a nie na oryginalnej zmiennej (różnica z call-by-reference). W momencie zakończenia procedury wartość tej lokalnej zmiennej podstawia się z powrotem na zmienną przekazaną jako parametr. |
|
wskaźnik (pointer) Identyfikator obiektu, adres
dyskowy, adres w pamięci operacyjnej lub inny jednoznaczny identyfikator
danej, który jest używany przez programistę tak jak wartość, np.
zapamiętywany jako wartość zmiennej lub atrybutu. Wskaźniki są podstawowym
sposobem implementacji powiązań asocjacyjnych pomiędzy obiektami. Wskaźniki
zaimplementowane w C/C++ są przyczyną złej sławy tego pojęcia, głównie
dlatego, że prowadzą do fizycznych adresów pamięci, a nie do danych lub
obiektów (w sposób logiczny). Poprzez tę własność oraz z powodu zbyt dużych
możliwości dostarczanych dla programisty (tzw. arytmetyka wskaźników),
wskaźniki mogą być źródłem poważnych błędów. Wskutek tego historycznego
dziedzictwa w nowszych propozycjach (np. w Java) termin
„wskaźnik” zastąpiono terminem „referencja”. W odróżnieniu
od wskaźnika, referencja prowadzi nie do adresu w pamięci, lecz do danej lub
obiektu. Wskaźniki (lub referencje) były tępione przez propagatorów modelu relacyjnego, ponieważ nie pasowały do koncepcji ideologicznej bazującej na pojęciu relacji. W obiektowych bazach danych wskaźniki/referencje wróciły z powrotem do łask, ponieważ są one idealną techniką implementacji koncepcyjnych powiązań pomiędzy obiektami, oraz sprzyjają wydajności i konceptualizacji programów. Wskaźniki i referencje spotykają się również z niechęcią teoretyków, którym nie pasują do koncepcji takich jak programowanie w logice, dedukcyjne bazy danych lub model funkcjonalny (oparty np. na rachunku lambda). Pewne problemy ze wskaźnikami/referencjami powstają również w przypadku obiektów rozproszonych w sieci komputerowej. Synonimy: odsyłacz, pointer. |
|
wspólne udogodnienia (common facilities, CF) Termin OMG CORBA
oznaczający udogodnienia przewidziane przez standard CORBA, wspólne dla wielu
dziedzin aplikacyjnych. http://www.omg.org |
|
wspólne udogodnienia pionowe (vertical common facilities) Termin OMG CORBA
oznaczający udogodnienia oferowane przez standard CORBA dla specyficznych
dziedzin aplikacyjnych (medycyna, CAD, finanse, wytwarzanie, telekomunikacja,
itd.). http://www.omg.org |
|
wspólne udogodnienia poziome (horizontal common facilities) Termin OMG
CORBA oznaczający udogodnienia oferowane przez standard CORBA wspólne dla
wszystkich dziedzin aplikacyjnych. http://www.omg.org |
|
współbieżność (concurrency) Zdolność systemu do jednoczesnej obsługi wielu użytkowników, transakcji lub procesów. |
|
współdziałanie (interoperability) Dziedzina badawcza i
praktyczna zajmująca się umożliwieniem współpracy niezależnie zbudowanych
(heterogenicznych) systemów, szczególnie w sieciach komputerowych. Spośród
ogromnej liczby aspektów związanych z tym pojęciem można wyróżnić
następujące:
Synonim: interoperacyjność. |
|
wstaw (insert) Operator w języku zapytań lub języku manipulacji danymi, którego zadaniem jest wstawienie nowej krotki do danej relacji, wstawienie nowego obiektu do kolekcji obiektów, itd. |
|
wyciąganie mnożnika (factoring, factoring out) Identyfikacja wspólnych cech (inwariantów, np. metod lub definicji atrybutów) dla pewnej grupy obiektów i utworzenie z nich klasy. Również identyfikacja wspólnych cech dla pewnej liczby klas i następnie, utworzenie nadklasy abstrakcyjnej zawierającej te cechy (oraz usunięcie tych wspólnych cech z podklas). |
|
wyciekanie pamięci (memory leak, memory leakage, storage leak) Niekorzystne zjawisko w aplikacjach zbudowanych przy pomocy języków lub systemów nie wyposażonych w automatyczne zbieranie nieużytków (garbage collection), np. C++. Polega ono na tym, że programiści nie zawsze stosują ścisłą dyscyplinę dealokacji obszarów pamięci, które nie są już potrzebne. W ten sposób powstają coraz to nowe bezużyteczne obszary, o których system nie wie, że są bezużyteczne, zaś rozmiar użytecznej pamięci ulega ciągłemu zmniejszaniu. Efektem tego jest zwykle coraz wolniejsze działanie aplikacji, aż do jej całkowitego zawieszenia z powodu pozornego braku pamięci. |
|
wydajność (performance) W większości przypadków chodzi o wydajność maszynową. |
|
wydajność maszynowa (performance) Czas zużyty przez system komputerowy na wykonanie zadania lub operacji. |
|
wydajność wytwarzania (productivity) Sprawność tworzenia projektu i oprogramowania, mierzona np. w osobo-miesiącach. |
|
wyjątek (exception) Specjalny byt programistyczny powodujący przerwanie lub zawieszenie normalnej nitki sterowania programu i przejście do specjalnego fragmentu programu zajmującego się obsługą tego wyjątku. Przejście do obsługi wyjątku oznacza „boczne” wyjście z wielu aktualnie zbudowanych zakresów (scopes). Wyjątki mogą mieć charakter sprzętowy (np. nastąpiło dzielenie przez zero) lub programowy (np. użytkownik nacisnął klawisz Esc). Wyjątki pozwalają na lepszą strukturalizację programów, gdyż programista po zadeklarowaniu wyjątku jest zwolniony z konieczności pisania wielu warunków („strażników”), których celem jest (najczęściej) reakcja na błąd w programie. Wyjątki są także traktowane jako rodzaj lub synonim zdarzenia (event), które są podstawą atrakcyjnego paradygmatu programowania zwanego programowaniem sterowanym zdarzeniami (event-driven programming). |
|
wykres stanów (state chart, statechart) Patrz: diagram stanów. |
|
wyliczalny (derived) Patrz: pochodny. |
|
wymagania (requirements) Zestaw mniej lub bardziej sformalizowanych zdań określający zakres merytoryczny systemu informatycznego (tzw. dziedzinę problemu), jego cel, misję, ograniczenia, którym ma podlegać, oraz jego wskaźniki eksploatacyjno-techniczne. |
|
wymiatanie (scavenging) Metoda zbierania nieużytków (garbage collection) polegająca na obiegnięciu wszystkich obiektów zgodnie z referencjami (jak w metodzie znacz i zamiataj), przepisaniu ich na nowy obszar i następnie skasowanie wszystkich danych w starym obszarze. Metoda ma zastosowanie prawie wyłącznie w pamięci operacyjnej. |
|
wyrażenie kropkowe (dot expression) Patrz: wyrażenie ścieżkowe. |
|
wyrażenie ścieżkowe (path expression) Wyrażenie umożliwiające przechodzenie od danych do kolejnych danych poprzez podanie ich nazw. Np. wyrażenie ścieżkowe Adam.PracujeW.Firma.Nazwa przechodzi kolejno od obiektu Adam poprzez powiązanie wskaźnikowe PracujeW do obiektu Firma, a stąd (poprzez zejście w dół hierarchii tego obiektu) do atrybutu Nazwa (firmy). Wyrażenia ścieżkowe umożliwiają konceptualizację dostępu do bazy danych i stanowią istotną cechę obiektowych języków zapytań. |
|
wysłanie komunikatu (sending a message) Przekazanie komunikatu od jego nadawcy do odbiorcy. |
|
wystąpienie (instance) Inaczej obiekt; termin „wystąpienie” podkreśla związek obiektu z jego klasą. Można mówić o bezpośrednich wystąpieniach klasy, czyli obiektach powiązanych z daną klasą bez pośrednictwa innych klas, oraz o pośrednich wystąpieniach klasy, tj. wszystkich obiektach, które w jakikolwiek sposób korzystają z definicji umieszczonych w tej klasie (tego rodzaju wystąpienie jest też określane jako „członek”). Terminu „wystąpienie” używa się także w innych kontekstach, w których istotne jest podkreślenie związku pewnego konkretnego bytu z jego definicją, typem lub deklaracją. W szczególności, wystąpieniem związku (relationship) lub asocjacji (association) jest konkretne powiązanie (link), wystąpieniem przypadku użycia jest konkretna interakcja użytkownika z systemem, wystąpienie procesu jest pewien jego konkretny przebieg, podobnie dla wystąpienia przepływu prac, itd. Często spotykanym synonimem terminu wystąpienie jest instancja (kalka terminu angielskiego). |
|
wystąpienie przypadku użycia (use case instance) Sekwencja akcji wykonywana przez system, której rezultatem jest rezultat obserwowalny dla pewnego aktora. Zwykle scenariusze ilustrują prototypowe wystąpienia przypadków użycia. |
|
wytwarzanie wspomagane komputerem (Computer Aided Manufacturing, CAM) Patrz: CAM. |
|
wytwórstwo oprogramowania (software development) Patrz: rozwój oprogramowania. |
|
wyzwalacz (trigger) Patrz: aktywne reguły. Synonim: tryger. |
|
wyzwolić (fire) Uruchomić pewną akcję, przejście, proces, czynność. |
|
wzorzec (pattern) Patrz: wzorzec projektowy. |
|
wzorzec projektowy (design pattern) Przykładowe lub
abstrakcyjne rozwiązanie często występującego problemu programistycznego lub
projektowego, które może być bezpośrednio użyte, lub może stanowić pomoc przy
rozwiązywaniu innych podobnych problemów. Wzorzec projektowy w systematyczny
sposób nazywa, motywuje i wyjaśnia stosunkowo często występujący element
projektu lub powtarzającą się sytuację projektową. W obiektowości wzorzec
projektowy identyfikuje klasy, ich wystąpienia, role, kolaboracje i
odpowiedzialności. Każdy wzorzec projektowy skupia się na pewnym szczególnym
problemie projektowym. Opisuje on, kiedy go stosować, jakie są ograniczenia w
stosowalności, oraz jakie są konsekwencje i kompromisy przy ich użyciu.
Wzorce projektowe w obiektowości zostały spopularyzowane w odniesieniu do
języków i systemów obiektowych przez grupę autorów określaną (żartobliwie)
jako „banda czworga” (gang of four, GOF): E. Gamma, R.
Helm, R. Johnson, J. Vlissides, którzy w szeroko spopularyzowanej książce (Design
Patterns) przedstawiają 21 wzorców projektowych. Dopasowanie tych i
innych wzorców do konkretnej sytuacji nie zawsze jest jednak oczywiste. Inną
wadą spotykanych w literaturze wzorców jest fakt, że często ich motywem jest
osłabienie negatywnych skutków złych lub ograniczonych rozwiązań niektórych
języków i systemów (np. C++ lub systemów relacyjnych); w wielu przypadkach
stałyby się one niepotrzebne, gdyby te języki lub systemy były lepiej
zaprojektowane. http://c2.com/ppr/index.html http://g.oswego.edu/dl/acs/acs/acs.html http://g.oswego.edu/dl/ca/ca/ca.html http://hillside.net/patterns/patterns.html http://st-www.cs.uiuc.edu/users/johnson http://st-www.cs.uiuc.edu/users/patterns/ http://st-www.cs.uiuc.edu/users/patterns/patterns.html http://www.enteract.com/~bradapp/docs/patterns-intro.html http://www.planet.net/bwalker/oo.html http://www.research.att.com/orgs/ssr/people/cope |
|
X Y Z |
|
Yourdon, Ed. Twórca metodyki obiektowej Coad/Yourdon oraz MainstreamObjects. |
|
Z++ Obiektowe rozszerzenie notacji Z. |
|
zachowanie (behaviour, behavior) Zestaw metod i innych abstrakcji proceduralnych przypisany do (klasy) obiektów. Synonim: behawior. |
|
zagnieżdżone relacje (embedded relations, nested relations) Patrz: nieznormalizowane relacje. |
|
zagnieżdżone transakcje (nested transactions) Koncepcja
przetwarzania transakcji, w której transakcja może składać się z
podtransakcji. Istnieją dwa podejścia do zagnieżdżonych transakcji:
|
|
zagnieżdżone zapytanie (nested query) Zapytanie będące fragmentem innego zapytania; zapytanie zawierające w sobie inne zapytanie. |
|
zagnieżdżony (nested) Termin ogólny; oznacza coś, co jest zawarte w innym bycie, jest składową innego bytu (np. zagnieżdżone zapytanie, zagnieżdżony moduł, itd.). Niekiedy terminem tym określa także byt zawierający w sobie inne byty (np. zagnieżdżona relacja). Synonim: zanurzony. |
|
zakleszczenie (deadlock) Sytuacja przy przetwarzaniu transakcji, powstająca m.in. wtedy, gdy transakcja T1 blokuje zasoby A i żąda dostępu do zasobów B, podczas gdy transakcja T2 blokuje zasoby B i żąda dostępu do zasobów A; żadna z nich nie może kontynuować swojego przebiegu. Możliwe są zakleszczenia, w których uczestniczy wiele transakcji. Istnieje szereg technik przeciwdziałania zakleszczeniom, w szczególności, nie dopuszczanie do zakleszczeń (np. popularna metoda „czekasz-giń” (wait-die), która automatycznie zrywa transakcję w sytuacji, kiedy musi ona czekać na zasoby), lub metody oparte na wykrywaniu zakleszczeń i zrywaniu jednej z transakcji uczestniczących w zakleszczeniu. Synonim: blokada. |
|
zakres (scope) Chodzi zwykle o zakres widoczności nazwy lub definicji (patrz: widoczność). Zakres jest kontekstem programu, w którym jest widoczna i może być użyta dana nazwa; patrz: reguły zakresu. Zakres może mieć charakter statyczny (inaczej leksykalny), ustalający fragmenty tekstu programu, w których jest widoczna dana nazwa. Podobnie zakres dynamiczny ustala, czy dana nazwa jest widoczna w aktualnie wykonywanym kodzie. Patrz też: zakres leksykalny, zakres dynamiczny. |
|
zakres dynamiczny (dynamic scope) W językach z zakresem dynamicznym dana nazwa jest widoczna poza tekstem sąsiadującym z jej definicją, np. jest widoczna wewnątrz procedur wywoływanych z danej procedury, w której jest zdefiniowana ta nazwa. Zakres dynamiczny jest własnością egzotyczną: daje niewielkie możliwości dodatkowe, zwiększając przy tym istotnie uciążliwość programowania i skłonność do błędów. |
|
zakres leksykalny (lexical scope) Określenie własności języków programowania, zgodnie z którą zakres definiowanej nazwy jest ograniczony do sąsiadującego z tą definicją tekstu programu (modułu, procedury, funkcji). Np. zakres zmiennej definiowanej wewnątrz pewnej procedury jest ograniczony do tekstu tej procedury; zmienna ta jest niewidoczna na zewnątrz. Synonim: zakres statyczny (static scope). Przeciwieństwem jest zakres dynamiczny (dynamic scope), kiedy dana nazwa jest widoczna poza sąsiedztwem jej definicji, np. wewnątrz procedur wywoływanych z danej procedury. |
|
zakres statyczny (static scope) Patrz: zakres leksykalny. |
|
zależne złączenie (dependent join) Konstrukcja lub operator
obiektowych języków zapytań takich jak OQL. Łączy on dwa zapytania, z których
pierwsze deklaruje pewną zmienną, zaś drugie odwołuje się do tej zmiennej.
Wynik stanowi kolekcja, w której każdy element jest kompozycją rezultatu
pierwszego zapytania z rezultatem drugiego. Np. jeżeli obiekty Pracownik
zawierają atrybuty wskaźnikowe PracujeW prowadzące do obiektów Firma,
to złączenie obiektów Pracownik z obiektami Firma można uzyskać
(w OQL) poprzez następujące zależne złączenie: Pracownik as x, x.PracujeW.Firma as
y W porównaniu z SQL, zależne złączenie umożliwia większą konceptualizację i skrócenie zapytań. W odróżnieniu od klasycznego złączenia, zależne złączenie nie jest operatorem algebraicznym, ponieważ zakłada, że ewaluacja drugiego argumentu jest uzależniona od wyniku ewaluacji pierwszego. |
|
zależność funkcyjna (functional dependency) Ograniczenie integralnościowe nakładane z zewnątrz na (nieskończoną) rodzinę relacji o wspólnym zestawie atrybutów, stwierdzające, że dla każdej relacji należącej do tej rodziny każda z wartości atrybutu A jest skojarzona z dokładnie jedną wartością atrybutu B; np. wartość atrybutu NR_PRACOWNIKA wyznacza dokładnie jedną wartość atrybutu NAZWISKO. Jest to zapisywane w postaci A ® B; mówi się też, że B jest funkcyjnie zależne od A. Zależność funkcyjną można łatwo uogólnić na przypadek, kiedy A i B są zestawami atrybutów. Istnieje aksjomatyka (Armstronga) tworząca prosty system dedukcyjny, pozwalający wnioskować o nowych zależnościach funkcyjnych na podstawie już istniejących zależności funkcyjnych, np. A ® BC implikuje A ® B oraz A ® C. Przy pomocy zależności funkcyjnych można łatwo zapisać i wyjaśnić niektóre anomalie w relacyjnych bazach danych, np. nie spełnienie warunków drugiej i trzeciej formy normalnej. Istniały nadzieje, że teorię zależności funkcyjnych (i innych) uda się wykorzystać do projektowania relacyjnych baz danych. Okazało się jednak, że są one w procesie projektowania praktycznie bezużyteczne, co podważyło sens rozwoju tej teorii. |
|
zamek (lock) Znacznik umieszczany przez daną transakcję na stronie dyskowej, danej, obiekcie, itp. Byt z umieszczonym na nim zamkiem staje się niedostępny dla innych transakcji aż do momentu, gdy dana transakcja zwolni zamek (co zwykle następuje po jej zerwaniu lub potwierdzeniu). Dostęp do samego zamka jest możliwy wyłącznie ze strony tej transakcji, która ten zamek założyła (oraz z programu nadzorującego przebieg wykonania wszystkich transakcji). Zamki mogą określać rodzaj operacji, które są dostępne lub niedostępne dla innych transakcji; np. zamek do czytania oznacza, że inne transakcje mogą czytać informację z danego bytu, ale nie mogą go zmieniać. Zamki są jedną z najprostszych metod synchronizacji równoległych transakcji (procesów); można je uważać za szczególny przypadek semaforów. Zamki są podstawową metodą przetwarzania transakcji w metodach określanych jako 2PL, lub ogólniej, w metodach określanych jako pesymistyczne. Patrz też: transakcja. |
|
zamek do czytania (read lock) Zamek umieszczany przez daną transakcję na pewnym bycie, który oznacza, że inne transakcje mogą czytać informację z tego bytu, ale nie mogą go zmieniać. Patrz też: zamek. |
|
zamek do pisania (write lock) Zamek umieszczany przez daną transakcję na danym bycie programistycznym, który oznacza, że inne transakcje nie mogą czytać informacji z danego bytu, ani też dokonywać w nim jakichkolwiek zmian. Patrz też: zamek. |
|
zamienialność (substitutability) Reguła zgodności typów mówiąca, że jeżeli w pewnym miejscu programu może być użyty byt programistyczny typu (klasy) A, to w tym miejscu może być również użyty dowolny byt programistyczny typu (klasy) B, o ile B jest podtypem (podklasą) A. Np. przy założeniu, że typ Student jest podtypem typu Osoba, reguła zamienialności ustala, że obiekt typu Student może być użyty wszędzie tam, gdzie może być użyty obiekt typu Osoba. Reguła lub zasada zamienialności została sformułowana przez B. Liskov (Liskov Substitutability Principle, LSP). Jakkolwiek wydaje się ona naturalna i oczywista, prowadzi do anomalii, m.in. związanych z operacją podstawienia i z wielodziedziczeniem. Regułę zamienialności można wyeliminować przyjmując semantycznie bardziej konsekwentną koncepcję ról obiektu; patrz: rola[1]. |
|
zanurzone zapytanie (embedded query) Patrz: zapytanie zanurzone. |
|
zanurzony (embedded) Dotyczy sytuacji, kiedy konstrukcje języka A (np. SQL) są używane wewnątrz konstrukcji języka B (np. PL/I, Pascal, C, C++, Ada); mówi się wtedy, że język A jest zanurzony w B, zaś B jest językiem-gospodarzem (host language). Technologia przetwarzania zakłada istnienie prekompilatora (precompiler), tj. programu, którego wejściem jest program zakodowany w A+B, zaś wynikiem jest program w B: konstrukcje języka A są zamieniane (zwykle na zasadzie rozwinięć makrosów) na sekwencje instrukcji języka B. Zaletą zanurzenia jest możliwość wykorzystania powiązania popularnego języka programowania z nowymi możliwościami, np. językiem zapytań. Zanurzenie zyskało sobie złą sławę, którą wyraża termin niezgodność impedancji (impedance mismatch). Z tego względu w systemach relacyjnych odchodzi się od koncepcji zanurzenia na rzecz budowy języków czwartej generacji oraz języków zintegrowanych takich jak SQL3. W obiektowych bazach danych (np. w standardzie ODMG) koncepcja zanurzenia jest (niestety) nadal dość popularna (chociaż w nieco zmodyfikowanej postaci). |
|
zapamiętana procedura (stored procedure) Procedura, zwykle napisana w SQL lub innym języku interpretowanym, która jest zapamiętana na dysku jako składnik bazy danych. W obiektowych bazach danych zapamiętane procedury mogłyby przyjąć postać zapamiętanych metod. Ta możliwość nie jest jednak własnością obecnych obiektowych baz danych, gdzie metody odnoszące się do trwałych obiektów są umieszczane poza bazą danych, najczęściej w programach aplikacyjnych. Synonim: procedura bazy danych. |
|
zapewnienie jakości (quality assurance, QA) Zestaw działań, metod, standardów, organizacji mających na celu uzyskanie jakościowego produktu, w szczególności oprogramowania. |
|
zapis (record) Termin używany w wielu starszych językach i systemach na oznaczenia zestawu nazwanych wartości. Synonimem zapisu w rodzinie języków C/C++ jest struktura, w systemach relacyjnych jest nim krotka lub wiersz, zaś w systemach obiektowych pojęcie zapisu jest protoplastą pojęcia obiektu. |
|
zapis z wariantami (record with variants) Patrz: unia. |
|
zapytanie (query) Wyrażenie języka zapytań, takiego jak SQL lub OQL. Zapytania charakteryzuje wysoki poziom abstrakcji (brak odwołań do struktur fizycznych takich jak np. indeksy), deklaracyjność (sformułowanie samego celu, a nie czynności do niego prowadzących), makroskopowość (jednoczesne działanie na wielu danych), naturalność (zgodność z naturalnym sposobem myślenia użytkownika), oraz efektywność (krótki czas wykonania zapewniany poprzez automatyczną optymalizację). Termin „zapytanie” jest często nadużywany, np. „zapytanie w języku C++” nie spełnia żadnego z wymienionych wyżej kryteriów. |
|
zapytanie ad hoc (ad hoc query) Zapytanie, które jest sformułowane interakcyjnie przez użytkownika (bezpośrednio z jego końcówki). Przeciwieństwem jest zapytanie zanurzone (embedded), stanowiące fragment programu aplikacyjnego. |
|
zapytanie interakcyjne (interactive query) Patrz: zapytanie ad hoc. |
|
zapytanie zagnieżdżone (embedded query, nested query) Patrz: zagnieżdżone zapytanie. |
|
zapytanie zanurzone (embedded query) Zapytanie, które stanowi fragment programu aplikacyjnego napisanego w pewnym języku programowania (np. w C). Przeciwieństwem zapytania zanurzonego jest zapytanie ad hoc. |
|
zarządca trwałymi obiektami (Persistent Storage Manager, PSM) Patrz: skład trwałych obiektów. |
|
zarządzanie wersjami (version management) Patrz: sterowanie wersjami. |
|
zasada korespondencji (correspondence principle) Zasada korespondencji mówi, że wraz z wprowadzeniem do języka pewnej cechy X należy precyzyjnie określić inne cechy języka w taki sposób, aby cecha X współdziałała z już istniejącymi konstrukcjami tego języka, została wtopiona w istniejące lub zmodyfikowane mechanizmy nazywania, typowania, zakresu i wiązania, oraz miała zapewnioną uniwersalną obsługę. Przykładowo, jeżeli cechą X jest dynamiczna tablica, to odpowiednimi pytaniami są: czy może ona być składową zapisu (struktury, obiektu), czy może być parametrem procedury, czy może być zwrócona przez procedurę funkcyjną, jakie środki będą przewidziane do typowania, wyszukiwania, aktualizacji, usuwania, dostawiania elementów; itd. Oddolny rozwój niektórych języków (np. SQL) jest przyczyną wielu przypadków łamania zasady korespondencji, co objawia się m.in. tym, że nowo dodawane cechy nie dają się gładko kombinować ze starymi cechami. |
|
zasada otwarte/zamknięte (open/closed principle) Zasada obowiązująca przy konstrukcji obiektowych języków programowania, zgodnie z którą klasa jest otwarta na rozszerzenia (specjalizacje), lecz jest zamknięta na modyfikacje. Konsekwencją tej zasady jest zasada zamienialności. |
|
zasada relatywizmu (relativity principle) Zasada mówiąca, że część pewnego bytu semantycznego powinna mieć takie same ogólne własności jak całość. Relatywizm obiektów oznacza, że dowolny obiekt składa się również z obiektów (podobiektów); pojęcie atrybutu staje się zbędne. Konsekwencją relatywizmu jest istnienie obiektów, które nie posiadają atrybutów (czyli obiektów atomowych), jak również obiektów, dla których nie jest istotne definiowanie klas. Relatywizm obiektów posiada istotne konsekwencje dla modelu danych, języków zapytań, interfejsów programistycznych oraz języków programowania, gdyż pociąga za sobą relatywizm środków definiowania danych i określania ich typów, oraz relatywizm środków dostępu do danych. Dzięki relatywizmowi środki te mogą być uproszczone do minimum. Minimalizacja ilości cech, które muszą być rozpatrywane przy definiowaniu i manipulowaniu obiektami, ma istotne konsekwencje dla prostoty modelu obiektowego, szybkości jego nauczania, rozmiaru dokumentacji, rozmiaru i regularności języków, złożoności modeli formalnych oraz łatwości i ogólności metod implementacyjnych. Jak dotąd, relatywizm obiektów nie jest koncepcją popularną. Metodyki i notacje służące do analizy i projektowania, np. OMT i UML, wyróżniają obiekty i atrybuty obiektów jako różne pojęcia. Podobne założenia przyjmuje większość języków programowania (poza językiem Smalltalk, systemem Loqis i niektórymi innymi koncepcjami). |
|
zasada zamienialności (substitutability principle) Patrz: zamienialność. |
|
zastępowalność (substitutability) Patrz: zamienialność. |
|
zastosowanie spadkowe (legacy application) Zastosowanie oparte o system spadkowy, czyli starszy system ciągle będący w eksploatacji. Synonim: aplikacja spadkowa. |
|
zbieranie nieużytków (garbage collection) Funkcja systemu, której zadaniem jest uzyskanie informacji o nieużytkach w pamięci operacyjnej lub na dysku (tj. o takich obszarach, które nie są wykorzystywane przez aktualnie przechowywane dane) i następnie, przesunięcie tych nieużytków do puli wolnej pamięci, która jest używana przy alokacji nowych danych. Do niedawna automatyczne zbieranie nieużytków uważane było za luksus, na który mogły sobie pozwolić wyłącznie języki o statusie idealizujących akademickich wzorców, takich jak LISP, ML czy CLU. W ostatnich latach ten pogląd uległ zmianie wskutek faktu, że pozostawienie problemu odzyskiwania nieużytków w rękach programistów prowadzi z reguły do błędów (patrz: wyciekanie pamięci). Konstrukcja szeregu języków (np. C++) jest słabo przygotowana do wprowadzenia tej funkcji, głównie ze względu na cechy niskiego poziomu, takie jak wskaźniki. Synonim: odśmiecanie. |
|
zbiór (set) W terminologii obiektowych baz danych (np. ODMG), konstruktor typów/klas nawiązujący do matematycznego pojęcia zbioru. Obiekt lub wartość typu zbiór można dowolnie zwiększać o nowe elementy oraz usuwać z niej elementy; nie może ona jednak zawierać dwóch identycznych elementów (lub równoważnie, istnienie dwóch lub więcej identycznych elementów nie ma znaczenia informacyjnego; duplikaty mogą być usunięte bez żadnych skutków dla przetwarzania). Porządek elementów w zbiorze nie ma znaczenia. W obiektowych bazach danych pojęcie zbioru jest kontrowersyjne, gdyż implikuje automatyczne usuwanie duplikatów (które jest bardzo kosztowne), oraz wymaga precyzyjnego zdefiniowania pojęcia równości elementów (co prowadzi do szeregu problemów semantycznych). |
|
zdarzenie (event) Pojęcie (występujące w metodykach analizy i projektowania oraz w niektórych językach programowania) oznaczające rejestrowalną zmianę stanu otoczenia lub środowiska (np. nadejście partii towaru, naciśnięcie klawisza Esc, itd.), albo nadejście określonego momentu czasowego. Szczególnym przypadkiem zdarzenia jest wyjątek. Zwykle przyjmuje się, że zdarzenie występuje losowo (asynchronicznie) w stosunku do normalnego przepływu sterowania programu i z tego względu jest pojęciem różnym od pojęcia komunikatu. Ostatnio popularny stał się paradygmat programowania sterowanego zdarzeniami (szczególnie w odniesieniu do interfejsów graficznych) w językach określanych jako języki czwartej generacji (4GL). |
|
zdarzenie zegarowe (clock event) Zdarzenie generowane po upływie pewnego odcinka czasu (stoper) lub w pewnym momencie (budzik). |
|
zdarzenie-warunek-akcja (event-condition-action, ECA) Paradygmat aktywnych reguł. Aktywna reguła uaktywnia się w wyniku pojawienia się określonego dla niej zdarzenia; jeżeli po nim spełniony jest określony warunek, to wówczas podejmowana jest akcja. Patrz też: aktywne reguły. |
|
zdjęcie (snapshot) Plik lub inna struktura danych przechowująca pewien chwilowy stan obiektów, stan zmiennych programu lub stan bazy danych. Najczęściej zdjęcie jest kopią bazy danych lub pewnego jej fragmentu (perspektywy), odwzorowującą pewien jej chwilowy stan. W odróżnieniu od składowania (back up) lub zrzutu (dump) zdjęcie może być przetwarzane przez standardowe środki programistyczne (np. przez SQL). Zdjęcia traktuje się często jako synonim zmaterializowanej perspektywy (materialized view); głównym jego celem jest uproszczenie programowania i polepszenie czasów wykonania. Zdjęcie jest również pojęciem stosowanym w technikach replikacji. Synonim: zdjęcie migawkowe. |
|
zdolny do trwałości (persistence-capable) Określenie klasy, której wystąpieniami mogą być zarówno obiekty ulotne, jak i trwałe. Termin występuje w standardzie ODMG (wiązanie do języka Java). |
|
zerwanie (abort) Przerwanie wykonania transakcji i odtworzenie stanu bazy danych sprzed początku jej działania. Zerwanie może być konsekwencją nienormalnych warunków zaistniałych podczas działania transakcji, lub może być wynikiem specjalnej komendy wydanej z wnętrza lub spoza danej transakcji. |
|
zerwanie transakcji (transaction abort) Patrz: zerwanie. |
|
zestaw miar (metrix suite) Zestaw wzajemnie uzupełniających się miar, pozwalający na wieloaspektową ocenę jakości lub złożoności oprogramowania, lub też jakości pracy uczestników danego projektu. |
|
zestaw testów (test suite) Zestaw (seria) wzajemnie uzupełniających się testów, pozwalający na wieloaspektową ocenę jakości oprogramowania. |
|
zewnętrzne złączenie (outer join) Złączenie tablic A i B może spowodować utratę informacji zawartej w tych tablicach. Niech np. A jest tablicą MIASTO z atrybutem NAZWA, zaś B jest tablicą PRACOWNIK z atrybutem MIEJSCE_URODZENIA. Złączenie tych dwóch tablic według wymienionych atrybutów spowoduje zgubienie informacji o wszystkich tych miastach, w których nie urodził się żaden pracownik, oraz o wszystkich tych pracownikach, dla których wartością atrybutu MIEJSCE_URODZENIA jest wartość zerowa (NULL). Motywem operatora zewnętrznego złączenia jest takie złączenie, które nie gubi informacji. Koncepcja ta zakłada, że dla każdej „wystającej” krotki, czyli takiej, której nie można złączyć z chociaż jedną krotką drugiej relacji, buduje się wiersz wynikowej tablicy, w którym ta krotka zostaje uzupełniona wartościami zerowymi (NULL values). Wyróżnia się lewostronne, prawostronne lub pełne zewnętrzne złączenie, w zależności od tego, która relacja jest podstawą pętli realizującej złączenie. Zewnętrzne złączenie jest istotne jako abstrakcja pojęciowa służąca do budowania zapytań. Stąd operator ten pojawił się w standardzie SQL-92. Pojęcie zewnętrznego złączenia może mieć także znaczenie w obiektowych językach zapytań. |
|
zgodność typów (type conformance) Reguły i metareguły ustalające, kiedy typ T1 pewnego bytu programistycznego wydedukowany na podstawie reguł wnioskowania o typie (type inference rules) jest zgodny z typem T2, występującym w deklaracji tego typu. Przykładem takich reguł jest zamienialność, kowariancja, kontrawariancja, nazwowa zgodność typów, strukturalna zgodność typów, itd. |
|
ziarnistość (granularity) Termin ten oznacza rodzaj jednostki danych będącej przedmiotem pewnych szczególnych procesów działających na bazie danych. Rozróżnia się ziarnistość blokowania (locking granularity) oznaczającą najmniejszą jednostkę, która może być zablokowana przez transakcję, ziarnistość replikacji (replication granularity) oznaczającą najmniejszą jednostkę, w stosunku do której można utworzyć odległą replikę, ziarnistość autoryzacji (authorization granularity) oznaczającą najmniejszą jednostkę, która może być uwzględniona przez prawa dostępu, itp. W systemach relacyjnych w większości poziom ziarnistości blokowania jest określony poprzez krotkę relacji, lub fizyczną stronę przesyłaną z pamięci zewnętrznej do operacyjnej i odwrotnie. W systemach obiektowych taką jednostką jest zwykle obiekt lub strona fizyczna. Systemy obiektowe mogą być także oparte o koncepcję zmiennej ziarnistości, przy której jednostką blokowania w tym samym systemie może być ekstensja klasy, obiekt, podobiekt, atrybut, itd. Istnieje kontrowersja odnośnie tego, czy ziarnistość ma odnosić się do poziomu logicznego (np. obiektów), czy też fizycznego (np. stron). W systemach relacyjnych ze względów wydajnościowych przyjmowano, że ziarnistość odnosi się do poziomu fizycznego (stron). Przy takim rozwiązania (odległy) serwer obiektów przesyła do klienta strony nie wnikając w ich semantykę, co może zaowocować znacznym wzrostem objętości przesyłanych danych. |
|
zlecenie (request) Dowolny komunikat wysłany do serwera (lub do obiektu) zlecający wykonanie usługi na rzecz klienta (lub innego obiektu). |
|
zlecenie asynchroniczne (asynchronous request) Zlecenie, po którym klient nie czeka na rezultat, lecz wykonuje dalsze czynności. Odpowiedź na takie zlecenie jest nadsyłana przez serwer po pewnym czasie, lub też klient może wysłać do serwera inne zlecenie sprawdzające stan wykonania wysłanego zlecenia asynchronicznego. |
|
zlecenie synchroniczne (synchronous request) Zlecenie, po którym klient czeka na rezultat. Zlecenie synchroniczne jest równoważne (zdalnemu) wołaniu procedury lub metody. |
|
zliczanie referencji (reference count) Metoda stosowana w algorytmach zbierania nieużytków (garbage collection) polegająca na tym, że każdy obiekt jest wyposażony w licznik określający, ile referencji (lub wskaźników) prowadzi do tego obiektu; dodanie nowej referencji zwiększa licznik o 1, usunięcie referencji zmniejsza licznik o 1. Obiekt przestaje istnieć, jeżeli skojarzony z nim licznik wskazuje zero. Zaletą metody jest to, że zbieranie nieużytków można wykonywać „w locie", bez zawieszania procesów operujących na danych. Wadami metody są: niestabilność (błąd może spowodować, że bezużyteczny obiekt pozostanie na zawsze lub użyteczny zostanie usunięty) oraz niemożliwość wykrycia nieużytków, o ile referencje od bezużytecznych obiektów do bezużytecznych obiektów tworzą cykl. |
|
złączenie (join) Jeden z ważniejszych operatorów występujących w systemach relacyjnych. Umożliwia utworzenie tablicy, która w logiczny sposób łączy informacje zawarte w dwóch (lub więcej) tablicach. Np. dla tablic Dział i Pracownik złączenie tworzy tablicę zawierającą dane z obydwu tablic w ten sposób, że numer działu wewnątrz tablicy Pracownik jest kojarzony z numerem działu wewnątrz tablicy Dział. W języku SQL operator ten nie występuje explicite: jest on złożeniem operatorów produktu kartezjańskiego i selekcji. Operator ten występuje często na poziomie implementacyjnym: istnieje szereg sprawnych metod implementacji operatora złączenia, w szczególności metody oparte o sortowanie obydwu relacji i scalenie (merging), oraz metody oparte o kodowanie mieszające. W obiektowych językach zapytań złączenie odgrywa znacznie mniejszą rolę ze względu na to, że obiektowa struktura danych może zawierać hierarchicznie zbudowane obiekty oraz powiązania wskaźnikowe (które mają charakter predefiniowanych złączeń). |
|
złączenie naturalne (natural join) W modelu relacyjnym, złączenie bazujące na identyczności nazw kolumn złączanych tablic. Np. naturalne złączenie tablic: FIRMA(NrFirmy, Nazwa, Adres) oraz PRACOWNIK(NrPrac, Nazwisko, NrFirmy) utworzy pewną relację R(NrFirmy, Nazwa, Adres, NrPrac, Nazwisko), gdzie warunkiem złączenia będzie identyczność wartości w kolumnach NrFirmy obu tablic. Złączenie naturalne nie występuje w SQL. Nie ma też odpowiedników w obiektowych językach zapytań. |
|
złączenie nawigacyjne (navigational join) Patrz: zależne złączenie. |
|
złączenie zależne (dependent join) Patrz: zależne złączenie. |
|
złączenie zewnętrzne (outer join) Patrz: zewnętrzne złączenie. |
|
złożoność (complexity) Charakterystyka, miara ilościowa lub miara jakościowa odzwierciedlająca stopień skomplikowania danego problemu, poziom trudności rozwiązania problemu, lub stopień skomplikowania pewnego tworu ludzkiej działalności. Próbą formalnego podejścia do problemu złożoności jest złożoność algorytmiczna, badająca zależność pewnego użytkowego aspektu danego algorytmu (najczęściej czasu działania) od rozmiaru danych lub parametrów tego algorytmu; np. zależność czasu sortowania od ilości sortowanych elementów. W analizie i projektowaniu złożoność nie daje się wyrazić w terminach matematycznych; stosowane są miary empiryczne, w dużej mierze subiektywne. Złożoność jest faktem towarzyszącym prawie wszystkim projektom lub produktom informatyki. Jednym z filozoficznych motywów obiektowości jest zredukowanie złożoności tworów informatycznych, procesów ich wytwarzania oraz metod ich utrzymania i modyfikacji. |
|
złożony atrybut (complex attribute, composite attribute) Patrz: atrybut złożony. |
|
złożony obiekt (complex object, composite object) Patrz: obiekt złożony. |
|
zmaterializowana perspektywa (materialized view) Dane lub obiekty pochodne wyliczone na podstawie pewnej definicji. Np. zmaterializowaną perspektywą dla obiektów Pracownik mogą być obiekty StaryPracownik wyliczone na podstawie warunku Wiek > 60. Podstawowym problemem dla realizacji zmaterializowanych perspektyw jest ich jednoczesna (tzw. przyrostowa, incremental) aktualizacja po aktualizacji oryginalnych danych, które stanowiły podstawę utworzenia danej zmaterializowanej perspektywy. |
|
zmienialność (mutability) Własność bytu programistycznego (np. obiektu) oznaczająca możliwość zastosowania operacji aktualizacji; ta własność jest często (nie zawsze) składnikiem typu. Własność zmienialności jest najczęściej wiązana z parametrem procedury lub metody i oznacza, że parametr jest przekazywany przez referencję (call-by-reference). |
|
zmienialny (mutable) Określenie parametru lub innej cechy posiadającej własność zmienialności; patrz: zmienialność. |
|
zmienna globalna (global variable) Zmienna dostępna dla wszystkich bytów programistycznych; zmienna znajdująca się w powszechnie dostępnym środowisku lub zakresie. |
|
zmienna klasowa (class variable) Patrz: zmienna klasy. |
|
zmienna klasy (class variable) Zmienna programistyczna umieszczona wewnątrz klasy, której wartość jest wspólna dla wszystkich obiektów (wystąpień) tej klasy. Patrz też: atrybut klasy. |
|
zmienna polowa (field variable) Atrybut obiektu w terminologii języka Java. |
|
zmienna wystąpienia (instance variable) Inne określenie (Smalltalk) atrybutów obiektu. W koncepcji ortodoksyjnej hermetyzacji zmienne wystąpienia są ukryte i dostępne wyłącznie poprzez metody. |
|
zmienność (mutability) Patrz: zmienialność. |
|
znacz i zamiataj (mark and sweep) Metoda stosowana w mechanizmach zbierania nieużytków. Zakłada się, że każdy obiekt jest wyposażony w jednobitowy znacznik. W pierwszej fazie (znacz) następuje wyzerowanie wszystkich znaczników i następnie obiegnięcie całego zestawu obiektów od pewnych obiektów początkowych (korzeni) zgodnie z referencjami (wskaźnikami) prowadzącymi od obiektów do obiektów; w odwiedzanych obiektach znacznik ustawia się na 1. W ten sposób obiekty, do których nie prowadzi żadna referencja, nie zostaną zaznaczone. W drugiej fazie (zamiataj) następuje fizyczne usunięcie nie zaznaczonych obiektów. Zaletą metody jest jej stabilność (mała wrażliwość na niespójności organizacji danych). Wadą metody jest konieczność zawieszenia normalnej pracy systemu na czas działania tego mechanizmu. |
|
zorientowany na wartości (value-oriented, value-based) Określenie modeli danych nie wprowadzających pojęcia wewnętrznego identyfikatora danej; np. model relacyjny, zagnieżdżone relacje, modele funkcjonalne i modele oparte o logikę (dedukcyjne). Niektórzy autorzy bronią tych modeli jako posiadających przewagę nad modelem obiektowym. Z kolei przeciwnicy tej koncepcji eksponują ich fundamentalną wadę polegającą na braku możliwości określenia naturalnej i spójnej definicji operacji aktualizacyjnych (ze względu na brak pojęcia stanu). |
|
zorientowany obiektowo (object-oriented) Inaczej obiektowy; patrz: obiektowość. |
|
zunifikowany język do modelowania (Unified Modeling Language, UML) Patrz: UML. |
|
związek (relationship) W modelu encja-związek, powiązanie asocjacyjne pomiędzy encjami, np. powiązanie PracujeW pomiędzy encją Pracownik i encją Firma. W modelach obiektowych związek taki nosi nazwę asocjacji (association), kompozycji (composition) lub agregacji (aggregation). Związek może być binarny (łączący dwie encje lub obiekty), ternarny (łączący trzy encje lub obiekty), lub wyższego rzędu. Związek posiada nazwę; poszczególne dziedziny związków mogą również posiadać nazwy, zwane rolami. Związek może posiadać własne atrybuty i niekiedy (np. w OMT i UML) może być wystąpieniem własnej klasy. Na diagramach encja-związek lub obiektowych deklarowana jest także liczność związku, określająca minimalną i maksymalną liczbę wystąpień innej klasy, które poprzez ten związek są powiązane z jednym wystąpieniem danej klasy. Synonim: asocjacja. |
|
związek „jest” (is-a relationship) Związek zawierania się zakresów znaczeniowych pojęć (zbiorów obiektów), np. związek pomiędzy pojęciem STUDENT i pojęciem OSOBA: STUDENT „jest" OSOBA. Związek „jest” jest inaczej określany jako generalizacja/specjalizacja. Jest on również praktycznie tożsamy ze związkami dziedziczenia wyznaczającymi hierarchię klas. |
|
związek dwukierunkowy (bidirectional relationship) Związek umożliwiający przechodzenie (nawigację) od jednej klasy do drugiej klasy, i odwrotnie. |
|
związek jednokierunkowy (unidirectional relationship) Związek umożliwiający przechodzenie (nawigację) od jednej klasy do drugiej klasy, ale nie odwrotnie. |
|
związek pochodny (derived relationship) Związek, który wynika z innych związków, lub który można wydedukować z innych informacji, np. atrybutów. |
|
zwisające powiązanie (dangling link) Powiązanie, które prowadzi do nieistniejącego obiektu. |
|
zwisający wskaźnik (dangling pointer) Wskaźnik, który nie jest identyfikatorem aktualnie przechowywanego obiektu, i którego wartość nie jest zerowa (NIL). |
