Obiekty, biblioteki, komponenty

W działalności inżynierskiej tworzenie nowych produktów z istniejących elementów jest normą. W sztuce programowania, dumnie nazywanej "inżynierią oprogramowania", raczej wyjątkiem.

W działalności inżynierskiej tworzenie nowych produktów z istniejących elementów jest normą. W sztuce programowania, dumnie nazywanej "inżynierią oprogramowania", raczej wyjątkiem.

Idea wielokrotnego używania kodu kusiła informatyków już od początku lat 70., jednak inżynieria oprogramowania nigdy nie osiągnęła rygorów zbliżonych do standardów stosowanych w tradycyjnej technice inżynierskiej. Ponadto uzyskanie znaczącej obniżki kosztów okazało się trudniejsze niż oczekiwano z powodu ogromnych trudności w zarządzaniu projektami z wielokrotnym używaniem już opracowanego kodu.

Wprowadzenie programowania obiektowego nadało nowy wymiar inżynierii oprogramowania. Trzeba pamiętać, że obiektowe to osiągnięcie techniczne: połączenie programowania sterowanego zdarzeniami, obsługiwanymi przez system operacyjny, z obiektami binarnymi tworzonymi z klas znacznie przyspieszyło proces produkcji oprogramowania. Jednak nie wniosło istotnie nowych wartości w proces tworzenia aplikacji.

Głównym motorem zmian jest biznes. W szybko zmieniającym się świecie, gdzie konieczna jest elastyczność, natychmiastowa reakcja na warunki rynkowe jest możliwa tylko przez stosowanie efektywnych metod tworzenia i osadzania programów z gotowych komponentów. Koszt przestaje być najważniejszym czynnikiem oprogramowania.

To są również powody ograniczonego sukcesu rynkowego bibliotek klas obiektowych i eksplozji rynku komponentów. Klas używają osoby zafascynowane programowaniem. Dobrze opracowane klasy niewątpliwie przyspieszają wiele projektów, choć nie wnoszą nowych jakości w proces tworzenia oprogramowania. Natomiast komponenty i ramy komponentowe pozwalają realizować projekty informatyczne w nowy sposób.

Komponenty

Klasa określa charakterystykę tego, co stanie się obiektem - czasową instancją klasy, gdy program będzie działał. Biblioteki zaś to zbiór opisów klas. Komponent natomiast nie jest ani obiektem, ani klasą.

Komponenty to niezależne jednostki binarne, współdziałające z sobą w taki sposób, aby stworzyć w pełni funkcjonalny system; komponent zawiera jedną lub więcej klas, a jego funkcje są dostępne przez interfejsy. Komponent to zamknięta (encapsulated) jednostka stworzona do określonego celu. Może być używany wielokrotnie, niezależnie od języka, w którym został napisany, pod warunkiem stosowania we właściwych ramach i środowisku.

Definicja ta nie zawiera informacji o rozmiarze ani o właściwościach funkcjonalnych komponentu. W praktyce spotyka się komponenty zarówno bardzo proste (np. do sprawdzania poprawności liczby wprowadzanej do określonego pola formularza), jak i bardzo złożone (cała aplikacja).

Komponenty działają za pośrednictwem interfejsów, nie ma więc przeszkód, aby w dowolnym momencie zamienić je na inne - ulepszone, ale o tych samych interfejsach. Większość komponentów ma charakter "czarnego pudełka" - informacje o ich realizacji nie są dostępne dla programisty. Znacznie rzadziej na rynku pojawiają się komponenty typu "białe pudełko" (z dostępnym kodem źródłowym) lub "przeźroczyste pudełko" (można do ich kodu zajrzeć, ale nie można go zmienić).

Ramy komponentowe

Dawne aplikacje były monolityczne - zawierały dane i kod. Dotyczy to również pierwszych aplikacji dla komputerów PC. W miarę upływu czasu pojawiły się systemy dwuwarstwowe, w których następuje oddzielenie danych, przechowywanych na centralnym serwerze, od kodu na PC. Systemy trój- i wielowarstwowe z pośrednimi warstwami programowymi pozwalają na separację danych, logiki aplikacji i warstwy prezentacji. Pojawiły się pierwsze rozwiązania architektoniczne do separacji danych od logiki aplikacji: Oracle NCA (Network Computing Architecture) i Microsoft DNA (Distributed Internet Applications Architecture).

