W numerze m.in.:

studia

informatyczne

nr 1 rok 2010

issn 2081-1578

W numerze m.in.:

Wyższa Szkoła Menedżerska w Warszawie Wydział Informatyki Stosowanej

Jacek Pomykała, Bartosz Źrałek E-delegation of rights and Id-based proxy signature scheme

Jan zabrodzki Procesory graficzne

Lucjan Grochowski

Programowanie komponentowe

w środowisku WWW

Adres redakcji^:

Wyższa Szkoła Menedżerska w Warszawie Wydział Informatyki Stosowanej

ul. Kawęczyńska 36 03-772 Warszawa tel.: (22) 59 00 830 www.wsm.warszawa.pl Realizacja wydawnicza^:

Wydawnictwo WSM w Warszawie

ul. Kawęczyńska 36 03-772 Warszawa tel.: (22) 59 00 868

e-mail: wydawnictwo@mac.edu.pl Komitet Naukowy^:

Prof. dr hab. inż. Jan Zabrodzki – Przewodniczący

Prof. dr Ir Daniel M. Dubois – (University of Liege, Belgium) Prof. dr hab. inż. Lucjan Grochowski

Doc. dr inż. Waldemar Szulc

Redaktor Naczelny^:

Prof. dr hab. inż. Lucjan Grochowski

Redakcja techniczna: Jarosław Juszczak Projekt okładki: Yarek

Wszystkie artykuły zamieszczone w czasopiśmie są recenzowane

Wydawca

WyżSZA SZKołA MeNeDżeRSKA W WARSZAWIe

Druk:

eLPIL – Jarosław Pilich, ul. Artyleryjska 11, 08-110 Siedlce, tel. (25) 643 50 42

SPIS

TREŚCI

OD REDAKCJI

Jan Zabrodzki

P

Lucjan Grochowski

P

WWW

Andrzej Skorupski, Szczepan Kaniewski

O

IN PROGRAMMABLE STRUCTURES

Jacek Pomykała, Bartosz Źrałek

E-

I

-

SIGNATURE SCHEME ...45 ELEKTRONICZNE DELEGOWANIE UPRAWNIEŃ I IDENTYFIKACJA

SCHEMATU PODPISU PROXY

STUDIA

INFORMATYCZNE

NR 1 ROK 2010

ISSN 2081-1578

ARTYKUŁY

Spis treści 2

Jerzy Cytowski

K

ELEKTROKARDIOGRAFICZNYCH ...57 ELECTROCARDIOGRAPHIC SIGNAL CLASSIFICATION

Waldemar Szulc, Adam Rosiński

M

SPECJALNEGO ZNACZENIA ... 67 CONTROL BIOMETRIC METHOD OF ADVANCED SECURITY

SYSTEM FOR SPECIAL PURPOSES OBJECTS

Spis treści 3

OD REDAKCJI

Z dużą satysfakcją oddajemy do rąk Czytelników pierwszy zeszyt „Studiów Informatycznych” – periodyku popularyzującego naukowe osiągnięcia kadry Wydziału Informatyki Stosowanej Wyższej Szkoły Menedżerskiej w Warszawie oraz współpracujących pracowników innych uczelni i ośrodków badawczych.

Zdecydowaliśmy się publikować tu prace pisane zarówno w języku polskim, jak i w angielskim.

Naszym celem jest upowszechnianie prac obejmujących najnowsze osiągnię- cia w zakresie prowadzonych badań w obszarze informatyki, a także ukazywa- nie trendów rozwoju szeroko rozumianych systemów informatycznych. Ambi- cją naszą jest zapewnienie periodykowi wysokiego poziomu merytorycznego i edytorskiego, nad czym czuwać będzie Rada Naukowa, w skład której wcho- dzą przedstawiciele kadry naukowej Wydziału Informatyki Stosowanej Wyż- szej Szkoły Menedżerskiej w Warszawie oraz współpracujący z nami przedsta- wiciele uczelni zagranicznych.

Wierzymy, że zamieszczane w tym i w dalszych zeszytach „Studiów Infor- matycznych” publikacje będą rozszerzać informatyczną wiedzę Czytelnika i sta- nowić będą istotny przyczynek do burzliwie rozwijającej się dyscypliny naukowej, jaką jest informatyka.

Prof. dr hab. inż. Lucjan Grochowski Redaktor Naczelny

Spis treści 4

Jan Zabrodzki

P ROCESORY GRAFICZNE

1. Wstęp

Grafika komputerowa zajmuje się generowaniem obrazów cyfrowych. Użyt- kownik, korzystając z odpowiedniej aplikacji, definiuje elementy składowe sceny dwuwymiarowej (2D) albo trójwymiarowej (3D). Na podstawie danych o tych obiektach i ich wzajemnym rozmieszczeniu generowany jest obraz cy- frowy składający się ze zbioru pikseli rozmieszczonych w matrycy prostokątnej o rozmiarach odpowiadających wymaganej rozdzielczości obrazu.

Końcowy obraz z reguły musi być wygenerowany w dostatecznie krótkim czasie, aby spełnić wymagania odnośnie do wymaganej częstotliwości wyświe- tlania obrazów na ekranie monitora. Dla przykładu, przy założeniu, że obrazy o rozdzielczości 1600 x 1200 pikseli muszą być wyświetlane z częstotliwością

* Jan Zabrodzki – Wyższa Szkoła Menedżerska w Warszawie, Wydział Informatyki Stosowanej oraz Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych; e-mail:

jza@ii.pw.edu.pl Streszczenie

W grafice komputerowej, wobec dużej ilość obliczeń i ograniczonego czasu dostęp- nego na generowanie kolejnych obrazów, konieczne jest stosowanie wspomagania sprzętowego obliczeń. Od ponad dziesięciu lat produkowane są specjalizowane pro- cesory graficzne (GPU). W miarę rozwoju dostępnej technologii możliwości obli- czeniowe tych procesorów stale rosną. Najnowsze procesory GPU są najbardziej złożonymi procesorami scalonymi dostępnymi na rynku – ich moc obliczeniowa przewyższa moc obliczeniową najbardziej zaawansowanych procesorów uniwersal- nych (CPU). W pracy omówione są procesory GPU, ich geneza, rozwój i stan obecny.

Przedstawione są dwie najnowsze koncepcje architektoniczne procesorów GPU oraz przewidywane kierunki ich rozwoju.

STUDIA INFORMATYCZNE

NR 1 ROK 2010

Jan Zabrodzki 6

75 Hz, czas dostępny na wygenerowanie pojedynczego obrazu jest na poziomie kilkunastu ms – w tym czasie trzeba obliczyć barwę każdego z prawie 2 milio- nów pikseli. Wykonanie tych obliczeń w wymaganym czasie nie jest możliwe za pomocą dostępnych uniwersalnych procesorów CPU. Sytuacja taka, oczywi- ście w innej skali, była zawsze typową sytuacją dla obliczeń związanych z gra- fika komputerową. Stąd praktycznie od początku rozwoju grafiki komputerowej zawsze korzystano ze sprzętowego wspomagania obliczeń (por. punkt 3). Po- czątkowo konstruowano specjalne komputery, później stacje graficzne, następ- nie karty graficzne ze specjalizowanymi układami scalonymi, a w końcu karty graficzne ze specjalizowanymi procesorami graficznymi (GPU). Od tego czasu trwa stały rozwój tych specjalizowanych układów (por. punkt 4).

Obraz cyfrowy może być generowany za pomocą różnych metod i przy wy- korzystaniu różnych algorytmów, zależnie od złożoności obrazu i wymagań co do jego jakości. Z punktu widzenia producentów układów scalonych istotne jest, żeby produkowany układ mógł zyskać jak największą akceptację rynku.

Stąd powinien być możliwie uniwersalny. Z drugiej strony zbytnia uniwersalność ogranicza możliwość optymalizacji wspomagania sprzętowego. Stąd dążono do opracowania takiego ciągu obliczeń, który zapewni odpowiedni kompromis.

W tym kontekście pojawiło się pojęcie „potok obliczeń graficznych”. Typowy potok jest omówiony punkcie 2.

W ostatnich latach w architekturach procesorów graficznych zaczęto wyko- rzystywać procesory SIMD i procesory strumieniowe. Dwa przykładowe roz- wiązania są omówione odpowiednio w punktach 5 i 6.

Korzystanie z procesorów GPU wymaga udostępnienia użytkownikom od- powiednich interfejsów (API) i określenia odpowiednich modeli programo- wych. Zagadnienia te są poruszone w punkcie 7.

W zakończeniu (punkt 8) zwrócono uwagę na tendencję do zbliżania się koncepcji rozwoju układów CPU i GPU.

2. Potok obliczeń graficznych

