Komponenty programowe

Zamiast pisaą kod, można składać aplikacje z gotowych elementów.

Zamiast pisać kod, można składaą aplikacje z gotowych elementów.

Budowanie aplikacji z elementów (komponentów) polega na łączeniu i integrowaniu wcześniej opracowanych i wstępnie przetestowanych składników programowych. Czym właściwie są te elementy lub komponenty? Każdy producent narzędzi do opracowania aplikacji deklaruje, że jego produkt pozwala na budowę aplikacji lub używanie w niej gotowych elementów. Niektórzy nawet dostarczają obszerne zestawy takich elementów. Czy oznacza to, że wszystkie narzędzia oferują te same właściwości funkcjonalne i w każdym z nich można używać tych samych elementów składowych? Czy istnieją różne rodzaje elementów i czym one różnią się? Jakie są właściwości tych elementów? Czy istnieją elementy standardowe (cokolwiek standard miałby tu znaczyć)? Jeśli nie odpowiemy na te pytania, nie znajdziemy wspólnego mianownika dla różnych narzędzi.

Nie wszystkie elementy są jednakowe

Zwolennicy programowania obiektowego zechcą zapewne zdefiniować element składowy oprogramowania jako obiekt w rozumieniu ich idei obiektowości. Fundamentaliści zapragną nawet ograniczyą ściśle tę definicję do obiektówspełniających trzy kryteria obiektowości, a mianowicie: dziedziczenie właściwości, polimorfizm, czyli dziedziczenie właściwości wielu obiektów, oraz enkapsulacja (kapsułkowanie) danych wewnątrz obiektu. To raczejakademickie widzenie obiektów nie przyjęło się szeroko na rynku, gdzie królują elementy składowe typu OCX (obecnie zwane ActiveX), opracowywane zgodnie z microsoftową filozofią komunikacji elementów programowych wWindows, a mianowicie OLE (łączenie i osadzanie obiektów). Elementy OCX nie oferują dziedziczenia ani polimorfizmu właściwości; to samo dotyczy też innych obiektów, które można używaą w popularnych pakietachprogramowych, takich jak PowerBuilder lub SQLWindows.

Powszechnie przyjmuje się więc, że za elementem programowym może być każdy moduł programu, który daje się wielokrotnie używać, nawet jeśli nie ma jego wersji źródłowej. Wygodne byłoby tworzenieinnych elementów przez dziedziczenie, ale działają tu prawa rynku. Natomiast poszukiwaną cechą elementu jest niezależność od kontekstu jego użycia. Ogranicza to jednak możliwości elementu do stosunkowo niewielkiego zestawu właściwości, np. do listy rozwijanej czy menu w programach Windows. Istnieje wiele drobnych elementów, które doskonale nadają się do tworzenia aplikacji, ale trudniej wyobrazić sobie, że elementem składowym będzie arkusz obliczeniowy lub program finansowo-księgowy. Trudno będzie zachować niezależność kontekstową.

W programowaniu obiektowym podstawowym motywem działania i motorem postępu jest wielokrotne użycie raz opracowanych obiektów. Jednakże tworzenie obiektów wielokrotnego użytku wymaga intensywnego testowania, atymczasem gonią terminy dokończenia aplikacji. W zespole produkcyjnym nikt nie ma czasu zajmować się problemem, czy elementy opracowane do danej aplikacji przydadzą się w przyszłości. Metoda szybkiej ścieżki tworzenia aplikacji (RAD) wyklucza powstanie elementów do użytku w przyszłości, dopuszczając używanie gotowych, komercyjnych elementów.

Przyjęto więc za elementy składowe uważać takie składniki, które dopuszczają enkapsulację i mogą służyą do budowy aplikacji. Jest to jednak definicja bardzo obszerna, obejmująca różne składniki nie tylko programowe: biblioteki ogólnego przeznaczenia, elementy OCX/ActiveX, specjalistyczne biblioteki narzędzi 4GL, kompletne ramy (framework) aplikacji oraz specyfikacje CASE, generujące aplikację.

Najważniejszą cechą elementów powinna być możliwośą współpracy z innymi elementami przy tworzeniu aplikacji. Nie wszystkie elementy mają publikowany lub standardowy interfejs zewnętrzny i wtedy nie nadają się dotworzenia dowolnych aplikacji, gdyż nie będą współpracować z innymi elementami.

Standardowe biblioteki

Standardowe biblioteki klas to typowy przykład elementów drobnych, które są bliskie czystemu kodowi, operując na ograniczonym zakresie abstrakcji danych. Nie zwiększają one znacznie wydajności programisty, gdyż aby je użyć, musi on poznać całą obszerną bibliotekę (czasem kilkaset lub kilka tysięcy obiektów). W dużych projektach jest to tak poważne ograniczenie, że większość programistów woli pracować z bibliotekami o większej skali integracji funkcjonalnej.

Standardowe biblioteki klas są powszechnie używane z językiem C/C++, a najpopularniejsza jest biblioteka Microsoft Foundation Class (MFC). Niektóre narzędzia 4GL także zawierają takie biblioteki, np. PowerBuilder i Delphi mają własne obszerne biblioteki klas do obsługi baz danych oraz obiektów wizualnych i niewizualnych. Wiele pakietów 4GL ma możliwośą korzystania z bibliotek C/C++ oraz komercyjnych bibliotek dostarczanych przez niezależnych producentów.

Biblioteki klas nie są w żaden sposób standaryzowane, chociaż dla C/C++ nieformalnym standardem stała się biblioteka MFC.

OCX/ActiveX i OpenDoc