Internet stworzył potrzebę komunikacji i możliwość uruchamiania komponentów na różnych systemach. Obecnie dwie podstawowe platformy komponentowe to Microsoft COM i Object Management Group CORBA. Nowa platforma komponentowa Enterprise Java Beans (EJB) jest bliska platformie CORBA i korzysta z jej rozwiązań (protokołów komunikacyjnych, brokerów obiektowych ORB, zestawów usług), a nowe opracowania OMG (np. CORBA Beans) pozwalają sądzić, że niedługo różnice pomiędzy tymi platformami się zatrą.

COM działa tylko w Windows i stanowi rozwinięcie idei wymiany danych na jednym komputerze poprzez OLE. Ulepszone COM, wdrożone w Windows NT i Windows 2000, stanowi podstawę obiektowej strategii Microsoftu. W połączeniu z monitorem transakcyjnym Microsoft Transaction Monitor (MTS) pozwala na realizację rozproszonych systemów transakcyjnych - bazy współczesnych aplikacji dla biznesu.

CORBA istnieje już od dłuższego czasu i jest dostępna w implementacjach na wiele systemów operacyjnych, pozwalając na niezawodną komunikację między różnymi platformami. Powstał również obszerny rynek komponentów dla serwerów aplikacyjnych CORBA, a jej mechanizmy komunikacyjne są używane do łączenia dawnych aplikacji na mainframe'ach ze środowiskiem współczesnych aplikacji biznesowych.

Istnieją również mosty COM/CORBA pozwalające na komunikację między dwiema platformami.

Komponentowa wojna

Linia podziału komponentów przebiega w zasadzie na granicy COM - CORBA. Komponentowy model EJB nie wprowadził tu dywersji, można go bowiem identyfikować z modelem CORBA, w którym wszystkie komponenty opracowuje się w języku Java.

Ten podział komponentów i ciągła dyskusja na temat przewagi jednego modelu nad drugim ma charakter bardziej polityczny niż techniczny, chociaż jej implikacje rynkowe są ogromne. Nie chodzi bowiem o to, który z modeli jest lepszy, ale o to, jak będzie wyglądała informatyka korporacyjna przez następne dziesiątki lat. Nie dziwią więc z jednej strony ostre ataki Microsoftu, z drugiej - koalicji IBM, Sun i Oracle.

Przechodzimy na komponenty

Komponenty można pozyskać: z własnych zasobów programowych, poprzez modyfikację istniejących modułów kodu do postaci komponentów, drogą opracowania nowych, zaprenumerowanie w Internecie biblioteki komponentów w celu sprawdzenia ich przydatności i ewentualnego kupna, nabycia ich od dostawcy komponentów lub wykorzystanie istniejących aplikacji przez zamknięcie ich w odpowiedniej otoczce obiektowej.

Przejście na technikę komponentową powinno odbywać się stopniowo przez identyfikację prostych procesów, które trzeba zautomatyzować, i stworzenie (lub nabywanie) komponentów realizujących potrzebne funkcje. Zdobycie doświadczenia w jednej dziedzinie pozwoli rozszerzyć technikę komponentową na inne procesy, obszary, oddziały, a także na całą organizację. Nie poleca się natomiast rozwiązania, polegającego na przepisaniu od nowa wszystkich aplikacji w technice komponentowej.

Na rynku pojawiły się już zaawansowane narzędzia do składania aplikacji z komponentów, współpracujące z popularnymi zestawami programistycznymi IDE, w których tworzy się komponenty. Są to produkty niezbyt drogie, dostępne również małym i średnim organizacjom.

Rozmiar i źródła komponentów

Wybierając komponenty, warto starannie dobierać ich rozmiar do klasy tworzonej aplikacji. Większość zestawów programistycznych IDE zawiera kilkadziesiąt komponentów wizualnych do tworzenia graficznego interfejsu użytkowego, natomiast rzadko zawiera przydatne komponenty biznesowe.

Duże komponenty biznesowe udostępniają wielcy producenci oprogramowania: IBM, Amdahl, EON, Fujitsu, ILOG, Oracle, Sterling Software, a także inni specjalizujący się w dostawach dla dużych korporacji.