Jednym z głównych zadań grafiki komputerowej jest generowanie obra- zów reprezentujących wirtualną scenę 3D. Typowa scena składa się ze zbioru obiektów odpowiednio rozmieszczonych i oświetlonych przez zestaw świateł.

Każdy obiekt ma określoną geometrię, parametry opisujące położenie w scenie oraz parametry charakteryzujące właściwości jego powierzchni. Podobnie, źródła światła mają określone położenie w scenie i parametry opisujące ich właściwości. Tak określona scena jest oglądana przez obserwatora (kamerę) znajdującego się w ustalonym miejscu i patrzącego w zadanym kierunku. Od- powiedni widok sceny jest generowany na ekranie monitora.

W ciągu obliczeń związanych z generowaniem widoku sceny z reguły można wyróżnić trzy etapy: modelowanie sceny, rendering sceny i wyświetla-

Procesory graficzne 7 nie sceny (rys. 1). Model sceny oraz elementy składowe sceny najczęściej są generowane za pomocą odpowiedniego programu aplikacyjnego. Dane opisu- jące scenę i jej obiekty składowe stanowią punkt wyjścia dla obliczeń prowa- dzących do wygenerowania obrazu. Ten etap obliczeń określany jest jako ren- dering. Ostatnim etapem jest wyświetlenie obrazu.

Obliczenia na etapie renderingu mogą być realizowane za pomocą różnych metod: metody przetwarzania wierzchołków, metody śledzenia promieni, meto- dy energetycznej, metody fotonów i in. Każda z tych metod ma swoje zalety i wady i wymaga innych rozwiązań przy wspomaganiu sprzętowym. W proce- sorach graficznych, jak dotychczas, wykorzystywana jest metoda przetwarzania wierzchołków.

W metodzie przetwarzania wierzchołków przyjmuje się, że obiekty sceny są opisane za pomocą zbiorów trójkątów przybliżających powierzchnie boczne obiek- tów. Ciąg obliczeń musi zapewnić takie przetwarzanie tych trójkątów, żeby osta- tecznie na ekranie pojawił się obraz sceny widzianej przez obserwatora. Ciąg tych obliczeń może być realizowany różnie i przy wykorzystaniu różnych algorytmów.

W praktyce ciąg obliczeń jest realizowany w postaci potoku przystosowanego do realizacji za pomocą dostępnego sprzętu wspomagającego obliczenia.

Na rysunku 2 przedstawiono typowy ciąg obliczeń – tak zwany potok gra- ficzny – wykorzystywany w procesorach graficznych. W potoku tym można wyróżnić kilka etapów obliczeń. Na początku znane są współrzędne 3D wierzchoł- ków geometrycznych prymitywów (punktów, odcinków, trójkątów), występujących w opisie obiektów sceny i dodatkowe atrybuty związane z tymi wierzchołkami, otrzymane na etapie modelowania sceny i obiektów składowych. Z reguły, opis każdego wierzchołka 3D zawiera informacje o jego współrzędnych x, y, z oraz pomocnicze informacje takie jak kolor, normalna, adres tekstury itp.

W pierwszym etapie (przetwarzanie wierzchołków) przetwarzaniu podlegają wyłącznie wierzchołki prymitywów. W wyniku przekształceń geometrycznych wyznaczane są współrzędne 2D rzutów wierzchołków na płaszczyznę ekranu.

Obliczane są tu również rozmaite atrybuty poszczególnych wierzchołków, istotne dla późniejszych obliczeń.

W drugim etapie (przetwarzanie prymitywów) na podstawie znajomości współrzędnych wierzchołków zrzutowanych na ekran odtwarzane są poszcze- gólne prymitywy (ich rzuty na płaszczyznę ekranu).

Rys. 1. Ogólny tor obliczeń graficznych

Jan Zabrodzki 8

W kolejnym etapie (przetwarzanie fragmentów) ma miejsce tak zwana raste- ryzacja, czyli wyznaczanie wszystkich punktów rastra należących do poszcze- gólnych prymitywów. Punkty te są określane często jako fragmenty. Każdy frag- ment ma przypisane współrzędne x,y oraz głębokość (współrzędna z). Dla każdego fragmentu są wyznaczane również wartości pomocniczych parametrów na podsta- wie interpolacji wartości atrybutów dla wierzchołków prymitywu. Dla każdego fragmentu wyznaczana jest barwa (z uwzględnieniem oświetlenia, tekstury itp.).

Ostatni etap jest poświęcony wyznaczeniu końcowej barwy dla każdego pik- sela na podstawie informacji o fragmentach mających te same współrzędne x, y, co analizowany piksel. W szczególności, rozwiązywane są tu problemy wi- doczności, przezroczystości i mieszania barw fragmentów. Wyznaczone barwy pikseli są zapisywane do bufora pamięci obrazu, skąd później są pobierane w celu wyświetlenia obrazu.

3. Sprzętowe wspomaganie obliczeń

Nawiązując do rysunku 1 zauważmy, że liczba obiektów przetwarzanych przez aplikację z reguły nie jest zbyt duża i czas obliczeń nie jest krytyczny.

Stąd obliczenia na tym etapie najczęściej są wykonywane bezpośrednio przez CPU komputera i nie wymagają wspomagania sprzętowego.

Rys. 2. Typowy potok graficzny

Procesory graficzne 9 Inaczej jest na etapie obliczeń związanych z renderingiem sceny. Tutaj liczba przetwarzanych obiektów jest znacznie większa, a czas obliczeń jest ograniczony.

Wynikiem obliczeń na tym etapie jest informacja o barwie każdego piksela obra- zu i wynik ten powinien pojawiać się w czasie umożliwiającym wyświetlanie kolejnych obrazów sceny z częstotliwością, przy której nie pojawia się efekt migotania obrazu na ekranie. Spełnienie tych warunków wymaga korzystania ze sprzętowego wspomagania obliczeń, realizowanego obecnie najczęściej za po- mocą specjalizowanych procesorów graficznych GPU.

Ostatni etap ciągu obliczeń pokazanego na rys. 1 polega na wyświetleniu ob- liczonego obrazu na ekranie monitora. Etap ten jest wspomagany sprzętowo przez pomocnicze układy dostępne na kartach graficznych.

Historia wspomagania sprzętowego obliczeń dla potoku graficznego sięga początków rozwoju grafiki, kiedy to budowano specjalizowane komputery dla wykonywania obliczeń związanych z grafiką komputerową. W latach osiem- dziesiątych poprzedniego stulecia produkowano złożone (i bardzo drogie) stacje graficzne (np. Silicon Graphics) i inne specjalizowane systemy do obliczeń graficznych (Pixel Planes, Pixel Flow). Możliwości opracowania sprzętu wspomagającego takie obliczenia w komputerach PC pojawiły się na początku lat dziewięćdziesiątych ubiegłego stulecia, kiedy opracowano pierwsze karty graficzne i zaczęto produkować pierwsze układy scalone dedykowane do tych zastosowań. Z czasem złożoność tych układów i ich możliwości obliczeniowe wzrosły na tyle, że zaczęto je określać jako procesory graficzne (GPU – Graphics Processing Unit).

Jak powiedziano wcześniej, praktycznie wszystkie procesory graficzne były projektowane z myślą o metodzie przetwarzania wierzchołków. Byty oczywi- ście próby wspomagania sprzętowego innych metod (na przykład specjalizowa- ne urządzenie do obliczeń związanych z metodą śledzenia promieni), jednak jak dotychczas nie zyskały one większego znaczenia.

Klasyczny potok obliczeń graficznych daje możliwość przyspieszania obli- czeń zarówno w sensie równoległości wykonywania różnych zadań w ramach potoku, jak i w sensie równoległego przetwarzania dużej ilości danych w ra- mach konkretnych zadań. Oba sposoby przyspieszania są poglądowo zilustro- wane na rysunku 3.

W obliczeniach potokowych kolejne stopnie potoku realizują różne operacje.

Każda porcja danych wejściowych poddawana jest obliczeniom w kolejnych stopniach (oznaczonych poglądowo na rysunku 3 jako operacje A, B, C, D i E).

W danym momencie mogą być równocześnie wykonywane wszystkie operacje, przy czym każda z nich w odniesieniu do innych danych. Odwołując się do potoku graficznego z rysunku 2, poszczególne etapy obliczeń mogą być przypi- sane do kolejnych operacji A, B, C, D i E z rysunku 3.

Przy równoległym wykonywaniu obliczeń ta sama operacja jest w danym momencie wykonywana w odniesieniu do kilku danych tego samego typu (na przykład operacje C lub D na rysunku 3). Na przykład operacje przetwarzania

Jan Zabrodzki 10