Nie są także standaryzowane elementy składowe o większej skali integracji, takie jak OCX. Wprawdzie Microsoft opublikował zestaw funkcji API, którymi można posługiwać się przy ich tworzeniu, ale firma nie ma obowiązku dotrzymywania w tej mierze zobowiązań, a w kolejnych wersjach Windows może tworzyć dodatkowe funkcje systemowe, dające firmie przewagę nad konkurencją w zakresie używania i tworzenia tych elementów.

Nieco lepiej przedstawia się sytuacja jedynego poważnego konkurenta OCX, którym jest konsorcjum firm wspierających OpenDoc. Jest to standard komunikacji obiektowej i metoda tworzenia złożonych dokumentów, oparte na specyfikacji IBM System Object Model (SOM) i Distributed Object Model (DSOM), które bazują na specyfikacji Common Object Request Broker Architecture (CORBA), opracowanej przez organizację Object Management Group (OMG). Obiekty zgodne ze specyfikacją OpenDoc mają właściwośą dziedziczenia, co umożliwia ich modyfikowanie, bez konieczności posiadania kodu źródłowego. Są rozpowszechniane w postaci bibliotek dynamicznych DLL dla Windows i OS/2 oraz bibliotek binarnych dla Unixa. W przeciwieństwie do OCX mogą być używane na różnych platformach i pozwalają na komunikację obiektową między różnymi platformami.

Przewaga rynkowa OCX nad OpenDoc jest tak ogromna, że trudno w ogóle mówią o jakiejkolwiek konkurencji. Na rynku OCX działają setki ,a może tysiące małych firm, sprzedających elementy OCX o dowolnej skali złożoności - od prostych list rozwijanych, przez kalendarze, moduły grafiki prezentacyjnej, arkusze obliczeniowe, aż po kompletne aplikacje. Na ten lukratywny rynek wchodzą także najpotężniejsi producenci oprogramowania: Sybase kupił firmę Visual Components, a Progress firmę Crescent Software.

Ogromny rozwój rynku elementów OCX spowodował, że wszystkie nowe pakiety do tworzenia aplikacji - Delphi 2.0, Optima++, PowerBuilder 5.0 - pozwalają obecnie na ich opracowywanie i używanie.

Biblioteki pakietów 4GL

Takie pakiety narzędziowe, jak PowerBuilder i SQLWindows (Gupta, obecnie Centura), zawierają firmowe zestawy obiektów wielokrotnego użytku - odpowiednio PowerBuilder Foundation Class i QuickObjects, dostępne z pasków narzędziowych pakietu. Wielu niezależnych producentów dostarcza także komercyjne biblioteki klas, które można dołączać do pakietu i używać równie łatwo jak obiekty własne. Lecz te biblioteki klas nie mogą być używane z innych pakietów narzędziowych.

PowerBuilder 5.0 i nowa wersja Centura Team Development dopuszczają także elementy typu OCX.

Ramy aplikacji

Klasy i kompletne obiekty to zestawy części składowych, ale nie zbliża nas to na razie do budowy kompletnej aplikacji. Aby je połączyć, trzeba napisać kod w języku 3GL lub 4GL. Ogromne możliwości szybkiej budowy aplikacji zapewniają ramy programowe (frameworks), stanowiące podłoże (fundament) całej aplikacji, do których dokładane są elementy mniejszej skali. Ze względu na wielką różnorodność aplikacji, ramy są modyfikowalne przez dziedziczenie i oferują narzędzia do dołączania różnych komponentów.

Przykładami ram programowych są Elements Environment (firmy Neuron Data), NeXTStep Developer (firmy NeXT Computer), Total FrameWork (firmy Cincom) i wiele innych nie znanych w Polsce.

Ramy pozwalają na znaczne zwiększenie wydajności programisty, gdyż większa część kodu łączącego elementy jest w nich na miejscu.

Narzędzia CASE

Model aplikacji opracowany za pomocą nowoczesnych narzędzi CASE można uważaą za obiekt programowy, gdyż nie tylko można go modyfikowaą i używać wielokrotnie do generowania zbliżonych aplikacji, ale także wykorzystać go do generowania kodu dla różnych narzędzi. Takie możliwości mają np. ObjectTeam (firma Cadre Technologies, obecnie kupiona przez Cayenne Software), Developer/2000 (Oracle) czy Paradigm Plus (Platinum Technology), pozwalające na generację kodu dla różnych pakietów narzędziowych.

Niektóre z narzędzi CASE zawierają także możliwości zarządzania elementami składowymi aplikacji za pośrednictwem repozytorium obiektów, zapewniające kontrolę wersji i konfiguracji.

Aplikacje jako elementy składowe

Czy kompletne aplikacje mogą stanowić część składową innej aplikacji? Oczywiście tak, pod warunkiem stworzenia wokół nich odpowiedniej otoczki obiektowej, zapewniającej im takie możliwości łączenia i dostępu, jaką oferują typowe komponenty.

Największy producent zintegrowanej aplikacji pakietowej SAP R/3 zamierza w najbliższej przyszłości przebudowaą ją na zestaw komponentów, które użytkownik będzie mógł zestawiać i modyfikować zgodnie z potrzebami.

Największe zyski

Elementy o największej skali integracji przynoszą największe zyski. Im mniej kodu 3GL lub 4GL trzeba napisać do opracowania kompletnej aplikacji, tym większy jest zysk programisty. Ramy programowe, narzędzia CASE i kompletne aplikacje jako komponenty innych aplikacji dają największą szansę na szybki efekt.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200