Obiektowość



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

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

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

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

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

blokada (deadlock) Patrz: zakleszczenie.

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

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



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

http://www.omg.org



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

http://www.omg.org



bogaty klient (rich klient) Patrz: mocny klient.

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

BON (Business Object Notation) Obiektowa metodyka analizy i projektowania systemów informatycznych oraz notacja graficzna zaproponowana przez Nersona, Meyera i Wadena. BON jest wiązany z językiem Eiffel, chociaż nie jest ograniczony do tego języka. Podstawowymi zasadami BON są:

  • bezszwowa integracja i użycie jednego spójnego systemu pojęć na wszystkich etapach projektu;

  • odwracalność, oznaczająca, że dowolna zmiana poczyniona na dalszym etapie projektu może być odwzorowana do tyłu (do poprzednich etapów projektu);

  • kontrakty w ramach oprogramowania (software contracting). Budowa oprogramowania jest poprzedzana ustalaniem precyzyjnych kontraktów pomiędzy jego modułami, dla zapewnienia niezawodności i spójności.

Patrz też: projektowanie przez kontrakty.

http://www.eiffel.com/products/bon.html

http://ftoomsh.progsoc.uts.edu.au/~geldridg/frsd2/b-bon1.htm


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

http://www.itr.ch/tt/case/BoochReferenz

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


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

http://www.rational.com/



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

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

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

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

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

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

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

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

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

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

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



  • Systemy relacyjne i SQL posiadają solidne podstawy matematyczne (w przeciwieństwie do systemów obiektowych).

  • Operatory algebry relacji spełniają tę samą rolę dla systemów baz danych, jak operatory arytmetyczne dla komputera.

  • W języku Smalltalk wszystko jest obiektem! („A komunikat też?” - „Eeeeee ... no .... nie.”)

  • Algebra relacji może być łatwo rozszerzona do pełnego, uniwersalnego języka programowania aplikacji.

  • Warunkiem optymalizacji obiektowych zapytań jest przekształcenie ich do postaci określonej przez pewną obiektową algebrę.

  • Zagnieżdżanie obiektowych zapytań wymaga spełnienia własności domkniętości (closure property), polegającej na tym, że zarówno wejściem jak i wynikiem zapytań są obiekty.

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

  • Hermetyzację należy odrzucić, bo uniemożliwia realizację języków zapytań.

  • Hermetyzacja polega na tym, że widoczne są wyłącznie niektóre metody obiektu, zaś niewidoczny jest jego stan (atrybuty). (Patrz: hermetyzacja.)

  • Dziedziczenie (oraz wielodziedziczenie) jest całkowicie zbędne, bo można je łatwo odwzorować przez agregację (delegację, asocjację, dodatkową tablicę, itd.).

  • Dynamiczne role obiektu powodują nieakceptowalne skomplikowanie modelu obiektowego; można je łatwo odwzorować przez odpowiednie wzorce projektowe (np. dekoratora).

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

  • Obiekty rozproszone nie mogą mieć (lub nie powinny mieć) stanu.

  • Systemy relacyjne umożliwiają matematyczną weryfikację poprawności zaprojektowanej bazy danych.

  • Ponieważ bazy danych zawierają fakty, zaś fakty opisuje logika predykatów, wobec tego logika predykatów jest doskonałym narzędziem przetwarzania baz danych.

  • Kręgosłupem SQL jest logika matematyczna.

  • Kręgosłupem OQL jest rachunek dziedzinowy (domain calculus).

  • Obiektowość w bazach danych jest przejściową modą; w dłuższym horyzoncie zwyciężą dedukcyjne bazy danych.

  • Obiektowe bazy danych nie mogą być wyposażone w języki zapytań.

  • Obiektowe języki zapytań nie mają (i nie mogą mieć) sprawnych metod optymalizacyjnych.

  • Jeżeli X jest kolekcją, wówczas składnia języka zapytań X.Y prowadzi do niejednoznaczności; konieczne jest w takiej sytuacji użycie składni select Y from X.

  • Obiektowe bazy danych nie mogą zapewnić skalowalności (bezpieczeństwa, wydajności, wielodostępu, przetwarzania transakcji, rozproszenia, itd.).

  • Obiektowość jest dobra na etapie analizy i projektowania, ale jest mało przydatna dla implementacji.

  • Aby uniknąć niespójności związanej ze zwisającymi wskaźnikami wystarczy nie wprowadzać w języku operacji usuwania obiektu, ale powierzyć tę sprawę mechanizmowi automatycznego zbierania nieużytków.

  • Uniwersalnym środkiem projektowania jest notacja Z (sieci Petriego, VDM, itd.); umożliwia ona matematyczną weryfikację poprawności projektu.

  • Obiektowe bazy danych sprowadzają się do dodania cechy trwałości do obiektowych języków programowania.

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

C

C

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

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

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

http://www.csci.csusb.edu/dick/c++std/ (C++ Standard)

http://www.cygnus.com/misc/wp/

http://info.desy.de/user/projects/C++.html

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



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

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

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

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

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

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

  • Graficzne interfejsy do rysowania, modyfikacji i drukowania diagramów encja-związek, diagramów klas, diagramów stanów, diagramów przepływu danych, lub innych diagramów.

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

  • Sprawdzanie formalnej zgodności pomiędzy różnymi diagramami.

  • Prowadzenie wspólnego słownika użytych nazw i sprawdzanie zgodności ich użycia.

  • Definiowanie i przetwarzanie więzów integralności.

  • Specyfikowanie funkcji aplikacyjnych działających na projektowanej bazie danych, poprzez określenie danych wejściowych, danych wyjściowych, oraz semantyki funkcji.

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

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



Składowe narzędzi CASE

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



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

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



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

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

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

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

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

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



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

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

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

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

cienki klient (thin klient) Patrz: chudy klient.

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

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

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



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

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

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

http://www.franz.com/



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

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

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

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

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

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

http://www.microsoft.com/com

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



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

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

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

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


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

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



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

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

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



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

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

http://www.omg.org

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

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

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

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

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

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

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

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



Pobieranie 6.06 Mb.

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




©operacji.org 2020
wyślij wiadomość

    Strona główna