fragmentów mogą być wykonywane równolegle – w tym samym czasie ta sama operacja (na przykład operacja C na rysunku 3) jest wykonywana dla wielu fragmentów (trzech na rysunku 3).

Trzeba jednak zauważyć, że nie wszystkie etapy obliczeń w potoku poddają się zrównolegleniu. Dotyczy to głównie rasteryzacji, operacji na etapie przetwa- rzania pikseli oraz operacji związanych z teksturowaniem (chodzi głównie o fil- trację tekstur).

Poszczególne fragmenty potoku mogą być realizowane rozmaicie. Mogą tu być wykorzystywane czysto sprzętowe rozwiązania, albo też mogą być wyko- rzystywane odpowiednie procesory (zestawy procesorów), realizujące funkcje przypisane na stałe przez producenta (tzw. funkcje stałe) lub programowane przez użytkownika.

Istotnym elementem dla pracy GPU jest współpraca z systemem pamięci.

Wymagana jest tu bardzo duża przepustowość, co oznacza w praktyce koniecz- ność stosowania szerokich szyn i specjalizowanych pamięci półprzewodniko- wych GDDR. Często wykorzystuje się kieszenie poziomów LI i L2.

W kontekście architektur systemów graficznych (komputerów czy też stacji graficznych), a ostatnio najnowszych procesorów graficznych, spotyka się poję- cia: „architektura SIMD” i „procesory strumieniowe”.

Klasyczny, najczęściej stosowany w uniwersalnych procesorach CPU para- dygmat obliczeń zakłada wykonywanie obliczeń na zasadzie sekwencyjnej, co oznacza, że w danym momencie jest wykonywana tylko jedna operacja. Ten typ obliczeń jest określany w taksonomii Flynna jako SISD (jedna instrukcja, jedna dana). Jeden ze sposobów zwiększania szybkości obliczeń, jak powiedziano wyżej, polega na wykorzystaniu możliwości „zrównoleglania” obliczeń. Orga- nizacja obliczeń, w której wykonuje się poszczególne operacje w odniesieniu do dużej liczby danych równocześnie jest określana mianem SIMD (jedna instruk- cja, wiele danych).

Przetwarzanie strumieniowe jest paradygmatem związanym z przetwarza- niem SIMD. W przetwarzaniu strumieniowym wykonuje się ciąg operacji w od- niesieniu do każdego elementu zbioru danych (strumienia danych), przy czym

Rys. 3. Ilustracja koncepcji obliczeń potokowych i równoległych

Procesory graficzne 11 kolejne operacje są realizowane potokowo. Tutaj aplikacja może wykorzysty- wać wiele jednostek obliczeniowych, na przykład zmiennopozycyjnych, przy czym nie trzeba zapewniać synchronizacji tych jednostek ani komunikacji mię- dzy nimi – wykonanie operacji nie jest uzależnione od dostępności wyniku przetwarzania innej danej ze strumienia (dane w strumieniu są niezależne i są wykorzystywane lokalnie).

4. Rozwój procesorów graficznych

Jak wspomniano wcześniej, pierwsze układy scalone dedykowane wspoma- ganiu obliczeń związanych z renderingiem pojawiły się na początku lat dzie- więćdziesiątych ubiegłego stulecia. W miarę upływu czasu i rozwoju technologii produkcji układów scalonych oraz rosnących wymagań użytkowników, możliwo- ści funkcjonalne i wartości parametrów wydajnościowych stale się zmieniały. Na rys. 4 pokazano poglądowo kolejne fazy rozwoju procesorów graficznych. Warto od razu zauważyć, że w implementacjach procesorów graficznych od początku wykorzystywano idee potokowości i równoległości obliczeń.

Początkowe układy (lata 1995-1998) o złożoności kilku Mtranzystorów wspomagały sprzętowo operacje związane z rasteryzacją, teksturowaniem i prze- twarzaniem pikseli. Jednostka centralna CPU obsługiwała aplikacje oraz wyko- nywała obliczenia związane z przekształceniami geometrycznymi. Do GPU przekazywane były informacje o wierzchołkach prymitywów wyznaczonych już w 2D. Do współpracy między CPU i GPU była wykorzystywana szyna PCI (szybkość transmisji 133 MB/s).

W procesorach GPU z lat 1999-2000 wbudowano sprzętowe wspomaganie przekształceń graficznych i obliczeń związanych z oświetleniem (tzw. proceso- ry T&L). Dzięki temu CPU zostało praktycznie uwolnione od obliczeń związa- nych z renderingiem. Do GPU przekazywana była informacja o wierzchołkach 3D prymitywów. Do komunikacji między CPU i GPU wprowadzona została szyna AGP. Procesory GPU z tego okresu nie zapewniały użytkownikowi moż- liwości wpływania na algorytmy realizowane sprzętowo.

Kolejny etap rozwoju procesorów GPU rozpoczął się około 2001 roku, kiedy to GPU zostało wyposażone w prosty shader wierzchołków, co otworzyło moż- liwość programowania niektórych operacji z potoku obliczeń.

W kolejnych latach wyposażano GPU w coraz to większe możliwości pro- gramowania. I tak, w latach 2002-2003 pojawił się pełny shader wierzchołków (z możliwością realizacji programów z rozgałęzieniami) oraz prosty shader pikseli. W 2004 roku procesory GPU wyposażone były już w pełne shadery wierzchołków i pikseli. Wtedy też szynę AGP zastąpiono szyną PCIe (szybkość transmisji na poziomie 4 GB/s). Złożoność GPU była wówczas na poziomie 300 Mtranzystorów.

Jan Zabrodzki 12

Przy wprowadzaniu shaderów wykorzystywano różne rozwiązania. Kla- syczne rozwiązanie polegało na dołączaniu jednostek obliczeniowych dla sha- derów wierzchołków i pikseli równolegle do funkcji stałych realizujących te funkcje. Wykorzystywano również koncepcję polegającą na tym, że zadania

Rys. 4. Ewolucja procesów graficznych

Procesory graficzne 13 shadera wierzchołków były realizowane przez CPU, które wobec stosunkowo niedużej liczby wierzchołków mogło te operacje wykonywać; koncepcja taka nie była jednak możliwa do zrealizowania w odniesieniu do shaderów pikseli.

Z czasem możliwości obliczeniowe jednostek realizujących shadery na tyle się zwiększyły, że możliwe było stopniowe wycofywanie funkcji stałych realizują- cych zadania tych jednostek i pozostawienie wyłącznie jednostek shaderów.

O ile początkowo shadery wierzchołków realizowały operacje zmiennopo- zycyjne, a shadery pikseli operacje stałopozycyjne, to z upływem czasu obie te jednostki stały się z tego punktu widzenia równoważne i obecnie realizują ope- racje zarówno stałopozycyjne jak i zmiennopozycyjne, w różnych formatach.

Pierwsze realizacje shaderów nie dopuszczały możliwości korzystania z in- strukcji sterujących wykonaniem programu. Z czasem ta sytuacja zmieniła się i możliwe stało się korzystanie z instrukcji if, for, czy też z podprogramów.

Dalej, o ile początkowo dostęp do tekstur był tylko na poziomie shadera pikseli, to później również shadery wierzchołków uzyskały dostęp do tekstur.

Rozwój koncepcji shaderów doprowadził do opracowania shadera geome- trii, który może przetwarzać dane pochodzące z shadera wierzchołków i może generować nowe wierzchołki.

Na przełomie lat 2006 i 2007 pojawiły się procesory GPU realizujące obli- czenia potoku graficznego na nowej zasadzie. W GPU udostępniono zestaw zmiennopozycyjnych procesorów strumieniowych. Każdy z tych procesorów może realizować każdą z programowalnych funkcji potoku obliczeń. Procesor GPU tego typu, GeForce 8800 jest omówiony dokładniej w punkcie 5. Złożo- ność procesora GPU z 2008 roku wynosiła1400 Mtranzystorów i warto dodać, że był to najbardziej złożony produkowany procesor, o mocy obliczeniowej przewyższającej znacznie moce obliczeniowe procesorów CPU.

W 2009 roku przewidywane jest pojawienie się na rynku kolejnego proceso- ra GPU o architekturze SIMD. Istotne właściwości projektowanego procesora Larrabee są omówione w punkcie 6.

5. Architektura procesora GeForce 8800

Producenci procesorów graficznych stale prowadzą analizy istniejących rozwiązań, mające na celu wykrycie „słabych miejsc” i w konsekwencji zapro- ponowanie doskonalszych rozwiązań możliwych do wprowadzenia między innymi dzięki rozwojowi technologii. Po wprowadzeniu procesorów GPU z shaderami wierzchołków i pikseli zauważono, że obciążenie potoku obliczeń nie jest równomierne i zależy od rodzaju renderowanego obrazu – na przykład przy pełnym obciążeniu shadera wierzchołków shader pikseli może być wyko- rzystany w niewielkim stopniu albo odwrotnie. Obrazy, w których występuje niewielka liczba trójkątów o dużych powierzchniach, wymagają przetwarzania stosunkowo niewielu wierzchołków. Z kolei w obrazie o dużej liczbie małych

Jan Zabrodzki 14

trójkątów pojawia się stosunkowo dużo wierzchołków. Obciążenie poszczegól- nych etapów potoku może zmieniać się również na skutek zmiennej długości programów shaderów. Brak możliwości wyrównywania obciążenia skutkuje tym, że moc obliczeniowa GPU nie zawsze jest w pełni wykorzystywana.

Równocześnie widoczna była potrzeba dalszego rozwinięcia idei udostęp- niania kolejnych etapów obliczeń dla programistów. W konsekwencji pojawiła się koncepcja opracowania uniwersalnej jednostki obliczeniowej, która mogłaby wykonywać obliczenia występujące na różnych etapach potoku graficznego, a więc obliczenia typowe dla shadera wierzchołków, dla shadera pikseli, dla shadera geometrii a także wspomagać obliczenia związane z fizyką wykorzy- stywane w zaawansowanej grafice. Z kolei, z chwilą opracowania takiej uni- wersalnej zmiennopozycyjnej jednostki przetwarzającej o zunifikowanej strukturze, można było zaproponować nową architekturę dla realizacji obliczeń graficznych, zawierającą wiele takich jednostek. Tego typu koncepcja została wykorzystana w architekturze procesora GeForce 8800 [13]. Poglądowy schemat blokowy tego procesora GPU pokazano na rysunku 5.

Procesor GPU zawiera 128 uniwersalnych jednostek przetwarzających (JP) – procesorów skalarnych – zorganizowanych w 8 klastrów. W każdym klastrze, oprócz 16 JP, znajdują się jednostki T wspomagające obliczenia związane z teks- turowaniem (wyznaczanie adresów i filtracja tekstur) oraz pamięci kieszeniowe poziomu 1 (LI).

Rys. 5. Architektura procesora GeForce 8800

Procesory graficzne 15 Obliczenia są prowadzone w następujący sposób. Dane z wejściowego stru- mienia wierzchołków są kierowane do kolejnych wolnych procesorów (JP), które wykonują operacje typowe dla shadera wierzchołków. Przetworzone dane są po- nownie kierowane do bloku przydziału zadań i wysyłane do pierwszego wolnego procesora, który wykonuje operacje typowe dla kolejnego etapu obliczeń potoku graficznego itd. Tak więc, kolejne operacje na określonej porcji danych są wyko- nywane przez różne procesory zgodnie z zasadą: pierwszy wolny procesor wykonu- je potrzebne w danym momencie obliczenia. Po wykonaniu pełnego cyklu obliczeń uzyskane wyniki są poddawane przetwarzaniu przez specjalizowane procesory (PP;

jest ich sześć) realizujące funkcje stałe związane z obliczeniami na poziomie prze- twarzania pikseli; wyniki są kierowane do pamięci obrazu. Na tym poziomie są wykorzystywane pamięci kieszeniowe poziomu 2 (L2).

Należy zwrócić uwagę na fakt, że w architekturze GeForce 8800 wykorzy- stuje się wyłącznie skalarne procesory strumieniowe. Procesor strumieniowy wykonuje obliczenia na strumieniu danych wejściowych i tworzy strumień da- nych wyjściowych, który może być wykorzystany przez inne procesory strumie- niowe. Duża liczba takich procesorów zawartych w GPU pozwala na przetwarzanie równoległe – GPU zapewnia równoczesne przetwarzanie tysięcy wątków. Rozwią- zanie takie zostało przyjęte przez firmę NVIDIA, mimo iż wcześniejsze GPU tej firmy zawierały z reguły jednostki przetwarzania wektorowego, co było uza- sadniane tym, że w grafice wiele operacji dotyczy danych wektorowych (na przykład operacje na elementach RGBA czy też na macierzach 4x4.

Warto dodać, że procesor GeForce 8800 ma dodatkowo wbudowany sprzęt dla przetwarzania wideo.

W celu ułatwienia korzystania z procesorów GPU budowanych na bazie ar- chitektury GeForce 8800 firma NVIDIA opracowała technologię CUDA (Compute Unified Device Architecture) stanowiącą jednolite rozwiązanie sprzętowo-pro- gramowe dla potrzeb intensywnego przetwarzania danych. Środowisko progra- mistyczne CUDA umożliwia pisanie programów dla obliczeń równoległych przy wykorzystaniu prostego rozszerzenia języka C. CUDA umożliwia wyko- rzystanie wielowątkowych GPU i zapewnia skalowalność dla obliczeń równo- ległych dostępnych na różnych GPU – dostępne są dziesiątki tysięcy wątków równoległych i setki rdzeni procesorów. CUDA umożliwia wykorzystanie GPU do innych obliczeń niż te związane z grafiką.

6. Architektura procesora Larrabee

Projektanci firmy Intel, po analizie istniejących rozwiązań architektonicz- nych procesorów GPU oraz tendencji rozwoju tych układów, opracowali projekt nowego procesora GPU o nazwie Larrabee [14]. Do najistotniejszych założeń projektu należały: realizacja całkowicie programowanego potoku obliczeń (łącznie z tradycyjnie wspomaganą sprzętowo rasteryzacją oraz przetwarzaniem

Jan Zabrodzki 16

pikselowym) oraz przyjęcie modelu programowania wygodnego dla zastosowań równoległych i nieregularnych struktur danych. W szczególności, istotne było umożliwienie stosowania różnych algorytmów dla określania widoczności (Z-bufor, ray tracing), zapewnienie możliwość dobierania stopnia dokładności obliczeń do zastosowania oraz wspomaganie obliczeń związanych z fizyką i sztuczną inteligencją. Ważne było również dążenie do zintegrowania renderin- gu z zarządzaniem sceną oraz zapewnienie łatwego wprowadzania modyfikacji.

Zaproponowana architektura procesora Larrabee zapewnia przetwarzanie wektorowe, wielowątkowość, rozszerzenia 64. bitowe. Architektura ta ma roz- budowany system pobierania rozkazów i danych z wyprzedzeniem oraz pro- gramowe zarządzanie rozdziałem zadań.

Na rysunku 6 pokazany jest ogólny schemat architektury procesora Larrabee.

Podstawową część systemu stanowi zestaw rdzeni CPU (32, 48,...) połączonych szerokopasmową siecią połączeń. Architektura Larrabee bazuje na rdzeniach in-order CPU (rozwinięcie koncepcji potoku stosowanego w procesorach Pen- tium) i realizuje rozszerzoną listę instrukcji x86. Każdy rdzeń ma swoją pamięć kieszeniową poziomu L2. Komunikacja z innymi elementami systemu odbywa się poprzez te pamięci.

W systemie znajduje się blok wspomagania sprzętowego operacji filtracji tekstur (blok „funkcje stałe” na rysunku 6). Operacje te są wspomagane sprzę- towo ponieważ ich realizacja programowa jest mało efektywna; niemniej istnie- je możliwość programowej realizacji tych operacji. Sieć połączeń jest zrealizo- wana jako dwukierunkowa sieć typu ring, umożliwiająca przesyłanie po 512 bitów w każdą stronę.

Rys. 6. Architektura procesora Larrabee

Procesory graficzne 17 Każdy z rdzeni zawiera jednostkę skalarną oraz 16. pozycyjną jednostkę wek- torową (rozkazy z trzema operandami), pomocnicze rejestry oraz pamięci kiesze- niowe poziomu LI i L2 (rys. 7). Każdy rdzeń może realizować cztery wątki.

W procesorze Larrabee przyjęto następującą koncepcję obliczeń dla render- ingu. Na początku wykonywane są operacje na wierzchołkach i prymitywach oraz wykonywana jest wstępna rasteryzacja prymitywów. Renderowana po- wierzchnia jest dzielona na bloki pikseli, na ogół kwadratowe (32x32, ..., 128x128). Wielkość bloku jest tak dobierana, żeby informacje potrzebne dla jego renderingu mieściły się w kieszeni L2 – wtedy szybkość renderingu bloku prawie nie zależy od jego wielkości. Dla każdego bloku wyznacza się zbiór prymitywów, które mają część wspólną z blokiem (prymityw może należeć do kilku zbiorów). Każdy blok jest przetwarzany przez osobny rdzeń, który wyko- nuje operacje typowe dla etapu rasteryzacji i przetwarzania pikseli. Poszczegól- ne wątki przetwarzają zestawy 16. pikselowe.

Projekt Larrabee wpisuje się w nurt ewolucji w kierunku modelu programo- wania równoległego wspomagającego dowolne algorytmy syntezy obrazu i za- dania inne niż obliczenia związane z grafiką komputerową.

W połowie grudnia 2009 INTEL ogłosił, że wycofuje się z projektu Larrabee.

Rys. 7. Budowa rdzenia wykorzystywanego w procesorze Larrabee

Jan Zabrodzki 18

7. Modele programowe

Korzystanie z procesorów graficznych, czy też kart graficznych, na których te procesory są montowane, ułatwiają interfejsy API. Najczęściej wykorzysty- wanymi API są OpenGL i DirectX. Udostępniają one prosty interfejs dla opi- sywania obliczeń grafiki czasu rzeczywistego i pozwalają uzyskiwać dobrą efektywność bez odwoływania się do równoległości, wątków, przetwarzania asynchronicznego albo synchronizacji. Jednak aplikacje muszą się dostosować do potoku obliczeniowego tych interfejsów, co utrudnia korzystanie z zaawan- sowanych technik renderingu.

Rozwojowi GPU towarzyszy rozwój oprogramowania wspomagającego ko- rzystanie z możliwości oferowanych przez nie. Początkowo GPU mogły być programowane za pomocą asemblera. Po wprowadzeniu shaderów możliwe stało się korzystanie z języków wysokiego poziomu HLSL, Cg, GLSL (GLslang) i innych języków podobnych do C. Korzystanie z tych języków wy- maga jednak dobrej znajomości graficznych API i możliwości wykorzystywanego sprzętu. Stąd też podejmowane są próby stworzenia środowisk programowania uwalniających programistów od konieczności zaznajamiania się z szczegółami budowy GPU. Jednym z takich przykładów jest środowisko Brook [3], w któ- rym programista widzi GPU jako koprocesor strumieniowy.

Coraz większe możliwości programowania GPU otwierają szansę na stoso- wanie nowych rozwiązań algorytmicznych i w efekcie na generowanie coraz bardziej złożonych obrazów o bardzo wysokiej jakości. Równocześnie wzrost mocy tych procesorów zachęca do wykorzystywania GPU do wykonywania obliczeń niezwiązanych z grafiką. Oczywiście GPU umożliwia wykonywanie jedynie niektórych złożonych obliczeń z gatunku obliczeń uniwersalnych – niezależnie od tego, że GPU dysponuje dużą mocą obliczeniową, to wiele roz- wiązań w GPU jest dedykowanych na obliczenia typowe dla grafiki. Chcąc jednak umożliwić wykorzystywanie GPU do różnych zastosowań producenci oferują specjalne środowiska programistyczne takie jak CUDA firmy NVIDIA [9] czy CAL firmy ATI/AMD (Compute Abstraction Layer). Ułatwiają one wykorzystywanie GPU jako jednostek do masowych obliczeń równoległych.

Nie zapewniają jednak możliwości korzystania z funkcji stałych GPU ani in- nych mechanizmów przystosowanych do obliczeń graficznych. Z tego punktu widzenia najkorzystniejszy jest projekt Larrabee, w którym jedynie filtracja tekstur jest realizowana jako funkcja stała.

Należy tu również wspomnieć o projekcie OpenCL (Open Computing Language), mającym na celu wspomaganie pisania aplikacji na wiele platform wykorzystujących różne rodzaje jednostek obliczeniowych (CPU, GPU).

W pracy [15] proponowany jest model programowy GRAMPS (General Runtime Architecture for Multicore Parallel Systems) dla przyszłych GPU. Jest to model programowy dla potoków renderingu i innych obliczeń równoległych, zarówno na poziomie zadań jak i na poziomie danych. Implementacje będą

Procesory graficzne 19 mogły korzystać z różnych kombinacji oprogramowania i wspomagania sprzę- towego; zakładana jest elastyczność w doborze drivera i GPU. W modelu GRAMPS nie jest proponowany potok o ustalonej sekwencji obliczeń. Zamiast tego proponuje się, żeby aplikacja mogła tworzyć odpowiednie dla niej potoki, które będą mogły obejmować zarówno dostępne stałe etapy obliczeń, jak i te programowalne. Zakłada się, że możliwa będzie wydajna realizacja tradycyjne- go potoku obliczeń graficznych oraz możliwa będzie równie wydajna imple- mentacja różnych zaawansowanych potoków obliczeń. Organizacja obliczeń będzie reprezentowana w postaci grafu etapów obliczeń realizowanych asyn- chronicznie i wymieniających dane za pomocą kolejek. W pracy [15] pokazane są przykładowe implementacje potoków obliczeń dla Direct 3D, metody śledze- nia promieni i hybrydy tych dwóch rozwiązań. Pokazana jest również realizacja koncepcji na bazie architektury NVBDIA seria 8 i na bazie architektury Larrabee.

8. Zakończenie

W artykule przedstawiono zagadnienia związane z współczesnymi proceso- rami graficznymi. Na tle rozwoju procesorów graficznych pokazano przykła- dowe architektury najnowszych procesorów GPU. Zapotrzebowanie na grafikę 3D wysokiej rozdzielczości w czasie rzeczywistym doprowadziło do opracowa- nia równoległych, wielowątkowych i wielordzeniowych procesorów, które wspie- rają programistyczny model shaderów grafiki, w którym pojedynczy wątek prze- twarza jeden wierzchołek albo fragment. GPU wykonuje tysiące niezależnych wątków przeliczających równolegle wierzchołki, geometrię, fragmenty i piksele.

Dotychczas najbardziej zaawansowane GPU produkowane były przez firmy NVIDIA (ostatnio GTX280 – technologia 65 nm, 1400 Mtranzystorów, 240 procesorów strumieniowych z zegarem 1296 MHz, 2485 końcówek obudowy) oraz ATI / AMD (ostatnio Radeon 4870 – technologia 55 nm, 965 Mtranzystorów, 800 procesorów strumieniowych z zegarem 750 MHz). Trzeba podkreślić, że liczby procesorów strumieniowych w układach GPU poszczególnych producen- tów są trudne do porównywania za względu na brak wspólnej definicji proceso- ra strumieniowego. Niemniej zostały one przytoczone, żeby przybliżyć rząd wielkości liczby procesorów wykorzystywanych we współczesnych GPU. Warto też zauważyć, że wysiłki twórców GPU nie idą w kierunku zwiększania częstotli- wości zegara, a w kierunku dodawania rdzeni działających z tą samą częstotliwo- ścią (albo i mniejszą) zegara. Końcowy zysk uzyskuje się dzięki zwiększaniu stop- nia równoległości obliczeń.

W pracy zwrócono uwagę głównie na procesory GPU o największych moż- liwościach obliczeniowych. Trzeba jednak wspomnieć, że obok tych najbardziej złożonych procesorów produkowane są również prostsze procesory GPU prze- znaczone do mniej wymagających zastosowań a także specjalizowane procesory dedykowane dla określonych urządzeń (na przykład konsole do gier).

Jan Zabrodzki 20

Rozwój procesorów GPU jest stymulowany przez stale rosnące wymagania stawiane przez użytkowników grafiki 3D, w ostatnim czasie głównie przez twórców gier komputerowych i innych użytkowników zainteresowanych inte- rakcyjną grafiką 3D. Użytkownicy procesorów GPU oczekują, że zapewnią one możliwość generowania odpowiednio dużej liczby ramek na sekundę, zwięk- szenie rozdzielczości ekranu, zwiększenie szczegółowości generowanych scen, zwiększenie dokładności odwzorowania scen, co może oznaczać zmianę pod- stawowego algorytmu renderingu bądź jego elementów oraz generalnie uzyska- nie jakości zbliżonej do jakości filmów generowanych komputerowo. Dążenie do spełnienia takich wymagać znajduje odzwierciedlenie w zmianie tendencji w rozwoju GPU. O ile dawniej algorytmy były opracowywane tak, żeby opty- malnie wykorzystać istniejący sprzęt (GPU), to teraz widoczna jest tendencja do tego, żeby sprzęt (GPU) był w miarę uniwersalny i umożliwiał realizację róż- nych koncepcji i algorytmów renderingu. Przykładowo, o ile dotychczas po- wierzchnie obiektów są reprezentowane przez zbiory wierzchołków, a więc niepołączonych ze sobą elementów, to rozważa się możliwość przetwarzania powierzchni krzywoliniowych jako podstawowych prymitywów (tzw. N-patches).

Najnowsze procesory GPU są obecnie najsilniejszymi jednostkami oblicze- niowymi i ich moc obliczeniowa, dzięki wbudowanym mechanizmom obliczeń równoległych, znacznie przekracza moc obliczeniową najsilniejszych uniwer- salnych procesorów CPU, które niezależnie od tego, nie są przystosowane do realizacji zaawansowanych systemów renderingu bazujących na koncepcjach wielordzeniowości, wielowątkowości i przetwarzaniu SIMD.

Należy jednak pamiętać, że jak dotychczas procesory GPU są projektowane dla zastosowań związanych z grafiką komputerową i mogą pełnić rolę uniwer- salnych procesorów równoległych (GPGPU) jedynie dla określonych zastoso- wań. Niemniej wyraźnie widoczna jest tendencja do zbliżania się dróg rozwoju procesorów CPU i GPU. Ponadto warto zwrócić uwagę na to, że producenci GPU zaczynają brać pod uwagę udostępnienie takich rozwiązań, które umożli- wią wspomaganie sprzętowe obliczeń związanych z innymi metodami genero- wania obrazów niż te bazujące na typowym potoku graficznym – można tu wymienić metodę śledzenia promieni, metodę energetyczną czy też metody typowe dla przetwarzania obrazów.

L

:

[1] AMD Stream Computing User Guide, AMD 2007.

[2] Blythe D., The Direct3D 10 System, ACM Transactions on Graphics, Vol.

25, Issue 3, July 2006,pp.724-734.

[3] Buck I. i in., Brook for GPUs: Stream Computing on Graphics Hardaware, SIGGRAPH 2004, pp. 777-786.

Procesory graficzne 21 [4] Fatahalian K., Houston M., A Closer Look at GPUs, Communications of the ACM, October 2008, vol. 51, No. 10, pp. 50-57.

[5] Fernando R., Kilgard M., Język Cg. Programowanie grafiki w czasie rze- czywistym, Helion 2003.

[6] Fernando R. i in. Programming Graphics Hardware, Eurographics 2004, tutorial, pp. 1-17.

[7] Haines E., An Introductory Tour of Interactive Rendering, IEEE Com- puter Graphics and Applications, January/February 2006, vol.26, no 1 pp. 76-87.

[8] Leavitt N., High-Stakes Battle Rages in Graphics-Chip Marketplace, Computer, October 2008, pp. 13-15.

[9] Lindholm E., i in., NVIDIA Tesla: A Unified Graphics and Computing Architecture, IEEE Micro, March-April 2008, pp. 39-55.

[10] Luebke D., Humphreys G., How GPU Work, Computer February 2007, pp. 96-100.

[11] Mark W., GPUs for Parallel Programming, Acmąueue vol. 6, no 2, March/April 2008.

[12] MOller T., Haines E., Real-Time Rendering, A K Peters 2002.

[13] NVIDIA GeForce 8800 GPU Architecture Overview, Technical Brief TB-02787-001_v09, November 2006.

[14] Seiler L. i in., Larrabee: A Many-Core x86 Architecture for Visual Computing, SIGGRAPH 2008, pp. 18:1-18:15.

[15] Sugerman J., Fatahalin K., Boulos S., Akeley K., Hanrahan P., GRAMPS: A Programming Model for Graphics Pipelines, ACM Transactions on Graphics, Vol. 28, No. l, January 2009.

[16] Venkatasubramanian S., The Graphics Card as a Stream Computer, AT&T Labs-Research 2003.

GRAPHICS PROCESSORS Abstract

Real time computer graphics requires a lot of computations. In consequence the usage of hardware support is a standard. Specialized graphics processors (GPUs) are being produced over ten years. Following the progress of technology their power is steadily growing. The newest GPUs processors are the most powerful integrated processors available on the market. Their computational power overcomes the power offered by the most advanced universal processors (CPUs).

In this paper GPU processors are discussed, including their roots, development and foreseen future. The two newest GPU architectures are discussed.

Lucjan Grochowski

P ROGRAMOWANIE KOMPONENTOWE W ŚRODOWISKU WWW

1. Wstęp

Celem artykułu jest prezentacja obecnego stanu rozwoju metod programo- wania komponentowego, rozumianego jako etap rozwoju oprogramowania roz- wijanego i znajdującego już wiele zastosowań, ale i stanowiącego pośredni etap rozwoju bardziej zaawansowanych metod, wiążących się z budową modeli se- mantycznych i kolektywnej inteligencji systemowej.

Metody programowania inżynierii oprogramowania wymuszane są usługami – aplikacjami lokowanymi w WWW, gdzie są one głównie odnoszone do cha- rakterystycznych architektur systemowych:

ƒ Component Based Software Architecture – CBSA,

ƒ Model Driver Architecture – MDA,

ƒ Service Oriented Architecture – SOA.

* Lucjan Grochowski – Wyższa Szkoła Menedżerska w Warszawie, Wydział Informatyki Sto- sowanej, Katedra Systemów Informatycznych oraz Politechnika Warszawska, Zakład Systemów Informatycznych; e-mail: lgr@it.pw.edu.pl

Streszczenie

Artykuł omawia metody programowania komponentowego, podaje genezę komponen- tu programowego, mechanizmy i implementacje komponentów. Rozważania odnie- sione są do obecnie najbardziej reprezentatywnych technologii komponentowych w środowisku WWW: Enterprise Java Beans (EJB), CORBA Component Model (CCM) i .NET firmy Microsoft.

STUDIA INFORMATYCZNE

NR 1 ROK 2010

Lucjan Grochowski 24

Podczas, gdy architektury CBSA i MDA mają wyraźnie zaznaczony obszar metodologiczny ostatnia architektura SOA łączy cechy podejścia i architektury CBSA i MDA. Przedmiotem zainteresowania artykułu będą metody programowa- nia komponentowego lokowane w obszarze architektury CBSA i jej zastosowań.

2. Komponentowe podejście w programowaniu

2.1. Idea komponentów programowych

Komponenty programowe są efektem rozwoju metod programowania obiek- towego [1-2], których mechanizm działania odnoszony jest do mechanizmu wielokrotnego użycia jednostek programu tworzących zbiór niezależnych kom- ponentów pozwalających na ich wykorzystanie na zasadzie plug and play. Po- dejście takie bynajmniej nie jest nowe, ale w ostatnich czasach nabrało nowych treści determinowanych nowymi możliwościami rozwoju informatyki. Problem jaki tu powstał to przyjęcie ogólnie akceptowanej definicji, co sobą obejmuje komponent programowy, gdyż jest on pojmowany różnie przez różnych auto- rów. Najbardziej adekwatną jest definicja komponentu podana przez Clemensa Szyperskiego [3]: „komponent programowy jest jednostką kompozycji progra- mowej z wyspecyfikowanymi interfejsami i kontekstem ich współzależności.

Komponent programowy może być stosowany niezależnie i jest elementem kom- pozycji mogącej być wykorzystywaną przez trzecią stronę”.

Dwie cechy wyróżnione przez Szyperskiego: deklaracje oferowanych inter- fejsów i żądanie ich współzależności pozwalają traktować komponent jako za- mkniętą całość, która oferuje usługi i żąda ich od zewnętrznych komponentów, przy ukrywaniu swych struktur wewnętrznych i nie wnikaniu w budowę innych komponentów. Konsekwencją jest fakt, że komponent jest jednostką progra- mowania bardziej abstrakcyjną niż obiekt. Podczas, gdy programowanie obiek- towe charakteryzuje polimorfizm wiązania wywołań, częściowa hermetyzacja i dziedziczenie klas, programowanie komponentowe to konfiguracja wdrożenia, wywołania wiązane z ładowaniem kodu, dziedziczenie interfejsów i ich wielo- krotne użycie [4].

W konsekwencji w podejściu obiektowym, w zależnym od użytkownika stop- niu abstrakcji i hermetyzacji, błędy mogą być maskowane większą liczbą po- wiązań obiektów. Powyższe staje się niemożliwe w podejściu komponentowym z uwagi na jednoznacznie określone interfejsy komunikacji komponentów.

Komponenty ponadto odróżnia od obiektów bardziej rygorystyczna hermetyza- cja a także wspomniane jednoznaczne definiowanie interfejsów określających sposoby komunikacji oraz wykorzystywanie tylko w niewielkim stopniu me- chanizmów dziedziczenia [5].

W efekcie podstawowe wymogi spełniane przez komponent to:

ƒ możliwość użycia przez inne elementy programu bez bezpośredniej in- terwencji programisty,

Programowanie komponentowe w środowisku WWW 25

ƒ posiadanie pełnej specyfikacji zależności funkcjonalnych,

ƒ wykorzystanie komponentu wyłącznie na podstawie specyfikacji,

ƒ współpraca i integracja określonego komponentu z innymi komponenta- mi w szybki i bezproblemowy sposób.

Komponenty programowe nigdy nie sprawują kontroli nad sobą, zarządzanie komponentami scedowane jest na kontener i dotyczy tworzenia, współzależno- ści i cyklów życia komponentów. Innymi słowy, w porównaniu do obiektów komponenty nie są jednostkami aktywnymi. Kontener w programowaniu kom- ponentowym realizuje tylko funkcje wynikające z przypisanych im aplikacji biznesowych, a zależności pomiędzy komponentami można osłabiać odpowied- nim definiowaniem interfejsów.

W ogólności metody wprowadzania zależności między komponentami po- dzielić można na trzy grupy:

ƒ zależności komponentów implementujące dedykowany interfejs, poprzez który otrzymują obiekt służący do wyszukiwania zależności; jest to tzw.

metoda wstrzykiwania zależności przez interfejs polegająca na aktywnym wyszukaniu przez komponent wymaganych zależności,

ƒ zależności przekazywane jako parametry konstruktora komponentu; jest to tzw. metoda wstrzykiwania zależności przez konstruktora – wszystkie zależności komponentu muszą zostać spełnione w momencie jego two- rzenia, a ich rozwiązaniem i spełnieniem zajmuje się kontener,

ƒ zależności przekazywane przez właściwości obiektu; tzw. metoda wstrzy- kiwania setter.

Zastosowanie każdej z powyższych metod wprowadzania zależności wiąże się z określonymi konsekwencjami. Nadrzędnym celem programowania kompo- nentowego jest stworzenie środowiska, w którym zależności pomiędzy kompo- nentami są wyszukiwane automatycznie poprzez kryteria spełnienia wymagań funkcjonalnych. Pozostałym celem jest dodatkowo wybór spośród znalezionych opcji programowych rozwiązania najlepiej spełniającego również wymagania niefunkcjonalne i zapewniającego możliwość złożenia wyspecyfikowanych komponentów w całość zadania programowego.

Komponent programowania wykorzystywany jest tylko w określonym za- kresie do realizacji przypisanych mu zadań. Narzuca to cykl życia komponentu zdeterminowany trzema fazami: inicjacji komponentu, świadczonych przez niego usług i zaprzestania jego wykorzystywania. W cyklu takim mieszczą się metody komponentu i kolejność ich wykonywania tak jedno- jak i wielokrotna.

Obecnie najbardziej reprezentatywnymi technologiami sieciowymi wykorzy- stującymi programowanie komponentowe są:

ƒ Enterprice Java Bean – EJB firmy Sun,

ƒ CORBA Component Model – CCM,

ƒ .NET lansowana przez Microsoft jako następca technologii COM. DCOM / COM +, która stanowi rozszerzenie Component Object Model – COM firmy Microsoft.

Lucjan Grochowski 26

Aplikacje odnoszone do tych technologii lokowane są w WWW w warstwie logiki biznesowej; technologie te mają wiele cech podobnych ale różnią się nawet znacznie w szczegółach.

2.2. Komponentowa technologia EJB

Technologię tą obecnie zaliczyć można do najbardziej popularnych. Wynika to przede wszystkim ze znaczenia języka Java, a także wysiłków firmy SUN Inc. w spopularyzowaniu tej technologii, głównie na bazie platformy J2EE. Za popularnością technologii EJB przemawia również względna łatwość pisania aplikacji znajdująca odzwierciedlenie m.in. w aplikacjach bazodanowych odno- szonych do serwerów i klasterów-serwerów aplikacji pośredniczących w do- stępie do zasobów bazodanowych. Komponent programowy rozproszonych aplikacji stanowi tu tzw. bean, który jest komponentem determinowanym pro- tokółem JavaBean specification określającym właściwości i funkcjonalność obiektu, a także wprowadzane zmiany. Protokół ten określa również zasady komunikacji pomiędzy bean-em a otoczeniem. Definiując bean definiujemy klasę, uwzględniając przy tym konwencje narzucone przez specyfikacje stan- dardu. Podstawową zaletą jest tu relatywnie prosta kreacja komponentu jako jednostki programowej [6].

Technologia EJB specyfikuje trzy rodzaje komponentów: jednostki danych (encje), sesje – przetwarzanie danych i obsługa komunikatów. Komponenty są tworzone i zarządzane przez kontener, który przejmuje większość zadań zwią- zanych z dostępem do danych, transakcyjnością itp. Dojrzałą wersję aplikacji EJB stanowiła już wersja 2.1 pozwalająca na implementacje interfejsów rodzaju komponentu, niezmieniony cykl życia i rozwiązywanie zależności przez wy- szukiwania. Wersja 2.1 uchodziła za skomplikowaną w stosowaniu i dla jej uproszczenia wprowadzono wersję 3. Wersja 3 EJB pozwalająca na wykorzy- stanie notacji języka Java zamiast interfejsów i dodatkowe wstrzykiwanie za- leżności przez atrybuty, co znakomicie upraszcza budowę aplikacji.

Popularnym jest wstrzykiwanie zależności poprzez interfejs, polegające na aktywnym wyszukiwaniu komponentów w rejestrze kontenera. Metoda ta pole- ga na implementacji w komponencie specjalnego interfejsu, stanowiącego znacznik wskazujący, że komponent ten wymaga wprowadzenia zależności.

Interfejs definiuje metodę posiadającą parametr, który jest obiektem kontekstu czyli sposobem wyszukiwania innych obiektów. Komponent w momencie utworzenia otrzymuje od kontenera instancję kontekstu, którą może zapamiętać, a następnie wykorzystać do rozwiązania swoich zależności. Mankamentem jest tu jednak silne powiązanie komponentu z konkretnym kontenerem.

Przykładową implementację mechanizmu wstrzykiwania przez interfejs po- kazuje poniższy listing:

Programowanie komponentowe w środowisku WWW 27

Klasa Sklep deklaruje implementację interfejsu. Interfejs ten definiuje meto- dę service(), przyjmującą parametr typu ServiceManager. Parametr pełniący rolę obiektu-kontekstu, zostaje przekazany komponentowi przez kontener w mo- mencie jego tworzenia poprzez wywołanie metody service(). Obiekt ServiceMa- nager wyszukuje komponenty w rejestrze kontenera poprzez metodę lookup(), która korzystając z przekazanego jej klucza komponentu wyszukuje go w reje- strze. Dzięki temu komponent Klient może uzyskać referencję do zależnego komponentu Sklep. Rola komponentu w wyszukaniu zależności polega tu więc na całkowitym uzależnieniu tego procesu od komponentu ponieważ komponent, który nie wywoła metody lookup(), nie otrzyma wymaganej zależności [7].

2.3. Komponentowa technologia CCM

COBRA Component Model – CCM stanowi rozwinięcie wcześniej wprowa- dzonego standardu dla systemów heterogenicznych, który pozwala na współ- pracę aplikacji w środowisku WWW niezależnie od platformy, języka progra- mowania, formatu i struktury danych. Model CCM odnoszony jest do standardu COBRA 3 i determinuje ramy współpracy komponentów rozproszonych pro- gramów w bardziej uniwersalnym zakresie niż operacje, które wynikają z moż- liwości komponentów standardu EJB. Mechanizm pracy CCM zapewnia usługi poprzez dobrze zdefiniowane interfejsy, zwane portami odnoszone do współ- pracy z kontenerami komponentów. Kontener taki oferuje zbiór usług wynika- jący z użytych komponentów i w rozproszonym środowisku przesuwa usługi z pojedynczych komponentów na kontenery komponentów, co wiąże się z istot- nym uproszczeniem struktur programowych wykorzystywanych we wcześniej- szym klasycznym podejściu COBRA [8].

Komponenty CCM kooperują wzajemnie poprzez tzw. ports. Wyróżniane są tu pokazane na rys 1 następujące rodzaje ports:

ƒ facets – definiujące interfejsy zapewniające na zasadzie punkt do punktu użycie metody inwokacji określonych komponentów z innych komponen- tów,

public interface Serviceable {

public void service(ServiceManager manager);

}

public class Sklep implements Servicseable { private ServiceManager manager = null;

private Klient klient = null;

}

public void service(ServiceManager manger) { this.manager = manager;

this. klient = (Klient) manager.lookup(“Klient”);

} }

Lucjan Grochowski 28

ƒ receptables – uzależniające interfejsy określonych komponentów punkt do punktu z innych komponentów,

ƒ event sources / sinks – pozwalające na wymianę informacji między jed- nym lub kilkoma komponentami.

Rys. 1. Komponent CCM z zaznaczonymi charakterystycznymi portami

Kontener w podejściu CCM determinuje środowisko pracy dla jednego lub kilku komponentów określonych notacją zdarzeń, transakcjami, bezpieczeń- stwem itp. Każdy kontener jest odpowiedzialny za inicjowanie i zarządzanie określonymi atrybutami komponentu oraz powiązania danego komponentu z in- nymi poprzez usługi pośrednie tzw. middleware services.

W rozproszonym systemie sieciowym każdy komponent może być konfigu- rowany na różne sposoby. Ponieważ jednak w indywidualnych komponentach liczba konfigurowanych parametrów i opcji wzrasta, w podejściu CCM dla cha- rakteryzowania meta-danych definiuje się grupy komponentów. Stanowią one tzw. assembly entities determinujące abstrakcyjny serwer komponentów, który dokonuje agregacji fizycznych obiektów w logiczne obiekty opisujące rozpro- szone usługi i podsystemy.

W podejściu CCM pociąga to za sobą standaryzację sposobów implementa- cji komponentów odnoszonych do pakietów komponentów z wyróżnionymi własnościami funkcjonalnymi oraz mechanizmami ich użycia. Te ostatnie od- noszą się do tzw. Dynamic Link Library i meta-danych opisujących właściwości w kontekście zastosowań. Pozwala to na wygenerowanie szkieletu implementa- cji komponentów określonej aplikacji, która automatycznie może być zarządza- na przez wykorzystanie tzw. Component Implementation Definition Language (CIDL).

Jest to równoważne budowie swoistej fabryki kreowania kontenerów wraz z ich środowiskiem wykonawczym, demonstruje to rys. 2.

Interfejs komponentu

Facets

Event sources Event

sinks

Atrybuty

Receptacle s

Porty oferowane

Komponent CCM

Porty żądane

Programowanie komponentowe w środowisku WWW 29

Rys. 2. Implementacja komponentów CCM z wykorzystaniem języka CIDL

2.4. Komponentowa technologia .NET

Technologia .NET lansowana jest przez Microsoft jako następca technologii Component Object Model COM oraz jej kolejnej wersji DCOM / COM + . Technologię tą tworzy platforma programistyczna obejmująca środowisko uru- chomieniowe zwane Common Language Runtime – (CLR) oraz biblioteki klas zapewniające funkcjonalność dla tworzonych aplikacji. Charakterystyczną ce- chą tej technologii jest brak powiązań z jednym językiem programowania; pro- gramy mogą być pisane praktycznie w każdym języku wysokiego poziomu dostosowanym do aplikacji sieciowych. Podstawową rolą platformy .NET jest zarządzanie kodami aplikacji, pamięcią i zabezpieczeniami odnoszonymi do środowiska programistycznego działającego tak po stronie serwerów WWW, jak i pracującego na komputerach zawierających implementacje platformy .NET typowo adresowane do aplikacji Microsoftu.

W skład platformy wchodzą kompilatory:

ƒ języków wysokiego poziomu – standardowo C++ / CLI, C#, Visual Basic .NET oraz J# (C#, Java # są wariantami języków C i Java opracowanych przez Microsoft),

ƒ zarządzanych kodów.

Stosowane tu metody kompilacji są podobne do zastosowanych w Javie, gdyż

ƒ kompilatory kompilują najpierw kod źródłowy do postaci uniwersalnego kodu pośredniego zwanego CLI,

PLIKI CIDL

Kompilator CIDL

Repozytorium interfejsów

Komponent IDL kompilator

Pliki IDL

Opis komponentów

Szkielet implementacji komponentów

Szkielety serwerów

Aplikacje klienta

Kod źródła

Kod źródła Kod wygenerowany

Kod wygenerowany Kod wygenerowany

Komponent implementacji - kod źródła

KOMPILATOR KOMPILATOR Kod źródłowy klienta

Program komponentu

Program klienta

Kod wykonywany Kod wykonywany

Lucjan Grochowski 30

ƒ kod CLI, z kolei, jest kompilowany do kodu maszynowego od momentu pierwszego wywołania. Realizowane to jest w czasie wprowadzania kodu przez dołączenie do każdej metody modułu tymczasowego fragmentu kodu, który przekazuje sterowanie do kompilatora i jest zastępowany przez skompilowany kod. Nosi to nazwę kompilacji w locie.

Podstawowymi blokami platformy .NET są bloki CLR, CTS i CSL. Pierwszy z nich odpowiada za lokalizowanie, wczytywanie i zarządzanie typami danych, drugi odpowiada za opis danych udostępnianych przez środowisko uruchomie- niowe a trzeci stanowi zbiór zasad definiujących podzbiór wspólnych typów zgodności kodu binarnego z kompilatorami .NET.

Platformę .NET wyróżnia wprowadzenie pośredniego kodu Common Language Infrastructure zapewniające każdemu językowi programowania dostęp do bi- bliotek .NET. Warunkiem jednak jest tutaj spełnianie przez takie języki wymo- gów standardów obiektowości. Dla podkreślenia spełniania tych standardów wprowadza się do takich języków niekiedy przyrostek .NET np. Visual Basic.NET, JavaScript.NET itp., ale równorzędnie z tym wymogi te spełniają również wa- rianty języków w wersji Microsoftu C#, Java#..., a także inne języki, w których nie wprowadza się żadnych dodatkowych oznaczeń.

Dodać można, że platforma .NET pociągnęła za sobą powstanie kilku po- chodnych technologii, z których najistotniejsze to ADO.NET ułatwiająca dostęp do baz danych oraz ASP.NET adresowana do budowy dynamicznych stron WWW.

Implementacje .NET adresowane są przede wszystkim do platform oznacza- nych jako Microsoft.NET Framework, Novell.Mono i DotGNU Portable.NET.

Pozwalają one na pracę w środowisku programistycznych, z których najbardziej popularne jest zintegrowane środowisko programistyczne Visual Studio 2005 Express obejmujące : Visual Basic 2005 Express Edition, Visual C# 2005 Express Edition, Visual C++ 2005 Express Edition, Visual J# 2005 Express Edition, Visual Web Developer 2005 Express Edition, SQL Server 2005 Express Edition.

Wersje .NET Framework są stale jeszcze rozwijane, ostatnia z nich to .NET Framework 4.0.

3. Wnioski

W artykule przedstawiono w przeglądowym zarysie obecny stan trendów tworzenia oprogramowania, które staje się w wielu obszarach zorientowane na programowanie sieciowe lokowane w WWW. Zaprezentowano, jako najbardziej reprezentatywne do wytyczonego celu, mechanizmy budowy i wykorzystywa- nia komponentów odnoszonych do technologii Enterprise Java Beans, COBRA Component Model oraz technologii firmy Microsoftu .NET. Rozważania po- przedziło zdefiniowanie pojęcia komponentu w kontekście wcześniej wprowa- dzonego na rynek oprogramowania obiektowego, akcentując, że podejście komponentowe jest kolejnym etapem rozwoju współczesnych metod oprogra-

Programowanie komponentowe w środowisku WWW 31 mowania. Pokazano, że komponent jest konfigurowalną jednostką wielokrotnego użytku, a zasadą jego wykorzystania jest instytucja kontenerów programowych pozwalająca na tworzenie pożądanych konfiguracji programowych i zarządzania cyklami życia komponentów. Zaprezentowane mechanizmy programowania kom- ponentowego potraktowano jako dojrzały technicznie etap wykorzystywania metod oprogramowania nie negując przy tym bardziej zaawansowanych, no- wych mechanizmów programowania odnoszących się, np. do metod takich jak Web Semantic. Te ostatnie są wprawdzie bardziej zaawansowane, ale nie osią- gnęły one stopnia dojrzałości pozwalającego na szersze implementacje, zwłasz- cza implementacje biznesowe.

L

:

[1] Cox B.J., Novobilski A.J., Object-Oriented Programming: An Evolutionary Approach, 2nd ed. Addison-Wesley, 1991.

[2] COBRA Component Model, W3C references.

[3] Heineman G.T., Councill W.T., Component-Based Software Engineering:

Putting the Pieces Together, Addison-Wesley Professional, Reading 2001.

[4] Meyer B., Object-Oriented Software Construction, 2nd ed. Prentice Hall, 1997.

[5] Szyperski C., Component Software, ACM Press/ Addison-Wesley, England, 1998.

[6] Szyperski C., Component Software: Beyond Object-Oriented Programming, 2nd ed. Addison-Wesley Professional, Boston 2002.

[7] Veryard R., Component-based business: plug and play, Springer, London 2001.

[8] Zieliński K., Zagadnienia konstrukcji oprogramowania komponentowego, art. w portalu e-Informatyka.pl, http://www.e-informatyka.pl/ article/show-bw/475.

COMPONENT PROGRAMMING IN WWW ENVIRONMENT Abstract

The paper presents the program component methods for WWW environment implementations. There are given the genesis of program component, its operating mechanism in WWW environment and implementing procedures. Considerations are referred to actually the most representative component technologies which are Enterprises Java Bean (EJB), CORBA Component Model (CCM) and .NET Microsoft Corporation.